Eine Unze Prävention: Sicherheit durch Software-Codierungsstandards

Die Software wurde vom Desktop auf nahezu alles verschoben, was wir berühren. Von intelligenten Thermostaten über Infusionspumpen bis hin zu Autos ist Software allgegenwärtig und wächst. Die sogenannten „Dinge“ aus dem Internet der Dinge (IoT) tragen zunehmend mehr Logik. Damit ein größeres Ausfallrisiko. Viele dieser Geräte werden in sicherheitskritischen Bereichen wie Medizin und Automobil eingesetzt, in denen sie möglicherweise Körperverletzungen verursachen können.

Die meisten Unternehmen, die Geräte bauen, betrachten die aktuelle Softwareentwicklung zu Recht als eine fast verrückte Gruppe von Cowboys und Chaos. Aber es gibt Hoffnung. Software kann und muss als technische Praxis behandelt werden. Codierungsstandards, die Teil einer guten Softwareentwicklungspraxis sind, führen uns vom Zyklus „Erstellen, Versagen, Reparieren“ zu einem Zyklus „Entwerfen, Erstellen, Liefern“ mit hoher Qualität, Sicherheit und Schutz.

Wie sich herausstellt, bieten dieselben Standards auch Vorteile in den Bereichen Cybersicherheit, da sie doppelte Pflichten erfüllen. Dieser Beitrag beschreibt:

• Wie diese Standards uns helfen, von der Suche nach Fehlern zur Entwicklung robusterer Software überzugehen.
• So verhindern Sie Probleme mit der richtigen Codierung.
• Wie Sie die Bemühungen anderer nutzen können, indem Sie allgemein anerkannte Industriestandards wie MISRA verwenden, um dieses Ziel zu erreichen.

Softwareentwicklung zum Software Engineering

Die Auswirkungen von Software auf die reale Welt werden häufig nicht berücksichtigt. Eines meiner Hauptthemen, über das ich als Evangelist bei Parasoft ständig diskutiere, ist, dass Softwareentwicklung eigentlich Engineering sein sollte.

Wir nennen Softwareentwickler häufig die Titel-Software-Ingenieure, aber das ist nicht unbedingt der richtige Begriff für ihre heutige Arbeitsweise. Die Entwicklung zu einer guten Softwareentwicklungspraxis führt zu sinkenden Kosten und steigender Qualität. Ein wesentlicher Teil davon ist die Übernahme von Standards, insbesondere von Codierungsstandards.

Das Alter des vernetzten Autos, des IoT und der ständig verbundenen Geräte ist da. Software schleicht sich in Produkte, Geräte und andere Orte ein, an die wir nie gedacht haben. Wir müssen jetzt über die Software in diesen Produkten und deren Auswirkungen nachdenken.

Die Kosten für schlechte Qualität

Eines der interessanten Dinge, die ich zu erklären versuche, ist, dass das Erstellen guter Software sich vom Erstellen eines Autos unterscheidet. Wenn ich versuche, ein hochwertiges Auto zu bauen, muss ich mehr für Materialien und mehr Zeit für den Bau aufwenden. Es stellt sich heraus, dass Sie in Software nicht mehr für die Erstellung hochwertiger Software ausgeben. Sie geben mehr aus, um Software von schlechter Qualität zu erstellen.

Wir müssen verstehen, dass in der Software die meisten Fehler vom Programmierer stammen, der sie in das Produkt einfügt. Wenn wir bei der Entwicklung der Software keine Fehler mehr einführen können, können wir viel bessere Software zu einem niedrigeren Preis haben.

Dieses Zitat stammt aus einem Gespräch aus dem Jahr 1972 mit dem Titel „Der bescheidene Programmierer”, Von Edsger W Dijkstra. Es ist heute noch sehr relevant.

Es ist wichtig zu wissen, wie sich Qualität auf die Kosten der Softwareentwicklung auswirkt. Kapern JonesDer Forscher verfolgt dies seit Jahrzehnten und führt jedes Jahr eine Umfrage zu den Softwarekosten durch. Die Zahlen ändern sich nicht viel von Jahr zu Jahr. Die Daten zeigen, dass die typischen Softwarekosten von den Anforderungen über die Codierung bis zur Wartung mit jeder Phase steigen. Die Art und Weise, wie Teams sich der Qualität nähern, bestimmt jedoch, ob ihr Prozess gesund oder „pathologisch“ ist.

Abbildung 1: Softwarequalität 2011: Ein Überblick über den Stand der Software - Capers Jones

