AutoST für OEM-Security-Teams: Zulieferer-Steuergeräte, Gateways, Fahrzeugnetz

Die Aufgabe

Ein OEM-Security-Team verantwortet die Cybersecurity des Fahrzeugs, schreibt aber fast keine Steuergeräte-Firmware selbst. Dutzende Steuergeräte kommen von einem Dutzend Zulieferern, jedes mit eigenem Diagnose-Stack, eigenem SecurityAccess-Algorithmus und einer eigenen Vorstellung davon, was “getestet” bedeutet. Das Team setzt die Anforderungen, nimmt die Work Products ab und muss bei der Typgenehmigung zeigen, dass die Maßnahmen aus UN R155 Anhang 5 am ausgelieferten Fahrzeug halten.

In einem Komplettfahrzeug-Penetrationstest für einen OEM waren die meisten kritischen Findings nicht raffiniert. Ein Gateway routete DoIP-Requests zu Steuergeräten, die gesperrt sein sollten. Ein Karosserie-Steuergerät bot ECUReset und RoutineControl in der Default Session an. Zwei Zulieferer hatten SecurityAccess-Keys, die sich aus dem Seed mit einer kurzen Konstante berechnen ließen. Jedes davon hätte eine wiederholbare Prüfung auf dem Prüfstand des Zulieferers gefunden, Monate früher und für einen Bruchteil der Kosten.

Was die Rolle aus einem Testlauf braucht

Das Team braucht denselben Test auf jedem Steuergerät, mit Ergebnissen, die sich über Zulieferer hinweg vergleichen lassen.

• Ein Testset für alle Zulieferer. UDS-Enumeration von Sessions, Services und DIDs, SecurityAccess-Prüfung (0x27) und Fuzzing laufen auf einem Leistungselektronik-Steuergerät genauso wie auf einer Infotainment-Einheit. Die Ergebnisse stehen in einer Tabelle statt in dreißig unterschiedlich formatierten Zuliefererberichten.
• Die Gateway- und Netzwerksicht. DoIP Vehicle Discovery und Routing Activation, UDS über DoIP zu den Steuergeräten hinter dem Gateway und SOME/IP Service Discovery zeigen, was vom Diagnoseport und aus dem Fahrzeugnetz erreichbar ist, nicht nur, was jeder Zulieferer isoliert getestet hat.
• Einen Score zum Priorisieren. Der gewichtete Risiko-Score von 0 bis 10 pro Steuergerät, eingestellt auf das Risikomodell des OEM, sagt dem Programm, welches Steuergerät zuerst eskaliert wird.
• Nachweise, die ein Audit überstehen. PDF-Berichte mit datierter Historie pro Komponente, SARIF für die Werkzeuge und ein Fix Plan, dessen Aufgaben eine ALM/PLM-Referenz zur zugehörigen Anforderung tragen.
• Trennung zwischen Zulieferern. Gruppen und rollenbasierter Zugriff, damit Zulieferer A nie die Findings von Zulieferer B sieht.

Was das Team von AutoST nicht bekommt, ist ein Ersatz für den Penetrationstest. AutoST deckt den wiederholbaren Teil der Diagnose- und Bus-Angriffsfläche ab; der Fahrzeug-Pentest und die harten Ziele (Secure Boot, HSM, Schlüsselspeicher) bleiben bei Spezialisten.

Typisches Setup

AutoST läuft gehostet von Zyberum in der EU oder als Container auf den Servern des OEM. OEMs wählen fast immer On-Premises, mit dem Dashboard im Firmennetz und den Test-Agenten in den Laboren. Der Carbyne-Agent steht an jedem Prüfstand, unter Windows mit Vector-Hardware über die XL Driver Library oder unter Linux mit jedem SocketCAN-Interface wie PEAK oder Kvaser, dazu Ethernet für DoIP und SOME/IP. Der Agent pollt das Backend über HTTPS, im Labornetz werden also keine eingehenden Ports geöffnet.

