AutoST für Tier-1-Zulieferer: Teste dein Steuergerät, bevor der OEM es tut

Die Aufgabe

Ein Tier-1-Zulieferer bekommt vom OEM eine Cybersecurity-Anforderungsspezifikation, baut das Steuergerät und muss in einem Verifikationsbericht zeigen, dass jede Anforderung erfüllt ist. Nach ISO/SAE 21434 Clause 7 steht die Arbeitsteilung in einem Cybersecurity Interface Agreement: wer die TARA macht, wer welche Maßnahme verifiziert, wer welches Work Product liefert. Das Testen landet fast immer beim Zulieferer, für jede Musterphase, für jede OEM-Variante und für jedes Software-Release nach dem Produktionsstart.

Am Prüfstand sieht die Realität anders aus als im Agreement. In Penetrationstests von Leistungselektronik-Steuergeräten für Tier-1-Zulieferer, darunter ein DC/DC-Wandler und ein On-Board-Charger, haben wir SecurityAccess-Seeds gefunden, die konstant waren oder aus der Laufzeit abgeleitet wurden, keinen Fehlversuchszähler nach falschen Keys, Identifikations-DIDs wie Seriennummer und Fingerprints, die ohne SecurityAccess beschreibbar waren, und Resets bei fehlerhaften ISO-TP First Frames. Nichts davon war intern aufgefallen, denn der einzige Test vor dem Pentest war der Diagnosetester, der prüft, ob die spezifizierten Services funktionieren.

Was die Rolle aus einem Testlauf braucht

Die Test- und Cybersecurity-Ingenieure beim Zulieferer brauchen einen Lauf, der zum Mustertakt passt und den Entwicklern etwas Konkretes in die Hand gibt.

• Ein wiederholbares Profil pro Musterphase. Dieselbe Enumeration von Sessions, Services und DIDs, dieselbe SecurityAccess-Prüfung (0x27) und dasselbe Seeded Fuzzing vor A-, B- und C-Muster. Eine Regression zwischen zwei Releases zeigt sich so als Diff und nicht als Überraschung im Labor des OEM.
• Die eigene Diagnosebeschreibung. Der ODX- oder CDD-Import benennt jede DID und ruft die Routinen auf, die das Steuergerät wirklich definiert. Die Schreibtests auf DIDs (0x2E) prüfen, was das Steuergerät annimmt, mit Bestätigung, bevor irgendetwas geschrieben wird.
• SecurityAccess-Prüfungen, die zur Implementierung passen. Zufälligkeit der Seeds über viele Requests, Key-Rückgewinnung bei schwachen Algorithmen und ein Katalog bekannter Default-Keys, Sperre nach falschen Keys, erzwungene Reihenfolge und der optionale Reset-Test. Der Zulieferer hat den Algorithmus geschrieben; der Lauf sagt ihm, ob er hält.
• Reproduzierbares Fuzzing. Ein gespeicherter Seed pro Lauf und die exakte Payload pro Finding, damit der Firmware-Entwickler den ISO-TP-Frame oder das übergroße TransferData nachspielen kann, das das Steuergerät aufgehängt hat.
• Ausgaben für Entwickler. Fix-Plan-Aufgaben, nach Schweregrad sortiert, mit Was, Risiko und Fix, exportiert als SARIF, CSV oder JSON in den Tracker, den das Team schon nutzt, und ein PDF für den OEM.

Typisches Setup

Der Prüfstand existiert schon: Steuergerät, Netzteil, Restbussimulation, ein CAN-Interface. Der Carbyne-Agent läuft auf dem Prüfstands-PC, unter Windows mit Vector-Hardware über die XL Driver Library oder unter Linux mit PEAK, Kvaser oder jedem anderen SocketCAN-Interface. Für Steuergeräte an Automotive Ethernet laufen DoIP und SOME/IP über den normalen Netzwerkport. Der Agent pollt das Backend über HTTPS.

