Registrazioni sulla gestione delle vulnerabilità previste dalla CRA

Obbligo relativo al processo

Al momento dell’immissione sul mercato di un prodotto con elementi digitali e per tutto il periodo di supporto, i fabbricanti garantiscono che le vulnerabilità di tale prodotto, compresi i suoi componenti, siano gestite efficacemente e in conformità ai requisiti essenziali di cibersicurezza di cui alla parte II dell’allegato I.

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

L’obbligo inizia quando il prodotto viene immesso sul mercato e prosegue durante il periodo di supporto. Riguarda il prodotto e i suoi componenti.

Tipi principali di registri

Esempio: da un avviso su un componente alla chiusura

Si consideri una vulnerabilità fittizia in un parser di una release firmware di un controllore. I sei registri seguenti costituiscono la cronologia esemplificativa del caso. Mostrano come un team può collegare la ricezione della segnalazione, l’impatto sul prodotto e il rimedio; la sequenza non è un modulo prescritto dal CRA.

1. Ricezione: registrare quando è arrivata la segnalazione, la fonte, il componente e l’identificatore della vulnerabilità, nonché le informazioni disponibili in quel momento. Conservare la segnalazione originale.
2. Impatto sul prodotto: utilizzare SBOM e record di build per individuare le release candidate. Verificare se un aggressore può raggiungere il parser interessato in ogni configurazione supportata; registrare sia le evidenze sia le incertezze residue.
3. Decisione di notifica: valutare immediatamente l’articolo 14 in presenza di prove di sfruttamento attivo o di un incidente grave di sicurezza del prodotto. Registrare i momenti in cui si è venuti a conoscenza dei fatti e inviare le notifiche richieste entro i termini applicabili mentre prosegue l’indagine tecnica.
4. Trattamento: valutare il rischio per il prodotto, assegnare la correzione o la misura di mitigazione e, se pertinente, coordinarsi con il responsabile della manutenzione del componente. Conservare l’azione scelta e la relativa motivazione.
5. Verifica e rilascio: testare il parser corretto e le funzioni interessate del prodotto, conservare la build testata e collegare l’aggiornamento di sicurezza, le evidenze di distribuzione e le istruzioni per gli utenti.
6. Chiusura e seguito: registrare l’esito verificato, l’inventario dei componenti aggiornato, la comunicazione agli utenti e la divulgazione. Mantenere aperte le azioni ulteriori per ogni versione supportata interessata che non disponga ancora di un rimedio efficace.

Il registro del caso dovrebbe distinguere tra completamento della correzione interna, invio delle notifiche richieste e consegna o installazione dell’aggiornamento. Ad esempio, una correzione può essere pubblicata mentre alcuni utenti interessati devono ancora installarla, rendendo necessario un seguito.

Collegamento all’allegato VII

L’allegato VII richiede che la documentazione tecnica includa informazioni e specifiche necessarie sui processi di gestione delle vulnerabilità, compresi SBOM, politica coordinata di divulgazione delle vulnerabilità, contatto per le segnalazioni e distribuzione sicura degli aggiornamenti.

• registri a supporto della cronologia delle vulnerabilità del prodotto;
• registri che spieghino come vengono classificate e corrette le vulnerabilità;
• registri che mostrino la distribuzione degli aggiornamenti e la comunicazione agli utenti;
• rapporti di test e riesame a supporto della valutazione della conformità.

Il progetto prEN 40000-1-3 illustra più dettagliatamente l’attuale progetto di norma sulla gestione delle vulnerabilità.