SAFETY UND CYBERSECURITY BETREFFEN DASSELBE SYSTEM: WARUM HARA UND TARA VERBUNDEN WERDEN MÜSSEN

Ein Bremssteuergerät weist verdächtigen Netzwerkverkehr zurück. Das Cybersecurity-Team sieht darin eine sinnvolle Maßnahme zur Eindämmung eines Angriffs. Das Safety-Team fragt, was geschieht, wenn gleichzeitig gültige Bremsanforderungen zurückgewiesen werden. Beide Fragen betreffen dasselbe Fahrzeugverhalten. Getrennte Analysen können diese Wechselwirkung jedoch übersehen. HARA und TARA zu verbinden bedeutet, sie ausdrücklich zu untersuchen, bevor eine Schutzmaßnahme zur verbindlichen Architekturentscheidung wird.

Dieser Beitrag schließt die konzeptionelle Verbindung zwischen unseren bereits veröffentlichten Artikeln zu den HARA- und TARA-Workflows. Die jeweiligen Analyseabläufe erläutern die beiden Fachbeiträge. Den Hintergrund zur Governance beschreibt der Beitrag zum Prinzip, dass KI Vorschläge erstellt, die Plattform den Prozess steuert und Menschen entscheiden. Hier geht es um die fachliche Beziehung zwischen den Analysen. Die Umsetzung folgt im nächsten Artikel.

Mit einem abgestimmten Systemkontext beginnen

Die gemeinsame Entwicklung von Safety und Cybersecurity beginnt mit einer abgestimmten Beschreibung des Items: Funktionen, Grenzen, Schnittstellen, Betriebsarten und Abhängigkeiten. Die Analysen benötigen teilweise unterschiedliche Detailinformationen. Für die TARA sind Angriffsflächen und Vertrauensgrenzen relevant, für die HARA Fehlverhalten und Betriebssituationen. Beide Sichten sollten einen konsistenten Systemstand beschreiben. Unterschiedliche Analyseumfänge brauchen ausdrücklich dokumentierte Ergänzungen.

Halten Sie Annahmen zu externen Diensten, Kommunikation, Energieversorgung, Fahrerinteraktion und eingeschränktem Betrieb fest. Nimmt ein Team einen unabhängigen Bremspfad an, während das andere sämtliche Befehle über ein Gateway führt, besteht ein fachlicher Widerspruch. Klären Sie ihn oder dokumentieren Sie ihn als offene Annahme mit einer verantwortlichen Person. Ein gemeinsamer Systemumfang bedeutet nicht, jedes Cybersecurity-Thema in die Safety-Analyse aufzunehmen.

Der von NIST veröffentlichte Bericht der Cyber-Physical Systems Public Working Group bietet dafür eine hilfreiche konzeptionelle Grundlage. Er betrachtet das Zusammenwirken physischer und digitaler Komponenten und behandelt Safety, Security, Zuverlässigkeit und Resilienz im Kontext der Vertrauenswürdigkeit sowie zeitliche Aspekte. Diese Perspektive begründet hier die Verbindung der Analysen. Sie legt weder ein automobilbezogenes Konformitätsverfahren fest noch schreibt sie das hier vorgeschlagene Beziehungsmodell vor.

Die Risikomethoden bleiben eigenständig

HARA und TARA beantworten unterschiedliche technische Fragen. Eine HARA betrachtet ein Gefährdungsereignis in seiner Betriebssituation und begründet anhand von Schweregrad, Exposition und Beherrschbarkeit eine Safety-Einstufung. Die Exposition betrifft diese Situation. Sie beschreibt nicht die Wahrscheinlichkeit eines erfolgreichen Angriffs. Eine TARA betrachtet plausible Bedrohungen, mögliche Schadensauswirkungen und Angriffsdurchführbarkeit, um Cybersecurity-Risikoentscheidungen zu begründen. Das Entwicklungsteam muss die für sein Projekt geltenden Bewertungsregeln und Begriffe anwenden.

