Il Parlamento Europeo ha approvato il testo definitivo del Cyber Resilience Act (CRA). Ora il testo dovrà essere formalmente approvato dal Consiglio Europeo per diventare legge.

Dopo che, a fine gennaio, la Commissione Europea aveva approvato il Regolamento di esecuzione relativo all’adozione di un sistema europeo comune di certificazione della cybersecurity basato sui Common Criteria, questo passaggio era atteso, per definire i requisiti di cyber security per i prodotti con componenti digitali immessi sul mercato europeo.

Si tratta di un passaggio destinato ad avere, seppure non in tempi brevissimi, un impatto enorme sulla sicurezza complessiva dei prodotti immessi sul mercato dell’Unione, ma anche sul mercato del software in generale.

A fronte di un gran numero di normative verticali sulla sicurezza, come ad esempio il GDPR per quanto riguarda la protezione dei dati personali, la Direttiva NIS2 per i soggetti essenziali ed importanti, l’MDR (Medical Device Regulation, Regolamento UE n. 2017/745) per i dispositivi medici, nonché normative verticali per settori come quello bancario o quello delle telecomunicazioni, mancava una normativa che potesse coprire orizzontalmente i tanti dispositivi digitali che ormai affollano le nostre aziende ed abitazioni: dalle videocamere di sorveglianza per uso domestico, alle smart tv, ai prodotti per la domotica, ai plc industriali, fino ai pacchetti software venduti per gli usi disparati.

Tutti questi prodotti sono venduti, in generale, senza alcuna garanzia dal punto di vista della sicurezza, lasciando all’acquirente l’onere di valutarla o, più spesso, di subirne le carenze per mancanza di informazioni e alternative.

Cyber Resilience Act: perimetro di applicabilità

Più specificamente, il Cyber Resilience Act si applica a tutti i prodotti (hardware e software) con componenti connessi, direttamente o indirettamente, con altri dispositivi o reti. L’impatto è quindi ampissimo.

Sono esplicitamente esclusi i prodotti soggetti ad alcune normative verticali che già prevedono logiche analoghe al CRA, in particolare in termini di certificazione, quali i dispositivi medici e i dispositivi medico-diagnostici in vitro, soggetti rispettivamente al Regolamento (UE) 2017/745 e al Regolamento (UE) 2017/746.

Non si applica, inoltre, veicoli a motore e relativi componenti, soggetti al Regolamento (UE) 2019/2144, e ai prodotti già certificati secondo il Regolamento (UE) 2018/1139 relativo al settore dell’aviazione civile.

Sono esclusi poi, in generale, i prodotti coperti da eventuali norme settoriali che garantiscano un analogo livello di sicurezza.

Infine, e questo è stato uno dei temi importanti nel corso della definizione del testo definitivo, il Cyber Resilience Act è applicabile al software free e open-source solo quando sia reso disponibile sul mercato nell’ambito di un’attività commerciale.

È stato trovato, quindi, un non facile equilibrio fra la necessità non ostacolare eccessivamente lo sviluppo di software che rappresenta un patrimonio importante, non solo dal punto di vista economico, e quella di tutelare gli utenti anche quando facciano uso di prodotti che lo contengono.

Non ricadono nel perimetro di applicabilità, quindi, i servizi, in particolare ad esempio il SaaS, essendo il CRA applicabile a prodotti.

Tuttavia, la definizione di prodotto comprende le sue “soluzioni di data processing remote”, compresi componenti hardware e software immessi sul mercato separatamente.

Quindi, se parte di un componente IoT è il servizio SaaS che ne consente l’utilizzo, quest’ultimo servizio ricade nel perimetro di applicabilità.

Requisiti per produttori, importatori e distributori

Cosa viene chiesto, nel concreto, ai produttori e, particolarmente per i prodotti importati dal di fuori dell’Unione Europea, agli importatori e distributori?

I requisiti si possono raggruppare in:

1. requisiti per i prodotti;
2. requisiti per i processi di gestione della conformità.

I requisiti per i prodotti sono elencati nell’allegato I e riguardano principalmente:

1. L’assenza di vulnerabilità note al momento dell’immissione sul mercato; questo comprende anche vulnerabilità che riguardino i componenti utilizzati, ad esempio ASIC, librerie software ecc.; da questo derivano requisiti sia indicati direttamente, come la gestione di un Software bill of materials (SBOM), sia indirettamente, come la necessità di selezionare con attenzione i propri fornitori, perché siano a loro volta in grado e disponibili a produrre e rendere disponibili le correzioni per eventuali vulnerabilità.
2. La gestione delle vulnerabilità e degli aggiornamenti durante il ciclo di vita del prodotto, mantenendo dove possibile separati gli aggiornamenti funzionali da quelli di sicurezza, e fornendo strumenti per l’aggiornamento automatico.
3. Una serie di requisiti normalmente previsti dalle buone pratiche di settore, come security by design, configurazioni sicure per default, meccanismi di autenticazione per l’accesso, meccanismi di tracciamento degli eventi di sicurezza, meccanismi di cancellazione sicura dei dati eccetera.

