Safety-Security-Co-Engineering: Ein Muss für autonome Systeme

Autoren: Daniel Schneider, Reinhard Schwarz und Christian Jung | Fraunhofer IESE

Autonome Systeme werden einer der zentralen Innovationstreiber des kommenden Jahrzehnts sein. Forschungs­- und Entwicklungsabteilungen arbeiten mit Hochdruck an der Umsetzung von hoch-­ und vollautomatisierten Systemen, welche autonom Entscheidungen treffen können. Solche autonomen Systeme bedeuten ein deutliches Mehr an Komplexität, an Unsicherheiten und Unbekannten, was Unternehmen bei der Gewährleistung der Safety (Funktionssicherheit) vor große Herausforderungen stellt.

Gleichzeitig ergeben sich durch die zunehmende Vernetzung und Heterogenität der Systeme viele potenzielle Angriffsvektoren im Sinne der Security (Cybersicherheit), die es ebenfalls abzusichern gilt.

Warum ist das Zusammenspiel von Safety & Security so wichtig?

Angriffe auf die Security können bei vielen Systemen einen direkten Einfluss auf die Safety haben, was deren Absicherung weiter erschwert. Das Zusammenspiel von Safety und
Security ist von immenser Bedeutung. Es genügt nicht, Safety einerseits und Security andererseits zu betrachten, sondern vor allem deren Zusammenspiel. So ist die Vermeidung gezielter Hackerangriffe auf ein Fahrzeug eine Aufgabe der Security ­Spezialisten. Gleichzeitig gefährdet ein solcher Angriff die Fahrzeug-­Safety und muss daher auch von den Safety-Spezialisten berücksichtigt werden.

Geläufige Safety-­Maßnahmen gehen von physikalischen Phänomenen wie elektromagnetischer Strahlung oder Bauteilalterung aus. Auch systematische Fehler, die sich unabsichtlich beispielsweise in Form von Programmierfehlern einschleichen, werden berücksichtigt, nicht aber böswillige Angriffe oder gezielte Manipulationen. Aus Safety­-Sicht genügt es z. B., ein übertragenes Signal mit einer Prüfsumme zu versehen, um zufällige Nachrichtenverfälschungen auf dem Übertragungsweg ausreichend sicher zu detektieren. Für einen Hacker wäre das allerdings keine Hürde, da sich die Prüfsumme leicht an eine verfälschte Nachricht anpassen lässt und daher kein geeignetes Mittel zur Sicherstellung der Nachrichtenintegrität aus Security-Perspektive ist.

Safety-Security-Co-Engineering als wichtige Voraussetzung für die Wertschöpfung
in autonomen Systemen

Das Zusammenspiel von Safety und Security wird umso wichtiger, wenn man den Blick vom einzelnen System löst, um sich die digitale Infrastruktur als Ganzes anzuschauen. Zukünftig formen unzählige Systeme zusammen mit zahlreichen digitalen Diensten
so genannte Smart Ecosystems. Die wesentliche Wertschöpfung wird nicht aus den autonomen Systemen an sich gewonnen, sondern aus den durch sie ermöglichten Diensten. So liegt beispielsweise die Wertschöpfung weniger in einem autonomen Fahrzeug als vielmehr in den dadurch ermöglichten Mobilitätsdiensten, die auf Basis einer intensiven Datenauswertung ganzer Flotten von Fahrzeugen das Zusammenspiel verschiedener Verkehrsmittel optimieren.

Über einen gezielten Angriff ließe sich ein Mobilitätsdienst vollständig lahmlegen, und ein Hacker könnte schlimmstenfalls nicht nur die Kontrolle über ein einzelnes Fahrzeug, sondern gleich über eine ganze Fahrzeugflotte erlangen – mit unabsehbaren Folgen für die Verkehrssicherheit. Neue Ansätze müssen also Safety und Security und deren
Wechselwirkungen gleichermaßen betrachten.

Neue Ansätze zur Analyse von Sicherheitsrisiken in komplexen Systemen

