Von TARA zum Angriff: Wirksamkeit Ihrer Cybersecurity-Maßnahmen nachweisen

1. Eine TARA ist eine Hypothese, kein Nachweis

Jede Bedrohungsanalyse und Risikobewertung, die wir lesen, endet gleich: mit einer Tabelle von Risikobehandlungsentscheidungen. Reduzieren, teilen, akzeptieren, vermeiden. Neben jeder „Reduzieren“-Zeile steht eine Maßnahme — Secure Boot, Nachrichtenauthentisierung, Zugriffskontrolle, ein gehärtetes Diagnose-Gate — und das implizite Versprechen, dass das Restrisiko akzeptabel ist, sobald diese Maßnahme existiert. Genau dieses Versprechen hat bislang niemand geprüft.

Eine TARA ist eine strukturierte Argumentation auf Basis von Annahmen. Sie nimmt an, der Angreifer benötige Spezialausrüstung. Sie nimmt an, ein Schlüssel sei nicht extrahierbar. Sie nimmt an, Secure Boot weise ein unsigniertes Image ab. ISO/SAE 21434 hält diese Behauptungen und ihren Beleg bewusst getrennt: Die TARA-Methoden in Klausel 15 liefern die Bedrohungsszenarien, die Schadensbewertung und die Bewertung der Angriffsmachbarkeit und speisen die in der Konzeptphase (Klausel 9) festgelegten Cybersecurity-Ziele; aus diesen Zielen werden in der Produktentwicklung (Klausel 10) Cybersecurity-Anforderungen; und ebenfalls in der Produktentwicklung sind Sie verpflichtet, die Umsetzung gegen diese Anforderungen zu verifizieren, bevor in Klausel 11 die Cybersecurity-Validierung auf Fahrzeugebene erfolgt. Die TARA ist die Hypothese. Die Testkampagne ist das Experiment.

Nach unserer Erfahrung ist die Lücke zwischen beiden größer, als Teams erwarten. Regelmäßig sehen wir eine TARA, die einen Angriff als „sehr gering“ machbar einstuft, weil er „Zugriff auf Chip-Ebene erfordert“ — während derselbe Effekt mit einem Laptop über den Diagnosebus erreichbar ist, weil eine Debug-Schnittstelle nie per Fuse deaktiviert wurde oder ein SecurityAccess-Seed sich als 16-Bit-Zähler entpuppt. Die Risikoeinstufung war ehrlich; die darunterliegende Annahme war falsch. Verifizierung ist der einzige Mechanismus, der das aufdeckt, bevor es das Feld tut — auf unseren Prüfständen trägt rund die Hälfte der erstmals eingereichten Stände mindestens einen Befund, der einer in die TARA eingebauten Annahme widerspricht.

Daher stellen wir an jede TARA, die uns übergeben wird, eine klare Frage: Wo ist der Nachweis? Nicht die Designabsicht, nicht der Anforderungstext — das Urteil aus einem Test, der genau das versucht hat, was die Maßnahme verhindern soll. Existiert dieses Urteil nicht, ist die Risikobehandlung eine Meinung.

2. Bedrohungsszenarien in Testfälle überführen

Der Brückenschlag von der Analyse zum Nachweis ist mechanisch — und das ist Absicht. Jedes Bedrohungsszenario der TARA — ausgedrückt als Schadensszenario, das über einen oder mehrere Angriffspfade realisiert wird — wird zu einem oder mehreren Missbrauchsfällen: einem Test, dessen Ziel es ist, die Bedrohung zu erreichen, nicht zu bestätigen, dass die Funktion funktioniert.

Ein Funktionstest fragt: „Gelingt die authentisierte Diagnose mit den richtigen Credentials?“ Ein Missbrauchsfall fragt: „Erreiche ich den geschützten Dienst ohne sie?“ Dieselbe Schnittstelle, umgekehrte Absicht. Wir leiten den Missbrauchsfall direkt aus dem bereits in der TARA dokumentierten Angriffspfad ab, sodass die Verfolgbarkeit lückenlos bleibt: Bedrohungsszenario → Angriffspfad → Missbrauchsfall → Urteil.

