Vulnerabilità digitali: ecco il nuovo approccio europeo

Paper security e sicurezza reale

La falsa percezione della sicurezza, costituita dal solo rispetto formale delle regole, ossia quella che viene correntemente definita “paper security”, o security di carta, rischia di far maggior danni della stessa minaccia.

La sicurezza reale è certamente una necessità, che riesce ad essere convergente con la conformità alle regole se e in quanto sia davvero in grado di prevenire, contenere, rispondere e rimediare agli eventi di sicurezza, idonei a determinare impatti sulla disponibilità, integrità e riservatezza delle informazioni.

Conoscere e risolvere le vulnerabilità

Se è vero – com’è vero – questo assunto, va da sé che l’organizzazione di sicurezza da un lato deve conoscere la minaccia, dall’altro, e in via principale, è chiamata ad uno sforzo quotidiano ed ininterrotto per l’identificazione e la risoluzione delle vulnerabilità (di tipo tecnico ed organizzativo, ma anche di fattore umano) che possano consentire all’attore ostile di ottenere accesso ai sistemi, acquisire privilegi amministrativi, evadere i controlli ed arrecare danni incommensurabili.

L’importanza del fattore tempo

Una prima riflessione, tutt’altro che banale se si considerano le statistiche del tempo intercorrente tra la scoperta di una vulnerabilità, il rilascio dei correttivi da parte del vendor del prodotto e l’effettiva applicazione del rimedio è proprio il fattore tempo, che è una variabile che gioca sempre a favore dell’attaccante.

Sistemi operativi obsoleti

Secondo il sito StatCounter[1], ancora nel mondo resistono decine di milioni di PC desktop con sistemi operativi obsoleti (Win7 con una quota del 2,4% dell’intero share), ma la situazione è sicuramente peggiore per i sistemi operativi server, dove la contesa tra Windows Server e le diverse distribuzioni di Linux si gioca anche sulla capacità delle organizzazioni di sostenere i costi di hardware e aggiornamenti software rilasciati con estrema frequenza per far fronte sia a “bug” tecnici che a vulnerabilità di sicurezza.

Consapevolezza delle vulnerabilità

Il tempo è davvero il fattore critico di successo che si affianca anche alla capacità delle organizzazioni, pubbliche e private, di avere piena ed assoluta consapevolezza che tenere esposto un sistema afflitto da vulnerabilità note o conoscibili è una colpevole assunzione di rischio, ancor più grave, quando non siano in atto misure “compensative” di sicurezza, che vanno dalla seria gestione degli accessi privilegiati alla segmentazione delle reti, all’esistenza di sistemi efficaci di monitoraggio.

Capacità di conoscere e rimediare alle vulnerabilità

In questo contesto, allora, appare fin troppo evidente quanto sia importante una reale capacità di conoscere le vulnerabilità e porvi rimedio nel più breve tempo possibile, quale elemento fondamentale di una seria strategia di gestione del rischio di sicurezza delle informazioni.

Limiti interni alle organizzazioni

Considerazione, questa, di assoluto buon senso, che incontra alcuni limiti interni alle organizzazioni, anche di tipo tecnico (si pensi all’ampio ricorso a software legacy, ossia sviluppato con caratteristiche proprietarie e non costantemente aggiornato, che mal tollera le innovazioni, spesso radicali, apportate dai sistemi operativi o da altre applicazioni collegate, o, assai peggio – come è purtroppo capitato di sentire con affermazioni disarmanti: “effettivamente questo software non è stato ideato guardando alla sicurezza”) ma anche legato al fatto che spesso i sistemi e i software appaiono come “black boxes”, oggetti misteriosi ed imperscrutabili, la cui stessa composizione sfugge all’utente finale che si aspetta, da un prodotto di mercato, non solo la capacità di funzionare secondo le promesse, ma anche l’assenza di vizi del bene, originari o sopravvenuti e comunque conoscibili con la dovuta diligenza professionale.

