È stata di recente pubblicata una modifica alla proposta di legge UE del 2022 riguardante la cyber security dei prodotti connessi che si chiama Cyber Resilience Act (ovvero CRA). La versione modificata della CRA è stata pubblicata il 20 dicembre 2023 (Proposta n. 17000/23) e include chiarimenti in generale per l’ambito di applicazione del regolamento e specialmente nell’area del software open source per renderlo molto più in linea con il modo in cui è effettivamente strutturata la moderna industria del software.
Le modifiche introdotte riguardano quasi tutti gli articoli della normativa (che sono ben 57) e anche gli allegati (che sono 6).
Ma vediamo meglio nel seguito quali sono le principali novità introdotte.
Software Defined “everything” (SDx): cos’è, modelli di minaccia e best practice difensive
Indice degli argomenti
Cyber Resilience Act: le novità introdotte
Innanzitutto, si ribadiscono i principi guida della normativa e lo scopo principale:
Gli obiettivi principali sono due:
- creare le condizioni per lo sviluppo di prodotti sicuri con elementi digitali garantendo che i prodotti hardware e software siano immessi sul mercato con meno vulnerabilità e garantire che i produttori prendano sul serio la sicurezza durante tutto il ciclo di vita di un prodotto;
- creare condizioni che consentano agli utenti di tenere conto della sicurezza informatica nella scelta e nell’utilizzo di prodotti con elementi digitali.
Gli obiettivi specifici sono quattro:
- garantire che i produttori migliorino la sicurezza dei prodotti con elementi digitali sin dalla fase di progettazione e sviluppo e durante l’intero ciclo di vita;
- garantire un quadro di sicurezza informatica coerente, facilitando la conformità per i produttori di hardware e software;
- migliorare la trasparenza delle proprietà di sicurezza dei prodotti con elementi digitali;
- consentire alle aziende e ai consumatori di utilizzare prodotti con elementi digitali in modo sicuro.
La nuova classificazione dei prodotti
Il primo dato di novità riguarda la classificazione dei prodotti che viene stabilita in questo modo:
- prodotti “importanti” (dal punto di vista della cyber security), suddivisi a loro volta in due classi (Classe I e Classe II);
- prodotti “critici”, una sola classe, di cui esiste una lista preliminare.
Procedura da seguire per assicurare la conformità normativa dei prodotti
Il secondo dato da sottolineare, collegato a questa suddivisione, è la diversa procedura da seguire per assicurare la conformità o meno alla normativa. Sono previsti quattro cosiddetti “Moduli”:
- Modulo A, da utilizzare per controlli interni, serve ad esempio per prodotti che non rientrano nelle categorie previste dalla norma.
- Modulo B, da utilizzare per una conformità eseguita da un ente accreditato.
- Modulo C, da utilizzare (insieme al precedente) per controlli interno sulla produzione.
- Modulo H, per una conformità più estesa che comprende anche il sistema qualità dell’azienda.
È ovvio che ogni modulo verrà applicato in base alla criticità dei prodotti sotto esame.
I prodotti coinvolti ed esclusi dal Cyber Resilience Act
Alcuni esempi di prodotti importanti della Classe I sono:
- IAM systems
- Biometric readers
- Browsers
- Password managers
- Network Management systems
E per la Classe II:
- Hypervisors
- Firewalls
- IDS/IPS
- Microprocessors
- Microcontrollers
Mentre per ora i prodotti critici identificati sono i seguenti:
- Hardware devices with Security boxes
- Smart meters
- Smartcards
- Smart home
Sono invece esclusi (Out-of-scope) le seguenti altre tipologie di prodotti, perché già considerati in normative dedicate di settore:
- Open source software (se non inserito in attività commerciale).
- Cloud services (che ricadono nella direttiva NIS).
- Dispositivi Medicali or “in-vitro diagnostic” (che ricadono nella direttiva MDR).
- Prodotti del settore Aviazione civile (che ricadono nella Regulation (EU) 2018/1139.
- Prodotti del settore Motor vehicles (che ricadono nella direttiva (EU) 2019/2144.
- Prodotti del settore Marine (che ricadono nella direttiva Directive 2014/90/EU )
- Prodotti in generale per la sicurezza nazionale o scopi militari o prodotti specificatamente progettati per elaborare informazioni classificate.
Maggiore attenzione sul software open source
Per la parte open source software e software in generale ci sono state modifiche importanti, anche a seguito della iniziale preoccupazione da parte di molte organizzazioni che vedevano minacciato il lavoro del software libero.
In particolare, si è chiarito il seguente approccio:
Per software libero e open source si intende il software il cui codice sorgente è apertamente condiviso e la cui licenza prevede tutti i diritti per renderlo liberamente accessibile, utilizzabile, modificabile e ri-distribuibile. Il software gratuito e open source viene sviluppato, mantenuto e distribuito apertamente, anche tramite piattaforme online. In relazione agli operatori economici soggetti al regolamento, solo il software gratuito e open source reso disponibile sul mercato e quindi fornito per la distribuzione o l’utilizzo nel corso di un’attività commerciale dovrebbe essere disciplinato dal presente regolamento…
… Per favorire lo sviluppo e la diffusione di software libero e open source, in particolare da parte di microimprese e piccole e medie imprese, comprese le start-up, e organizzazioni senza scopo di lucro, ricercatori accademici e singoli individui, l’applicazione del regolamento CRA a software gratuiti e open source i prodotti software open source forniti per la distribuzione o l’utilizzo nel corso di un’attività commerciale dovrebbero tenere conto della natura dei diversi modelli di sviluppo del software distribuito e sviluppato nell’ambito licenze software gratuite e open source…
… Persone giuridiche che forniscono sostegno su base continuativa per lo sviluppo di tali prodotti con elementi digitali qualificabili come software gratuiti e open source, destinati ad attività commerciali, e svolgono un ruolo principale nel garantire la fattibilità di tali prodotti (‘ gli steward del software open source’) dovrebbero essere soggetti a un regime normativo leggero e su misura ……Il solo atto di ospitare prodotti con elementi digitali su repository aperti, anche tramite gestori di pacchetti o su piattaforme di collaborazione, non costituisce di per sé messa a disposizione sul mercato di un prodotto con elementi digitali. I fornitori di tali servizi dovrebbero essere considerati distributori solo se mettono tale software a disposizione sul mercato e quindi lo forniscono per la distribuzione o l’uso sul mercato dell’Unione europea nel corso di un’attività commerciale.
Alcuni nuovi concetti sono stati dunque introdotti nell’ambito software: viene sottolineata più volte l’importanza del “SBOM” (Sw Bill of Materials), si è introdotto il concetto di “Unfinished Sw” (es. versioni alfa, beta del software), e quello di “Steward” in riferimento agli attori coinvolti nel processo di distribuzione di software open source.
L’importanza del risk assesment e della gestione vulnerabilità
Un altro aspetto maggiormente enfatizzato in questa revisione della norma è il concetto dell’importanza di risk assesment e gestione vulnerabilità che deve seguire il prodotto per tutta la durata del ciclo di vita con relativi aggiornamenti, laddove necessario.
Infine, si sono introdotti articoli specifici per le medio-piccole imprese, microimprese e anche startup, onde agevolare questo percorso per aziende che hanno al proprio interno risorse limitate. Proprio in riferimento a queste categorie anche l’importante articolo 53 sulle sanzioni è stato modificato. Nuove linee guida apposite sono attese quando la normativa entrerà in vigore.
Si sono poi chiariti meglio i ruoli di Fabbricante, Importatore, Distributore e/o ruoli non appartenenti a queste categorie, con i relativi obblighi di conformità.
Conclusioni
Lo scopo finale del Cyber Resilience Act è garantire che i prodotti con elementi digitali immessi sul mercato dell’UE presentino meno vulnerabilità e i produttori siano responsabili della sicurezza informatica per tutto il ciclo di vita di un prodotto.
È importante anche sottolineare l’interscambio tra questa direttiva e altre normative europee: NIS2, GDPR (privacy), RED (per dispositive Radio), AI Act (Intelligenza artificiale), direttive Macchina e Safety. Questo per assolvere la strategia digitale europea che vuole quattro pilastri:
- protezione dei dati;
- diritti fondamentali;
- sicurezza (intesa come “Safety”);
- cyber security.
Il chiarimento sul software open source (forse l’aspetto principale che ha subito modifiche) è stato recepito positivamente dai principali fornitori e sviluppatori, ma alcuni punti rimangono ancora aperti in questa revisione.
Ad esempio, la costituzione di una piattaforma on-line per il reporting di incidenti e vulnerabilità, la costituzione di schemi europei di certificazione per assolvere alla conformità dei prodotti critici, la costituzione dei corretti flussi di notifica verso CSIRT ed ENISA, infine l’interscambio con le altre normative di cui sopra, dovrà essere regolamentato per evitare sovrapposizioni o contrasti. Anche l’accreditamento degli enti certificatori dovrà essere finalizzato prima dell’entrata in vigore della norma.
Una volta che il Cyber Resilience Act verrà approvato e adottato dai paesi UE, operatori economici e Stati membri avranno tre anni per adeguarsi alle nuove esigenze.
L’obbligo di segnalare le vulnerabilità sfruttate attivamente e gli incidenti si applicheranno invece dopo due anni circa.
