Phoenix Protocol: rinascere dalle ceneri dopo un attacco informatico

Gli incidenti informatici coinvolgono avversari attivi e infezioni nascoste. Recovery deve essere prudente e verificato per evitare una reinfezione. 

È il framework di Recovery post-attacco di Commvault basato su Commvault AirGap, il ripristino isolato, un piano di Recovery informatico e i test di caos. 

Molte non pianificano né si esercitano nella Recovery. I team impreparati spesso intraprendono azioni frammentarie che diffondono l’infezione e ritardano la Recovery. 

I test di caos simulano le pressioni del mondo reale, aiutando i team a convalidare i processi e a migliorare il coordinamento prima che si verifichi un incidente reale. 

Contribuiscono a prevenire manomissioni e consentono un’analisi e un ripristino sicuri dei sistemi non infetti senza il rischio di reinfezione. 

Per la trascrizione con indicazione dei tempi, guarda il video qui

Benvenuti alla puntata odierna del podcast SHIFT, intitolata “Il Protocollo Phoenix: come risorgere dalle ceneri
dopo un attacco informatico”. 

Sono Chris Dirado e oggi con me c’è Michael Stempf. 

Michael, grazie per essere qui con me oggi, non vedo l’ora di parlare con te. 

Grazie, Chris. 

Quando si verifica un attacco informatico, Recovery può sembrare un compito arduo, ma è anche un’occasione per ricostruire
in modo più solido. 

In questa conversazione, esploreremo il Protocollo Phoenix e vedremo come i nostri quattro pilastri qui a
Commvault possano aiutarvi a rinascere dalle ceneri. 

AirGap Protect, l’ambiente di Recovery isolato, un piano di Recovery informatico e, soprattutto
, i test in condizioni di caos. 

Insieme vedremo come le organizzazioni possano trasformare questa crisi in un’opportunità
di rinnovamento e come uscire vincitori da un attacco. 

Allora, Michael, quali sono alcuni degli errori più comuni che le organizzazioni commettono durante il ripristino
dopo un attacco informatico? 

Beh, questa è una domanda a trabocchetto. 

Il problema più comune che le persone incontrano nel Recovery è che non lo pianificano finché non è necessario procedere al
Recovery. 

Bisogna essere preparati, giusto? 

L’evento principale, che ci piace chiamare “bang”, induce le persone a pensare a ciò che accade subito dopo
che si è verificato. 

Ma se non hai pianificato, se non ti sei esercitato, se non hai sviluppato quella resistenza mentale
che ti permette di rivivere la situazione più e più volte e di lavorare con i tuoi team, 

per creare un’esperienza di team building attorno a questo, non sarai preparato. 

A posteriori, ciò che abbiamo visto molte volte è che le persone cercano sinceramente di fare del loro meglio. 

Ci sarà un amministratore di Windows che vuole solo dare una mano e rimettere in
funzione i propri server, e così agirà un po’ di propria iniziativa, ricorrendo all’IT ombra e mettendo in piedi i propri 

sistemi. 

E abbiamo visto più e più volte che, quando fanno questo genere di cose, finiscono semplicemente
per infettare nuovamente un’area in cui il malintenzionato non era presente, 

e poi bisogna intervenire e occuparsene di nuovo. 

Quindi si perpetua il problema cercando di fare del proprio meglio. 

E senza quella pratica, senza testare in condizioni di caos come quelle di cui parlavi,
non riusciranno a comprendere il vero livello di complessità e sofisticazione che questi 

malintenzionati ci pongono di fronte. 

E hai sollevato un punto davvero importante riguardo alle persone che cercano semplicemente di aiutare, ma
a volte… 

sai, si lasciano prendere la mano, giusto? 

Avviando le operazioni di Recovery prima di essere effettivamente pronti a farlo. 

E so per esperienza mia e anche tua che ci siamo trovati in molti di questi scenari di Recovery
. 

A volte si lavora 60, 70, 80 ore alla settimana. 

Il momento peggiore per fare qualcosa che non porta a un buon risultato finale è quando sei già
al limite delle tue forze e stai andando a tutto gas, giusto? 

Quindi, per la mia prossima domanda, vorrei parlare di alcune delle false credenze che… 

sai, quelle per cui pensiamo di essere al sicuro, ma in realtà, sai, sono solo
illusioni e alla fine non ci aiutano davvero. 

