6 TARA Tools für ISO/SAE 21434: Methodik & Vergleich

Die Cybersicherheit vernetzter Fahrzeuge steht und fällt mit einer Frage: Woher wissen Sie, welche Angriffe auf ein Steuergerät wirklich gefährlich sind und welche Schutzmaßnahmen sich lohnen? Genau das beantwortet die Threat Analysis and Risk Assessment (TARA), das methodische Herzstück von ISO/SAE 21434. Ohne eine belastbare TARA gibt es weder eine tragfähige Cybersecurity-Konzeptphase noch einen Nachweis gegenüber den Zulassungsbehörden nach UNECE R155.

In der Praxis stellt sich schnell die Werkzeugfrage. Eine TARA für ein modernes Fahrzeug mit Hunderten Steuergeräten und über 100 Millionen Zeilen Code lässt sich in Excel zwar beginnen, aber kaum sauber über Jahre pflegen. Spezialisierte TARA-Tools versprechen Automatisierung, Angriffsbaum-Editoren, Bedrohungskataloge und auditsichere Berichte. Doch welches Tool passt zu welchem Anwendungsfall, und wo endet der Nutzen der Automatisierung?

Dieser Artikel liefert beides: zuerst die TARA-Methodik nach Clause 15 als nachvollziehbare Schrittkette samt einem durchgerechneten Beispiel, dann einen faktengeprüften, kritischen Vergleich von sechs etablierten TARA-Werkzeugen, ergänzt um weitere Marktangebote und eine konkrete Auswahlhilfe. Wenn Sie den Standard grundsätzlich einordnen möchten, hilft vorab unser Überblick zur ISO/SAE 21434 in der Automobilindustrie.

Was ist TARA nach ISO/SAE 21434 (Clause 15)?

TARA steht für Threat Analysis and Risk Assessment, also Bedrohungsanalyse und Risikobewertung. In ISO/SAE 21434 ist die Methodik in Clause 15 definiert und wird über den gesamten Lebenszyklus hinweg verwendet: in der Konzeptphase (Clause 9), in der Produktentwicklung (Clause 10) sowie in Produktion und Betrieb (Clauses 12 und 13). TARA ist also kein einmaliges Dokument, sondern ein lebendes Artefakt, das mit jeder Architekturänderung fortgeschrieben wird.

Wichtig zur Abgrenzung: TARA nach ISO/SAE 21434 ist nicht dasselbe wie generisches IT-Risikomanagement. Die Bewertung des Schadens erfolgt konsequent aus Sicht des betroffenen Verkehrsteilnehmers, nicht aus Sicht des Unternehmens. Ein Angriff, der ein Bremssteuergerät manipuliert, wird also primär über seine Gefährdung von Menschenleben bewertet, nicht über den finanziellen Schaden für den Hersteller.

Die TARA-Schrittkette

Der Kern von Clause 15 lässt sich als Schrittkette lesen. Verschiedene Beraterhäuser und Tool-Hersteller fassen sie mal in sechs, mal in neun Schritten zusammen, inhaltlich decken sie sich jedoch:

1. Item Definition (Betrachtungsgegenstand festlegen): Was genau wird analysiert (ein Steuergerät, eine Funktion, ein Teilsystem)? Systemgrenzen, Schnittstellen und Betriebsumgebung werden abgesteckt.
2. Asset Identification (Werte identifizieren): Welche schützenswerten Objekte gibt es? Funktionen, Daten (kryptografische Schlüssel, Kalibrierdaten, Firmware), Schnittstellen (CAN, Automotive Ethernet, Bluetooth, OBD-II, JTAG) und Hardware. Jedem Asset werden die relevanten Cybersecurity-Eigenschaften zugeordnet: Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität.
3. Threat Scenario Identification (Bedrohungsszenarien identifizieren): Wie kann eine Cybersecurity-Eigenschaft verletzt werden? In der Praxis nutzen viele Teams das STRIDE-Modell (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).
4. Impact Rating (Schadensbewertung): Wie schwer wären die Folgen? Bewertet wird in vier Kategorien: Safety (Sicherheit), Financial (Finanzen), Operational (Betrieb) und Privacy (Datenschutz), kurz S/F/O/P.
5. Attack Path Analysis (Angriffspfadanalyse): Über welche konkreten Schritte lässt sich ein Bedrohungsszenario realisieren? Häufig als Angriffsbaum modelliert.
6. Attack Feasibility Rating (Durchführbarkeitsbewertung): Wie aufwendig ist der Angriff? ISO/SAE 21434 erlaubt drei Ansätze: die attack-potential-basierte Methode (abgeleitet aus ISO/IEC 18045), einen angriffsvektorbasierten Ansatz und die CVSS-Exploitability-Metrik.
7. Risk Value Determination (Risikowert bestimmen): Der Risikowert ergibt sich aus der Kombination von Schadensschwere und Durchführbarkeit, häufig als Matrix. Die Grundformel lautet sinngemäß Risiko = Impact x Feasibility.
8. Risk Treatment Decision (Risikobehandlung entscheiden): Für jedes Risiko wird eine von vier Optionen gewählt: vermeiden (Avoid), reduzieren (Reduce), übertragen (Transfer) oder akzeptieren (Accept). Reduktion bedeutet konkrete Sicherheitsmaßnahmen, Akzeptanz erfordert eine formale Freigabe durch das Management.

