Cybersecurity als Herausforderung im Produktlebenszyklus von Autos

Risiken sind allgegenwärtig. Für Fahrzeuge gilt dies insbesondere durch die Vernetzung im Cyberraum. Aktuelle Risikobewertungen bilden daher den Kern jedes Cybersecurity-Managements. Hierfür gibt es unterschiedliche Philosophien. Mit der TARA hat sich die Autoindustrie für eine Kombination aus Bedrohungsanalyse und Risikobewertung entschieden.

In der Fahrzeugentwicklung versteht man unter Cybersecurity, das Fahrzeug vor mutwilligen Angriffen zu schützen. Schäden können dabei in vier Kategorien (SFOP) entstehen: Störung der Funktionssicherheit (Safety / Functional Safety), Vermögensschäden (Finance), Unterbrechung der Betriebsfähigkeit (Operations / Operational Safety) oder Datenverlust (Privacy).

Cybersecurity hat ein Verfallsdatum

Ein Fahrzeug, das heute sicher ist, muss es morgen nicht mehr sein. Wenn sich das technische Umfeld verändert, bilden sich mögliche Einfallstore. Selbst Kryptographie kann gebrochen werden, sobald Hacker die entsprechenden Wege finden, diese zu umgehen. Darum ist Cybersecurity keine dauerhafte Eigenschaft, die einem Fahrzeug in der Produktion ein für alle Mal mitgegeben werden kann. Stattdessen muss das Auto als hochgradig zu schützendes Gerät gedacht werden, bei dem die Security ständig gehärtet werden muss.

Im Umkehrschluss bedeutet dies, dass Cybersecurity eine ganzheitliche Aufgabe darstellt, die auch auf Unternehmensebene angegangen werden muss: Durch verbindliche Prozesse muss die Organisation sicherstellen, dass die Risikolage für das Fahrzeug und seine Komponenten ebenso proaktiv wie regelmäßig überprüft wird. Weil Cybersecurity ein bewegliches Ziel darstellt, bilden regelmäßige Risikobewertungen gewissermaßen wie Grundlagenforschung die Basis, auf der alle anderen Cybersecurity-Entscheidungen und -Aktivitäten aufbauen.

Mit der Sicherheit ist es jedoch so eine Sache, denn bei technischen Systemen kann man nur das steuern, was man messen kann. Und Tests können Edsgar W. Dijkstra, niederländischer Informatiker und Wegbereiter der strukturierten Programmierung, zufolge lediglich zeigen, dass ein Fehler vorliegt. Schwierig, wenn man nicht mal einen Test-Case spezifizieren kann – schließlich weiß man nicht, wo die Sicherheitslücke liegen könnte. Wie kann ein Unternehmen also bewerten, wie groß ein Risiko sein wird, das es nicht kennt?

Da sich der Angreifer nicht statistisch modellieren lässt, braucht es andere Konzepte. Ein gängiger Ansatz beispielsweise baut auf dem Wissen auf, dass Angreifer überwiegend über die Fahrzeugarchitektur ins Innere gelangen. Ein ganzheitliches Vorgehen denkt das Fahrzeug als System mit Komponenten, Schnittstellen und Kommunikationskanälen. Mit einem Architekturmodell besteht dann die Möglichkeit, kritische Zonen zu bestimmen und abzusondern. Andere Ansätze gehen wiederum von der gedachten Person des Angreifers aus und überlegen, was diesen zu einem Hack motivieren könnte.

Nine2Five ─ die Erfolgsformel

Die Autobranche hat sich allerdings für ein eigenes Vorgehen entschieden, um Bedrohungen zu erkennen und Risiken systematisch bewerten zu können: die sogenannte TARA. TARA ist ein Konzept zur Risikobewertung, wobei die Abkürzung für Threat Analysis and Risk Assessment steht. Die Elemente der TARA werden im neuen Cybersecurity-Standard ISO/SAE 21434 beschrieben. Statt vom Angreifer oder dem Gesamtsystem auszugehen, richten die Autoren des Security-Standards ihr Augenmerk auf die schützenswerten Güter innerhalb der Elektronikarchitektur, die sogenannten Assets.

Um die erforderlichen Elemente kombinieren und Ziele fürs Cybersecurity-Konzept ableiten zu können, haben Experten den Nine2Five TARA-Navigator entwickelt. Dieser ist als strukturierte Tabelle mit einer horizontalen Referenzstruktur aufgebaut. Der Navigator empfiehlt auch jeweils passende Methoden, mit denen sich die Ziele erreichen lassen.