Jeder Missbrauchsfall braucht explizite, falsifizierbare Bestehens-/Durchfallkriterien, die vor Testbeginn festgelegt werden — sonst gibt sich „wir haben es zwei Tage versucht und sind nicht reingekommen“ als Sicherheit aus. Wir definieren sie so konkret, wie es die Maßnahme zulässt. Beispiele:

Spoofing eines sicherheitsrelevanten Frames → Kriterium: Ein Frame mit manipuliertem SecOC-Payload und/oder veraltetem Freshness-Wert wird vom Empfänger abgewiesen und löst die erwartete Fehlerbehandlung aus; BESTANDEN = in allen N Versuchen abgewiesen.
Umgehung der authentisierten Diagnose → Kriterium: Keine Anforderungssequenz versetzt das Steuergerät ohne gültigen Seed-Key-Austausch in den entsperrten Zustand; BESTANDEN = der gesperrte Zustand hält unter allen erprobten Replay-, Fuzz- und Timing-Varianten.
Ausführung nicht autorisierter Firmware → Kriterium: Ein Image mit defekter oder herabgestufter Signatur wird nicht ausgeführt; BESTANDEN = Boot bricht ab oder fällt auf ein bekannt gutes Image zurück.

Das Formulieren des Kriteriums erzwingt vorab eine nützliche Debatte: Welche Beobachtung würde tatsächlich beweisen, dass die Maßnahme gehalten hat? Kann das Team sie nicht benennen, ist die dahinterliegende Anforderung vermutlich nicht testbar — was selbst ein Befund ist, den es in die Cybersecurity-Anforderungen nach Klausel 10 zurückzuspielen lohnt.

3. Angriffsmachbarkeit als Priorisierungswerkzeug

Sie können nicht alles gleich tief prüfen, und ISO/SAE 21434 liefert die Priorisierungslogik bereits mit: die Bewertung der Angriffsmachbarkeit. Die Norm bietet mehrere Ansätze an; wir nutzen am häufigsten den auf dem Angriffspotenzial basierenden Ansatz (in der Tradition der Schwachstellenanalyse nach ISO/IEC 18045), der jeden Angriffspfad anhand von fünf Faktoren bewertet:

Benötigte Zeit — wie lange der Angriff zur Identifikation und Ausführung braucht, von Minuten bis zu vielen Monaten.
Fachwissen — Laie, geübt, Experte oder mehrere Experten.
Kenntnis des Items oder der Komponente — öffentliche Information gegenüber eingeschränktem, sensiblem oder streng vertraulichem internem Detail.
Gelegenheitsfenster — unbegrenzter, einfacher, mäßiger oder schwieriger Zugang zum Ziel, einschließlich der erforderlichen Zugriffsdauer und ob der Zugang aus der Ferne oder physisch erfolgt.
Ausrüstung — Standard, spezialisiert, maßgefertigt oder mehrere maßgefertigte Werkzeuge.

Die Faktoren verbinden sich zum Angriffspotenzial, das auf eine Machbarkeitsstufe von hoch bis sehr gering abgebildet wird. So setzen wir das in einem Verifizierungsplan tatsächlich ein — und zwar nicht auf naheliegende Weise. Pfade mit hoher Machbarkeit erhalten die größte Tiefe, weil es die billigen Angriffe sind, die ein opportunistischer Gegner zuerst findet — die Klasse „Laptop am Diagnosebus“. Wir hinterfragen aber gezielt auch die Annahmen, die eine Einstufung gesenkt haben. Wurde ein Pfad nur als gering eingestuft, weil er „Spezialausrüstung erfordert“, ist der entscheidende Test, ob handelsübliche Werkzeuge diese Ausrüstung seit Erstellung der TARA klammheimlich zum Standard gemacht haben. Machbarkeitsbewertungen altern. Glitching-Aufbauten, Logikanalysatoren und Software-Defined Radios, die vor fünf Jahren exotisch waren, sind heute auf Hobbyniveau verfügbar.

Die Machbarkeit lenkt den Aufwand also in zwei Richtungen: Tiefe dort, wo die Ausnutzung einfach ist, und Skepsis dort, wo die Einstufung auf einer womöglich überholten Annahme beruht. Eine Bewertung ist eine Vorhersage; der Pentest ist die Kalibrierung.