Potresti farmi qualche esempio di queste credenze errate? 

Sì, penso che la prima e più importante sia che tutti abbiano un piano di ripristino in caso di disastri. 

Ce l’hanno da anni. 

Li hanno testati per anni. 

E gli attacchi informatici sono solo un altro tipo di disastro, o almeno così credono. 

Il problema è che nel Recovery ciò che conta sono la velocità e l’efficienza. 

Esatto. 

Che si tratti di un disastro naturale, 

un tornado, un uragano, qualunque cosa possa essere. 

E non c’è alcun intento malevolo. 

E quando si entra nel mondo del cyber, la velocità e l’intensità significano semplicemente che si finirà per reinfezionare
l’ambiente. 

Bisogna procedere con calma, bisogna essere metodici, bisogna tenere conto di quella malizia,
del malintenzionato che si trova lì dentro. 

E quindi, utilizzare un piano progettato specificamente per ripristinare l’operatività il
più rapidamente possibile causerà solo problemi. 

Quindi bisogna rallentare, prendere fiato. 

Devi avere un piano di Recovery informatico, che forse nella sua essenza riprende gran parte di ciò che è previsto nel piano
di Recovery di emergenza, ma l’obiettivo finale è: come tornare a un sistema pulito, non come tornare 

il più rapidamente possibile. 

Questo è davvero l’aspetto principale. 

Ma ci sono così tanti altri aspetti che ne derivano. 

Sapete, prima di tutto, ho effettivamente visto distruggere praticamente tutto ciò che si potesse immaginare in un
attacco informatico. 

E uno dei fattori che lo rendono possibile è che oggi tutti hanno 

oggi tutto collegato a un sistema di gestione delle identità, ad esempio Active Directory. 

Le ultime statistiche su Active Directory indicano che è presente nel 98% di tutte le aziende ed è oggetto del
92% di tutti gli attacchi informatici. 

È ovvio, no? 

Una volta entrati in Active Directory, si può accedere ovunque. 

È la chiave del regno. 

Quindi una delle cose che consiglio sempre è di… ehm… rafforzare la vostra ultima linea di difesa, separare
il vostro sistema di protezione dei dati da Active Directory, 

perché una delle mosse più comuni dei malintenzionati, sapendo che se il sistema di protezione
dei dati resiste all’attacco, è probabile che non pagherete. 

È così che si evita di pagare. 

Assolutamente. 

Una delle cose che consigliamo è di estrarre il sistema di protezione dei dati da Active Directory, renderlo
autonomo, separarlo e isolarlo il più possibile. 

In questo modo, per quanta parte della vostra azienda venga distrutta, quella parte continuerà comunque a sopravvivere. 

Una breve nota: Michael ha sollevato un 

buona osservazione riguardo a un piano di Recovery informatico. 

In alcune delle sessioni che ho tenuto, ho scoperto che molte persone non disponevano di piani di Recovery
informatico. 

Beh, in Commvault abbiamo la soluzione che fa per voi. 

Se accedete alla nostra piattaforma di Readiness e cercate un piano di Recovery informatico, potete scaricare
il nostro modello e personalizzarlo in base alle vostre esigenze. 

E come ha detto Michael, alcuni elementi saranno già presenti nel vostro piano di DR. 

Prendete pure in prestito quegli elementi, va bene? 

Copiate e incollate. 

Ma avere un piano di Recovery informatico è proprio ciò che vi aiuterà a cavarvela una volta che vi troverete
in uno di questi scenari. 

Michael, in che modo sono cambiate le aspettative di Recovery, passando dal semplice recupero dei dati al ripristino dell’attività
aziendale? 

Ottima domanda. 

Sai, la maggior parte delle persone pianifica ripristini di tipo “una Z” o “due Z”. 

Ho un paio di file qui. 

Ho un server qui. 

E puoi pianificarlo, giusto? 

È una questione molto matematica, vero? 

Per un D.R. 

Ho un piano. 

Ho un server. 

Ho un edificio. 

Devo sapere quanti dati ci sono, quanta larghezza di banda ho a disposizione per la 

sede, una sede geograficamente dispersa, e posso simulare scenari su questo tutto il giorno. 

Il problema di un evento informatico è che non ne conosco la portata, giusto? 

