TARA METHODIK FÜR ISO 21434: SCHRITT FÜR SCHRITT

TARA steht für Threat Analysis and Risk Assessment und ist ein zentraler Cybersecurity-Workflow in ISO/SAE 21434. Die Methode hilft Automotive Teams zu klären, welche Assets geschützt werden müssen, welche Damage Scenarios entstehen können, welche Threat Scenarios und Attack Paths relevant sind, wie Attack Feasibility und Impact bewertet werden und welche Cybersecurity Goals, Requirements, Controls und Evidence daraus folgen.

Dieser Leitfaden richtet sich an Cybersecurity Engineers, Functional Safety Teams, Systemarchitekten, Product Owner, OEMs, Tier 1s und Engineering-Dienstleister, die ein TARA Tool oder ISO 21434 Software evaluieren. Ziel ist ein Workflow, der schneller zu reviewbaren Ergebnissen führt und gleichzeitig Traceability und Engineering-Verantwortung erhält.

Aegis SafeForge ist eine KI-gestützte Workflow-Plattform für funktionale Sicherheit und Cybersecurity Engineering, HARA, TARA, Requirements Traceability, Artefaktgenerierung, Review Control und auditierbare Engineering-Evidence. Für TARA hilft SafeForge Teams, von Projektkontext und Assets zu geprüften Cybersecurity-Risk-Outputs zu kommen.

Was TARA in ISO 21434 bedeutet

Eine TARA verbindet Assets, Cybersecurity Properties, Damage Scenarios, Threat Scenarios, Attack Paths, Attack Feasibility, Impact, Risk Value, Risk Treatment, Cybersecurity Goals und Requirements. Sie ist keine reine Threat-Liste. Sie ist das Argument, warum bestimmte Controls und Anforderungen notwendig sind.

Eine gute TARA muss für Cybersecurity Engineers reviewbar sein und gleichzeitig für Safety, Systems, Software und Management nachvollziehbar bleiben. Sie sollte zeigen, warum ein Risiko relevant ist, welche Annahmen gelten, welche Behandlung gewaehlt wurde und welche Requirements oder Evidence daraus entstehen.

Schritt 1: Scope und Systemkontext definieren

TARA beginnt mit Kontext. Teams müssen Item- oder Systemgrenzen, Schnittstellen, Trust Boundaries, Datenflüsse, Betriebsannahmen, externe Abhängigkeiten, Update-Mechanismen, Diagnosekanaele, Nutzerrollen, Backend-Verbindungen und Lifecycle-Kontext erfassen. Wenn dieser Scope unvollständig ist, fehlen später wichtige Attack Paths oder es entstehen Risiken außerhalb der realen Systemgrenzen.

Bei vernetzten Fahrzeugen und softwaredefinierten Plattformen umfasst der Scope oft Cloud Services, Mobile Apps, OTA Update Infrastruktur, Fleet Operations, Supplier-Komponenten und Service- oder Produktionswerkzeuge. Ein TARA Tool sollte diese Annahmen festhalten, damit Reviewer verstehen, warum ein Threat Scenario im Scope ist.

Schritt 2: Assets und Cybersecurity Properties identifizieren

Assets sind Dinge, die Schutz brauchen: Firmware, Kalibrierdaten, kryptografische Schluessel, Fahrzeugkommandos, Sensordaten, personenbezogene Daten, Diagnosezugang, safety-relevante Funktionen, Backend APIs oder Update Packages. Pro Asset sollten relevante Cybersecurity Properties wie Confidentiality, Integrity, Availability, Authenticity, Authorization oder Freshness betrachtet werden.

Die Asset-Sicht hält die TARA geerdet. Statt generische Angriffe zu sammeln, fragt das Team: Welcher Wert oder welche Funktion ist betroffen? Welche Eigenschaft kann kompromittiert werden? Welcher Schaden entsteht daraus?

Schritt 3: Damage Scenarios definieren

Ein Damage Scenario beschreibt den möglichen Schaden, wenn eine Cybersecurity Property eines Assets kompromittiert wird. Unautorisierte Änderung einer Steuerungssoftware kann zum Beispiel unsafe vehicle behavior, regulatorische Probleme, Vertrauensverlust, Datenschutzschaden oder Betriebsunterbrechung verursachen.

Starke Damage Scenarios verhindern vage Risikosprache. Sie verbinden Cybersecurity mit Safety, Business, Datenschutz und Betrieb. Wenn das Damage Scenario unklar bleibt, wird auch Risk Treatment schwer zu begruenden.

Schritt 4: Threat Scenarios und Attack Paths ableiten

Threat Scenarios beschreiben, wie eine Cybersecurity Property kompromittiert werden kann. Attack Paths beschreiben den Weg des Angreifers. In Automotive-Systemen können Diagnoseinterfaces, Funkkanaele, Backend APIs, Update Packages, Supplier Tools, kompromittierte Zugangsdaten, Debug-Zugänge oder physischer Zugriff auf Fahrzeugnetzwerke relevant sein.

KI-gestützte Tools können aus Systemkontext Kandidaten für Threats und Attack Paths vorschlagen. Diese Vorschläge brauchen aber Expertenreview. Ein plausibel klingendes Threat Scenario kann trotzdem unrealistisch, außerhalb des Scope oder unvollständig sein.

Schritt 5: Attack Feasibility und Impact bewerten

Attack Feasibility bewertet, wie schwierig ein Angriff umzusetzen ist. Faktoren können Expertise, Wissen über das Item, Opportunity Window, Equipment, Zeitaufwand und weitere projektspezifische Annahmen sein. Impact bewertet die Schwere des Damage Scenario. Zusammen führen diese Bewertungen zur Risk-Entscheidung.

Diese Bewertung sollte nicht als Black-Box-Zahl enden. Reviewer müssen die Rationale sehen: Warum ist ein Angriff machbar? Welche Annahmen reduzieren Feasibility? Welche Controls existieren schon? Welche Damage-Kategorie treibt den Impact?

Schritt 6: Risk Treatment und Cybersecurity Goals festlegen

Risk Treatment legt fest, wie das Risiko behandelt wird: vermeiden, reduzieren, teilen, akzeptieren oder nach Organisationsprozess anders behandeln. In der Produktentwicklung entstehen daraus Cybersecurity Goals, Requirements, Controls, Claims, Verification Activities, Monitoring oder Supplier Obligations.

Eine schwache TARA endet bei einer Risk-Rating-Tabelle. Eine starke TARA erzeugt eine nachvollziehbare Linie von Asset und Damage Scenario zu Requirement, Control, Evidence und Review-Historie.

Wo TARA und HARA zusammenkommen

Cybersecurity und funktionale Sicherheit sind unterschiedliche Disziplinen, aber moderne Automotive-Systeme verbinden sie immer staerker. Ein Cybersecurity Threat kann safety-relevantes Fehlverhalten ermöglichen oder beeinflussen. Deshalb sollten TARA und HARA dort verbunden werden, wo Threats Safety-Annahmen, Safety Mechanisms oder den Safety Case beruehren.

SafeForge unterstützt HARA und TARA in einer Plattform, weil regulierte Teams einen gemeinsamen Evidence-Kontext brauchen. Safety- und Security-Artefakte sollten nicht getrennt bleiben, wenn das technische Risiko verbunden ist.

Typische TARA Fehler

FAQ zur TARA