È abbastanza evidente che l’utilizzo di strumenti di AI per la ricerca di vulnerabilità nel software, anche allo scopo di utilizzarle per attaccare sistemi e servizi, è ormai una realtà con la quale bisogna fare i conti.
In questi giorni vengono pubblicate un gran numero di vulnerabilità gravi anche di prodotti e componenti particolarmente critici, a opera soprattutto di Anthropic Mythos.
Il kernel Linux è particolarmente esposto, probabilmente anche perché essendo open source qualsiasi vulnerabilità diviene rapidamente di dominio pubblico, ma vulnerabilità gravi che vengono identificate anche in prodotti con una fama di “maggiore sicurezza”, e non solo in sistemi operativi, ma anche in altri componenti importanti dei sistemi informativi.
Altrettanto, o forse addirittura più grave, la possibilità di tradurre con poco sforzo queste vulnerabilità in codice che le sfrutti efficacemente e rapidamente per violare sistemi. Questo sviluppo è possibile in misura maggiore con i modelli di LLM più recenti, ma è possibile comunque anche con quelli meno recenti, realizzati dai diversi paesi che hanno in questo momento un ruolo dominante nel settore. A questo punto, è necessario chiedersi come affrontare il problema, in particolare in una prospettiva europea che, su questi temi, non può non essere diversa da quella statunitense, o cinese. Lo scenario internazionale, infatti, vede attualmente una maggiore aggressività, ancor più che dal punto di vista militare, dal punto di vista commerciale, contesto in cui l’Europa non può che avere una prospettiva autonoma.
Indice degli argomenti
Attacchi AI al software e nuova esposizione delle vulnerabilità
Un primo tema riguarda la disponibilità in modo diffuso di questi strumenti di analisi del codice. Se può avere senso limitarla in questa prima fase, in cui la quantità di vulnerabilità critiche che viene individuata è particolarmente elevata e le software house non sono attrezzate per gestirle, in una fase successiva probabilmente sarà necessario cambiare prospettiva: il numero di vulnerabilità individuate nel codice pregresso tenderà a ridursi nonostante l’evoluzione degli strumenti, e sarà molto più importante che queste analisi avvengano in modo diffuso e soprattutto sul nuovo codice in fase di sviluppo.
Nel complesso, una volta superato lo scoglio del pregresso, è ipotizzabile che questi strumenti possano diventare una fonte di riduzione dell’esposizione, e non di peggioramento. Purtroppo, c’è anche un rischio opposto: gli strumenti di sviluppo del codice supportati dall’AI sembrano per ora poter produrre con una certa facilità codice di bassa qualità e con vulnerabilità numerose. In una prospettiva statistica, c’è da dubitare, dove la qualità del codice peggiori, che l’utilizzo di strumenti di analisi per rilevare vulnerabilità possa compensare questo peggioramento. È importante quindi assicurare che per i componenti più critici dei sistemi informativi, l’evoluzione degli strumenti di sviluppo sia utilizzata per produrre codice di maggiore qualità, e non per produrre più codice più rapidamente ma con minore qualità.
Attacchi AI al software e qualità del codice critico
Se per i prodotti software in generale diventerà indispensabile, oltre ovviamente a progettare il software sicuro “by design”, utilizzare strumenti di analisi del codice, per quelli più critici sarà però probabilmente anche necessario intervenire sul processo di sviluppo. Su questo è utile richiamare come esempio un paragone storico, cioè quello fra Linux e OpenBSD, due diversi prodotti della famiglia dei sistemi operativi unix-like. OpenBSD è storicamente particolarmente attento alla sicurezza, con un processo di verifica del codice particolarmente attento, mentre Linux ha sempre dedicato una maggiore attenzione alle funzionalità evolute e sperimentali.
Dove si parli di componenti infrastrutturali critiche, e dove quindi tante funzionalità non sono di fatto necessarie, vale la pena di chiedersi se non sia opportuno prevedere un modello analogo a quello di OpenBSD, che rappresenta certamente una differenza più grande rispetto a quella che c’è fra “Stable” e “Unstable” che tipicamente si trova nelle distribuzioni Linux.
L’esempio di Linux è particolarmente rilevante non solo perché è al centro dell’attenzione in queste settimane per le vulnerabilità rilevate, ma anche perché l’open source dovrebbe e può giocare un ruolo rilevante nelle strategie di sovranità digitale europea. È importante però che l’Unione Europea possa assicurare che siano disponibili prodotti che soddisfano i requisiti, anche di sicurezza, dell’Unione, affrontando quindi l’open source non semplicemente come una semplice soluzione “free lunch”, ma come un contesto in cui finanziare in modo importante le iniziative più strategiche.
Cyber Resilience Act e attacchi AI al software
Al di là di questi componenti particolarmente critici, rimane comunque la necessità di un cambio di approccio generale allo sviluppo del software da parte di molte software house che, seppure comprensibilmente sotto una pressione commerciale spesso molto forte, seguono la strada di aggiungere continuamente funzionalità e lasciar fare il “beta test” ai clienti. Quanto questo approccio sarà sostenibile, lo deciderà in parte il mercato, ma in parte anche la normativa.
Su questo, vale la pena di ricordare a questo punto il ruolo critico che può giocare il Cyber Resilience Act. Questa norma, che dovrebbe essere applicabile nei suoi aspetti più critici da fine 2027, prevede non solo che i prodotti con componenti digitali connessi (quindi anche il software) siano immessi sul mercato senza vulnerabilità note sfruttabili, ma anche, e in questo contesto soprattutto, che i prodotti siano aggiornabili, e che gli aggiornamenti di sicurezza siano resi disponibili in generale separatamente da quelli funzionali, gratuitamente e tempestivamente. Questo requisito, che interesserà tutti i prodotti immessi sul mercato europeo, è un passo necessario per un’altra misura importante per gestire l’evoluzione della minaccia di strumenti che sfruttino rapidamente nuove vulnerabilità, e cioè il miglioramento dei processi di gestione degli aggiornamenti, il cosiddetto “patching”. Purtroppo, ci sono voci che il Cyber Resilience Act potrebbe essere posticipato nella sua piena applicabilità, principalmente per complessità legate ai processi di certificazione che prevede per i prodotti più critici. Sarebbe importante invece che, seppure dovesse essere rinviata la parte sulla certificazione, non lo fosse quella sul processo di gestione delle vulnerabilità.
Attacchi AI al software, zero day: cosa possono fare le aziende
E parlando di gestione delle vulnerabilità, è utile vedere a questo punto cosa possono fare le aziende. Naturalmente, ha senso parlare delle aziende che hanno già una gestione dignitosa della propria sicurezza: dove il problema siano ancora cose come la mancanza di backup immutabili, autenticazione multifattore o monitoraggio degli eventi, sicuramente sono questi i problemi da affrontare.
Ma anche dove la sicurezza sia ad un buon livello, uno 0-day rappresenta comunque una criticità. Le strategie fondamentali sono comunque sempre quella della difesa in profondità, nel tentativo di rendere meno raggiungibile la vulnerabilità, e quella della riduzione della superficie di attacco, per ridurre la possibilità che un componente vulnerabile si trovi nel sistema informativo aziendale. Questa riduzione della superficie di attacco parte dalla minimizzazione dei sistemi e servizi esposti, fino ad arrivare all’eliminazione dei componenti del sistema operativo o, nel caso di Linux, anche dei moduli all’interno del kernel. La vulnerabilità “Copy Fail” di Linux di aprile era ad esempio in uno specifico modulo non sempre utilizzato, e non averlo installato voleva dire non avere quella vulnerabilità.
Patching rapido e continuità operativa
Nonostante tutta la riduzione della superficie di attacco e la difesa in profondità possibile, uno 0-day ha la potenzialità di aggirare tutte queste protezioni ed arrivare in un istante al cuore di un sistema critico. Diventa quindi essenziale saper eliminare le vulnerabilità il più rapidamente possibile.
La possibilità di essere attaccati rimane infatti un tema probabilistico, e per quanto l’evoluzione in corso possa aumentare la probabilità, per molte aziende rimane comunque più critico il tempo fra quando l’aggiornamento è disponibile e quando i sistemi vengono effettivamente aggiornati. Essere capaci, su una rapida valutazione di rischio, di minimizzare questi tempi dove necessario diventa ancor più fondamentale, prevedendo comunque aggiornamenti automatici dove il rischio di un disservizio sia tollerabile, ma assicurando comunque che gli aggiornamenti manuali siano avviati rapidamente. Le modalità per velocizzare questa attività, compresa la ridondanza dei sistemi per poterli aggiornare senza interrompere il servizio e la capacità di effettuare un roll-back, sono cose note da tempo, si tratta di adottarle e testarle.
Ma alla fine, rimane comunque la possibilità di un attacco con successo. Questa possibilità, naturalmente, c’era già prima. È difficile dire, se i sistemi sono adeguatamente protetti, di quanto potrà aumentare questa probabilità. Finora non abbiamo avuto “ondate distruttive” di violazioni dei sistemi dovute alle vulnerabilità scoperte in questo periodo, neanche ad esempio con la vulnerabilità “Dirty Frag”, per la quale il codice in grado di sfruttarla è stato pubblicato prima che una patch fosse disponibile. Non è detto però che la situazione rimanga questa, anche gli attaccanti si abitueranno ad avere più facilmente 0-day da sfruttare rapidamente.
Gli ambienti più esposti agli attacchi AI al software
Qui si possono comunque evidenziare due punti importanti: il primo è che alcuni contesti sono particolarmente esposti: oltre ovviamente ai server pubblici, lo sono gli ambienti virtualizzati in cui possano essere eseguiti comandi arbitrari da utenti non privilegiati. La compromissione di queste utenze, o una loro azione direttamente malevola, possono portare alla compromissione dell’intero ambiente in modalità difficilmente rilevabili. Diventa quindi importante, per quanto ovviamente non risolutivo, il monitoraggio delle anomalie, come la nascita di processi che non rientrano nel funzionamento normale o abituale della piattaforma.
Purtroppo, gli strumenti di monitoraggio scontano in generale la necessità di un equilibrio fra capacità di rilevazione e impatto prestazionale. Nel momento in cui poi venga rilevato un attacco, si pone il tema dei tempi di risposta: tempi che devono essere sempre più rapidi, e che costringono ad una gestione sempre più automatizzata della difesa. La gestione manuale delle attività di rilevazione e contenimento è infatti sempre meno efficace, mentre la capacità di contenere un incidente è sempre più critica.
Attacchi AI al software e presenza nascosta nei sistemi
L’altro punto importante però è che in un contesto di maggiore aggressività a livello internazionale come quello attuale, non dobbiamo pensare solo al “ransomware” che crea un grande impatto immediato e si fa però rilevare. Tenendo conto del fatto che attori particolarmente pericolosi avranno comunque nel proprio arsenale degli 0-day da utilizzare con maggiore facilità, il rischio è che possano compromettere sistemi critici e mantenere una presenza nascosta per esfiltrare nel tempo le informazioni di valore, o per creare un punto di attacco immediato quando si voglia invece creare un disservizio in un momento di particolare impatto. Per questo rischio, è utile essere in grado di verificare regolarmente l’integrità dei propri sistemi, in modo da individuare eventuali modifiche.
Il costo reale degli attacchi AI al software
Purtroppo, tutte queste attività costituiscono non solo un maggior costo in termini di strumenti, ma soprattutto un maggior onere in termini di gestione e di complessità del sistema informativo. Il vero costo degli attacchi sta proprio nelle risorse e nei vincoli che derivano dalla necessità di limitarli e contenerli, molto più che l’eventuale riscatto e disservizio quando, nonostante tutto, abbiano successo.