Impact Rating: die vier Schadenskategorien

Für das Impact Rating sieht ISO/SAE 21434 vier Stufen vor: Negligible (vernachlässigbar), Moderate (moderat), Major (erheblich) und Severe (schwerwiegend). Der Gesamt-Impact eines Szenarios entspricht in der Regel dem höchsten Einzelwert über die vier Kategorien hinweg. Die folgende Zuordnung ist eine in der Praxis gängige Annäherung, die auf Vorläufer- und Referenzmethodiken wie HEAVENS beruht und nicht wörtlich aus der (kostenpflichtigen) Norm zitiert ist:

Attack Feasibility Rating: die fünf Faktoren

Die attack-potential-basierte Methode bewertet fünf Faktoren und summiert deren Punkte. Die folgenden Punktwerte sind gängige Sekundärquellen-Werte auf Basis der attack-potential-Methode aus ISO/IEC 18045, auf die sich ISO/SAE 21434 bezieht. Sie sind kein wörtliches Normzitat und dienen der Veranschaulichung der zugrunde liegenden Logik:

Aus der Punktsumme leitet sich das Feasibility-Rating ab. ISO/SAE 21434 verwendet eine vierstufige Skala: High, Medium, Low, Very Low. Eine niedrige Punktsumme bedeutet dabei einen leicht durchführbaren Angriff, also eine hohe Durchführbarkeit. Eine gängige Zuordnung lautet: 0 bis 13 Punkte = High, 14 bis 19 = Medium, 20 bis 24 = Low, ab 25 = Very Low. Achtung: Manche Quellen (etwa aus dem EVITA-Umfeld) nutzen eine inverse fünfstufige Benennung (basic bis beyond-high). Wir halten uns hier konsequent an die ISO-Vierstufigkeit, um Verwirrung zu vermeiden.

Risikowert und Risikobehandlung

Impact und Feasibility werden zu einem Risikowert kombiniert, meist über eine Risikomatrix mit vier Risikostufen:

• Stufe 1 (akzeptabel): keine zusätzlichen Maßnahmen nötig.
• Stufe 2 (niedrig): beobachten, Verfeinerung erwägen.
• Stufe 3 (mittel): Sicherheitsmaßnahmen erforderlich, Entscheidung dokumentieren.
• Stufe 4 (hoch): Sicherheitsmaßnahmen verpflichtend, Risikoreduktion nachweisen.

CAL und der Bezug zu UNECE R155/R156

Ein häufig missverstandener Begriff ist der Cybersecurity Assurance Level (CAL). Analog zum ASIL in der funktionalen Sicherheit (ISO 26262) drückt der CAL aus, mit welcher Strenge Cybersecurity-Aktivitäten für einen bestimmten Betrachtungsgegenstand durchgeführt und geprüft werden sollten. Wichtig: Der CAL ist kein direktes Ergebnis der Risikobewertung und ersetzt diese nicht. Rund um CAL und die zugehörige Verifikation und Validierung gibt es zudem laufende Standardisierungsarbeit bei ISO/SAE. Das ursprünglich als PWI 8475 geführte Arbeitselement hat den PWI-Status verlassen und ist als ISO/SAE PAS 8475 (Cybersecurity Assurance Levels und Targeted Attack Feasibility) fortgeschritten, ergänzt um den zugehörigen ISO/SAE TR 8477. GlobalPlatform ist dabei allenfalls ein mitdiskutierendes Forum, nicht der Herausgeber. Das Konzept reift also weiter. Eine vertiefte Einordnung finden Sie in unserem Artikel zum Cyber Security Assurance Level.