4. Jede Maßnahmenklasse mit konkreten Kriterien verifizieren

Generische Testpläne erzeugen generische Befunde. Jede Maßnahmenklasse versagt auf charakteristische Weise, und die Missbrauchsfälle müssen genau diese Spezifika treffen. Das ist der Kern eines ECU-Penetrationstests und die Ebene, auf der unsere Penetrationstest-Methodik arbeitet.

Secure Boot — lässt sich die Vertrauenskette umgehen oder herabstufen?

Die Behauptung lautet, dass nur authentische, aktuelle Firmware ausgeführt wird. Wir greifen die Behauptung an, nicht die Kryptografie. Kann ein Image mit ungültiger oder verstümmelter Signatur dennoch booten? Ist der Vertrauensanker unveränderlich oder liegt er an einer neu beschreibbaren Stelle? Gibt es einen Downgrade-Pfad — akzeptiert das Gerät ein älteres, gültig signiertes Image mit bekannter Schwachstelle, weil Anti-Rollback-Zähler fehlen oder rücksetzbar sind? Verhält sich ein Fehler während der Prüfung fail-open oder fail-closed? Ist die Debug-/JTAG-Schnittstelle im Serien-Silizium wirklich per Fuse deaktiviert oder nur „in Software abgeschaltet“? Eine Vertrauenskette ist nur so stark wie ihr schwächstes Glied — und das schwache Glied ist nach unserer Erfahrung fast nie die Signaturprüfung selbst, sondern der Rollback-Schutz oder ein offener Debug-Port.

SecOC — Freshness, Replay und Fälschung

Secure Onboard Communication schützt Authentizität und Aktualität fahrzeuginterner Nachrichten. Wir prüfen alle drei Eigenschaften. Fälschung: Ein Frame mit gefälschtem oder fehlendem MAC muss abgewiesen werden. Replay: Ein zuvor gültiger, aufgezeichneter Frame, später erneut eingespielt, muss aufgrund seines veralteten Freshness-Werts abgewiesen werden — hier zeigen Implementierungen Schwächen, durch verkürzte Freshness, vorhersehbare Zähler oder Empfänger, die ein zu breites Freshness-Fenster akzeptieren. Behandlung von Prüffehlern: Ein anhaltender Strom ungültiger MACs darf nicht in einen Fail-open-Zustand oder einen Denial of Service auf dem Bus abgleiten. Wir achten besonders auf das Freshness-Management: Ein perfekter MAC über einem erratbaren Zähler ist kein Replay-Schutz.

UDS SecurityAccess (0x27) — Entropie, Brute Force und Replay

Das ist die häufigste Schwachstelle, die wir finden. Der Seed-Key-Mechanismus ist nur so stark wie seine Seed-Entropie und seine Sperrrichtlinie. Wir bewerten Seed-Entropie und -Vorhersagbarkeit (ist der „zufällige“ Seed in Wahrheit ein Zähler, ein Zeitstempel oder nach Reset ein fester Wert?), versuchen Seed-Key-Replay (entsperrt ein zuvor beobachteter gültiger Key denselben Seed weiterhin?), bewerten die Brute-Force-Resistenz gegenüber dem Schlüsselraum sowie das Verzögerungs- und Versuchsbegrenzungsverhalten und prüfen, dass die entsperrte Session nicht durch Zustandsautomaten-Missbrauch unter völligem Überspringen des Austauschs erreichbar ist. Ein 16-Bit-Seed ohne exponentielles Back-off ist keine Zugriffskontrolle, sondern eine Bodenschwelle.

Schlüsselmanagement — Extraktion und Provisionierung

Jede der obigen Maßnahmen beruht darauf, dass Schlüssel geheim bleiben. Wir bewerten, ob Schlüsselmaterial extrahierbar ist — aus externem Flash, aus Logs oder Diagnose, über Debug-Schnittstellen oder weil Schlüssel nie in die geschützte Grenze des HSM überführt wurden. Wir prüfen die Provisionierung gründlich: Sind Schlüssel je Steuergerät eindeutig oder über eine Flotte hinweg geteilt (sodass eine Extraktion alle kompromittiert)? Wird derselbe Schlüssel in Entwicklung und Serie wiederverwendet? Werden Testschlüssel im Feld noch als vertrauenswürdig behandelt? Ein makelloses HSM ist bedeutungslos, wenn der Schlüssel beim End-of-Line-Programmieren im Klartext geloggt wurde.