Il regolamento europeo sulla cyber resilienza

Di questo aspetto critico si è fatta interprete l’Unione Europea, con un recente Regolamento del Parlamento Europeo e del Consiglio n. 2024/2847 del 23 ottobre 2024, detto “Regolamento sulla cyber resilienza”[2] che, al di là dell’insopportabile neologismo usato dai traduttori dalla lingua inglese, merita un approfondimento di dettaglio, perché codifica uno specifico “statuto obbligatorio dei prodotti digitali sicuri”, riconoscendo per la prima volta una doverosità per le software houses di stabilire e mantenere un processo di sviluppo sicuro del software destinato all’immissione sul mercato, che non si limita alla imposizione dell’obbligo di sviluppare all’origine in modalità sicura il software, ma anche e soprattutto di impostare un processo di gestione delle vulnerabilità che i produttori di software sono tenuti a mettere in atto “… per garantire la cibersicurezza dei prodotti con elementi digitali durante il periodo in cui si prevede che i prodotti siano in uso e obblighi per gli operatori economici in relazione a tali processi”, ossia la sicurezza lungo l’intero ciclo di vita del software.

Obblighi dei fabbricanti

Nell’articolo 13, intitolato “obblighi dei fabbricanti” si trova una dettagliata illustrazione della posizione di garanzia che viene costruita in capo alle software houses e agli altri fabbricanti di prodotti digitali, che costituisce un elemento particolarmente forte che appare idoneo a demolire qualunque aspettativa di esenzione di responsabilità, da parte del produttore, non vincibile da clausole di stile che di frequente si trovano nei software del tipo “Il produttore non risponde di eventuali errori contenuti nel programma, pertanto è esclusiva responsabilità del Cliente verificare, secondo la dovuta diligenza professionale, l’esattezza dei dati e delle operazioni svolte dal programma, nonché la loro conformità alle normative vigenti… Il produttore non risponderà né per danni diretti, né per danni indiretti (quali perdita di produzione, perdita di dati e così via) comunque dal Cliente o da terzi subiti e derivanti dal funzionamento o dal non funzionamento, dall’uso o dal non uso del Software, in particolare, non assume responsabilità per danni di qualunque tipo derivanti da propria errata o incompleta conoscenza o interpretazione di leggi o per tardiva conoscenza delle medesime…”.

Clausole di esenzione di responsabilità

Clausole che, alla luce della sopravvenuta normativa, seppur applicabile dall’11 dicembre 2027, diverranno in manifesto contrasto alla legge e pertanto nulle (qualora non lo siano già oggi, quando mirino ad escludere il dolo e la colpa grave del produttore, la cui esenzione già oggi non è ammissibile a tenore del codice civile).

La divulgazione coordinata delle vulnerabilità

Salvo tornare in altro approfondimento su questo interessante quanto complesso regolamento, il legislatore europeo si intrattiene ripetutamente nel testo normativo sul delicato tema della “Divulgazione coordinata delle vulnerabilità”, ben consapevole che si tratta di un tema estremamente delicato, che presuppone anche una valutazione del rischio per apprezzare se la pubblicazione della vulnerabilità, quando non ancora nota e senza che sia identificabile un rimedio temporaneo o definitivo, possa costituire un rischio ancor maggiore della cautela nella divulgazione.

Il processo di valutazione della vulnerabilità

In altri termini, e assai apprezzabilmente, la scoperta di una vulnerabilità in un prodotto informatico non determina, di per sé, l’obbligo di pubblicazione, ma richiede un processo di valutazione della vulnerabilità stessa che, se da un lato attiva la necessità di un’azione correttiva, dall’altra innesca un processo nel quale entra in gioco un attore cruciale, il CSIRT nazionale, che assume su di sé, in relazione al livello e capacità di sfruttamento attivo della vulnerabilità, un ruolo di decisore nel processo di divulgazione della stessa.

Le linee guida ENISA