Regulatorisch bewegt sich TARA im Rahmen von zwei UN-Regelungen: UNECE R155 verlangt ein zertifiziertes Cybersecurity Management System (CSMS) als Voraussetzung für die Fahrzeug-Typgenehmigung, UNECE R156 ein Software Update Management System (SUMS) für Over-the-Air-Updates. R155 fordert eine strukturierte TARA gegen den Bedrohungskatalog aus Anhang 5 der Regelung, schreibt aber keine bestimmte Methode vor. Die Clause-15-Methodik von ISO/SAE 21434 gilt als die am breitesten akzeptierte Grundlage für belastbare Nachweise. Entscheidend zu wissen: ISO/SAE-21434-Konformität ist nicht automatisch dasselbe wie eine R155-Zertifizierung, auch wenn die Norm faktisch der De-facto-Nachweisrahmen ist.

Durchgerechnetes Beispiel: ADAS-Kamera-Steuergerät

Theorie wird greifbar an einem konkreten Fall. Wir betrachten das Steuergerät einer ADAS-Frontkamera, wie es Fahrerassistenzsysteme mit Objekterkennung speisen. Das Beispiel ist bewusst vereinfacht und dient der Veranschaulichung der Methodik, die Zahlenwerte beruhen auf den oben genannten Sekundärquellen-Staffelungen.

Schritt 1 und 2 (Item und Assets): Betrachtungsgegenstand ist das Kamera-Steuergerät. Assets sind unter anderem die Objekterkennungsfunktion, die Kalibrierparameter, das Firmware-Image sowie die CAN- und Ethernet-Schnittstellen und die JTAG-Debug-Schnittstelle.

Schritt 3 (Bedrohungsszenario): Wir wählen ein Tampering-Szenario nach STRIDE: Ein Angreifer manipuliert die Kalibrierparameter über die Diagnoseschnittstelle, sodass die Objekterkennung Hindernisse falsch verortet. Die verletzte Eigenschaft ist die Integrität.

Schritt 4 (Impact Rating): Eine fehlerhafte Objekterkennung kann zu einer unterlassenen Notbremsung führen, das Safety-Impact ist damit Severe (lebensgefährlich). Rückrufe und Haftung ergeben ein Financial-Impact von Major. Operational und Privacy sind hier niedriger. Der Gesamt-Impact entspricht dem höchsten Wert, also Severe.

Schritt 5 und 6 (Angriffspfad und Feasibility): Der Angriffspfad läuft über physischen oder logischen Zugang zur Diagnoseschnittstelle. Bewertung der fünf Faktoren:

21 Punkte fallen in den Bereich 20 bis 24, das entspricht dem Feasibility-Rating Low, der Angriff ist also aufwendig, aber nicht unmöglich.

Schritt 7 (Risikowert): Ein Severe-Impact trifft auf eine Low-Feasibility. In einer typischen Matrix ergibt das dennoch einen erhöhten Risikowert (Stufe 3, mittel), weil das potenzielle Schadensausmaß so hoch ist. Das Risiko muss behandelt und die Entscheidung dokumentiert werden.

Schritt 8 (Risikobehandlung): Gewählt wird Reduce. Konkrete Maßnahmen, die eins zu eins auf die Bedrohung wirken:

• Secure Onboard Communication (SecOC) für CAN-Botschaften gegen Spoofing und Tampering
• zertifikatsbasierte Authentifizierung der Diagnosezugriffe
• Secure Boot mit Measured Boot für die Firmware-Integrität
• TLS-Verschlüsselung der Ethernet-Kommunikation
• Deaktivierung der JTAG-Schnittstelle in der Serienproduktion
• Audit-Logging in einen gesicherten Speicher

Dieses Beispiel zeigt den entscheidenden Punkt: Die Zahlen sind nur so gut wie die dahinterliegende Ingenieurbewertung. Genau hier setzen die Werkzeuge an, sie strukturieren und automatisieren die Bewertung, ersetzen aber nicht das Fachurteil.

