Security by Design im Automotive-Entwicklungsprozess

Im Automotive-Bereich wird Security immer wichtiger – insbesondere für die neuen Generationen vernetzter, (teil-)autonomer Fahrzeuge. In diesem Artikel erkläre ich das Grundkonzept hinter dem Begriff „Security by Design". Sie erfahren außerdem, wie ein sicheres Systemdesign entwickelt wird und welche zusätzlichen Security-Herausforderungen auftreten können. Los geht’s!

Autos sind zu „Computern auf Rädern" geworden, mit einer Vielzahl externer Schnittstellen wie NFC, Bluetooth, WLAN oder USB-Anschlüssen. Schon heute ist der Großteil der Funktionen in Software implementiert. Dadurch wird das gesamte System anfällig für böswillige Security-Angriffe, einschließlich Diebstahl oder Manipulation von Daten.

Ohne geeignete Security-Konzepte können die Integrität und letztlich die Sicherheit des Fahrzeugs leicht kompromittiert werden. Um sichere Fahrzeuge zu entwickeln und auszuliefern, müssen Hersteller Security-Aspekte beachten, und zwar von den frühen Phasen des Automotive-Entwicklungsprozesses an.

Was ist Security by Design?

Werfen wir einen Blick auf die grundlegenden Konzepte und Ideen hinter „Security by Design".

Übertragen auf den Entwicklungsprozess von Fahrzeugen bedeutet das: Das Security-Design muss in den frühen Phasen der Entwicklung berücksichtigt werden, in denen die Kernfunktionen und die Struktur des Fahrzeugs definiert werden.

Ein gängiger Ansatz, um die Phasen des Automotive-Entwicklungsprozesses zu strukturieren, ist das V-Modell:

Anforderungen sind der Ausgangspunkt des Entwicklungsprozesses. Anforderungen können funktionale und nicht-funktionale Aspekte umfassen, die von den Stakeholdern des Systems definiert werden.

Ein Beispiel wäre die Anforderung eines Remote-Software-Updates eines Steuergeräts über einen 4G-Mobilfunkkanal (= funktional) mit einer maximalen Dauer des Remote-Updates von 30 Minuten (= nicht-funktional).

Manche Anforderungen sind sehr technischer Natur und beschreiben z. B. bestehende Schnittstellen oder Laufzeitumgebungen, die bei der Entwicklung neuer Funktionen berücksichtigt werden müssen. Andere Anforderungsquellen können normativen Ursprungs sein, etwa Safety- oder Datenschutzvorschriften.

Auf Basis der initialen Anforderungen entsteht das Design des Systems.

Ein modellbasierter Design-Ansatz unterstützt diesen Prozess, indem er das zu entwickelnde System (System under Development, SUD) in Funktionen, Komponenten, Verbindungen und Datenflüsse zerlegt. Relevante Annahmen, z. B. über die Betriebsumgebung des Systems, sind ebenfalls Teil des Designprozesses.

Während das Abstraktionsniveau in der Designphase noch relativ hoch und oft informell ist, definiert die Spezifikation alle Aspekte des Grunddesigns detaillierter. Dazu gehören z. B. die Zuordnung von Funktionen zu Komponenten, konkrete Protokolle für den Datentransport (z. B. CAN oder Bluetooth) und spezifische Aspekte von Software-Schnittstellen. Das Ergebnis der Spezifikationsphase muss detailliert und formal genug sein, um die Grundlage der Implementierung aller Hardware- und Softwarekomponenten zu bilden.

Das Security Risk Assessment im Automotive-Bereich

Woher weiß ich, dass ein Design ausreichend sicher ist?

Da es keine absolute Sicherheit gibt, birgt das entworfene System immer ein gewisses Risiko, das bewertet werden muss. Dieses Risiko muss auf oder unter der Schwelle liegen, die der Hersteller als akzeptabel ansieht.

Das Risikoniveau eines Systemdesigns lässt sich durch ein Security Risk Assessment ermitteln, das auf den ersten drei Phasen des Entwicklungsprozesses aufsetzt. Die Anforderungen enthalten typischerweise bereits Verweise auf Security-, Safety- oder Datenschutz-Normen wie ISO 27001, ISO 26262 oder DSGVO.

In naher Zukunft wird die ISO/SAE 21434 für die sichere Entwicklung von Personenkraftwagen gelten. Die meisten Normen empfehlen oder schreiben sogar vor, in dieser Phase des Entwicklungsprozesses ein Security Risk Assessment durchzuführen. Das Security Risk Assessment betrachtet potenzielle Schäden, die aus der Verletzung von Security-Aspekten der Elemente des SUD entstehen.