Quanti server sono stati colpiti in questa organizzazione? 

Quante sedi sono state colpite? 

Ho avuto un cliente che è stato colpito. 

Avevano 99 sedi in tutto il mondo e il malintenzionato le ha distrutte tutte. 

Quindi ogni copia dei dati che possedevano, ovunque si trovasse, è stata completamente distrutta. 

Analizzare la situazione, progettare le contromisure, testarle e metterle in pratica sono davvero alcune delle
cose più importanti in questo contesto, quindi devi assicurarti di affrontarla in modo diverso 

che la si guardi in modo diverso e che i risultati saranno sempre diversi. 

E qui hai sollevato un punto davvero importante. 

Esistono tre tipi distinti di operazioni di Recovery che pianifichiamo correttamente: 

Recovery operativo, recupero in caso di disastri e recupero informatico. 

Puoi spiegarci un po’ di più su ciascuna di queste, in che modo si differenziano e in che
modo 

impedisce effettivamente ai clienti di non riuscire a riprendersi in caso di evento informatico? 

Certo. 

Il Recovery operativo è quello tipico: ho cancellato un file, ne hai una copia locale da cui
puoi ripristinarlo, è velocissimo, facile da eseguire, automatizzato nella maggior parte dei casi; basta semplicemente 

e… 

Stavo per dire che qui a Commvault abbiamo tutti la possibilità di eseguire autonomamente le Recovery sui
nostri portatili. 

Sono sicuro che nella maggior parte delle organizzazioni sia semplice, giusto? 

Una procedura semplice. 

Assolutamente. 

Il Recovery, in caso di disastri naturali, 

ed è molto avanzato. 

Lo facciamo da oltre 30 anni, testandolo trimestralmente nella maggior parte delle sedi. 

In effetti, l’abbiamo fatto così tante volte che la gente si è adagiata sul DR. 

In realtà non lo testano più. 

Quello che fanno di solito ora è spostare il loro data center da una sede all’altra
ogni sei mesi e dire: «Ehi, siamo in produzione». 

È un buon test. 

Ma poi, con quest’ultimo aspetto, quello relativo alla sicurezza informatica, sono necessarie alcune misure specifiche. 

La prima, e credo la più importante, è una copia terziaria dei dati. 

Una terza copia dei dati che si trovi all’interno dell’infrastruttura di qualcun altro perché, come sapete, i
malintenzionati avranno accesso ad AD, avranno il controllo dell’intero ambiente, 

avranno tutte le tue credenziali cloud. 

Quindi, avere solo quella seconda copia dei dati, che normalmente si distribuirebbe
geograficamente, non è una protezione sufficiente. 

Dovete quindi assicurarvi che si trovi all’interno dell’infrastruttura di qualcun altro, che sia
immutabile e indelebile. 

Il fatto che sia indelebile garantisce quella governance necessaria per assicurarsi che 

nessuno, nemmeno chi possiede credenziali con privilegi elevati ottenute da AD, possa modificare
o cancellare quei dati. 

Sono quei dati che ci salveranno una volta che saremo sotto attacco. 

Sappiamo che saranno lì quando serviranno, perché non possono essere cancellati come hai detto tu, non possono
essere modificati e devono soddisfare requisiti rigorosi. 

E poi, affinché un malintenzionato possa impossessarsene, non dovrebbe solo violare la tua
organizzazione, ma dovrebbe violare anche la nostra, giusto? 

Quindi si tratterebbe davvero di un attacco su due fronti che dovrebbe riuscire a portare a termine. 

Quindi, detto questo… 

sappiamo di poter disporre di una copia dei dati sicura e protetta. 

Dove dovremmo ripristinare quei dati in caso di attacco informatico? 

Questo è il punto a cui nessuno pensa mai, giusto? 

Circa il 17% di tutti gli attacchi sono attacchi distruttivi, in cui gli hacker penetrano nel firmware e
nel BIOS dei server, e non è possibile ripristinarli. 

Ma questo fa parte del piano di tutti. 

Tornerò esattamente al punto di partenza. 

E al giorno d’oggi, anche se quel 17% è una percentuale piuttosto bassa, la maggior parte dei CISO 

dato che non si sa se si è trattato di un attacco distruttivo, ragionano così: “Devo presumere che sia
distruttivo”. 

