Tracciabilità in un audit ISO 21434: dare valore al fuzzing

La ISO/SAE 21434 non ti chiede solo di essere sicuro. Ti chiede di dimostrarlo, a un assessor, con evidenze. È in questa differenza che molto buon lavoro di sicurezza crolla in un audit, e il test di sicurezza ne è l’esempio più netto.

La norma chiede i test. Chiede anche la documentazione

I requisiti di test sono abbastanza chiari. La Clause 10.4.2 (integrazione e verifica) richiede di verificare che l’implementazione soddisfi la specifica di cybersecurity ([RQ-10-09]), e [RC-10-12] raccomanda il test dei componenti, con fuzz testing e vulnerability scanning, per ridurre al minimo le debolezze non identificate. La Clause 11 (validazione della cybersecurity) indica il penetration testing ([RQ-11-01]). Dal CAL 2 in su, il fuzzing delle interfacce di comunicazione è di fatto atteso.

Ma un assessment 21434 non viene valutato in base al fatto che tu abbia eseguito un fuzzer. Viene valutato in base ai tuoi work product: il report di verifica, il report di validazione e, in ultima analisi, il cybersecurity case che argomenta che il tuo item sia adeguatamente sicuro, giudicato nel cybersecurity assessment (Clause 6.4.9). L’assessor legge l’argomentazione e le evidenze che la sostengono. Una campagna di fuzzing che non è scritta dentro quell’argomentazione è come se non fosse mai avvenuta.

Tracciabilità bidirezionale, in una frase

Ciò che gli assessor continuano a chiedere è la tracciabilità bidirezionale: un collegamento documentato da ogni requisito di cybersecurity al test che lo verifica, e da ogni test fino a un requisito.

Per il test di sicurezza questo significa che un assessor può partire da un cybersecurity goal (“l’ECU non deve accettare scritture diagnostiche senza autenticazione”), seguirlo fino a un requisito di cybersecurity, seguire quest’ultimo fino al test che lo controlla e vedere il risultato, la sua data e cosa è successo a qualsiasi scoperta. E può andare nella direzione opposta: scegliere una scoperta e risalire fino al requisito che minaccia.

La maggior parte dei team riesce a produrre i test. Molti meno riescono a produrre quella catena il giorno dell’assessment.

Dove il fuzzing in particolare diventa difficile

Il fuzzing è particolarmente ostico da rendere tracciabile, per tre motivi:

• È non deterministico per natura. Se un crash non può essere riprodotto, è un aneddoto, non un’evidenza. Un assessor non può accettare “si è bloccato una volta a marzo”.
• Produce volume, non struttura. Milioni di iterazioni e un cumulo di log non si mappano in modo pulito su una breve lista di requisiti di cybersecurity.
• Viene eseguito tardi e di rado. Una campagna una tantum prima di un audit ti dice qualcosa sul software che avevi quella settimana, non sul software che spedisci, e non porta con sé alcuno storico.

Quindi la domanda che un assessor pone davvero sul tuo fuzzing non è “hai fatto fuzzing?”. È: puoi riprodurre questa scoperta, quando l’hai vista per la prima volta, a quale requisito si riferisce e cosa hai fatto al riguardo?

Che aspetto ha un’evidenza di test di sicurezza pronta per l’audit

Qualunque strumento tu usi, l’evidenza deve portare con sé cinque cose:

1. Riproducibilità. Un seed o una configurazione memorizzati così che ogni scoperta possa essere rigiocata su richiesta, da te e dall’assessor.
2. Uno storico datato. Non un’istantanea, ma un registro di cosa è stato testato e quando, lungo tutta la vita dell’ECU, così da poter mostrare la tendenza, non solo lo stato finale.
3. Collegamento ai requisiti. Ogni scoperta legata al requisito di cybersecurity o al ticket che riguarda, così che la traccia bidirezionale regga.
4. Accettazione del rischio documentata. Quando un rischio residuo viene accettato, la decisione e la sua motivazione sono registrate e sopravvivono al ciclo di test successivo.
5. Un export leggibile. L’evidenza deve uscire dallo strumento in una forma che l’assessor e il tuo stesso tracker possano consumare, PDF per il fascicolo e SARIF per il tooling.

Centra queste cinque cose e una campagna di fuzzing smette di essere un file di log e diventa un work product.

Come AutoST è costruito per questo

Questa è la parte di un programma 21434 che AutoST è progettato per sostenere.

Ogni run è riproducibile: il seed del fuzzing è memorizzato e mostrato, così che un crash possa essere rigiocato esattamente. Ogni scan è datato e conservato, così che lo storico lungo la vita di un ECU ci sia, e non vada ricostruito. Ogni scoperta porta con sé una severità e un fix concreto, e il Fix Plan assegna a ogni task uno stato e un campo di riferimento ALM/PLM, dove vive il collegamento al tuo requisito o ticket. L’accettazione del rischio e i commenti si trasferiscono ai re-test, così che un rischio residuo accettato resti documentato e un problema risolto appaia come risolto. E l’output è PDF per il fascicolo di audit e SARIF per il tuo tooling.

Poiché AutoST gira dall’API e in CI, il test diventa un’attività continua nel senso inteso dalla Clause 8.5, invece di una corsa affannosa prima dell’assessment. L’assessor vede una tendenza e una traccia, non una singola campagna eroica.

Il confine onesto

AutoST produce l’evidenza dei test e la mantiene tracciabile. Non scrive la tua TARA, non gestisce il tuo cybersecurity management system né redige il tuo cybersecurity case. Quelli sono lavoro di processo e di giudizio ingegneristico. Zyberum si occupa anche di quel versante, come consulenza, con un team che detiene la certificazione SAE e TÜV SÜD Automotive Cybersecurity per la ISO/SAE 21434 e ha portato programmi Tier 1, Tier 2 e OEM esattamente attraverso questo percorso. Le referenze sono disponibili su richiesta.

Se vuoi vedere che aspetto ha un’evidenza di test pronta per l’audit sul tuo ECU, prenota una demo e la eseguiremo su un target reale.