Eine Verbindung zwischen Szenarien überträgt relevanten Kontext, keine numerische Einstufung. Leiten Sie aus einem ASIL keine Cybersecurity-Risikostufe ab, ersetzen Sie Exposition nicht durch Angriffsdurchführbarkeit und bilden Sie keinen gemeinsamen Score. Eine sicherheitsrelevante Folge kann die Bewertung der Cybersecurity-Auswirkungen informieren. Das Cybersecurity-Team muss diese Bewertung dennoch selbst begründen. Ebenso kann ein Bedrohungsszenario eine Safety-Annahme infrage stellen, ohne automatisch eine freigegebene HARA-Einstufung zu ändern.

Ein hypothetischer Konflikt in der Bremssteuerung

Betrachten wir ein vollständig hypothetisches Fahrzeug mit einem vernetzten Bremssteuergerät, einem Gateway und einem separat realisierten lokalen Bremspfad. Für das Beispiel fordert das Safety-Konzept eine angemessene Bremsreaktion innerhalb von 20 Millisekunden nach einer gültigen lokalen Anforderung. Dieser Wert ist frei gewählt. Er ist weder eine Normanforderung noch eine Empfehlung für ein reales Fahrzeug.

Die HARA betrachtet eine unzureichende Verzögerung, wenn der Fahrer beim Annähern an stehenden Verkehr bremst. Das Team bewertet Schweregrad, Exposition und Beherrschbarkeit für die definierte Situation und dokumentiert die resultierende Einstufung. Wir vergeben hier bewusst keine S-, E-, C- oder ASIL-Werte. Geschwindigkeit, Straßenbedingungen, verfügbare Bremswirkung und Fahrerreaktion benötigen dafür eine belastbare, auf das konkrete Item bezogene Grundlage.

Die TARA untersucht, ob ein kompromittiertes Gateway Befehle einschleusen oder erneut abspielen könnte, die die Bremssteuerung beeinträchtigen. Die Kausalkette gilt unter bestimmten Voraussetzungen: Der Angreiferzugriff ermöglicht eine Befehlsmanipulation, akzeptierte Befehle beeinflussen das Steuergeräteverhalten, und dieses Verhalten kann in der relevanten Situation zu unzureichender Verzögerung beitragen. Authentifizierung, Aktualitätsprüfungen, Arbitrierung und der lokale Pfad können die Kette unterbrechen. Jede behauptete Unterbrechung braucht Nachweise.

Angenommen, eine vorgeschlagene Cybersecurity-Maßnahme sperrt nach wiederholten Authentifizierungsfehlern die gesamte Befehlsverarbeitung für 100 Millisekunden. Blockiert diese Sperre auch gültige lokale Anforderungen, widerspricht sie der hypothetischen Reaktionsanforderung von 20 Millisekunden. Betrifft sie ausschließlich Netzwerkanforderungen und bleibt der lokale Pfad verfügbar, kann der direkte Konflikt entfallen. Gemeinsame Abhängigkeiten bei Ablaufplanung, Speicher oder Energieversorgung könnten diese scheinbare Trennung dennoch unwirksam machen.

Safety-Randbedingungen prägen die Schutzmaßnahme

Die gemeinsame Entwicklungsentscheidung besteht darin, den Wirkungsbereich der Sperre genau zu bestimmen und Alternativen zu bewerten. Das Team könnte den nicht vertrauenswürdigen Netzwerkzugang isolieren, den Authentifizierungsaufwand begrenzen, lokale Anforderungen priorisieren oder Wiederholungen beschränken, ohne wesentliche Steuerungsfunktionen auszusetzen. Das sind mögliche Entwurfsentscheidungen, keine validierten Lösungen. Jede verändert Angriffswiderstand, Ressourcenverbrauch oder Verhalten im eingeschränkten Betrieb und muss daher aus beiden fachlichen Perspektiven geprüft werden.