Quindi la maggior parte delle aziende non dispone di un piano che preveda 50 server pronti all’uso nel proprio magazzino.
 

E quindi, nell’ambiente odierno, è necessario disporre di un ambiente di Recovery isolato. 

In primo luogo, è un luogo sicuro in cui posso effettuare il ripristino e, in secondo luogo, è un luogo che posso promuovere
in produzione e in cui so che il malintenzionato non è presente. 

Pertanto, come una di quelle aree chiave di cui parlavi prima, 

un ambiente di Recovery isolato, che noi chiamiamo “clean room”, è essenziale per la resilienza informatica
. 

Certo, quindi ora abbiamo una buona base: sappiamo di avere copie dei nostri dati, al sicuro e protette, e ora
abbiamo un luogo in cui possiamo trasferire quei dati e, come hai sottolineato prima, possiamo ripulire 

e ripulirli prima di trasferirli in produzione. 

E una delle caratteristiche che, secondo me, qui a Commvault non riceve abbastanza attenzione è la nostra
portabilità “any-to-any”, giusto? 

Perché, come hai detto, potresti subire un attacco distruttivo in locale; a quel punto devi cambiare
strategia, giusto? 

Devi… 

bisogna andare da qualche altra parte; quanto tempo ci vuole per procurarsi nuovo hardware? 

Forse sei settimane? 

Non puoi restare fermo per sei settimane senza server di produzione. 

Puoi spostare i tuoi carichi di lavoro sul tuo fornitore di cloud preferito o su un hypervisor diverso, e
questo ti offre davvero la flessibilità necessaria per riprenderti dopo uno di questi attacchi. 

In realtà, uno dei punti di forza di
Commvault rispetto ai concorrenti, di cui non si parla mai, è il fatto che da anni offriamo soluzioni “any-to-any”. 

Quindi, se voleste… 

avere un ambiente VMware on-premise e poi trasferirlo su un ambiente AWS EC2, il tutto
avviene in modo automatico. 

Succede durante il ripristino, non devo preoccuparmi di nulla. 

E la gamma di variabili “da qualsiasi piattaforma a
qualsiasi altra” che offriamo, da una piattaforma all’altra, è assolutamente incredibile e supera di gran lunga qualsiasi altro operatore del settore. 

Sì, offriamo davvero ai nostri clienti tutte le opzioni che potrebbero mai desiderare, giusto, quando si
tratta di questo? 

Assolutamente. 

Va bene, allora cambiamo argomento. 

Quali sono le sfide che riscontri più frequentemente in questo momento con questi attacchi informatici? 

La prima è la mancanza di preparazione. 

Si tratta di affrontarlo come se fosse un disastro. 

Quando si parla di Recovery di emergenza e di come riprendersi da un evento del genere, in genere si ha
un amministratore addetto ai backup, giusto? 

E questa persona, in quel caso, 

io li chiamo sempre così: sono considerati una sorta di divinità, giusto? 

Quando si arriva alla fase del Recovery, è come se si dicesse: «Non avvicinatevi a questa persona,
state alla larga, limitatevi a portarle da mangiare e da bere ogni tanto e lasciatela fare», 

perché ha elaborato il piano da sempre. 

Ed era tutta una sua responsabilità. 

Il problema è che quella persona non ha praticamente alcuna responsabilità in caso di attacco informatico. 

Non può semplicemente iniziare a ripristinare i sistemi perché innescherebbe una fase di reinfezione. 

Bisogna collaborare con i team di sicurezza, quelli IT, l’ufficio legale e i team di comunicazione:
tutte queste persone devono lavorare insieme, ma non l’hanno mai fatto prima. 

E mi piace sempre scherzare dicendo che probabilmente l’ultima volta che il team di sicurezza e quello
IT si sono riuniti è stato quando hanno giocato l’uno contro l’altro in una partita di baseball durante un 

evento. 

Sono sempre l’uno contro l’altro, mai nella stessa squadra. 

Ma quando si verifica un incidente informatico, se io sono il responsabile di backup, io… 

non ho l’autorità per eseguire una Recovery finché qualcuno del reparto di sicurezza non mi dice di
farlo. 

E il personale addetto alla sicurezza non può fare ciò che deve fare finché qualcuno del reparto IT non
interviene. 