5. Negativ- und Missbrauchstests

Konventionelle Verifizierung wird vom Happy Path dominiert: Beweisen, dass das System das tut, was die Anforderungen vorschreiben. Sicherheitsverifizierung ist die umgekehrte Disziplin. Wir prüfen, was das System niemals tun darf — und „niemals“ lässt sich nicht dadurch belegen, dass man das beabsichtigte Verhalten bestätigt.

Negativtests bedeuten, gezielt die Bedingungen einzuspeisen, die eine positive Anforderung implizit verbietet: fehlerhafte Frames, Diagnoseanforderungen außerhalb der Reihenfolge, um ein Byte abweichende Signaturen, Freshness-Werte aus der Vergangenheit, über unerwartete Zustandsübergänge betretene Sessions. Missbrauchstests gehen weiter — sie verfolgen das Ziel eines Angreifers statt einer einzelnen Fehleingabe und verketten Schritte so, wie es ein realer Gegner täte: die Diagnoseoberfläche abtasten, einen ungeschützten Dienst finden, damit einen Speicherbereich lesen, einen Schlüssel wiederherstellen, ihn andernorts wieder einspielen.

Hier zeigen auch Anforderungen, die auf dem Papier perfekt lesbar sind, ihre Lücken. „Das Steuergerät muss Diagnoseanforderungen authentisieren“ ist eine gute Funktionsanforderung und eine schlechte Sicherheitsanforderung, denn sie sagt nichts darüber, was mit den tausend Anforderungsformen geschieht, die nicht der authentisierte Pfad sind. Im Missbrauchstest decken wir regelmäßig auf, dass ein Dienst in einem Session-Typ geschützt, in einem anderen aber exponiert war, oder dass ein Timing-Unterschied in der Fehlerantwort verrät, ob ein Rateversuch nah dran war. Das Fuzzing der Diagnose- und Kommunikationsschnittstellen gehört dazu — nicht um Robustheit im Abstrakten zu beweisen, sondern weil ein Absturz bei Fehleingabe häufig das erste Glied einer Kette ist, die bei Codeausführung endet. Nichts davon ist vom Happy Path aus sichtbar — konstruktionsbedingt.

6. Wenn der Pentest die TARA widerlegt

Das unbequeme — und wertvollste — Ergebnis ist, wenn ein Test dort gelingt, wo die TARA es ausschloss. Ein als „sehr gering“ machbar eingestufter Angriff funktioniert an einem Nachmittag. Das ist kein Versagen der TARA — es ist die TARA, die ihre Aufgabe erfüllt, indem sie falsifizierbar ist. Entscheidend ist, dass sich der Kreis schließt.

Widerspricht ein Befund der Analyse, fahren wir eine definierte Sequenz, statt einen Fehler zu protokollieren und weiterzugehen:

Angriffsmachbarkeit neu bewerten mit dem vorliegenden Nachweis. Das Gelegenheitsfenster, die Ausrüstung oder das Fachwissen, das die ursprüngliche Einstufung rechtfertigte, war falsch; korrigieren Sie es. Der Pfad, der „einen Experten und maßgefertigte Ausrüstung brauchte“, brauchte einen Laptop und einen Forenbeitrag.
Risiko neu bewerten. Eine höhere Machbarkeit bei gleichem Schaden treibt den Risikowert nach oben, was die Risikobehandlungsentscheidung vollständig ändern kann — was akzeptabel zu akzeptieren war, kann nun Reduktion verlangen.
Neu behandeln: Anforderungen ableiten oder verschärfen. Die neuen oder geänderten Cybersecurity-Anforderungen fließen zurück in die Produktentwicklung (Klausel 10) und von dort in die Umsetzung. Anti-Rollback-Zähler werden ergänzt; der Seed-Generator erhält echte Entropie; der Debug-Port wird per Fuse deaktiviert.
Neu verifizieren. Die Korrektur erhält ihren eigenen Missbrauchsfall und ihr eigenes Urteil. Eine nach Änderung nicht erneut getestete Maßnahme ist wieder nur eine Hypothese.

