Conformità
ISO/SAE 21434 e UN R155 ti chiedono di verificare che i controlli di sicurezza funzionino, e di conservarne le evidenze. AutoST produce quelle evidenze, in modo ripetibile, su ogni ECU.
In breve
AutoST supporta un programma ISO/SAE 21434 e UN R155 sul fronte dei test. ISO/SAE 21434:2021 richiede test di sicurezza in tre punti: Clause 10.4.2 Integrazione e verifica ([RQ-10-09], e [RC-10-12] che raccomanda test di componente con fuzzing e scansione delle vulnerabilità per ridurre al minimo le debolezze non identificate), Clause 11 Validazione della cybersecurity ([RQ-11-01], che cita il penetration testing) e Clause 8.5 Analisi delle vulnerabilità come attività continua. AutoST esegue quei test (enumerazione, probing di SecurityAccess, fuzzing, DoIP/SOME/IP e IVI) e produce le evidenze alla loro base (report PDF e SARIF, storico delle scansioni, accettazione del rischio). Non gestisce il tuo CSMS né scrive la tua TARA: per questi, Zyberum offre consulenza ISO/SAE 21434.
Le clausole
I riferimenti sono alla ISO/SAE 21434:2021. Questa è una guida pratica, non una certificazione, ma è il punto in cui fuzzing, analisi delle vulnerabilità e penetration testing vivono nello standard.
[RQ-10-09] richiede di verificare che l’implementazione soddisfi la specifica di cybersecurity. [RC-10-12] raccomanda test di componente, con fuzz testing e scansione delle vulnerabilità, per ridurre al minimo le debolezze non identificate. È esattamente ciò che fanno, in modo ripetibile, l’enumerazione, i controlli SecurityAccess e il fuzzing di AutoST.
[RQ-11-01] indica il penetration testing come modo per confermare che gli obiettivi di cybersecurity siano raggiunti. AutoST dà a quella validazione una baseline ripetibile e documentata su tutta la superficie di attacco diagnostica e di bus, su cui gli specialisti possono poi costruire.
La Clause 8 tratta la ricerca e l’analisi delle debolezze come un’attività continua lungo la vita della ECU. Rieseguire AutoST su ogni build, tramite API e CI, la trasforma in un processo permanente anziché in un audit una tantum.
I percorsi di attacco della tua TARA sono ciò contro cui AutoST testa: servizi diagnostici raggiungibili senza autenticazione, SecurityAccess debole, XCP/CCP esposti. I risultati rientrano direttamente nel quadro del rischio. La TARA stessa la scrive Zyberum.
Tracciabilità
Un auditor non vuole solo sentirsi dire che hai testato. Vuole vedere cosa è stato testato, quando, cosa è stato trovato e che fine ha fatto ogni risultato. AutoST mantiene intatta quella catena.
Ogni risultato porta con sé una severità e una correzione concreta. Il Fix Plan assegna a ogni task uno stato e un campo di riferimento ALM/PLM, così da ricollegarsi al tuo requisito o ticket. Storico delle scansioni e accettazione del rischio si conservano tra un test e l’altro, così un rischio residuo accettato resta documentato e un problema corretto risulta risolto. L’export è PDF per il fascicolo di audit e SARIF per i tuoi strumenti.
Un confine onesto
AutoST non scriverà la tua TARA né gestirà il tuo sistema di gestione della cybersecurity. È uno strumento di test, e promettere di più non ti aiuterebbe a superare un audit.
La strategia, la TARA, la tracciabilità dei work product e la preparazione all’audit sono lavoro di consulenza. Zyberum fa anche questo: lo stesso team che costruisce AutoST possiede la certificazione SAE e TÜV SÜD Automotive Cybersecurity per ISO/SAE 21434.
FAQ
Fuzzing e scansione delle vulnerabilità ricadono sotto la Clause 10.4.2 (Integrazione e verifica), dove [RC-10-12] raccomanda test di componente per ridurre al minimo le debolezze non identificate. Il penetration testing è citato nella Clause 11 (Validazione della cybersecurity), [RQ-11-01]. La Clause 8.5 (Analisi delle vulnerabilità) rende la ricerca delle debolezze un’attività continua. In pratica, il fuzz testing delle interfacce di comunicazione è atteso da CAL 2 in su.
Nessuno strumento lo fa da solo. AutoST copre i test e le evidenze: scansioni di sicurezza e fuzzing ripetibili per [RC-10-12], una baseline di penetration test per [RQ-11-01], punteggio di rischio, storico e report PDF/SARIF. La TARA, il CSMS e l’audit sono lavoro di processo, che Zyberum può supportare separatamente.
Ogni risultato porta con sé una severità e una correzione, e ogni task del Fix Plan ha un campo di riferimento ALM/PLM che lo collega al tuo requisito o ticket. Storico delle scansioni e accettazione del rischio si conservano tra un test e l’altro, così la traccia di audit mostra cosa è stato testato, cosa è stato trovato e cosa è stato fatto al riguardo.
UN R155 richiede un CSMS certificato e che le mitigazioni del suo Annex 5 siano dimostrate efficaci, il che significa testate. AutoST fornisce evidenze di test ripetibili per le mitigazioni a livello di ECU; Zyberum supporta il lato CSMS e omologazione.
Vedilo sulla tua ECU
In un’ora definiamo l’ambito di un progetto pilota: il tuo banco, i tuoi protocolli, i target e cosa significa successo.
La tua demo è conTom ZaubermannFondatore di Zyberum, ex responsabile del VW InCar Security Testing Lab
Già scelto da fornitori Tier 1, Tier 2 e OEM. Referenze su richiesta.
Rispondiamo entro un giorno lavorativo.
La tua privacy
Utilizziamo cookie e tecnologie simili per misurare il nostro sito web e il successo delle nostre inserzioni. Decidi tu quali possiamo usare. Puoi modificare la tua scelta in qualsiasi momento tramite "Impostazioni cookie" nel footer. Informativa sulla privacy
