Die TARA kommt an. Leider als Text.

Ein Zulieferer schließt seine Threat Analysis and Risk Assessment (TARA) ab, und der OEM will sie sehen. Oft kommt sie als Excel-Datei an, manchmal als PDF. Lesen lässt sich darin alles: Assets, Schadensszenarien, Angriffspfade, Risiken.

Was fehlt, sind die Verbindungen. Welcher Angriffspfad führt zu welchem Risiko? Welcher Impact Level hängt an welcher Funktion? Im Modell des Zulieferers war das ein Verweis. In der Tabelle ist es Text in einer Spalte. Beim OEM baut dann jemand das Modell nach. Oder er liest nur und hakt ab.

Sergio Scabar hat 2025 in einer studentischen Arbeit an der Wrexham University nachgefragt, wie verbreitet das ist. Befragt wurden Leute aus OEMs, Zulieferern und Beratungen. 70 Prozent der 30 Befragten hatten beim Teilen von TARA-Daten schon Probleme mit Integrität oder Kompatibilität. Gut die Hälfte überträgt die Daten von Hand. Die Stichprobe ist klein, und wer bei so einer Umfrage mitmacht, kennt das Problem vermutlich schon. Als Richtung reicht es mir.

In diesem Artikel geht es um openXSAM, ein offenes Austauschformat für genau diese Daten. itemis hat das Format angestoßen und begleitet die Standardisierung in der Automotive Security Research Group (ASRG) bis heute beratend. Ich bin also nicht neutral.

Drei Begriffe vorab

• TARA: die Bedrohungs- und Risikoanalyse nach ISO/SAE 21434:2021. Sie verknüpft Assets, Schadensszenarien, Bedrohungsszenarien, Angriffspfade und Risiken. Wie das Schritt für Schritt geht, beschreibt meine Serie, die mit Was ist eine TARA? beginnt.
• Cybersecurity Interface Agreement: die Vereinbarung zwischen Kunde und Zulieferer darüber, wer welche Cybersecurity-Aktivität übernimmt und welche Arbeitsprodukte liefert.
• XSAM und openXSAM: XSAM ist das Austauschformat von itemis SECURE. openXSAM ist 2020 daraus als offenes, herstellerneutrales Format hervorgegangen und liegt heute bei der ASRG, einer offenen Community für Fahrzeugsicherheit.

Die Norm regelt den Prozess, nicht die Datei

ISO/SAE 21434 rechnet damit, dass eine TARA nicht in einem Haus entsteht. Kapitel 7 behandelt die verteilten Cybersecurity-Aktivitäten zwischen Kunde und Zulieferer, und im Interface Agreement steht, wer was liefert. Ein Dateiformat schreibt die Norm nicht vor. Das finde ich richtig. Sie regelt einen Engineering-Prozess, keine Schnittstelle.

Das Interface Agreement könnte ein Format festlegen. Dafür muss es aber eins geben, das beide Seiten lesen können, ohne dass einer das Werkzeug des anderen kauft. Solange es das nicht gibt, einigt man sich auf Excel.

Die Lieferkette ist auch nicht die einzige Grenze. Die Architektur kommt aus einem Modellierungswerkzeug. Testteams leiten aus den Risiken ihre Testpläne ab. Im Betrieb will das Security Operations Center wissen, welche Risiken an welcher Schnittstelle hängen. Die openXSAM-Spezifikation nennt genau diese Fälle: Risikoinformationen teilen, Testpläne ableiten, Attack Surface Management und Detection & Response versorgen.

Der Scheinwerfer aus Annex H als Datei

openXSAM ist XML. Die Spezifikation teilt den Inhalt in Module: Item Definition, Bewertungsmodell, Analyse, Risiken und Maßnahmen.

Am Scheinwerfer aus Annex H der Norm sieht das so aus.

