La sicurezza informatica non si certifica

C'è un equivoco di fondo nel modo in cui continuiamo a parlare di sicurezza informatica: l'idea che la sicurezza possa essere certificata come si certifica un oggetto industriale.

Una vite può essere certificata. Posso stabilire con quale materiale debba essere costruita, quali tolleranze debba rispettare, quanta forza debba sopportare, in quali condizioni debba lavorare. Posso sottoporla a prove ripetibili, confrontare il risultato con uno standard e dire che quella vite, entro certe condizioni, risponde a determinati requisiti.

Con un'analisi di sicurezza informatica questo schema semplicemente non regge.

Immaginiamo un lavoro serio, durato tre o quattro mesi. Si studia l'architettura, si analizzano configurazioni e codice, si fanno test, si ricostruiscono relazioni tra sistemi, si osservano permessi, integrazioni, API, comportamenti applicativi. Si procede per ipotesi, si cambia direzione, si approfondisce ciò che appare anomalo. Alla fine arriva il report, qualcuno lo firma e magari quel documento entra in un processo di certificazione.

Ma che cosa è stato davvero certificato?

Non l'impenetrabilità del sistema, perché nessun professionista serio potrebbe sostenerla. Non l'assenza di vulnerabilità, perché una vulnerabilità può semplicemente non essere stata trovata. Non l'esistenza di un metodo universalmente valido, perché le analisi di sicurezza reali non sono una ricetta industriale ripetibile allo stesso modo in ogni ambiente. Ci sono framework, procedure e buone pratiche, naturalmente, ma il valore di un'analisi nasce proprio dalla capacità di adattarsi al contesto.

Un ambiente complesso non si lascia analizzare seguendo soltanto una checklist. A un certo punto bisogna capire dove guardare, quali relazioni approfondire, quali ipotesi mettere in discussione. Due infrastrutture formalmente simili possono richiedere approcci completamente diversi. Una vulnerabilità può emergere non da un errore evidente, ma dall'interazione tra elementi che, presi singolarmente, sembrano corretti.

Per questo l'idea di certificare "il metodo" rischia spesso di diventare una finzione burocratica. Si può certificare che un processo sia stato seguito. Si può certificare che siano stati effettuati determinati controlli. Ma da qui a dire che si sia certificata la sicurezza c'è un salto enorme.

La differenza diventa evidente con un esempio molto semplice.

Io e il mio team lavoriamo quattro mesi su un sistema. Facciamo un buon lavoro, siamo competenti, troviamo diversi problemi, produciamo un report dettagliato e alla fine lo firmiamo. Il giorno successivo arriva un nuovo modello di intelligenza artificiale molto più potente. Gli diamo accesso allo stesso codice, alla stessa documentazione, alle stesse configurazioni e quello, in un decimo del tempo, trova una vulnerabilità critica che noi non avevamo visto.

Quella vulnerabilità non è nata il giorno dopo.

Era già lì mentre firmavamo.

A quel punto la domanda non è se il modello abbia invalidato la nostra certificazione. La questione è più scomoda: quella certificazione non aveva mai certificato la sicurezza del sistema. Aveva certificato, al massimo, il limite della nostra capacità di analizzarlo in quel momento.

Ed è qui che il discorso sulla certificazione si lega inevitabilmente a quello della responsabilità.

La firma non serve soltanto a dichiarare che un lavoro è stato svolto bene. Serve anche a costruire un soggetto responsabile. Se qualcosa va storto, c'è qualcuno che ha firmato, qualcuno che può essere chiamato a rispondere.

Questa impostazione ha funzionato per molto tempo perché qualità tecnica e responsabilità personale erano spesso sovrapposte. Il professionista eseguiva il lavoro, lo controllava e se ne assumeva la responsabilità. Con l'intelligenza artificiale questa sovrapposizione inizia a rompersi.

Se un sistema automatico diventa più bravo di me nell'analisi di sicurezza, che senso ha che sia io a certificarne il lavoro?

Posso leggerne il report, posso controllare alcuni passaggi, posso verificare che le conclusioni siano coerenti. Ma se la macchina è realmente migliore di me nel trovare vulnerabilità, io non posso garantire che non abbia sbagliato senza rifare integralmente il lavoro. E se potessi rifarlo con la stessa efficacia, allora non sarebbe vero che la macchina è migliore di me.

La firma, a quel punto, rischia di diventare una pura costruzione amministrativa. Non serve più a garantire il valore tecnico del risultato. Serve a mantenere qualcuno dentro il processo perché il sistema giuridico e organizzativo vuole un nome in fondo alla pagina.

L'esempio medico rende ancora più chiaro il problema.

Un medico può essere eccellente, ma rimane un essere umano. La sua prestazione non è perfettamente costante. Può essere più stanco, più lucido, più concentrato, può avere alle spalle un turno particolarmente pesante. La qualità della sua decisione può variare.

