Wo Programmierstandards helfen und wo nicht Software-Sicherheit in der Fahrzeugentwicklung

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

SYNOPSYS GmbH

Eskenzi PR Limited

Programmierstandards wie MISRA-C sind in der automobilen Softwareentwicklung etabliert und decken inzwischen auch (Cyber-)Sicherheit ab. Aber was bringt die Einhaltung oder gar Konformität mit diesen Standards wirklich? Und welcher Programmierstandard ist der richtige?

Die Menge der in einem Fahrzeug verbauten Software wächst schon seit Jahren exponentiell. Auf aktuellen Modellen laufen längst jenseits von 100 Millionen Zeilen Code. Die Automobilbranche spricht von „Software-definierten Fahrzeugen“, deren Features und Funktionen primär durch Software ermöglicht werden.

Gleichermaßen hat sich die Anzahl der externen Schnittstellen erhöht. Immer mehr Funktionen können drahtlos aus der Ferne bedient und überwacht werden. Beide Faktoren haben dazu beigetragen, dass sich die Angriffsfläche für potenzielle Cyberattacken drastisch verbreitert hat.

Glücklicherweise steht aus der IT und anderen Industriebereichen sehr viel Know-how zu Cybersicherheit zur Verfügung, das sukzessive in den Automobilbereich übertragen wird. Hierbei versucht man, sich an bereits etablierte Prozesse und Standards in der Fahrzeugentwicklung „anzuflanschen“. Das ist sinnvoll, um eine möglichst reibungslose Umsetzung der jeweiligen Maßnahmen und Methoden zu gewährleisten.

Der im letzten Jahr veröffentlichte Standard ISO/SAE 21434 („Road Vehicles – Cybersecurity Engineering“) ist ein gutes Beispiel für diese Entwicklung, orientiert er sich doch stark am bekannten ISO 26262 für Funktionale Sicherheit. Daher ist es wenig überraschend, dass auch der ISO/SAE 21434 die Anwendung von Coding Standards wie MISRA-C oder CERT-C empfiehlt.

Dieser Umstand und die gute Überprüfbarkeit des Quellcodes auf Konformität durch entsprechende Tools haben Coding Standards zu einer der häufigsten Cyber-Security-Maßnahmen in der automobilen Softwareentwicklung gemacht. Interessant ist, dass im traditionellen AppSec-Bereich solche Programmierstandards eine vergleichsweise untergeordnete Rolle spielen. Dort setzt man eher darauf potenzielle Schwachstellen zu finden, etwa durch Code Reviews von Softwaresicherheits-Experten oder durch sogenannte SAST-Tools.

Das hängt unter anderem damit zusammen, dass viele Sicherheitsschwachstellen durch den Datenfluss von manipulierbaren (englisch „tainted“) Daten entstehen, z.B. der Buffer-Overflow. Das lässt sich durch Coding-Regeln nur bedingt verhindern und erfordert oft eine tiefergehende Taint-Analyse. Dazu später mehr, widmen wir uns zunächst dem Cybersicherheitsstandard ISO/SAE 21434.

Anforderungen gemäß ISO/SAE 21434

ISO/SAE 21434 deckt die Entwicklung des gesamten elektrisch-elektronischen (E/E) Systems im Fahrzeug unter Cybersicherheitsaspekten ab. Ziel des Standards ist es, Anforderungen für die Cybersicherheit über den gesamten Lebenszyklus des Fahrzeugs zu spezifizieren sowie ein Framework zur Verfügung zu stellen, an dem man sich bei der Umsetzung orientieren kann.

Anforderungen, die Programmierstandards für die Softwareentwicklung vorschlagen, finden sich im Kapitel 10 („Product Development“). Da der Standard eine Entwicklung nach dem V-Modell unterstellt, teilt sich die Softwareentwicklung in eine Implementierungsphase (linker Ast des V) und eine Integrations- und Verifikationsphase (rechter Ast im vorangestellten Bild). Es finden sich folgende Anforderungen:

• RQ-10-05 fordert die Verwendung von Coding Guidelines, sofern die Programmiersprache selbst nicht für genug Sicherheit sorgt (also z.B. dem Entwickler gar nicht die Möglichkeit gibt, Buffer Overflow-Schwachstellen zu erzeugen). Es wird beispielhaft auf die Coding Standards MISRA-C und CERT-C verwiesen.