Die meisten Tier-1 installieren AutoST auf eigenen Servern, weil Diagnosebeschreibungen des OEM und Firmware-Details vertraulich sind; kleinere Standorte nutzen die von Zyberum in der EU gehostete Instanz und behalten den Agenten lokal. Der Cybersecurity-Manager besitzt das Testprofil und die Risikogewichtung, der Testingenieur fährt die Scans am Ende jedes Integrationszyklus, und das Firmware-Team arbeitet den Fix Plan ab. Lizenziert wird pro getesteter Komponente, eine Steuergerätefamilie mit mehreren OEM-Varianten ist also ein Gespräch, nicht mehrere.

Ein sinnvolles erstes Projekt

Mach den Pilot an einem Steuergerät in der B-Muster-Phase, für das es eine Cybersecurity-Anforderungsspezifikation gibt, gegen die du prüfen kannst.

1. Woche 1: Umfang. Steuergerät auswählen, ODX oder CDD anhängen, die SecurityAccess-Level auflisten und die Services, die nur in Extended oder Programming Session erreichbar sein dürfen. Den Agenten am vorhandenen Prüfstand installieren und koppeln.
2. Woche 2: Baseline. Enumeration über alle Sessions, DID- und Routinen-Scan, SecurityAccess-Prüfung. Die Findings mit dem Firmware-Lead durchgehen und festlegen, was ein Bug ist, was akzeptiert wird und was der OEM wissen muss.
3. Wochen 3 und 4: Fuzzing. Seeded UDS-Fuzzing auf den Services, die das Steuergerät anbietet, mit TesterPresent-Lebenszeichen und DTC-Überwachung. Jeden Crash einmal reproduzieren, bevor er in den Fix Plan geht.
4. Wochen 5 und 6: Fix und Retest. Die Entwickler arbeiten die priorisierten Aufgaben ab; dasselbe Profil läuft erneut. Akzeptierte Risiken und Kommentare bleiben erhalten, das zweite PDF zeigt genau, was geschlossen wurde.
5. Übergabe. Das PDF an den Verifikationsbericht für das C-Muster hängen und entscheiden, ob das Profil Teil jedes Releases wird.

Wie Ergebnisse in ISO/SAE 21434 und UN R155 fließen

ISO/SAE 21434:2021 Clause 10.4.2 fordert, dass die Implementierung gegen die Cybersecurity-Spezifikation verifiziert wird ([RQ-10-09]), und empfiehlt Komponententests mit Fuzz-Testing und Schwachstellen-Scans ([RC-10-12]). Das AutoST-PDF mit seiner datierten Scan-Historie ist der Nachweis auf Komponentenebene hinter diesem Verifikationsbericht, und die ALM/PLM-Referenz im Fix Plan verbindet jedes Finding mit der Anforderung oder dem Ticket, zu dem es gehört. Die Validierung nach Clause 11 ([RQ-11-01]) nennt Penetrationstests; AutoST ist die Baseline dafür, kein Ersatz. Clause 8.5 behandelt die Schwachstellenanalyse als fortlaufende Aktivität, und ein Profillauf vor jedem Release liefert genau das ohne zusätzlichen Prozess.

UN R155 richtet sich an den Fahrzeughersteller, aber Absatz 7.2.2.5 verlangt, dass der Hersteller zeigt, wie sein CSMS die Abhängigkeiten von Zulieferern steuert. Deshalb fragen OEMs nach Testnachweisen der Zulieferer gegen die Bedrohungen aus Anhang 5. UN R156 macht dasselbe für jedes Software-Update nach der Genehmigung. Bei der Unterstützung eines R155-Audits bei einem Tier-1 lag die Lücke nie im Testen selbst, sondern im Nachweis, welcher Test welche Anforderung abdeckt und wann er zuletzt lief. Eine Historie pro Komponente mit reproduzierbaren Läufen schließt diese Lücke. AutoST ist keine Zertifizierung und macht das Steuergerät nicht konform; es erzeugt die Nachweise, die das Agreement mit deinem OEM verlangt.