In der Konzeptphase eines Systems erfolgt eine umfassende Bedrohungsanalyse; deren Ergebnisse können die Fahrzeugarchitektur wesentlich beeinflussen. Zur Vorarbeit wird wie bei der Funktionssicherheit das Item, etwa eine Funktion, mitsamt Schnittstellen gedanklich von der System- und Betriebsumgebung abgegrenzt. Dann wird geprüft, welche schützenswerten Güter es gibt (S1 in Bild 1), beispielsweise ein Kommunikationskanal ins Internet. Um den Schutz dieser Assets geht es dann im Folgenden bei der Bedrohungsanalyse sowie künftig bei den regelmäßigen Risikobewertungen. Um die für Cybersecurity relevanten Assets bestimmen zu können, gibt es sogenannte Schutzziele:

• Vertraulichkeit,
• Integrität und
• Verfügbarkeit

Pro Asset ist zu klären, ob dessen Kompromittierung einen Schaden gemäß den SFOP-Schutzzielen anrichten könnte. Ob das in der Praxis möglich ist, wird erst später untersucht. Wird ein Schutzziel verletzt, kann ein Schadensszenario entstehen. Bei Bedrohungsmodellierungen werden über die drei Schutzziele hinaus weitere Attribute betrachtet:

• Nicht-Abstreitbarkeit,
• Authentizität und
• Autorisierung.

Wer diese gleich in die Betrachtung einbezieht, spart sich später Aufwand.

Schützenswerte Güter und Schadwirkung bestimmen

Wie folgenschwer ein solches Schadensszenario sein kann, bemisst sich anhand der Interessen, die ein Stakeholder in Bezug auf eine oder mehrere der Schadenskategorien (SFOP) hat. Entsprechende Bewertungstabellen helfen, die mit einem Angriff verbundene Schadwirkung zu ermitteln, also der Wucht eines möglichen Schadens (S2). Das Beispiel des Kommunikationskanals macht dies deutlich: Eine Verkehrsteilnehmerin ist darauf angewiesen, dass jederzeit die Funktionssicherheit (S) des Fahrzeugs gewährleistet ist. Für die Fahrzeughalter kommen noch Datenschutz (P) und Betriebssicherheit (O) hinzu, also dass die persönlichen Daten sicher sind und sie jederzeit über den Wagen verfügen können. Letzteres kann auch finanzielle Auswirkungen haben (F). Für das Unternehmen schließlich stehen diese im Vordergrund (F). Hier dreht sich alles um Haftung und Reputation. Auch die Höhe des Schadens ist aus Sicht der Betroffenen verschieden hoch. Der unauffällige Kommunikationskanal ist also für drei unterschiedliche Stakeholder aus jeweils eigenen Gründen wertvoll. Mit der Bestimmung der Schadwirkung ist die Bedrohungsanalyse abgeschlossen.

Allmählich lässt sich auch erkennen, wie eine TARA aufgebaut wird: Sie bildet eine logische Kette. Die Schritte bauen aufeinander auf. Pro Schritt gibt es eine einzige Fragestellung. So werden systematisch Bedrohungskandidaten ermittelt und gleichzeitig sichergestellt, dass die Entwickler und Ingenieure tatsächlich alle denkbaren Hypothesen prüfen ─ Stichwort: Voreingenommenheit. Die nächsten Schritte gehören zur Risikobewertung, also einem Verfahren, das bis zum Service-Ende der Fahrzeugreihe regelmäßig wiederholt werden muss. Nur so lassen sich neue Risiken erkennen und per Update begegnen.

Von der Bedrohung zum Schaden

Weiter im Rennen bleiben diejenigen Schadensszenarien, bei denen mit einem der Cybersecurity-Schutzziele auch Stakeholder-Interessen verletzt werden könnten (S3). Allerdings versteckt sich die Schwachstelle irgendwo im Fahrzeug. Das verschafft den Entwicklern einen Startvorteil: Während sich ein Angreifer bei seinem Angriffspfad wie in einem Labyrinth vorarbeiten muss, geht das Entwicklerteam einfach von der Schatzkammer, dem Asset, durch das System, bis es zu den äußeren Schnittstellen gelangt. An jedem Interaktionspunkt wird geprüft, ob ein Angreifer diesen passieren könnte (S4). Ein Angreifer muss möglicherweise mehrfach um die Ecke denken und erst ein anderes Bauteil kompromittieren, um zum Ziel zu gelangen: Vielleicht sorgt er mittels Fluten des CAN-Bus‘ dafür, dass keine Nachrichten mehr übertragen werden. Mit redundanten Schutzmaßnahmen kann eine Defense-in-depth den Hackern das Eindringen zusätzlich erschweren. Annex 5 zur UNECE (R.155) liefert eine hilfreiche Auflistung von Bedrohungskategorien mit potenziellen Verwundbarkeiten.