Wer macht was: Das zentrale Security-Team definiert Testprofile und Risikogewichtung und besitzt das Dashboard. Komponententeams oder die Resident Engineers der Zulieferer fahren die Scans auf ihren Prüfständen. Mehrere OEMs geben wichtigen Zulieferern Zugang, damit diese dasselbe Profil vor der Lieferung laufen lassen; das OEM-Team vergleicht das Ergebnis mit dem eigenen Lauf. Lizenziert wird pro getesteter Komponente, der Preis kommt nach einer Demo.

Ein sinnvolles erstes Projekt

Fang mit einem Gateway und den zwei oder drei Steuergeräten dahinter an, für die schon eine TARA existiert.

1. Woche 1: Umfang und Verkabelung. Gateway und Steuergeräte auswählen, ODX- oder CDD-Dateien, DBC-Dateien und die SecurityAccess-Level sammeln, die gesperrt sein sollen. Den Agenten auf einem vorhandenen Prüfstand installieren und mit einem API-Token koppeln.
2. Woche 2: Baseline. Enumeration über alle Sessions, DID- und Routinen-Scan aus der ODX, SecurityAccess-Prüfung und DoIP-Routing-Tests. Die Risikogewichtung mit dem TARA-Team abstimmen.
3. Wochen 3 und 4: Fuzzing und Review. Seeded UDS-Fuzzing auf den Steuergeräten hinter dem Gateway mit Crash-Erkennung, dann ein Review, in dem jedes Finding akzeptiert, im Fix Plan zugewiesen oder mit dem reproduzierbaren Request an den Zulieferer geschickt wird.
4. Wochen 5 und 6: Zulieferer-Schleife und Retest. Der Zulieferer behebt und fährt dasselbe Profil auf seinem Prüfstand; dein Team scannt erneut. Risikoakzeptanz und Kommentare bleiben erhalten, der Bericht zeigt, was sich geändert hat.
5. Entscheidung. Aufwand und Findings mit dem letzten Zuliefererbericht für dasselbe Steuergerät vergleichen und entscheiden, welche Baureihe das Profil als Nächstes bekommt.

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

ISO/SAE 21434:2021 verlangt Verifikation in Clause 10.4.2: [RQ-10-09] fordert, dass die Implementierung gegen die Cybersecurity-Spezifikation verifiziert wird, und [RC-10-12] empfiehlt Komponententests mit Fuzz-Testing und Schwachstellen-Scans. AutoST-Berichte sind der Nachweis für dieses Work Product auf Komponentenebene. Clause 11 ([RQ-11-01]) nennt Penetrationstests für die Validierung auf Fahrzeugebene; die AutoST-Baseline zeigt dem Pentest-Team, wo die Diagnoseoberfläche schon sauber ist, damit die Tage in die harten Ziele gehen.

UN R155 verlangt ein zertifiziertes CSMS und in Anhang 5, dass die Maßnahmen gegen die gelisteten Bedrohungen umgesetzt und wirksam nachgewiesen sind. Für Bedrohungen wie unautorisierten Diagnosezugriff oder Manipulation über das Fahrzeugnetz ist eine datierte Scan-Historie pro Steuergerät die Art Nachweis, der ein Technischer Dienst folgen kann. UN R156 ergänzt, dass jedes Software-Update diese Sicherheit erhalten muss, also Retest nach jedem Update statt einmal pro Projekt. Bei der Unterstützung eines R155-Audits bei einem Tier-1 war die häufigste Frage die Nachvollziehbarkeit: Welcher Test deckt welche Anforderung ab, und wann lief er zuletzt. Die ALM/PLM-Referenz im Fix Plan und die Historie pro Komponente beantworten sie. AutoST ist keine Zertifizierung und macht kein Fahrzeug typgenehmigt; es liefert dem Team die Nachweise, die die Genehmigung braucht.