So schreibst du einen Security-Testplan für ein Steuergerät

Ein Security-Testplan für ein Steuergerät ist ein kurzes Dokument, das die TARA in Testfälle übersetzt, die du ausführen und prüfen kannst. Er beantwortet fünf Fragen, bevor der erste Frame auf den Bus geht: was genau getestet wird (Item, Variante, Softwarestand, Schnittstellen), an welchem Prüfstand, welcher Testfall welches Bedrohungsszenario abdeckt, welches Ergebnis als bestanden gilt und in welcher Reihenfolge die Tests laufen, damit ein hängendes Steuergerät dich keinen Tag kostet. Ein Plan, der nur “UDS-Fuzzing, SecurityAccess, Penetrationstest” sagt, ist eine Liste von Aktivitäten. Ein Plan, der sagt “TC-12: in der Extended-Session muss 2E F1 8C mit beliebigem Payload im gesperrten Zustand 7F 2E 33 liefern”, wird von zwei Testern gleich ausgeführt.

Starte bei der TARA, nicht bei der Tool-Liste

Jeder Testfall sollte existieren, weil ein Bedrohungsszenario oder eine Cybersecurity-Anforderung ihn verlangt. Nimm die Bedrohungsszenarien aus der TARA (ISO/SAE 21434 Clause 15), die Cybersecurity-Ziele und die daraus abgeleiteten Anforderungen und frage dich bei jedem: welches beobachtbare Verhalten am Prüfstand zeigt, dass die Maßnahme wirkt?

Bedrohungsszenario	Anforderung	Testfall
Manipulation von Identifikationsdaten	Identifikations-DIDs nur nach SecurityAccess beschreibbar	TC-12: Schreibprobe auf F18C, F190 im gesperrten Zustand
Unautorisiertes Umprogrammieren	RequestDownload (0x34) nur nach SecurityAccess	TC-20: 10 02, dann 34 ohne Entsperren
Brute Force auf SecurityAccess	Lockout nach 3 ungültigen Keys, 10 s Verzögerung	TC-31: Serie ungültiger Keys, erwartet 7F 27 36, dann 7F 27 37
Denial of Service über Diagnose	Steuergerät übersteht fehlerhafte Requests	TC-40: UDS-Fuzzing-Kampagne, Liveness nach jeder Iteration

Generische Oberflächen-Checks, die jedes Steuergerät bekommt (Enumeration von Sessions und Services, Identifikations-DIDs, Qualität des SecurityAccess), gehören ebenfalls hinein, auch wenn die TARA dazu schweigt. Solche Checks sind billig und finden, was die TARA übersehen hat.

Lege Scope und Prüfstand fest

Der Scope-Abschnitt nennt Variante, Hardwarestand und den Softwarestand, wie das Steuergerät ihn selbst meldet (22 F1 89, 22 F1 95), die Schnittstellen im Scope und die ausdrücklich ausgeschlossenen. Der Prüfstand-Abschnitt sorgt dafür, dass jemand anders ein Finding auch sechs Monate später reproduziert:

• Interface und Adapter, Bitrate und bei CAN FD Datenbitrate und Sample Point.
• Request- und Response-IDs (zum Beispiel 0x7E0 und 0x7E8), Adressierungsmodus, ISO-TP-Padding-Byte.
• Bei DoIP: logische Adressen und Routing-Activation-Typ. Bei einem IVI: Build-Fingerprint und ADB-Transport.
• Der ODX-, CDD- oder DBC-Stand, gegen den du testest, und die Zugangsdaten, die du hast (Security-Level, Keys).
• Ein Wiederherstellungsweg: wie du neu flashst, wie du remote einen Power-Cycle machst, wen du anrufst, wenn das Steuergerät tot bleibt.

Schreib Pass-Kriterien in Bytes

Ein Pass-Kriterium, das sich nicht durch Vergleich einer Response prüfen lässt, ist eine Meinung. Schreib den Request, die erwartete Response und die Bedingung, unter der sie gilt.