Alle diese Schritte waren abstrakt. Untersucht wurde bislang, was möglich ist. Erst jetzt wird die Frage geklärt, wie realistisch die Bedrohung ist. Vielleicht stößt die Angreiferin mitten im System auf eine Barriere, die sie nicht überwinden kann ─ wenn Verschlüsselung den Durchmarsch verhindert, kann sie keinen Schaden anrichten. Für die Machbarkeitsbewertung eines Angriffs (S5) nennt die ISO/SAE 21434 drei Verfahren:

1. Analysen auf Basis des Angriffspotenzials
2. Common Vulnerability Scoring System (CVSS2)
3. Angriffsvektoren

Liegen genügend Informationen über das Item vor, ist das Angriffspotenzial-basierte Vorgehen eine gute Wahl. Zur Bewertung dienen folgende Parameter: Wieviel Zeit benötigt die Angreiferin, welche Expertise und welches Produktwissen sind erforderlich, was braucht sie an Ausrüstungen und Werkzeugen? Hat sie überhaupt eine Gelegenheit zu dem Angriff? Im Konzeptstadium ist auch die Analyse der Angriffsvektoren hilfreich.

Die mögliche Schadwirkung und die Angriffsmachbarkeit ergeben zusammen den Wert des Risikos (S6):

Risikowert = Auswirkung Schadensszenario x Machbarkeit Angriffspfad

Der Risikowert wird aus einer Risikomatrix ermittelt. Er bezieht sich auf die jeweilige Schadenskategorie. Im Gegensatz zur ISO 26262 lässt er sich nicht errechnen, weil Cybersecurity mit Eintrittswahrscheinlichkeiten operiert.

Da unterschiedliche Stakeholder unterschiedliche Interessen haben, müssen die Beteiligten für die Bewertung die entsprechende Schadenskategorie aus dem SFOP-Quartett heranziehen. In einem Diagramm lässt sich das gut darstellen und kommunizieren.

Die Risikobewertung ist nun abgeschlossen. In der Praxis beginnt erst die eigentliche Arbeit: Nicht trivial ist die Entscheidung, wie mit dem Risiko umgegangen werden soll (S7). Hierbei gibt es vier Optionen:

1. Vermeidung,
2. Verringerung,
3. Übertragung auf Dritte – etwa durch den Abschluss einer Versicherung,
4. Akzeptanz.

Kommt nur die Vermeidung in Betracht, muss die Produktarchitektur verändert werden. Dann ist natürlich auch eine neue Bedrohungsanalyse erforderlich.

Cybersecurity wandert als Produktanforderung ins Pflichtenheft

Soll das Risiko verringert werden, müssen entsprechende Cybersecurity-Ziele spezifiziert werden (S8). Ähnlich wie bei der Funktionalen Sicherheit handelt es sich dabei um (nicht-)funktionale Anforderungen auf Konzeptebene. Im Cybersecurity-Konzept müssen wir diese Ziele denjenigen Komponenten der Produktarchitektur zuweisen, für die eine Schutzvorkehrung entwickelt werden muss, etwa für den Internet-Kommunikationskanal. Aus dem Cybersecurity-Ziel wird eine zusätzliche Produktanforderung (S9); Cybersecurity wird so zum Tagesgeschäft. Manche Security-Ziele allerdings müssen auch durch Maßnahmen auf Organisationsebene erfüllt werden.

Leider gibt die ISO 21434 – im Gegensatz zur ISO 26262 – kein Mindestmaß vor, mit welchen Methoden die Anforderungen umzusetzen sind. Formell kann einer Anforderung mit Qualitätssicherungs-Maßnahmen begegnet werden, selbst wenn diese bei potentiell hohem Schaden unzureichend sind, aber dann wird das Risiko in die Zukunft verlagert.

Bei der TARA erfolgt die initiale Bedrohungsanalyse mit Risikobewertung in der Konzeptphase, also vor der eigentlichen Entwicklung. Um das Lagebild der Bedrohungslandschaft aktuell zu halten, muss die Risikobewertung aktuell gehalten und nötigenfalls wiederholt werden – vor und nach der Entwicklung. Ist eine Angriffsmöglichkeit hinzugekommen, ergibt sich dann ein neuer Risikowert mit allen Konsequenzen für den Prozess. Cybersecurity ist also eine Aufgabe, die bereits bei der Konzeption mitgedacht und bis zum vertraglich vereinbarten Serviceende betrieben werden muss.

Damit dies kein Lippenbekenntnis bleibt, fordert die UNECE hierfür ein Cybersecurity Managementsystem (CSMS). Sie fordert folglich klare organisatorische Regeln, Verfahren und Verantwortlichkeiten, um Risiken systematisch erkennen und abwehren zu können – und zwar auch und gerade dann, wenn sich das ursprüngliche Projektteam längst aufgelöst hat.(av)