Was ist eine TARA? Und warum eine Tabelle irgendwann nicht mehr reicht

Was ist eine TARA?

TARA steht für Threat Analysis and Risk Assessment, also Bedrohungsanalyse und Risikobewertung. Es ist die zentrale Analysemethode der ISO/SAE 21434, und wenn ich sie in einem Satz erklären soll, dann so: eine TARA beantwortet strukturiert die Frage, was an einem Fahrzeug oder einer Komponente schützenswert ist, wie ein Angreifer es kompromittieren könnte, wie schlimm das wäre und was man dagegen tut.

Wichtig ist mir dabei ein Punkt, den ich oft missverstanden sehe. Eine TARA ist keine Liste gefundener Bedrohungen. Sie ist ein nachvollziehbarer Nachweis von Risikoentscheidungen. Der Unterschied klingt nach Wortklauberei, ist aber der Kern der Sache: eine Bedrohung zu benennen ist der erste Schritt, die Entscheidung darüber und ihre Begründung sind das eigentliche Arbeitsergebnis.

Warum ist eine TARA wichtig?

Der offensichtliche Grund ist regulatorisch. Für die Typgenehmigung nach UNECE R155 muss ein OEM nachweisen, dass er Cybersecurity-Risiken über den Lebenszyklus hinweg identifiziert und behandelt. Die TARA ist dabei der primäre technische Nachweis, den man vorlegt. Ohne belastbare TARA gibt es keine saubere R155-Typgenehmigung, und ohne die keine Zulassung des Fahrzeugs in den betroffenen Märkten.

Der Grund, der mir persönlich wichtiger ist: die TARA zwingt einen dazu, Sicherheit früh zu durchdenken, statt sie hinterher aufzukleben. Die ISO 21434 folgt dem V-Modell über den gesamten Entwicklungszyklus, und die TARA sitzt schon in der Konzeptphase (Clause 9). Wer erst nach der Implementierung über Angriffspfade nachdenkt, zahlt jede Designentscheidung doppelt. Security by Design ist kein Slogan, es ist schlicht billiger.

Die Schritte hin zu einer TARA

Eine TARA läuft in vier Schritten ab, die aufeinander aufbauen.

• Item Definition. Zuerst legt man fest, was überhaupt betrachtet wird: das Item mit seinen Funktionen, Daten, Komponenten, Kanälen und Datenflüssen, dazu die getroffenen Annahmen und die Systemgrenze. Ohne saubere Abgrenzung analysiert man ins Leere.
• Asset Identification & Impact Rating. Aus den Elementen werden Assets, sobald eine Sicherheitseigenschaft daran hängt, also Vertraulichkeit, Integrität oder Verfügbarkeit. Für die so qualifizierten Assets leitet man Schadensszenarien ab und bewertet, wie schwer der Schaden wäre, über Impact-Kategorien wie Safety, finanzielle, operative und Privatsphäre-Folgen. Das Ergebnis ist der Impact Level (IL).
• Threat Analysis. Jetzt fragt man, wie eine Sicherheitseigenschaft verletzt werden kann. Man leitet Bedrohungsszenarien und die zugehörigen Angriffsschritte ab, gestützt auf einen Threat- und einen Control-Katalog, und bewertet die Durchführbarkeit jedes Angriffs anhand von Faktoren wie Zeit, Fachwissen, Zugang und Ausrüstung. Das Ergebnis ist der Attack Feasibility Level (AFL), nicht aus dem Bauch geschätzt, sondern nach der Methodik der Norm.
• Determine Risks. Impact und Attack Feasibility ergeben zusammen über eine definierte Risikomatrix den Risk Level (RL). Für jedes Risiko trifft man dann eine Behandlungsentscheidung: reduzieren, vermeiden, teilen oder akzeptieren, jeweils mit den gewählten Maßnahmen oder einer Begründung für die Risikoübernahme.

Ein Detail, das gern untergeht: eingeführte Maßnahmen sind selbst wieder neue Assets, die geschützt werden wollen. Eine TARA ist deshalb iterativ, man dreht die Schleife, bis das Restrisiko vertretbar ist.

Ich habe eine TARA. Reicht das?

Nein. Und das ist keine Formalität.

