AutoST für ISO/SAE-21434-Compliance-Manager: Nachvollziehbare Testnachweise

Die Aufgabe

Der ISO/SAE-21434-Compliance-Manager, oft Cybersecurity-Manager oder CSMS-Verantwortlicher genannt, ist die Person, die dem Auditor antwortet. Die Rolle besitzt den Cybersecurity-Plan, sorgt dafür, dass TARA, Cybersecurity-Konzept und Verifikationsberichte für jedes Item existieren, hält die Interface Agreements mit Zulieferern in Ordnung und stellt den Cybersecurity Case zusammen. Die Ingenieure testen; der Compliance-Manager muss belegen, dass getestet wurde, dass es ausgereicht hat und dass etwas daraus folgte.

Genau hier sind die meisten Programme am schwächsten. Bei der Unterstützung eines UN-R155- und ISO/SAE-21434-Audits bei einem Tier-1-Zulieferer war das Testen selbst nicht das Problem. Das Problem war, dass Testergebnisse in Tabellen, E-Mails und Pentest-PDFs mit unterschiedlicher Struktur lagen und niemand schnell sagen konnte, welcher Test welche Cybersecurity-Anforderung abdeckt, auf welchem Softwarestand und wann er zuletzt lief. Diese Tabelle von Hand zu bauen, hat vor dem Audit Wochen gekostet.

Was die Rolle aus einem Testlauf braucht

Der Compliance-Manager braucht Nachweise, die vier Fragen ohne Meeting beantworten: was getestet wurde, wann, gegen welche Anforderung und was mit dem Ergebnis passiert ist.

• Einen datierten Bericht pro Komponente. Jeder AutoST-Scan erzeugt ein PDF mit Überblick, Findings und einer Fußzeile zur Nichtabstreitbarkeit. Die Scan-Historie pro Komponente zeigt, dass der Test nach jeder Änderung wiederholt wurde und nicht nur einmal lief.
• Nachvollziehbarkeit zu Anforderungen. Jede Fix-Plan-Aufgabe trägt ein ALM/PLM-Referenzfeld, das das Finding mit der Cybersecurity-Anforderung oder dem Ticket verbindet. Exporte als CSV, JSON und SARIF 2.1.0 gehen in die Werkzeuge, die die Organisation schon nutzt.
• Dokumentierte Risikoentscheidungen. Risikoakzeptanz und Kommentare werden pro Finding festgehalten und über Re-Scans übernommen. Ein akzeptiertes Restrisiko bleibt mit Begründung dokumentiert, ein behobenes Problem erscheint als erledigt.
• Einen konsistenten Score. Der gewichtete Risiko-Score von 0 bis 10 wird pro Mandant auf das eigene Risikomodell eingestellt, damit er im TARA-Review referenziert und nicht diskutiert wird.
• Eine ehrliche Umfangsangabe. Was AutoST getestet hat (UDS-Services, SecurityAccess, Fuzzing, DoIP, SOME/IP, Android-IVI) und was nicht (FlexRay, LIN, Hardware, Secure Boot), damit der Nachweis nicht mit einem Penetrationstest verwechselt wird.

Typisches Setup

Compliance-Manager stehen selten am Prüfstand. Im AutoST-Dashboard bekommen Compliance-Manager eine passende Rolle und sehen Komponenten, Scans, Berichte und den Fix Plan der Gruppen, für die sie zuständig sind. Das Security- oder Testteam fährt die Scans mit dem Carbyne-Agenten am Prüfstand, über CAN, CAN FD, DoIP oder SOME/IP, und besitzt die Testprofile.

Die meisten Organisationen, denen Auditnachweise wichtig sind, betreiben AutoST auf eigenen Servern, damit Berichte und Findings in der bestehenden Dokumentenlenkung bleiben; die von Zyberum in der EU gehostete Instanz funktioniert genauso. AutoST hat keine Anbindung an DOORS, Polarion oder codebeamer: Die Verbindung sind das Referenzfeld und der Export.

Ein sinnvolles erstes Projekt

Nimm ein Item, für das ein Audit oder ein Zulieferer-Review ansteht, und baue seine Nachweiskette einmal komplett.

1. Woche 1: Anforderungen auf Tests abbilden. Die Cybersecurity-Anforderungen eines Steuergeräts auflisten, die an der Diagnose- und Busschnittstelle testbar sind: gesperrte Services, SecurityAccess-Level, Robustheit gegen fehlerhafte Eingaben, Gateway-Routing. Mit dem Testteam festlegen, welcher AutoST-Scan welche abdeckt.
2. Woche 2: Baseline. Das Testteam fährt Enumeration, SecurityAccess-Prüfung sowie DID- und Routinen-Scan. Die Anforderungs-IDs in das ALM/PLM-Referenzfeld jeder entstandenen Fix-Plan-Aufgabe eintragen.
3. Wochen 3 und 4: Fuzzing und Entscheidungen. Seeded Fuzzing läuft; jedes Finding wird behoben, zugewiesen oder mit schriftlicher Begründung akzeptiert.
4. Woche 5: Retest. Dasselbe Profil läuft nach den Fixes erneut. Der zweite Bericht zeigt, was geschlossen wurde.
5. Woche 6: Probe-Audit. Einen internen Reviewer von einer Anforderung zum Test, zum Bericht, zum Finding und zur Entscheidung führen und die Zeit dafür messen.

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

AutoST deckt die Test-Clauses ab, nicht die ganze Norm. ISO/SAE 21434:2021 Clause 10.4.2 fordert die Verifikation der Implementierung gegen die Cybersecurity-Spezifikation ([RQ-10-09]) und empfiehlt Komponententests mit Fuzz-Testing und Schwachstellen-Scans ([RC-10-12]); AutoST-Berichte und Scan-Historie sind der Nachweis für dieses Work Product. Clause 11 ([RQ-11-01]) nennt Penetrationstests für die Validierung; AutoST ist die Baseline dafür, kein Ersatz. Clause 8.5 macht die Schwachstellenanalyse zur fortlaufenden Aktivität, was wiederholte Scans nach jedem Release unterstützen. Clause 7 regelt verteilte Aktivitäten mit Zulieferern; einen Zulieferer das Ergebnis eines vereinbarten AutoST-Profils liefern zu lassen, ist ein praktischer Weg, das Interface Agreement zu füllen.

UN R155 Absatz 7.2 verlangt, dass das CSMS des Herstellers Tests und Zuliefererrisiken abdeckt, Absatz 7.3 verlangt angemessene und ausreichende Tests für den Fahrzeugtyp, und Anhang 5 listet die zu adressierenden Bedrohungen und Maßnahmen. Für Bedrohungen auf Steuergeräteebene wie unautorisierten Diagnosezugriff liefert AutoST wiederholbare Nachweise, dass die Maßnahme wirkt. UN R156 ergänzt, dass jedes Software-Update diese Sicherheit erhalten muss, also läuft dasselbe Profil nach jedem Update erneut. AutoST ist keine Zertifizierung und macht nichts konform; es macht den Testteil des Cybersecurity Case nachvollziehbar.