EINBLICK IN AEGISSAFEFORGE: VON DER ITEM DEFINITION ZUM FREIGEGEBENEN TARA-ARTEFAKT

Die erste TARA in einem neuen Entwicklungsprogramm ist häufig der Punkt, an dem das Cybersecurity Engineering an Geschwindigkeit verliert.

Die Item Definition ist möglicherweise bereits vorhanden, während sich die Systemgrenzen noch verändern. Architekturinformationen sind über Diagramme, Anforderungen, Schnittstellenbeschreibungen und Lieferantendokumente verteilt. Assets müssen identifiziert, Bedrohungsszenarien entwickelt, Schwachstellen untersucht, Angriffspfade erstellt und Risiken bewertet werden, bevor das Team belastbare Entscheidungen zur Risikobehandlung treffen kann.

Die Herausforderung besteht nicht darin, eine Tabelle mit möglichst vielen Bedrohungen zu erstellen.

AegisSafeForge wurde für genau diesen Engpass entwickelt. Die Plattform behandelt eine TARA nicht als Aufgabe zur Dokumentenerstellung, sondern als gesteuerten Engineering Workflow: Der Produktkontext fließt in die Analyse ein, die KI schlägt strukturierte Artefakte vor, Lebenszyklusregeln steuern deren weiteren Verlauf, Engineering Fachkräfte überprüfen die Annahmen und Werte, und freigegebene Entscheidungen bleiben mit den nachfolgenden Aktivitäten verbunden.

Eine TARA beginnt mit dem Produkt, nicht mit einem leeren Prompt

Eine belastbare TARA setzt ein ausreichend klares Verständnis des betrachteten Items oder der betrachteten Komponente voraus.

Dazu gehören Systemgrenzen, Funktionen, Architektur, Schnittstellen, Kommunikationspfade, externe Abhängigkeiten, Betriebsumgebung, Annahmen und relevante Stakeholder. Ohne diesen Kontext kann selbst ein technisch plausibles Bedrohungsszenario nur wenig mit dem tatsächlichen Produkt zu tun haben.

In AegisSafeForge kann die TARA Generierung die Item Definition, anwendbare Referenzwerte und bereits vorhandene Analysezeilen aus dem Projekt Workspace verwenden. Die Generierungsanfrage enthält außerdem einen strukturierten Prompt Vertrag, der Folgendes definiert:

Das Modell wird somit nicht aufgefordert, aus einem frei formulierten Prompt eine uneingeschränkte TARA zu erzeugen. Stattdessen soll es einen bestimmten Typ von Engineering Artefakt innerhalb der bereits durch die Plattform definierten Struktur und des vorhandenen Kontexts vorschlagen.

Dieser Unterschied ist entscheidend.

Ein allgemeiner Prompt kann eine plausibel wirkende Liste automobiler Cybersecurity Bedrohungen erzeugen. Ein gesteuerter Workspace kann überprüfbare Vorschläge hervorbringen, die mit dem entwickelten Produkt, der aktiven Analyse und dem tatsächlich verwendeten Schema verbunden sind.

Eine TARA ist eine Kette verbundener Schlussfolgerungen

Eine TARA ist nicht einfach eine Liste möglicher Angriffe.

