# Was in einen ECU-Pentest-Bericht gehört

Die Abschnitte, die ein ECU-Pentest-Bericht braucht: Scope, Prüfstand, reproduzierbare Findings, Bewertung, Nachweise und Re-Test, damit Fixen und Nachverfolgen geht.

Source: https://auto-st.com/de/insights/was-in-einen-ecu-pentest-bericht-gehoert · Updated: 2026-10-07

Ein ECU-Penetrationstest-Bericht ist gut, wenn zwei Menschen damit arbeiten können, ohne den Tester anzurufen: der Entwickler, der ein Finding beheben muss, und der Assessor, der es auf ein Bedrohungsszenario in der TARA zurückführen muss. Dafür braucht es sieben Teile: Scope und Item-Grenze, den Prüfstand bis hin zu Firmware-Version und Bitrate, die Methode mit ihrer Abdeckung, Findings mit den exakten Bytes zum Reproduzieren, eine Bewertung mit Begründung, datierte Nachweise und den Re-Test mit dem Restrisiko. Eine Zeile wie "schwacher SecurityAccess, hoch" ohne Seed-Werte und Request-Trace ist eine Meinung, kein Nachweis.

## Scope und Item-Grenze

Beginne mit dem, was getestet wurde, und genauso wichtig, was nicht. Nenne die Steuergeräte-Variante und den Hardwarestand, die Softwareversion, wie das Steuergerät sie selbst meldet (zum Beispiel `22 F1 89` für die Applikationssoftware-Version, `22 F1 95` für die Zulieferer-Softwareversion), die Schnittstellen im Scope sowie die Sessions und Security-Level, für die der Tester Zugangsdaten hatte.

| Punkt | Warum der Leser ihn braucht |
| --- | --- |
| Variante, Hardware- und Softwarestand | Ein Finding auf Software 0x0142 kann in 0x0143 schon behoben sein |
| Schnittstellen im Scope (CAN 500 kbit/s, DoIP, ADB) | Eine nicht genannte Schnittstelle gilt als ungetestet, nicht als sauber |
| Verfügbare Sessions und Security-Level | Erklärt, warum Findings aus der Programming-Session fehlen können |
| Explizite Ausschlüsse (Hardware-Angriffe, Firmware-Extraktion, Schlüsselmaterial) | Verhindert, dass der Assessor Abdeckung annimmt |

## Prüfstand

Ein Leser muss den Prüfstand nachbauen können. Halte CAN-Interface und Adapter fest, das ISO-TP-Adresspaar (`0x7E0` Request, `0x7E8` Response) und den Adressierungsmodus, die verwendeten Timing-Parameter (P2, P2\*, S3), den DBC- oder ODX-Stand, die Tool-Versionen, das Datum und den Tester. Bei einem DoIP-Ziel kommen logische Adressen und der Routing-Activation-Typ dazu, bei einer IVI-Einheit der Android-Build-Fingerprint und der ADB-Transport.

## Methode und Abdeckung

Liste pro Angriffsfläche auf, was gemacht wurde und wie weit. Abdeckungszahlen sind das, womit ein Assessor die Angemessenheit nach ISO/SAE 21434 Clause 10.4.2 ([RQ-10-09], [RC-10-12]) beurteilt:

- Enumeration: alle Service Identifier 0x00 bis 0xFE in den Sessions 0x01, 0x02 und 0x03, dazu die herstellerspezifischen Sessions, die geantwortet haben.
- Data Identifier: der gelesene Bereich (0xF180 bis 0xF19F oder der volle Raum 0x0000 bis 0xFFFF) je Session.
- SecurityAccess: getestete Level, Anzahl gesammelter Seeds, beobachtetes Lockout-Verhalten.
- Fuzzing: Kampagnen mit Seed, Iterationszahl, Service Identifier im Scope und die verwendeten Monitore.
- Netzwerk: Ergebnisse von DoIP Vehicle Discovery und Routing Activation, gefundene SOME/IP-Services.

## Findings, die sich reproduzieren lassen

Jedes Finding bekommt dieselbe Struktur: eine Kennung, einen Titel, die betroffene Schnittstelle und Session, die Vorbedingungen, den exakten Request und die Response, das erwartete Verhalten, die Auswirkung, eine Bewertung, eine Behebung und den Verweis auf das TARA-Bedrohungsszenario und die Cybersecurity-Anforderung, gegen die es verstößt. Ein Beispiel in dem Format, das wir verwenden:

```
F-07  WriteDataByIdentifier ohne SecurityAccess akzeptiert
Schnittstelle: CAN 0x7E0/0x7E8, Session: Extended (10 03), Security: gesperrt
Request:   2E F1 8C 41 42 43 44 45 46 47 48
Response:  6E F1 8C
Erwartet:  7F 2E 33 (securityAccessDenied)
Auswirkung: Seriennummer (DID F18C) von jedem Tester am Bus beschreibbar
Referenz:  TS-14 (Manipulation von Identifikationsdaten), CSR-022
```

Die erwartete Antwort ist die Zeile, die in den meisten Berichten fehlt, und die, die Diskussionen beendet. ISO 14229-1 sagt, was das Steuergerät hätte antworten müssen; die Spezifikation sagt, welche DIDs in welcher Session beschreibbar sind.

