EINBLICK IN AEGISSAFEFORGE: HARA UND TARA VERBINDEN UND IHRE ENTSCHEIDUNGEN GETRENNT HALTEN

Eine Fachkraft für Cybersicherheit ergänzt die Authentifizierung von Befehlen an einer Bremsschnittstelle. Eine Fachkraft für funktionale Sicherheit muss sicherstellen, dass Bremsanforderungen innerhalb einer festgelegten Reaktionszeit verarbeitet werden. Beide Entscheidungen können sinnvoll sein. Ihr Zusammenspiel bleibt jedoch möglicherweise unsichtbar, wenn die Teams getrennte Dokumente prüfen. Die konkrete technische Aufgabe lautet: feststellen, ob die Maßnahme ein gefährliches Verhalten verhindert, ob sie einen weiteren Fehlerpfad eröffnet und welche Nachweise diese Schlussfolgerungen tragen.

Der verbundene ASF-Workflow macht dieses Zusammenspiel durch kontrollierte Verknüpfungen prüfbar. Dieser Rundgang verwendet ein ausdrücklich hypothetisches Fahrzeug-Item und beispielhafte Kennungen. Er beschreibt den vollständig umgesetzten domänenübergreifenden Entwurf: Ingenieurteams arbeiten innerhalb eines gemeinsamen Item-Umfangs, verknüpfen ausgewählte Artefakte und prüfen die entstehenden Abhängigkeiten. HARA und TARA behalten dabei ihre eigenen Methoden, Bewertungen und Freigabeverantwortlichkeiten.

Mit demselben Item und einem plausiblen Ursache-Wirkungs-Pfad beginnen

Betrachten wir ein hypothetisches Item zur Bremssteuerung mit einem Gateway, das Anforderungen eines anderen Fahrzeugsteuergeräts annimmt. Die Item-Definition beschreibt die Schnittstelle, Betriebsarten, Vertrauensgrenze und Annahmen zur Nachrichtenverarbeitung. Die Teams für funktionale Sicherheit und Cybersicherheit verwenden denselben Item-Umfang und bestimmen die relevante Baseline, bevor sie eine Verknüpfung vorschlagen. Ähnliche Namen allein belegen nicht, dass zwei Artefakte dieselbe Funktion oder Konfiguration betreffen.

In der TARA beschreibt Bedrohungsszenario TS-17, wie ein Angreifer über einen kompromittierten Kommunikationspfad eine Bremsanforderung einschleust. In der HARA verbindet Gefährdungsereignis HE-08 unbeabsichtigtes Bremsen mit einer bestimmten Betriebssituation: Das Fahrzeug fährt, während ein anderes Fahrzeug mit geringem Abstand folgt. Die vorgeschlagene Verknüpfung hält fest, dass TS-17 das an HE-08 beteiligte Fehlverhalten verursachen kann, sofern die dokumentierten Annahmen zur Schnittstelle und zum Angreiferzugang gelten. Sie behauptet nicht, dass jede eingeschleuste Anforderung dieses Ereignis auslöst.

Diese Systemperspektive hat eine hilfreiche wissenschaftliche Grundlage. Das Framework for Cyber-Physical Systems des NIST beschreibt das Zusammenwirken digitaler, physischer und menschlicher Komponenten. Es gliedert die Analyse nach Gesichtspunkten wie Zeitverhalten, Vertrauenswürdigkeit, Systemgrenzen und Lebenszyklus. Diese Gesichtspunkte helfen, die Schnittstellendiskussion einzuordnen. Das Framework bestätigt weder die Gültigkeit unserer hypothetischen Verbindung zwischen Bedrohung und Gefährdung noch schreibt es den ASF-Freigabeworkflow vor.

Ziele verbinden, ohne Risikobewertungen umzurechnen

Das Team für funktionale Sicherheit formuliert Sicherheitsziel SG-04: unbeabsichtigtes Bremsen infolge des identifizierten Fehlverhaltens verhindern. Das Cybersicherheitsteam formuliert Cybersicherheitsziel CG-12: verhindern, dass unautorisierte Bremsanforderungen über die definierte Schnittstelle angenommen werden. Eine typisierte Zielverknüpfung dokumentiert, wie CG-12 unter den Szenarioannahmen SG-04 unterstützt. Verantwortung und Prüfung verbleiben für jedes Ziel in der jeweiligen Domäne.

