TARA Schritt für Schritt: eine ECU-Bedrohungsanalyse

Eine TARA (Threat Analysis and Risk Assessment) ist der strukturierte Weg, auf dem ISO/SAE 21434 dich entscheiden lässt, was zu schützen ist und wie stark. Clause 15 legt die Schritte fest; dieser Leitfaden arbeitet sie an einem einzelnen Diagnose-ECU durch, damit die Methode konkret wird. Das Ergebnis ist ein Satz Cybersecurity-Anforderungen, gegen die du testen kannst, kein Dokument, das im Regal liegt. Es ist Ingenieursabwägung, gestützt auf Nachweise, kein Tool-Output.

Die Schritte, der Reihe nach

ISO/SAE 21434 Clause 15 definiert eine Kette, in der jeder Schritt den nächsten speist:

1. Asset-Identifikation mit Cybersecurity-Eigenschaften (Vertraulichkeit, Integrität, Verfügbarkeit).
2. Damage-Szenarien: welcher Schaden folgt, wenn eine Eigenschaft verloren geht.
3. Threat-Szenarien: wie die Eigenschaft eines Assets kompromittiert werden könnte.
4. Angriffspfad-Analyse: die konkreten Wege, eine Bedrohung zu realisieren.
5. Attack-Feasibility-Rating: wie schwer jeder Pfad ist.
6. Impact-Rating: wie schlimm der Schaden ist, über Safety, Finanzen, Betrieb und Privatsphäre.
7. Risikowert: Impact kombiniert mit Feasibility.
8. Risikobehandlung: reduzieren, teilen, behalten oder vermeiden.

Durchgearbeitetes Beispiel: ein Diagnose-ECU

Nimm ein ECU, das einen Aktor steuert und UDS-Diagnostik über CAN offenlegt.

Assets und Damage-Szenarien

Asset	Eigenschaft	Damage-Szenario
Aktor-Steuerlogik	Integrität	Unautorisierte Aktuierung, ein mögliches Safety-Ereignis
Kalibrierdaten	Integrität	Verändertes Verhalten außerhalb des validierten Rahmens
Firmware	Integrität	Persistenter Schadcode über den Flash-Pfad
Identifikationsdaten (Seriennummer, Fingerprint)	Integrität	Komponenten-Klonen oder Wegfahrsperren-Umgehung

Threat-Szenarien

Für das Kalibrier-Asset: “Ein Angreifer verändert Kalibrierdaten, indem er einen Kalibrier-DID ohne Autorisierung schreibt.” Das ist eine präzise, testbare Aussage, und genau darum geht es bei einem guten Threat-Szenario.

Angriffspfad-Analyse

Zerlege die Bedrohung in einen Pfad. Für die Kalibrierschreibung:

1. Das ECU auf dem CAN-Bus erreichen (physisch oder über ein Gateway)
2. In die Session eintreten, die den Schreibservice offenlegt:   10 03
3. Die Kalibrierschreibung versuchen:                            2E F1 A0 <Daten>
4. Bei 0x33 securityAccessDenied SecurityAccess überwinden:      27 01 / 27 02
5. Schreibung akzeptiert:                                        6E F1 A0

Jeder Schritt ist ein Punkt, an dem eine Kontrolle den Angreifer entweder aufhält oder nicht. Der Pfad ist eine Hypothese darüber, was das ECU erlaubt.

Attack-Feasibility-Rating

ISO/SAE 21434 bietet einen Attack-Potential-Ansatz basierend auf verstrichener Zeit, Expertise, Wissen über das Item, Gelegenheitsfenster und Ausrüstung. Bewerte jeden Pfad aus diesen Faktoren zu einer Feasibility-Stufe (sehr niedrig bis hoch). Eine Schreibung, die nur Bus-Zugang und einen Standard-Tester braucht, liegt weit höher als eine, die rekonstruierte Firmware und ein Labor braucht.

Genau hier ändern Tests die Zahl. Der obige Pfad nimmt an, dass 0x27 überwunden werden kann. Zeigt ein Prüfstandstest, dass der SecurityAccess-Seed konstant ist und kein Lockout existiert, ist der Schritt “SecurityAccess überwinden” trivial und die Feasibility springt hoch. Zeigt der Test, dass die Schreibung ohne gültigen Key schlicht nicht erreichbar ist, wird der Pfad deutlich schwerer. Eine geschätzte Feasibility wird zu einer beobachteten.

Impact-Rating

Bewerte den Schaden über die vier Kategorien. Eine unautorisierte Aktuierung an einem safety-relevanten ECU ist ein hoher Safety-Impact; veränderte Identifikationsdaten mögen niedrige Safety, aber höheren finanziellen und betrieblichen Impact haben.

Risikowert und Behandlung

Kombiniere Impact und Feasibility zu einem Risikowert und entscheide dann die Behandlung. Für den Kalibrierpfad, wenn die Feasibility hoch ist, weil SecurityAccess schwach ist, ist die sinnvolle Behandlung, das Risiko zu reduzieren: das Seed/Key-Tor reparieren und einen Lockout ergänzen, was Feasibility und Risiko senkt. Jede Behandlungsentscheidung wird zu einer Cybersecurity-Anforderung, etwa “der Kalibrier-Schreibservice muss eine entsperrte SecurityAccess-Stufe mit zufälligem Seed und Brute-Force-Lockout erfordern”.

Von der TARA zu testbaren Anforderungen

Der Wert der Kette ist, dass sie in Anforderungen endet, die du verifizieren kannst. “SecurityAccess muss einen zufälligen Seed und einen funktionierenden Lockout haben” ist ein Satz, den ein Test am Prüfstand bestätigen oder widerlegen kann. Die TARA benennt die Angriffspfade; Tests messen, wie offen sie wirklich sind; der Verifikationsnachweis speist dann zurück ins Risikobild. Bei einer vollen TARA, die wir für einen ADAS-Tier-1 schrieben, bewegten sich die Diagnose-Schreibpfade am meisten, sobald echte Feasibility die Annahmen ersetzte.

Wo AutoST hineinpasst, und wo nicht

AutoST schreibt nicht deine TARA. Eine TARA ist eine Ingenieursabwägung über Assets, Schaden und Angreifer, und kein Scanner erzeugt das. Was AutoST tut, ist die Angriffspfade zu testen, die eine TARA identifiziert: ob Services ohne Authentifizierung erreichbar sind, ob SecurityAccess hält, ob Identifikations-DIDs schreibbar sind, ob der Flash-Pfad offenliegt. Diese Ergebnisse machen aus geschätzter Feasibility beobachtete Feasibility, der Input, der einer TARA am häufigsten fehlt. Die TARA, das Cybersecurity-Konzept und die Risikobehandlung sind Beratungsarbeit, die Zyberum neben dem Tool anbietet.