Die 6 TARA-Werkzeuge im Überblick

Die folgenden sechs Tools sind in der Automotive-Branche etabliert. Für jedes Tool nennen wir den aktuellen Produkt- und Herstellerstand (Juli 2026), eine Kurzeinordnung und den aktuellen Link. Öffentliche Preislisten gibt es für keines dieser Tools, alle Anbieter verweisen auf Angebot oder Demo auf Anfrage.

AVL ThreatGuard

• Hersteller: AVL (Österreich)
• Status: aktiv, ergänzt um das Schwesterprodukt AVL ComplyGuard für Compliance- und Dokumentationsmanagement nach ISO 21434 und ISO 26262
• Wofür geeignet: automatisierte Generierung von Bedrohungsszenarien, Impact-Analysen und Angriffsbäumen direkt aus der Systemarchitektur; Import bestehender MBSE-Modelle; Integration mit Jira, ALM, PLM und ReqIF

ThreatGuard richtet sich an Teams, die Architektur und TARA eng koppeln wollen. Der zugehörige Trial-Zugang läuft über das Experience-Portal von AVL. Hinweis: Der genaue Produktlink im Portal enthält eine Salesforce-ID, die sich ändern kann, prüfen Sie ihn vor der Nutzung.

ESCRYPT CycurRISK (ETAS)

• Hersteller: ETAS GmbH (Bosch-Tochter). ESCRYPT ist heute Teil von ETAS, das Produkt heißt aber weiterhin offiziell ESCRYPT CycurRISK.
• Status: aktiv. Die früher genutzte Produkt-URL leitet inzwischen per Redirect um, die aktuelle Adresse lautet etas.com/.../escrypt-cycurrisk.
• Wofür geeignet: workflow-orientierte TARA-Erstellung mit integriertem Angriffsbaum-Editor, Variantenverwaltung und kollaborativer Analyse auf On-Premise-Servern; Bedrohungsbibliothek "Automotive Threat Matrix" (ATM); Konformitätsanspruch für ISO/SAE 21434 und UN R155

CycurRISK eignet sich besonders für Organisationen mit On-Premise-Anforderungen und mehreren Produktvarianten. Der Hersteller nennt hohe Nutzungszahlen (Marketing-Angabe, nicht unabhängig verifiziert).

itemis SECURE

• Hersteller: itemis AG (Deutschland)
• Status: aktiv, deutlich weiterentwickelt. Neu sind KI-Assistenten zur automatisierten Angriffsbaum-Generierung, community-getriebene Bedrohungskataloge (u. a. ASRG), CVE-Integration und ein Compliance-Anspruch, der neben ISO/SAE 21434 und IEC 62443 nun auch den Cyber Resilience Act (CRA) umfasst.
• Wofür geeignet: browserbasierte, modellzentrierte TARA mit Komponenten- und Datenflussdiagrammen, Angriffsbäumen und auditsicherer Berichtserstellung

itemis SECURE ist eine der ausgereiftesten Standalone-Workbenches und kooperiert mit Cybellum für eine kombinierte CSMS-Lösung. Genannte Referenzkunden sind unter anderem ZF Group und Knorr-Bremse.

Ansys medini analyze for Cybersecurity / Ansys Medini Cybersecurity SE

• Hersteller: Ansys, Inc.
• Status: aktiv, in Weiterentwicklung. Der etablierte Name lautet "Ansys medini analyze for Cybersecurity"; 2025 hat Ansys eine webbasierte Weiterentwicklung unter dem Namen Ansys Medini Cybersecurity SE eingeführt (Version 2025 R2, webbasiert, mit TARA-Automatisierung und Anbindung an ein Vehicle Security Operations Center, VSOC). Vor einer Kaufentscheidung sollten Sie den aktuellen Funktionsumfang direkt bei Ansys prüfen.
• Wofür geeignet: TOE-Modellierung, Angriffsbäume, Bedrohungsanalyse und Risikobewertung; besonders interessant für Teams, die bereits medini analyze für die funktionale Sicherheit (ISO 26262) nutzen und Safety und Security in einem Werkzeug bündeln wollen