Die HARA bewertet Schwere, Exposition und Beherrschbarkeit für ihr Gefährdungsereignis. Die TARA bewertet die Bedrohung und das zugehörige Risiko nach ihrer eigenen Bewertungsmethode. ASF erhält diese unabhängigen Entscheidungen. Eine Verknüpfung rechnet weder eine Cybersicherheitsrisikobewertung in einen ASIL um noch ersetzt sie eine fehlende Sicherheitsbewertung. Ändern sich die Betriebssituation oder die Angreiferannahmen, müssen Fachverantwortliche die betroffenen Schlussfolgerungen mit der jeweils passenden Methode erneut prüfen.

Unterstützung und Einschränkungen ausdrücklich dokumentieren

Die hypothetische funktionale Sicherheitsanforderung FSR-21 verlangt, unbeabsichtigte Bremsbetätigung durch ungültige Anforderungen zu verhindern. Die technische Sicherheitsanforderung TSR-33 legt die Validierung von Anforderungen und eine definierte Reaktion auf zurückgewiesene Eingaben fest. Cybersicherheitsanforderung CR-09 verlangt Authentifizierung und Aktualitätsprüfungen. Eine unterstützende Verknüpfung dokumentiert, warum CR-09 zu FSR-21 und TSR-33 beiträgt. Ihre Begründung benennt den konkreten Pfad für unautorisierte Eingaben, der damit behandelt wird.

Eine zweite Verknüpfung dokumentiert eine Einschränkung: Die Authentifizierungsverarbeitung muss in das zu TSR-33 gehörende Reaktionszeitbudget passen. Auch das Zurückweisen einer Nachricht erfordert eine sorgfältige Bewertung. Eine ungültige Anforderung und eine ausbleibende berechtigte Anforderung können unterschiedliche Systemreaktionen erfordern. Deshalb prüfen die Verantwortlichen Latenz, Ressourcenüberlastung und Rückfallverhalten gemeinsam. Keine dieser beispielhaften Anforderungen stellt einen validierten Bremsentwurf dar. Sie sollen Entscheidungen sichtbar machen, die abgestimmte Entwicklungsarbeit benötigen.

Eine zentrale Verknüpfung aus beiden Arbeitsbereichen prüfen

ASF speichert jede domänenübergreifende Verbindung als eine einzige maßgebliche, kontrollierte Verknüpfung. Wer TS-17 im Cybersicherheitsarbeitsbereich oder HE-08 im Arbeitsbereich für funktionale Sicherheit öffnet, erreicht dieselbe Verbindung zwischen Bedrohung und Gefährdung. Bidirektionale Rückverfolgbarkeit bedeutet, diesen gemeinsamen Datensatz von beiden Endpunkten aus aufzurufen. Sie macht die Kausalaussage nicht umkehrbar: Ein Gefährdungsereignis beweist nicht, dass ein bestimmter Angriff vorliegt.

Die Verknüpfung enthält ihren Typ, den gemeinsamen Item-Umfang, die Begründung, unterstützende Quellen und die Versionen ihrer Endpunkte. Im Beispiel verweist sie auf TS-17 Version 3 und HE-08 Version 2 sowie auf die relevante Item-Baseline. Außerdem dokumentiert sie die vorschlagende Person, zuständige Prüfende und den Prüfverlauf. Unterstützende Quellen können eine Schnittstellenspezifikation, eine Architekturentscheidung und eine Analysenotiz sein. Prüfende untersuchen deren Anwendbarkeit, statt einen Anhang bereits als ausreichende Begründung zu behandeln.

Eine Fachkraft kann die Verknüpfung manuell anlegen. Auch KI kann einen Kandidaten mit Begründung und Quellen zur Prüfung vorschlagen. Der Vorschlag bleibt offen, bis die zuständigen Fachverantwortlichen ihn freigeben. Prüfende können eine oberflächlich plausible Zuordnung ablehnen, weil die Betriebsart abweicht oder der angenommene Angriffspfad die Funktion nicht erreichen kann. Die dokumentierte Entscheidung bewahrt diese Überlegungen für spätere Prüfungen.

Mit der Matrix offene Fragen erkennen