Warum wir Fehler frühzeitig beheben müssen

Es ist sinnvoll, dass die Kosten relativ günstig sind, wenn wir beim Schreiben des Codes einen Fehler richtig finden - beispielsweise einige Minuten Entwicklerzeit. Wenn es möglich ist, 85% der Fehler in der Entwicklungsphase zu beseitigen, hat dies einen großen Einfluss auf die Kosten. Betrachten Sie die jetzt bekannte Grafik von Capers Jones, die die durchschnittlichen Kosten für die Behebung von Fehlern in jeder Entwicklungsphase zeigt:

Abbildung 2: Quellen - Angewandte Softwaremessung, Capers Jones, 1996, Einbau von Sicherheit in den Software-Lebenszyklus, Marco M. Morana, 2006

Die Behebung von Fehlern nach der Veröffentlichung kostet etwa 16,000 US-Dollar (möglicherweise viel mehr), basierend auf der Forschung an echten Unternehmen, die echte Software herstellen, und nicht auf einem theoretischen Modell. Wenn wir uns späte Qualitäts- und Sicherheitsbemühungen wie Penetrationstests ansehen, befinden sich die hier gefundenen Sicherheitsprobleme am teuren Ende des Zyklus. Es ist wahrscheinlich 15-mal so teuer wie das Auffinden von Schwachstellen durch Tests im Vergleich zu frühen Sicherheitsüberprüfungen.

Ein veralteter und nachweislich falscher Ansatz besteht darin, die Qualität Ihrer Software zu verbessern, indem Sie sie am Ende des Lebenszyklus kurz vor der Veröffentlichung testen. In der Fertigungswelt verstehen sie, dass dies unmöglich ist, aber aus irgendeinem Grund glauben wir, dass wir Qualität (und Sicherheit) in Software testen können.

Die Gründe, warum ich sage, dass Softwareentwicklung fast nie Engineering ist, sind diese gemeinsamen Merkmale der aktuellen Softwareentwicklung:

• Was die meisten Entwickler tun, ist nicht wiederholbar. Das heißt, wenn ich zwei verschiedenen Personen dieselbe Aufgabe gebe, sind die Ergebnisse nicht dieselben.
• Mangel an gut ausgeübten Best Practices. Softwareentwickler betrachten Codierungsstandards als ein Wort, das wenig Bedeutung hat. Standards werden als eine Reihe von Regeln betrachtet, auf die der Teamleiter besteht, dass ich sie befolge, anstatt zu verstehen, dass der Codierungsstandard die Verkörperung von Wissen, Praxis und Erfahrung ist. Ein Elektrotechniker weiß, dass Standards der Weg sind, um beim ersten Mal ein sicheres Produkt zu bauen. Ein Softwareentwickler glaubt, dass Standards eine Einschränkung sind, die sie verlangsamt… ein „falsches Positiv“.
• Entwicklerschulungen sind unbekannt und inkonsistent. Die Ausbildung in Softwareentwicklung ist nicht wie in technischen Disziplinen standardisiert. Standards und etablierte Praktiken sind oft nicht Teil des Lehrplans, sondern der Schwerpunkt liegt auf Programmiersprachen.

Codierungsstandards verbessern die Sicherheit

Das Ziel von Software-Codierungsstandards besteht darin, bewährte Programmierpraktiken zu vermitteln, die zu sicherem, zuverlässigem, testbarem und wartbarem Code führen. In der Regel bedeutet dies, bekannte unsichere Codierungspraktiken oder Code zu vermeiden, die zu unvorhersehbarem Verhalten führen können. Dies ist in Programmiersprachen wie C und C ++ von entscheidender Bedeutung, in denen das Potenzial zum Schreiben von unsicherem oder unsicherem Code hoch ist.

Ich denke jedoch, dass sich die Branche mit diesen Programmierstandards verirrt hat. In den letzten zehn Jahren haben sich die Tools (z. B. statische Analysetools) von der Erkennung potenziell problematischer Codes, die unsicher sind oder eine bekannte Sprachschwäche aufweisen, zu einem Fokus auf die Suche nach Fehlern als eine Form des frühen Testens, auch als Linksverschiebung bezeichnet, verschoben.

Obwohl das Suchen nach Fehlern wichtig ist, ist das Erstellen von Sound-Software eine produktivere Aktivität. Was wir tun sollten, ist die Erstellung und Durchsetzung von Standards, um die Situation zu vermeiden, in der Fehler überhaupt erst auftreten - und noch weiter nach links zu verschieben.

