UN-R155-Audits: was Tester liefern müssen

Für ein UN-R155-Assessment muss die Testseite drei Dinge zeigen: dass jedes relevante Risiko aus der Risikobewertung getestet wurde, dass die Tests belegen, dass die Sicherheitsmaßnahmen wirken, und dass die Ergebnisse nachverfolgbar und reproduzierbar sind. Die Regelung schreibt keine Testmethoden vor. Verlangt wird vom Hersteller, Risiken zu identifizieren, zu behandeln und die Wirksamkeit der Maßnahmen zu verifizieren, und der Assessor folgt dann der Kette von Risiko zu Maßnahme zu Test zu Ergebnis. Tester, die Testfälle mit Kennungen liefern, verknüpft mit Bedrohungsszenarien, mit datierten und versionierten Nachweisen und einer klaren Aussage, was nicht getestet wurde, machen diese Kette leicht nachvollziehbar. Tester, die ein PDF mit “keine kritischen Findings” liefern, machen sie schwer.

Was R155 verlangt, kurz

UN R155 hat zwei Teile, die hier zählen. Absatz 7.2 betrifft das Cyber Security Management System (CSMS) des Herstellers: die Prozesse für Risikoidentifikation, Bewertung, Behandlung, Test und Überwachung. Absatz 7.3 betrifft den Fahrzeugtyp: der Hersteller muss eine Risikobewertung für den Typ durchführen, ihn mit angemessenen Maßnahmen gegen die identifizierten Risiken schützen und die Wirksamkeit dieser Maßnahmen vor der Typgenehmigung testen. Annex 5 listet Bedrohungen und Maßnahmen, die die Risikobewertung berücksichtigen muss.

ISO/SAE 21434 ist der übliche Engineering-Rahmen dahinter. Die Testpflichten stehen in Clause 10 (Integration und Verifikation), Clause 11 (Cybersecurity-Validierung) und der TARA in Clause 15. Die verteilte Entwicklung mit Zulieferern regelt Clause 7.

Die Kette, der ein Assessor folgt

Glied	Was der Tester liefert
Bedrohungsszenario (TARA, Annex-5-Bezug)	Die Testfall-Kennungen, die es adressieren
Cybersecurity-Anforderung	Das Pass-Kriterium, das zeigt, dass sie erfüllt ist
Testfall	Schritte, Vorbedingungen, erwartetes Ergebnis, Abdeckung
Ergebnis	Datum, Softwarestand, Tester, Tool-Version, Rohnachweis
Finding	Bewertung mit Begründung, Fix-Status, Restrisiko-Entscheidung

Fehlt ein Glied, fragt der Assessor nach. Die häufigste Lücke, die wir in der Audit-Unterstützung sehen, ist der Rückbezug vom Testfall zum Bedrohungsszenario: die Tests liefen, aber niemand kann zeigen, welches Risiko jeder Test adressiert hat.

Nachweise, die tragen

Ein Nachweis für ein Audit ist roh, datiert und zuordenbar. Halte je Testfall fest:

• Den Software- und Hardwarestand des getesteten Items, wie das Steuergerät ihn meldet, zum Beispiel aus 22 F1 89 und 22 F1 91.
• Den Request und die Response oder das Log der Kampagne, nicht nur das Urteil. Eine Zeile wie 2E F1 8C ... -> 7F 2E 33 belegt, dass ein Schreiben abgelehnt wurde.
• Das Datum, den Tester, das Tool und seine Version, die Prüfstandskonfiguration.
• Für Fuzzing: Seed, Iterationszahl, Services im Scope, verwendete Monitore. Eine Kampagne, die sich nicht wiederholen lässt, ist ein schwacher Nachweis.

Saubere Ergebnisse zählen. “SecurityAccess Level 1: Lockout nach drei ungültigen Keys (7F 27 36), Verzögerung durchgesetzt (7F 27 37), Seed hat die Zufallsprüfungen bestanden” ist der Nachweis, dass die Brute-Force-Maßnahme wirkt. Assessoren lesen negative Ergebnisse als Beleg der Abdeckung.

Abdeckung und Grenzen

Nenne die Abdeckung in Zahlen und die Grenzen in Worten. “Alle Service Identifier 0x00 bis 0xFE in den Sessions 01, 02 und 03” oder “DID-Bereich 0xF100 bis 0xF1FF” sagt dem Assessor, wie weit der Test ging. Ausschlüsse sind genauso wichtig: waren Hardware-Angriffe, Firmware-Extraktion oder das Telematik-Backend außerhalb des Scopes, schreib es auf, mit Verweis darauf, wo diese Risiken abgedeckt sind.

Restrisiko und Re-Test

Jedes Finding braucht einen Endzustand: behoben und verifiziert auf einem benannten Softwarestand, durch eine andere Maßnahme mitigiert oder als Restrisiko akzeptiert von einer benannten Rolle an einem Datum. Offene Findings ohne Entscheidung sind die zweithäufigste Audit-Frage. Plane den Re-Test von Anfang an und halte die Testfall-Kennungen stabil, damit der Re-Test auf dem neuen Softwarestand denselben Fall als bestanden zeigt.

Was Zulieferer übergeben sollten

Ein Tier-1, der die R155-Genehmigung eines OEM unterstützt, wird meist nach der TARA oder ihrem relevanten Teil gefragt, nach den umgesetzten Cybersecurity-Anforderungen, der Testspezifikation und den Ergebnissen mit Nachverfolgbarkeit, offenen Findings mit Status und der Vulnerability-Management-Regelung nach dem Produktionsstart. Vereinbare das Format früh im Cybersecurity Interface Agreement. Ein PDF ohne Testfall-Kennungen zu übergeben zwingt den OEM, die Zuordnung neu zu machen, und daher kommen Audit-Findings.

Wie AutoST das unterstützt

AutoST erzeugt den wiederholbaren Teil dieser Nachweise: Testläufe mit dem Scope aus Steuergerät, Schnittstelle und Session, Abdeckungszahlen, jedes Finding mit Request- und Response-Bytes, einen PDF-Bericht und einen SARIF-Export pro Lauf und einen Fix Plan, der Status, Verantwortlichen, Risikoakzeptanz und eine ALM/PLM-Referenz pro Finding über Re-Tests hinweg führt. Es betreibt kein CSMS, schreibt die TARA nicht und stellt keine Genehmigung aus, und es ersetzt nicht den Penetrationstest, den die Validierung nach Clause 11 meist einschließt. Seine Aufgabe ist, die Testergebnisse nachverfolgbar und wiederholbar zu machen, Release für Release.