La gestione delle vulnerabilità è in effetti il cardine dell’intero Regolamento, partendo dalla loro gestione durante la progettazione e lo sviluppo, fino alla segnalazione e alla gestione degli aggiornamenti.

Il Regolamento pone dei requisiti anche per le attività di divulgazione delle (informazioni sulle) vulnerabilità, la cosiddetta vulnerability disclosure, sia nei confronti dell’ENISA che nei confronti degli utenti.

Nel complesso, i requisiti non si discostano molto da quanto già implementato dai produttori di software più maturi, per i quali siano disponibili bollettini informativi e aggiornamenti automatici.

Costituisce, però, un salto di qualità enorme per i prodotti realizzati da tante piccole aziende poco strutturate o, peggio ancora, importati dall’estero e immessi sul mercato, o utilizzati all’interno di propri prodotti sulla base di criteri in cui l’aspetto economico prevale enormemente rispetto alla qualità.

Proprio l’attenzione alle piccole aziende, e agli oneri che questo regolamento potrebbe imporre loro, è stata oggetto di molte osservazioni e modifiche alla norma, nel tentativo di ridurre l’impatto e facilitare la conformità.

Particolarmente interessante, per quanto dipendente da come verrà implementata, è l’indicazione, per gli Stati membri e per l’ENISA, di realizzare degli ambienti di test controllati per prodotti innovativi, per facilitarne lo sviluppo, in particolare a supporto delle microimprese e PMI, comprese le startup.

Cyber Resilience Act: conformità e marchio CE

I prodotti con componenti digitali immessi sul mercato, compresi quindi i prodotti software, dovranno riportare il marchio CE e, per poterlo fare, dovranno aver soddisfatto i requisiti posti dal Cyber Resilience Act sui prodotti e sui processi messi in atto per soddisfarli.

Ci si muove, quindi, nella direzione di sollevare l’utente, azienda o cittadino, dall’onere di valutare e, in caso di requisiti posti da altre normative come il GDPR o la Direttiva NIS2, dimostrare, l’adeguatezza di un prodotto dal punto di vista della cyber security.

Come, ad esempio, non è richiesto a un cittadino di valutare se i freni della sua automobile siano adeguati, perché l’immissione sul mercato di un’automobile è subordinato ad un processo in cui questi aspetti sono valutati, così al cittadino e all’azienda sarà garantito che un prodotto con componenti digitali sia immesso sul mercato con determinate garanzie di cyber security, che quindi l’utente non avrà bisogno di verificare.

Sarà fornita, insieme al prodotto, la documentazione necessaria per comprendere per quale contesto di utilizzo sia adatto il prodotto, e su come utilizzarlo in modo sicuro.

I prodotti saranno quindi divisi in quattro categorie: i prodotti non critici, quelli critici di classe I e quelli critici di classe II, entrambi riconducibili agli elenchi in Allegato III (da aggiornare ogni due anni), e quelli altamente critici, individuati caso per caso dalla Commissione Europea. Per questi prodotti altamente critici sarà richiesta una certificazione secondo lo schema di certificazione europea citato all’inizio di questo articolo.

Per i prodotti delle classi I e II, invece, è previsto un processo meno impegnativo ma comunque piuttosto articolato, per il quale sarà essenziale l’attività da parte della Commissione Europea, attraverso atti delegati, per la creazione di norme (tecniche) armonizzate che possano essere utilizzate a questo scopo.

Un’attenzione specifica viene data anche ai sistemi di AI classificati come ad alto rischio secondo l’AI Act, nonché ai prodotti che ricadono sotto il Regolamento macchine.

Tempi per la creazione di un mercato UE uniforme per i produttori

Con l’adozione del Cyber Resilience Act, l’Unione Europea punta alla creazione di un mercato per prodotti digitali connessi sicuri, per i quali i requisiti di sicurezza siano una garanzia per aziende e cittadini, ma che consenta anche alle aziende produttrici e importatrici di avere un’unica normativa di riferimento, salvo eventualmente per mercati particolarmente critici come quello della Difesa.

Questa uniformità di requisiti e procedure dovrebbe rendere nel complesso più accessibile un mercato europeo che altrimenti, per i requisiti di sicurezza, risulterebbe frammentato in 27 piccoli mercati, ciascuno con i propri requisiti e ciascuno, in molti casi, troppo poco interessante per affrontarne i requisiti di conformità.

Da questa norma, posto l’obiettivo comunque di avere prodotti adeguati dal punto di vista della mitigazione dei rischi di cyber security, dovrebbero trarre vantaggio sia gli utenti che i produttori.

La norma prevede 36 mesi per l’adeguamento a partire dalla data dell’entrata in vigore, salvo alcuni requisiti relativi alla notifica ad ENISA di vulnerabilità ed incidenti, che saranno efficaci dopo 18 mesi.

Si tratta di tempi apparentemente lunghi, ma non dobbiamo dimenticare che molti prodotti che verranno immessi sul mercato fra tre anni sono probabilmente in fase di progettazione già adesso, e quindi è opportuno iniziare da subito ad operare secondo i principi e requisiti indicati dalla norma, adeguando i propri processi di sviluppo e, ancora di più, di acquisizione di componenti da terze parti.

@RIPRODUZIONE RISERVATA