Quindi si tratta di questo principio di controlli e contrappesi, che è un concetto del tutto estraneo a qualsiasi Recovery dati
prima degli incidenti informatici. 

Sì, e sai, la cosa che mi fa ridere è che, pensa all’ultima volta che hai interagito
con un amministratore di backup, giusto? 

Probabilmente è stato: “Ehi, ho perso un’e-mail o un foglio di calcolo”, e cosa hanno fatto? 

L’ha ripristinato in pochi minuti, giusto? 

Ora, per tornare al tuo punto, non possono farlo. 

Non possono farlo perché non sai cosa sia stato compromesso. 

Non sai se hanno colpito una dozzina di server, se hanno colpito l’intera farm ESX, e non puoi
semplicemente iniziare a ripristinare le cose perché questo ti riporterebbe esattamente al punto di partenza. 

Deve davvero essere un lavoro di squadra, giusto? 

Alla fine tutti devono unirsi, lavorare insieme, collaborare per rimettere in piedi l’organizzazione
. 

Sono d’accordo. 

Quali sono quindi alcune delle lezioni più importanti che le organizzazioni hanno imparato dopo aver subito un
attacco informatico? 

Le lezioni apprese variano. 

Sono di ogni tipo. 

Penso che la cosa più importante sia, e in genere si capisce dopo il secondo attacco (
è molto comune subire fino a quattro attacchi all’anno circa), che non si tratta di qualcosa di veramente pianificabile. 

Non si riescono a prevedere scenari che si verifichino esattamente come li si
immagina quando si verifica quell’evento informatico. 

Ci sono tantissime variabili diverse. 

Il punto è questo: nel disaster recovery, è molto facile pianificare le misure da adottare in caso di tornado. 

Un tornado probabilmente distruggerà un edificio. 

Un’alluvione può distruggere… 

forse i piani inferiori di un edificio, ma è pianificabile, è simulabile, posso intervenire e farlo
. 

Nel caso degli attacchi informatici, ci sono tantissimi modi diversi in cui possono attaccare. 

Tanti modi diversi in cui possono entrare, tanti modi in cui possono distruggere le informazioni. 

Diamine, al giorno d’oggi non si tratta nemmeno più tanto di ransomware, giusto? 

Ci sono attacchi che avvengono semplicemente perché qualcuno vuole eliminare un concorrente, o perché un
governo vuole eliminare un altro governo. 

Si tratta semplicemente di puro intento malevolo senza alcun ritorno economico, se non quello di distruggere
il proprio nemico. 

È difficile prepararsi a questo. 

Certo. 

E quindi quello che dobbiamo fare è davvero applicare quella teoria del caos quando effettuiamo i nostri test. 

Una delle cose che mi piace sempre fare quando mi avvio a questi test è che loro
hanno sempre un elenco predefinito di ciò che è stato attaccato, giusto? 

Sanno sempre esattamente quali server sono coinvolti e, cosa positiva, alle riunioni con noi sono sempre presenti tutti i
responsabili di quei server. 

Assolutamente. 

E una delle cose che mi piace sempre fare è scrivere i nomi dei server sul retro
delle carte da gioco, 

poi le lancio contro il muro e quelle che cadono a faccia in su sono proprio quelle
che sono state colpite. 

Quindi questo è un ottimo modo per introdurre qui la metodologia del caos in modo da poter effettuare i test. 

E una volta che avete effettuato i test in tanti modi caotici diversi, non dirò che siete
preparati a quell’attacco, ma avete un’idea e una comprensione di quale sarà l’impatto 

e di come potrete riprendervi al meglio. 

Sì, e conosci il tuo punto di svolta, giusto? 

Ehi, se so che se succede X, passerò a Y, giusto? 

Se so che se faccio Y e non funziona, passerò a Z. 

E penso che non si possa essere preparati a tutti questi scenari, ma più si è
preparati quando questo accade davvero, più si tratta di quella memoria muscolare, giusto? 

Del tipo: «Ehi, so che saremo in grado di farlo perché mi sono preparato, mi sono
preparato per tutte queste situazioni». 

So che qualche anno fa l’FBI diceva: “Ehi, se subisci un attacco informatico,
devi seguire questa serie di procedure”. 

E poi, un anno dopo, hanno cambiato il messaggio in: 

