Punti di forza
- Frontier AI sta riducendo i tempi a disposizione per la correzione delle vulnerabilità; la prevenzione da sola non è più sufficiente a garantire la sicurezza.
- La domanda che i consigli di amministrazione, le autorità di regolamentazione e le compagnie assicurative si stanno ponendo ora non è «Abbiamo dei sistemi di backup?», ma «Siamo in grado di dimostrare di poter ripristinare i dati senza problemi?».
- I backup non equivalgono al ripristino: una copia ti dice che i dati esistono, ma non se sono integri o ripristinabili.
- Il tempo medio di ripristino della pulizia (MTCR) deve diventare un indicatore misurato costantemente a livello di consiglio di amministrazione, non una stima teorica.
- Un ambiente di ripristino isolato – separato fisicamente dalla rete, immutabile, rinforzato e con identità isolate – rappresenta lo standard di base, non una funzionalità avanzata.
- Il concetto di “pulito” continuerà a evolversi man mano che i modelli di intelligenza artificiale diventeranno sempre più capaci di individuare compromessi che gli esseri umani non sono in grado di prevedere.
Ho trascorso gran parte della mia carriera gestendo sistemi di produzione. Conosco dall’interno gli ambienti di backup, quelli di cui i clienti si fidano davvero. So che i piani di Recovery sono quegli elementi che rivelano le loro debolezze solo quando qualcosa è già andato storto. Quell’esperienza cambia il modo in cui si concepisce la resilienza informatica.
A prima vista, il Backup and Recovery sembrano gestibili. Proteggere i dati, archiviare copie, documentare la procedura operativa, testare quando possibile, ripristinare quando necessario. Ma il margine di tempo su cui si basa sta crollando.
L’intelligenza artificiale di frontiera ha rivoluzionato la velocità con cui vengono individuate le vulnerabilità, concatenati i percorsi di attacco e generati gli exploit. Modelli come Claude Mythos e GPT-5.5-Cyber hanno già dimostrato come ciò avvenga, sebbene finora in test controllati in fase di accesso anticipato che si basavano ancora sulla competenza umana e presentavano tassi significativi di falsi positivi; tuttavia, la traiettoria è inequivocabile. Man mano che l’accesso si amplia, la stessa capacità passa nelle mani degli aggressori.
In un solo mese, Palo Alto Networks ha segnalato 26 CVE, corrispondenti a 75 vulnerabilità sottostanti, dopo aver adottato modelli di intelligenza artificiale all’avanguardia per l’analisi del codice, rispetto al suo volume abituale di meno di cinque CVE al mese. I ricercatori avvertono inoltre che l’individuazione assistita dall’IA sta riducendo drasticamente i tempi a disposizione per la correzione, con alcuni exploit che ora emergono entro pochi minuti dalla divulgazione. Quando il tempo a disposizione per applicare le patch scompare, la logica della correzione smette di funzionare. La prevenzione non può sostenere da sola tutto il peso della Readiness.
La prevenzione conta ancora, ma non definisce più la Readiness. I clienti con cui parlo non chiedono se hanno bisogno di più controlli. Sanno già di averne bisogno. Chiedono se la loro azienda sia in grado di riprendersi completamente quando quei controlli falliscono, quando gli aggressori agiscono più velocemente dei cicli di correzione o quando la compromissione è presente da più tempo di quanto chiunque potesse immaginare.
Questa è ora la domanda che i consigli di amministrazione, le autorità di regolamentazione e le compagnie assicurative stanno ponendo. Sono passati dalla domanda “Abbiamo dei sistemi di backup?” a una più rilevante: “Siamo in grado di dimostrare di poter ripristinare il sistema senza problemi?” Questa dimostrazione parte da una distinzione che la maggior parte delle organizzazioni continua a fraintendere: i backup non equivalgono al ripristino.
Un backup indica che esiste una copia. Non garantisce però che i dati siano integri, che le dipendenze delle applicazioni siano intatte, che i servizi di identità possano essere ripristinati in modo sicuro, né che la sequenza di ripristino rifletta ancora l’ambiente attuale. Ho esaminato piani che sembravano completi finché qualcuno non ha provato a metterli in pratica. Il runbook c’era, ma era obsoleto. Il ripristino ha funzionato, ma ha richiesto tre volte più tempo del previsto. Il sistema è tornato operativo, ma le applicazioni a valle non riuscivano a connettersi. Nulla di tutto ciò è insolito. È esattamente ciò che i test reali dovrebbero far emergere. Il problema è che la maggior parte delle organizzazioni scopre queste lacune durante un incidente vero e proprio. L’indicatore più importante quando si verifica un problema è la rapidità con cui si riesce a tornare a uno stato di funzionamento corretto. Ecco perché il Mean Time to Clean Recovery (MTCR) deve diventare un dato di riferimento a livello di consiglio di amministrazione, non una stima teorica contenuta in un piano, ma un tempo misurato e convalidato.
L’obiettivo in continua evoluzione: ciò che oggi è considerato pulito potrebbe non esserlo domani
Per quanto riguarda i modelli di Frontier AI, la risposta sincera è questa: non è possibile garantire che ogni vulnerabilità venga individuata e risolta in tempo. Gli autori degli attacchi che sfruttano gli stessi modelli stanno scoprendo e concatenando gli exploit a un ritmo tale che nessun programma di correzione può realisticamente tenere il passo. Questo non è un fallimento del vostro team di sicurezza. È la nuova realtà del panorama delle minacce.
Ciò che potete controllare è la vostra capacità di Recovery. Ciò significa un ambiente di Recovery isolato: backup isolati fisicamente da Internet, irraggiungibili dalla rete di produzione e protetti dal movimento laterale che caratterizza una violazione sofisticata. Significa immutabilità e blocco della conformità, in modo che nessuna credenziale, per quanto privilegiata, possa abbreviare il periodo di conservazione o cancellare dati al di fuori di un processo autorizzato. E significa mettere in pratica il ResOps: non solo eseguire il backup dei dati, ma testare continuamente Recovery, automatizzare la verifica dell’integrità e misurare il proprio MTCR – il tempo convalidato necessario per tornare a uno stato noto come corretto.
Ma ecco l’aspetto di cui la maggior parte delle organizzazioni non tiene ancora conto: ciò che conta come “pulito” non è una linea fissa. Man mano che i modelli di IA diventano più capaci, individueranno sempre più vulnerabilità che la mente umana semplicemente non può anticipare, percorsi di attacco inediti, implant dormienti, corruzioni sottili incorporate molto prima del rilevamento. Un punto di ripristino che è pulito secondo gli standard odierni potrebbe nascondere compromissioni che l’analisi forense assistita dall’IA di domani porterà alla luce. Ciò significa che la vostra definizione di “pulito” deve evolversi continuamente. L’MTCR non è un numero che si imposta una volta per tutte. È una disciplina da mantenere, che implica riesaminare il significato di “pulito”, aggiornare i criteri di convalida e considerare la resilienza come uno standard dinamico piuttosto che una certificazione da superare una volta sola.
Qual è quindi un buon MTCR? Sulla base di ciò che ho visto funzionare nella pratica, l’obiettivo per l’intera “minimum viable company” – l’insieme minimo di sistemi che consente di continuare a operare, che definisco con precisione di seguito – dovrebbe essere inferiore a sei ore. Sei ore sono un obiettivo raggiungibile con la giusta architettura: un IRE pronto all’uso, una sequenza di Recovery pre-convalidata e runbook che siano eseguibili piuttosto che solo leggibili. Se il vostro attuale MTCR si misura in giorni, il divario è quasi sempre da ricercarsi in uno di questi tre elementi.
Quattro passi per mantenere la resilienza nell’era dell’intelligenza artificiale di frontiera
Accettare che la prevenzione da sola non sia sufficiente è il punto di partenza. Da lì, il lavoro diventa specifico. Ecco su cosa consiglio alle organizzazioni di concentrarsi.
1. Valuta i tuoi rischi effettivi in materia di recupero.
La maggior parte delle valutazioni dei rischi di Recovery pone le domande sbagliate. “Esistono i backup?” non è la stessa cosa di “Riusciamo a ripristinare senza problemi?”. Le domande più difficili sono: è possibile ripristinare i sistemi critici senza reintrodurre la minaccia? Gli ambienti di Recovery sono isolati dai sistemi di produzione compromessi? I piani di Recovery sono allineati alle dipendenze attuali – e non all’architettura di due anni fa?
In un contesto di vulnerabilità in rapida evoluzione, il divario tra «abbiamo dei backup» e «possiamo ripristinare» è proprio il punto in cui le organizzazioni subiscono danni. Valutare onestamente quel divario, prima che un incidente imponga la questione, è il punto di partenza della pianificazione della resilienza. Tale valutazione deve includere un’analisi dell’impatto sul business: quali sistemi hanno una finestra di ripristino misurabile in minuti, quali in ore e quali possono attendere un giorno. Senza tale classificazione, ogni sistema appare ugualmente urgente durante un incidente e nulla viene ripristinato abbastanza rapidamente.
2. Fare in modo che il ripristino isolato e l’air gap diventino la norma, non l’eccezione.
Se considerate ancora le copie immutabili e isolate fisicamente come una funzionalità avanzata anziché come un requisito standard, tale presupposto non è più valido. Quando i tempi di sfruttamento si riducono a pochi minuti, occorrono soluzioni alternative che siano strutturalmente separate dai piani di identità, rete e gestione dell’ambiente di produzione – isolate logicamente o fisicamente, immutabili e prive di percorsi attivi verso l’ambiente di produzione che un aggressore possa seguire.
L’obiettivo non è solo proteggersi dalla minaccia attuale, ma anche garantire opzioni di ripristino efficaci nel caso in cui venga sfruttata una vulnerabilità a cui non avete ancora applicato una patch. È una situazione che si verifica già oggi. Preparatevi ad affrontarla. L’isolamento è efficace solo se l’infrastruttura circostante è rinforzata. Ciò significa un’infrastruttura di backup su sistemi operativi rinforzati, non su immagini generiche, e idealmente su server fisici in grado di resistere a un attacco a livello di hypervisor. Significa che le chiavi di crittografia devono essere archiviate al di fuori della piattaforma di backup, in un deposito esterno con accesso just-in-time e senza dipendenza dall’Active Directory di produzione. E significa trattare il dominio di backup come un confine di identità separato: nessuna relazione di fiducia con l’Active Directory di produzione, autenticazione a più fattori (MFA) obbligatoria e autorizzazione da parte di più persone per le operazioni distruttive. Nulla di tutto ciò è insolito: è la base di riferimento affinché il vostro ambiente possa ripristinarsi in uno spazio non compromesso.
Altrettanto importante è la questione di cosa si sta ripristinando. I dati del settore relativi alla risposta agli incidenti indicano costantemente che il tempo mediano di permanenza di una violazione è dell’ordine delle settimane, non dei giorni. Ciò significa che le copie di ripristino devono risalire abbastanza indietro nel tempo per trovare un punto realmente pulito, non solo il backup di ieri. I sistemi critici richiedono più copie separate geograficamente, inclusa almeno una copia immutabile e una completamente offline. La politica di conservazione non è una decisione legata ai costi di archiviazione. È una decisione di sicurezza.
3. Individuare i sistemi di cui l’azienda non può fare a meno e ripristinarli per primi.
La maggior parte delle organizzazioni definisce la propria procedura di ripristino proprio nel corso di un incidente. Ecco perché le prime 24–48 ore non vengono dedicate al ripristino dei sistemi, ma a stabilire quali siano gli aspetti prioritari. Le organizzazioni sanno che devono ripristinare le piattaforme di gestione delle identità, i sistemi di fatturazione, i database operativi e l’infrastruttura di base. Ciò che spesso non hanno ancora definito, però, è l’ordine di ripristino, le dipendenze tra tali sistemi e le applicazioni a valle che non possono funzionare finché non vengono ripristinati determinati servizi.
La situazione si complica man mano che l’intelligenza artificiale viene integrata nelle operazioni aziendali. Pipeline di dati, repository di modelli, database vettoriali, flussi di lavoro basati su agenti: questi elementi sono ormai dipendenze operative, non solo infrastruttura tecnica. Se la sequenza di ripristino non ne tiene conto, le stime relative ai tempi di ripristino sono probabilmente errate. Definire cosa significa operare come “azienda minimamente funzionante” (l’insieme più piccolo di sistemi necessario per mantenere l’azienda in funzione) e costruire Recovery attorno a tale definizione non è un esercizio teorico. È la risposta pratica alla domanda che ogni team dirigenziale si porrà durante un incidente: cosa ripristiniamo per primo?
In base alla mia esperienza nell’assistenza ai clienti durante incidenti in corso, le prime 12 ore rispondono a questa domanda, che lo abbiate pianificato o meno: ciò che viene ripristinato in quel lasso di tempo diventa automaticamente la vostra MVC. Le organizzazioni che superano la crisi più rapidamente hanno deciso in anticipo: sapevano esattamente quali sistemi dovevano tornare operativi entro 12 ore e avevano verificato di poterlo fare. Se la vostra MVC non rientra nelle 12 ore, non è la vostra MVC, ma una lista dei desideri. Il lavoro consiste nel continuare a ridurre l’insieme fino a quando ciò che rimane possa essere realisticamente ripristinato in quel lasso di tempo, quindi testarlo fino a quando non si è in grado di dimostrarlo.
4. Automatizzare la resilienza ed eseguire test in modo continuo, senza attenersi a un calendario prestabilito.
Un piano di ripristino che rimane confinato in un documento e viene rivisto annualmente non costituisce una capacità di ripristino. Si tratta di un’ipotesi che non è mai stata verificata nella pratica. Il problema dei test basati su un calendario è ciò che sfugge tra un ciclo e l’altro. Gli ambienti cambiano costantemente: nuovi carichi di lavoro, dipendenze aggiornate, infrastrutture che si sono discostate da quanto descritto nel runbook. Quando il test annuale viene eseguito, si sta verificando un’istantanea di un ambiente che non esiste più. In un panorama di minacce in cui lo sfruttamento può avvenire entro pochi minuti dalla divulgazione, tale ritardo è inaccettabile. L’analisi delle minacce, l’identificazione di punti di ripristino puliti, il ripristino che tiene conto delle dipendenze e l’orchestrazione del ripristino devono essere tutti automatizzati e funzionare in modo continuo. Non perché l’automazione sia una best practice, ma perché l’alternativa manuale non riesce a stare al passo con la rapidità con cui oggi si muovono le cose. I test continui dipendono anche dal rilevamento continuo. Il monitoraggio continuo dipende anche dal rilevamento continuo. Non è possibile selezionare un punto di ripristino sicuro se non si sa quando è iniziata la compromissione. Ecco perché il rilevamento delle minacce, l’analisi delle anomalie nei dati di backup e l’analisi dei punti di ripristino devono alimentarsi a vicenda: il rilevamento indica quali copie sono precedenti all’intrusione e tale determinazione determina da quale punto si effettua effettivamente il ripristino. Senza questo collegamento, si esegue il ripristino a una data che si spera sia sicura piuttosto che a una che è stata verificata, e in un panorama di minacce come quello di Frontier AI, la speranza non è una strategia di ripristino.
Ciò che emerge dai test continui è diverso da ciò che rilevano i test annuali. I test periodici tendono a confermare che il piano funzioni in condizioni controllate. I test continui individuano invece la dipendenza che è cambiata il mese scorso, la sequenza di ripristino che si interrompe quando workload aggiunto un workload specifico, il servizio di identità il cui ripristino richiede il doppio del tempo previsto dalla stima. Sono proprio queste le lacune che contano durante un evento reale, e l’unico modo per individuarle prima che si verifichi un incidente è effettuare test costanti.
I test devono inoltre essere eseguiti nell’ambiente corretto. Un test di Recovery eseguito sull’infrastruttura di produzione non indica se è possibile ripristinare i dati quando la produzione è compromessa. I test in “cleanroom” – ovvero la convalida del ripristino in un ambiente completamente isolato senza alcuna connettività con la produzione – consentono di confermare che le copie di backup siano effettivamente utilizzabili in condizioni di incidente. Ciò include il ripristino in isolamento dei servizi di identità, della gestione delle chiavi esterne e delle applicazioni di livello 0, con account di emergenza dedicati che esistono al di fuori della directory normale.
Ciò che rende fattibile il test quotidiano è il “validate restore”, un tipo di ripristino che verifica l’intero percorso di ripristino per ogni risorsa critica senza interferire con l’ambiente di produzione. La piattaforma di backup deve supportare questa funzionalità in modo nativo; se non è in grado di eseguire ogni giorno un test di ripristinabilità automatizzato e senza interruzioni su tutto il vostro MVC, non potete sapere con certezza se i vostri backup funzionano. In Commvault, questo test esegue il ripristino sui gruppi di risorse critiche, con report automatici sullo stato di ripristino di ogni sistema protetto.
Lo stesso vale per i vostri runbook. Un runbook contenuto in un documento Word o PDF è un manuale di riferimento, non uno strumento operativo: presuppone che qualcuno abbia il tempo, la lucidità e l’accesso necessari per leggerlo in situazioni di stress. I veri runbook sono script digitali che eseguono la sequenza di Recovery e convalidano ogni fase, confermando che l’applicazione funzioni effettivamente prima di procedere: non “il servizio è stato avviato”, ma “l’applicazione ha risposto correttamente a una transazione sintetica”. I Commvault Cleanroom Runbooks sono progettati proprio per questo: flussi di lavoro eseguibili che guidano un ripristino end-to-end in un ambiente isolato, senza che un operatore debba interpretare un documento ad ogni passaggio.
Un ultimo punto che raramente viene inserito nei piani di ripristino finché non è troppo tardi: durante un incidente grave, la stessa infrastruttura di comunicazione aziendale potrebbe essere compromessa o non disponibile. Email, Teams e Slack funzionano sulla stessa infrastruttura presa di mira dagli aggressori. Individuate in anticipo quali canali fuori banda utilizzerà il vostro team per coordinarsi e assicuratevi che tali canali vengano testati insieme alle vostre procedure tecniche di Recovery. Scopri di più da Bill O’Connell, Chief Security Officer di Commvault, sui quattro passaggi fondamentali per garantire la resilienza nell’era dell’intelligenza artificiale.
La resilienza è una disciplina operativa, non un progetto
Le organizzazioni che riusciranno a resistere alle minacce all’avanguardia accelerate dall’intelligenza artificiale sono quelle che considerano la resilienza una disciplina operativa: MTCR misurato, convalida continua e una capacità di ripristino comprovata, non presunta. Il problema non è che gli attacchi stiano diventando più rapidi. È che la capacità di ripristino non è ancora al passo, e finché non lo sarà, i conti non tornano.
Domande frequenti
D: Che cos’è il Mean Time to Clean Recovery (MTCR) e perché è importante?
R: L’MTCR misura la rapidità con cui un’organizzazione può tornare a uno stato verificato e noto come corretto dopo un attacco informatico — non solo ripristinando i dati, ma confermando che siano puliti e che le dipendenze delle applicazioni siano intatte. Dovrebbe essere una metrica a livello di consiglio di amministrazione con un tempo misurato e convalidato, non una stima teorica sepolta in un piano di Recovery. L’obiettivo per un MVC ben progettato – che copra tutti i sistemi di identità, le applicazioni critiche e la Readiness dell’ambiente isolato – è inferiore a sei ore.
D: Che cos’è un ambiente di ripristino isolato e in che modo differisce da un backup standard?
R: Un ambiente di ripristino isolato è una copia immutabile e completamente isolata (air-gapped) dei dati critici, strutturalmente separata dalle reti di produzione, dai sistemi di identità e dai piani di gestione. Un backup standard indica semplicemente che esiste una copia. Un IRE garantisce che tale copia sia protetta dallo stesso attacco che ha colpito l’ambiente di produzione.
D: Come facciamo a sapere se oggi siamo effettivamente in grado di ripristinare i dati?
R: L’unica risposta onesta deriva dai test, non dalla documentazione. Se non si è in grado di indicare un ripristino recente e convalidato della propria “minimum viable company” – idealmente un test automatizzato giornaliero – allora non lo si sa, si sta solo ipotizzando. Una risposta difendibile davanti al consiglio di amministrazione è un MTCR misurato e supportato da una convalida continua, non un piano di Recovery che sembra completo sulla carta.
D: Cosa si aspettano ora le autorità di regolamentazione e gli assicuratori informatici?
R: L’asticella si è spostata da «Avete dei backup?» a «Potete dimostrare di poter ripristinare in modo pulito, e in quanto tempo?». Le autorità di regolamentazione si aspettano sempre più una capacità di ripristino dimostrabile e una resilienza testata; gli assicuratori, dal canto loro, stabiliscono sempre più spesso il prezzo della copertura – e pagano i sinistri – sulla base di prove relative a backup isolati e immutabili e a tempi di ripristino convalidati. Un MTCR misurato e una cadenza di test documentata stanno diventando requisiti fondamentali per entrambi. Rajiv Kottomtharayil è Chief Product Officer presso Commvault.
