Valutazione dei rischi di cybersicurezza della CRA

Ruolo della valutazione dei rischi

Ai fini della conformità al paragrafo 1, i fabbricanti effettuano una valutazione dei rischi di cibersicurezza associati a un prodotto con elementi digitali e ne tengono conto durante le fasi di pianificazione, progettazione, sviluppo, produzione, consegna e manutenzione del prodotto con elementi digitali, al fine di ridurre al minimo i rischi di cibersicurezza, prevenire gli incidenti e limitarne l’impatto, anche in relazione alla salute e alla sicurezza degli utenti.

Regolamento (UE) 2024/2847, articolo 13(2)

L’articolo 13 richiede che la valutazione dei rischi segua il ciclo di vita del prodotto e venga aggiornata, se necessario, durante il periodo di supporto.

Che cosa spiega la valutazione

A norma dell’articolo 13(3), la valutazione deve considerare la finalità prevista, l’uso ragionevolmente prevedibile, le condizioni d’uso, l’ambiente operativo, gli asset da proteggere e la durata prevista dell’utilizzo.

• quali requisiti della parte I dell’allegato I si applicano al prodotto;
• come sono attuati tali requisiti del prodotto;
• come si applica il requisito generale di cibersicurezza basato sul rischio di cui al punto 1 della parte I dell’allegato I;
• come si applicano i requisiti di gestione delle vulnerabilità di cui alla parte II dell’allegato I;
• perché un requisito non è applicabile, quando questa è la conclusione del fabbricante.

Esempio: valutare il percorso di aggiornamento del firmware

Si consideri un controllore connesso fittizio che riceve il firmware da un servizio di aggiornamento. Un aggressore potrebbe tentare di sostituire l’immagine prima dell’installazione. La valutazione deve stabilire se ciò sia possibile e che cosa potrebbe fare il firmware modificato.

1. Definire il percorso di aggiornamento per il modello di controllore e la release del firmware. Individuare chi può fornire un’immagine, come raggiunge il dispositivo e quali controlli vengono eseguiti prima dell’installazione.
2. Descrivere la minaccia: un aggressore sostituisce un’immagine del firmware prima dell’installazione. L’asset è l’integrità del codice eseguibile; le conseguenze dipendono dalle funzioni che il controllore può modificare.
3. Valutare i controlli esistenti: stabilire dove viene verificata l’immagine, quali chiavi di firma sono considerate attendibili e che cosa accade in caso di verifica non riuscita. Una dichiarazione di progettazione, da sola, non dimostra il comportamento della versione rilasciata.
4. Collegare le misure alla verifica: conservare il progetto di aggiornamento approvato e i test relativi a immagini modificate, firme non valide e ripristino dopo un errore. Registrare il firmware e la configurazione sottoposti a test.
5. Spiegare il rischio residuo considerando le condizioni di attacco e le conseguenze previste. Individuare le ipotesi ancora da confermare e le eventuali misure aggiuntive necessarie. Riesaminare la conclusione quando cambiano il meccanismo di aggiornamento o la minaccia.

Un diagramma del flusso dei dati (DFD) e STRIDE possono aiutare a individuare i percorsi di attacco per questa analisi. La decisione sul rischio richiede comunque i dati del prodotto e i risultati della verifica. Ad esempio, prima di fare affidamento sulla verifica della firma per ridurre il rischio, il team dovrebbe confermarla rispetto alla progettazione e al firmware sottoposto a test.

Collegamento alla documentazione tecnica

L’articolo 13(4) inserisce la valutazione dei rischi di cibersicurezza nella documentazione tecnica. L’allegato VII richiede quindi che la documentazione includa una valutazione dei rischi di cibersicurezza rispetto ai quali il prodotto è progettato, sviluppato, prodotto, consegnato e mantenuto.

Riferimento alle norme

Il progetto prEN 40000-1-2 spiega l’attuale documento orizzontale di principi per la gestione dei rischi di ciberresilienza. Può aiutare a strutturare il lavoro, ma l’obbligo giuridico deriva comunque dall’articolo 13 e dall’allegato I.