Im Rahmen der [ISO/SAE 21434](https://www.iso.org/standard/70918.html) untersucht das Cybersecurity Risikomanagement, wie Cybersecurity Bedrohungen ein Item oder eine Komponente eines Straßenfahrzeugs und die zugehörigen Stakeholder beeinträchtigen könnten. Dafür ist üblicherweise eine zusammenhängende Argumentationskette über Assets, Schadensszenarien, Bedrohungsszenarien, Angriffspfade, Auswirkungen, Angriffsdurchführbarkeit, Risikoermittlung und Risikobehandlung erforderlich.

AegisSafeForge strukturiert den übergeordneten Cybersecurity Workflow anhand miteinander verbundener Artefakttypen. Dazu gehören:

Der Workspace umfasst darüber hinaus Schwachstellenmanagement, Cybersecurity Ereignisse und Incident Response Planung.

Diese Artefakte sind miteinander verbunden, aber nicht austauschbar. Ein Asset beschreibt etwas Schützenswertes. Ein Bedrohungsszenario beschreibt eine mögliche Beeinträchtigung. Eine Schwachstelle stellt eine Schwäche dar, die ausgenutzt werden könnte. Ein Angriffspfad beschreibt, wie eine Bedrohung realisiert werden könnte. Das daraus resultierende Risiko bildet anschließend die Grundlage für Risikobehandlung, Ziele, Anforderungen, Controls und Verifikation.

Was die KI tun darf

Der Assistent ist besonders dort hilfreich, wo Cybersecurity Fachkräfte durch Recherche, Wiederholungen und die Arbeit auf einer leeren Ausgangsbasis Zeit verlieren.

Kandidaten für Artefakte vorschlagen. Das System kann die Item Definition, bestehende TARA Inhalte und verfügbare Referenzwerte verwenden, um strukturierte Kandidaten für bestimmte Teile der Analyse zu generieren.

Bedrohungsszenarien und Angriffspfade entwerfen. Die KI kann erste Beschreibungen und Begründungen erstellen, die von Engineering Fachkräften überprüft, hinterfragt und weiterentwickelt werden.

Bei der Identifizierung möglicher Abdeckungslücken helfen. Bestehende Artefakte können als Generierungskontext bereitgestellt werden. Dadurch kann der Assistent berücksichtigen, was bereits analysiert wurde, anstatt bei jeder Anfrage wieder bei null anzufangen.

Engineering Sprache vereinheitlichen. Schemageführte Ausgaben unterstützen Teams dabei, Felder, Terminologie und Beziehungen über verschiedene Mitwirkende und Review Zyklen hinweg konsistenter zu halten.

Inhalte für das Review vorbereiten. Anstatt generierte Inhalte lediglich als Antwort darzustellen, überführt die Plattform sie in denselben Lebenszyklus, der auch für manuell erstellte Engineering Artefakte gilt.

Bei diesen Ausgaben handelt es sich um Vorschläge. Ihr Zweck besteht darin, die Analyse zu beschleunigen und Engineering Fachkräften eine konkrete Grundlage für das Review zu geben, nicht darin, automatisch freigegebene Cybersecurity Entscheidungen zu erzeugen.

Was die KI nicht entscheiden darf

Ein überzeugend formuliertes Bedrohungsszenario ist nicht zwangsläufig glaubwürdig. Ein Angriffspfad, der technisch möglich klingt, ist in der tatsächlichen Architektur nicht automatisch durchführbar.

Die KI darf daher nicht stillschweigend entscheiden:

AegisSafeForge kann strukturierte Risikowerte speichern und dem Analyse und Generierungsworkflow Referenzwerte nach ISO/SAE 21434 zur Verfügung stellen. Die aktuelle TARA Implementierung verwendet jedoch keine dedizierte integrierte Risikomatrix Engine, die automatisch die endgültige Risikoentscheidung trifft.

Diese Verantwortung verbleibt bei der zuständigen Cybersecurity Fachkraft.

Diese Grenze ist wichtig, da eine Risikoentscheidung Auswirkungen auf Architektur, Anforderungen, Entwicklungsaufwand, Verifikationsumfang und Aktivitäten nach der Produktion haben kann. Sie darf nicht an ein Sprachmodell delegiert werden, nur weil die generierte Begründung plausibel erscheint.

Der Review Status ist Teil des Artefakts

Ein TARA Artefakt in AegisSafeForge umfasst mehr als die in einer Tabelle sichtbaren Inhalte.

Jedes Artefakt besitzt eine Lebenszyklus und Governance Struktur. Diese enthält Status, Provenienz, Traceability, Validierungsstatus, Versionsinformationen, Ersteller, Bearbeiter, Freigebenden, Freigabezeitpunkt und Statushistorie.

Ein Artefakt kann unter anderem folgende Zustände durchlaufen:

Dabei handelt es sich nicht nur um visuelle Kennzeichnungen. Das Backend legt fest, welche Übergänge zwischen den Zuständen zulässig sind, und validiert vor der Freigabe die erforderlichen Felder des jeweiligen Artefakts.

Dadurch wird die menschliche Entscheidung sichtbar. Reviewer können einen von der KI generierten Vorschlag von benutzererstellten Inhalten unterscheiden, erkennen, was bearbeitet wurde, sehen, ob Änderungen angefordert wurden, und nachvollziehen, wer das Artefakt abschließend freigegeben hat.

Die Freigabe hängt von der Engineering Kette ab

Eine häufige Schwäche tabellenbasierter TARAs besteht darin, dass einzelne Zeilen vollständig wirken können, obwohl die zugrunde liegende Analyse fehlt oder noch nicht freigegeben wurde.

AegisSafeForge verwendet abhängigkeitsbasierte Freigaberegeln, um dies zu verhindern.

Ein Angriffspfad kann beispielsweise erst freigegeben werden, wenn er auf eine freigegebene Schwachstelle verweist, die demselben Bedrohungsszenario zugeordnet ist. Ein Risiko kann erst freigegeben werden, wenn es auf einen freigegebenen Angriffspfad mit passenden Beziehungen zum Bedrohungsszenario und zur Schwachstelle verweist.

Der Workflow prüft somit nicht nur, ob das aktuelle Artefakt ausgefüllt wurde. Er kontrolliert auch, ob die unterstützenden Engineering Artefakte einen akzeptablen Status erreicht haben.

Dadurch entsteht eine belastbarere Kette:

Die Plattform ist weiterhin auf Engineering Fachwissen angewiesen, um zu beurteilen, ob die Inhalte fachlich korrekt sind. Sie ergänzt jedoch eine strukturelle Durchsetzung, die verhindert, dass nachgelagerte Artefakte freigegeben werden, solange ihre erforderliche Grundlage noch nicht geklärt ist.

Traceability beginnt bei der Item Definition

Die aktuelle Implementierung verknüpft die Item Definition ausdrücklich mit den daraus abgeleiteten TARA Assets.

Diese Beziehung wird als „derived from“ beziehungsweise „abgeleitet von“ dargestellt. Sie kann nach einer Änderung der übergeordneten Item Definition eine erneute Freigabe erfordern und die weitere Generierung abgeleiteter Artefakte verhindern, solange das erforderliche Quellartefakt nicht freigegeben ist.

Das ist wichtig, weil eine TARA veralten kann, ohne dass sie direkt bearbeitet wurde.

Eine neue externe Schnittstelle, ein geändertes Kommunikationsprotokoll, eine veränderte Systemgrenze oder eine andere Lieferantenkomponente können die Assets und Annahmen verändern, auf denen die Analyse basiert. Bleiben diese vorgelagerten Änderungen von der TARA getrennt, kann die Analyse weiterhin vollständig erscheinen, obwohl sie das Produkt nicht mehr korrekt repräsentiert.

Indem AegisSafeForge Traceability und Lebenszyklusregeln direkt mit den Artefakten verbindet, wird die Änderungsfolgenanalyse zunehmend zu einem Bestandteil des normalen Workflows und nicht zu einer nachträglichen Dokumentationsaufgabe.

Mit der Freigabe endet die TARA nicht

Eine TARA wird erst dann wirksam, wenn ihre Entscheidungen die weitere Entwicklung beeinflussen.

Freigegebene Risiken und Entscheidungen zur Risikobehandlung sollten in Cybersecurity Ziele, Anforderungen, Controls, Claims und Verifikationsaktivitäten überführt werden. Der TARA Workspace der Plattform bildet diese bereits als miteinander verbundene Stufen des übergeordneten Cybersecurity Engineering Lebenszyklus ab.

Dieser Lebenszyklus setzt sich nach der Freigabe des Produkts fort. Schwachstellenmanagement, die Behandlung von Cybersecurity Ereignissen und die Incident Response Planung bleiben miteinander verbundene Themen, da neue Schwachstellen und Informationen aus dem Feld die während der Entwicklung getroffenen Annahmen infrage stellen können.

Auch die UN Regelung Nr. 155 betont die Identifizierung und Behandlung von Cybersecurity Risiken sowie die Überprüfung der Wirksamkeit der implementierten Maßnahmen über den gesamten Fahrzeuglebenszyklus hinweg.

Das Ergebnis, auf das wir hinarbeiten

Unser Ziel ist nicht, einen Chatbot zu entwickeln, der eine TARA „durchführt“.

Unser Ziel ist es, die Entwicklung, Überprüfung, Pflege und Begründung einer TARA zu vereinfachen.

AegisSafeForge unterstützt Teams dabei, vom Produktkontext zu strukturierten Kandidaten für Engineering Artefakte zu gelangen, während von der KI generierte Inhalte innerhalb eines gesteuerten Lebenszyklus verbleiben. Die Schemavalidierung sorgt dafür, dass generierte Inhalte die erwartete Struktur einhalten. Statusübergänge machen Reviews sichtbar. Abhängigkeitsprüfungen schützen die Freigabekette. Traceability erhält die Beziehung zwischen der Item Definition und der daraus abgeleiteten Cybersecurity Analyse.

Die Plattform soll Arbeit dort beschleunigen, wo Unterstützung sinnvoll ist, und den Workflow genau an den Stellen verlangsamen, an denen fachliche Beurteilung entscheidend ist: Umfang, Anwendbarkeit, Durchführbarkeit, Risikobehandlung, Restrisiko und Freigabe.

So eingesetzt ist eine durch KI unterstützte TARA keine Abkürzung, mit der die methodische Disziplin der ISO/SAE 21434 umgangen wird. Sie ist ein gesteuerter Workflow, mit dem diese Disziplin konsistenter angewendet werden kann, mit weniger Aufwand beim Start und einer klareren Dokumentation darüber, wie jede Cybersecurity Entscheidung zustande gekommen ist.

Der nächste Artikel dieser Reihe betrachtet die Fragestellung aus einer übergeordneten Engineering Perspektive: Warum HARA und TARA nicht getrennt voneinander bleiben können, wenn Cybersecurity Bedrohungen Auswirkungen auf die funktionale Sicherheit haben können und Entscheidungen zur funktionalen Sicherheit neue Cybersecurity Risiken erzeugen können.