Il 10 dicembre 2024 è entrato in vigore il Cyber Resilience Act (CRA), regolamento dell’Unione Europea che introduce requisiti obbligatori di cybersicurezza per tutti i prodotti con elementi digitali (di seguito chiamati anche prodotti ICT) venduti o utilizzati nel mercato europeo.
Indice degli argomenti
Il quadro normativo del Cyber Resilience Act e la classificazione dei prodotti
Il CRA è un quadro legislativo completo e complesso che mira ad affrontare i crescenti rischi di sicurezza informatica in tutti i settori, stabilendo una serie di requisiti di sicurezza essenziali per garantire che i prodotti siano progettati, sviluppati e mantenuti con la sicurezza come priorità, migliorando così la resilienza del panorama digitale dell’UE.
Il CRA si applica a tutti i prodotti con elementi digitali e li classifica in base al livello di rischio tra prodotti “non critici” e prodotti “importanti” i quali sono soggetti a valutazioni della sicurezza che possono coinvolgere una terza parte. Questi ultimi sono a loro volta divisi in ulteriori due classi (Classe I e Classe II) in base al rischio ad essi associato e il regolamento fornisce una lista esaustiva delle tipologie di prodotto inclusi nelle due classi. Infine, vengono identificati dei prodotti “importanti” che hanno però elementi digitali critici; per questi è richiesto che siano valutati in accordo ad un sistema di certificazione della sicurezza europeo.
Il CRA diventerà vincolante dopo 36 mesi (Dicembre 2027), ma già da settembre 2026 sarà obbligatorio per tutti i fornitori la notifica di eventuali vulnerabilità che afferiscono ai propri prodotti ICT.
Un aspetto essenziale del CRA è il suo approccio basato sul rischio, con una chiara attenzione alla valutazione del rischio che tiene conto non solo della categoria di prodotto, ma anche dell’uso specifico e delle implicazioni di sicurezza di ciascun prodotto. Ad esempio, le smart card utilizzate in ambienti diversi, come una tessera di accesso a una palestra rispetto a una tessera che consente l’ingresso a una struttura critica, comportano livelli di rischio intrinsecamente diversi. Sebbene entrambi i prodotti possano rientrare nella stessa categoria di prodotti CRA, l’impatto potenziale sulla sicurezza è molto maggiore per una smart card utilizzata in un ambiente sensibile e ad alto rischio. Pertanto, il CRA richiede ai produttori di determinare livelli di sicurezza adeguati in base al profilo di rischio e al contesto di utilizzo del prodotto, garantendo che le misure di sicurezza informatica siano proporzionali ai rischi di sicurezza presentati da ciascun caso d’uso.
Percorsi di conformità e standardizzazione europea per prodotti digitali
Per fornire ai produttori mezzi flessibili di conformità, il CRA offre diversi percorsi per dimostrare l’aderenza ai suoi requisiti essenziali anche attraverso norme armonizzate che specificano criteri tecnici in linea con i suoi requisiti essenziali di sicurezza (in seguito indicati come ESR). Non è un caso quindi che la Commissione Europea intende incaricare gli organismi europei di normazione (CEN, Cenelec ed ETSI) di sviluppare delle norme armonizzate (circa 40) che coprano sia i requisiti orizzontali di sicurezza informatica sia le norme specifiche per le categorie importanti e critiche di prodotti con elementi digitali. Questo ampio lavoro di standardizzazione mira a garantire che i produttori di tutta l’UE abbiano accesso a linee guida armonizzate e all’avanguardia, facilitando la conformità al CRA e promuovendo al contempo l’interoperabilità e la coerenza nel mercato digitale dell’UE.
Presunzione di conformità tramite certificazione EUCC nel Cyber Resilience Act
Un altro percorso suggerito dal CRA per dimostrare la conformità alla norma è l’utilizzo degli schemi di certificazione europei in materia di sicurezza informatica, vedi a esempio l’EUCC. Va osservato che il CRA, come indicato nell’articolo 27 della norma, stabilisce una “presunzione di conformità” per i prodotti che sono stati certificati secondo uno schema di certificazione europeo riconosciuto in materia di sicurezza informatica, come l’EUCC, a condizione che la certificazione soddisfi almeno un livello di garanzia “sostanziale”. Quindi, l’ottenimento della certificazione EUCC non è obbligatorio per ottenere la conformità al CRA per i prodotti classificati come importanti (lo è solo per quelli con elementi digitali critici), ma si tratta semplicemente di un percorso a disposizione dei produttori che desiderano sfruttare i processi di conformità strutturati dell’EUCC come mezzo per soddisfare i requisiti del CRA.
Mandato Enisa per l’implementazione CRA attraverso schema EUCC
Per tale ragione, la Commissione Europea, nel giugno 2023, ha incaricato ENISA di effettuare uno studio per definire una strategia su come fosse possibile implementare la conformità al CRA attraverso l’utilizzo dello schema europeo di certificazione EUCC.
Dopo una prima versione pubblicata a settembre 2023 e il recepimento dei commenti pervenuti dai membri dell’European Cybersecurity Certification Group (ECCG) e dal Stakeholder Cybersecurity Certification Group (SCCG), nel gennaio 2025 ENISA ha pubblicato sul proprio sito la versione finale del documento.
Nel presente articolo illustreremo i principali aspetti descritti nel documento di ENISA, lasciano alla lettura del documento le informazioni tecniche di dettaglio.
Va comunque specificato che lo studio di ENISA, come specificato nell’introduzione del documento stesso, punta solo ad esaminare gli aspetti tecnici dell’attuazione del CRA attraverso l’EUCC come schema europeo di certificazione della sicurezza informatica, concentrandosi sui suoi elementi tecnici e fornendo potenziali conclusioni che potrebbero essere prese in considerazione dalla Commissione europea al momento di stabilire la presunzione di conformità. Lo studio non deve essere quindi interpretato come una serie di linee guida per stabilire la presunzione di conformità al CRA, poiché la definizione di tale presunzione richiederebbe un atto giuridico formale ai sensi del CRA, in linea con l’articolo 27 (9). Infatti, lo studio è solo un’analisi e non pregiudica in alcun modo le decisioni future della Commissione Europea.
Lo studio di ENISA per la convergenza CRA – EUCC
Il documento predisposto da ENISA è molto articolato e complesso e analizza tutti gli aspetti dell’EUCC , e quindi dello standard Common Criteria, effettuando una mappatura con i requisiti di sicurezza essenziali (Allegato I – parte I e Parte II) del CRA fornendo una possibile mappatura tra questi e i Security Functional Requirements (SFR) e Security Assurance Requirements (SAR) dello standard CC adottato dall’EUCC.
Non andremo nei dettagli dello studio effettuato e della mappatura proposta, ma analizzeremo i punti salienti dello studio illustrando le conclusioni a cui lo studio è pervenuto.
Limiti dello standard CC/EUCC per una convergenza verso il CRA
Una prima analisi è stata relativa agli elementi tecnici del CC/EUCC dove sono evidenziati i punti di convergenza, ma anche i limiti che tale standard presenta.
Il Target of Evaluation (TOE), in italiano Oggetto della valutazione, è un concetto centrale nello standard CC, e quindi nell’EUCC in quanto definisce i confini della valutazione. In alcuni casi il TOE corrisponde al prodotto ICT, ma non è sempre così. Infatti il TOE può essere costituito da una parte di un prodotto IT o da un insieme di prodotti IT (ad esempio nei sistemi distribuiti). In pratica, è piuttosto comune che il TOE costituisca solo una parte del prodotto o un suo sottoinsieme e, di conseguenza, il TOE e il prodotto ICT hanno confini diversi. Ogni altro elemento diverso dal TOE necessario al funzionamento o all’operatività del TOE, come previsto dallo standard, è denominato ambiente operativo e non è coperto dalla valutazione.
Una prima assunzione che si deve effettuare per l’applicazione delle valutazioni CC/EUCC in ambito CRA è che il TOE copra tutto il prodotto ICT e questo potrebbe essere un problema perché potremmo avere valutazioni CC/EUCC molto complesse in termini di tempi e costi.
L’attuale versione dei CC e la 2022 e questa ha introdotto il concetto di multi-assurance, che prevede la definizione di diversi livelli di sicurezza nell’ambito dei TOE, facilitando così l’applicazione per prodotti completi anche quando gli aspetti di sicurezza sono localizzati solo in parti specifiche del prodotto.
Altro aspetto rilevante sono i Security Functional Requirements (SFR) che, in ambito CC/EUCC, sono i requisiti relativi alle funzionalità di sicurezza che il prodotto in fase di valutazione deve soddisfare. Lo standard CC definisce una serie di SFR strutturati in 11 classi funzionali, che sono ulteriormente suddivise in famiglie funzionali, ma gli SFR sono formulati in modo generico, poiché sono destinati ad essere validi e applicabili a un’ampia varietà di tipi eterogenei di prodotti ICT. In termini più semplici, gli SFR indicano ciò che il TOE deve fare, ma non come deve farlo.
Nonostante l’ampia gamma di classi e famiglie di sicurezza incluse nel CC/EUCC, potrebbero esserci dei casi in cui un prodotto in fase di valutazione presenti caratteristiche di sicurezza specifiche non coperte dagli SFR esistenti nello standard. In tali casi, lo standard Common Criteria consente la creazione di SFR estesi. Si tratta di SFR personalizzati, diversi da quelli presenti nello standard, che devono essere redatti secondo il linguaggio e le convenzioni standardizzati definiti dallo standard stesso (ad esempio devono essere organizzati all’interno di classi e famiglie funzionali).
Lo standard CC/EUCC definisce i Security Assurance Requirement (SAR) come «una descrizione delle modalità di valutazione del TOE» o «una descrizione delle modalità con cui garantire che il TOE soddisfi gli SFR». Si tratta di un tipo specifico di requisito di sicurezza che non riguarda la funzionalità di sicurezza del TOE, ma definisce ciò che sarà valutato durante la valutazione CC/EUCC o, in altre parole, le diverse attività di valutazione che avranno luogo durante la valutazione.
Le SAR sono incluse nelle valutazioni tipicamente attraverso pacchetti di assurance, che sono insiemi di SAR con attività di assurance incrementali. I CC forniscono una serie di sette pacchetti di assurance denominati “Evaluation Assurance Level (EAL)”, con EAL1 che è il più basso ed EAL7 il più alto.
Come gli SFR, anche le SAR sono formulate in modo generico, poiché sono destinati ad essere validi e applicabili a un’ampia varietà di tipi eterogenei di prodotti ICT. Anche in questi casi, il CC consente anche di definire SAR estesi, attraverso lo stesso meccanismo di estensione utilizzato per gli SFR.
Mappatura ESR del CRA con gli SFR e SAR del CC/EUCC
In questa parte del rapporto, ENISA fornisce una mappatura tra gli ESR del CRA e gli elementi tecnici (SFR e SAR) del CC/EUCC.
In particolare:
- viene effettuata la mappatura tra gli ESR dell’Annex 1 – Parte I del CRA con gli SFR del CC/EUCC;
- viene effettuata la mappatura tra gli ESR dell’Annex 1 – Parte II del CRA relativi alla gestione delle vulnerabilità e le SAR della classe AVA del CC/EUCC;
- viene analizzato come mappare il Risk Assessment previsto dal CRA con gli SFR del CC/EUCC, ovvero come faccio a scegliere gli SFR necessari da implementare rispetto alla criticità del prodotto evidenziata dal Risk Assessment;
- infine, viene analizzato come lo scope delle valutazioni CC/EUCC deve essere predisposto per poter utilizzare la valutazione in ambito CRA, ovvero come faccio ad includere tutto il prodotto ICT da valutare in ambito CRA nel TOE della valutazione CC/EUCC.
Tralasciando i dettagli tecnici dell’analisi che sono molto complessi e articolati, un elemento importante che emerge dall’analisi è che la modalità migliore per effettuare valutazioni CC/EUCC che coprano anche i requisiti del CRA è l’utilizzo di Protection Profiles i quali ad oggi sono ampiamente utilizzati in ambito valutazioni CC (si consideri che dal 2020 al 2024 circa il 76% delle valutazioni CC è stata effettuata in conformità ad un PP).
Nello studio ENISA ha analizzato i principali PP esistenti nel mondo e i domini tecnici dell’EUCC per verificare se essi coprono in maniera adeguata sia gli ESR dei prodotti ICT importanti con componenti digitali critici sia gli ESR i principali prodotti importanti elencati negli allegati del CRA.
Dall’analisi emerge che vi è una sostanziale convergenza tra i PP dei CC, domini tecnici EUCC e gli ESR del CRA, anche se esistono dei gap che devono essere risolti. Tra l’altro, tale convergenza è maggiore nei PP/Domini tecnici relativi ai prodotti importanti con elementi digitali critici, ovvero i prodotti ICT con i rischi più alti.
Una possibile soluzione per utilizzare i PP dei CC e i domini tecnici EUCC esistenti nelle valutazioni CRA, è quella di identificare i gap presenti negli attuali PP e integrare gli stessi attraverso inserimento/modifica dei componenti tecnici del CC/EUCC.
Tale attività potrebbe essere effettuata da comitati tecnici di esperti già oggi presenti in varie organizzazioni (es. CEN, CENELEC, ETSI,…).
Strategie per l’implementazione delle convergenza tra CC/EUCC e CRA
Sulla base dell’analisi effettuata, ENISA ha suggerito alcune opzioni che possono essere implementate per ottenere la conformità al CRA utilizzando i CC/EUCC.
- Predisposizione di un Security Target (ST) per la valutazione CC/EUCC del prodotto ICT che sia personalizzato su misura per la conformità al CRA: nonostante l’elevata flessibilità e libertà nell’incorporazione degli elementi tecnici nella ST per avere la conformità agli ESR del CRA, tale soluzione è vista poco percorribile in quanto. La produzione del ST sarebbe molto onerosa e la valutazione rischia di essere molto lunga e costosa. Non è un caso che, ad oggi, solo il 23% dei produttori non utilizza i PP ma effettua valutazioni con ST personalizzati.
- PP personalizzato ad hoc per la conformità agli ESR del CRA: la redazione di un PP generalista che includa tutte le SFR e le SAR necessarie per soddisfare gli ESR del CRA che sia anche tecnologicamente indipendente non è semplice. Inoltre, un PP generalista per tutti i tipi di prodotti potrebbe risultare troppo grande, complesso da sviluppare e forse poco pratico nel suo utilizzo.
- PP-configuration e PP-module: un PP con parti modulari create da moduli PP in cui le funzionalità correlate descritte dagli ESR del CRA sarebbero organizzate in moduli PP che comprenderebbero anche gli SFR e altri elementi tecnici CC correlati. Grazie ai PP-module, il livello di armonizzazione e di flessibilità sarebbe elevato soprattutto per casi d’uso specifici grazie ai moduli PP. Tuttavia, la flessibilità sarebbe limitata al numero finito di combinazioni di moduli PP esistenti. La complessità di applicazione potrebbe essere potenzialmente elevata e, come nel caso precedente, l’interoperabilità con i ST che dichiarano di essere conformi ad altri PP potrebbe essere difficile.
- Pacchetti funzionali e di assurance standalone: i pacchetti funzionali e di assurance contengono, rispettivamente, insiemi di SFR (funzionali) e SAR (di assurance) e possono essere definiti in modo modulare e riutilizzabile. Possono essere inclusi in ST standalone, in PP o in moduli PP. Tale soluzione offre una elevata flessibilità e un buon livello di interoperabilità con le certificazioni conformi ai PP (tranne quando si utilizza la conformità esatta). Il livello di armonizzazione sarebbe moderato e i PP con conformità esatta dovranno essere aggiornati per includere questi pacchetti.
- PP con Pacchetti Funzionali: definizione di uno o più PP che dichiarano la conformità con i pacchetti funzionali e di assurance che includono le SFR e le SAR richieste per conformarsi agli ESR delle CRA. Tale soluzione presenta un elevato equilibrio tra flessibilità e armonizzazione. L’interoperabilità con le certificazioni conformi ai PP è limitata a quelle che non utilizzano la conformità esatta. I PP con conformità esatta dovranno essere aggiornati per includere questi pacchetti.
Come si può evincere da quanto illustrato, esistono diverse strategie che possono essere utilizzate e che non si escludono l’una con l’altra. Emerge altresì che l’utilizzo dei PP e di tutte le sua accezioni (PP-configuration, PP-module, PP-packages,..) al momento solo le soluzioni che sembrano offrire il miglior bilanciamento tra flessibilità e complessità della valutazione del prodotto.
Conformity Assessment Body (CAB) in ambito CSA vs Notified Body (NB) in ambito CRA
I CAB in ambito Cyber Security ACT (CSA) sono gli organismi accreditati per effettuare la valutazione della sicurezza dei prodotti ICT rispetto all’EUCC e possono, se sono anche Certification Body, emettere i relativi certificati.
In ambito CRA, sono identificati dei Notified Body che sono degli organismi di valutazione delle conformità (in pratica dei CAB) che sono conformi a quanto prescritto dal CRA e notificati dall’Autorità Nazionale alla Commissione Europea come organismi autorizzati alla verifica della conformità dei prodotti ICT rispetto ai requisiti del CRA. Non è richiesto obbligatoriamente un accreditamento per tali organismi che devono solo dimostrare all’Autorità notificante che essi agiscono secondo i requisiti del CRA (art 39). Ad ogni buon conto, le Autorità Nazionali possono decidere comunque un accreditamento di tali organismi utilizzando l’Autorità di Accreditamento Nazionale preposta, in Italia è ACCREDIA.
Osservando i requisiti richiesti ai CAB dal CSA e quelli richiesti ai NB dal CRA, si nota come essi siano molto allineati soprattutto per quanto riguarda i requisiti relativi allo status giuridico, l’indipendenza, l’imparzialità, le responsabilità, le competenze tecniche e le procedure e, infine, la riservatezza e la trasparenza.
Inoltre, la norma ISO 17065 utilizzata per l’accreditamento dei CAB in ambito EUCC è molto vicina ai requisiti richiesti dal CCRA e quindi, i CAB già certificati EUCC, sono ottimamente posizionati per diventare dei NB in ambito CRA.
Infatti, i CAB EUCC CAB potenzialmente agire come organismi notificati CRA e questo sarebbe particolarmente utile per valutare le sovrapposizioni tra i due schemi di certificazioni (ad esempio PP CC vs ESR del CRA).
In conclusione, non si esclude che in futuro, con lievi modifiche, i CAB EUCC potrebbero qualificarsi come organismi notificati CRA promuovendo sinergie tra i quadri normativi dell’UE in materia di sicurezza informatica.
Prospettive future per la convergenza CRA EUCC nel mercato europeo
L’entrata in vigore del CRA, e in particolare la sua applicazione vincolante dopo 36 mesi, avrà un impatto dirompente sul mercato europeo dei prodotti ICT.
Lo studio di ENISA è molto bene fatto e articolato e fornisce alcuni spunti che devono essere ulteriormente verificati.
Se da una parte una convergenza tra CRA e EUCC è possibile, la sua implementazione non sembra essere molto agevole considerando anche che ad oggi non sono state ancora effettuate valutazioni EUCC in quanto gli schemi nazionali termineranno di operare il 26 febbraio 2026.
Per tale ragione, ENISA sta promuovendo l’esecuzione di diversi progetti piloti per verificare sul campo le evidenze emerse dallo studio.
Altro aspetto rilevante dello studio è la conclusione che la convergenza tra CRA ed EUCC è possibile utilizzando i PP. Paradossalmente, i PP utilizzati oggi per i prodotti importanti e quelli importanti con elementi digitali critici, hanno una copertura con il CRA già molto elevata.
È pertanto richiesto un elevato sforzo da parte dei comitati tecnici delle varie Organizzazioni Europee per aggiornare i PP attuali e in tale ambito la Commissione Europea ha già promosso la produzione circa 40 linee guida e intende supportare tale sforzo.
In conclusione, come fatto per altre normative (vedi il DORA in ambito finanziario, NIS2 per le infrastrutture critiche,..), la Commissione Europea spinge molto sulla cybersicurezza cercando di ottenere, come primo risultato, una security-by-compliance. Ma il mercato e gli attori coinvolti in tali normative non sono spesso ancora pronti ed è quindi importante che la Commissione Europea e tutte le principali Istituzioni a contorno supportino tali iniziative sia dal punto di vista tecnico che normativo e finanziario al fine di evitare di vanificare le stesse e non ottenere l’aumento del livello di sicurezza auspicato.
