Was ist TARA (Threat Analysis and Risk Assessment)?

TARA steht für Threat Analysis and Risk Assessment (Bedrohungsanalyse und Risikobewertung). Es handelt sich um ein systematisches Verfahren in der Cybersecurity, um potenzielle Cyber-Bedrohungen für ein System frühzeitig zu identifizieren, deren Eintrittswahrscheinlichkeit zu bewerten und die Auswirkungen auf die Sicherheit zu priorisieren. TARA ist das zentrale Element, um Sicherheitsanforderungen (Cybersecurity Goals) methodisch herzuleiten, statt sie nur zu raten.

Im Gegensatz zum klassischen Risikomanagement fokussiert sich TARA auf die Cyber-Dimension. Es geht nicht um Hardware-Defekte, sondern um böswillige Angriffe von außen. Das Ziel ist es, ein Gleichgewicht zwischen Sicherheitskosten und dem tatsächlichen Risiko zu finden.

Der Prozess (oft angelehnt an die ISO/SAE 21434) folgt einer logischen Kette:

1. Item Definition – Scope festlegen

Was schützen wir (Architektur), was ist wichtig (Relevance), was „Out of Scope“? Zur Definition des Untersuchungsgegenstands sollten:

• die relevanten Stakeholder eingebunden werden,
• die Systemgrenzen durch Definition von Entry/Exit Points, Interaktionen mit externen Interfaces, Abhängigkeiten etc. definiert werden,
• der Abgrenzungsprozess und der Scope nachvollziehbar dokumentiert werden.

Der Einsatz von UML-Diagrammen kann hier hilfreich sein.

2. Asset Identification – Bewertung der kritischen Elemente

Welches sind die zu schützenden Werte (z.B. Hardware, Software, Personal, Nutzerdaten, Steuerungsbefehle)? Identifizierte Assets werden nicht „einfach so“ geschützt, sondern im Hinblick auf die sogenannte CIA-Triade: Confidentiality (Vertraulichkeit), Integrity (Integrität) und Availability (Verfügbarkeit). Hier geht es nicht um eine reine Auflistung, sondern um eine strategische Priorisierung der Werte für die Entwicklung gezielter Schutzmaßnahmen.

3. Threat Analysis – Bedrohungsanalyse

Welche Bedrohungen existieren? Schritte der Bedrohungsanalyse sind:

• Bedrohungsakteuren identifizieren: Erkennen potenzieller Angreifer (extern / intern).
• Bedrohungsszenarios entwickeln: Entwickeln hypothetischer Angriffsszenarien, um potenzielle Risiken besser zu verstehen.
• Ergebnisse regelmäßig aktualisieren: Sicherstellen, dass aufkommende Bedrohungen zeitnah erkannt werden.

Für den Automotive-Sektor liefert der Anhang 5 der ISO/SAE 21434 einen umfangreichen Bedrohungskatalog.

4. Impact Rating – Bewertung der Konsequenzen

Wie wirkt sich ein Sicherheitsvorfall auf die identifizierten Werte aus. Wie schlimm wäre der Schaden (Sicherheit, Finanzen, Betrieb, Privatsphäre)? Es werden Schadensszenarien analysiert. Im Automotive-Sektor wird dabei das SFOPP-Modell verwendet. Es macht die Bewertung objektiv und multidimensional. Dabei steht:

• S für Safety: Verletzungsrisiko,
• F für Financial: monetäre Schäden,
• O für Operational: Funktionseinschränkungen,
• P für Privacy: Verlust sensibler Daten,
• P für Perception: Vertrauensverlust.

5. Attack Feasibility – Bewertung der Machbarkeit eines Angriffs

Wie einfach ist der Angriff durchzuführen und wie realistisch ist er? Statt einfach nur zu schätzen wird hier oft ein Ereignisbaum genutzt, um das AFR (Attack Feasibility Rating) herzuleiten. Er gliedert sich typischerweise in die die Ebenen:

• Bedrohungsszenario (Top-Event),
• Angriffspfade (Attack Paths),
• Einzelschritte (Attack Steps).

Für jeden Schritt im Ereignisbaum wird bewertet, wie hoch der Aufwand für den Angreifer ist. Daraus ergibt sich am Ende die Summe für das AFR.

6. Risk Determination – Risikoeinstufung

Berechnung des Gesamtrisikos aus Impact und Feasibility. Hier wird oft auch eine Risikomatrix erstellt. Risiken werden basierend auf der AFR und der SFOPP-Bewertung in die Risikomatrix eingetragen, typischerweise mit einer Skala von 1 (gering) bis 5 (hoch).

7. Risk Treatment – Risikobehandlung

Welche Maßnahmen zur Behandlung der erkannten Risiken sollen getroffen werden? Mögliche Strategien sind: Risiken vermeiden, mindern, akzeptieren und transferieren oder die Verantwortung teilen. Je nach Strategie entstehen daraus aktive Maßnahmen (Cybersecurity Goals) oder dokumentierte Risikoakzeptanz (Cybersecurity Claims).

In der Praxis werden die Begriffe Bedrohung (Threat) und Schwachstelle (Vulnerability) oft synonym verwendet, doch für eine präzise TARA nach ISO/SAE 21434 ist die Unterscheidung essenziell:

• Bedrohung: Ein potenzielles Ereignis, das eine Cybersecurity Property (CIA) verletzen könnte (z. B. „Manipulation von Steuerungsdaten“).
• Schwachstelle: Eine konkrete Schwäche im Design oder in der Implementierung, die die Bedrohung realisierbar macht (z. B. „Fehlende Authentifizierung am CAN-Bus“).

Eine fundierte TARA nutzt die Ergebnisse der Schwachstellenanalyse, um die Eintrittswahrscheinlichkeit objektiv zu bewerten. Nur wer seine Schwachstellen kennt, kann die Angriffspfade im Ereignisbaum korrekt gewichten und effektive Cybersecurity Goals definieren.

Viele Projektteams stellen sich die Frage, ob eine bestehende FMEA die TARA ersetzen kann. Die Antwort lautet: Nein. Während die FMEA auf Sicherheit (Safety) abzielt, adressiert die TARA die Security. Hier ein Vergleich im Überblick:

TARA ist kein Nischenprodukt, sondern in regulierten Industrien Pflicht:

• Automotive: Durch die Norm ISO/SAE 21434 ist TARA für moderne, vernetzte Fahrzeuge (Software-Defined Vehicles) zwingend.
• Medizintechnik: Schutz von Patientendaten und Sicherstellung der Gerätefunktion gegen Hackerangriffe.
• Industrie 4.0 (OT): Absicherung von Produktionsanlagen und kritischer Infrastruktur (KRITIS).
• Luft- und Raumfahrt: Schutz der Avionik vor unbefugten Zugriffen.

In objectiF RPM verknüpfen Sie die TARA direkt mit Ihrem Requirements Engineering. Identifizierte Bedrohungen führen unmittelbar zu neuen Sicherheitsanforderungen, die für alle Entwickler sichtbar sind.

Mit objectiF RPM ist die Traceability eingebaut. Vom Asset über die Bedrohung bis hin zur technischen Umsetzung und dem Testfall – die Kette ist lückenlos nachweisbar.

Cybersecurity für Ihr Requirements Engineering

Entdecken Sie, wie objectiF RPM Sie bei der Erstellung von TARAs unterstützt und die Compliance zu ISO/SAE 21434 sicherstellt.