Punti di forza
- La resilienza dipende dalla rapidità e dalla sicurezza con cui l’azienda è in grado di riprendersi, non solo dalla capacità di tenere a bada ogni minaccia.
- Trasformare i piani di Recovery in dati concreti: i risultati comprovati sono più credibili per i consigli di amministrazione, le autorità di regolamentazione e gli assicuratori rispetto a obiettivi o ipotesi.
- Rendere ResOps un modello operativo condiviso per la sicurezza, l’infrastruttura, la continuità operativa e i responsabili dei servizi.
- Misurate ciò che conta: i team devono sapere se i servizi critici possono essere ripristinati, quanto tempo richiede effettivamente il ripristino e se sono in grado di dimostrarlo.
- Scegliete uno o due servizi critici, definite cosa si intende per “Recovery riuscito”, eseguite un’esercitazione realistica e documentate i risultati.
- Vent’anni di leadership nel settore della sicurezza ti insegnano presto una cosa: l’attacco che hai bloccato non viene mai menzionato durante la riunione del consiglio di amministrazione. Quello che non sei riuscito a fermare è l’unica storia che tutti ricordano. A un certo punto ho smesso di valutare il mio team in base al numero di attacchi che abbiamo assorbito da soli e ho iniziato a valutarci anche in base alla rapidità con cui siamo riusciti a riprenderci.
- Ecco perché voglio che ogni CISO, CIO e membro del consiglio di amministrazione che conosco legga il nuovo rapporto di O’Reilly, *ResOps: An Executive Guide*, pubblicato questa settimana. È stato sponsorizzato da Commvault, ma lo consiglierei comunque.
Il muro non è mai stato l’intero piano
Per gran parte della mia carriera, il mio lavoro è stato quello di costruire muri più alti: rilevamento più efficace, controlli più rigorosi, risposta più rapida. Quel lavoro è ancora importante, e lo sarà sempre. Ma un muro risponde solo a una domanda, e non è più quella che si pone il vostro consiglio di amministrazione.
Lo scorso settembre, un attacco ransomware ha costretto Jaguar Land Rover a interrompere la produzione a livello globale. Le linee di assemblaggio si sono fermate. Le catene di approvvigionamento si sono bloccate. Il Cyber Monitoring Centre del Regno Unito ha stimato il costo per l’economia in generale a circa 1,9 miliardi di sterline, e JLR ha registrato il suo volume di produzione mensile più basso degli ultimi 73 anni. JLR disponeva di difese. Ciò che l’incidente ha messo alla prova non è stato se il muro avrebbe retto, ma se l’azienda sarebbe stata in grado di riprendersi una volta che non avesse retto.
L’ho già detto in passato e continuerò a ripeterlo: la disruption non è una questione di “se”, ma di “quando”. I CISO che dormono sonni tranquilli non sono quelli che credono di poter tenere fuori ogni minaccia; sono quelli che si sono esercitati a riprendersi così tante volte che l’esercitazione stessa è la loro sicurezza.
Tre domande che pongo al mio team
Il rapporto articola l’intero problema in tre domande, e ho iniziato ad aprire ogni revisione sulla resilienza proprio con queste:
- Se fossimo colpiti stanotte, riusciremmo a riprenderci?
- Quanto tempo ci vorrebbe effettivamente?
- Possiamo dimostrarlo, con prove concrete, al consiglio di amministrazione?
La maggior parte delle organizzazioni risponde alle prime due domande con un piano e alla terza con il silenzio. Quel silenzio rappresenta il divario di resilienza, ed è più grande e più costoso di quanto la maggior parte dei dirigenti si renda conto.
Prove, non promesse
Ecco una distinzione che il rapporto illustra meglio di quanto io abbia mai sentito altrove: un obiettivo di tempo di ripristino (RTO) è un traguardo. Indica ciò a cui si punta, ma non dice se lo si raggiungerà.
Confrontate «crediamo di poter ripristinare il servizio di pagamenti in quattro ore» con «lo abbiamo ripristinato in 3,2 ore lo scorso trimestre, da un punto di ripristino verificato e pulito, con una tolleranza di quattro ore». La prima frase è un piano. La seconda è una prova. Solo una delle due regge quando il vostro consiglio di amministrazione, la vostra autorità di regolamentazione o la vostra compagnia di assicurazione contro i rischi informatici inizieranno a porre domande più difficili, cosa che sicuramente faranno.
Il rapporto definisce questa disciplina «ResOps», abbreviazione di «resilience operations» (operazioni di resilienza). Non si tratta di un prodotto che si acquista né di un raccoglitore da archiviare. È un modello operativo che collega sicurezza, infrastruttura, continuità operativa e i responsabili aziendali che dipendono da questi servizi, tutti operanti sulla base delle stesse prove anziché di piani separati.
L’aspetto che dovrebbe preoccupare ogni CISO
Il rapporto menziona anche qualcosa che percepivo da tempo e per cui finalmente ho trovato le parole giuste: il paradosso dell’IA. La stessa capacità dell’IA che ci aiuta a individuare le vulnerabilità più rapidamente sta aiutando gli aggressori a colmare il divario tra individuazione e sfruttamento altrettanto rapidamente, forse anche più velocemente. Individuare più problemi non vi rende più sicuri se non riuscite a riprendervi da quelli che riescono a passare. La velocità di rilevamento non è mai stata l’obiettivo finale. Lo è invece la capacità di Recovery.
Iniziate con un solo servizio
Nulla di tutto ciò richiede di voler fare l’impossibile, e mentirei se dicessi che il mio team ha azzeccato tutto al primo tentativo. Il rapporto Delinea un percorso di 90 giorni: scegliete uno o due dei vostri servizi più critici, definite cosa significhi realmente “ripristinato” per ciascuno di essi, eseguite un’esercitazione di Recovery onesta e producete la vostra prima prova concreta. È un progetto che qualsiasi team può avviare in questo trimestre, compreso il mio.
I fatti contano più delle promesse. La Readiness conta più della perfezione. Questo è lo standard a cui sottopongo il mio team, ed è lo standard verso cui questo rapporto vi indica un percorso concreto.
Scaricate qui la vostra copia di “ResOps: An Executive Guide”.
Domande frequenti
D: Che cos’è ResOps?
R: ResOps, abbreviazione di “resilience operations” (operazioni di resilienza), è un modello operativo che mette in collegamento i responsabili della sicurezza, dell’infrastruttura, della continuità operativa e dei servizi attorno a pratiche di Recovery condivise e basate su prove concrete.
D: In che modo ResOps si differenzia dal tradizionale Disaster Recovery?
R: Il disaster recovery tradizionale si concentra spesso su piani e obiettivi tecnici. ResOps pone l’accento sulla convalida continua, sulla responsabilità trasversale e sulla prova misurabile che i servizi critici possano essere ripristinati entro i limiti di tolleranza aziendali.
D: Perché i test di Recovery sono importanti?
R: I test di Recovery dimostrano ciò che un’organizzazione ha effettivamente testato e realizzato. Contribuiscono a infondere nei consigli di amministrazione, nelle autorità di regolamentazione, negli assicuratori e nei dirigenti aziendali una fiducia maggiore rispetto ai soli piani o obiettivi di Recovery.
D: Cosa dovrebbero misurare le organizzazioni in un programma ResOps?
R: Le organizzazioni dovrebbero valutare se i servizi critici possano essere ripristinati, quanto tempo richieda effettivamente il ripristino, se i punti di ripristino siano integri e verificati e se i risultati rispettino i limiti di tolleranza aziendali definiti.
D: Chi dovrebbe essere coinvolto nelle ResOps?
R: Il programma ResOps dovrebbe riunire i responsabili della sicurezza, dell’infrastruttura, della continuità operativa, delle applicazioni e dei servizi, nonché i dirigenti coinvolti, affinché le priorità e le verifiche relative a Recovery riflettano le esigenze aziendali.
D: Come può un’organizzazione avviare un programma ResOps?
R: Iniziate con uno o due servizi critici. Definite cosa si intende per Recovery riuscito, eseguite un’esercitazione di Recovery realistica, documentate i risultati e utilizzate tali dati per migliorare il test successivo.
Bill O’Connell è Chief Security Officer presso Commvault.
