Resilience Over Panic: Four Steps for the Age of Frontier AI

Per anni, nell’ambito della sicurezza aziendale si è partendo dal presupposto che un sistema di prevenzione ben consolidato potesse tenere testa alle minacce abbastanza a lungo da consentire ai difensori di reagire. Frontier AI 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 di sicurezza rappresentati dal proprio modelloMythos, l’iniziativaProgetto Glasswingdi Anthropic ha già coinvoltoquasi 200 aziendee ha portato alla luce circa 10.000 vulnerabilità critiche o ad alta gravità. Nel frattempo,il GPT-5.5 di OpenAIsta 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 esplorare le nuove tempistiche 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 di Recovery complete – offre alle organizzazioni un punto di partenza pratico.

L’IA di frontiera rivoluziona la gestione delle vulnerabilità

La potenza dell’IA all’avanguardia raddoppia ora all’incircaogni 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.
• Il concatenamento 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 corrette, 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.

1. 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.
2. È 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 da 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 visibilità più chiara della propria resilienza, le organizzazioni hanno iniziato a utilizzare la metricaMTCR (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 affiancare 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 “Minimum Viable Company” risiedano in un ambiente isolato (air-gapped), immutabile e segmentato in rete, che possa essere avviato e disattivato rapidamente. Per i carichi di lavoro più critici, ciò dovrebbe essere verificato con cadenza di 45 giorni.
• Fase 3: Valutare i rischi legati alla Recovery prima di dichiararla completata, poiché reintrodurre una backdoor o un malware durante la Recovery vanifica lo scopo dell’operazione e lascia poco tempo per un secondo tentativo.
• Fase 4: Considerare la Recovery come qualcosa di più di una semplice simulazione teorica. Eseguire le operazioni di Recovery avvalendosi delle stesse persone e delle stesse procedure che verrebbero coinvolte in un incidente reale, insieme ai processi automatizzati che ne stanno alla base.

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 espande l’area che necessita di protezione, dai database vettoriali e dai pesi dei modelli alle configurazioni degli agenti e agli endpoint, comeClaude CoworkoGoogle Antigravità, 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 essere 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 può 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 la Recovery informatica è un problema 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 la Recovery basata sull’IA agentica. Iscrivitiquiper il webinar.

Domande frequenti

D: Che cos’è il mean time to clean recovery (MTCR)?

A: Il tempo medio di ripristino sicuro (MTCR) misura il tempo necessario a un’organizzazione per tornare a uno stato operativo verificato e sicuro 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 manuale 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 si differenzia dall’RTO?

A: 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 impiegato per la convalida manuale prima che i sistemi tornino in produzione. In caso specifico di incidente informatico, un sistema può rispettare il proprio RTO e tuttavia non raggiungere una vera resilienza se l’ambiente ripristinato viene nuovamente infettato poco dopo.

D: Che cos’è una “minimum viable company” e in che cosa si differenzia da un piano completo di Recovery di emergenza?

A: Una “minimum viable company”, talvolta denominata anche “minimum viable business”, è l’insieme ridotto e orientato alle attività aziendali di sistemi, dati e dipendenze che un’organizzazione deve ripristinare per continuare a funzionare dopo un incidente, anziché l’intero parco 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 pratica di Recovery?

A: Un’esercitazione teorica è una simulazione su carta di un piano di risposta agli incidenti, solitamente utilizzata per mettere alla prova il processo decisionale e la comunicazione tra le parti interessate senza attuare effettivamente alcuna misura 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 avere un piano di resilienza che sembra solido a prima vista, ma che non è stato testato rispetto ai dettagli operativi che tendono a far 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?

A: Gli NHI sono le credenziali, le autorizzazioni e i diritti di accesso assegnati a componenti software, come gli agenti di intelligenza artificiale, anziché a singole persone. Man mano che le organizzazioni implementano un numero crescente di agenti di intelligenza artificiale, il numero di NHI in un ambiente aumenta e, in caso di Recovery, è necessario tenerne conto insieme a elementi più familiari come i database e i sistemi transazionali.

Il ripristino di un sistema di IA agentica 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)?

A: 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 una sola 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.