Per anni, nel campo della sicurezza aziendale si è partiti dal presupposto che un sistema di prevenzione ben consolidato potesse tenere testa alle minacce abbastanza a lungo da consentire ai difensori di reagire. L’IA di frontiera sta mettendo in discussione questa premessa, poiché i modelli più recenti riducono i tempi necessari per individuare e sfruttare le vulnerabilità da giorni o settimane a quasi tempo reale.
Lanciata per valutare i potenziali rischi per la sicurezza rappresentati dal proprio modello Mythos, l’iniziativa Project Glasswing di Anthropic ha già coinvolto quasi 200 aziende e ha portato alla luce circa 10.000 vulnerabilità critiche o di elevata gravità. Nel frattempo, il GPT-5.5 di OpenAI sta dimostrando capacità simili.
In un recente webinar, Pranay Ahlawat, Chief Technology and AI Officer di Commvault, e Vidya Shankaran, Field CTO, si sono uniti a me per approfondire i nuovi tempi nella gestione delle vulnerabilità, la crescente importanza della convalida di Recovery e il modo in cui i team dovrebbero concepire la resilienza oggi.
Registrati al webinar on-demand.
Punti di forza
- Man mano che le capacità all’avanguardia dell’IA raddoppiano a un ritmo sempre più accelerato, le funzionalità avanzate che contribuiscono a ridurre il tempo che intercorre tra l’individuazione di una vulnerabilità e il suo sfruttamento saranno a disposizione degli avversari entro sei-nove mesi.
- Il ripristino di un sistema di IA agentica richiede la sincronizzazione simultanea di fonti di dati, configurazioni degli agenti e identità non umane; il ripristino di un singolo elemento in modo isolato può creare lacune che emergono solo quando si verifica un guasto a valle.
- Backup and Recovery risolvono problemi diversi: il backup conferma che i dati esistono in un luogo sicuro, mentre Recovery conferma che un’organizzazione possa effettivamente tornare a uno stato pulito e funzionante.
- ResOps™ (operazioni di resilienza) inquadra Recovery come una disciplina interfunzionale. Riunisce i team di sicurezza, operazioni e tecnologia attorno a una definizione condivisa di cosa significhi effettivamente “pulito”.
- Un quadro di riferimento in quattro fasi – definizione di un’azienda minimamente funzionante, isolamento e test dei carichi di lavoro più preziosi, valutazione del rischio di Recovery ed esecuzione di esercitazioni complete di Recovery – offre alle organizzazioni un punto di partenza pratico.
L’IA all’avanguardia rivoluziona la gestione delle vulnerabilità
La potenza dell’IA all’avanguardia raddoppia ora all’incirca ogni quattro mesi, molto più rapidamente rispetto a pochi anni fa. Sebbene i modelli di tipo Mythos non siano ancora stati resi pubblici, gli avversari potrebbero presto ottenere accesso open-source a funzionalità simili a quelle di Mythos, tra cui:
- Una finestra di contesto praticamente illimitata.
- La capacità di costruire un framework di attacco tramite la decompilazione del codice e la creazione di container per individuare vettori di attacco.
- La concatenazione delle vulnerabilità, ovvero il collegamento di debolezze singolarmente minori in un exploit grave.
Ciò comporta gravi implicazioni. Attualmente, due organizzazioni su tre presentano oltre 100.000 vulnerabilità non risolte, con un tempo medio di risoluzione di circa 240 giorni. In passato, i team di sicurezza hanno sottovalutato molte vulnerabilità ritenendole troppo difficili da concatenare per un malintenzionato medio, ma l’automazione ha reso tale punto di vista quasi obsoleto.
Allo stesso tempo, l’uso dell’IA per la creazione di codice – circa il 41% del nuovo codice è ora generato dall’IA e GitHub ha registrato un aumento del 25% su base annua dei commit – sta ampliando la superficie di vulnerabilità più rapidamente di quanto la correzione riesca a affrontarla. La capacità di scoprire nuove vulnerabilità zero-day su larga scala aggrava il problema.
Quando il tempo che intercorre tra la scoperta e lo sfruttamento si avvicina allo zero, la finestra per un’azione difensiva si chiude di fatto.
Anteprima: il futuro in rapida evoluzione dell’IA
Questo video mette in luce una realtà fondamentale: le funzionalità avanzate dell’IA raramente rimangono esclusive a lungo. Man mano che le innovazioni all’avanguardia nel campo dell’IA si diffondono in ecosistemi più ampi, le organizzazioni devono prepararsi a un futuro in cui capacità offensive sempre più sofisticate diventeranno più ampiamente disponibili.
Il nuovo indicatore di resilienza: il tempo medio per la Recovery completa
Backup and Recovery risolvono problemi fondamentalmente diversi. Il backup conferma solo che i dati sono stati copiati in un luogo sicuro, ma non dice nulla sulla capacità dell’organizzazione di tornare effettivamente a uno stato operativo. Ed è qui che le cose possono complicarsi.
Due sfide spesso si frappongono tra un backup riuscito e un ripristino riuscito.
- Il ripristino di un ambiente complesso implica il recupero dell’applicazione, delle macchine virtuali, della configurazione di rete, di Active Directory e dei database transazionali che lo supportano, il tutto nella sequenza corretta.
- È necessario assicurarsi che i dati che si stanno ripristinando siano privi di malware o backdoor – un aspetto che sette organizzazioni su dieci, impegnate nel recupero a seguito di un incidente informatico, non sono attualmente in grado di verificare.
Una Recovery che rispetta i tempi previsti ma reintroduce una minaccia attiva può essere peggiore di un mancato ripristino.
Per ottenere una visione più chiara della propria resilienza, le organizzazioni hanno iniziato a utilizzare la metrica MTCR (Mean Time to Clean Recovery), che combina l’obiettivo di tempo di ripristino (RTO), il tempo necessario per verificare che i dati ripristinati siano effettivamente puliti e una fase finale di verifica manuale prima che i sistemi tornino in produzione. L’obiettivo di Recovery per l’MTCR è la “minimum viable company”: circa il 30% di un ambiente, ordinato in base alle dipendenze, che deve tornare online affinché l’organizzazione continui a funzionare.
La “cleanroom” come strumento di test
I test di Recovery, ovvero la fase finale di verifica manuale nell’ambito dell’MTCR, comportano in genere la creazione di un ambiente separato dai sistemi di produzione attivi – un’operazione che richiede tempo quando ogni minuto è prezioso. Sebbene le “cleanroom” siano talvolta considerate un elemento del backup, una “cleanroom” basata sul cloud può anche svolgere un ruolo proattivo nel ripristino, fornendo un ambiente isolato per orchestrare e testare ripristini complessi prima che questi vengano riportati in produzione.
Lo stesso ambiente isolato può anche fungere da strumento forense, consentendo ai team di confrontare due versioni di un backup per comprendere meglio cosa sia cambiato durante un incidente. E poiché è nativo del cloud e basato sul consumo, le organizzazioni possono evitare di implementare un’infrastruttura dedicata solo per testare il Recovery.
Quattro passaggi verso la resilienza operativa
Il modello in quattro fasi di Commvault per la creazione di una resilienza operativa misurabile si basa su queste idee.
- Fase 1: Definire la “minimum viable company”: una visione orientata al business di ciò che deve essere ripristinato, in quale sequenza e con quali dipendenze, affinché l’organizzazione torni a funzionare, piuttosto che un semplice inventario di database e macchine virtuali.
- Fase 2: assicurarsi che i sistemi a supporto di tale “azienda minima funzionante” risiedano in un ambiente isolato (air-gapped), immutabile e segmentato in rete, in grado di essere avviato e disattivato rapidamente. Per i carichi di lavoro più critici, ciò dovrebbe essere testato ogni 45 giorni.
- Fase 3: Valutare il rischio associato alla Recovery prima di dichiararla completata, poiché reintrodurre una backdoor o un malware durante la Recovery vanifica lo scopo dell’esercizio e lascia poco tempo per un secondo tentativo.
- Fase 4: Considerare la Recovery come qualcosa di più di una semplice esercitazione teorica. Eseguire le Recovery con le stesse persone e gli stessi processi che sarebbero coinvolti in un incidente reale, insieme all’automazione che li supporta.
Quando l’IA diventa il problema della Recovery
Una quota consistente di aziende sta già utilizzando sistemi di IA in produzione, ma solo circa il 20% di esse ne ha effettivamente testato la recuperabilità, rendendole vulnerabili in caso di incidente. Ciò è particolarmente significativo alla luce dei tre modi in cui l’IA modifica l’architettura di resilienza.
In primo luogo, l’IA amplia l’area che necessita di protezione, dai database vettoriali e dai pesi dei modelli alle configurazioni degli agenti e agli endpoint, come Claude Cowork o Google Antigravity, dove i dipendenti interagiscono effettivamente con gli agenti.
Inoltre, introduce un problema di “fan-out”, in cui un singolo aggiornamento da parte di un agente può propagarsi a cascata attraverso una rete di sistemi connessi in modi molto meno prevedibili rispetto a un’applicazione tradizionale a tre livelli.
Infine, l’IA rende più complesso lo stesso processo di Recovery, poiché ripristinare un sistema agente significa sincronizzare contemporaneamente memoria, stato, dati transazionali e identità non umane (NHI) – ovvero le credenziali e le autorizzazioni assegnate agli agenti di IA anziché alle persone.
I clienti più avanzati nelle implementazioni basate su agenti hanno già integrato questi sistemi nel loro modello aziendale minimo funzionante (MVP). In ogni fase di maturità, l’enfasi è posta sul ripristino congiunto di fonti di dati, configurazioni degli agenti ed elementi di supporto come pesi e bias, piuttosto che su interventi separati, poiché un disallineamento tra uno qualsiasi di questi elementi può introdurre un rischio che un singolo punto di Recovery non riuscirebbe a individuare.
Agire sulla resilienza post-Mythos
Come punto di partenza per ridurre i rischi derivanti dall’IA all’avanguardia, individuate i sistemi più preziosi della vostra organizzazione e verificate che si trovino in un ambiente isolato (air-gapped). Una volta definito il vostro modello aziendale minimo funzionante (MVC), eseguite esercitazioni in ambiente controllato (cleanroom) per stabilire una linea di base di recuperabilità e MTCR per i carichi di lavoro di primo livello. Questo dovrebbe costituire il vostro punto di riferimento, la metrica a livello di consiglio di amministrazione per la resilienza, che mostri chiaramente la rapidità con cui la vostra azienda è in grado di riprendere le operazioni essenziali a seguito di un incidente.
I test sono fondamentali per individuare le lacune nella comprensione del business, della tecnologia e dei processi. Spesso, alcuni dei problemi più gravi sono di natura organizzativa. ResOps™ (operazioni di resilienza) può affrontarli.
Più che un prodotto, ResOps è un framework che riunisce i team di sicurezza, operazioni e tecnologia attorno a una visione condivisa di come dovrebbero essere progettati la resilienza e la convalida del Recovery. ResOps formalizza il crescente riconoscimento del settore secondo cui il Recovery informatico è una questione interfunzionale che richiede il coinvolgimento di tutte le parti interessate dell’azienda, ciascuna delle quali ha un interesse nel risultato.
Nell’era post-Mythos, tale coordinamento è fondamentale sia per sostenere la Readiness operativa continua sia per consentire una risposta rapida ed efficace a un incidente. Frontier AI rende un processo di Recovery collaudato, ben definito e pulito un requisito fondamentale.
Guarda il webinar completo
Guarda la sessione completa «Resilience Over Panic» on demand per esplorare in modo più dettagliato il nostro quadro di riferimento in quattro fasi, compresi i requisiti per il Recovery basato sull’IA agentica. Iscriviti qui al webinar.
Domande frequenti
D: Che cos’è il «mean time to clean Recovery» (MTCR)?
R: Il tempo medio di ripristino pulito (MTCR) misura il tempo necessario a un’organizzazione per tornare a uno stato operativo verificato e pulito dopo un incidente. Si tratta di una misura più ampia rispetto al semplice tempo necessario per ripristinare i dati. Combina il tradizionale obiettivo di tempo di ripristino (RTO) con il tempo aggiuntivo necessario per confermare che i dati ripristinati siano privi di malware o backdoor, oltre a una fase finale di convalida umana prima che i sistemi tornino in produzione.
Le organizzazioni considerano sempre più spesso l’MTCR, piuttosto che la sola velocità di Recovery, come la metrica di resilienza a livello dirigenziale, poiché un Recovery rapido che reintroduca una minaccia attiva può causare danni maggiori rispetto a uno più lento, ma verificato.
D: In che modo l’MTCR differisce dall’RTO?
R: L’RTO misura la rapidità con cui i sistemi e i dati possono essere ripristinati dopo un’interruzione. L’MTCR include l’RTO come una delle sue componenti, ma aggiunge il tempo necessario per confermare che i dati ripristinati siano integri e il tempo dedicato alla verifica manuale prima che i sistemi tornino in produzione. In particolare, nel caso di un incidente informatico, un sistema può rispettare il proprio RTO e tuttavia non raggiungere la vera resilienza se l’ambiente ripristinato viene reinfezionato poco dopo.
D: Che cos’è una «minimum viable company» e in cosa si differenzia da un piano completo di Disaster Recovery?
R: Una “minimum viable company”, talvolta denominata “minimum viable business”, è il sottoinsieme più ristretto e orientato alle priorità aziendali di sistemi, dati e dipendenze che un’organizzazione deve riportare online per continuare a funzionare dopo un incidente, anziché l’intero patrimonio IT.
Un piano completo di disaster recovery mira in genere a ripristinare tutto, col tempo; la definizione di “minimum viable company” costringe un’organizzazione a decidere in anticipo cosa deve davvero tornare in funzione per primo, e in quale sequenza, per evitare un arresto operativo.
D: Qual è la differenza tra un’esercitazione teorica e un’esercitazione di Recovery dal vivo?
R: Un’esercitazione teorica è una simulazione su carta di un piano di risposta agli incidenti, tipicamente utilizzata per testare il processo decisionale e la comunicazione tra le parti interessate senza eseguire effettivamente alcuna procedura tecnica di Recovery.
Un’esercitazione di Recovery dal vivo va oltre, eseguendo effettivamente un Recovery, utilizzando gli strumenti reali, l’automazione e le persone coinvolte, per confermare che il processo funzioni nella pratica, al di là di ciò che un’esercitazione teorica può mostrare. Le organizzazioni che si affidano esclusivamente alle esercitazioni teoriche potrebbero disporre di un piano di resilienza che a prima vista sembra solido, ma che non è stato testato rispetto ai dettagli operativi che spesso fanno sì che gli incidenti reali richiedano più tempo del previsto.
D: Cosa sono le identità non umane (NHI) e perché complicano la Recovery dell’IA?
R: Le NHI sono le credenziali, le autorizzazioni e i diritti di accesso assegnati a componenti software, come gli agenti di IA, piuttosto che a singole persone. Man mano che le organizzazioni implementano un’IA sempre più incentrata sugli agenti, il numero di NHI in un ambiente cresce, e ciascuna di esse deve essere presa in considerazione durante la Recovery insieme a elementi più familiari come database e sistemi transazionali.
Il ripristino di un sistema di IA basato su agenti richiede in genere la sincronizzazione delle NHI con il resto dello stack di IA, poiché il ripristino di dati o configurazioni senza ripristinare le autorizzazioni corrette degli agenti può lasciare lacune difficili da individuare fino a quando non si verifica un malfunzionamento a valle.
D: In che modo un’organizzazione dovrebbe avviare ResOps™ (operazioni di resilienza)?
R: ResOps è un framework interfunzionale che riunisce i team di sicurezza, operazioni e tecnologia attorno a una definizione condivisa di progettazione resiliente, distinta da qualsiasi singolo prodotto.
Le organizzazioni possono iniziare identificando un numero limitato di applicazioni fondamentali ed eseguendo un test di Recovery iniziale per stabilire un MTCR di riferimento, anziché cercare di formalizzare l’intera disciplina in un’unica volta. Tale punto di riferimento iniziale fornisce ai team di sicurezza, operazioni e governance un punto di riferimento concreto per monitorare i miglioramenti. Contribuisce inoltre a sviluppare nel tempo le abitudini trasversali ai team su cui si basa ResOps.
Michael Thelander è direttore senior del marketing di prodotto presso Commvault.
