Erste Schritte zur Einführung eingebetteter sicherer Codierungsstandards

Es gibt so viele sicherheitsorientierte Codierungspraktiken und -standards (z. B. CERT, OWASP, CWE, MISRA, AUTOSAR und eine ganze Familie von IEC 61508-basierten Standards). Wie bestimmen Sie die Codierungsstandards, die für Ihr spezifisches Projekt gelten sollen? Dieser Leitfaden wird Sie auf Ihren Weg bringen.

Software spielt in unserem täglichen Leben immer mehr eine wichtige Rolle. Alltägliche Geräte enthalten Software wie Autos, Telefone, Kühlschränke, Uhren, medizinische Geräte oder Flugzeuge. Und Organisationen, auf die wir uns verlassen, von einer Bank oder einer Versicherungsgesellschaft bis hin zu einem Kraftwerk oder einem Verkehrskontrollsystem, sind alle auf zuverlässige Software angewiesen. Die Existenz dieser Software bietet uns viele Möglichkeiten: Wir leben in Smart Homes, fahren Smart Cars und unsere Smartphones und Smartwatches unterstützen uns bei allem, was wir brauchen. Da immer mehr dieser Elemente miteinander verbunden werden, können wir zusätzliche Vorteile hinzufügen und Effizienz, die unser Leben so viel einfacher machen.

All dies ist jedoch mit einem Risiko verbunden. Sicherheitslücken in der Software können ausgenutzt werden, um unprivilegierten Zugriff auf jedes System zu erhalten. Dies kann einfache Hacks bedeuten, wie das Ausschalten des Lichts, wenn wir es nicht erwarten, oder alarmierendere Angriffe, wie das Ausspionieren mit unseren Kameras oder das Leeren unserer Bankkonten ohne unser Wissen oder unsere Erlaubnis. Und Softwarefehler, die zu unerwünschtem Verhalten einer Anwendung führen, können ähnliche Probleme verursachen, auch ohne Beteiligung eines Cyberkriminellen. Aus diesen Gründen wird die Software-Sicherheit für Bürger auf der ganzen Welt immer wichtiger.

Sichere Codierung: Von CVE zu CWE Top 25

1999 begann die MITRE Corporation (eine amerikanische gemeinnützige Organisation, die von der Bundesregierung geförderte Forschungs- und Entwicklungszentren betreibt), bekannte Sicherheitslücken in Bezug auf Software auf der Liste der Common Vulnerabilities and Exposures (CVE) zu dokumentieren. Die ursprüngliche Liste bestand aus 321 CVE-Einträgen, wuchs jedoch schnell und derzeit (Stand September 2018) enthält die CVE-Liste über 100,000 Einträge und wird von 92 CVE-Nummerierungsbehörden (CNAs) verwaltet - verschiedenen Organisationen aus der ganzen Welt ( Schwachstellenforscher, Produktanbieter und Bug-Bounty-Programme), die berechtigt sind, erkannten Problemen CVE-IDs zuzuweisen. Die Liste ist sehr weit verbreitet und wird vom Nationalen Institut für Standards und Technologie (NIST), der US-amerikanischen Agentur für Verteidigungsinformationssysteme (DISA) und vielen anderen empfohlen.

Die MITRE Corporation wollte es einfacher machen, die Wurzeln der häufigsten Probleme zu verstehen und geeignete Maßnahmen zu ergreifen, um ähnliche Probleme in Zukunft zu vermeiden. Daher kategorisierten sie die CVE-Einträge je nach Art des Problems, das mit der Veröffentlichung von endete, in Gruppen das Dokument mit der vorläufigen Liste der Beispiele für Sicherheitslücken für Forscher (PLOVER). Die Kombination dieser Arbeit mit anderen Untersuchungen führte zur Definition der CWE-Liste (Common Weakness Enumeration), bei der es sich um eine formale Liste von Schwachstellentypen für Software handelt. Derzeit enthält die CWE-Liste Version 3.1 rund 800 Arten von Schwachstellen, die in 300 Kategorien und Ansichten unterteilt sind. Da diese Zahl überwältigend sein kann, wird die Liste der „25 gefährlichsten Softwarefehler“ von der CWE in Zusammenarbeit mit dem SANS-Institut geführt, um die am weitesten verbreiteten und kritischsten Fehler beizubehalten, die zu schwerwiegenden Sicherheitslücken in der Software führen können. Am Anfang der aktuellen Liste der „Top 25“ stehen beispielsweise SQL-Injections, OS Command Injections, Buffer Overflows und Cross-Site Scripting.