Um dies zu sichern, betrachten Sie die Forschungsprojekte Dies wurde vom Software Engineering Institute (SEI) durchgeführt, wo nicht überraschend festgestellt wurde, dass Sicherheit und Zuverlässigkeit Hand in Hand gehen und dass die Sicherheit von Software anhand der Anzahl und Art der festgestellten Qualitätsfehler vorhergesagt werden kann. Darüber hinaus sind kritische Fehler häufig Codierungsfehler, die durch Inspektionen und Tools wie statische Analysen verhindert werden können.

Industriestandards

Dieser Beitrag geht nicht auf Details zu jedem dieser Punkte ein Kodierungsstandards In den folgenden Industriestandards gibt es jedoch eine beträchtliche Menge an Arbeit. Obwohl ihre Anwendung für einen bestimmten Typ spezifisch sein kann, werden diese Standards in vielen Branchen angewendet. Hier einige Beispiele für etablierte Codierungsstandards für Sicherheit und Schutz.

• MISRA C / C ++: Es wurde von der Motor Industry Software Reliability Association entwickelt und beschreibt eine Teilmenge der Sprache C oder C++ und Richtlinien für deren Verwendung, um die Sicherheit der Anwendung zu verbessern. Obwohl es ursprünglich auf Automobilanwendungen ausgerichtet war, wurde es in anderen sicherheitskritischen Anwendungen eingesetzt. „MISRA“, „MISRA C“ und das Dreieckslogo sind eingetragene Marken von The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Alle Rechte vorbehalten.
• SEI / SANS CERT: Das Computer Emergency Response Team (CERT) des Software Engineering Institute (SEI) verfügt über eine Reihe von Richtlinien, die Entwicklern helfen sollen, sicherere, sicherere und zuverlässigere Software zu erstellen. Die Richtlinien werden durch Gruppen von „Regeln“ und „Empfehlungen“ in ihre Bedeutung unterteilt. Sie sind sehr gründlich und umfassend und enthalten Risikometadaten.
• OWASP Top 10: Das Open Web Application Security Project (OWASP) ist, wie der Name schon sagt, eine Organisation, die sich der Verbesserung der Sicherheit von Webanwendungen verschrieben hat. Daher bietet ihr OWASP Top 10-Projekt eine Liste der häufigsten und schwerwiegendsten Sicherheitslücken in Webanwendungen. Die neueste Version von OWASP Top 10 ist direkt mit spezifischen CWE-IDs korreliert und enthält Risikometadaten.
• Joint Strike Fighter Luftfahrzeug C ++ Codierungsstandard (JSF AV): Ein Standard, der auf einer Teilmenge von MISRA C speziell für das JSF-Programm basiert.
• CWE - Common Weakness Enumeration Top 25: CWE ist eine Liste der entdeckten Software-Schwachstellen, die auf der Analyse der gemeldeten Schwachstellen (CVEs) basiert. In den Top 25 sind die häufigsten und gefährlichsten Sicherheitslücken aufgeführt, die aus der größeren Liste der CWEs ausgewählt wurden. Hierbei handelt es sich um Exploits, bei denen eine hohe Wahrscheinlichkeit des Auftretens besteht und die Auswirkungen der Ausnutzung der Schwachstelle groß sind. CWE enthält auch Risikoinformationen in Form von technischen Auswirkungen, um zu verstehen, welche Probleme für Ihr Unternehmen am wichtigsten sind.

Betrachten wir MISRA C, das ich erwähnt habe, nicht nur für Automobilanwendungen. Es ist jedoch ein Standard, der seit 1998 verwendet wird und gut definiert ist. Es wird alle paar Jahre aktualisiert. Während sich C- und C ++ - Sprachen weiterentwickeln, entwickeln sie die Standards, die damit verbunden sind. Es ist ein sehr flexibler Standard, der unterschiedliche Schweregrade berücksichtigt, und es gibt eine dokumentierte Strategie für die Behandlung und Dokumentation von Abweichungen.

Als Technologie, die Verstöße gegen Codierungsstandardrichtlinien (wie statische Analyse) erkennen kann, berücksichtigen neuere Versionen von MISRA, welche Richtlinien entscheidbar sind (mit hoher Präzision durch Tools erkennbar) und welche nicht. Damit sind wir beim Thema Akzeptanz und Durchsetzung und der Bedeutung statischer Analysetools für Codierungsstandards.

 

Rolle der statischen Analyse

