Durchgängige Absicherung und lückenlose Traceability für Cybersecurity, Functional Safety und den Cyber Resilience Act
Zur Übersichtsseite
Methodische Exzellenz und maßgeschneiderte Werkzeuge für die modellbasierte System- und Softwareentwicklung.
Zur Übersichtsseite
Enterprise-Software aus einer Hand: AI-Integration, Legacy-Migration und Full-Stack-Entwicklung — kosteneffizient und souverän gehostet.
Zur Übersichtsseite
Jens Bühl
8 Min. Lesezeit
Die Item Definition ist der Schritt einer Threat Analysis and Risk Assessment (TARA) nach ISO/SAE 21434, den ich in der Praxis am häufigsten unterschätzt sehe. Dabei nennt die Norm für die eigentliche Risikoanalyse genau eine Voraussetzung: die Item Definition als Arbeitsergebnis. Trotzdem stecken viele Projekte nur ein paar Stunden hinein, in die Bedrohungsanalyse dagegen Wochen. Aus meiner Erfahrung entscheidet sich aber genau hier, wie gut eine TARA überhaupt werden kann, lange bevor das erste Bedrohungsszenario geschrieben ist.
Die Norm verlangt an dieser Stelle genau drei Dinge: die Item Boundary, die Funktionen des Items und eine vorläufige Architektur. Item Boundary meint die Grenze, die das Item, also das System oder den Verbund von Bauteilen, der eine Funktion auf Fahrzeugebene umsetzt, von seiner Umgebung trennt, beschrieben über die Schnittstellen zu anderen Items im Fahrzeug und zu Systemen außerhalb. Die vorläufige Architektur ist die vorläufige innere Struktur des Items: aus welchen Komponenten es besteht, wie sie verbunden sind, welche Daten fließen und gespeichert sind und welche Schnittstellen nach außen führen. Modellbasiert beschreibt man sie über fünf Elementtypen: Funktionen, Komponenten, Kanäle, Datenflüsse und Daten.
Dazu kommt die Beschreibung der cybersecurity-relevanten Gegebenheiten und Annahmen, auf die man sich stützt. Das Normbeispiel für eine solche Annahme finde ich sprechend: dass jede PKI-Zertifizierungsstelle, auf die sich das Item verlässt, ordentlich betrieben wird. Wo diese Annahmen am Ende leben, ist aus meiner Sicht zweitrangig; in der Praxis hängen sie oft nicht am Item selbst, sondern dort, wo sie wirken, nämlich an den Szenarien und Bewertungen der Analyse. Entscheidend ist, dass sie dokumentiert und mit der Analyse verknüpft sind.
Die Norm stellt diesen Schritt nicht zufällig an den Anfang: jeder folgende baut darauf auf. Assets sind Elemente des Items. Bedrohungsszenarien verletzen Sicherheitseigenschaften dieser Assets. Angriffspfade laufen entlang der Kanäle und Schnittstellen, die die Architektur beschreibt. Und die Verifikation der Analyse prüft ausdrücklich deren Vollständigkeit gegenüber der Item Definition. Vollständigkeit lässt sich nur an einem definierten Item messen. An einem unscharfen Item gemessen ist jede Analyse “vollständig”, und genau das ist das Problem.
Die Norm kennt übrigens eine Hintertür, und die hat einen Preis. Wenn der Item Definition Informationen fehlen, darf die Analyse mit Annahmen arbeiten. Aber: stützt sich die Entscheidung, ein Risiko zu akzeptieren, auf eine solche Annahme, verlangt die Norm einen dokumentierten Cybersecurity Claim. Eine Annahme, die nirgends festgehalten ist, ist ein nicht auditierbarer Claim, der nur noch nicht aufgefallen ist.
Die Abgrenzung des Analysegegenstands ist keine Eigenheit der Automobilwelt. Die IEC 62443-3-2 beginnt ihre Risikobewertung für industrielle Automatisierungssysteme mit demselben Schritt: erst das System under Consideration abgrenzen, welches dann in Zonen und Conduits zerlegt und bewertet wird. Im Bahnumfeld wird dieselbe Zonen-und-Conduits-Denke auf Sicherheitsarchitekturen angewandt. Und wer eine Risikoanalyse für den Cyber Resilience Act aufsetzt, braucht dieselbe Abgrenzung, bevor sich die erste Bedrohung sinnvoll benennen lässt: welches Produkt, welche Schnittstellen, welche Umgebung. Und dieses Modell ist nicht mal neu: Threat-Modeling-Werkzeuge wie das Microsoft Threat Modeling Tool zeichnen seit den frühen 2000ern Datenflussdiagramme mit Trust Zones, lange bevor ISO 21434 oder IEC 62443 diesen Schritt normativ verlangten.
Ich halte mich in diesem Artikel an die ISO 21434, weil sie diesen Schritt sehr klar beschreibt. Die Denkweise lässt sich trotzdem übertragen: was gleich zum Abstraktionsgrad, zur Auflösung und zum lebenden Modell kommt, gilt für eine Analyse nach IEC 62443 oder eine CRA-Risikoanalyse ganz genauso.
Die Frage höre ich oft, und die Antwort ist: ja, man darf. Man muss sogar. Die Item Definition ist keine Kopie der E/E-Architektur, und wer versucht, jedes Detail hineinzunehmen, analysiert am Ende die Dokumentation statt das Risiko.
Eine allgemeingültige Regel dafür habe ich nicht gefunden. In der Praxis prüft man oft so: ein Detail gehört in die Item Definition, wenn es ein Asset, ein Bedrohungsszenario, einen Angriffspfad oder eine Bewertung verändern kann. Kann es keines davon, ist es Architekturdokumentation, keine Item Definition.
Der Haken daran: jedes Weglassen ist eine stillschweigende Annahme. Und falsche Annahmen lassen echte Bedrohungen lautlos aus der Analyse fallen. Das sage nicht nur ich: Katja Tuma und Mathias Widman führen es in ihrem IEEE-Artikel zu den sieben Schmerzpunkten der TARA-Praxis als eigenes Problemfeld auf, denn der Abstraktionsgrad und die Annahmen dahinter gehören zu den schwersten Entscheidungen der ganzen Methode.
Genau hier zeigt sich der erste Vorteil eines modellbasierten Ansatzes. In einem Modell ist die Abstraktionsentscheidung explizit: die Grenze ist ein Element, Annahmen sind eigene Objekte, die an der Analyse hängen, und ein Reviewer sieht, was ausgeklammert wurde. In einem Diagramm, das als Bild in einem Dokument klebt, sind die Auslassungen unsichtbar.
Der Abstraktionstest von eben liefert eine Obergrenze. Das Schwachstellenmanagement liefert die Untergrenze, und über die wird seltener gesprochen.
Wenn morgen ein CVE aufschlägt, lautet die Frage: welche Komponente meines Items führt das betroffene Paket aus, und welche Bedrohungsszenarien und Angriffspfade berührt das? Um sie zu beantworten, muss sich eine Kette verfolgen lassen: Das CVE betrifft ein Software-Paket. Das Paket läuft auf einer Komponente des Items. Die Komponente hängt an Kanälen, über die Angriffspfade laufen. Und am Ende dieser Pfade stehen die Bedrohungsszenarien, deren Risiko jetzt neu zu bewerten ist. Jeden dieser Übergänge stellt die Item Definition entweder her, oder er fehlt. Modelliert sie das Steuergerät nur als einen einzigen Kasten, reißt die Kette gleich am ersten Übergang: das Paket findet keine Komponente, an der es andocken könnte, oder es fehlen Details, um den potentiellen Schaden konkret bewerten zu können.
Daraus folgt eine praktische Faustregel: nicht jede Bibliothek gehört in die Item Definition, aber die Komponenten müssen fein genug geschnitten sein, dass Einträge aus der SBOM, der Software Bill of Materials, also der Stückliste der verbauten Software-Pakete, an ihnen andocken können. Die SBOM bleibt in ihrem eigenen Werkzeug; das Item-Modell muss ihr nur stabile Ankerpunkte bieten. Das ist die Mindestauflösung, ab der sich der Weg vom CVE bis zum Risiko überhaupt nachverfolgen lässt.
Ein Fahrzeug-Item ändert sich: Architektur-Iterationen in der Entwicklung, danach Software-Updates über eine Fahrzeuglebensdauer von rund 25 Jahren im Feld. Die vorläufige Architektur aus der Item Definition ist genau das: vorläufig. Im Lauf der Entwicklung wird sie durch die tatsächliche Architektur abgelöst, oft mehrfach, und jede dieser Ablösungen betrifft dieselben Assets, Bedrohungsszenarien und Angriffspfade, die auf ihr aufgebaut sind. Die fortlaufenden Cybersecurity-Aktivitäten der ISO 21434 (Clause 8) und das CSMS nach UNECE R155 setzen voraus, dass neue Ereignisse gegen das aktuelle Item bewertet werden, nicht gegen den Stand aus der Konzeptphase.
Eine statische Item Definition, das Visio-Diagramm im PDF, entkoppelt sich innerhalb von Monaten von der Engineering-Realität. Das Tückische daran: jedes nachgelagerte TARA-Ergebnis erbt diese Drift stillschweigend. Die Analyse sieht weiterhin ordentlich aus, sie beschreibt nur ein Item, das es so nicht mehr gibt.
Konkret heißt das: die Item Definition sollte mit den führenden Ständen im Engineering synchron bleiben, also mit den Architekturmodellen und den Anforderungen, und eine Änderung dort sollte automatisch die Frage aufwerfen, ob sich die TARA ändert, statt dass die Frage erst beim nächsten Audit auffällt. In der Praxis sieht das oft anders aus: die Synchronisierung passiert manuell, unregelmäßig oder gar nicht, und genau darin liegt die Drift, die weiter oben beschrieben ist. Das muss nicht vom ersten Tag an perfekt laufen: ein Modell, das sich sauber reviewen lässt, ist der Anfang, und die Synchronisierung wächst mit dem Prozess.
Zieht man die Fäden zusammen, bleiben drei Dinge, die ein Modell kann und ein Dokument nicht:
Der für mich wichtigste Punkt kommt zum Schluss, weil er alle vorherigen trägt: eine maschinenlesbare Item Definition ist nicht bessere Buchhaltung, sie ist die Voraussetzung für alles Weitere.
Über eine API lässt sich die Architektur aus den Systems-Engineering-Werkzeugen importieren, statt sie von Hand nachzubauen. SBOM- und Schwachstellen-Feeds docken an den Komponenten an, und Anforderungen verlinken auf die Cybersecurity Goals, die aus der TARA entstehen.
Wo es diese saubere Werkzeugquelle nicht gibt, weil das Item älter ist als die eigene Systems-Engineering-Toolchain, hilft dieselbe KI-Anbindung an anderer Stelle: aus vorhandenen Bestandsdaten wie PDF-Spezifikationen oder Visio-Diagrammen lässt sich über MCP und LLM ein erster Entwurf der Item Definition erzeugen, den man danach reviewt und verfeinert, statt bei null anzufangen.
Und über einen MCP-Server, MCP steht für Model Context Protocol, eine Schnittstelle, über die KI-Assistenten strukturiert auf Werkzeugdaten zugreifen, wird das Modell für KI-Assistenten abfragbar. KI-Unterstützung ist nur so gut wie der Kontext, den sie befragen kann. Die Frage “welche Kanäle kreuzen die Item Boundary und transportieren personenbezogene Daten?” kann ein Assistent an einem Modell beantworten. Welche Rolle KI in der TARA-Arbeit am Ende spielt, wird sich zeigen. Sicher scheint mir: erst das Item-Modell bindet ihre Antworten an das tatsächliche System. Ohne Modell bleiben sie nur plausibel.
Eine Item Definition ist schnell zusammengefasst: Boundary, Funktionen, vorläufige Architektur. Auf dem Abstraktionsgrad, den die Analyse braucht. In der Auflösung, die das SBOM-Mapping braucht. Und perspektivisch als lebendes Modell statt als Diagramm im Anhang.
Wer das modellbasiert umsetzen will: itemis SECURE ist um genau diesen Ansatz herum gebaut, vom Item-Modell mit seinen Elementtypen über die berechnete Risikobewertung bis zum MCP-Server für KI-Assistenz. Wenn ihr sehen wollt, wie eine Item Definition darin aussieht, erreicht ihr mich direkt auf LinkedIn oder über itemis.com.
Im nächsten Teil geht es um die Asset Identification: ab wann ist ein Element des Items ein Asset, und wessen Schaden zählt eigentlich? Und wer vor der Tiefe erst den Überblick über die ganze Methode sucht, findet ihn in meinem Einführungsartikel Was ist eine TARA?.
Mich würde interessieren, wie ihr das handhabt: Überlebt eure Item Definition die nächste TARA-Revision, oder fangt ihr jedes Mal wieder mit einem leeren Diagramm an?
Product Owner
Excel-Vorlage für die CRA-Risikoanalyse: TARA nach ISO 21434 und IEC 62443 — wie man methodisch startet, was sich importieren lässt und wann Excel zum Engpass wird.
Zum Blog
Jens Bühl
5 Min. Lesezeit
Eine TARA ist kein Bedrohungskatalog, sondern ein Nachweis von Risikoentscheidungen — was dahintersteckt, wie der Ablauf aussieht und ab wann Excel an seine Grenzen stößt.
Zum Blog
Jens Bühl
5 Min. Lesezeit