Un modello che analizza una radiografia, una TAC o un referto può certamente sbagliare, ma non è soggetto agli stessi fattori. La sua capacità computazionale non cambia perché sono le tre del mattino. Non arriva alla cinquantesima analisi della giornata con meno attenzione della prima. Se è stato costruito bene, la sua prestazione tende a essere molto più stabile.

Questo non significa che sia infallibile.

Significa che il problema cambia natura.

Se un sistema automatico diventa statisticamente più affidabile di un essere umano, continuerà comunque a commettere una certa percentuale di errori. L'errore non scompare. Diventa però un rischio misurabile, un errore statistico residuo.

Ed è qui che la nostra ossessione per la responsabilità personale comincia a mostrare i suoi limiti.

Se una macchina, mediamente, sbaglia meno di un medico, avrebbe poco senso mantenere il medico nel processo soltanto perché, quando qualcosa va storto, vogliamo avere una persona da indicare come responsabile. Sarebbe ancora più assurdo se la sua presenza non migliorasse il risultato, ma servisse soltanto a mettere una firma.

A quel punto bisogna accettare una cosa molto semplice: non tutta la responsabilità può essere pensata come ricerca di una colpa individuale. Alcuni sistemi funzionano su base probabilistica. Possono essere migliori di qualunque alternativa disponibile e continuare comunque a sbagliare.

La questione diventa allora come gestire quell'errore, come misurarlo, come ridurlo e come compensare chi ne subisce le conseguenze. Ma questa è una questione di gestione del rischio, non di certificazione della qualità.

Ed è esattamente ciò che accade nella sicurezza informatica.

Nessuna firma trasforma un'analisi in una verità. Nessun certificato elimina il fatto che il sistema possa contenere qualcosa che nessuno ha ancora trovato. Nessuna procedura, per quanto seria, cambia la natura del problema.

La sicurezza è una condizione continuamente negoziata tra ciò che sappiamo oggi e ciò che scopriremo domani.

Per questo il vero valore non sta nel produrre un documento che chiuda il problema, ma nel costruire un processo che rimanga aperto. Revisione continua dei progetti, analisi durante le implementazioni, verifica delle modifiche, osservazione dell'ambiente, audit ripetuti, capacità di tornare su decisioni considerate corrette mesi prima.

Questo tipo di sicurezza è più scomodo, perché non produce il momento rassicurante del "siamo certificati".

Non finisce.

Non permette al management di mettere una spunta verde e considerare il problema risolto.

E forse proprio per questo il mercato preferisce spesso venderci l'idea opposta.

Un'azienda chiama una società di consulenza e invece di ricevere qualcuno che entri davvero nei processi, che studi come vengono prese le decisioni architetturali e che accompagni l'evoluzione dei sistemi, si ritrova davanti un catalogo di prodotti.

Prodotti certificati.

Soluzioni certificate.

Metodologie certificate.

Come se la somma di oggetti certificati producesse automaticamente un ambiente sicuro.

È un modo estremamente comodo di trasformare un problema tecnico complesso in una pratica amministrativa.

Si compra il prodotto, si compila la documentazione, si supera l'audit, si ottiene il certificato.

Il problema è che un attaccante non attacca il certificato.

Attacca il sistema.

E al sistema non interessa se qualcuno ha firmato un documento sei mesi prima.

Questo è il punto sul quale dovremmo essere molto più radicali.

Certificare la conformità a uno standard può avere senso. Certificare che un'organizzazione abbia implementato determinate procedure può avere senso. Certificare che un certo controllo sia stato eseguito può avere senso.

Ma chiamare tutto questo "certificazione della sicurezza" produce un'illusione.

La sicurezza non è un attributo assoluto che viene assegnato a un sistema dopo un audit. È una misura sempre provvisoria della nostra capacità di trovare problemi prima che li trovi qualcun altro.

Più avanzano gli strumenti di intelligenza artificiale, più questa realtà diventerà evidente.

Se domani un modello riesce a fare in poche ore ciò che oggi richiede mesi di lavoro umano, la quantità di tempo spesa nell'analisi non sarà più un buon indicatore del suo valore. Se quel modello trova vulnerabilità che un team certificato non ha trovato, la firma del team non diventa improvvisamente inutile: semplicemente diventa evidente che non era mai stata una garanzia tecnica.

Era una fotografia.

Parziale.

Temporanea.

Legata alle capacità di chi osservava.

E a quel punto forse dovremo smettere di usare la certificazione come una forma di rassicurazione collettiva e cominciare a descrivere la sicurezza per quello che realmente è: un problema di probabilità, capacità di analisi, velocità di reazione e gestione continua del rischio.

Una vite può essere certificata per resistere a una certa forza.

Un'infrastruttura informatica non può essere certificata per resistere a ciò che ancora non sappiamo vedere.

E se il giorno dopo una macchina trova in dieci minuti ciò che quattro mesi di analisi non avevano trovato, non ha reso inutile la sicurezza.

Ha soltanto strappato il timbro dal foglio e ci ha ricordato che quel timbro non era mai stato la sicurezza.