Das Werkzeug richtet sich an ISO/SAE 21434 und UN R155 aus und unterstützt etablierte Bewertungsmethodiken wie HEAVENS und die SAE-J3061-Linie.

Vultara

• Hersteller: Vultara, Inc. (spezialisierter Anbieter)
• Status: aktiv, Positionierung unverändert als reines TARA-Automatisierungstool
• Wofür geeignet: Drag-and-Drop-Oberfläche, automatische Bedrohungs- und Risikogenerierung über eine Regel-Engine, direkte Bearbeitung von Architekturdiagrammen mit automatischer Ergebnisaktualisierung bei Designänderungen

Vultara grenzt sich explizit von reinen Verwaltungs-Tools ab, die nur die Dateneingabe strukturieren, und betont die aktive Generierung von Bedrohungen und Risiken. Preise gibt es nur auf Anfrage über eine kostenlose Demo.

AUTOThreat PRO (Upstream Security)

• Hersteller: Upstream Security (Israel)
• Status: aktiv, aber wichtige Einordnung nötig. AUTOThreat PRO ist in der Außendarstellung primär ein Cyber-Threat-Intelligence-Produkt mit Deep- und Dark-Web-Monitoring, IOC/IOA-Echtzeitwarnungen und Lieferketten-Risikoanalyse, keine klassische TARA-Autoring-Workbench wie die anderen fünf Tools. Upstream bietet separat einen eigenständigen TARA-Rechner nach ISO/SAE 21434 an, jedoch unter einer anderen Bezeichnung und URL.
• Wofür geeignet: kontinuierliche Bedrohungsaufklärung und Ergänzung einer bestehenden TARA um reale, aktuelle Bedrohungsdaten, weniger als alleiniges Werkzeug zur Erstellung der TARA selbst

Diese ehrliche Einordnung ist wichtig: Wer eine Workbench zur Durchführung der Clause-15-Schrittkette sucht, ist mit den anderen Tools besser bedient. Wer eine bestehende TARA mit Threat Intelligence anreichern will, findet hier den passenderen Ansatz.

Vergleichstabelle der 6 TARA-Werkzeuge

Die folgende Übersicht ordnet die Tools nach den in der Praxis wichtigsten Kriterien ein. Sie beruht auf öffentlich verfügbaren Herstellerangaben (Stand Juli 2026) und ersetzt keine eigene Evaluierung.

Weitere relevante TARA-Werkzeuge am Markt

Der Markt umfasst deutlich mehr als sechs Anbieter. Wer eine fundierte Auswahl treffen will, sollte auch diese Optionen kennen:

• Cybellum Product Security Platform: primär SBOM- und Schwachstellenmanagement, das TARA-Ergebnisse konsumiert statt sie zu erzeugen; ergänzt itemis über eine Partnerschaft.
• C2A Security (EVSec): Risk-Driven-DevSecOps-Plattform mit TARA-Modul, explizit als Alternative zu Excel-basierter TARA positioniert, mit Compliance-Tracking für WP.29 und ISO/SAE 21434.
• Vector COMPASS: Werkzeug für Planung, Durchführung und Auswertung von Threat Assessments samt Vulnerability Management; lückenloser Audit-Trail und Kombination von Komponenten-TARAs zu einer Produkt-TARA (Angaben aus Herstellerquellen, vor Kauf live prüfen).
• PlaxidityX Security AutoDesigner: KI-gestützte TARA-Automatisierung. Wichtig: PlaxidityX ist die seit 2024 umbenannte Nachfolgemarke von Argus Cyber Security, ältere Quellen führen das Angebot noch unter "Argus".
• EnCo SOX: TARA-Workbench nach ISO 21434 mit Vorlagen, Workflows und Traceability; der Anbieter veröffentlicht zugleich einige der methodisch tiefsten frei zugänglichen TARA-Leitfäden.
• SystemWeaver und No Magic (Cameo): MBSE-integrierte Cybersecurity-Erweiterungen für Teams, die bereits in einer Systems-Engineering-Suite arbeiten und kein zusätzliches Standalone-Tool einführen wollen.

