Was macht Cybersecurity im autonomen und hochvernetzen Umfeld so herausfordernd?

Die Fahrzeugentwicklung kann sich heute bereits auf Normen, Richtlinien und Erfahrungswerte stützen. Darunter bspw. UNECE R155/156 und ISO21434 und einen relativ homogenen Pool an typischen Cybersecurity Controls, also high-level Anforderungen. Kurzum, eine Art Basis-Security ist vorhanden, die Normung des Vorgehens weitestgehend ausreichend. Was autonome Fahrzeuge und People-Mover in den Cybersecurity Anforderungen besonders macht ist deren Einsatzfeld bzw. die damit verknüpften Use-Cases:

• Dem Monitoring des Gesamtsystems kommt deutlich mehr Bedeutung zu als bei nicht-autonomen Systemen. Der Fahrer, dem bspw. ein ungewöhnliches Verhalten an seinem Fahrzeug auffallen würde, fällt vollständig weg.
• Bei People-Movern kommt erschwerend hinzu, dass sich das Fahrzeug in verschiedene Ökosysteme integrieren muss. Redundanz gilt dabei als Feind des Cybersecurity Grundprinzips „keep it small and simple“. Beispiele für mehrere Ökosysteme sind ein Backend-System des Betreibers, über das Buchungen vorgenommen werden, die cloudbasierte Anbindung des autonomen Fahrsystems eines anderen Herstellers, eine Connectivity Plattform für das Entertainmentsystem, welches In-Vehicle-Advertisment platziert und werbetreibende Unternehmen vernetzt, sowie diverse Lösungen für Maintenance, Update-Management und Charging. Jede Schnittstelle integriert externe Unternehmen mit einem immer größer werdenden Bedarf an Daten und ist eine potenzielle Schwachstelle.
• Gegenüber einem autonomen PKW hat jedoch der People-Mover den Vorteil, dass er sich in sehr engen Zeitabständen in seiner Home-Base einfindet, wo das Fahrzeug nicht nur geladen wird, sondern sich auch Wartungsarbeiten oder Softwareupdates ausführen lassen. Hier ließe sich auch ein manuelles Cybersecurity Testing durchführen.

Auf dem Weg zum idealen Cybersecurity Projektsetup für autonome Fahrzeuge und People-Mover

Aus unseren Erfahrungen mit Cybersecurity Projekten im Umfeld von autonomen Fahrzeugen, wie bspw. dem People-Mover Projekt HOLON, können wir einige Punkte ableiten, welche für die Teamzusammenstellung, die richtige Projektarchitektur und für die Zusammenarbeit mit Zulieferern essenziell sind.

Die ideale Teamzusammenstellung

Der Teamzusammenstellung sollte gleich zu Beginn größte Aufmerksamkeit geschenkt werden, denn die besonderen Herausforderungen bei People-Movern und autonomen Fahrzeugen machen es ratsam, nicht nur auf Cybersecurity Generalisten zu setzen, sondern Fachexperten mit zusätzlichem Fahrzeug-Know-how einzubinden. Viele Sicherheitsmaßnahmen müssen tief in den Stack des Software-Defined-Vehicles eingreifen, da Kernfunktionen zunehmend als Software abgebildet und über zahlreiche Steuergeräte verteilt werden. Dieses Systems Engineering Verständnis, das die Fahrzeug-IT und EE-Architektur einschließt, hilft bspw. zu erkennen, welche Datenflüsse und Schnittstellen zwingend erforderlich sind und welche nicht. Jeder Zugriff, der sich unter Berücksichtigung des Gesamtsystems vermeiden lässt, ist eine Schnittstelle weniger, die abgesichert und gemonitort werden muss. Festzuhalten bleibt also, dass Cybersecurity Systems Engineering Herausforderungen in der Software-Architektur gelöst werden können und spezifisches Know-how dafür notwendig ist.

Security Normen und Zulieferer

Die Norm R155 ist das primäre Ziel für die Typzulassung in Bezug auf Cybersecurity Anforderungen. Die sogenannte „Vehicle TARA“ ist der ideale Weg, um diese und andere begleitende Normen zu erreichen und um ein gemeinsames Verständnis im gesamten Projektteam herzstellen. Zulieferer, die in Fahrzeugprojekten eingebunden werden, erhalten in der Regel Vorgaben des Security Konzepts vom OEM. Ein anderer Weg kann jedoch sein, Security auf Komponentenebene zu definieren und die Zulieferer in die Pflicht zu nehmen. So geschehen beim People-Mover Projekt HOLON, dessen „Components-Off-The-Shelf“-Strategie nicht nur für eine Kostenoptimierung entlang des Projektes sorgte, sondern die Projektpartner tiefer als üblich in den Security Prozess einband.   

Die richtige Architektur für die richtige Flughöhe

Was ist der richtige Aufsatzpunkt, um Sicherheitsmaßnahmen ins Fahrzeug zu integrieren und Schwachstellen bzw. mögliche Angriffsvektoren nicht außer Acht zu lassen? In der Praxis hat sich hier das Herunterbrechen von Fahrzeug- auf Funktions- und dann auf Komponentenlevel bewährt:

1. Im ersten Schritt werden analog zum Paradigma der funktionsorientierten Entwicklung die vorhandenen Features und Funktionen mit ihren funktionalen und nichtfunktionalen Anforderungen erfasst.
2. Funktionen werden sukzessiv bis auf Komponentenebene zerlegt.
3. Die notwendigen Cybersecurity „Arbeitsprodukte“ werden aus der R155 und der ISO21434 abgeleitet.
4. Für alle Funktionen und Komponenten werden diese Arbeitspakete mit ihren Zielen, Anforderungen und Kontrollmechanismen angewendet. Hier kann strukturiert nach der TARA vorgegangen werden.