Die domänenübergreifende Prüfmatrix führt relevante Bedrohungsszenarien, Gefährdungsereignisse, Ziele und Anforderungen in einer gemeinsamen Prüfansicht zusammen. Die Teams betrachten freigegebene Verbindungen, ausstehende Vorschläge und ungeklärte Beziehungen innerhalb des Items. Die Warteschlange für offene Lücken ermöglicht eine verantwortliche Weiterbearbeitung. Beispielsweise muss das Team klären, ob der Verlust gültiger Bremsanforderungen berücksichtigt wurde, bevor es den Sicherheitsbeitrag der Authentifizierungsmaßnahme akzeptiert.

Vollständigkeit erfordert ein fachliches Urteil über den definierten Umfang. Eine leere Matrixzelle kann auf eine fehlende Analyse hinweisen oder auf ein Zusammenspiel, das geprüft und als nicht relevant bewertet wurde. Eine gefüllte Zelle kann trotzdem eine schwache Begründung enthalten. Prüfende müssen freigegebene Anwendbarkeitsentscheidungen von offenen Lücken unterscheiden und ausstehende Nachweise benennen. Das Zählen von Verknüpfungen belegt keine angemessene Behandlung des Zusammenspiels von funktionaler Sicherheit und Cybersicherheit.

Nachweise gemeinsam nutzen und getrennt bewerten

Für das hypothetische Item schleust eine Verifikationskampagne unautorisierte Anforderungen ein, prüft Aktualitätskontrollen und misst Reaktionszeiten unter definierter Last. Der Ergebnisbericht kann sowohl die Cybersicherheitsanforderung als auch die technische Sicherheitsanforderung stützen. Jede Domäne dokumentiert anhand ihrer eigenen Akzeptanzkriterien, was der Bericht nachweist, einschließlich Testkonfiguration, Abdeckung und Einschränkungen. Ein bestandener Authentifizierungstest allein belegt kein akzeptables Bremsverhalten.

Gemeinsame Nachweise verringern den Aufwand, denselben Konfigurationskontext in getrennten Prüfungen erneut zusammenzutragen. Sie zeigen auch widersprüchliche Erwartungen frühzeitig: Eine Maßnahme kann bösartige Eingaben korrekt zurückweisen und dennoch das sicherheitsbezogene Zeitbudget überschreiten. Die Verknüpfung bietet einen Ort, um diesen Konflikt und seine Auflösung zu dokumentieren. Für Bedingungen außerhalb der Kampagne können weiterhin zusätzliche Analysen oder Tests erforderlich sein.

Änderungen als Anlass zur erneuten Prüfung behandeln

Nun ändert sich im Beispiel die Validierungsreihenfolge im Gateway-Entwurf. Dadurch entsteht CR-09 Version 4. Eine gegen Version 3 freigegebene Verknüpfung belegt keine geprüfte Anwendbarkeit auf den neuen Endpunkt. ASF kennzeichnet die betroffene Beziehung als veraltet und eröffnet eine domänenübergreifende Prüfaufgabe. Frühere Begründung, Endpunktversionen und Freigaben bleiben verfügbar. Freigegebene Ziele, Risikobewertungen und Anforderungen werden nicht stillschweigend umgeschrieben.

Die Prüfenden bewerten, ob die Änderung die Zurückweisung unautorisierter Anforderungen, das Zeitverhalten oder das Rückfallverhalten beeinflusst und ob bestehende Nachweise weiterhin anwendbar sind. Sie können die Verknüpfung mit aktuellen Versionen bestätigen, ihre Begründung überarbeiten oder sie ablehnen. Zugehörige Lücken bleiben sichtbar, bis sie durch Prüfung geklärt sind. Diese Änderungsfolgenanalyse zieht eine klare Entscheidungsgrenze: Eine erkannte Abhängigkeit löst fachliche Arbeit aus, entscheidet aber nicht über deren Ergebnis.

Vollständigkeits- und Exportfreigaben hängen von geprüfter Abdeckung, Verknüpfungsstatus und offenen Lücken im gewählten Umfang und in der gewählten Baseline ab. Veraltete oder ausstehende Verknüpfungen müssen geklärt werden, bevor sie als freigegebene Abdeckung dienen können. Die Exportvorbereitung macht deshalb den Prüfstand sichtbar, statt jede Verbindung als abgeschlossen darzustellen. Der technische Vorteil ist ein klarerer Weg von einer geänderten Schnittstelle zu verantwortlichen Entscheidungen und anwendbaren Nachweisen. Veröffentlichung, Releasefreigabe und jede Konformitätsaussage bleiben eigenständige menschliche Verantwortlichkeiten.