Eine TARA ist ein lebendes Dokument (siehe Living TARA). Die ISO 21434 kennt dafür die fortlaufenden Cybersecurity-Aktivitäten (Clause 8): Monitoring, Bewertung neuer Ereignisse, Schwachstellenanalyse über den gesamten Lebenszyklus. Wenn morgen ein neues CVE in einer verbauten Komponente auftaucht, lautet die Frage nicht “gibt es eine Bedrohung”, denn eine Bedrohung gibt es immer. Die Frage ist: verändert dieses CVE den AFL auf einem Angriffspfad, der bisher als akzeptabel galt? Öffnet es einen Pfad, den die ursprüngliche Analyse nicht kannte?

Diese Frage kann man nur beantworten, wenn die ursprüngliche Entscheidung dokumentiert und wiederauffindbar ist. Sonst fängt man jedes Mal bei null an. Genau deshalb schreibt R155 die kontinuierliche Pflege vor. Eine TARA, die man einmal schreibt und ablegt, ist zum Zeitpunkt des ersten neuen Angriffs schon veraltet.

Reicht dafür nicht Excel?

Für den Anfang: ja, durchaus. Wer sich die Methode aneignet, ein kleines Item betrachtet oder ein Gefühl für die Bewertungslogik bekommen will, kommt mit einer Tabelle weit. Ich würde niemandem raten, für die erste Übung ein Werkzeug zu kaufen.

Der Punkt, an dem Excel kippt, ist nicht die erste TARA, sondern die zehnte Änderung an ihr. Sobald Angriffspfade sich über Komponenten hinweg fortpflanzen, sobald derselbe Asset in mehreren Szenarien auftaucht, sobald ein CVE eine Neubewertung an fünf Stellen gleichzeitig auslöst, wird die Tabelle zur Fehlerquelle. Konsistenz von Hand über hunderte Zeilen zu halten ist genau die Arbeit, die Menschen schlecht und Werkzeuge gut erledigen. Und die Nachvollziehbarkeit, wer wann was auf welcher Basis entschieden hat, bekommt man in einer Tabelle praktisch nicht sauber hin.

Für eine ernsthafte, prüffähige TARA empfehle ich deshalb Werkzeugunterstützung. itemis SECURE führt durch die Schritte, hält die Bewertungen von IL, AFL und RL konsistent, rechnet die Propagation über Angriffspfade und hält die Entscheidungshistorie fest. Es nimmt einem die Analyse nicht ab, das soll es auch nicht, aber es hält die Buchhaltung sauber, damit man sich auf die eigentlichen Entscheidungen konzentrieren kann.

Und was ist mit Threat Modeling?

Hier lohnt sich ein Blick zurück. Threat Modeling, also das systematische Durchdenken von Angreifern, Zielen und Angriffswegen, gibt es lange vor der ISO 21434. Aus der IT-Sicherheit kennt man Ansätze wie STRIDE oder Angriffsbäume seit Jahrzehnten, und die Methode, die die Norm inspiriert, geht auf Arbeiten wie MoRA am Fraunhofer AISEC zurück.

Die TARA erfindet Threat Modeling also nicht neu. Sie nimmt eine etablierte Disziplin und schnürt sie in einen normativen Rahmen: definierte Bewertungsskalen, eine feste Risikomatrix, geforderte Arbeitsergebnisse und die Pflicht zur Pflege über den Lebenszyklus. Threat Modeling ist die Denkweise, die TARA ist die auditierbare, für die Typgenehmigung taugliche Form davon. Wer schon Threat Modeling betreibt, hat den schwierigeren Teil bereits verstanden und muss sich nur noch un die Nachvollziehbarkeit im Sinne der ISO 21434 kümmern.

Fazit

Eine TARA ist eine strukturierte Bedrohungsanalyse mit einem festen Rahmen und einem klaren Zweck: nachvollziehbare Risikoentscheidungen, die einer R155-Prüfung standhalten und über den Lebenszyklus gepflegt werden. Sie beginnt bei der Item-Definition und endet nie ganz, weil sich die Bedrohungslage ständig verschiebt. Für die ersten Schritte reicht eine Tabelle, für den ernsthaften Betrieb wird sie zur Last.

Der Übergang von der Tabelle zum Werkzeug passiert bei jedem an einem anderen Punkt. Wenn ihr gerade an genau dieser Stelle steht und darüber sprechen wollt, wie eine werkzeuggestützte TARA in eurem Kontext aussieht, erreicht ihr mich über das Kontaktformular auf itemis.com oder direkt auf LinkedIn.

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