• RQ-10-10 ist das Gegenstück auf dem rechten Ast des V und verlangt unter anderem die Feststellung der Konformität mit den vorher genannten Coding Guidelines durch entsprechende Testmethoden, wie etwa der statischen Codeanalyse.

Über die Verwendung und Einhaltung von Coding Standards hinausgehend, wird in RC-10-12 eine Überprüfung auf nicht identifizierte Codeschwächen („Weaknesses“) sowie Schwachstellen („Vulnerabilities“) empfohlen. Das ist der Bereich der klassischen Softwaresicherheitstools wie beispielsweise SAST, DAST und Fuzz Testing.

Coding Standards für sichereres Programmieren

Die bekanntesten Coding Standards für der Automobilentwicklung werden von dem MISRA-Konsortium (Motor Industry Software Reliability Association) bereitgestellt. MISRA-C gibt es bereits seit 1998, als Coding Guidelines für Eingebettete Systeme. Obwohl nicht ausschließlich für den Automobilbereich entworfen, haben sich die Richtlinien dort etabliert. Die MISRA Coding Guidelines haben insbesondere durch die Empfehlung im ISO 26262 Standard für Funktionale Sicherheit stark an Bedeutung gewonnen.

Auf den Bereich Cybersicherheit wurden sie erstmals 2016 mit dem Amendment 1 für MISRA-C 2012 erweitert. 2018 kamen dann weitere Regeln aus den bekannten Standards SEI CERT-C und ISO/IEC TS 17961:2013 für sicheres Programmieren hinzu. Aktuell arbeitet das MISRA-Konsortium an der „Renovierung“ von MISRA-C++.

Coding Standards sind vor allem dort beliebt, wo Konformität im Vordergrund steht. Durch die enge Verknüpfung mit den Standards ISO 26262 und 21434 ist die Verwendung von MISRA-C in der Fahrzeugsoftwareentwicklung nahezu obligatorisch. In anderen Bereichen wie beispielweise der Verteidigungsindustrie oder der Medizintechnik sieht es ähnlich aus.

Licht und Schatten

Die Verwendung von Coding Standards hilft, besseren Code zu schreiben, weil es lediglich erlaubt ist, eine Untermenge der Programmiersprache zu verwenden. Dadurch vermeidet man „ungünstige“ Muster, also beispielsweise Konstrukte, die bestimmte Arten von Schwachstellen wie Buffer Overflows begünstigen. Ähnliches gilt für Strukturen, welche die Komplexität unnötig erhöhen oder die nicht eindeutig sind. Vermeidet man auch die, lässt sich eine Software deutlich besser warten und portieren.

Dank guter Tool-Unterstützung lassen sich die entsprechenden Regeln bereits während der Codeentwicklung automatisiert überprüfen. Viele integrierte Entwicklungsumgebungen (IDEs) bringen diese Unterstützung bereits mit oder lassen sich durch entsprechende Plug-ins nachrüsten. Der große Vorteil gegenüber einer nachträglichen Überprüfung, etwa in der CI-Pipeline, besteht darin ist, dass der Entwickler den Code direkt im Kontext anpassen kann, statt zu einem späteren Zeitpunkt zum fertigen Code zurückkehren zu müssen.

Daher eignen sich Coding Standards sehr gut für neuen Code. In den meisten Fällen allerdings nicht für die nachträgliche Standardisierung von existierendem Code. Das wäre in etwa so, als würde man einen spanischen Text mithilfe einer französischen Rechtschreibkorrektur ins Französische übersetzen. Am Ende hätte man zwar vermutlich einen französischen Text. Nur würde der Inhalt nicht mehr dem Originaltext entsprechen – im besten Fall. Leider ist es aber genau dieses Vorgehen, was wir in der Praxis häufig beobachten.

Ein anderes Phänomen: Coding Standards werden mit statischer Codeanalyse gleichgesetzt. Das führt tendenziell zu einem trügerischen Sicherheitsgefühl. Oft verzichtet man dann in der Folge auf SAST oder Secure Code Reviews, weil man ja bereits statische Codeanalyse einsetzt.