In der Item Definition stehen die Funktionen, etwa das Licht nach Schalterstellung ein- und auszuschalten und bei Gegenverkehr automatisch abzublenden. Dazu kommen die Komponenten: Lichtschalter, Body-Control-Steuergerät, Kamera-Steuergerät und der Aktor, der den Scheinwerfer schaltet. Und die Datenflüsse, darunter die Lichtanforderung an diesen Aktor. Jede Komponente verweist auf die Daten, die sie speichert, und auf die Funktionen, die sie trägt.

Das Bewertungsmodell reist mit: die Impact-Stufen, das Feasibility-Modell und die Risikomatrix, die aus beiden einen Risikowert macht. Das klingt nach Beiwerk. Ich halte es für den wichtigsten Teil der Datei. Im zweiten Teil meiner TARA-Serie ging es darum, dass eine Schadensstufe wie “major” nur innerhalb eines Bewertungsmodells etwas bedeutet. Ohne das Modell weiß der OEM nicht, auf welcher Skala der Zulieferer gemessen hat. Mit ihm kann er es nachlesen.

In der Analyse steht das Schadensszenario: die Frontalkollision mit einem Baum, weil bei Nachtfahrt das Licht ausgeht. Dazu das Bedrohungsszenario, eine gefälschte Lichtanforderung. Und die Angriffsschritte. Der Angreifer kompromittiert das Navigationssteuergerät über die Mobilfunkschnittstelle, das Gateway leitet die gefälschten Signale an den Aktor weiter. Jeder Schritt verweist auf das, was er vorbereitet. Welche Bedrohungen ein Security Objective gefährden, steht in der Datei als logischer Ausdruck mit “und” und “oder”. Der Angriffsbaum kommt also als Struktur an und nicht als Bild davon.

itemis hat dieses Beispiel 2021 als XSAM-Datei veröffentlicht, damals noch aus dem Normentwurf. Die Datei war ein Vorschlag, wie Funktionen, Komponenten, Datenflüsse und Daten im offenen Format aussehen könnten. Sie enthält nur die Item Definition und ist schlanker als der heutige Annex H: Kamera-Steuergerät und automatisches Abblenden fehlen. Zum Nachlesen hängt sie an diesem Artikel: ISO21434_G_ItemDefinition.xsam (XML, 10 KB).

Was ein Austauschformat im Alltag braucht

Ein Austauschformat scheitert aus meiner Sicht selten am Datenmodell. Eher scheitert es am zweiten Import. Drei Entscheidungen im Format zielen genau darauf.

Verweise über Namen. Elemente verweisen über Namen aufeinander, nicht nur über IDs. Der Verweis auf einen Bewertungsfaktor lautet dann name/FeasibilityCategory/TIME statt einer kryptischen ID. Solche Verweise bleiben gültig, wenn sich das Bewertungsmodell drumherum ändert.

Externe IDs. Jedes Element kann die ID aus dem System mitbringen, aus dem es stammt. Wer seine Architektur aus einem Modellierungswerkzeug übernimmt, behält dessen IDs. Der zweite Import aktualisiert dann die vorhandenen Elemente, statt sie zu verdoppeln.

Erweiterungen. Herstellerspezifisches kommt in einen eigenen XML-Namespace. Der Kern bleibt für alle lesbar, und wer die Erweiterung nicht kennt, überliest sie.

Teilaktualisierungen, vorerst nur als Idee. Der Vorschlag, mit dem itemis 2020 für die Initiative geworben hat, sah vor, dass eine Datei nur Änderungen enthält und alles andere unverändert bleibt. Sein Beispiel: Eine Threat-Intelligence-Datenbank setzt für einen Man-in-the-Middle-Angriff den Zeitfaktor auf “Stunden” und schickt nur diese eine Änderung. In die Spezifikation 1.0 hat es das nicht geschafft. Ich hoffe, die Idee kommt wieder. Mit ihr würde aus einem Format für Übergaben eins für laufende Änderungen.

Von XSAM zur ASRG

