Per anni, il dibattito sulla resilienza si è concentrato sulla tecnologia. Avete dei backup? Avete un piano di ripristino in caso di emergenza? Avete messo in atto misure di protezione per prevenire un attacco?
Queste rimangono domande importanti. Ma sempre più spesso non sono quelle che mi vengono poste dai dirigenti.
Invece, mi sembra di sentire una domanda molto più semplice:Se domani subissimo un attacco informatico, riusciremmo a riprenderci e a dimostrarlo?
NovitàRicerca IDC, sulla base di un sondaggio condotto su 539 responsabili delle decisioni in materia di IT e resilienza negli Stati Uniti e in Canada, rivela una realtà sempre più evidente: disporre di tecnologie di Recovery non significa automaticamente che un’organizzazione sia pronta per il Recovery.
Di recente ho incontrato Jason Cray, del team Product Experience di Commvault, per discutere di quella ricerca condotta da IDC. Dalla nostra conversazione non è emersa semplicemente una discussione sul backup, sul Recovery o sulla resilienza informatica.
Si è trattato di una discussione sulla fiducia. Più precisamente, sul motivo per cui così tante organizzazioni ritengono di poter riprendersi, ma faticano a dimostrare di essere effettivamente pronte per Recovery.
Guarda ilWebinar “Prepararsi alla Recovery” on demand.
Punti di forza
- La differenza tra essere recuperabile ed essere pronto per il recupero è come quella tra teoria e dimostrazione.
- IDC ha rilevato che il 57,7% delle organizzazioni non ha definito in modo completo il proprio “minimum viable business”. Se non si sa cosa è necessario ripristinare, come è possibile stabilire le priorità su ciò che deve essere ripristinato per primo?
- Il recupero completo dei dati non è una strategia praticabile. Il successo del recupero dipende dalla definizione delle priorità e dal contesto aziendale.
- Per avere successo, la Recovery richiede un approccio di squadra.
- La differenza fondamentale tra il cyber recovery e il disaster recovery risiede nella necessità di fiducia.
- La velocità potrebbe non essere il parametro migliore per valutare il Recovery, soprattutto se non ci si può fidare dei propri backup.
- Le organizzazioni conquistano la fiducia attraverso la verifica, non solo con la pianificazione.
- ResOps offre un quadro di riferimento per trasformare la resilienza in una disciplina operativa.
Qual è la differenza tra essere “recuperabile” ed essere “pronto per il recupero”?
Qualche anno fa, molte discussioni sul tema della resilienza si concludevano con una lista di controllo.
- Backup? Controllo.
- Piano di Recovery? Controllo.
- Test di ripristino di emergenza? Controllo.
Oggi, quel livello di garanzia non è più sufficiente.
Durante il webinar, Jason ha espresso un punto di vista che sento spesso dai clienti: le organizzazioni di solito sono in grado di indicare con esattezza quanto investono nelle tecnologie di sicurezza e protezione, ma sono molto meno numerose quelle che possono spiegare con sicurezza come si riprenderebbero qualora tali controlli fallissero.
La distinzione può sembrare sottile, ma è importante.
Essere “recuperabili” significa disporre di meccanismi in grado di supportare il ripristino. Essere “pronti al ripristino” significa aver dimostrato che tali meccanismi sono in grado di ripristinare con successo le operazioni aziendali critiche in condizioni reali.
Man mano che la resilienza diventa una priorità a livello di consiglio di amministrazione, le ipotesi stanno lasciando il posto ai dati concreti. I dirigenti vogliono avere la certezza che i piani di Recovery funzioneranno davvero quando la pressione sarà al massimo.
Quando la situazione si fa critica, la tua organizzazione sa cosa conta davvero?
Uno dei risultati più sorprendenti emersi dallo studioRicerca IDCè cheIl 57,7% delle organizzazioni non ha ancora definito appieno il proprio modello di business minimo funzionante.
Un “business minimo funzionante” non è semplicemente un elenco di applicazioni essenziali. È l’insieme di persone, processi, sistemi e dati necessari per garantire il funzionamento dell’organizzazione in caso di interruzione delle attività. Risponde a una domanda fondamentale:
Cosa deve assolutamente tornare per primo?
È proprio qui che molte strategie di Recovery cominciano a fallire.
Ho collaborato con organizzazioni che comprendono quali applicazioni siano importanti, ma che non hanno mappato le dipendenze che le sostengono. Altre continuano a considerare quasi ogni carico di lavoro come mission-critical. Sebbene tale approccio possa sembrare prudente, crea un problema pratico durante Recovery.
Quando tutto è fondamentale, nulla lo è
Recovery richiede tempo. Le infrastrutture hanno dei limiti. Le dipendenze sono importanti.
Le organizzazioni non possono realisticamente aspettarsi di ripristinare un intero ambiente da diversi petabyte subito dopo un incidente informatico su larga scala. Diventa quindi essenziale stabilire delle priorità.
Le organizzazioni che riescono a riprendersi in modo più efficace tendono a sapere esattamente cosa deve essere ripristinato per primo, cosa può aspettare e quali risultati aziendali dipendono da tali decisioni. È proprio questo che permette di definire un modello di business minimo funzionante.
Anteprima: webinar sulla preparazione al Recovery
Uno dei temi che Jason e io abbiamo approfondito durante il webinar è il fatto che la resilienza informatica sia una responsabilità condivisa. In molte organizzazioni prevale l’errata convinzione che la Readiness per il ripristino sia una sfida di natura infrastrutturale. Non è così: si tratta di una sfida organizzativa. Richiede un allineamento tra i team di sicurezza, IT, legale, comunicazione e business per garantire che le applicazioni critiche, i processi e le priorità di ripristino siano chiaramente compresi prima che si verifichi un’interruzione.
I piani di Recovery falliscono se attuati in modo isolato
Molte organizzazioni continuano ad affrontare il tema della resilienza attraverso team che operano in modo disgiunto. I team che si occupano di infrastrutture si concentrano sui sistemi. I team di sicurezza si concentrano sulle minacce. I dirigenti aziendali si concentrano sulla continuità operativa. I team legali e di comunicazione spesso vengono coinvolti solo dopo che si è verificato un incidente.
Il problema è che le interruzioni non rispettano i confini organizzativi.
Il successo della Recovery dipende da un processo decisionale coordinato tra tutte queste funzioni. Le priorità di Recovery, la comunicazione con i clienti, le operazioni aziendali, gli obblighi legali e le attività tecniche di Recovery devono tutte operare in sinergia in tempo reale.
Recentemente, un cliente ha descritto il proprio impegno nella pianificazione della resilienza come la creazione di una squadra di supereroi. Sebbene lo intendesse come una battuta, questa affermazione ha colto perfettamente la realtà della moderna Readiness al ripristino. Le organizzazioni si riprendono agendo come squadre, non grazie alle tecnologie.
Perché il cyber recovery è fondamentalmente diverso dal disaster recovery
Un malinteso di cui abbiamo parlato durante il webinar è la convinzione che i piani tradizionali di Recovery in caso di disastri possano essere semplicemente adattati al Recovery informatico.
In realtà, risolvono problemi diversi.
Il disaster recovery tradizionale era spesso basato su scenari di guasto prevedibili: un’interruzione del sito, un guasto dell’infrastruttura, un’interruzione nota che innescava una risposta documentata. Gli incidenti informatici sono fondamentalmente diversi.
Le organizzazioni devono stabilire quali sistemi siano stati compromessi, quali dati siano affidabili e se le azioni di Recovery possano inavvertitamente reintrodurre dei rischi. La sfida non consiste semplicemente nel Recovery, ma nella verifica.
Non si può ripristinare ciò di cui non ci si può fidare. Questa incertezza determina un processo di Recovery molto diverso.
Se le organizzazioni ripristinano sistemi compromessi o dati infetti, rischiano di reintrodurre il problema nell’ambiente di produzione. Poiché gli attacchi diventano sempre più sofisticati, verificare l’integrità degli ambienti ripristinati assume un’importanza sempre maggiore.
Recovery non consiste più solo nel riportare i sistemi in funzione. Si tratta di riconquistare la fiducia.
Perché la fiducia conta più della rapidità: un recupero veloce può comunque rivelarsi un fallimento
Questo ci porta a uno dei punti più importanti della nostra discussione. Per anni, il successo del Recovery è stato misurato principalmente in base alla velocità.
- In quanto tempo è possibile ripristinare i sistemi?
- In quanto tempo potranno riprendere le operazioni?
Quelle domande sono ancora importanti. Ma la velocità da sola non basta più.
Una recovery che reintroduca malware, identità compromesse o dati non attendibili nell’ambiente di produzione non può dirsi realmente riuscita. Ecco perché sempre più organizzazioni stanno investendo in ambienti di recovery isolati, esercitazioni di convalida e test di recovery progettati per verificare l’integrità delle risorse ripristinate prima che tornino in produzione.
Un recupero veloce ha senso solo se si recupera qualcosa di cui ci si può fidare.
MTCR: il nuovo indicatore della fiducia nella Recovery
Mentre le organizzazioni stanno ridefinendo il modo in cui misurano la resilienza, molte stanno andando oltre i tradizionali obiettivi di tempo di ripristino (RTO) e obiettivi di punto di ripristino (RPO).
Si stanno invece concentrando sutempo medio necessario per il ripristino della pulizia.
Ciò che rende prezioso l’MTCR è che riflette la realtà della Recovery informatica moderna. Non si tratta solo della rapidità con cui un’organizzazione ripristina i dati, ma comprende anche il tempo necessario per verificare, valutare e riportare con sicurezza i sistemi in produzione.
Questa distinzione è importante perché le organizzazioni non si limitano a ripristinare l’infrastruttura, ma ripristinano le operazioni aziendali. L’MTCR riflette meglio la rapidità con cui l’organizzazione può tornare in sicurezza a uno stato operativo affidabile.
La fiducia deriva dai test
Se c’è una lezione che ho imparato lavorando con organizzazioni che si trovano in diverse fasi di maturità in termini di resilienza, è questa: la fiducia non deriva dalla documentazione.
La fiducia deriva dai test.
Gli esercizi di recupero statico spesso confermano processi noti in condizioni ideali. Le interruzioni che si verificano nella realtà sono raramente così prevedibili.
Le organizzazioni pronte al Recovery effettuano test in modo continuativo. Simulano condizioni realistiche. Introducono elementi di incertezza. Identificano le dipendenze. Individuano i punti deboli prima che lo facciano gli aggressori.
Ma soprattutto, sviluppano la “memoria muscolare” organizzativa.
Durante il webinar, Jason ha espresso un punto di vista che ho sempre trovato molto convincente: le organizzazioni possono scegliere di affrontare le questioni in un periodo di stabilità, oppure possono cercare di risolverle nel bel mezzo di una crisi. L’opzione migliore è ovvia.
I test non si limitano a verificare la tecnologia. Verificano le persone, i processi, la comunicazione, le priorità e le ipotesi. Ed è proprio da lì che nasce la vera fiducia.
ResOps: ecco cosa succede quando Recovery diventa una disciplina operativa
Nel corso della nostra discussione, quasi tutte le sfide che abbiamo individuato rimandavano alla stessa esigenza: le organizzazioni hanno bisogno di un modo per definire le priorità in modo coerente, allineare le parti interessate, verificare la recuperabilità e migliorare nel tempo.
È proprio per questo che le operazioni di resilienza, o ResOps, stanno prendendo piede.
ResOps non consiste nell’introdurre un altro strumento o processo. Si tratta piuttosto di rendere operativa la resilienza. Riunisce persone, processi e tecnologia in un quadro comune finalizzato alla verifica e al miglioramento continui.
Perché, in fin dei conti, la Readiness al ripristino non è un progetto. È una disciplina.
Le organizzazioni che si distingueranno nei prossimi anni non saranno semplicemente quelle dotate di tecnologie di Recovery o di piani documentati. Saranno invece quelle in grado di dimostrare che tali piani funzionano:
- Sapranno cosa conta di più.
- Capiranno come recuperarlo.
- Verificheranno che sia sicuro procedere con la guarigione senza rischio di reinfezione
- E avranno le prove per dimostrarlo.
In altre parole, non saranno semplicemente recuperabili. Saranno pronti per il recupero.
Per saperne di più
Il rapporto IDC ha inoltre rilevato che la resilienza organizzativa complessiva delle aziende intervistate è compromessa sia da lacune nelle singole tecnologie, sia dall’assenza di un quadro di coordinamento che riunisca le funzioni aziendali, infrastrutturali e di sicurezza attorno a un obiettivo comune di Recovery.
Per approfondire la ricerca:
- Guarda il webinar: Webinar “Prepararsi alla Recovery” on demand
- Scarica il rapporto: Rapporto IDC sulle operazioni di resilienza
Domande frequenti
D: Che cos’è ResOps?
R:ResOps (operazioni di resilienza) è una disciplina operativa che aiuta le organizzazioni a verificare e migliorare costantemente la propria capacità di riprendersi da eventuali interruzioni. Essa integra persone, processi e tecnologia per rendere misurabile e dimostrabile la Readiness al ripristino.
D: Che cos’è un’impresa minimamente funzionante?
R:Un “business minimo funzionante” è l’insieme di sistemi, processi, persone e dati necessari per continuare a operare durante un’interruzione. Aiuta le organizzazioni a stabilire le priorità nelle operazioni di Recovery quando non è possibile ripristinare tutto contemporaneamente.
D: In che modo il cyber recovery differisce dal disaster recovery?
R:Il disaster recovery tradizionale si basa su scenari di guasto prevedibili. Poiché la natura degli attacchi informatici è imprevedibile, il cyber recovery richiede alle organizzazioni di concentrare la propria attenzione sull’individuazione dei sistemi affidabili, sulla convalida dei dati recuperati e sulla garanzia che le minacce non vengano reintrodotte negli ambienti di produzione.
D: Che cos’è il mean time to clean recovery (MTCR)?
R:L’MTCR misura il tempo necessario a un’organizzazione per tornare a uno stato operativo verificato e affidabile. Esso comprende attività di Recovery, convalida e rafforzamento della fiducia, anziché concentrarsi esclusivamente sulla velocità di ripristino.
Perché i test di recovery sono importanti?
R:I test aiutano le organizzazioni a individuare dipendenze nascoste, a verificare le ipotesi, a sviluppare la “memoria muscolare” e a migliorare i processi di Recovery prima che si verifichi un’interruzione effettiva. La fiducia nel Recovery si conquista con la pratica, non con le scartoffie.
D: Perché è importante la resilienza dell’identità?
R:I sistemi di identità svolgono un ruolo fondamentale nel processo di Recovery. Se gli utenti non riescono ad accedere ai sistemi di produzione, agli ambienti di Recovery o ai dati critici, anche i migliori piani di Recovery potrebbero risultare difficili da attuare con successo.
D: In che modo le organizzazioni possono valutare il proprio grado di Readiness per il ripristino?
R:Le organizzazioni possono iniziare definendo il proprio modello di business minimo funzionante, testando regolarmente i processi di Recovery, verificando gli ambienti ripristinati e misurando i risultati utilizzando indicatori quali il tempo medio necessario per un ripristino completo (MTCR).
Vidya ShankaranIl futuro della resilienza informatica non è solo un’IA più intelligente, ma un’IA più logica. Combinando la potenza esecutiva dei sistemi agenti con la profondità di ragionamento dell’IA causale, possiamo costruire architetture di sicurezza che non si limitano a sopravvivere agli attacchi, ma li comprendono.