Das Internet der Dinge zu kompromittieren scheint zurzeit eine der "angesagtesten" Hacker-Betätigungen zu sein. Das Hacken von vernetzten Autos ist hierfür ein illustres Beispiel, wie das große Medienecho auf die Fernsteuerung eines Jeep Cherokee durch die Sicherheitsforscher Charlie Miller und Chris Valasek bewies. Für ihren Versuch haben die beiden eine Sicherheitslücke in UConnect, der Infotainment-Software des Autos, ausgenutzt. Was bei der ganzen Sicherheitsdiskussion seither jedoch zu kurz kommt, ist die Berücksichtigung des Softwareentwicklungsprozesses. Denn schon hier treten Sicherheitsrisiken auf, die im vernetzten Auto zu Gefahren für Leib und Leben werden können.

Einer der wesentlichen Gründe dafür besteht darin, dass sich im Entwicklungsprozess Sicherheitslücken sozusagen einschleichen, das heißt aus Versehen oder Nachlässigkeit entstehen und übersehen werden. Hacker sind unglaublich kreativ in ihrer Hartnäckigkeit, frei nach dem Motto "Wo ein Wille ist, ist auch ein Weg". Deshalb müssen Automobilhersteller das Thema Sicherheit auch unter diesem Aspekt betrachten.

Stürzt eine mobile App wegen eines Softwarefehlers ab, ist das ärgerlich und kostet diese App vielleicht ein paar Nutzer. In der Welt der vernetzten Autos jedoch kann schon ein kleines Problem, das während des Entwicklungsprozesses aufgetreten ist, katastrophale Folgen verursachen. So hat zum Beispiel Honda im Jahr 2014 öffentlich zugegeben, dass ein Softwarefehler in einer elektronischen Kontrolleinheit (ECU) zu willkürlichen Beschleunigungsvorgängen führte. Das Unternehmen rief deshalb 175.000 Hybridautos in die Werkstatt. Selbst wenn in solchen Fällen glücklicherweise keine physischen Schäden zu beklagen sind, sind die mit Rückrufaktionen verbundenen Kosten und die daraus resultierende Rufschädigung nicht zu unterschätzen.

Autos von heute enthalten mehrere zehn Millionen Zeilen an Softwarecode, die von über hundert elektronischen Kontrolleinheiten ausgeführt werden. Mit dem Aufkommen des vernetzten Autos kann die Codemenge schnell eine ganz neue Größenordnung erreichen. Unter Umständen muss der Code häufiger aktualisiert werden, auch über Funk, was zusätzliche Sicherheitsrisiken verursachen kann.

Die Trennung von Systemen, so dass wesentliche Funktionen der klassischen Fahrzeugsicherheit - z. B. beim Bremsen, Lenken und Beschleunigen - voneinander isoliert sind, ist sicherlich ein Teil der Antwort auf diese Risiken. Aber selbst wenn die Fahrzeugsicherheitssysteme getrennt sind, findet typisch für das vernetzte Auto weiterhin ein hohes Maß an externer Kommunikation statt, zum Beispiel WiFi-Updates, GPS-Empfang, Ferndiagnose etc. Jede dieser Verbindungen stellt ein potenzielles Sicherheitsrisiko dar.

Eine gemeinsame, transparente Basis

Was ist also zu tun? Eine Voraussetzung für mehr Sicherheit im vernetzten Auto stellt eine größere Transparenz im gesamten Design-Prozess dar. Diese ermöglicht einen höheren Grad an Teamarbeit zwischen allen Beteiligten und macht die gesamte Entwicklungshistorie für etwaige Untersuchungen in der Zukunft zugänglich.

Die am meisten gebrauchten Programmiersprachen für das vernetzte Auto sind C und C++. Dabei handelt es sich um ältere Sprachen. Dennoch halten die Fahrzeughersteller weiterhin daran fest, einmal aufgrund der bereits getätigten Investitionen in den Code-Bestand, zum anderen aber wegen der geringen Auslastung des Arbeitsspeichers, Beschränkungen bei der Code-Ausführung in Echtzeit und der Notwendigkeit, maschinennahe Gerätetreiber zu schreiben (obwohl speziell hierfür mit den Programmiersprachen Rust und Ivory Alternativen zur Verfügung stünden).

Das Problem mit C und C++ besteht darin, dass sie Angriffe erleichtern können, zum Beispiel über Format-String-Attacken, Pufferüberlauf, defekte Pointer oder Softwarefehler bei der Rechteerweiterung. Allerdings lässt sich der Abschied von diesen Entwicklungsplattformen in vielen Fällen nicht über Nacht bewerkstelligen. Die Automobilindustrie bemüht sich jedoch, die Risiken rund um die Codeentwicklung anzugehen und zu beseitigen. Zu den bereits länger bestehenden Initiativen in dieser Richtung zählen etwa die Programmierstandards der "Motor Industry Software Reliability Association" (MISRA), die vor der Verwendung risikoanfälligen Codes schützen sollten.

Statische Analysen können den Quellcode oder die Repositories von Versionskontrollsystemen untersuchen, um nicht regelkonformen Code aufzuspüren, Softwarefehler oder mögliche Sicherheitslücken zu entdecken. Andere Werkzeuge können Regelverstöße aufdecken, Flow-Analysen und Code-Reviews erstellen sowie Laufzeitfehler offenlegen, um Lecks im Arbeitsspeicher oder Pufferüberläufe während des Build- und Testprozesses zu identifizieren. Internationale Standards wie ISO26262 schließlich genießen einen hohen Verbreitungsgrad, um die funktionale Sicherheit zu gewährleisten.

Leider liegt das Problem jedoch nicht allein in der Software. Optimale Design- und Entwicklungspraktiken für Fahrzeug- und Informationssicherheit würden die Bereiche Hardware und Software nicht getrennt voneinander betrachten. Eine ganzheitliche Herangehensweise war in der Vergangenheit jedoch schwer umzusetzen, weil die verwendeten Werkzeuge einfach zu unterschiedlich waren. Heute jedoch gibt es moderne Versionsverwaltungssysteme, die sowohl mit Hardware-Designs (und damit zusammenhängenden Assets wie Simulator-Definitionen oder Testskripten) als auch mit Softwarequellcode umgehen können. Wird ein zentrales Repository genutzt, lassen sich Lücken und Missverständnisse zwischen sämtlichen beteiligten Teams und Prozessen vermeiden.