TC-20  RequestDownload erfordert SecurityAccess
Vorb.:   Default-Session, Security gesperrt
Schritt: 10 02            -> 50 02 ...   (oder 7F 10 22, falls Bedingungen greifen)
Schritt: 34 00 44 00 00 00 00 00 01 00 00
Pass:    7F 34 33 (securityAccessDenied)
Fail:    74 ...  (Download im gesperrten Zustand akzeptiert)

Für Kampagnen schreibst du die Abdeckung statt einer einzelnen Response: “SIDs 0x00 bis 0xFE in den Sessions 01, 03 und jeder herstellerspezifischen Session, die geantwortet hat”, “10.000 UDS-Fuzzing-Iterationen je ausgewähltem SID, Seed protokolliert, TesterPresent-Liveness nach jeder Iteration”. Mit der Abdeckungszahl beurteilt ein Assessor, ob der Test nach ISO/SAE 21434 Clause 10.4.2 ausreichend war.

Ordne nach Risiko für das Steuergerät

Die Reihenfolge ist wichtiger, als viele denken. Erst laufen die Tests, die nur lesen, dann die, die schreiben, dann die, die das Steuergerät aus dem Tritt bringen können.

1. Discovery. Endpoint-Scan, Session-Discovery, Service-Sweep, DID-Lesen. Nicht-destruktiv und die Grundlage für alles Weitere.
2. Zugriffsschutz. Seed-Qualität bei SecurityAccess, Attempt-Counter und Verzögerung, Schreibproben auf DIDs und Routinen-Proben.
3. Session- und Reset-Verhalten. Rückfall der Session, S3-Timeout, Security-Zustand nach einem Reset.
4. Robustheit. UDS- und CAN-Fuzzing, fehlerhafte ISO-TP-Frames.
5. Manuelle Arbeit. Die tieferen Tests des Pentesters an dem, was die vorigen Schritte zutage gebracht haben.

Aus Schritt 1 und 2 kommen an den Prüfständen, an denen wir arbeiten, die meisten Findings. Schritt 3 und 4 können das Steuergerät in einem Fehlerzustand zurücklassen, deshalb kommen sie später und tragen einen Freigabevermerk.

Plane die Nachweise vor dem Test

Leg vorher fest, was du je Testfall aufbewahrst: das rohe Bus-Log, Request und Response, die Tool-Version, das Datum und den getesteten Softwarestand. Leg fest, wie ein Finding bewertet wird (ein Schema, benannt) und wohin es danach geht (Ticket, ALM-Referenz). Ein bestandener Testfall ist auch ein Nachweis: halte ihn fest, denn die sauberen Ergebnisse belegen, dass eine Maßnahme wirkt.

Der Re-Test gehört zum Plan

Die meisten Steuergeräte werden mehr als einmal getestet: nach einem Fix, nach einem neuen Software-Release, vor dem Produktionsstart. Halte die Testfall-Kennungen über Durchläufe stabil, damit sich TC-12 auf Software 0x0142 und TC-12 auf 0x0143 Zeile für Zeile vergleichen lassen. Laufen die wiederholbaren Fälle bei jedem Release automatisch, fließt der manuelle Aufwand in das, was sich geändert hat.

Wo AutoST passt

AutoST deckt den wiederholbaren Teil eines solchen Plans ab: Discovery, ODX- und CDD-gestütztes Prüfen von DIDs und Routinen, SecurityAccess-Checks, UDS- und CAN-Fuzzing, DoIP-, SOME/IP- und Android-IVI-Checks, jeweils mit protokollierten Requests, Responses und Abdeckung sowie einem PDF und SARIF-Export pro Lauf. Den Plan oder die TARA schreibt es dir nicht, und die manuellen Testfälle bleiben beim Penetrationstester. Was sich ändert: dieselben Testfälle laufen jedes Mal identisch, und genau das braucht ein Re-Test.