Tutte le aziende che hanno fallito un ripristino – e sono molte di più di quante l’abbiano ammesso pubblicamente – avevano un elemento in comune: essere convinte di poterci riuscire prima ancora che accadesse. È una convinzione che spesso ha un fondamento. Un’esercitazione teorica portata a termine, un sistema di backup che risultava funzionante, un test annuale di disaster recovery superato. Tutto documentato, tutto, fino a un certo punto, accurato. Ma quando l’incidente si è effettivamente verificato, le cose sono andate in modo diverso.
Questo è il gap di fiducia ed è proprio ciò che la verifica continua del recovery ha l’obiettivo di colmare.
Cosa significa realmente “effettuare test” nella maggior parte delle aziende
Se si chiede alla maggior parte dei responsabili della sicurezza o dell’IT con quale frequenza testino le loro capacità di recovery, la risposta è generalmente su base annuale, a volte semestrale. Il test prevede il ripristino di un sottoinsieme di sistemi da un backup in un ambiente di test, la verifica che si avviino correttamente e la redazione di un report. A volte, viene condotta in parallelo anche un’esercitazione.
Tuttavia, questo tipo di test non verifica che i dati di backup siano privi di malware, non conferma che la sequenza di ripristino funzioni per i servizi interdipendenti, né testa il recupero dell’identità, un aspetto essenziale quando è stata la compromissione delle credenziali a permettere l’attacco. Non conferma neanche che il team che dovrebbe effettivamente eseguire il recovery conosca i runbook aggiornati, né produce prove sufficientemente significative da soddisfare un ente regolatore, un revisore o un consiglio di amministrazione riguardo alla reale e attuale capacità di ripristino.
In breve, si limita a certificare un punto specifico nel tempo. Le operazioni di resilienza (ResOps) richiedono invece una convalida continua.
Il modello di validazione continua
La validazione continua del recovery non è un singolo test eseguito con maggiore frequenza. È un insieme di pratiche integrate che producono una prova costante, basata su evidenze, della recuperabilità dei servizi critici.
· Scansione automatizzata dell’integrità dei backup. Ogni backup viene continuamente valutato rispetto ad anomalie, modelli di crittografia e firme di malware. Questo avviene non al momento del ripristino, ma prima. L’obiettivo è sapere se i punti di ripristino sono puliti prima che se ne abbia bisogno, non durante un incidente.
· Esercitazioni programmate di recovery in cleanroom. Almeno due volte l’anno, prevedono il ripristino da punti di backup immutabili in un ambiente di recovery cleanroom isolato – non in produzione, né in un ambiente di test adiacente alla produzione, ma uno spazio realmente isolato dove sia possibile effettuare analisi forensi senza rischio di reinfezione. Queste esercitazioni producono prove documentate della recuperabilità rispetto a tolleranze d’impatto predefinite.
· Validazione del ripristino dell’identità. Poiché l’abuso di credenziali è il vettore di violazione più comune, il recovery di Active Directory ed Entra ID deve essere testato insieme a quello dei dati. Le aziende che effettuano il restore dei sistemi senza ripristinare un livello di identità verificato come pulito potrebbero scoprire che gli attaccanti riescono a rientrare dalla stessa porta da cui sono entrati la prima volta.
· Dashboard degli Indicatori di Resilienza dei Servizi (Service Resilience Indicator). Gli SRI – segnali continui derivati dalla telemetria dei backup, dalla mappatura delle dipendenze e dai risultati dei test – forniscono a CISO, CIO e consigli di amministrazione una visione in tempo reale della postura di recuperabilità. Non un report statico, ma un segnale operativo continuo.
Ciascuna di queste pratiche alimenta quello che Commvault, con Deloitte, definisce il backlog della resilienza: un elenco costantemente aggiornato e prioritario di lacune identificate tramite i test e monitorate fino alla risoluzione. È il meccanismo attraverso il quale la validazione porta al miglioramento della situazione, anziché limitarsi a produrre semplici report.
Il valore del Mean Time to Clean Recovery (MTCR)
Le metriche di ripristino tradizionali, Recovery Time Objective (RTO) e Recovery Point Objective (RPO), misurano la velocità e l’attualità dei dati. Non forniscono però alcune indicazioni sull’affidabilità dei dati che vengono ripristinati. Il Mean Time to Clean Recovery (MTCR) colma questa lacuna, misurando il tempo necessario per ripristinare dati che sono integri in modo verificabile, non solo tecnicamente disponibili.
Il MTCR è cruciale perché, in caso di un attacco ransomware, l’obiettivo dell’avversario è spesso quello di compromettere le opzioni di ripristino, non solo di crittografare i sistemi di produzione. Un’azienda che ripristina rapidamente, ma partendo da un backup compromesso, non ha effettivamente recuperato i dati, si è semplicemente infettata di nuovo.
Integrare il MTCR nel proprio framework di misurazione della resilienza, insieme a RTO e RPO, cambia gli obiettivi di ottimizzazione e i dati da riportare al consiglio di amministrazione. Velocità, tempestività e integrità: questi sono gli elementi fondamentali di una reale preparazione al ripristino.
Resilienza che si può dimostrare
Le aziende che gestiscono le interruzioni informatiche subendo il minor danno possibile condividono una caratteristica: considerano le capacità di recovery come qualcosa da dimostrare costantemente, non da affermare su base periodica. Conoscono il proprio MTCR, hanno SRI aggiornati e il loro ripristino in ambiente cleanroom è stato testato negli ultimi 90 giorni.
Una postura del genere non discende dalla scelta di una tecnologia migliore, ma è il frutto di una disciplina operativa – la cosiddetta ResOps – che rende la resilienza continua, misurabile e governabile.