Funktionale Sicherheitsstandards

Für Branchen, in denen Sicherheit viel wichtiger ist als in anderen (z. B. Luft-, Automobil- oder Gesundheitssysteme im Vergleich zu Fernsehen oder anderen Unterhaltungssystemen), hat die Internationale Elektrotechnische Kommission (IEC) die IEC 61508: Funktionale Sicherheit elektrischer / elektronischer / programmierbarer elektronischer sicherheitsrelevanter Systeme. IEC 61508 ist eine Allzwecknorm, die in einer Vielzahl von Branchen verwendet wird. Hier sind jedoch auch Normen aufgeführt, die für die jeweiligen Branchen bestimmt sind, z.

• In der Luft: DO-178C / ED-12C
• Automobil: ISO 26262
• Eisenbahn: IEC 62279 / EN 50128
• Kernkraftwerke: IEC 61513

Diese Standards berücksichtigen Besonderheiten einer bestimmten Domäne, aber ihre allgemeine Idee - zumindest aus Sicht der Software - ist ziemlich ähnlich. Alle von ihnen erfordern (neben anderen Überprüfungstechniken) eine statische Analyse des entwickelten Codes und bieten einige allgemeine Richtlinien für die erforderlichen Maßnahmen, wobei viel Raum für Interpretationen bleibt. Sie nennen normalerweise keine spezifischen Codierungskonventionen oder Codierungsstandards, die verwendet werden sollen, aber z. B. erwähnt ISO 26262 MISRA C als Beispiel für eine Codierungsrichtlinie für die Programmiersprache C.

(Sichere) Codierungsstandards

Das Schreiben von sicherem Code bedeutet das Schreiben von Code, der nicht anfällig ist, dh Code, der keine Schwachstellen enthält, die möglicherweise ausgenutzt werden könnten. Es bedeutet, Code zu schreiben, der einigen „sicheren“ Mustern entspricht, und Code, der „unsichere“ Muster vermeidet. Und diese Muster sind für verschiedene Programmiersprachen unterschiedlich. Natürlich gibt es kein einziges goldenes Regelwerk, das befolgt werden könnte, um die Sicherheit der Software zu gewährleisten. Einige der weit verbreiteten Codierungsstandards, die die Sicherheit berücksichtigen, sind:

• Für C-Sprache: MISRA C, SEI CERT C Codierungsstandard
• Für die C ++ - Sprache: MISRA C ++, JSF AV C ++ - Codierungsstandard, SEI CERT C ++ - Codierungsstandard, AUTOSAR C ++ - Codierungsrichtlinien

Die Standards MISRA C und MISRA C ++ werden von der Motor Industry Software Reliability Association (MISRA) entwickelt. Die AUTOSAR C ++ - Codierungsrichtlinien wurden von der Entwicklungspartnerschaft AUTOSAR (AUTomotive Open System ARchitecture) entwickelt. Der JSF AV C ++ Coding Standard wurde von der Lockheed Martin Corporation entwickelt. SEI CERT C- und C ++ - Codierungsstandards enthalten allgemeine Regeln, die die Sicherheit, Zuverlässigkeit und Sicherheit von Softwaresystemen gewährleisten sollen, die in den Programmiersprachen C und C ++ entwickelt wurden.

Die Regeln in diesen Standards sind normalerweise in mehrere Kategorien unterteilt, um eine einfachere Navigation zu ermöglichen, da die Anzahl der Regeln in einem bestimmten Standard sehr groß sein kann, z.

• MISRA C 2012 enthält 173 Richtlinien mit 156 Regeln und 17 Richtlinien
• CERT C hat 307 Richtlinien mit 121 Regeln und 186 Empfehlungen
• AUTOSAR hat 344 Richtlinien, von denen 319 erforderlich und 25 „beratend“ sind.
• CERT C ++ verfügt über 163 Richtlinien mit 83 C ++ - Regeln und 80 relevanten C-Regeln

In Anbetracht der Anzahl der verschiedenen Standards für die funktionale Sicherheit, der Codierungsstandards und der Anzahl der von jedem Standard empfohlenen oder geforderten Richtlinien ist es wichtig, gute Entscheidungen zu treffen, wenn Sie die Initiative zur Sicherung des Codes starten.

„MISRA“, „MISRA C“ und das Dreieckslogo sind eingetragene Marken von The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Alle Rechte vorbehalten.

So wählen Sie den richtigen Kodierungsstandard