quando subisci un attacco informatico, devi fare questo. 

E quest’anno dicono: “Considerando quante volte sarete colpiti da un attacco informatico
, dovete essere pronti, dovete essere preparati”. 

Puoi dirci qualcosa di più su come si concretizza questa preparazione? 

Sì, quindi è una cosa frequente, e per questo penso che la cosa più importante nella preparazione sia cambiare
la propria mentalità. 

E la mentalità non cambia in base a “se”, “quando” o “con quale frequenza”, ma consiste piuttosto nel dover
partire dal presupposto di essere già stati violati. 

Sai, ci piace sempre scherzare dicendo che al mondo esistono due tipi di aziende. 

Quelle che sanno di aver subito una violazione e quelle che non sanno di averla subita. 

E anche se questo non è del tutto vero, voglio dire, siamo onesti, l’anno scorso in America solo il 60% delle aziende ha subito
una violazione, giusto? 

Quindi avevate una possibilità, avevate il 40% di probabilità di non aver subito una violazione, ma quello era solo un
anno. 

Sì, che fortuna. 

Ma se adotti la mentalità di partire dal presupposto che ci sia stata una violazione, 

quando domani andrò al lavoro, prenderò decisioni diverse. 

Guarderei le cose in modo diverso, le analizzerei in modo diverso e, si spera, darei
il via a quell’esperienza di team building, coinvolgendo l’IT e l’ufficio legale e 

discutendo di cose di cui normalmente non avrei parlato con loro. 

Quindi, sai, è curioso, hai detto che il 60% delle organizzazioni ha subito una violazione. 

Il punto è questo: l’altro giorno ho letto una statistica secondo cui nel 2025 si verificherà un attacco informatico ogni
14 secondi. 

Quel numero mi sembra pazzesco. 

Un altro dato davvero sbalorditivo è che si prevede che il crimine informatico raggiunga i 10,5
trilioni di dollari quest’anno. 

Quindi, anche se si trattasse solo del 60% delle organizzazioni negli Stati Uniti, non si arriva
a 10 trilioni di dollari senza prendere di mira tutti, giusto? 

Non è che prendano di mira solo l’1% delle grandi aziende, giusto? 

Prendono di mira tutti. 

Per mettere le cose in prospettiva, 10.000 miliardi di dollari: se lo si considerasse dal punto di vista del PIL dei
paesi di tutto il mondo, sarebbe il terzo paese più grande del mondo. 

È incredibile. 

Il crimine informatico: il terzo paese più grande del mondo. 

È incredibile. 

Ok, penso sia ora di cambiare argomento, giusto? 

Abbiamo parlato molto degli aspetti negativi e delle difficoltà. 

Parliamo di come ridurre questa tempistica di 24 giorni. 

Parliamo di cosa possono fare i clienti non solo per riprendersi da questi attacchi, ma anche per reagire
e magari uscirne addirittura più forti. 

Li chiamiamo i nostri quattro pilastri. 

È molto importante. 

Quindi, prima di tutto, è necessario disporre di una copia terziaria dei dati ospitata sull’infrastruttura di
un altro soggetto. 

Ora si dispone di una copia valida e pulita, immutabile e indelebile. 

È necessario disporre di un luogo in cui ripristinarla, ovvero un ambiente di Recovery isolato. 

Noi chiamiamo il nostro “clean room”. 

Questo vi permette di, ehm, effettuare i test, che sono la priorità assoluta. 

Non riusciremo a ridurre i 24 giorni, nemmeno applicando questi metodi, se non effettuiamo i
test con essi. 

Quindi devi avere un luogo dove andare a testare, perché non puoi interrompere la produzione. 

Lì si possono anche effettuare analisi forensi. 

Spesso, ad esempio, non si è nemmeno sotto attacco, ma si introduce un nuovo
strumento di sicurezza informatica e si vuole testarlo all’interno della propria organizzazione. 

Non si vuole semplicemente rilasciare del malware all’interno dell’organizzazione per vedere se lo rileva. 

E non si vuole nemmeno andare in un ambiente sterile che non assomigli in alcun
modo alla propria produzione. 

Quindi, con Commvault Cleanroom, posso ripristinare il mio ambiente in una posizione sicura, 

e posso rilasciare un malware al suo interno per verificare l’efficacia di quella soluzione di sicurezza informatica. 