## Bewertung mit Begründung

Wähle ein Bewertungsschema, nenne es im Bericht und wende es auf jedes Finding gleich an. Für ein TARA-getriebenes Programm passen die Impact- und Attack-Feasibility-Bewertungen aus ISO/SAE 21434 Clause 15 am besten, weil das Finding dann direkt im Risikobild landet; CVSS 3.1 ist für softwareartige Findings auf einem IVI in Ordnung. In beiden Fällen gehört die Begründung dazu: "Attack Feasibility hoch, weil der Key mit einem konstanten XOR aus dem Seed abgeleitet wird und der Bus vom OBD-Stecker aus erreichbar ist". Eine Bewertung ohne Begründung ist das Erste, was ein Auditor anzweifelt.

Liste auch auf, was sauber war. "SecurityAccess Level 1: Lockout nach drei ungültigen Keys, 10 s Verzögerung, Seeds haben die Zufallsprüfungen bestanden" ist ein Ergebnis, und zwar das, das die Wirksamkeit der Maßnahme belegt.

## Nachweise

Nachweise sind roh, datiert und zuordenbar: Bus-Logs oder Captures für jedes Finding, Screenshots und logcat-Auszüge für IVI-Findings, der Fuzzing-Seed, der einen Crash auslöst, Hashes der getesteten Firmware. Lege sie in Anhänge oder liefere sie maschinenlesbar. SARIF 2.1.0 ist das praktische Format für die Findings selbst, weil es in die Code-Scanning-Ansichten importiert, die Entwickler ohnehin nutzen.

## Re-Test und Restrisiko

Der Bericht ist nicht fertig, wenn die Findings übergeben sind. Nach den Fixes bekommt jedes Finding einen Status: behoben und verifiziert auf welchem Softwarestand, mitigiert wodurch, als Restrisiko akzeptiert von wem und wann, oder weiterhin offen. Der Schlussabschnitt benennt das Restrisiko in klaren Worten. Diese Seite liest der Assessor zuerst.

## Was AutoST beiträgt

AutoST schreibt den wiederholbaren Teil dieses Berichts automatisch: den Scope mit Steuergerät, Schnittstelle und Sessions, die Abdeckungszahlen, jedes Finding mit Request- und Response-Bytes, den Risiko-Score mit den Gewichten dahinter, ein PDF mit Nichtabstreitbarkeits-Fußzeile und einen SARIF-Export. Der Fix Plan trägt Status, Verantwortlichen und eine ALM/PLM-Referenz pro Finding über Re-Tests hinweg, sodass sich der Re-Test-Abschnitt von selbst schreibt. Die Einordnung, die Zuordnung zu deinen Bedrohungsszenarien und die Findings, die einen Menschen brauchen, bleiben beim Penetrationstester.

## FAQ

**Wie detailliert muss ein Finding sein?**

So detailliert, dass ein Entwickler es reproduziert, ohne den Tester anzurufen: Session, Security-Zustand, die exakten Request-Bytes, die Antwort des Steuergeräts und die Antwort, die Norm oder Spezifikation erwartet hätten.

**Soll der Bericht auch auflisten, was nicht gefunden wurde?**

Ja. Negative Ergebnisse belegen die Abdeckung. Ein Assessor, der liest, dass alle 255 Service Identifier in drei Sessions geprüft wurden und SecurityAccess nach drei falschen Keys gesperrt hat, kann beurteilen, ob der Test ausreichend war.

**Welches Bewertungsschema passt zu einem ECU-Bericht?**

Eines, das benannt und konsequent angewendet wird. CVSS 3.1 passt zu softwareartigen Findings, die Impact- und Attack-Feasibility-Bewertung aus ISO/SAE 21434 Clause 15 passt besser zu einer TARA. Die Begründung hinter jeder Bewertung zählt mehr als das Schema.

**Kann ein Tool den Bericht schreiben?**

Ein Tool schreibt den wiederholbaren Teil: Scope, Abdeckungszahlen, Findings mit Bytes und eine datierte Nachweisdatei. Die Einordnung, die Zuordnung zu Bedrohungsszenarien und die manuellen Findings kommen vom Penetrationstester.

## Sources

- [ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering, Clauses 10 und 11](https://www.iso.org/standard/70918.html)
- [ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1](https://www.iso.org/standard/72439.html)
- [OASIS SARIF 2.1.0 (Static Analysis Results Interchange Format)](https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html)

## Related

- [Nachverfolgbarkeit im ISO 21434 Audit: Fuzzing zählbar machen](https://auto-st.com/de/insights/traceability-iso-21434-audit)
- [ISO/SAE 21434 Verifikationsnachweise aus Security-Tests](https://auto-st.com/de/insights/iso-21434-verifikationsnachweise)
- [So schreibst du einen Security-Testplan für ein Steuergerät](https://auto-st.com/de/insights/ecu-security-testplan)
- [SARIF (Static Analysis Results Interchange Format)](https://auto-st.com/de/glossar/sarif)
- [Eine Zahl, die du verteidigen kannst, Nachweise, die du ablegen kannst.](https://auto-st.com/de/risikobewertung-reports)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/de/insights/was-in-einen-ecu-pentest-bericht-gehoert