In den vergangenen Jahren hat sich das Fraunhofer IESE sowohl in Förderprojekten als auch in Kollaborationen mit Industriepartnern dem Thema Safety­-Security-Co­-Engineering gewidmet. Dabei stand einerseits die Integration beider Disziplinen und andererseits die Nutzung modellbasierter Ansätze im Blickpunkt. In diesem Sinne wurden etabliertemTechniken aus beiden Welten in einer integrierten Methodik zusammengefasst und dabei auch die Leitplanken berücksichtigt, die aus der jeweils relevanten Normung hervorgehen, wie die ISO 26262 »Roadvehicles – Functional safety« und ISO 21434 »Road vehicles – Cybersecurity engineering«.

Ein vielversprechender Ansatz aus der Forschung, welchen wir in unsere übergeordnete Methodik integriert haben, ist eine Methode zur Analyse von Sicherheitsrisiken
in komplexen Systemen: System Theoretic Process Analysis (STPA).

Was ist die System Theoretic Process Analysis (STPA)?

Im Gegensatz zu traditionellen Methoden zur Risikoanalyse, die sich oft auf das Versagen einzelner technischer Komponenten als mögliche Fehlerquellen konzentrieren, untersucht STPA das System als Ganzes und betrachtet die Wechselwirkungen zwischen den verschiedenen Elementen des Systems. Die Gewährleistung von Sicherheit wird hier nicht als ein Verhindern funktionaler Defekte verstanden, sondern als ein Steuerungsproblem, das darauf zielt, das Systemverhalten jederzeit so zu beschränken, dass vorgegebene Missionsziele eingehalten werden.

Diese Sichtweise berücksichtigt, dass in heutigen Systemen viele Sicherheitszwischenfälle nicht durch Komponentenversagen hervorgerufen werden, sondern dadurch, dass im komplexen Zusammenspiel der Komponenten, die alle gemäß ihrer Spezifikation korrekt funktioniert haben, unerwartete Wechselwirkungen auftreten. Ein solches Paradigma eignet sich gleichermaßen für die Betrachtung von funktionaler Sicherheit wie für Informationssicherheit. Gerade Cyberangriffe machen sich oft solche überraschenden Rückkopplungseffekte zunutze.

STPA bietet damit eine gemeinsame Modellierungsbasis für die Verständigung zwischen
Systementwicklern, Safety-­ und Security-­Spezialisten. STPA bietet auch die Möglichkeit,
die Systemnutzer:innen als eigene Steuerungsebene zu modellieren. Dadurch können nicht nur offensichtliche, sondern auch versteckte und komplexe Sicherheitsprobleme
aufgedeckt werden, etwa auch sogenannte Human Factors von Sicherheitszwischenfällen.

Da Cybersecurity einen planmäßig handelnden Angreifer mit eigenen, böswilligen
»Missionszielen« unterstellt, ist die Berücksichtigung des Faktors Mensch ein wichtiger Aspekt.

Praktische Anwendung der System-Theoretic Process Analysis

Bei der Anwendung der STPA-Methodik geht man in vier Schritten vor: Ausgehend von den Missionszielen eines Systems betrachtet man zunächst mögliche Schadenszenarien auf Systemebene, die den Missionserfolg gefährden würden und Schäden oder Einbußen für
relevante Interessengruppen zur Folge hätten. Dies können unbeabsichtigte oder böswillig herbeigeführte Szenarien sein. Daraus ergibt sich ein Steuerungsproblem für die cyber­physischen Systemprozesse:

Die Prozesse müssen so überwacht und gesteuert werden, dass die zuvor bestimmten Schadensszenarien nicht eintreten und dass das Systemverhalten die vorzeichneten
Grenzen niemals verlässt. Dazu wird im zweiten Schritt ein hierarchisches
STPA Kontrollstruktur­-Modell erstellt. Das Modell stellt dar, wie die verschiedenen Steuerungsebenen durch sogenannte Control Actions das Prozessverhalten in sichere Bahnen lenken, wobei die Steuerungslogik ihre Entscheidungen auf ein Modell der cyber­physischen Prozesse stützt, dass durch Prozessfeedback stets auf einem aktuellen Stand gehalten wird. Sicherheitszwischenfälle treten auf, wenn die Steuerung entweder falsche
Control Actions auslöst, oder sinnvolle Control Actions verfrüht, verspätet oder in der falschen Intensität ergreift.