Wenn die Software nach einem bestimmten funktionalen Sicherheitsstandard zertifiziert werden muss (z. B. ISO 26262 für die Automobilindustrie oder DO-178C für die Luftfahrt), ist die erste Entscheidung bereits getroffen. Unabhängig davon muss jedoch eine Auswahl getroffen werden, um den Codierungsstandard oder die Codierungsstandards oder eine Teilmenge eines Standards zu bestimmen, der für die entwickelte Software durchgesetzt werden soll. Es kann, muss aber nicht einer der oben genannten Standards sein.

Als nächstes muss ein geeignetes statisches Codeanalyse-Tool ausgewählt werden, da es nicht möglich ist, die Einhaltung all dieser Regeln manuell zu überprüfen. Es sind sowohl Open-Source- als auch kommerzielle statische Analysetools verfügbar. Es ist wichtig, einen guten zu holen. Einige der Faktoren, die berücksichtigt werden sollten, sind:

• Unterstützt das Tool die ausgewählten Codierungsstandards vollständig oder teilweise?
• Wenn die Werkzeugqualifikation nach dem Funktionssicherheitsstandard erforderlich ist, ist das Werkzeug zertifiziert? Bietet es das Qualifikationskit?
• Kann das Tool Analyseberichte in einer Form erstellen, die für die Durchführung von Compliance-Analysen erforderlich ist?
• Kann das Tool Analyseberichte in einer Form erstellen, die für die Entwickler leicht lesbar ist?
• Lässt sich das Tool sauber in verwendete IDEs, Build- und CI-Systeme integrieren?
• Ermöglicht das Tool die selektive Analyse des neuen Codes, des geänderten Codes oder des Legacy-Codes?
• Unterstützt das Tool die flexible Konfiguration der Analyse?
• Nutzt das Tool die Algorithmen zur Risikobewertung, um festgestellte Fehler zu priorisieren?

Darüber hinaus führt die CWE-Community das CWE-Programm für Kompatibilität und Effektivität durch, bei dem es sich um einen formellen Überprüfungs- und Bewertungsprozess für ein Produkt oder eine Dienstleistung handelt. Die Liste der „offiziell CWE-kompatiblen“ Produkte und Dienstleistungen enthält derzeit 55 Einträge. Durch die Verwendung des Tools aus dieser Liste wird sichergestellt, dass die letzte Phase des formellen CWE-Kompatibilitätsprogramms von MITRE erreicht ist.

Wenn der Codierungsstandard und das geeignete Tool ausgewählt sind, sollte für die von Grund auf neu gestarteten Softwareprojekte die weitere Arbeit einfach sein - integrieren Sie das Tool einfach in das CI-System und stellen Sie sicher, dass kein Fehler unbeaufsichtigt bleibt. In der Regel muss der Codierungsstandard für die bereits in der Entwicklung befindliche Software durchgesetzt werden.

In solchen Fällen kann die blinde Ausführung der Analyse auf der gesamten Codebasis dazu führen, dass Hunderte von Fehlern gemeldet werden, die insgesamt schwer zu handhaben sind. Glücklicherweise gibt es mehrere Techniken, die verwendet werden können, um den Prozess zu vereinfachen. Beispielsweise können Sie sich zuerst auf den neu geschriebenen oder geänderten Code konzentrieren, um sicherzustellen, dass ab dem Zeitpunkt der Festlegung des Codierungsstandards mindestens keine neuen Fehler mehr auftreten.

Eine weitere bewährte Methode besteht darin, die gemeldeten Mängel zu priorisieren, um sicherzustellen, dass die schwerwiegendsten überhaupt behandelt werden. Mit CERT C- und C ++ - Regeln ist beispielsweise eine Risikobewertung verbunden, die eine einfache Priorisierung gefundener Fehler ermöglicht.

Ein ausgeklügeltes statisches Analysetool kann Ihnen auch dabei helfen, sich zuerst auf die Regeln mit dem höchsten Schweregrad zu konzentrieren und die Anzahl der Regeln zu erhöhen, die Sie beachten, wenn die schwerwiegenderen Fehler behoben werden.

Fazit

Der wichtigste Teil besteht darin, sicherzustellen, dass auf die Analyse geeignete Maßnahmen des Entwicklungsteams folgen. Es spielt keine Rolle, wie gut die Berichte aus der statischen Analyse sind, wenn sie nicht von den Entwicklern zum Korrigieren des Codes verwendet werden, was zu sichereren Softwareprodukten führt. Wenn Sie sich die Zeit nehmen, die richtige statische Analyselösung und die richtigen Codierungsstandards auszuwählen, sind Sie auf dem Weg zum Erfolg.