Auffällig ist ein Trend, den ältere Tool-Listen ignorieren: Moderne TARA-Tools positionieren sich zunehmend multi-regulatorisch, also über ISO 21434 und R155 hinaus auch für den EU CRA oder den verbindlichen chinesischen Pflichtstandard GB 44495-2024 (im chinesischen Normwesen kennzeichnet das Präfix "GB" ohne Zusatz einen verpflichtenden Standard, anders als das empfehlende "GB/T").

Welches Tool für welchen Fall?

Da es keine öffentlichen Preise gibt, entscheidet die Passung zu Ihrem Anwendungsfall. Diese Kriterien haben sich in der Praxis bewährt:

• Standalone oder MBSE-integriert? Arbeiten Sie bereits mit Cameo oder einer MBSE-Suite, spart ein integriertes Modul (No Magic, SystemWeaver) Reibungsverluste. Ohne MBSE-Basis ist eine dedizierte Workbench (itemis SECURE, CycurRISK) meist der schnellere Weg.
• Safety und Security in einem Werkzeug? Wer ISO 26262 und ISO 21434 bündeln will, sollte Ansys Medini prüfen.
• On-Premise oder Cloud? Strenge IP-Anforderungen sprechen für On-Premise-fähige Tools wie CycurRISK, verteilte Teams eher für browserbasierte Lösungen wie itemis SECURE oder Vultara.
• Automatisierungsgrad: Vultara und PlaxidityX betonen die aktive, automatisierte Generierung von Bedrohungen und Risiken, andere Tools strukturieren eher die manuelle Bewertung.
• Threat Intelligence statt Autoring? Für kontinuierliche Bedrohungsdaten ist AUTOThreat PRO gedacht, nicht für die Erstellung der TARA selbst.

Wann reicht sogar Excel?

Ein ehrlicher Blick gehört dazu: Nicht jedes Projekt braucht sofort ein spezialisiertes Tool. In der Praxis kehren einzelne Organisationen trotz teurer Lösungen zur Excel-basierten TARA zurück, weil der Mehrwert der Software für ihren Anwendungsfall gering blieb (eine Beobachtung aus der Branche, keine Statistik). Für sehr kleine, stabile Betrachtungsgegenstände in der frühen Konzeptphase kann eine strukturierte Tabelle genügen.

Ab einer gewissen Größe stößt Excel jedoch klar an Grenzen. Die typischen Schwächen: keine Versionskontrolle über kollaborative Dateien, schlechte Skalierbarkeit und Datenintegrität bei manuellen Updates, schwache Visualisierung komplexer Angriffsbäume, kaum Integration mit Threat-Intelligence-Feeds oder Asset-Management sowie keine eingebaute Anleitung für Standards wie WP.29 oder ISO/SAE 21434. Genau an diesen Punkten entfalten dedizierte Tools ihren Nutzen, sofern sie diszipliniert eingesetzt werden.

Die Grenzen der Automatisierung

Werkzeuge lösen nicht jedes Problem. Drei bekannte Fallstricke sollten Sie kennen:

1. Fehlerhafte Aggregation von Angriffspfaden: Automatisierte Tools summieren oder verrechnen die Feasibility mehrstufiger Angriffe teils naiv und überschätzen dadurch systematisch das Risiko. Das kostet Ressourcen für Schutzmaßnahmen gegen Angriffe, die real viel schwerer sind, als das Tool suggeriert.
2. Bedrohungsorientierte statt angriffspfadbasierte Ziele: Leitet ein Tool Cybersecurity Goals aus abstrakten Bedrohungen ab, entstehen generische Vorgaben wie "Verhinderung böswilliger Software-Modifikationen". Angriffspfadbasiert wird daraus etwas Umsetzbares: "Schutz vor Manipulation über unsichere Debug-Schnittstellen".
3. Kompetenz schlägt Werkzeug: Die Qualität einer TARA hängt vor allem von der Expertise der Ingenieure ab, tiefem Verständnis der Automotive-Systeme, aktuellem Angriffswissen und der Zusammenarbeit zwischen Security-, Entwicklungs- und Safety-Teams. Ein Tool beschleunigt gute Arbeit, ersetzt sie aber nicht. Mehr dazu in unserem Artikel zu den Herausforderungen der ISO 21434.

FAQ

Was ist TARA nach ISO/SAE 21434?