Projektabstimmung in der Praxis: Wie bringt man OEM und Zulieferer in Bezug auf Cybersecurity zusammen?

Um alle Stakeholder an einen Tisch zu bekommen und gemeinsam an einer Lösung zu arbeiten, hat sich im Projektalltag ein Phasenmodell bewährt.

1. Während der ersten Anfragephase werden die Komponenten in Klassen eingeteilt und grundlegende Security Anforderungen je Klasse definiert (bspw. Secure Boot, Secure Update, Message Authentication, Hardware-Security-Module) und angefragt. Diese grundlegenden Anforderungen dienen der Auslegung der Komponenten und erlauben die Planung und das Anbieten dieser.
   
2. Parallel dazu werden strukturiert die detaillierten Schutzziele ausgehend vom vernetzten Gesamtfahrzeug auf die einzelnen Komponenten heruntergebrochen. Diese Schutzziele dienen der ersten, detaillierten Abstimmungen bzgl. Cybersecurity mit den Zulieferern und sind essenziell, um unterschiedliche Annahmen und Risikobewertungen anzugleichen. In dieser Phase sind zwar die Ziele klar, es besteht aber noch ein entsprechender Umsetzungsspielraum für die Zulieferer.
   Was auf den ersten Blick gut klingt und als Entgegenkommen für die Zulieferer gedacht war, stellt sich jedoch je nach Reife des Zulieferers stellenweise auch als größere Herausforderung dar. Denn damit werden teils gewohnte Pfade der strikten Implementierung von detailliert vorgegebenen Requirements verlassen und eine gewisse Selbständigkeit und ein Cybersecurity-Bewusstsein für das eigene Produkt erwartet. Anforderungen, die bisher seitens der OEMs und nicht der Zulieferer gelöst wurden.
   
3. Hat man sich schlussendlich auf eine gemeinsame Implementierungsvariante geeinigt, so werden die Restrisiken basierend auf diesen Beschlüssen erneut auf den verschiedenen Ebenen von Komponente bis hin zum vernetzten Fahrzeug bewertet und ggf. weitere Maßnahmen ergriffen. Typische Maßnahmen könnten die Akzeptanz eines erhöhten Risikos, der Transfer einer Maßnahme auf eine andere Komponente oder eine Anpassung der Funktionalität sein. Je nach Ergebnis werden mehrere Schleifen dieser Abstimmung benötigt.
   
4. Der abgestimmte Stand wird dann in Form von Cybersecurity Anforderungen in das Komponentenlastenheft geschrieben und die Umsetzung im Implementierungsplan (schrittweise) ausgeplant. Wann immer Abhängigkeiten zwischen den Steuergeräten berücksichtig werden müssen, ist auf eine strikte Koordination zwischen den Komponenten zu achten.
   Viele Cybersecurity Controls basieren auf kryptografischen Verfahren und verhindern die nicht explizit freigegebene Nutzung gesicherter Funktionen. Zur Authentifikation bzw. Autorisierung wird entsprechendes kryptografisches Schlüsselmaterial in unterschiedlichen Formen benötigt. Egal ob symmetrische oder asymmetrische Verfahren zum Einsatz kommen, es wird immer eine gewisse Koordination des Schlüsselmaterials zwischen Steuergeräten, Tools und IT-Systemen notwendig sein.
   
5. Erst nach Implementierung entsprechender Identity-, Access- und Key Management- Prozesse bei allen Beteiligten können diese Funktionen wieder wie ursprünglich angedacht, prozesssicher verwendet werden. Die Definition und Implementierung der entsprechenden Prozesse und Werkzeuge über alle Beteiligten hinweg ist daher Voraussetzung zu einer erfolgreichen Integration von Komponenten mit aktiven Security Funktionen.
   
6. Sobald die ersten Steuergeräte mit implementierten Security-Funktionen zur Verfügung stehen, kann die funktionale Testphase dieser Mechanismen analog zu anderen funktionalen Tests durchgeführt werden. Getestet wird hier also, ob die Implementierung der Security Funktionen der Spezifikation entspricht. Eine Security Teststrategie sieht dabei typischerweise eine Aufteilung verschiedener Testschritte auf Zulieferer, Komponenten- und Integrationsteststände, sowie Tests mit den notwendigen Tools und IT-Systemen vor.
   
7. Ergänzt werden die funktionalen Tests durch sog. Security Tests. Ziel dabei ist es herauszufinden, ob die implementierten Maßnahmen die gewünschten Schutzziele erreichen. Mögliche Sicherheitslücken lassen sich z. B. durch Penetration-Tests identifizieren. Bei diesen Tests ist kreatives Potenzial gefragt, denn Schwachstellen lassen sich meist nur durch unkonventionelle Denkmuster aufdecken. Als Beispiel sei hier auf die ersten Keyless-Go-Systeme verwiesen, die sich trotz kryptografischer Absicherung mit einem einfachen Signalrepeater austricksen ließen.
   
8. Die letzte Phase beschreibt das kontinuierliche Monitoring und sogenannte „Vulnerability Management“. Die Schwierigkeit in dieser Phase der Kooperation zwischen OEM und Zulieferer liegt in der relativ langen Lebenszeit (Vehicle Lifetime) der Fahrzeuge. Es empfiehlt sich, eine vertragliche Lebenszeit zu vereinbaren, auf die eine Security Garantie abgegeben werden kann.

Das Team bei Cognizant Mobility beschäftigt sich seit Jahren mit den Cybersecurity Herausforderungen komplexer, vernetzter und autonomer Fahrzeuge und verbindet Cyber-Fachwissen mit Fahrzeug-Know-how von Embedded Software bis hin zur Cloud-IT.