D’altra parte, se venite colpiti – come mi è capitato una volta in cui non si è trattato di un
attacco distruttivo – una volta ottenuto il via libera, potremmo procedere al ripristino dei dati, ma il governo degli 

Stati Uniti è intervenuto dicendo: “Non potete ripristinare i dati in questo momento”. 

Non avevamo mai visto questo malintenzionato né questo tipo di attacco. 

Quindi volevano condurre la propria analisi forense. 

Una domanda veloce: qual era il loro SLA in quel caso? 

Sì, hanno superato di gran lunga il… 

Sì, certo, giusto? 

Non c’è alcuno SLA quando è il governo a occuparsene. 

No, per niente. 

Ci sono volute due settimane. 

Due settimane perché il governo facesse le sue ricerche. 

Quindi non sarebbe stato fantastico se avessi avuto Commvault Cleanroom e avessi potuto ripristinare
quelle macchine in quell’ambiente e dire: «Ehi, prendetevi tutto il tempo che vi serve. 

“Procedete pure con le vostre valutazioni, chiaritevi le idee. 

Noi torniamo al lavoro». 

Sì, fantastico. 

Davvero fantastico. 

Quindi, ho dei dati validi. 

Ho un ambiente pulito dove posso trasferire i dati. 

La prossima cosa, e la più importante, è il piano di Recovery informatico, di cui abbiamo già parlato, il che
è fantastico. 

Descriverà tutto nei dettagli, ma ci sono alcuni elementi che devono essere inclusi in quel piano di Recovery informatico
che, di per sé, sono molto difficili da ottenere. 

Quindi si tratta di un’analisi completa della mappatura di tutte le vostre applicazioni. 

Se devo ripristinare solo un paio di file da un file server, non mi interessa particolarmente. 

Se devo ripristinare, diciamo, Epic per un ambiente sanitario, e ci sono 32
server diversi che interagiscono tra loro, 

devo ripristinarli tutti. 

Devo ripristinarli tutti in uno stato coerente. 

E spero che abbiate effettuato l’analisi per scoprirlo, per realizzare la mappatura delle applicazioni. 

Esistono alcuni strumenti che ti aiutano a farlo, ma, ad essere onesti, è un processo molto difficile
. 

Sì, come fai a capire che 32 server alimentano una macchina, giusto? 

E la maggior parte delle persone dice: “Beh, lo sappiamo perché stiamo per ripristinare i nostri server di primo
livello”. 

Beh, il problema è che un server di livello uno funziona solo se si dispone di un gruppo di server di livello tre
e quattro che gli forniscono effettivamente i dati, 

di cui ha bisogno. 

E quindi l’unico modo per farlo è con questo quarto passo, ovvero il test con il caos. 

Devo entrare nella camera bianca. 

Devo assicurarmi di eseguire le Recovery, renderle casuali, vedere cosa succede, vedere cosa funziona
e cosa non funziona dopo quella casualizzazione. 

Va bene, forse sono state colpite solo 32 macchine, ma dovrò ripristinarne 142
a causa di tutte le dipendenze presenti. 

Queste sono davvero le quattro cose fondamentali: l’air gap, la camera bianca o l’ambiente di Recovery
isolato, 

un piano di recupero informatico e infine testare tutto ciò, perché un piano di recupero informatico è solo un
pezzo di carta finché non lo si mette effettivamente alla prova. 

Assolutamente, giusto. 

È solo un documento finché non lo si mette alla prova. 

E alcuni dei test che consiglierei sono quelli che i clienti dovrebbero fare, ad esempio esercitazioni teoriche
: riunirsi in una sala riunioni e discutere di cosa succederebbe se fossimo colpiti da un ransomware, e 

faremo per prima, seconda e terza cosa? 

Quando dovremo addirittura attivare il nostro piano di Recovery informatico? 

Ma io farei anche un passo in più, giusto? 

In realtà bisognerebbe effettuare un’esercitazione pratica di Recovery informatico. 

Assolutamente. 

Ehi, ho questo strumento chiamato AirGap Protect, ho questo strumento chiamato Cleanroom, ora
mettiamoli alla prova: la prova sta nei fatti, giusto? 

Assicuriamoci di poter ripristinare questi carichi di lavoro da questa copia terziaria dei dati in Cleanroom, perché quella
è la vera prova, giusto? 