Zu den Security-Aspekten gehören typischerweise die Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit.

Doch was genau sind die potenziellen Schäden, die wir berücksichtigen müssen?

Während sich der Datenschutz auf rechtliche Aspekte konzentriert, betrachtet die Safety ausschließlich mögliche Verletzungen oder den Tod von Fahrer oder Insassen. Da Security sowohl Datenschutz als auch Safety beeinflussen kann, muss das Security Risk Assessment rechtliche Schäden und mögliche Verletzungen einbeziehen.

Weitere Schäden aus einem schlechten Security-Design können auch finanzieller Natur sein, z. B. wenn wertvolle Daten gestohlen werden.

Security-Probleme können außerdem zu erheblichen Funktionseinschränkungen führen, etwa einem Fahrzeug mit eingeschränkten Funktionen oder einem Fahrzeug, das gar nicht mehr fahren kann. Aus Safety-Sicht ist dieser stationäre „sichere Zustand" unproblematisch. Aus Sicht von Hersteller und Insassen ist es jedoch höchst unerwünscht, das Auto nicht starten zu können, und sollte daher berücksichtigt werden.

Neben den potenziellen Schäden muss auch die Wahrscheinlichkeit betrachtet werden, mit der die negativen Folgen eintreten. Bei Safety-Aspekten eines Systems lässt sich die Wahrscheinlichkeit oft als statistische Größe ausdrücken, z. B. als mittlere Betriebsdauer zwischen Ausfällen einer Komponente (MTBF) unter definierten Betriebsbedingungen.

Diese Wahrscheinlichkeiten basieren oft auf physikalischen Gesetzen und bleiben über die Lebensdauer des Systems relativ stabil. Bei der Bestimmung der Wahrscheinlichkeit von Cyber-Angriffen funktioniert dieser Ansatz leider nicht.

Um in der Security ein Gefühl für Wahrscheinlichkeiten zu bekommen, kommen potenzielle Angriffe und Gegenmaßnahmen ins Spiel. Je leichter ein Angriff erfolgreich durchgeführt werden kann, desto wahrscheinlicher tritt der daraus resultierende Schaden ein. Gleichzeitig lassen sich Kontrollen oder Gegenmaßnahmen etablieren, die erfolgreiche Angriffe erschweren und damit unwahrscheinlicher machen.

