Cyber Security in Fahrzeugen: Wettlauf zwischen Hackern und Industrie
Sicherheitslücken in Fahrzeugen, deren Software nicht mit der Außenwelt kommuniziert, wären wenig problematisch. Doch diese Situation gibt es in Neuwagen praktisch nicht mehr.
(Bild: Mercedes)
Mit der Digitalisierung von Autos nimmt die Bedrohung durch Cyber-Attacken zu. Die Industrie muss mit einer ganzheitlichen Sicherheitsinfrastruktur antworten.
Die Zeiten, in denen Fahrzeuge vor allem aus mechanischen und elektronischen Komponenten bestanden, sind längst vorbei. Schon 1967 produzierte Volkswagen ein Fahrzeug mit dem computergestützten, elektronischen Einspritzsystem D-Jetronic von Bosch. Seit den 1970er-Jahren ist Software fester Bestandteil von Autos. Heute werden in modernen Fahrzeugen fast alle Funktionen durch Software unterstützt, selbst so simple Dinge wie ein Scheibenwischer. Dass sich zunehmend die Bezeichnung Software Defined Vehicle (SDV) durchsetzt, ist also nur folgerichtig.
Wie relevant Software für Autos ist, lässt sich auch mit Zahlen veranschaulichen. So umfasst die durchschnittliche Software in einem aktuellen Auto rund 120 Millionen Zeilen Code. Zum Vergleich: Der Tarnkappen-Kampfjet F-35 von Lockheed Martin benötigt etwa 25 Millionen Zeilen, die Boeing 787 zwischen10 und 15 Millionen. Richtig bescheiden nimmt sich das Space Shuttle aus. Mit lediglich 400.000 Zeilen Code beförderte das Raumschiff jahrzehntelang Menschen ins All und wieder zurück.
Einmal Attacke, bitte!
Für Fahrer bringt die Digitalisierung der Fahrzeuge eine Reihe von Vorteilen mit sich. Dazu gehört in vielen Fällen auch eine zusätzliche, physische Sicherheit: Ein Abstandhalter hilft dabei, Auffahrunfälle zu vermeiden, ein Spurhalteassistent greift ein, wenn der Fahrer in einen Sekundenschlaf fällt. Gleichzeitig ergeben sich aus der Digitalisierung auch neue Risiken durch Cyber-Attacken. Das liegt vor allem an drei Faktoren.
Mit jeder zusätzlichen Zeile Code nimmt aus statistischer Sicht auch die Anzahl an Bugs zu. Als Faustregel gilt im Automotive-Kontext: Pro einer Million Zeilen Code ist mit etwa 1000 Bugs zu rechnen, was schon eine super Qualität ist. Von etwa fünf Prozent dieser Bugs geht die Gefahr von Cyber-Angriffen aus. Bei einer durchschnittlichen SDV-Software sind also 6000 kritische Programmierfehler wahrscheinlich. By the way: Bug-Bounty-Programme können den Herstellern helfen, gemeinsam mit der Security Community Bugs frühzeitig zu finden und dann rasch zu beheben. Tesla beispielsweise ist hier schon sehr aktiv [1].
Wären Autos in sich geschlossene Systeme, wären solche Bugs kein so großes Risiko, da die Angriffe einen physischen Zugang erfordern würden und sich auch nicht selbstständig verteilen könnten. Der Aufwand wäre für Cyberkriminelle zu hoch. Tatsächlich sind Fahrzeuge aber offen und kommunizieren über viele verschiedene Schnittstellen mit ihrer Umwelt. Nicht nur über das Internet, sondern ebenso über Bluetooth, das automatische Notrufsystem eCall, über Mirco-SD-Karten und über OBD-2-Diagnosebuchsen. All das sind potenzielle Einfallstore für Hacker.
Fahrzeuge kommunizieren außerdem nicht nur mit ihrer Umwelt, die einzelnen verbauten Komponenten tauschen sich auch untereinander aus. Das führt dazu, dass Hacker unabhängig davon, wo der Erstzugriff erfolgt ist, überall hingelangen – entlang von sogenannten Attack Trees. Auch vom Temperatursensor zur Lenkradsteuerung. In Summe sind die drei Faktoren eine Einladung an alle Cyberkriminellen, ihre Fähigkeiten auszuprobieren.
Inhaltliche Risikoszenarien
Sollte man angesichts dessen das mit der Digitalisierung und Vernetzung der Fahrzeuge wegen der Risiken doch lieber sein lassen? Natürlich nicht, schließlich steht wirklich eine Menge auf der Haben-Seite! Für die Automotive-Unternehmen, für die Fahrer und für alle Menschen, die irgendwie am Verkehr teilnehmen. Stattdessen sollten Hersteller und Zulieferer die neuen Bedrohungsszenarien als Herausforderung verstehen, der sie sich jetzt konsequent widmen müssen. Sie müssen ein digitales Sicherheitskonzept entwickeln und umsetzen – auch, wenn das ursprünglich nicht zu ihrer Kernkompetenz gehört.
Um auf Risiken reagieren zu können, müssen diese zunächst einmal bekannt sein. Das kontinuierliche Monitoring der Entwicklungen gehört deshalb unbedingt zu einem digitalen Sicherheitskonzept. Eine gute erste Orientierung liefert beispielsweise der jährlich erscheinende Global Automotive Cybersecurity Report [2] des Cyber-Security-Unternehmens Upstream. In aktuellen Bericht werden für die nähere Zukunft vor allem drei Bedrohungsszenarien skizziert.
Functions on Demand
Zahlreiche OEMs bietet heute die Option an, via Abo-Modell zusätzliche Funktionalitäten freizuschalten – etwa Sitzheizung, Fernlichtassistenten oder Apple CarPlay. Das Stichwort dazu: Function on Demand. Für die Hersteller bietet das Angebot eine Reihe von Vorteilen. Sie verdienen mit einem Fahrzeug nicht nur einmal beim Verkauf, sondern haben dauerhafte Einnahmen. Außerdem können sie mehr oder weniger sämtliche Fahrzeuge eines Modells mit den gleichen mechanischen und elektronischen Komponenten ausstatten, was zu einem deutlich effizienteren Produktionsprozess führt. Es gibt allerdings auch einen erheblichen Nachteil: Die verbauten Komponenten müssen nur noch im Over-the-air-Verfahren (OTA) über die Software freigeschaltet werden. Für Hacker ist das ein großartiger Ansatzpunkt für Attacken.
Hinzu kommt, dass ein nicht autorisierter Zugriff auch im Auftrag des Besitzers erfolgen kann. Um die Function-on-Demand-Kosten zu umgehen, lassen sie die Software einfach "jailbreaken". Durch solche Manipulationen ergeben sich schnell zusätzliche Angriffsvektoren. Da die Hersteller diese zunächst nicht bekannt sind, können sie auch keine Gegenmaßnahmen entwickeln. Für Cyberkriminelle mit weniger Business-orientierten Absichten ist das ein Traum. Gerade erst ist es einer Gruppe von Forschern gelungen, das Infotainment-System von Tesla zu hacken und eigentlich kostenpflichtige Upgrades umsonst zu bekommen. Zudem konnten sie Daten der Nutzer abgreifen.
Digitales Flottenmanagement
Viele Logistikunternehmen modernisieren derzeit ihre Flotten und ersetzen aussortierte Vehikel durch vernetzte Elektroautos. Damit kommen zum einen rechtlichen Vorgaben der Europäische Union nach (Stichwort: Green Deal). Zum anderen optimieren sie durch die Vernetzung die Auslastung ihrer gesamten Flotte – etwa durch eine flexiblere Routenplanung. Der Austausch zwischen den Fahrzeugen und dem System für das digitale Flottenmanagement macht allerdings auch Hackern den Zugriff vergleichsweise leicht – und zwar nicht nur auf ein einzelnes Vehikel, sondern auf die gesamte Flotte. Damit sind nicht nur in der Lage, bestimmte Fahrer zu gefährden. Sie haben auch die Möglichkeit, gesamte Flotten stillstehen zu lassen und damit Lieferketten erheblich zu stören. Angesichts der massiven Folgen, die Lieferschwierigkeiten mit sich bringen, gewinnen Cyberkriminelle dadurch ein erhebliches Erpressungspotenzial.
Ladeinfrastruktur
Neben einzelnen Fahrzeugen oder ganzen Flotten wird die Ladeinfrastruktur für Elektroautos zum immer beliebteren Ziel. Dabei nutzen Hacker oft das Open Charge Point Protocol (OCPP), das die Kommunikation zwischen einem Ladepunkt und dem Backend-System des Charge Point Operators (CPO) beziehungsweise des Mobility Service Providers (MSP) organisiert, und führen darüber Denial-of-Service- (DoS) und Distributed-Denial-of-Service-Angriffe (DDoS) aus. Auf diese Weise können Cyberkriminelle nicht nur essenzielle Bestandteile der Verkehrsinfrastruktur lahmlegen, sondern gegebenenfalls auch sensible Daten der Fahrer abgreifen. Derzeit ist die Zahl solcher Übergriffe noch überschaubar. Angesichts der voranschreitenden Elektrifizierung und dem damit einhergehenden Ausbau der Infrastruktur spricht aber viel dafür, dass sich das auf absehbare Zeit ändert.
Regulierte Sicherheit
Die Gesetzgeber weltweit haben längst die Risiken erkannt, die von Software Defined Vehicles ausgehen, und haben deshalb entsprechende regulatorische Vorgaben auf den Weg gebracht. Das gilt auch für die Staaten der Europäischen Union. Die EU bezieht sich dabei hauptsächlich auf zwei Richtlinien der United Nations Economic Commission for Europe (UNECE), die von der Working Party on Automated/Autonomous and Connected Vehicles (WP.29) erarbeitet wurden:
• UN-Regulation No. 155 – Cyber security [3]
• UN-Regulation No. 156 – Software update [4]
Die UNECE R 155 verpflichtet Automobilhersteller dazu, ein Cyber-Security-Management-System (CSMS) in ihren Fahrzeugentwicklungsprozess zu integrieren und dieses über den gesamten Lebenszyklus eines Fahrzeugmodells aktuell zu halten – prinzipiell bis zum End of Life des letzten einzelnen Fahrzeugs des Modells. Die UNECE R 156 verlangt von den OEMs, ein Software-Update-Management-System (SUMS) zu etablieren. Damit unterscheiden sich die beiden Vorgaben deutlich von anderen Anforderungen, die für eine Typzulassung neuer Fahrzeugmodelle erfüllt sein müssen. Die UNECE R 155 und die UNECE R 156 zielen nicht auf spezifische Produktmerkmale für eine Betriebsgenehmigung beziehungsweise die Straßenzulassung ab, sondern auf die Prozesse bei den Automobilherstellern.
Wettlauf zwischen Cyberkriminellen und OEMs
Tatsächlich lässt sich der Umweg über die Prozesse kaum vermeiden, weil der Sicherheitsstatus zum Zulassungszeitpunkt nur wenig darüber aussagt, wie das Fahrzeug in Zukunft geschützt sein wird. Denn wie bei anderen Software-basierten Produkten findet auch bei SDVs ein Wettlauf zwischen Hackern auf der einen Seite und Sicherheitsexperten auf der anderen Seite statt. Bessere Sicherheitskonzepte fordern Cyberkriminellen häufig regelrecht heraus, auf die von ihnen neu entwickelten Attacken müssen dann die OEMS wieder reagieren. Und so weiter.
Dass die Vorgaben der UNECE auf die Prozesse abzielen, ist also nachvollziehbar. Beide Richtlinien sind aber sehr generisch formuliert und lassen bei der Auditierung einen großen Raum für Interpretationen. Dass es auch konkreter geht, zeigen drei Normen der International Standard Organisation. Die ISO/SAE[ ]21434 [5] beschreibt ein System für das Engineering von Cybersicherheit, die ISO/PAS[ ]5112 [6] macht Vorgaben für dessen Auditierung und für die Umsetzung eines Software-Update-Management-System wird durch die ISO[ ]24089 [7] geregelt. Für die meisten OEMs sind diese strikteren Regeln vorteilhaft, weil sie den Einstieg in die Cyber Security erleichtern. Aus den Vorgaben lassen sich so – grob skizziert – drei Pflichten ableiten.
Die Pflicht zum Risikomanagement
Die Hersteller müssen ein Riskmanagement etablieren, das Maßnahmen zur Risikoerkennung, -bewertung und -minderung bezüglich aller denkbaren Cybergefahren umfasst. Das erstreckt sich über den gesamten Produktlebenszyklus; die Verantwortung für die Cyber Security endet damit nicht mit der Typzulassung eines Modells, sondern reicht von der Designphase bei der Produktentwicklung bis zum End of Life eines einzelnen Fahrzeugs.
Das Risikomanagement an sich ist schon eine Herkulesaufgabe. Den ein OEM muss dazu jedes einzelne Bauteil kennen und dieses bei jedem einzelnen Fahrzeug in der Stückliste führen. Das gleich gilt für alle Softwarefunktionen, selbst das System on Chip (SoC) muss dokumentiert werden. Damit das gelingt, müssen alle Stakeholder entlang der Lieferkette eine volle Transparenz sicherstellen. Jede Veränderung an einem Bauteil oder an einer Softwarefunktion muss dokumentiert und neu bewertet werden.
Die Pflicht zum Monitoring
Das Risikomanagement geht mit der Pflicht einher, aktiv nach möglichen neuen Bedrohungsszenarien zu suchen und auf diese zeitnah zu reagieren – beispielsweise mit regelmäßigen Softwareupdates, die sich nicht nachteilig auf andere Fahrzeugfunktionalitäten auswirken dürfen, was eine zusätzliche Herausforderung ist. Dabei soll sich die Suche nicht nur auf das Fahrzeug beziehen, sondern auch fahrzeugfremde Sektoren einschließen: Beispielsweise kann der Angriff auf einen eSIM oder einen Bluetooth-Chip bei einem Mobiltelefon auch Auswirkungen auf das Fahrzeug haben, wenn dort die gleiche Hardware verbaut wurde.
Security by Design: Was die Hersteller nun tun müssen
Zum Monitoring sollte auch die IT-Forensik umfassen. Dementsprechend müssen die Sicherheitsexperten mögliche Bedrohungen nicht nur beobachten, sie sollen sie prinzipiell verstehen. Denn nur das schafft die Grundlage dafür, Sicherheitslücken wirklich zu schließen. Dazu gehört im Zweifel auch, erfolgte Cyberangriffe im Labor zu rekonstruieren.
Die Pflicht zur Zertifizierung
Die Hersteller sind verpflichtet, ihr CSMS wird durch ein akkreditiertes Prüfinstitut zertifizieren zu lassen. Ohne dieses Zertifikat ist es dem OEM nicht mehr gestattet Fahrzeuge Typgenehmigen zu lassen. Spätestens alle zwei Jahre müssen die OEMs die Zertifikate erneuern. In Deutschland übernimmt die Zertifizierung beispielsweise der TÜV.
Security by Design: Sicherheit von Anfang an mitdenken
All das führt dazu, dass die Hersteller – und ebenso die Zulieferer – bei der Entwicklung von Fahrzeugen umdenken müssen: weg von einer sequenziellen und hin zu einer vernetzten Arbeitsweise. Ausgangspunkt dafür ist das „Security by Design“-Konzept. IT-Architekturen sollen so konzipiert sein, dass sie alle bereits zum Entwicklungszeitpunkt bekannten Angriffsszenarien berücksichtigen und sich laufend auf Basis des proaktiven Monitorings aktualisieren lassen. Die Sicherheit geht dabei im Zweifel stets vor Wirtschaftlichkeit. Demnach dürfen die Hersteller potenzielle Gefahren nicht nur deshalb ignorieren, weil sie bisher faktisch selten sind, sofern diese zu einer echten Bedrohung werden könnten. Erfüllen OEMs diese Kriterien nicht und wären Cyberangriffe vermeidbar gewesen, haften die schnell für entstandene Schäden. Aktuell bestehen hier allerdings noch diverse Rechtsunsicherheiten.
Zero Trust: Zugriff nur mit Authentifizierung
Um Security by Design zu operationalisieren, können sich die Hersteller unter anderem am Zero-Trust-Prinzip orientieren. Dabei stufen sie jeden Zugriff auf ein Fahrzeug zunächst als unsicher ein. Erst nach einer Authentifizierung wird ein Zugriff freigegeben und durch das System verarbeitet. Es besteht also so etwas wie eine Beweislastumkehr: Jeder Zugriff gilt so lange als riskant, bis seine Ungefährlichkeit nachgewiesen ist. Wichtig sind in diesem Zusammenhang Zwei-Faktoren- und Multi-Faktoren-Authentifizierungsverfahren. Soll ein E-Fahrzeug beispielsweise mit einer Ladesäule verbunden werden, muss der Fahrer diese Verbindung durch ein Passwort und einen zweiten Faktor (die Antwort auf eine Frage, eine TAN usw.) verifizieren. Für viele Szenarien ist das Zero-Trust-Prinzip eine gute Möglichkeit, die Sicherheit zu steigern. Es gibt aber auch Grenzen – nämlich da, wo die physische Sicherheit ein schnelles Handeln erfordert. Bei einem Aufprall etwa sollte der Airbag nicht auf eine Authentifizierung warten. Schon gar nicht auf eine Zwei-oder-Multi-Faktor-Authentifizierung.
DevSecOps: Gemeinsam für Cyber Security
Auch die systematische Weiterentwicklung von IT-Architekturen hinsichtlich ihrer Sicherheit lässt sich operationalisieren. Dazu bietet sich vor allem der DevSecOps-Ansatz an. Hierbei arbeiten die Teams für die Softwareentwicklung, das Monitoring von Cyber-Bedrohungen und die Operation der Software nicht isoliert voneinander, sondern integriert. Auf diese Weise werden die Feedbackschleifen zwischen den unterschiedlichen Beteiligten institutionalisiert und es kann schneller auf neue Situationen reagiert werden.
Schwierigkeiten resultieren dabei teilweise aus sehr unterschiedlichen datenschutzrechtlichen Bestimmungen in verschiedenen Ländern. Um diese zu lösen, werden künftig neue Anonymisierungsverfahren benötigt, mit deren Hilfe Informationen datenschutzkonform von einem Staat in einen anderen – beispielsweise von China in die USA – übermittelt werden können.
Know-how der Tech-Giganten nutzen?
Automobilhersteller stehen grundsätzlich vor der Wahl: Sollen sie ein eigenes Betriebssystem entwickeln oder die Software der Tech-Giganten nutzen. Zum Beispiel Android Automotive, das Alphabet als technologische Plattform für OEMs bereitstellt. Aus Sicherheitsaspekten ist es einerseits sinnvoll, auf solche etablierte Software zu vertrauen. Schließlich arbeiten daran seit Jahren Spezialisten. Anderseits werden solche Plattformen mit einer steigenden Verbreitung zu einem immer attraktiveren Angriffsziel. Was perspektivisch überwiegt, ist im Augenblick seriös nicht zu beantworten.
Gegen den Einsatz fremder Software spricht noch ein Grund: Hersteller machen sich im hohen Maß von OS-Lieferanten abhängig. Wenn zum Beispiel der Anbieter des verbauten Betriebssystems seine Security Patches nach fünf Jahren einstellt, weil diese unwirtschaftlich werden, dann ist der OEM ordentlich in Bedrängnis. Soll er eigene Security Patches für das OS entwickeln? Kann und darf er das überhaupt? Oder muss ein gesamtes Upgrade umgesetzt werden, mit der Gefahr, dass diese nicht zur schon mehrere Jahre alten Fahrzeughardware passt.
Zeit zu handeln!
Im Bereich Cyber Security ist vieles gerade noch im Werden. Das macht es für Hersteller, die ohnehin ein für sie ziemlich neues Spielfeld betreten, nicht einfacher. Fest steht lediglich: Es ist Zeit zu handeln. Und zwar jetzt! Das passiert aber nur bedingt, wie das Global Automotive Cyber Security Management Survey 2022 der Wirtschaftsprüfungsgesellschaft PwC nahelegt. Zwar erwarten alle der befragten Vertreter aus verschiedenen Bereichen der Automobilindustrie, dass Cyberattacken auf Fahrzeuge drastisch zunehmen werden. Ebenfalls 100 Prozent gaben an, bereits ein CSMS implementiert zu haben. Bei den OEMs lag der Fertigstellungsgrad aber im Durchschnitt lediglich bei 71 Prozent, bei den Zulieferern sogar nur bei 59 Prozent. Beide Stakeholder-Gruppen werden ihr Engagement also noch steigern müssen, um zügig eine möglichst hohe Sicherheit der Software Defined Vehicles zu erreichen.
(mfz [8])
URL dieses Artikels:
https://www.heise.de/-9318721
Links in diesem Artikel:
[1] https://www.tesla.com/de_de/legal/security
[2] https://upstream.auto/reports/global-automotive-cybersecurity-report/
[3] https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security
[4] https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update
[5] https://www.iso.org/standard/70918.html
[6] https://www.iso.org/standard/80840.html
[7] https://www.iso.org/standard/77796.html
[8] mailto:mfz@heise.de
Copyright © 2023 Heise Medien