Im dritten Schritt der Analyse wird daher untersucht, inwieweit unsichere Control Actions solche Schadensereignisse verursachen können und wie sie ausgelöst werden können. Mögliche Ursachen sind zum Beispiel Fehler im logischen Prozessmodell,
das die wahren Gegebenheiten im cyber­physischen Prozess aufgrund von fehlerhaftem oder manipuliertem Prozessfeedback falsch widerspiegelt. Eventuell wird aber auch eine korrekte
Steuerungsanweisung falsch übermittelt oder vom Aktuator fehlerhaft ausgeführt, oder die Regelungs­- und Steuerungskreise des Systems sind intakt, aber die Steuerungslogik
leitet aus dem Prozessmodell falsche Schlüsse ab.

Für jede erkannte Fehlerquelle werden im vierten Schritt entsprechende Sicherheitsziele
formuliert, die darauf abzielen, den entsprechenden Steuerungsfehler durch geeignete Sicherheitsvorkehrungen auszuschließen. Entsprechende Beschränkungen
können auf allen Hierarchieebenen ansetzen: Sie können technische Abläufe absichern oder einschränken, aber auch das mögliche Nutzerverhalten an der Bedienschnittstelle.

Das STPA-­Kontrollstruktur­-Model hilft dabei, auch komplexere Rückkopplungsschleifen aufzudecken, die ein unerwünschtes Systemverhalten auslösen könnten, ohne dass der
Fehler an einer einzelnen Systemkomponente festzumachen wäre. Die hier skizzierte Vorgehensweise kann sowohl Safety-­ als auch Cybersecurity-­Risiken betrachten, gegebenenfalls sogar nicht­sicherheitsrelevante Aspekte wie etwa Anwendungsfreundlichkeit der Systemschnittstellen.

Zudem kann ein logisches Kontrollstruktur­-Modell schon in ganz frühen Phasen der Systementwicklung erstellt werden, noch ehe überhaupt eine genauere Systemarchitektur mit festgelegten technischen Schnittstellen verfügbar ist. Daher eignet sich STPA als gemeinsame Basis für Hazard Analysis and Risk Assessment (HARA) aus
Safety-­Sicht sowie für Threat Analysis and Risk Assessment (TARA) aus Security­-Sicht.

Fazit

Das STPA­-Modell bietet zudem eine willkommene Gelegenheit für die Sicherheitsexperten, den Systementwurf und seine Ziele zu hinterfragen und sich in das Systemdesign einzuarbeiten. Im Sinne von »Safety and Security by Design« ist es wichtig Sicherheitsspezialisten möglichst früh in die Systementwicklung einzubeziehen, um grundlegende Safety- und Security-­Eigenschaften von Beginn an im Systementwurf zu verankern.

Nachdem die elementaren Sicherheitsziele bestimmt worden sind, kann auf dieser Basis ein Safety­- und ein Cybersecurity­-Konzept für das System erstellt werden, das dann in nachfolgenden Iterationen zusammen mit den Systementwicklern schrittweise in genaue technische Anforderungsspezifikationen verfeinert wird. Unsere Ansätze haben sich in der
Praxis bereits in verschiedenen Projekten bewährt, um Safety und Security gemeinsam zu betrachten, und zwar auf eine systematische und wiederholbare Weise.

Ungeachtet erster vielversprechender Anwendungen sind wir immer daran interessiert, unsere Co­-Engineering-Methoden weiterzuentwickeln und deren Generalisierbarkeit zu evaluieren. Daher freuen wir uns auf zukünftige Herausforderungen im Bereich des Safety-Security-Co-­Engineerings, denn nur ein cybersicheres System ist auch ein funktionssicheres System