Nachverfolgbarkeit im ISO 21434 Audit: Fuzzing zählbar machen

ISO/SAE 21434 verlangt nicht nur, dass du sicher bist. Die Norm verlangt, dass du es einem Assessor mit Nachweisen zeigst. An diesem Unterschied scheitert im Audit viel gute Sicherheitsarbeit, und Sicherheitstests sind das deutlichste Beispiel.

Die Norm fordert die Tests. Und den Nachweispfad fordert sie auch

Die Testanforderungen sind klar genug. Clause 10.4.2 (Integration und Verifizierung) verlangt den Nachweis, dass die Implementierung die Cybersecurity-Spezifikation erfüllt ([RQ-10-09]), und [RC-10-12] empfiehlt Komponententests mit Fuzz-Testing und Schwachstellen-Scans, um unentdeckte Schwächen zu minimieren. Clause 11 (Cybersecurity-Validierung) nennt Penetrationstests ([RQ-11-01]). Ab CAL 2 wird Fuzzing der Kommunikationsschnittstellen faktisch erwartet.

Aber ein 21434-Assessment wird nicht danach bewertet, ob du einen Fuzzer laufen lassen hast. Bewertet werden deine Work Products: der Verifizierungsbericht, der Validierungsbericht und am Ende der Cybersecurity Case, der begründet, dass dein Item angemessen sicher ist, beurteilt im Cybersecurity Assessment (Clause 6.4.9). Der Assessor liest die Argumentation und die Nachweise dahinter. Eine Fuzzing-Kampagne, die nicht in diese Argumentation einfließt, kann genauso gut nie stattgefunden haben.

Bidirektionale Nachverfolgbarkeit, in einem Satz

Was Assessoren immer wieder verlangen, ist bidirektionale Nachverfolgbarkeit: eine dokumentierte Verbindung von jeder Cybersecurity-Anforderung zu dem Test, der sie verifiziert, und von jedem Test zurück zu einer Anforderung.

Für Sicherheitstests heißt das: Ein Assessor kann bei einem Cybersecurity-Ziel starten (“das ECU darf keine diagnostischen Schreibzugriffe ohne Authentifizierung akzeptieren”), ihm zur Cybersecurity-Anforderung folgen, von dort zu dem Test, der sie prüft, und sieht das Ergebnis, dessen Datum und was mit einem Fund passiert ist. Und er kann den umgekehrten Weg gehen: einen Fund nehmen und ihn zurück zu der Anforderung verfolgen, die er bedroht.

Die meisten Teams können die Tests liefern. Weit weniger können diese Kette am Tag des Assessments liefern.

Wo Fuzzing speziell schwierig wird

Fuzzing ist besonders schwer nachverfolgbar zu machen, aus drei Gründen:

• Es ist von Natur aus nicht-deterministisch. Wenn sich ein Crash nicht reproduzieren lässt, ist er eine Anekdote, kein Nachweis. Ein Assessor kann “es ist im März einmal abgestürzt” nicht akzeptieren.
• Es produziert Masse, keine Struktur. Millionen von Iterationen und ein Haufen Logs lassen sich nicht sauber auf eine kurze Liste von Cybersecurity-Anforderungen abbilden.
• Es wird spät und selten ausgeführt. Eine einmalige Kampagne vor einem Audit sagt dir etwas über die Software, die du in jener Woche hattest, nicht über die Software, die du auslieferst, und sie trägt keine Historie.

Die Frage, die ein Assessor zu deinem Fuzzing wirklich stellt, lautet also nicht “hast du gefuzzt?” Die Frage lautet: kannst du diesen Fund reproduzieren, wann hast du ihn zuerst gesehen, auf welche Anforderung bezieht er sich und was hast du dagegen getan?

Wie auditfähige Nachweise für Sicherheitstests aussehen

Egal welches Tool du nutzt, die Nachweise müssen fünf Dinge tragen:

1. Reproduzierbarkeit. Ein gespeicherter Seed oder eine gespeicherte Konfiguration, damit sich jeder Fund auf Abruf erneut abspielen lässt, von dir und vom Assessor.
2. Eine datierte Historie. Keine Momentaufnahme, sondern ein Nachweis darüber, was wann getestet wurde, über das Leben des ECU hinweg, damit du den Trend zeigen kannst und nicht nur den Endzustand.
3. Verknüpfung mit Anforderungen. Jeder Fund ist an die Cybersecurity-Anforderung oder das Ticket gebunden, die er betrifft, damit die bidirektionale Verfolgung hält.
4. Dokumentierte Risikoakzeptanz. Wenn ein Restrisiko akzeptiert wird, werden die Entscheidung und ihre Begründung festgehalten und überdauern bis in den nächsten Testzyklus.
5. Ein lesbarer Export. Die Nachweise müssen das Tool in einer Form verlassen, die der Assessor und dein eigener Tracker verarbeiten können, PDF für die Akte und SARIF für das Tooling.

Wenn du diese fünf richtig machst, hört eine Fuzzing-Kampagne auf, eine Logdatei zu sein, und wird zu einem Work Product.

Wie AutoST dafür gebaut ist

Das ist der Teil eines 21434-Programms, den AutoST tragen soll.

Jeder Lauf ist reproduzierbar: Der Fuzzing-Seed wird gespeichert und angezeigt, sodass sich ein Crash exakt erneut abspielen lässt. Jeder Scan wird datiert und aufbewahrt, sodass die Historie über das Leben eines ECU vorhanden ist und nicht rekonstruiert werden muss. Jeder Fund trägt eine Schwere und einen konkreten Fix, und der Fix Plan gibt jeder Aufgabe einen Status und ein ALM/PLM-Referenzfeld, in dem die Verknüpfung zurück zu deiner Anforderung oder deinem Ticket lebt. Risikoakzeptanz und Kommentare werden über Re-Tests hinweg übernommen, sodass ein akzeptiertes Restrisiko dokumentiert bleibt und ein behobenes Problem als gelöst erscheint. Und die Ausgabe ist PDF für die Audit-Akte und SARIF für dein Tooling.

Weil AutoST über die API und in CI läuft, werden die Tests zu einer kontinuierlichen Aktivität im Sinne von Clause 8.5, statt zu einer Hauruckaktion vor dem Assessment. Der Assessor sieht einen Trend und eine Spur, nicht eine einzelne heldenhafte Kampagne.

Die ehrliche Grenze

AutoST erzeugt die Testnachweise und hält sie nachverfolgbar. Es schreibt nicht deine TARA, betreibt nicht dein Cybersecurity-Managementsystem und verfasst nicht deinen Cybersecurity Case. Das ist Prozess- und Engineering-Urteilsarbeit. Zyberum übernimmt auch diese Seite, als Beratung, mit einem Team, das die SAE- und TÜV SÜD-Zertifizierung Automotive Cybersecurity für ISO/SAE 21434 hält und Tier 1-, Tier 2- und OEM-Programme genau dadurch geführt hat. Referenzen gibt es auf Anfrage.

Wenn du sehen willst, wie auditfähige Testnachweise auf deinem eigenen ECU aussehen, buche eine Demo und wir lassen AutoST gegen ein echtes Target laufen.