Cybersicherheit in der Entwicklung von Fahrzeugkomponenten und -systemen ist zunehmend eine Frage der Effizienz. Es gilt, die von der ISO/SAE 21434 geforderte Bedrohungsanalyse und Risikobewertung (Threat Analysis and Risk Assessments, kurz TARA), die heute als zentraler Bestandteil der Entwicklung moderner Fahrzeuge gilt, einerseits korrekt und sinnvoll, andererseits effizient und ressourcenschonend durchzuführen. Die TARA-Methodik selbst ist ein ausgeklügeltes Prinzip der risikobasierten Untersuchung von Cybersicherheitseinflussfaktoren und legt den Grundstein für die Abwehr potenzieller Bedrohungen. Sie bietet einen strukturierten Ansatz zur Identifizierung, Bewertung und Priorisierung von Cybersicherheitsrisiken in Fahrzeugsystemen. Nachfolgend sollen jedoch die Fallstricke aufgezeigt werden, die häufig mit dieser Methode einhergehen.
Jan-Peter von Hunnius
In einer Zeit, in der Konnektivität im Fahrzeug zum Standard wird sind und kritische Fahrzeugfunktionen auf komplexen Softwaresystemen basieren, können Schwachstellen in der Implementierung von Schutzmechanismen weitreichende Folgen haben – nicht nur für einzelne Fahrzeuge, sondern für ganze Flotten.
Entsprechend fordert die UN Regulierung Nr 155 von OEMs und Zulieferern eine durchgängige Bewertung dieser Risiken. Die damit verbundene TARA-Methodik, genau definiert in der ISO/SAE 21434, rückt in den Mittelpunkt der Cybersicherheitsstrategien.
Wichtig: TARAs sind nicht nur als einmalig aufgesetzte technische Dokumentationen zu verstehen. Vielmehr dienen sie als “evolutionäre Entwicklungsskizzen”, die Ingenieurteams dabei unterstützen, fundierte Sicherheitsentscheidungen während des gesamten Fahrzeuglebenszyklus zu treffen – von der ersten Idee über den operativen Betrieb bis hin zur Außerbetriebnahme.
Trotz des Aufkommens spezialisierter Tools und Lösungen zur Erarbeitung der TARA bleiben einige systematische Herausforderungen im Vorgehen mit der Methodik bestehen. Sie deuten darauf hin, dass sich in der Branche noch nicht die eine Lösung durchgesetzt hat, die der wachsenden Komplexität moderner Automobilsysteme in vollem Umfang gerecht wird.
Um dies zu verdeutlichen, werden im Folgenden drei wesentliche Herausforderungen skizziert, die der Branche weiterhin Kopfzerbrechen bereiten: die automatische Aggregation von Angriffspfaden, die übermäßige Abhängigkeit von bedrohungszentrierten Risikomatrizen und der Mangel an Kollaborationsmöglichkeiten für die TARA-Zusammenarbeit zwischen OEMs und Zulieferern.
Automatisierte Aggregierung als Ausgangspunkt für folgenschwere Ungenauigkeiten?
Innerhalb der TARA-Methodik spielen Angriffspfade und Angriffsbäume eine zentrale Rolle, um die Nachvollziehbarkeit und das Verständnis potenzieller Cybersicherheitsrisiken durch Visualisierung zu fördern.
Was sind Angriffsbäume innerhalb der TARA-Methodik?
Angriffsbäume sollen durch eine strukturierte, hierarchische Darstellung systematisierte Information zusammenstellen und visualisieren, wie ein Angreifer bestimmte Ziele erreichen könnte, z.B. unbefugten Zugriff auf ein System zu erlangen oder Fahrzeugfunktionen zu beeinträchtigen. In diesen Bäumen stellt jeder Zweig einen möglichen Angriffspfad dar, der komplexe Angriffe in einzelne Schritte zerlegt, die von einem Angreifenden genutzt werden könnten. Diese Visualisierung ist innerhalb der TARA von entscheidender Bedeutung, da sie es Ingenieuren ermöglicht, jeden möglichen Weg, den ein Angreifer einschlagen könnte, zu identifizieren und zu bewerten. Ziel ist es, ein klares Bild der potenziellen Schwachstellen vom ersten initialen Zugang bis zum endgültigen Angriffsziel zu erhalten.
AND/OR: Die Sache mit dem UND und dem ODER bei einem möglichen Angriff
Viele spezialisierte TARA-Lösungen realisieren das Beschriebene mit Hilfe von Angriffsbäumen, bei denen ganze Angriffspfade als Knoten dargestellt werden, die durch UND/ODER-Gatter verbunden sind. Sie veranschaulichen, unter welchen Bedingungen ein Angriff erfolgreich sein könnte. Diese UND/ODER-Gatter dienen als logische Verbindungen und sollen die Anforderungen für jeden einzelnen Schritt im Angriffspfad darstellen:
- UND-Gatter zeigen an, dass alle Bedingungen erfüllt sein müssen.
- ODER-Gatter zeigen an, dass eine beliebige der gegebenen Bedingungen ausreicht.
Mit dieser Methodik kann die genutzte TARA-Lösung verschiedene Angriffsszenarien modellieren und deren Wahrscheinlichkeit und Auswirkungen bewerten.
Durch die Systematisierung der Bewertung der einzelnen Zweige des Baums versuchen die TARA-Lösungen, die beteiligten Teams bei der Berechnung von Risikobewertungen und der Priorisierung von Maßnahmen zur Risikominderung zu unterstützen.
Dadurch soll sichergestellt werden, dass die (stets begrenzten) Ressourcen auf die kritischsten Bedrohungen ausgerichtet werden. Dies ist eines der zentralen Ziele bei der effektiven Implementierung von Cybersicherheit in der Fahrzeugentwicklung.
Exkurs: Wie bewertet die ISO/SAE 21434 die Durchführbarkeit von Cyberangriffen?
Die ISO/SAE 21434 etabliert ein Punktesystem zur Bewertung der Durchführbarkeit von Angriffen, das sogenannte “attack feasibility rating”. Dabei definiert der Standard (Vgl. Clause 15) fünf Parameter, denen eine Punktzahl zugeordnet wird. Diese Parameter sind:
- Dauer des Angriffs (einschließlich Recherche usw.),
- erforderliches Fachwissen zur Durchführung,
- Verfügbarkeit relevanter Informationen über das System,
- das gegebene Zeitfenster (“window of opportunity”), in dem eine Möglichkeit zur Durchführung eines Angriffs zeitlich gegeben ist (dies ist z.B. besonders relevant, wenn physischer Zugang zum angegriffenen System erforderlich ist)
- und die Gebräuchlichkeit der für den Angriff erforderlichen Ausrüstung.
In der TARA-Systematik werden die Bewertungen dieser genannten Parameter pro Angriffspfad über alle seine Schritte aggregiert (z.B. indem immer der höchste Wert gewählt wird) und anschließend zu einem Rating für die generelle Durchführbarkeit eines Angriffs aufsummiert.
Eine hohe Bewertung steht für einen nicht durchführbaren Angriff, während eine niedrige Bewertung einen einfachen Angriff beschreibt.
Was ist automatisierte Aggregierung von Angriffspfaden in der TARA und warum können sie ein Problem darstellen?
Obwohl dieses Verfahren zur Bewertung und die entsprechende Handhabe von Angriffsbäumen eine der zentralen Grundlagen der TARA darstellt, kann es dabei dennoch zu Einschränkungen und Ungenauigkeiten kommen.
Diese ergeben sich aus der automatisierten Aggregierung der Bewertungen der einzelnen Parameter eines Angriffspfades.
Die meisten TARA-Lösungen aggregieren automatisch verschiedene Elemente, wie z. B. die Angriffsdauer, um mit Hilfe der Aggregierung eine abschließende Risikobewertung erstellen zu können. Das Risiko dabei: Dieser automatisierte Prozess kann jedoch in realen Szenarien zu (folgenschweren) Ungenauigkeiten führen.
Ein Beispiel hierfür ist die Einschätzung des für einen erfolgreichen Angriff erforderlichen Fachwissens, das insgesamt ein nicht zu unterschätzendes Element bei der Beurteilung der tatsächlichen Durchführbarkeit eines erfolgreichen Angriffs darstellt.
Betrachten wir dazu ein fiktives, vereinfachtes Beispiel, bei dem eine bösartige Softwaremodifikation vorgenommen wird (siehe Diagramm unten).
Hier gibt es verschiedene Möglichkeiten, die zu einem erfolgreichen Angriff führen können. Jede dieser Möglichkeiten wird anhand der diskutierten Parameter bewertet.
Die “Specialist Expertise” und die tatsächliche Angriffswahrscheinlichkeit
Wenn es nun um die Expertise geht, die für die einzelnen Schritte benötigt wird, ist es wichtig zu wissen, dass nach der Bewertungsskala der ISO/SAE 21434 die höchste Stufe “multiple experts” dadurch definiert ist, dass mehrere hochqualifizierte Spezialisten aus unterschiedlichen Bereichen benötigt werden.
Wer den Inhalt des Angriffsbaums versteht, erkennt, dass es sich hier wohl um unterschiedliche Domänen handelt, so dass sich eigentlich der Wert für den Parameter Expertise eigentlich erhöhen müsste (das wäre dann “Multiple experts” mit 8 Punkten). Dies ist aber nicht der Fall, da gängige TARA-Tools und -Lösungen hier nur die gegebene Bewertung für das Expertise-Level (hier “Expert” mit 6 Punkten) durchreichen. Die Folge: Der Expertise-Wert für diesen Angriff wird zu niedrig angegeben, die Wahrscheinlichkeit in der Praxis wird überschätzt.
Als Folge dieser fehlerhaften Risikobewertung kann es in der Praxis tatsächlich passieren, dass unnötige Sicherheitsmechanismen implementiert werden, um ein falsch bewertetes Risiko zu mindern. Verschwendete Ressource.
Das Equipment und die tatsächliche Angriffswahrscheinlichkeit
Diese Problematik der möglichen falschen Aggregation besteht auch beim Parameter der für einen Angriff erfolgreichen Ausrüstung. Auch hier gibt es für die Ausrüstung den Wert “bespoke” (im Deutschen: maßgeschneidert / individuell zugeschnitten) (mit 7 Punkten) oder “multiple bespoke” (mit 9 Punkten).
Auch hier kann die Frage, inwieweit ein aggregierter Gesamtwert von 7 oder 9 Punkten nun korrekt ist, erst nach einer genaueren inhaltlichen Betrachtung der jeweils erforderlichen Ausstattung beurteilt werden.
Die Angriffsdauer und die tatsächliche Angriffswahrscheinlichkeit
Am deutlichsten wird diese Problematik jedoch bei der Betrachtung der für einen Angriff benötigten Zeit, der Angriffsdauer.
Nach der Bewertungsskala der ISO/SAE 21434 kann im obigen Beispiel eine Situation mit zweimal “≤ 1 Monat” zusammengenommen alle möglichen Werte zwischen 16 und 60 Tagen annehmen.
(Hierfür relevant zu wissen: Der Standard definiert keine Schritte zwischen dem Wert “≤ 1 Monat” (4 Punkte) und “≤ 6 Monate” (17 Punkte); 17 Punkte ändern die Angriffswahrscheinlichkeit aber bereits von „high“ auf „medium“.)
Diese Unschärfe spiegelt sich in den entsprechenden Werten wider: Ein Zeitraum von 16 Tagen würde dem Wert “≤ 1 month” zugeordnet und mit 4 Punkten bewertet werden – ein Zeitraum von 60 Tagen würde wiederum den Wert “≤ 6 months” zugeordnet und mit 17 Punkten bewertet werden.
Diese Punktdifferenz von 13 Punkten wird zwangsläufig zu gravierenden Unterschieden in der Gesamtrisikobewertung führen und auch hier im Zweifelsfall eine zu hohe Wahrscheinlichkeit und unnötige Sicherheitsmechanismen zur Folge haben.
Hier das gleiche Beispiel als Angriffspfad (“attack path”) mit einer optimistischeren (oder aus Sicht des Angreifers pessimistischeren) manuellen Aggregation. Die gesamten Angriffspfade dauern nun “<6 months“ und einer erfordert „multiple experts“.
Dieser Ansatz findet sich in vielen manuell entwickelten TARAs (z. B. unter Verwendung von Excel-Tabellen).
Die Bewertung der Durchführbarkeit der beiden möglichen Angriffe ist nun genauer – und aufgrund der höheren Punktzahlen vor allem deutlich niedriger (21 vs. 36/38) – als im vorherigen Diagramm.
Aufgrund der genaueren Bewertung kann in der nachgelagerten Entwicklung mit hoher Wahrscheinlichkeit Aufwand für unnötige Sicherheitsmechanismen eingespart werden, da diese Angriffe in der Praxis ohnehin als unrealistisch bzw. vernachlässigbar durchführbar einzustufen sind.
Das Problem mit bedrohungsorientierten Risikomatrizen
Bei der Betrachtung des Gesamtsicherheitsrisikos eines Angriffs oder einer Bedrohung ist der Schaden, den sie anrichten können, eine Dimension der abschließenden Risikobewertung, die andere ist die Durchführbarkeit einer realisierten Bedrohung oder eines durchgeführten Angriffs. Im ersten Diagramm ist ein Blatt des Baumes eine Bedrohung – eine böswillige SW-Modifikation. Sie ist eher abstrakt.
Viele TARA-Tools verwenden Bedrohungen anstelle von Angriffspfaden, um die endgültige Risikobewertung zu erstellen, was wahrscheinlich auf die oben beschriebene Aggregationsstrategie zurückzuführen ist. Dieser Ansatz schränkt jedoch die Granularität der TARA-Ergebnisse ein und führt zu eher abstrakten Empfehlungen (den sogenannten “Cybersecurity Goals”), die zu allgemein sind als das sie während der Entwicklung konkret umsetzbar sind.
Ein bedrohungsorientierter Ansatz könnte, wenn das Risiko zu hoch ist, um akzeptiert zu werden, zu einem Cybersecurity Goal wie „Verhinderung böswilliger Software-Modifikationen“ führen.
Ein solches Ziel gibt jedoch keine Details darüber, wie diese Bedrohung in der Praxis tatsächlich auftreten kann oder wie ein Angriff durchgeführt wird.
Benutzt der Angreifer eine Debug-Schnittstelle? Manipulieren sie den Speicher direkt?
Ohne diese Informationen ist es für Entwicklungsteams schwierig, spezifische, und wirksame Cybersicherheitsmaßnahmen zu implementieren, z. B. den Schutz von Debug-Ports und mikrocontrollerinternen Flash-Speichern.
Die Informationen über das Spezifische sind bereits in der TARA enthalten – allerdings in den Angriffspfaden. Die Ableitung von Risikobewertungen und daraus resultierenden Cybersecurity Goals und Cybersecurity Claims aus den Bewertungen der Angriffspfade und nicht aus den Bedrohungen führt eher zu einem detaillierten Cybersecurity Goal wie “Verhinderung von böswilligen Änderungen an der Software über eine entsperrte JTAG-Debug-Schnittstelle” oder “Verhinderung von böswilligen Änderungen an der Software über direkten Zugriff auf den Flash-Speicher”. Damit wird eine klare Richtung vorgegeben, wie ein Risiko reduziert werden kann.
Einfach deshalb, weil die Cybersecurity Goals hier aus einem konkreten Angriffspfad und nicht aus einer abstrakten Bedrohung abgeleitet werden.
Fehlende (Tools und) Zusammenarbeit zwischen OEMs und Zulieferern
Das dritte und vielleicht dringendste Problem im Zusammenhang mit der effizienten Anwendung der TARA-Methodik ist das Fehlen von Tools für die Zusammenarbeit. Dies betrifft nicht nur das strukturelle Problem in vielen Organisationen, dass TARAs oft manuell ausgewertet und übertragen werden müssen (was mit einem immens kostenintensiven Ressourcenverbrauch einhergeht), sondern auch der Austausch von Informationen, Arbeitsständen oder vollständigen TARAs zwischen OEMs und Zulieferern scheint ein Ding der Unmöglichkeit zu sein.
Da Fahrzeuge und ihre Komponenten immer komplexer und vernetzter werden, kann die alleinige Verantwortung für Cybersicherheit nicht mehr nur bei einer Partei liegen.
In der Praxis müssen OEMs mit ihren Zulieferern effektiv zusammenarbeiten, um umfassende TARAs zu entwickeln, die die gesamte Risiko- und Bedrohungslandschaft gesamtheitlich entlang der Lieferkette abdecken.
Leider verfügen die heutigen TARA-Tools und-Lösungen nicht über die dafür notwendigen Schnittstellen, um diese so wichtige Zusammenarbeit verlustfrei und sauber abzubilden.
OEMs und Zulieferer arbeiten – auch aus diesem Grund – häufig in Silos.
Tatsächlich gibt es bis heute keine standardisierte Möglichkeit, relevante Teile einer TARA mit Entwicklungspartnern zu teilen. Dies führt häufig zu Ineffizienzen und Lücken im Risikobewertungsprozess, da verschiedene Organisationen Schwierigkeiten haben, ihre Bewertungen und Sicherheitsmaßnahmen abzustimmen .
Im Gegensatz zu Tools für das Application Lifecycle Management (ALM) gibt es kein weit verbreitetes Standardaustauschformat, das den Informationsaustausch erleichtert.
Ohne ein solches aufeinander abgestimmtes Austauschsystem, das den Austausch von Bewertungen aus unterschiedlichen Perspektiven ermöglicht, wird es schwierig, ein Gesamtbild zu erhalten und sicherzustellen, dass alle potenziellen Angriffsvektoren abgedeckt sind.
Bezogen auf den eigentlichen Zweck der TARA kann diese Diskrepanz dazu führen, dass Schwachstellen und Risiken übersehen werden oder redundante Cybersicherheitsbemühungen unternommen werden, was beides nicht zu effizienten Cybersicherheitsimplementierungen führt.
Lösungen in der Kollaboration rund um die TARA
Anstatt hier nur Schnittstellen für den reinen Informationsaustausch zu definieren, die leicht aus dem Gleichgewicht geraten können, bietet sich auch ein anderes Modell der Zusammenarbeit an: Bei der Entwicklung einer TARA mit dem gleichen Datenmodell zu arbeiten.
In der siloartigen Arbeitsweise der Automobilbranche klingt dieser Vorschlag fast provokativ: Gehostet beim OEM könnte eine TARA für ein neues Fahrzeug(-system) von allen beteiligten Parteien gemeinsam entwickelt werden, wobei der Zugriff für alle Beteiligten kontrolliert wird. Damit würden der Datenaustausch und mögliche Inkonsistenzen zwischen den TARAs der Zulieferer und des OEM entfallen. Jeder kann die für ihn relevanten Teile sehen und bearbeiten, und das Ergebnis ist eine umfassende und in sich konsistente TARA – für das gesamte Fahrzeug.
Beispielsweise könnte dann eine festgestellte Beeinträchtigung eines Steuergerätes (z. B. ein Denial of Service durch böswillig veränderte Software) zu einem Angriffsschritt auf das Fahrzeug mit weitaus größerem Schaden führen (z.B. durch Spoofing-Nachrichten, die das angegriffene Steuergerät senden kann, um andere Systeme im Fahrzeug zu beeinflussen).
Werden diese Abhängigkeiten gemeinsam in ein und derselben TARA modelliert, wie in der folgenden Abbildung dargestellt, führen Änderungen in der Angreifbarkeit eines Steuergeräts automatisch und konsistent zu kohärenten Änderungen im gesamten Fahrzeug. Umgekehrt können Anpassungen, die das Gesamtfahrzeug betreffen, dann ebenfalls konsistent und automatisiert auf die einzelnen ECU-Lieferanten und deren Risikobewertungen und Punkteverteilungen heruntergebrochen werden.
Die TARA als geistiges Eigentum?
Klar ist, dass für diesen Ansatz Bedenken hinsichtlich des geistigen Eigentums überwunden werden müssen. Hier gilt es aber – gerade angesichts der Herausforderungen, vor denen die globale Automobilindustrie derzeit steht – die richtigen Entscheidungen in Bezug auf Zusammenarbeit und Effizienz zu treffen. Gleichzeitig sind, wie bei so vielen Business-Anwendungen Lösungen, Tool- und Lösungsanbieter in der Pflicht, durch intelligente Funktionen im Berechtigungsmanagement die Vergabe von Zugriffsrechten so zu steuern, dass das geistige Eigentum aller Beteiligten geschützt werden kann.
Es ist nicht nur eine technische, sondern auch eine kulturelle Frage, Kollaboration als Treiber für die Wettbewerbsfähigkeit der Zukunft zu begreifen.
Zusammenfassung und Ausblick
Was reißerisch klingt, ist die gegenwärtige Realität: Die Automobilindustrie steht in Sachen Cybersicherheit an einem Scheideweg. Zwar sind immer mehr Tools und Lösungen zur Umsetzung der TARA auf dem Markt, aber deren Grenzen und Nachteile – automatische Aggregation, bedrohungsorientierte Risikomatrizen und unzureichende Funktionsweisen der Zusammenarbeit – führen zu teilweise weitreichenden Problematiken, die die Effektivität und Effizienz von Risikobewertungen behindern.
Es erscheint daher nicht verwunderlich, dass in einer überraschend hohen Anzahl von Projekten in der Praxis immer noch Excel-Lösungsansätze für die TARA zu beobachten sind. Die beteiligten Sicherheitsingenieure bevorzugen die Microsoft-Lösung aus einem einfachen Grund: Dedizierte (und oft teure) TARA-Softwarelösungen bieten zu wenig Mehrwert, um ihre Kosten zu rechtfertigen.
Eines ist jedoch sicher: Cybersicherheit in der Fahrzeugentwicklung und die Werkzeuge und Lösungen, mit denen hier effizient gearbeitet wird, entwickeln sich weiter.
