Automatisierter ECU-Security-Test vs. manueller Penetrationstest

Was ist der Unterschied?

Automatisierter ECU-Security-Test ist Software am Prüfstand, die einem Steuergerät tausende Fragen stellt, deren Antwortmuster schon bekannt ist: Welche Sessions öffnen sich, welche der 255 Service Identifier antworten in welcher Session, welche DIDs sind lesbar oder schreibbar, wiederholt sich der SecurityAccess-Seed, was passiert mit dem Steuergerät, wenn ein ISO-TP First Frame eine unmögliche Länge ankündigt. Ein manueller Penetrationstest ist ein Engineer, der Fragen stellt, die noch niemand aufgeschrieben hat: Wozu gibt es diese Routine, was akzeptiert der Bootloader nach einem Reset, lässt sich die Kalibrierschnittstelle mit einer schreibbaren DID zu einer dauerhaften Änderung kombinieren.

Die beiden konkurrieren nicht. Automatisierung liefert Abdeckung und Nachweis bei jeder Firmware-Version. Der Pentester liefert Verständnis und findet den Angriffspfad, der Komponenten überschreitet. Ein guter ECU-Penetrationstest enthält schon heute beides: Der Tester lässt Enumeration und Fuzzing im Hintergrund laufen und steckt die bezahlten Tage dorthin, wo Tools blind sind.

Nebeneinander

	Automatisierter ECU-Test	Manueller Penetrationstest
Findet	Services in der falschen Session erreichbar, lesbare und schreibbare DIDs, schwache oder konstante Seeds, fehlende Versuchszähler, Parser-Crashes und Hänger beim Fuzzing, offenes XCP/CCP, DoIP-Routing zu gesperrten Steuergeräten, offene SOME/IP-Services, ADB und debuggbare Apps auf IVI-Einheiten	Logikfehler in der Diagnose-Zustandsmaschine, aus der Firmware rekonstruierte Seed/Key-Algorithmen, Bootloader- und Update-Schwächen, Ketten über Schnittstellen hinweg, Designfehler im Security-Konzept, alles Neue
Übersieht	Kontext, Absicht, verkettete Angriffe, Firmware-Interna, alles ohne Muster	Breite in der Fläche, Regressionen zwischen den Tests, lange Fuzzing-Läufe; begrenzt durch die gebuchten Tage und den vereinbarten Scope
Wer macht es	Deine Test- oder QA-Engineers, mit dem Steuergerät am Prüfstand	Externe oder interne Security Engineers mit Scope und Spielregeln
Prüfstandszeit	Minuten für die Enumeration, Stunden für Fuzzing, unbeaufsichtigt	Zwei bis sechs Wochen pro Steuergerät inklusive Bericht
Kosten	Lizenz pro getesteter Komponente, Preis auf Anfrage; die Prüfstandshardware hast du schon	20.000 bis 45.000 Euro pro Steuergerät, typische Spanne für Deutschland und die EU, kein Angebot
Passt in den Release-Zyklus	Ja, bei jedem Build über API oder CI-Plugin	Nein, ein Zeitpunkt, meist einmal pro Plattformgeneration und nach großen Änderungen
Verlangt von	ISO/SAE 21434 Clause 10.4.2 [RC-10-12] empfiehlt Komponententests mit Fuzzing und Schwachstellen-Scans; UN R155 verlangt angemessene und ausreichende Tests	ISO/SAE 21434 Clause 11 [RQ-11-01] nennt Penetrationstests für die Validierung; OEM-Anforderungskataloge und Kundenverträge
Ergebnis	PDF-Bericht pro Lauf, SARIF-Export, Scan-Historie, ein priorisierter Fix Plan	Bericht mit Reproduktionsschritten, Schweregrad im Kontext, Angriffsketten und Fixes; Debrief und Retest

Nimm automatisierte Tests, wenn

• du dasselbe Steuergerät in vielen Varianten auslieferst oder mehrmals im Jahr Firmware freigibst. Dieselben Checks jedes Mal von Hand zu fahren ist langsamer, weniger konsistent, und nach dem zweiten Release macht es niemand mehr.
• die Schwächeklasse eine ist, in der Tools gut sind: Sessions und Services, DIDs, SecurityAccess-Zähler und -Verzögerungen, Robustheit unter fehlerhaftem UDS- und CAN-Verkehr, DoIP-Routing, SOME/IP-Exposition, Android-Härtung.
• du Nachweise brauchst, nicht Geschichten. Ein Auditor, der fragt “Was habt ihr wann getestet, und was ist aus jedem Finding geworden”, ist mit datierter Scan-Historie und einer SARIF-Datei besser bedient als mit einem PDF von vor zwei Jahren.
• noch kein Budget für einen Pentest da ist. Fix zuerst, was die Automatisierung findet; ein Tester, der bezahlte Tage mit einer schreibbaren Seriennummer-DID verbringt, ist ein verschenkter Pentest.

Für Regressionstests und Protokollrobustheit ist Automatisierung schlicht die bessere Wahl.

Nimm einen manuellen Penetrationstest, wenn

• die Plattform neu ist: eine neue Mikrocontroller-Familie, ein neuer Bootloader, ein neuer Diagnose-Stack, das erste Ethernet-Steuergerät. Jemand muss es verstehen, bevor sich daran irgendetwas automatisieren lässt.
• die Security-Ziele Logik betreffen: Wer darf welches Level entsperren, wem vertraut der Update-Pfad, wie entscheidet das Gateway, was es routet. Kein Tool weiß, was erlaubt sein soll.
• ein Kunde, ein OEM oder ein Assessor einen Penetrationstest mit benanntem Tester und Methodenbeschreibung verlangt. Das meint Clause 11 der ISO/SAE 21434 mit Validierung.
• Findings verkettet und bewertet werden müssen. Die Automatisierung meldet eine schreibbare DID und einen schwachen Seed als zwei Findings; ein Tester zeigt, dass beide zusammen dauerhafte Codeausführung ergeben.

Beides zusammen

Das sinnvolle Setup sind automatisierte Tests bei jedem Build plus ein manueller Penetrationstest pro Plattformgeneration und vor SOP, mit den automatisierten Ergebnissen in der Hand des Testers. Der Tester überspringt das Offensichtliche, die Tage gehen in Firmware, Bootloader und Ketten, und die automatisierte Suite hält zwischen den Tests Wache, damit der Pentest-Bericht nicht leise abläuft.

Zyberum baut AutoST und setzt trotzdem auf jede neue Plattform einen Engineer an. Wir sind genau darin, was das Produkt tut: AutoST findet das Bekannte, die Regressionen und die Crashes und schreibt den Nachweis. Es ist kein Penetrationstest, und wir verkaufen es nicht als einen. Wenn ein Anbieter dir einen vollständigen ECU-Pentest allein aus einem Tool verspricht, frag, wer die Ergebnisse gelesen hat.