Cybersecurity

Neben der funktionalen Sicherheit müssen Autohersteller auch die Cybersecurity gewährleisten und es zum Tagesgeschäft machen. (Bild: Kugler-Maag)

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.

Cybersecurity im Auto

Cybersecurity ist keine dauerhafte Eigenschaft, die einem Fahrzeug in der Produktion ein für alle Mal mitgegeben werden kann, und Security-by-Design reicht auch nicht (mehr). Stattdessen muss das Auto als hochgradig zu schützendes Gerät gedacht werden, bei dem die Security ständig gehärtet werden muss. Cybersecurity stellt eine ganzheitliche Aufgabe dar, die durch verbindliche Prozesse auch auf Unternehmensebene angegangen werden muss. Aus dem Cybersecurity-Ziel wird eine zusätzliche Produktanforderung, denn Cybersecurity wird zum Tagesgeschäft. Mit dem Nine-to-Five TARA-Navigator besteht jetzt die Möglichkeit, systematisch Risiken zu identifizieren und Cybersecurity-Ziele abzuleiten.

Wie kann ein Unternehmen bewerten, wie groß ein Risiko sein wird, das es nicht kennt?

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.

TARA-Navigator von Kugler Maag Cie
Bild 1: Der Nine2Five-TARA-Navigator besteht aus neun Analyseschritten und fünf Zielen für Cybersecurity. Der TARA-Navigator ist ein praxiserprobtes Vorgehen, um in der Konzeptphase strukturiert Threat Analyses and Risk Assessments zu erstellen. Er bereitet die Prozessschritte aus der ISO/SAE DIS 21434 für die Anwendung in der Praxis auf. Darüber hinaus enthält er Hinweise, welche Methoden besonders hilfreich sind. (Bild: Kugler Maag Cie)

Jetzt geht es los

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.

Eine TARA ist als logische Kette aufgebaut

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.

Wahrscheinlichkeit

Bei der Bestimmung des Risikowerts wird ein fundamentaler Unterschied zur Funktionssicherheit (ISO 26262) deutlich. Cybersecurity-Konzepte verwenden mit dem Wort „Likelihood“ den Ausdruck der Auf- oder Eintrittswahrscheinlichkeit. Die Funktionale Sicherheit hingegen spricht von Wahrscheinlichkeit und damit von „Probability“. Dadurch wird betont, dass Cybersecurity-Angriffe mit einem hohen Maß an Ungewissheit verbunden sind: Cyber-Risiken lassen sich nicht mit einer geschlossenen Wahrscheinlichkeitsformel errechnen, denn schließlich ist die Grundgesamtheit potenzieller Angriffe unbekannt. Stattdessen wird durch Beobachtungen auf die Auftrittswahrscheinlichkeit eines Angriffs geschlossen.

Studie

Studie "Automotive Security. State of Practice 2020"
Gemeinsam mit der Universität Stuttgart führte Kugler Maag Cie eine Studie mit dem dem Namen "Automotive Security. State of Practice 2020" zur Cybersecurity im Fahrzeug durch. (Bild: Kugler Maag Cie)

Zusammen mit Experten von führenden Automobilherstellern und -zulieferern hat Kugler Maag Cie in qualitativen Interviews erörtert, wie es um Cybersecurity derzeit in der Autobranche bestellt ist. In einem Horizon Scan wurden Experten darum gebeten einzuschätzen, welches Verständnis in der täglichen Praxis tätige Personen von Cybersecurity derzeit haben. Auf den Erkenntnissen aufbauend hat Kugler Maag Cie eine kleine Anleitung verfasst, wie diese Herausforderungen strukturiert und mit Synergieeffekten geschlossen werden können.

Vor allem geht es dabei um den fundamentalen Wandel im Verständnis, dass Cybersecurity nur funktionieren kann, wenn sie tief in der Organisation verankert ist. Selbstverständlich wirken Schutzvorkehrungen auf technischer Ebene, die per Security-by-Design implementiert sind. Doch das Wissen, wann und wo gehandelt werden muss, kann nur die Organisation selbst beitragen und aktuell halten.

Aus dem Inhalt

  • Grundlagen der Automotive Cybersecurity
  • Einführung in die Normenwelt
  • Von der Theorie zur TARA
  • Architekturskizze für Software-Updates
  • Automotive SPICE im Kontext von Cybersecurity
  • Funktionssicherheit und Cybersecurity
  • Offene Fragen der Automotive Cybersecurity

»Automotive Cybersecurity. State of Practice 2020« wurde in enger Abstimmung mit dem Institut für Informationssicherheit (SEC) der Universität Stuttgart unter Leitung von Prof. Dr. Ralf Küsters durchgeführt. Der Report steht in der Online-Variante dieses Beitrags kostenfrei für den Download bereit.

Der Risikowert lässt sich bestimmen

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.

Bedrohungsanalyse, Risikobewertung mit TARA
Bild 2: Cybersecurity vor, während und nach den Projekten: Zu Beginn eines Entwicklungsprojekts führt das Team eine Bedrohungsanalyse sowie eine initiale Risikobewertung durch. Diese TARA muss aktuell gehalten werden. Findet sich noch vor dem Produktionsstart eine Bedrohung, geht diese als Verwundbarkeit in die Entwicklung ein. Wird die Bedrohung erst im Flottenbetrieb entdeckt, handelt es sich um einen Vorfall. Wie mit diesem umgegangen werden soll, regeln Entscheidungsroutinen im Managementsystem für Cybersecurity. (Bild: Kugler Maag Cie)

TARA: Bedrohungsanalyse mit Risikobewertung schon in der Konzeptphase

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)

Autor

Dominik Strube, Kugler Maag Cie
Dominik Strube, Kugler Maag Cie (Bilder: Kugler Maag Cie)

Dipl.-Ing. Dominik Strube, M.BC

Unternehmenskommunikation und Betreuung Studienprogramm bei Kugler Maag Cie.

Kostenlose Registrierung

Bleiben Sie stets zu allen wichtigen Themen und Trends informiert.
Das Passwort muss mindestens acht Zeichen lang sein.
*

Ich habe die AGB, die Hinweise zum Widerrufsrecht und zum Datenschutz gelesen und akzeptiere diese.

*) Pflichtfeld

Sie sind bereits registriert?

Unternehmen

KUGLER MAAG CIE GmbH

Leibnizstraße 11
70806 Kornwestheim
Germany