Die sogenannten Risikofaktoren für Angriffe und Gegenmaßnahmen sind dynamischer Natur, da regelmäßig neue Schwachstellen entdeckt werden (z. B. die „Heartbleed"-Schwachstelle des OpenSSL-Protokolls) und Hacking-Ausrüstung mit der Zeit leistungsfähiger und erschwinglicher wird.

Die Kombination aus potenziellen Schäden und der Wahrscheinlichkeit erfolgreicher Angriffe, gemindert durch Kontrollen, ergibt das Gesamtrisikopotenzial des zu entwickelnden Systems.

Der Gesamtprozess des Security Risk Assessments lässt sich wie folgt darstellen:

Security by Design – ein modellbasierter, iterativer Prozess

Im Systems Engineering – und dazu gehört auch der Automotive-Entwicklungsprozess – ist die Modellierung von Systemen zum Mittel der Wahl geworden, um mit der gestiegenen Komplexität umzugehen. Die vorgeschlagene Methodik für das Security Risk Assessment ist daher ebenfalls ein modellbasierter Ansatz, der die relevanten security-spezifischen Aspekte berücksichtigt.

Der Bedarf an einem iterativen Prozess bei der Modellierung von Security-Aspekten ist jedoch ausgeprägter als in anderen Bereichen. Die Minderung identifizierter Risiken durch Kontrollen und Gegenmaßnahmen muss das verbleibende Risiko auf ein akzeptables Niveau senken.

Gleichzeitig müssen Kontrollen wie Verschlüsselung, Schlüsselmanagement oder sichere Hardware-Elemente kosteneffizient sein. Ein Security Risk Assessment und ein Security-by-Design-Prozess umfassen daher auch die Aufgabe, den kosteneffizientesten Weg zum Erreichen der Schutzziele zu finden.

Das lässt sich nur in einem iterativen Prozess erreichen, indem die Auswirkungen verschiedener Kombinationen von Gegenmaßnahmen verglichen und die Anforderungen und das Design entsprechend angepasst werden.

Systemmodell und Gegenmaßnahmen beeinflussen sich gegenseitig. Verschlüsselung erschwert die Durchführung eines Angriffs und kann daher eine wirksame Gegenmaßnahme sein. Gleichzeitig bringt Verschlüsselung symmetrische oder asymmetrische Schlüssel in die Lösung ein. Diese Schlüssel werden dann Teil des Systemmodells und damit auch des Designs.

Damit werden Erzeugung, Schutz und Verwaltung von Schlüsseln zu einem integralen Bestandteil des Systemmodells und des Security-by-Design-Prozesses.

Zusätzliche Security-Herausforderungen im Automotive-Bereich

Nehmen wir an, der Designprozess war erfolgreich und es ist ein sicheres Systemmodell (Anforderungen + Design + Spezifikation) mit ausreichenden Kontrollen und Gegenmaßnahmen für ein sicheres System entstanden. Nehmen wir außerdem an, dass die Implementierung sicher durchgeführt wurde, z. B. nach Secure-Coding-Richtlinien. Im Entwicklungsprozess wurden dem System keine zusätzlichen Schwachstellen hinzugefügt. Alle anschließenden Tests waren erfolgreich, und das Fahrzeug wurde auf den Markt gebracht.

Im Gegensatz zu Safety-Aspekten technischer Systeme ist das Security-Umfeld hochdynamisch. Angreifer sind kreativ und einfallsreich. Neue Schwachstellen werden täglich entdeckt und gemeldet. Das Security-Risikoniveau eines Fahrzeugs oder einer Komponente ist daher nicht über die Zeit stabil, sondern muss über die Lebensdauer des Systems regelmäßig neu bewertet werden.

Für ein bestimmtes Fahrzeugmodell können das leicht 12 oder 15 Jahre kontinuierlicher Risikobewertung sein!

Werden Risiken identifiziert, die über dem akzeptierten Risikoniveau liegen, müssen neue Gegenmaßnahmen eingeführt oder bestehende Kontrollen aktualisiert werden. Das ist eine gewaltige Herausforderung für die Automobilindustrie!

Ein modellbasierter Ansatz für die Security-Risikoanalyse ist daher nicht nur in der Designphase eines Fahrzeugmodells oder einer Komponente entscheidend, er wird auch zur Grundlage eines fortlaufenden Security Risk Assessments über die gesamte Lebensdauer des Fahrzeugs.

Zusammenfassung

Im Automotive-Entwicklungsprozess beginnt Security by Design bereits in der Anforderungsphase. In einem iterativen Prozess, der auch die Design- und die Spezifikationsphase umfasst, entsteht ein sicheres Systemdesign.

Über mehrere Iterationen werden im Rahmen eines modellbasierten Security Risk Assessments potenzielle Schäden und Bedrohungen identifiziert. Geeignete Gegenmaßnahmen werden dem Design hinzugefügt, sodass die angestrebten Risikoniveaus mit dem wirtschaftlich und technisch sinnvollsten Satz an Kontrollen erreicht werden. Auf Basis des sicheren Designs wird das System anschließend implementiert, getestet und auf den Markt gebracht.

Geeignete Werkzeuge unterstützen Security-Analysten über den gesamten Modellierungsprozess hinweg und stellen sicher, dass alle Abhängigkeiten von Assets, Schäden, Bedrohungen und Kontrollen berücksichtigt und die resultierenden Risikoniveaus automatisch berechnet werden.

Über die gesamte Lebensdauer des Fahrzeugs können das ursprüngliche Systemmodell und das Modell des Security Risk Assessments genutzt werden, um aktualisierte Schwachstelleninformationen sowie die neuesten Bedrohungs- und Kontrolldaten einzuspielen.

Das kontinuierliche Monitoring der aktuellen Risikoniveaus kann genutzt werden, um Software-Updates zu planen oder bei Bedarf alternative Maßnahmen einzuleiten. Mit geeigneter Werkzeugunterstützung wird das Fahrzeug von Anfang an sicher entworfen und über die gesamte Lebensdauer sicher gehalten.

Mit YAKINDU Security Analyst (heute itemis SECURE) bietet itemis ein modellbasiertes Werkzeug für Security Risk Assessments in der Designphase und über die gesamte Lebensdauer des Fahrzeugmodells. Mehr über itemis SECURE erfahren →

Automotive Cybersecurity bei itemis — ISO/SAE 21434, TARA, IEC 62443 und ihre Umsetzung mit passendem Tooling: Cyber Security bei itemis →