Untersuchungen zeigen, dass eine unzureichende Fehlerbeseitigung die Hauptursache für qualitativ schlechte Software ist. Programmierer sind zu etwa 35 % effizient darin, Fehler in ihrer eigenen Software zu finden. Später im Entwicklungszyklus liegen die meisten Fehler, die wir nach all den Design-Reviews, Peer-Reviews, Unit-Tests und Funktionstests beseitigen können, bei etwa 75 %.

Eine statische Analyse kann bei ordnungsgemäßer Verwendung in einem vorbeugenden Modus die Fehlerbeseitigung auf etwa 85% erhöhen. Der Schwerpunkt der statischen Analyse für die meisten Unternehmen liegt heute jedoch auf der Erkennung und der schnellen Lösung.

Weitere Vorteile sind möglich, wenn statische Analysewerkzeuge verwendet werden, um bekannte schlechte Programmierpraktiken und Sprachfunktionen zu verhindern. Hier kommen Codierungsstandards als Richtlinien und Teilmengen der Programmiersprache ins Spiel, die verhindern, dass häufig auftretende Fehler wie Pufferüberläufe oder fehlende Initialisierung in den Code geschrieben werden.

Eine Unze Prävention

Stellen Sie sich ein Beispiel vor, bei dem beim Testen ein ziemlich komplexer Pufferüberlauffehler festgestellt wird, möglicherweise mit einem dynamischen Anwendungssicherheitstool (DAST). Dies ist ein Glücksfall, da Ihre Tests gerade den Codepfad ausgeführt haben, der den Fehler enthält. Sobald es erkannt und debuggt wurde, muss es erneut getestet werden und so weiter. Die statische Analyse mithilfe der Flussanalyse hat diesen Fehler möglicherweise ebenfalls festgestellt, hängt jedoch von der Komplexität der Anwendung ab.

Die Erkennung von Laufzeitfehlern ist präzise, ​​überprüft jedoch nur die von Ihnen ausgeführten Codezeilen. Es ist also nur so gut wie Ihre Testcode-Abdeckung. Überlegen Sie, ob ein Codierungsstandard den Code verboten hat, der diesen Fehler überhaupt aktiviert hat.

Codierungsstandards wie MISRA C beschreiben beispielsweise nicht, wie nicht initialisierter Speicher erkannt wird, sondern weisen Programmierer an, Code zu schreiben, der überhaupt nicht zu einem solchen Fehler führt. Ich glaube, dies ist viel mehr ein technischer Ansatz: Programm nach bekannten und anerkannten Standards. Nehmen wir zum Beispiel Tiefbau und Brückenbau.

Wir würden nicht den Ansatz verfolgen, eine Brücke zu bauen und sie dann zu testen, indem wir immer größere Lastwagen darüber fahren, bis sie zusammenbricht, das Gewicht des letzten erfolgreichen Lastwagens messen und ihn erneut bauen, um diesem neuen Gewicht standzuhalten. Dieser Ansatz wäre noch dumm, er ist nicht anders als die Art und Weise, wie wir uns der Softwareentwicklung nähern.

Sobald ein Softwareteam einen Codierungsstandard anwendet und die statische Analyse ordnungsgemäß angewendet wird, kann es Fehler frühzeitig erkennen und verhindern. Mit anderen Worten, anstatt frühzeitig einen Fehler zu finden, was gut ist, ändert das Team die Art und Weise, wie Code geschrieben wird, was besser ist!

Betrachten Sie die Heartbleed Verletzlichkeit. Es gibt jetzt Detektoren für diese spezielle Sicherheitsanfälligkeit, aber es gibt eine Möglichkeit, Code so zu schreiben, dass Heartbleed überhaupt nicht hätte passieren können. Prävention ist eine bessere und sicherere Methode.

Zusammenfassung

Dykstra sagte: "Diejenigen, die wirklich zuverlässige Software wollen, werden feststellen, dass sie Mittel finden müssen, um die meisten Fehler zu vermeiden." Eine solide Präventionsmethode ist weniger als die Kosten für die Behebung dieser Fehler.

Codierungsstandards verkörpern fundierte technische Prinzipien für die Programmierung in ihren jeweiligen Sprachen und bilden die Grundlage für jeden präventiven Ansatz. Die Kosten für gute Software sind geringer als die Kosten für schlechte Software. Wenn Sie heute keine statische Analyse verwenden oder sie nur zur Früherkennung verwenden, werfen Sie einen Blick auf die statischen Analysetools von Parasoft für C und C ++, Javaund C # und VB.NET mit einer umfangreichen Bibliothek von Checkern für alle gängigen Sicherheitsstandards.