Holen Sie sich die neuesten wichtigen Update-Informationen für die Log4j-Sicherheitslücke. Sehen Sie sich an, wie Sie das Problem mithilfe der Parasoft-Anleitung beheben können. Erfahren Sie mehr >>
Holen Sie sich die neuesten wichtigen Update-Informationen für die Log4j-Sicherheitslücke. Sehen Sie sich an, wie Sie das Problem mithilfe der Parasoft-Anleitung beheben können. Erfahren Sie mehr >>
Lesezeit: 9 MinutenDie 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:
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.
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
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:
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 Forschung 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.
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.
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.
Forschung zeigt, dass eine unzureichende Fehlerbeseitigung die Hauptursache für Software von schlechter Qualität ist. Programmierer sind zu etwa 35% effizient darin, Fehler in ihrer eigenen Software zu finden. Später im Entwicklungszyklus liegen die meisten Mängel, die wir nach all den Entwurfsprüfungen, Peer Reviews, Komponententests 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.
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.
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.
Arthur ist seit über 25 Jahren bei Parasoft im Bereich Software-Sicherheit und Testautomatisierung tätig. Er hilft bei der Erforschung neuer Methoden und Techniken (einschließlich 5 Patente) und hilft Kunden dabei, ihre Software-Praktiken zu verbessern.