Posso rimettere in piedi la mia azienda. 

E questo mi porta alla mia prossima domanda: come fanno le aziende a determinare cosa ripristineranno
per secondo e terzo? 

Ho sentito usare spesso questo termine, “minima fattibilità”. 

Immagino che sia diverso per ogni organizzazione. 

Come si inserisce questo concetto nei quattro pilastri? 

È diverso per ogni organizzazione, giusto, a seconda del settore in cui si
opera. 

E l’unico modo per scoprirlo è attraverso la sperimentazione. 

Senza di essi, non si può sapere. 

Molto spesso le persone pensano di capire cosa debba andare dove e come. 

E senza quella fase di test, che abbiamo condotto per anni nell’ambito del Disaster Recovery, quindi il
processo ce l’abbiamo. 

Semplicemente non l’abbiamo applicato. 

Voglio dire, ecco la cosa assurda. 

Per anni, 30 anni, abbiamo effettuato test trimestrali per il ripristino di emergenza e i piani di ripristino di emergenza
, eppure meno dell’1% di tutte le aziende mai esistite ha mai dichiarato un 

disastro e, come abbiamo detto prima, il 60% di tutte le aziende americane ha subito una violazione dei dati l’anno
scorso e nessuno sta effettuando test in merito. 

Nessuno effettua test perché è una questione complessa, giusto? 

Ci vuole un dottorato di ricerca per capire la differenza tra cyber-recupero e Recovery di emergenza, cosa che oggi chiunque è
in grado di fare. 

Certo. 

Sì, ed è quasi come dire: “Ehi, come faccio a sapere cosa sto testando in un evento di cyber-Recovery
?”, giusto? 

E penso che, sapete, i nostri clienti qui a Commvault siano davvero fortunati. 

Abbiamo appena lanciato questo nuovo servizio, il servizio Guardian, e, ehi, capiamo bene che non si tratta di qualcosa
che si ottiene dall’oggi al domani, giusto? 

Se volessimo essere resilienti alle minacce informatiche già domani, lo saremmo, ma non è così semplice,
vero? 

È un percorso. 

Ci vuole tempo. 

In molti casi, molto spesso avrete bisogno di aiuto. 

E penso che questo nuovo servizio sia pensato proprio per aiutare i clienti 

a compiere il passo successivo nel loro percorso verso la resilienza informatica. 

Beh, e grazie al nostro “readi verse”, dato che molte persone non sanno come condurre correttamente un’esercitazione
teorica, ora disponiamo di un percorso sia esecutivo che tecnico per 

simulazione di eventi informatici. 

Ma, come hai detto tu, questo è solo il primo passo. 

Ora bisogna metterlo in pratica sul serio. 

In ambito militare, lo chiamavamo ciclo OODA: Osservare, Orientarsi, Decidere e Agire. 

Si tratta di un ciclo che si ripete, 

in cui si prova costantemente qualcosa, la si valuta, la si modifica e la si prova di nuovo. 

In questo modo si è più preparati quando succede davvero qualcosa. 

Beh, hai attraversato così tanti cicli di prove, modifiche e modi di fare le cose
che per te è quasi solo un’altra prova. 

Certo. 

Ed è così che si riesce davvero a risollevarsi, giusto? 

Quindi con questi quattro pilastri: la protezione tramite air gap, la camera bianca, il piano di Recovery informatico e poi i test in condizioni di caos,
giusto? 

E noi… 

ci allineiamo perfettamente a questi, come hai detto tu. 

Abbiamo copie sicure e protette dei nostri dati. 

Abbiamo il luogo in cui i nostri dati vengono ripristinati. 

Diamine, se hai bisogno di un piano di Recovery informatico, scaricalo da Readiverse, come ho
detto, e adattalo alle tue esigenze. 

E infine, ma non meno importante, se hai bisogno di aiuto lungo il percorso, ci pensiamo
noi con il Guardian Service. 

Michael, grazie per il tempo che ci hai dedicato oggi. 

È stato davvero illuminante. 

Grazie, Chris. 

E con questo si conclude la nostra conversazione sul Phoenix Protocol e su come i quattro
pilastri della resilienza informatica di Commvault aiutino davvero i clienti a rinascere dalle ceneri dopo un 

attacco informatico.