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 lontane tutte le minacce.
- Trasformate i piani di Recovery in dati concreti: i risultati verificati 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 i responsabili della sicurezza, dell’infrastruttura, della continuità operativa e 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 bloccare è 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 ci siamo ripresi.
- Ecco perché voglio che ogni CISO, CIO e membro del consiglio di amministrazione che conosco legga questo nuovo libro, *ResOps: An Executive Guide*. È 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 il vostro consiglio di amministrazione sta ponendo.
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 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, bensì 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’esercizio stesso è fonte di fiducia.
Tre domande che pongo al mio team
Il libro articola l’intero problema in tre domande, e ho iniziato ad aprire ogni revisione della 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 presentando un piano, mentre alla terza risponde con il silenzio. Quel silenzio rappresenta il divario di resilienza, ed è più ampio e costoso di quanto la maggior parte dei dirigenti si renda conto.
Prove, non promesse
Ecco una distinzione che il libro illustra meglio di quanto io abbia mai sentito fare altrove: un obiettivo di tempo di ripristino (RTO) è un traguardo. Indica ciò a cui si mira, ma non dice se lo si raggiungerà.
Confrontate «riteniamo di poter ripristinare il servizio di pagamenti in quattro ore» con «lo abbiamo ripristinato in 3,2 ore lo scorso trimestre, partendo 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, l’autorità di regolamentazione o la vostra compagnia di assicurazione contro i rischi informatici inizieranno a porre domande più incisive, cosa che sicuramente faranno.
Chiamiamo questa disciplina ResOps, abbreviazione di «resilience operations» (operazioni di resilienza). Non è un prodotto che si acquista né un fascicolo 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 concrete anziché di piani separati.
L’aspetto che dovrebbe preoccupare ogni CISO
Il libro 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 scoperta e sfruttamento con la stessa rapidità, forse anche più velocemente. Individuare più problemi non vi rende più sicuri se non riuscite a riprendervi da quelli che riescono a sfilarvi di mano. La velocità di rilevamento non è mai stata il traguardo. 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 fatto tutto bene al primo tentativo. Il libro 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 esercizio di Recovery onesto 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 libro vi indica un percorso concreto.
Acquistate qui la vostra copia di “ResOps: An Executive Guide”.
Domande frequenti
D: Che cos’è ResOps?
R: ResOps, abbreviazione di “resilience operations”, è un modello operativo che mette in collegamento sicurezza, infrastruttura, continuità operativa e responsabili 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à interfunzionale e sulla prova misurabile che i servizi critici possano essere ripristinati entro i limiti di tolleranza aziendali.
D: Perché le prove di Recovery sono importanti?
R: Le prove di Recovery mostrano 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 misurare se i servizi critici possono essere ripristinati, quanto tempo richiede effettivamente il ripristino, se i punti di ripristino sono integri e verificati e se i risultati soddisfano le tolleranze aziendali definite.
D: Chi dovrebbe essere coinvolto in ResOps?
R: Il ResOps dovrebbe riunire i responsabili della sicurezza, dell’infrastruttura, della continuità operativa, delle applicazioni e dei servizi, nonché i dirigenti interessati, in modo che le priorità e le prove 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 evidenze per migliorare il test successivo.
Bill O’Connell è Chief Security Officer presso Commvault.