Questo concetto deriva dalla dottrina sviluppata nel tempo da ENISA, l’agenzia europea per la sicurezza delle informazioni, che ha sviluppato una serie di linee guida e migliori pratiche per la divulgazione coordinata delle vulnerabilità (CVD). Queste pratiche mirano a garantire che le vulnerabilità siano divulgate al pubblico solo dopo che i responsabili hanno avuto il tempo di sviluppare una soluzione, come una patch o una mitigazione.

Principi inclusi nel regolamento

In realtà, le proposte ENISA sono più ampie ma non tutte recepite nel provvedimento regolamentare. Sono stati inclusi i principi:

1. del Coinvolgimento dei CSIRTs: ENISA incoraggia i Computer Security Incident Response Teams (CSIRTs) a partecipare attivamente al processo di divulgazione delle vulnerabilità;

2. Registrazione delle vulnerabilità: ENISA mantiene un registro delle vulnerabilità per facilitare la divulgazione coordinata, sul modello delle CVE (Common Vulnerability Exposure) di derivazione statunitense.
3. Collaborazione tra stakeholder: ENISA promuove la collaborazione tra ricercatori di vulnerabilità, fornitori di tecnologia e proprietari di infrastrutture ICT.

Protezione legale per i ricercatori

Mentre per un altro elemento fondamentale, ossia la necessità di una protezione legale per i ricercatori, ve ne è traccia nel solo Considerando 75 dove si trova una raccomandazione agli Stati Membri “…incoraggiati ad adottare orientamenti per quanto riguarda la non perseguibilità dei ricercatori in materia di sicurezza delle informazioni e l’esenzione dalla responsabilità civile per le loro attività”.

La Direttiva NIS2

Ma il Regolamento 2024/2847 non è il solo testo a valenza normativa adottato sul tema dall’Unione Europea: infatti, se nel regolamento in questione l’attenzione è tutta dedicata ai produttori di beni e servizi ICT, la Direttiva NIS2, n. 2022/2555, recepita in Italia con il Decreto legislativo 138/2024 disciplina i ruoli e le responsabilità delle autorità pubbliche degli Stati membri, ed in particolare dei CSIRT, per il loro ruolo centrale nella gestione della divulgazione coordinata delle vulnerabilità con un modello strutturato, che si può riassumere nei seguenti punti:

• Identificazione e segnalazione: il processo inizia con l’identificazione e la segnalazione della vulnerabilità da parte dei ricercatori, anche in forma anonima e con forme di assistenza alle persone fisiche e giuridiche che segnalino vulnerabilità (anche per contrastare la possibile ritrosia dei produttori alla segnalazione, temendo potenziali effetti reputazionali).
• Valutazione dell’impatto: la vulnerabilità viene valutata per determinare il suo potenziale impatto;
• Sviluppo di soluzioni: i fornitori di tecnologia lavorano per sviluppare una soluzione, come una patch o una mitigazione;
• Divulgazione pubblica: una volta sviluppata una soluzione, la vulnerabilità viene divulgata al pubblico in modo coordinato, inclusa la negoziazione dei tempi di divulgazione e la gestione delle vulnerabilità che interessano più soggetti.

Il fondamento giuridico per la divulgazione coordinata

I Considerando 58, 60, 121 e gli articoli 7, 11, 12 della Direttiva forniscono un solido fondamento giuridico per la divulgazione coordinata delle vulnerabilità, enfatizzando l’importanza di un’azione concertata tra stakeholder per identificare, comunicare e mitigare le vulnerabilità in modo tempestivo e probabilmente questo articolato tra Regolamento Ciberresilienza (!) e Direttiva NIS2, quando sarà ben rodato e a regime, costituirà un serio strumento di gestione di un tassello rilevante della strategia preventiva, che si articola su doveri dei produttori e compiti (tutt’altro che semplici) dell’Autorità e dei CSIRT.

