Ogni organizzazione che abbia mai fallito un tentativo di ripristino – e ce ne sono più di quante se ne ammettano pubblicamente – aveva una cosa in comune: credeva di poter riuscire a riprendersi prima ancora di provarci.
Questa convinzione aveva una sua origine. Un’esercitazione teorica portata a termine. Un sistema di backup che mostrava lo stato “verde”. Un test annuale di ripristino di emergenza superato. Tutto documentato. Tutto, a un certo punto, accurato. Nulla di tutto ciò era aggiornato quando l’incidente si è effettivamente verificato. Questo è il divario di fiducia. Ed è proprio questo divario che la verifica continua del ripristino è chiamata a colmare.
Cosa significa realmente “testare” nella maggior parte delle organizzazioni
Se si chiede alla maggior parte dei responsabili della sicurezza o dell’IT con quale frequenza testino la propria capacità di ripristino, la risposta è in genere “una volta all’anno”, a volte “due volte all’anno”. Il test consiste nel ripristinare un sottoinsieme di sistemi dal backup in un ambiente di prova, verificare che si avviino correttamente e redigere un rapporto. Talvolta, parallelamente, viene condotta anche un’esercitazione teorica. Ciò che questo tipo di test non fa: verificare che i dati di backup siano privi di malware; confermare che la sequenza di ripristino funzioni per servizi interdipendenti. Non verifica la Recovery delle identità, essenziale quando sono state proprio le credenziali compromesse a consentire l’attacco. Non conferma che il team che dovrebbe effettivamente eseguire la Recovery conosca le procedure operative aggiornate. Né produce prove sufficientemente significative per dimostrare a un’autorità di regolamentazione, a un revisore o a un consiglio di amministrazione che la capacità di Recovery sia reale e aggiornata. In breve, convalida un momento specifico. Le operazioni di resilienza (ResOps) richiedono che la convalida sia uno stato continuo.
Il modello di convalida continua
La convalida continua del ripristino non consiste semplicemente nell’eseguire un unico test con maggiore frequenza. Si tratta piuttosto di un insieme di pratiche integrate che forniscono una dimostrazione continua e basata su dati concreti della ripristinabilità dei servizi critici. Scansione automatizzata dell’integrità dei backup. Ogni backup viene valutato continuamente per individuare anomalie, modelli di crittografia e firme di malware. Non al momento del ripristino, ma prima del ripristino. L’obiettivo è verificare che i punti di ripristino siano integri prima che se ne presenti la necessità, non durante un incidente.
Cleanroom Recovery: "Cleanroom Recovery" programmate. Da effettuare almeno due volte all’anno, prevedono il ripristino da punti di backup immutabili in un ambiente “Cleanroom Recovery” isolato – non in produzione, né in un ambiente di test adiacente alla produzione, ma in uno spazio realmente isolato dove sia possibile effettuare analisi forensi senza rischio di reinfezione. Queste esercitazioni forniscono prove documentate della recuperabilità rispetto a tolleranze di impatto definite.
Verifica del ripristino dell’identità. Poiché l’uso improprio delle credenziali rappresenta il vettore di violazione più comune, è necessario testare il ripristino di Active Directory e Entra ID parallelamente al ripristino dei dati. Le organizzazioni che ripristinano i sistemi senza ripristinare un livello di identità verificato e pulito potrebbero scoprire che gli aggressori rientrano dalla stessa porta.
Dashboard degli indicatori di resilienza dei servizi (SRI). Gli SRI – segnali continui ricavati dalla telemetria di backup, dalla mappatura delle dipendenze e dai risultati dei test – offrono ai CISO, ai CIO e ai consigli di amministrazione una visione in tempo reale dello stato di recuperabilità. Non si tratta di un report puntuale, bensì di un segnale operativo continuo.
Ciascuna di queste pratiche contribuisce a ciò che Deloitte e Commvault definiscono “resilience backlog”: un elenco, costantemente aggiornato e ordinato per priorità, delle lacune individuate tramite test e di cui viene monitorata la risoluzione. Si tratta del meccanismo attraverso il quale la convalida stimola il miglioramento, anziché limitarsi alla semplice produzione di report.
Cosa si intende per “tempo medio necessario per la pulizia delle modifiche di ripristino”
Le metriche di Recovery tradizionali – l’obiettivo del tempo di Recovery (RTO) e l’obiettivo del punto di Recovery (RPO) – misurano la velocità e l’attualità dei dati. Non forniscono alcuna indicazione sull’affidabilità dei dati che vengono ripristinati. Il Mean Time to Clean Recovery (MTCR) colma questa lacuna: misura il tempo necessario per ripristinare dati che siano verificabilmente integri, non solo tecnicamente disponibili.
L’MTCR è importante perché, in caso di attacco ransomware, l’obiettivo dell’autore dell’attacco è spesso quello di compromettere le opzioni di ripristino, non solo di crittografare i sistemi di produzione. Un’organizzazione che effettua un ripristino rapido ma attingendo da un backup compromesso non si è effettivamente ripresa. Si è semplicemente reinfectata.
Incorporare l’MTCR nel proprio quadro di misurazione della resilienza, insieme all’RTO e all’RPO, modifica gli obiettivi di ottimizzazione e i dati da comunicare al consiglio di amministrazione. Velocità, tempestività e integrità: ecco il quadro completo della prontezza al ripristino.
Una resilienza che si può dimostrare
Le organizzazioni che affrontano le interruzioni informatiche subendo il minor danno possibile hanno una caratteristica in comune: considerano la capacità di ripristino come qualcosa da dimostrare continuamente, non da affermare periodicamente. Conoscono il proprio MTCR. I loro SRI sono aggiornati. La loro “cleanroom” è stata testata negli ultimi 90 giorni. Questo approccio non è solo il risultato di una tecnologia migliore. È il risultato di una disciplina operativa – ResOps – che rende la resilienza continua, misurabile e governabile. La piattaforma di Commvault fornisce le basi tecniche: Recovery pulito, convalida automatizzata e visibilità unificata su dati, identità e servizi che ResOps richiede su larga scala.
Per quanto riguarda l’aspetto organizzativo di questa equazione – come definire le tolleranze di impatto, allineare la leadership esecutiva e costruire la struttura di governance che sostiene la disciplina – consulta il blog di Deloitte, “La conversazione sulla resilienza che il tuo consiglio di amministrazione non sta ancora affrontando”. E per un quadro completo del ResOps, comprese le sei aree del ResOps e il modello di misurazione che collega la recuperabilità tecnica alla responsabilità a livello di consiglio di amministrazione, leggete il white paper congiunto: “Dalla fattibilità minima alla resilienza operativa: il ResOps nella pratica”.
Bill O’Connell è Chief Security Officer presso Commvault.
