17.02.2023
Erschienen in: Maschinenmarkt, Ausgabe 2/2023 vom 17.2.2023
Sicher vernetzt
Cybersecurity ist das Thema der Stunde in der Automobilindustrie – und auch darüber hinaus. Bis 2025 werden laut dem Upstream Cybersecurity Report vernetzte Fahrzeuge fast 86 % des globalen Automobilmarktes ausmachen. Die steigende Komplexität erfordert besondere Maßnahmen, um Schutz vor Hackerangriffen zu bieten.
Die steigende Vernetzung führt dazu, dass unsere technischen Systeme immer komplexer werden. Allein die Zahl der industriellen IoT-Verbindungen weltweit soll von 17,7 Milliarden im Jahr 2020 auf 36,8 Milliarden im Jahr 2025 steigen.
Mögliche negative Wechselwirkungen zwischen Fahrzeugfunktionen oder Maschinenfunktionen müssen frühzeitig in der Entwicklungsphase identifiziert werden, ansonsten könnten diese im Rahmen von Cybersecurity-Attacken von Hackern ausgenutzt werden. Ein intelligentes Systemdesign kann diese Art von Wechselwirkungen vermeiden und unnötige Komplexität reduzieren.
„Schwere Unfälle von Flugzeugen, Autos und Industrieanlagen haben im letzten Jahrhundert zur Entwicklung der funktionalen Sicherheit geführt. Eine häufige Ursache von diesen Unfällen waren Ausfälle von Komponenten und Bauteilen. Der Fokus der funktionalen Sicherheit war deshalb diese Ausfälle zu verhindern bzw. deren Auswirkungen zu minimieren. Dies wurde vor allem durch zwei Maßnahmen sichergestellt: Zuverlässige Komponenten und Redundanz. Mit Cyberangriffen kam eine neue Art von Gefährdung auf, die mit diesen Maßnahmen nicht verhindert werden kann. Somit hat sich das Feld Cybersecurity neben der funktionalen Sicherheit entwickelt“, erklärt Stefan Wachter, Head of Business Competence Center Mobility bei msg Plaut.
Standards und Datenbasis
Cybersecurity-Standards wie die ISO 21434 in der Automobilindustrie und die EN62443-Reihe in der Maschinen- und Anlagenindustrie führen durch die Prozesse, die für die zur Erfüllung von Cybersecurity-Anforderungen notwendig sind. Bei Systemen, die nicht nur einer Domäne zugeordnet werden können, kann dieser Prozess schwierig sein. Feuerwehrautos oder Mähdrescher sind weder ausschließlich Straßenfahrzeuge noch ausschließlich Maschinen. Die eingangs erwähnte steigende Komplexität erschwert die Situation noch mehr. Security-Ingenieur:innen steht inzwischen eine große Palette von Methoden zur Threat-Analyse und Risikobewertung zur Auswahl. Die Auswahl einer bestimmten Methodik hängt oft von der Domäne ab, in der man sich befindet.
Viele dieser etablierten Methoden und damit die notwendigen Schritte zur Durchführung sind standardisiert. Als Input ist man in der Regel jedoch auf historische Daten von Vorprojekten und Threat-Datenbanken angewiesen. Zusammen mit Expertenwissen müssen Assets identifiziert und relevante Threat-Szenarien ausgewählt werden. Assets sind alle Komponenten oder Subsysteme, die vor Angriffen geschützt werden müssen.
Risikoanalyse
Eine formale Vorgehensweise zur Auswahl und Begründung der gewählten Assets und Threat-Szenarien fehlt. Dies ist vor allem kritisch, wenn steigende Komplexität technischer Systeme, steigende Security-Anforderungen und der Drang Innovation auf den Markt zu bringen zusammenkommt. Man stelle sich die einfache Frage: Woher sollen Daten aus Vorprojekten kommen, wenn man doch an innovativen, nie dagewesenen Systemen arbeitet? Der Bedarf an erfahrenen Expert:innen steigt und gleichzeitig werden die Systeme weniger übersichtlich. Im Rahmen von internen Übungs- und Prozessentwicklungssitzungen sowie bei ersten Anwendungen beim Kunden hat sich STPA als hilfreich bei der Entwicklung intelligenter Systemdesigns erwiesen. STPA (System-Theoretic Process Analysis) ist eine neuartige Gefährdungs- und Risiko-Analysemethode, die auf der Systemtheorie basiert. Es wurde von Nancy Leveson, Professorin am MIT (Massachusetts Institute of Technology) entwickelt. Ziel der Methodik ist es, potenzielle Schadensereignisse, die am Anfang festgelegt werden müssen, zu verhindern. Diese Schadensereignisse können der Verlust von Menschenleben sein (wie im klassischen Safety Engineering), aber auch finanzielle Schäden oder Reputationsverlust. Letzteres macht die Methodik auch für eine Vielzahl von Branchen interessant, auch wenn sie ursprünglich für das Safety Engineering entwickelt wurde.
Hier werden die Gründe für potenzielle Schadensszenarien als ein Kontrollproblem gesehen. Eine unsichere Kontroll-Aktion gilt es zu verhindern, um Schadensszenarien (Situationen auf Systemebene, die man verhindern möchte), zu vermeiden. Beispiele für unsichere Kontrollaktionen:
- Beispiel 1: Ein Ventil wird nicht geöffnet, wenn der Druck im Kessel zu hoch ist.
- Beispiel 2: Eine Fahrassistenzfunktion lenkt das Auto auf die Gegenfahrbahn, wenn Gegenverkehr ankommt.
Ausgehend von sogenannten Loss-Szenarien – die mit Schadensszenarien (Damage-Scenarios) vergleichbar sind – und einer logischen Befehls- und Feedback-Struktur werden die unsicheren Kontroll-Aktionen identifiziert. Anschließend wird aus Sicht der OT- und Cybersecurity (z.B. ISO 21434 oder EN 62443) vor allem der Frage nachgegangen, wie diese Systemzustände durch Manipulation des Systems hervorgerufen werden könnten.
Daraus werden die Assets identifiziert, die in weiterer Folge mit den etablierten Methoden analysiert werden können. Mit dieser Vorgehensweise erhält man eine schlüssige und rückverfolgbare Argumentation zwischen Schadensszenarien und Assets.