Un ulteriore aspetto positivo è il sistema di coordinamento e scambio informativo tra i CSIRT, al fine di agevolare la diffusione delle vulnerabilità, nell’ottica della cooperazione internazionale, altro pilastro della strategia europea di difesa cibernetica, declaratoria di piena e definitiva consapevolezza della globalità senza frontiere della minaccia cyber.

Intelligenza artificiale e vulnerabilità

E per l’intelligenza artificiale?

L’apparentemente inarrestabile diffusione di sistemi basati sull’intelligenza artificiale nelle sue diverse fenomenologie, spinge ad interrogarci, non solo sul significato di questo complesso e controverso argomento, ma anche sulle conseguenze di possibili ed anzi probabili vulnerabilità, con impatti potenzialmente devastanti sulla collettività.

Un significativo lavoro di ricerca è “Coordinated Flaw Disclosure for AI: Beyond Security Vulnerabilities“[3], scritto da Sven Cattell, Avijit Ghosh, Lucie-Aimée Kaffee e pubblicato su arXiv, della Cornell University.

L’articolo sottolinea che non esiste un metodo ben definito per segnalare e risolvere le criticità esistenti nei sistemi di intelligenza artificiale, a differenza di quanto avviene nella sicurezza del software.

Un framework di divulgazione coordinata dei difetti

Gli autori propongono quindi di creare un nuovo sistema chiamato “framework di divulgazione coordinata dei difetti” (CFD – Coordinated Flaws Disclosure) specifico per affrontare le sfide legate all’intelligenza artificiale e all’apprendimento automatico.

Questa proposta include idee innovative come modelli più dettagliati, possibilità di ampliare il campo d’azione, un gruppo indipendente di esperti per valutare i problemi e un processo automatizzato per verificarli.

Responsabilità nell’uso dell’intelligenza artificiale

L’obiettivo è garantire maggiore responsabilità nell’uso dell’intelligenza artificiale, tutelando al contempo gli interessi delle aziende e della comunità, nella piena consapevolezza che un uso sempre più diffuso di questi strumenti, che dovrebbero recare, come per i prodotti farmaceutici, un “bugiardino” comprensivo di effetti collaterali e rigorose avvertenze per un uso responsabile.

Efficacia della divulgazione coordinata

Diamo atto che l’Unione Europea ha compiuto uno sforzo significativo, nel quadro della strategia di rafforzamento della difesa del mondo digitale, per codificare il principio della divulgazione coordinata delle vulnerabilità, quale elemento fondamentale dell’efficacia dell’azione preventiva di difesa.

Questo strumento, tuttavia, sarà efficace soltanto quando i produttori di beni e servizi ICT saranno effettivamente ingaggiati e parteciperanno in modo convinto alla ricerca costante delle vulnerabilità e alla loro gestione, rendendo il mercato realmente capace di frapporre un concreto ostacolo all’azione ostile, rendendo robusti i sistemi sempre più pervasivi nella vita dei cittadini.

Coordinamento pubblico-privato e sfide future

Questi strumenti normativi rappresentano ulteriore espressione di quella spinta al coordinamento pubblico privato ed una spinta al dialogo leale, trasparente e collaborativo tra privati e autorità, che è la chiave di volta dell’efficacia del sistema.

Tuttavia, l’emergente campo dell’intelligenza artificiale richiede ulteriori sforzi per sviluppare un quadro di divulgazione coordinata dei difetti. Solo attraverso un impegno concertato e un’azione tempestiva si potrà garantire una sicurezza robusta e una gestione efficace delle vulnerabilità, proteggendo così gli interessi della società e delle imprese.

Note

[1] https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide/

[2] REGOLAMENTO (UE) 2024/2847 DEL PARLAMENTO EUROPEO E DEL CONSIGLIO del 23 ottobre 2024 relativo a requisiti orizzontali di cibersicurezza per i prodotti con elementi digitali e che modifica i regolamenti (UE) n. 168/2013 e (UE) 2019/1020 e la direttiva (UE) 2020/1828 (regolamento sulla ciberresilienza)

[3] https://arxiv.org/abs/2402.07039