Tools für statische Codeanalyse

Dabei ist es ist wichtig zu verstehen, dass der Begriff der statischen Codeanalyse lediglich die grundsätzliche Methode bezeichnet. Was der Begriff nicht definiert, ist die Qualität der Ergebnisse. Mittels statischer Codeanalyse lassen sich einfache (Programmier-)Regeln nahezu in Echtzeit überprüfen, aber auch aufwändige Kontroll- und Datenflussanalysen durchführen, die auf großen Codebasen nicht selten stundenlang laufen.

Der Markt bietet eine Fülle von Tools für die statische Codeanalyse. Das macht es zuweilen schwierig, das am besten geeignete zu finden. Neben etlichen technischen und kommerziellen Aspekten sollte man sich vorrangig über den geplanten Anwendungsbereich im Klaren sein – insbesondere, ob das Tool primär für die Einhaltung von Programmierregeln oder das Aufspüren von Schwachstellen eingesetzt werden soll.

Viele Tools unterstützen beides (Coding Standards und SAST). Aber Achtung: häufig ist eines davon sozusagen die Paradedisziplin und der jeweils andere Bereich ist erst später hinzugefügt worden – setzt aber auf der gleiche Engine auf. Das führt unter Umständen zu Nachteilen in Bezug auf die Laufzeit oder die Qualität der Ergebnisse, je nachdem, welche Engine verwendet wird.

Tools, mit denen man die Einhaltung von Coding Standards überprüfen kann, arbeiten häufig musterbasiert, d.h. sie suchen nach bestimmten Codemustern, die die jeweilige Regel verletzen. Das ist normalerweise weniger aufwändig als eine vollständige Kontroll- und Datenflussanalyse und erlaubt eine schnelle Überprüfung schon im Editor oder der IDE.

SAST-Tools sind auf das Finden von Sicherheitsschwachstellen spezialisiert, und decken diese oft mittels der bereits erwähnten Taint-Analyse auf. Dabei handelt es sich um eine tiefergehende Kontroll- und Datenflussanalyse, bei der potenziell manipulierbare Daten vom Ursprung (z.B. einer CAN-Leseroutine) bis zu ihrer sicherheitskritischen Verwendung (z.B. als Eingangsparameter für die Motorsteuerung) nachverfolgt werden.

Besonders ausgefeilte SAST-Tools versuchen, potenzielle Schwachstellen zu validieren, indem sie Indizien und (falls möglich) Beweise für deren Präsenz sammeln. Dabei werden komplexe Algorithmen angewendet, um die Intention des Entwicklers zu erkennen und so die Anzahl der falsch-positiven Meldungen zu senken.

Fazit

Die Verwendung von Coding Standards ist sinnvoll und sagt etwas über die damit entwickelte Software aus – so wie ein Zahnarzt bei einem Patienten, der sich an empfohlene Maßnahmen zur Zahngesundheit hält, eine andere Erwartung hat als bei einem der dies nicht tut. Man sollte sich aber darüber im Klaren sein, dass Coding Standards keinen allumfänglichen Schutz bieten und – um bei dem Vergleich zu bleiben – den regelmäßigen Besuch beim Zahnarzt nicht ersetzen. Es ist vielmehr ein Versuch, das Know-how des Zahnarztes seinem Patienten als „Best Practice“ zur Verfügung zu stellen.

Letztendlich ist beides nötig: die Prophylaxe, aber auch der Experte. Ob es sich dabei um einen Secure Code Review eines Sicherheitsexperten handelt oder um ein SAST-Werkzeug, das hängt dann von anderen Anforderungen wie z.B. der Automatisierbarkeit ab. Kombi-Tools, die beides können, bieten Vorteile. Hier sollte man aber beide Bereiche separat evaluieren.

* Gunnar Braun ist Security Engineer bei Synopsys und unterstützt große Unternehmen bei der Erstellung von sicherer Software. Zuvor war er in verschiedenen Engineering- und Managementfunkionen im Bereich Embedded Systems, Simulation und Compilation bei CoWare tätig, einem Technologie-StartUp, das 2010 von Synopsys übernommen wurde. Er besitzt einen Diplomabschluss der RWTH Aachen.

(ID:48717013)