Riflessioni sugli elementi che i decisori dovrebbero prendere in considerazione per raggiungere effettivamente una maggiore sicurezza informatica nei prodotti e nei servizi digitali.
Nel maggio 2022, la Commissione europea ha invitato tutte le parti interessate a condividere i propri contributi per l’imminente Cyber Resilience Act (CRA). Avendo individuato la necessità di rafforzare la sicurezza dei “prodotti e servizi digitali” moderni e avendo ravvisato la mancanza di incentivi – sia per i consumatori che per i produttori – a valutare la sicurezza di prodotti e servizi, la Commissione ha avviato una discussione più ampia su una potenziale nuova serie di requisiti diretti di cybersecurity per “tutto ciò che oggi è un computer” (e non solo). Ciò potrebbe rivoluzionare concretamente l’intero settore tecnologico al di là dei confini formali dell’UE, ma anche avere ulteriori implicazioni tecnologiche ed economiche.
In questo articolo vorremmo suggerire alcuni quadri di riferimento per questa discussione e per il futuro CRA. Scopo principale è quello di condividere le nostre prime riflessioni (dato l’attuale inizio anticipato del processo legislativo) derivanti dalla nostra vasta esperienza professionale in campo di cybersecurity. Di seguito ci concentreremo su sei idee principali; l’elenco completo di tutte le riflessioni è disponibile nella presentazione completa fatta il mese scorso.
Non esitate a contattarci per condividere il vostro feedback: saremo lieti di discuterne!
#1 Adottare un approccio differenziato: i prodotti (hardware e software) e i servizi digitali richiedono una serie di requisiti di cybersecurity su misura, e devono essere presi attentamente in considerazione.
Data l’intenzione di introdurre requisiti di cybersecurity per i prodotti digitali e i servizi accessori, ciò che va considerato per prima cosa è la necessità di mantenere un approccio attentamente differenziato per ogni sottoinsieme di tali prodotti, ossia hardware, software, IoT e servizi. È necessario un approccio personalizzato per cogliere in modo realistico le specificità dell’uso di tali prodotti e, di conseguenza, i loro profili di rischio. In particolare, l’uso di servizi digitali non crea generalmente rischi diretti di compromissione della rete dei clienti o degli utenti finali, al contrario di quanto avviene con l’uso di prodotti digitali on-premise. In modo analogo, software e hardware sono prodotti con una “natura” e un’applicazione diverse.
#2 Anche gli strumenti e le librerie open source utilizzati nei servizi critici dovrebbero essere presi in considerazione.
La recente divulgazione di una serie di vulnerabilità in librerie open source (log4j) ha messo in evidenza la “vulnerabilità endemica” in tutta la rete Internet globale all’interno di prodotti software vecchi e nuovi, coinvolgendo così più parti interessate nella comunità di sviluppo del software, nell’industria tecnologica e negli apparati governativi. Sebbene non sia stata sviluppata una soluzione universale per risolvere il problema, è importante sollevare la questione della disponibilità e della sicurezza di strumenti e librerie open source così critici. Si spera che il futuro CRA impegni sotto questo punto di vista, in uno sforzo coordinato, tutta l’UE nonché i partner internazionali.
#3 L’intero ciclo di vita dei prodotti digitali on-premise dovrebbe essere coperto da requisiti di cybersecurity, mentre i servizi richiedono un approccio diverso.
Nell’analisi, di cui siamo coautori, sulle lacune politiche nel garantire la sicurezza della catena di approvvigionamento delle TLC (sviluppato con una comunità multistakeholder all’interno del Gruppo di lavoro 6 dell’Appello di Parigi), abbiamo sottolineato che “garantire la sicurezza dei prodotti e dei servizi TLC è uno sforzo continuo, lungo tutto il ciclo di vita della distribuzione, per proteggere i clienti e gli utenti finali”. Questo non è certo un concetto definitivo. A questo proposito, in particolare, concordiamo con i Paesi Bassi sul fatto che il CRA dovrebbe coprire l’intero ciclo di vita, ossia “dalla fase di progettazione fino alla dismissione e allo smaltimento”. Ma ci sono importanti sfumature.
Primo: l’uso, la manutenzione, la disattivazione e lo smaltimento non sono gli stessi per i prodotti o per i servizi. In particolare, i servizi digitali (ad esempio, nel contesto dell’elaborazione in cloud) non sono soluzioni on-premises, il che significa che il cliente o l’utente finale non ha la completa proprietà locale dei dati elaborati o del software e dell’hardware utilizzati. In secondo luogo, la maggior parte dei servizi digitali non può essere completamente autonoma (ad eccezione di reti chiuse basate su cloud specificamente progettate): l’accesso da parte di terzi è una caratteristica predefinita, il che significa che il produttore o il fornitore (una parte terza) svolge un ruolo nel garantire la sicurezza durante l’intero ciclo di vita.
Questo porta chiaramente a diversi prodotti e servizi con diverse forme di relazione tra produttori/fornitori e clienti/utenti finali. Ad esempio, i requisiti di gestione delle vulnerabilità dovrebbero essere differenziati in particolare tra software on-premise e servizi cloud, per riflettere i diversi ruoli e responsabilità in materia. Nel caso di software on-premises, il cliente o il committente conosce meglio la propria infrastruttura e ha il pieno controllo di definire e controllare i requisiti di sicurezza; per questo motivo sarebbe il principale responsabile della gestione immediata delle patch e dovrebbe anche garantire che tutti i prodotti del perimetro funzionino con software o hardware aggiornati. Nel caso dei servizi cloud, la situazione è diversa: è il proprietario di un servizio cloud il principale responsabile dell’efficace patch dei suoi servizi e della mitigazione di eventuali vulnerabilità, non il cliente.
Ci auguriamo che questi diversi contesti, usi e forme di relazione, vengano presi in considerazione nel futuro CRA per sviluppare requisiti di cybersecurity su misura.
#4 Gli incentivi per un comportamento più orientato alla sicurezza dovrebbero essere forniti sia dal lato della domanda che da quello dell’offerta.
Apprezziamo lo sforzo della Commissione di affrontare anche la mancanza di incentivi come prerequisito per una maggiore consapevolezza della sicurezza sia da parte dei consumatori e dei produttori. Nel rapporto analitico del Paris Call WG6 citato in precedenza, abbiamo sviluppato un elenco dettagliato e strutturato di incentivi chiave per stimolare un comportamento orientato alla sicurezza nel mercato. Gli incentivi economici – che comprendono la pressione dei clienti/utenti finali, la pressione dei pari e la concorrenza con altri operatori – sono solo una parte della storia. Anche se gli incentivi possono essere specifici per il mercato e per il settore, l’intervento del governo si configura come indispensabile al fine di risolvere l’asimmetria informativa esistente (ne abbiamo scritto in un precedente blogpost) e la mancanza di incentivi.
Cosa si può fare, dunque? Etichettatura, valutazioni di conformità e certificazioni sono solo parte di un disegno più grande. L’introduzione di un’etichettatura volontaria della sicurezza dei prodotti digitali è una delle pratiche normative discusse anche dall’OCSE, dal Dialogo di Ginevra e negli Stati Uniti, dove l’Ordine Esecutivo del Presidente ha già prescritto misure per i programmi di etichettatura dei prodotti di consumo IoT e dei software di cybersecurity. Il NIST statunitense ha persino proposto una bozza di criteri di base per l’etichettatura della cybersicurezza del software per i consumatori e ha sviluppato quattro categorie di attestazioni in base alle quali i consumatori possono ottenere maggiori informazioni sullo sviluppo sicuro del software, sulle pratiche di protezione dei dati e altro ancora. Nell’affrontare questo aspetto all’interno del CRA, riteniamo che si debbano considerare alcuni fattori chiave:
- è fondamentale che il CRA, in quanto legislazione orizzontale, sia armonizzato e coerente con altre legislazioni – il Cybersecurity Act dell’UE, che ha già imposto la creazione di una certificazione europea di cybersecurity. Nel definire i requisiti di cybersecurity, il CRA dovrebbe integrare il Cybersecurity Act, non sovrapporvisi.
- I moderni prodotti software sono multicomponenti e, nella progettazione di etichette/valutazioni di conformità, difficilmente possono funzionare criteri statici per software dinamici destinati ai consumatori, poiché la conformità a tali criteri diventerebbe obsoleta abbastanza rapidamente. L’attenzione, quindi, dovrebbe essere spostata dalle valutazioni statiche alla valutazione dei processi e dei controlli. Per esempio, invece di un requisito di sicurezza per un prodotto software formulato come “non presenta vulnerabilità”, sarebbe meglio “attiva controlli di gestione e divulgazione delle vulnerabilità”.
In un articolo separato, abbiamo scritto di più sui fattori chiave per rendere efficace l’etichettatura del software per i consumatori.
#5 Il divario esistente in materia di fine vita (EOL) deve essere affrontato.
Numerose discussioni tra esperti nell’ambito del Dialogo di Ginevra, dell’OCSE e del rapporto analitico del Gruppo di lavoro Paris Call WG6 sulle lacune delle politiche in materia di sicurezza della catena di approvvigionamento delle TLC hanno messo in evidenza l’attuale divario tra la fine del ciclo di vita (EOL), ossia tra la fine del supporto alla sicurezza e la fine dell’utilizzo.
Per affrontare il gap EOL, è necessario un approccio personalizzato per i diversi prodotti (software, hardware o IoT). Alcune idee includono, ad esempio, la richiesta agli attori del lato dell’offerta di progettare e implementare politiche EOL chiare e trasparenti per i loro prodotti e servizi digitali, la pubblica dichiarazione circa la durata minima per la quale un prodotto verrà fornito con aggiornamenti di sicurezza.
#6 La cooperazione internazionale è fondamentale per evitare la frammentazione degli standard e dei requisiti emergenti.
La Commissione ha annunciato l’obiettivo di sviluppare modelli di cybersecurity al fine di “rafforzare la leadership dell’UE nella definizione di standard, definendo standard per i prodotti digitali e i servizi ausiliari che potrebbero servire come parametri di riferimento a livello globale”, in conformità con la strategia dell’UE per la standardizzazione (febbraio 2022). Dato l’importante ruolo che l’UE svolge a livello globale nello sviluppo di norme e nel perseguimento di valori nell’approccio alla regolamentazione della cybersecurity, chiediamo di sviluppare il dialogo con altri Paesi (e con i loro organismi di regolamentazione), gli organismi di standardizzazione, l’industria e la comunità tecnica in generale a livello internazionale.
Se il CRA stabilisce requisiti diretti di cybersecurity per i moderni prodotti e servizi digitali, compresi gli IoT (fino a quando questi non saranno chiaramente esclusi dal campo di applicazione), non c’è dubbio che la legislazione dell’UE avrà un impatto sull’intero settore tecnologico, interessando un numero di produttori ben superiore a quelli registrati nell’UE. Ecco perché è fondamentale garantire un dialogo internazionale continuo per evitare la frammentazione degli standard e dei requisiti emergenti. Raccomandazioni simili sono state formulate anche dall’OCSE come parte delle sei raccomandazioni di alto livello rivolte ai responsabili politici, così come dal Dialogo di Ginevra (durante il suo evento online con i rappresentanti dei governi, dell’industria, della ricerca e della comunità accademica).
Conclusioni
Sostenendo pienamente le intenzioni della Commissione Europea di stabilire requisiti diretti di cybersecurity per i moderni prodotti e servizi digitali, siamo ansiosi di vedere se un singolo atto legislativo sarà in grado di coprire l’intero insieme di tali prodotti e servizi (software, hardware, IoT, servizi cloud [per tutti: sia industriali che consumer]). In ogni caso, l’avvio di una più ampia discussione del settore sul futuro CRA è un passo che arriva nel momento giusto, nonché molto apprezzato da parte dell’autorità di regolamentazione per portare maggiore sicurezza e protezione in una società che si sta rapidamente digitalizzando.