Die Geschichte ist kurz. XSAM entstand im Forschungsprojekt SecForCARs und wurde das Austauschformat von itemis SECURE, damals noch YAKINDU Security Analyst. 2020 hat itemis daraus eine offene Initiative gemacht, mit eigener Website und Partnern aus Testhäusern, Forschung und Industrie. 2022 wurde openXSAM ein Technical Committee der ASRG. Ende 2023 erschien die Spezifikation in Version 1.0, kurz darauf folgten die XML-Schemas. Beides liegt öffentlich im GitHub-Repository der ASRG.

Warum gibt ein Werkzeughersteller sein Format ab? Ein Austauschformat, das einem Hersteller gehört, bleibt am Ende eine Exportfunktion. Kein Wettbewerber baut einen Import für das Format eines anderen. Bei einem neutralen Gremium gibt es dafür wenigstens eine Chance.

Inzwischen greifen andere das Format auf. 2025 haben Forscher der UESTC in Chengdu und der Firma GoGoByte es als “OpenXSAM++” erweitert. Damit beschreiben sie Fahrzeugkonfigurationen so genau, dass ein LLM-gestütztes System daraus Angriffsbäume erzeugen kann. Ob diese Erweiterungen in den Standard zurückfließen, weiß ich nicht. Mich freut trotzdem, dass jemand das Format als Grundlage nimmt, statt ein eigenes zu erfinden.

Ohne Modell keine Verweise

Ein Austauschformat ist nur so gut wie das, was man hineinschreiben kann. Aus einer Tabelle lassen sich Zeilen exportieren. Verweise lassen sich nur exportieren, wenn es sie vorher gab. Ein Angriffsschritt, der in einer Excel-Zelle als Text auf “TS-12” zeigt, wird in XML wieder ein Text, der auf “TS-12” zeigt.

Der Nutzen von openXSAM hängt also daran, dass die TARA vorher ein Modell war. In itemis SECURE ist sie das: Assets hängen an Elementen der Item Definition, Angriffsschritte an Bedrohungsszenarien, und das Werkzeug berechnet Impact Level und Attack Feasibility. Über XSAM importiert und exportiert das Werkzeug das vollständige Analyse- und Bewertungsmodell, die Verweise eingeschlossen.

Eine TARA, die mit der Freigabe stehen bleibt, nützt im Feld wenig. Neue Schwachstellen und Angriffstechniken ändern Bewertungen laufend. Innerhalb eines Werkzeugs rechnet das Modell die Folgen nach. Über Firmengrenzen hinweg geht das nur, wenn die Änderung in einer Form ankommt, die das andere Werkzeug versteht. Ein offenes Format ist dafür die Voraussetzung.

Fazit

openXSAM löst ein klar umrissenes Problem. Es bringt TARA-Inhalte samt ihren Verweisen und ihrem Bewertungsmodell von einem Werkzeug ins nächste. Es ist offen, liegt bei einem neutralen Gremium und lässt sich gegen veröffentlichte Schemas prüfen.

Und das Format entwickelt sich weiter. Gerade wird eine Erweiterung auf Basis von CycloneDX untersucht, dem offenen Standard für Software-Stücklisten (SBOM). Damit käme die TARA mit der Stückliste der Software zusammen, auf die sie sich bezieht.

Mein Rat wäre, das Format ins Interface Agreement zu schreiben, bevor die erste TARA übergeben wird. Und vorher einmal einen Austausch mit den beteiligten Werkzeugen auszuprobieren. Eine Datei, die einmal hin und zurück gelaufen ist, sagt mehr als jedes Datenblatt.

Wer sehen will, wie eine TARA aus itemis SECURE als Datei aussieht, erreicht mich auf LinkedIn oder über itemis.com.

Mich interessiert, wie das bei euch läuft: Wie kommen TARAs vom Zulieferer zum OEM? Als Excel, als PDF, über ein gemeinsames Werkzeug, oder schon als Datei, die sich importieren lässt?

Cyber Security bei itemis — Systematisches Security-Engineering für Automotive, IoT und Industry 4.0: Cyber Security →