Zeitverhalten ist nur eine Randbedingung. Verfügbarkeitsanforderungen bestimmen, welche Funktionen während der Eindämmung nutzbar bleiben müssen. Anforderungen an den sicheren Zustand legen fest, welches Verhalten in der jeweiligen Betriebssituation akzeptabel ist. Einen Aktuator abzuschalten ist während der Fahrt nicht automatisch sicher. Mit nicht vertrauenswürdigen Eingaben weiterzuarbeiten ist ebenfalls nicht automatisch akzeptabel. Beschreiben Sie Übergang, verbleibende Funktionalität, Fahrerinformation und Wiederherstellungsbedingungen, statt lediglich einen sicheren Zustand zu benennen.

Die Verifikation sollte die Wechselwirkung gezielt prüfen: gültige Anforderungen bei bösartigem Netzwerkverkehr, maximale Authentifizierungslast, Erkennungsverzögerungen, Kommunikationsverlust und Wiederherstellung nach der Eindämmung. Messen Sie das relevante Reaktionsintervall unter definierten Bedingungen gegen die festgelegte Anforderung. Bestätigen Sie die Unabhängigkeit des lokalen Pfads, wenn die Argumentation darauf beruht. Ein Test des nominalen Zeitverhaltens oder ein isolierter Penetrationstest belegt nicht die gesamte fachübergreifende Argumentation.

Jede Beziehung muss erklärbar sein

Eine brauchbare Beziehung beschreibt ihre Bedeutung. Ein Bedrohungsszenario kann Fehlverhalten verursachen oder dazu beitragen. Ein Cybersecurity-Ziel kann ein Safety-Ziel unterstützen. Eine Schutzmaßnahme kann eine funktionale oder technische Safety-Anforderung einschränken. Dokumentieren Sie Richtung, Begründung, betroffene Betriebsarten und Voraussetzungen. Eine Bedrohung kann mehrere gefährliche Ereignisse beeinflussen. Ein gefährliches Ereignis kann mehrere bösartige oder nicht bösartige Einflussfaktoren haben.

Die Nachweise müssen eindeutig identifizierbar und versioniert bleiben: Schnittstellenspezifikationen, Architekturzuordnungen, Zeitbudgets, Abhängigkeitsanalysen und Testergebnisse. Unterscheiden Sie eine zunächst angenommene Beziehung von einer durch geprüfte Nachweise gestützten Beziehung. Eine fehlende Verbindung kann eine Lücke aufzeigen. Sie kann aber auch begründet sein, etwa wenn ein Szenario die Vertraulichkeit betrifft und keine plausible Safety-Folge hat. Dokumentieren Sie die Begründung, statt viele Verknüpfungen mit Vollständigkeit gleichzusetzen.

Änderungen aus beiden Perspektiven prüfen

Änderungen am Gateway, am Timeout, am Authentifizierungsverfahren oder am eingeschränkten Betriebsmodus können Annahmen beider Disziplinen entkräften. Eine gemeinsame Änderungsprüfung sollte betroffene Szenarien, Ziele, Anforderungen und Nachweise bestimmen und fachliche Prüfungen zuweisen. Im Beispiel verlangt eine längere Sperrdauer eine erneute Betrachtung der Bremsverfügbarkeit und der Cybersecurity-Risikobehandlung, selbst wenn die ursprünglichen HARA-Einstufungen weiterhin angemessen sind.

Bewahren Sie die frühere Entscheidung auf und dokumentieren Sie, warum sie gültig bleibt oder überarbeitet werden muss. Die Zustimmung zu einer Beziehung gibt keine der zugrunde liegenden Analysen frei. Der nächste Beitrag zur Umsetzung kann darauf aufbauen: konsistenter Systemumfang, ausdrückliche Kausalargumentation, eigenständig begründete Risikoentscheidungen und Nachweise, die auch bei Architekturänderungen belastbar bleiben.