Genau das meint ISO/SAE 21434, wenn sie die TARA als lebendes Arbeitsergebnis behandelt und nicht als Meilenstein-Lieferung. Derselbe Kreislauf läuft nach SOP über das kontinuierliche Cybersecurity-Monitoring: Eine neu offengelegte Schwachstelle in einer geteilten Komponente ist faktisch ein von außen eintreffendes Ereignis zur Neubewertung der Machbarkeit und tritt bei Schritt 1 wieder ein. Eine finalisierte und abgelegte TARA ist eine TARA, die aufgehört hat, die Wahrheit zu sagen.

7. Nachweis und Verfolgbarkeit

All das Vorhergehende ist nur so viel wert wie die Kette, die es zusammenhält. Was ein Assessor — und hinter ihm eine UNECE-R155-Typgenehmigung — tatsächlich will, ist ein einziger, navigierbarer Faden vom Asset zum Urteil:

Asset → Bedrohungsszenario → Cybersecurity-Ziel → Cybersecurity-Anforderung → Maßnahme → Testfall → Urteil

Jedes Glied muss bidirektional sein. Vorwärts, damit kein Cybersecurity-Ziel ohne Anforderung, keine Anforderung ohne verifizierenden Test und kein Test ohne festgehaltenes Urteil bleibt. Rückwärts, damit jedes Testergebnis erklärbar ist — warum existiert dieser Missbrauchsfall, welche Bedrohung legt er still, welches Asset schützt er? Ein verwaister Test beweist nichts; eine ungetestete Anforderung schützt nichts. Die Verfolgbarkeit verwandelt einen Haufen Aktivität in eine Argumentation.

Diese Kette ist auch der natürliche Ort für die Begründung des Restrisikos. Wo ein Test durchfällt und das Restrisiko akzeptiert statt weiter gemindert wird, liegen Urteil, neu bewertete Machbarkeit und Akzeptanzbegründung auf demselben Faden — so ist die Entscheidung auditierbar, zuordenbar und bei späterer Machbarkeitsverschiebung erneut überprüfbar.

Für die Typgenehmigung nach R155 ist das kein Selbstzweck-Papierkram. R155 verpflichtet den Hersteller, über das Cyber Security Management System nachzuweisen, dass Risiken identifiziert und beherrscht werden und dass die zu ihrer Behandlung gewählten Maßnahmen auf ihre Wirksamkeit getestet wurden. „Beherrscht“ und „getestet“ sind genau die beiden Behauptungen, die ein Faden vom Asset zum Urteil belegt — der Verifizierungsnachweis verwandelt die TARA aus einer internen Analyse in einen belastbaren Teil der Typgenehmigungsakte. Wir behandeln den Faden als das eigentliche Produkt der gesamten Übung, mit den Testberichten als seinen Blättern; das Zusammenspiel von R155, CSMS und dieser Nachweiskette vertiefen wir in unserem Beitrag zur eingebetteten Cybersecurity unter UNECE R155. Eine Risikobewertung ist der Ort, an dem Sie entscheiden, was schiefgehen könnte. Die verfolgbare Verifizierungskette ist der Ort, an dem Sie beweisen, dass Sie recht hatten — oder am eigenen Prüfstand feststellen, dass Sie es nicht hatten.

Möchten Sie einen 30-minütigen Walkthrough zu Ihrem Projekt?

Keine NDA nötig. Sagen Sie uns die Norm, das Item bzw. Asset, den Assessor und Ihre Deadline. Innerhalb von 48 Stunden erhalten Sie eine einseitige Diagnose, abgebildet auf die obigen Punkte — Ihre, ob Sie uns beauftragen oder nicht.

Cyber-Walkthrough buchen

Autor: Adrian Valea, Gründer & Geschäftsführer, SafetyTrust Software Technology GmbH. ASPICE Provisional Assessor (intacs / VDA), Functional Safety Engineer (TÜV Rheinland), Automotive Cybersecurity (TÜV NORD). Veröffentlicht 2026-06-02.

Von TARA zum Angriff die Wirksamkeit Ihrer Maßnahmen nachweisen.