TARA steht für Threat Analysis and Risk Assessment, also Bedrohungsanalyse und Risikobewertung. In ISO/SAE 21434 ist die Methodik in Clause 15 definiert. Sie identifiziert schützenswerte Assets, leitet Bedrohungsszenarien ab, bewertet Schadensschwere und Durchführbarkeit von Angriffen und mündet in eine dokumentierte Risikobehandlung. TARA ist kein einmaliges Dokument, sondern ein lebendes Artefakt über den gesamten Lebenszyklus.

Ist ein TARA-Tool für ISO/SAE 21434 Pflicht?

Nein. Weder ISO/SAE 21434 noch UNECE R155 schreiben eine bestimmte Software vor. Gefordert ist eine strukturierte, nachvollziehbare TARA, nicht ein konkretes Werkzeug. Für kleine, stabile Betrachtungsgegenstände kann eine disziplinierte Tabelle genügen. Ab wachsender Komplexität, vielen Varianten und Audit-Anforderungen erleichtert ein dediziertes Tool die Pflege und den Nachweis erheblich.

Was kostet eine TARA-Software?

Für keines der etablierten TARA-Werkzeuge gibt es öffentliche Preislisten. Alle Anbieter verweisen auf ein individuelles Angebot oder eine Demo auf Anfrage. Die Kosten hängen von Lizenzmodell, Nutzeranzahl, Betriebsmodell (On-Premise oder Cloud) und Supportumfang ab. Für eine belastbare Kalkulation sollten Sie mehrere Anbieter direkt anfragen und entlang Ihres Anwendungsfalls vergleichen.

Kann man TARA auch in Excel durchführen?

Ja, in der frühen Konzeptphase und bei sehr kleinen, stabilen Betrachtungsgegenständen kann eine strukturierte Tabelle genügen. Excel stößt jedoch schnell an Grenzen: keine echte Versionskontrolle, schwache Datenintegrität bei manuellen Updates, kaum Visualisierung komplexer Angriffsbäume und keine Integration von Threat Intelligence. Ab einer gewissen Größe entfalten dedizierte Tools ihren Nutzen.

Was ist der Unterschied zwischen TARA und HARA?

HARA (Hazard Analysis and Risk Assessment) stammt aus der funktionalen Sicherheit nach ISO 26262 und bewertet Gefährdungen durch zufällige Fehler und Fehlfunktionen. TARA nach ISO/SAE 21434 bewertet gezielte Angriffe auf die Cybersicherheit. HARA fragt "Was passiert bei einem Ausfall?", TARA fragt "Was kann ein Angreifer bewusst herbeiführen?". Beide ergänzen sich in der Fahrzeugentwicklung.

Fazit

Ein gutes TARA-Werkzeug ist wertvoll, aber es ist Mittel zum Zweck, nicht Selbstzweck. Entscheidend ist zuerst das Verständnis der Methodik nach Clause 15: die saubere Schrittkette von der Asset-Identifikation über Impact- und Feasibility-Bewertung bis zur dokumentierten Risikobehandlung, eingebettet in den regulatorischen Rahmen von UNECE R155 und R156.

Auf dieser Grundlage lässt sich die Werkzeugfrage nüchtern beantworten. Die sechs vorgestellten Tools decken unterschiedliche Schwerpunkte ab, von der architekturgetriebenen Automatisierung (AVL ThreatGuard) über ausgereifte Workbenches (itemis SECURE, ESCRYPT CycurRISK) und die Safety-Kopplung (Ansys Medini) bis zur reinen Automatisierung (Vultara) und der Threat-Intelligence-Ergänzung (AUTOThreat PRO). Daneben steht ein breiterer Markt mit Cybellum, C2A, Vector, PlaxidityX, EnCo und MBSE-integrierten Optionen.

Die beste Entscheidung treffen Sie, wenn Sie Ihren Anwendungsfall entlang der genannten Kriterien schärfen (Standalone oder integriert, Cloud oder On-Premise, Automatisierungsgrad, Multi-Regulatorik) und die Automatisierung kritisch begleiten. Denn die härteste Anforderung an eine belastbare TARA bleibt menschlich: Fachwissen, Sorgfalt und die Bereitschaft, das Artefakt über den gesamten Lebenszyklus lebendig zu halten. Wie sich TARA in die übergreifende Cybersecurity-Planung einfügt, zeigt unser Beitrag zum Cyber Security Plan nach ISO 21434.