Presentazione dell’MTCR: l’indicatore mancante per il successo della Recovery nel cyber space

L’MTCR misura il tempo necessario per ripristinare i sistemi e i dati in modo pulito — senza malware, danni o tracce residue — a seguito di un attacco informatico. 

RTO e RPO misurano il tempo e la perdita di dati. L’MTCR misura l’affidabilità. Un Recovery rapido non ha senso se le minacce permangono. 

Ciò richiede la verifica dei backup,alla ricerca di minacce nascoste e convalida dei carichi di lavoro ripristinati: un processo è ben più complesso di un semplice failover. 

Gli autori degli attacchi compromettono sempre più spesso i backup e nascondono le tracce della loro presenza, rendendo l’identificazione dei dati integri la fase più lunga del processo di Recovery. 

Fornisce ai leader un indicatore realistico della qualità della Recovery, consentendo investimenti e preparativi più oculati. 

Per la trascrizione con l’indicazione dei tempi, guarda il videoqui

Benvenuti alla nostra discussione su un nuovo modo di concepire la resilienza informatica: il Mean Time to Clean
Recovery, o MTCR.

Al mio fianco ci sono due esperti che hanno ideato questo concetto di MTCR: Darren Thomson, CTO sul campo presso
Commvault, che collabora a stretto contatto con organizzazioni di diversi settori in materia di resilienza e

strategie, e Duncan Bradley, responsabile del settore sicurezza e resilienza per il Regno Unito e l’Irlanda presso Kyndryl
. Sono stati proprio loro a redigere il documento originale di leadership di pensiero sull’MTCR. E

Da anni, il successo della Recovery nelle organizzazioni viene misurato in base alla rapidità con cui i sistemi possono essere
ripristinati.

Utilizziamo acronimi come RTO e RPO: RTO (Recovery Time Objective, obiettivo di tempo di ripristino) e RPO (Recovery Point
Obiettivo (punto di ripristino).

Ma nell’attuale panorama delle minacce, sappiamo che la velocità da sola non equivale alla sicurezza e non equivale
al successo del Recovery.

Se i dati recuperati non sono puliti e affidabili, si rischia di trasformare la Recovery nella
a seguito di un altro attacco.

Ciao.

Sono Danielle Sheer, Chief Trust Officer di Commvault.

Dedico gran parte del mio tempo ad aiutare i consigli di amministrazione e i dirigenti a comprendere in che modo il rischio informatico si intersechi
con il rischio aziendale.

Sono davvero entusiasta di moderare la discussione di oggi e di spiegare perché questo nuovo concetto, l’MTCR,
non è solo un’altra metrica tecnica, ma lo standard aziendale che ora deve trovare spazio nella

sala del consiglio.

Proviamo a farlo.

Sì, grazie Danielle.

E grazie per l’ottima introduzione.

Proprio quest’anno, nel 2025, in particolare nel Regno Unito, ma in realtà in tutto il mondo,
Soprattutto in Europa, abbiamo assistito ad alcuni attacchi mirati al settore del commercio al dettaglio.

E abbiamo visto con i nostri occhi quanto sia stato difficile per quei rivenditori mantenere i contatti
con i propri clienti e, soprattutto, ripristinare i propri sistemi.

Quest’anno sono stato coinvolto personalmente in un attacco mirato iniziato verso la metà di
aprile del 2025.

E solo per darvi un’idea dei tempi necessari a quell’azienda
per riprendersi.

Nel mese di aprile si è verificato essenzialmente un attacco ransomware.

E in quel periodo l’azienda ha svolto un ottimo lavoro, se non nel fermare l’evento
, almeno per isolarlo e bloccarne la diffusione.

Nel mese di maggio, l’azienda si è concentrata sul tentativo di confermare la natura e la portata, ciò che io
chiamiamo il “raggio d’azione” dell’attacco.

E hanno iniziato a comunicare con l’esterno.

Da maggio fino all’inizio di agosto si è svolta la vera e propria fase di Recovery dei sistemi.

In altre parole, ci sono voluti quasi tre mesi, fino ad agosto, per
un ripristino graduale dei sistemi.

Allora, perché ci è voluto tutto quel tempo, cioè tre mesi, per rimettere in funzione l’azienda?
?

Beh, gran parte di quel tempo è stata dedicata al tentativo di trovare dati corretti e puliti.

Sistemi puliti su cui l’azienda potesse fare affidamento per tornare a interagire con i propri
clienti e generare ricavi in qualità di rivenditore.

Ed è proprio questo, quel periodo di tre mesi, a essere indicativo di ciò di cui vogliamo parlare
qui.

L’azienda deve iniziare a porre una serie diversa di domande all’organizzazione
IT per arrivare a un punto in cui non solo si possano fare promesse sulla rapidità con cui

ripristiniamo i sistemi,

ma si possa anche cominciare a fare promesse su quanto quei sistemi saranno puliti, su quanto sarà pulita
la loro natura.

Altrimenti, temo che continueremo a constatare, come sappiamo, che in genere ci vogliono due, tre,
a volte addirittura quattro o cinque mesi per ripristinare il funzionamento dei sistemi.

Sapete, ok, è affascinante.

Ci hai fornito molti spunti su cui lavorare.

Duncan, ora vorrei tornare all’inizio.

Puoi darci la definizione di MTCR?

Spiegaci i cinque pilastri e perché questa è la strada giusta da seguire, in questo
panorama, in questo panorama delle minacce, per valutare il successo del piano di Recovery.

Sì, certo, Danielle.

Credo che sia davvero importante.

Abbiamo ideato il concetto di “Mean Time to Clean Recovery” proprio per creare un indicatore
aziendale comprensibile per l’azienda.

Si tratta del tempo che impiegano a tornare operativi, come diceva Darren.

Con dati puliti e sistemi in grado di funzionare e riprendere la produzione.

La maggior parte delle organizzazioni si è concentrata principalmente sulla disponibilità dei propri sistemi online, senza comprendere che questi attacchi informatici rendono inutilizzabili
i dati e le piattaforme

che supportano tali operazioni.

Pertanto, quando si verifica un evento di Recovery, si tratta piuttosto di dover ricominciare da capo
da zero per tornare al punto di Recovery,

un ambiente pulito.

Spesso ciò richiede giorni, come diceva Darren nell’esempio relativo al settore del commercio al dettaglio.

A quel punto è necessario ripristinare tutti i servizi essenziali.

Successivamente, è necessario ripristinare il funzionamento delle piattaforme e recuperare i dati
integri al loro interno.

E molto spesso, considerando il tipo di attacchi a cui assistiamo, i dati risultano già compromessi da
giorni, se non settimane, prima dell’attacco.

È quindi necessario esaminare i backup e riportare quei dati puliti in produzione.

Questo MTCR, ovvero il “Mean Time to Clean Recovery” (tempo medio per il ripristino pulito), è concepito come un indicatore aziendale per rispondere alla domanda:

Per quanto tempo potete rimanere fuori servizio?

Per quanto tempo si rimarrebbe fuori servizio oggi se si verificasse l’evento?

E questo dato viene poi utilizzato per spronare i reparti IT e di controllo di qualità a ridurre i tempi
tramite Recovery.

In che modo l’MTCR si differenzia dalle misure tradizionali?

Sembra quasi che riunisca molte delle misure tradizionali in un unico indicatore più ampio.

Beh, credo che sia proprio qui che entrano in gioco gli obiettivi relativi ai tempi di ripristino (RTO).

Quanto tempo ci vuole per ripristinare il funzionamento di quel sistema?

Non tiene conto del tipo di dati che saranno presenti all’interno di quella piattaforma.

Sai, in genere si usa la disponibilità come parametro.

Quanto tempo mi occorre per eseguire il failover dal data center A al data center B in caso di un
un attacco tradizionale all’infrastruttura?

Il recupero dei dati è un’impresa molto più complicata.

Non si tratta solo di recuperare un insieme di dati.

Si tratta di ripristinare il funzionamento della piattaforma online.

Quindi, se si pensa ai servizi di identità, è necessario che l’identità funzioni prima che chiunque possa
accedere ai dati.

Il semplice fatto di misurare il tempo necessario per ripristinare un database

Ciò non significa che quel processo aziendale tornerà a funzionare online.

Ed è stato davvero progettato per riunire quei diversi pilastri dei sistemi che costituiscono
È necessario ripristinarne il funzionamento affinché il processo aziendale possa procedere regolarmente.

E Danielle, se mi permetti, penso che questo rimandi a una questione più ampia.

Quindi è molto facile, ehm, adottare un approccio tecnico in questa conversazione.

E in effetti, questo rappresenta sotto molti aspetti un modo per valutare l’organizzazione tecnica.

Ma credo che ciò sia legato a un problema organizzativo.

Quello che vediamo continuamente è che uno dei problemi culturali legati al restauro
dei sistemi, ed è uno dei motivi per cui in molti casi ci vuole così tanto tempo, come è successo nel mio

Ad esempio, il fatto è che in realtà abbiamo a che fare con due squadre che devono assumersi una
parte di responsabilità in questo ambito.

C’è ovviamente il tradizionale team addetto alle infrastrutture, composto dalle persone responsabili
di Backup and Recovery, che ovviamente hanno un ruolo da svolgere, ma non sono più gli unici.

C’è anche un team di sicurezza.

Un team in grado di indicarvi, ad esempio tramite analisi forense, dove si trova il backup integro, dove si trovano i
integrità dei dati, in che misura i sistemi siano infetti: quello è un team di sicurezza.

Quindi, quando questi team non collaborano alla Recovery, o parlano lingue diverse
, o se valutano i propri risultati in modi diversi, cominciamo a intravedere un problema

E tutto parte dalla cultura.

Un modo per riflettere su questo argomento è quello di prendere in considerazione l’RPO e l’RTO (Recovery Time Objective, tempo obiettivo di ripristino):

Quanto tempo mi ci vorrà per ripristinare i dati?

L’obiettivo del punto di ripristino (RPO), ovvero: quanti dati potrei dover recuperare?

E a tutto ciò si aggiunge l’attività forense, una disciplina legata alla sicurezza.

Ora abbiamo l’MTCR.

Quindi, la “C” è importante.

La pulizia di quei dati è davvero, davvero fondamentale.

E il punto di partenza, di cui senza dubbio discuteremo, è semplicemente chiedere all’azienda di porsi
questa domanda.

In quanto tempo possiamo ripristinare la pulizia dei nostri sistemi?

E quello che vediamo ogni giorno è che non si tratta di una domanda così difficile da porre, ma di una
È davvero difficile rispondere a questa domanda, soprattutto quando c’è quel divario culturale tra

il team addetto alla sicurezza e quello addetto alle infrastrutture.

Credo davvero che sia proprio questa la genialità di MTCR: si prende una serie di concetti molto
tecnici su cui i team IT e di sicurezza si confrontano e li si trasforma in

qualcosa di cui discutere con gli amministratori delegati e i consigli di amministrazione.

Per tornare al tuo esempio, Darren, di un rivenditore che a Natale ha subito un attacco informatico
, come useresti l’MTCR se ti trovassi di fronte a un consiglio di amministrazione a

spiegare cosa è successo e come sta procedendo il processo di Recovery?

Beh, inizierò io a rispondere e poi passerò la parola
Duncan, poiché si tratta di una parte di questo documento di cui Duncan è stato in gran parte responsabile, che riguarda proprio

raggruppamento

di risorse che si combinano per costituire un servizio.

Ma inizierò dicendo che ci sono un paio di questioni che devono essere affrontate e che molto
spesso non vengono affrontate.

Una riguarda la propensione al rischio.

Allora, chi siamo come azienda?

Che tipo di azienda siamo?

Un’azienda di vendita al dettaglio, in genere, presenta una propensione al rischio da bassa a media, più
o meno in quel intervallo.

Ma questo aspetto va chiarito in modo che, man mano che andiamo avanti e iniziamo a, ehm, comprendere i
rischi che ci circondano, possiamo decidere cosa è accettabile e cosa

dovrebbe essere coperto dalla nostra assicurazione, ad esempio, e cosa invece debba essere assolutamente integrato
.

Quindi questa è la prima discussione.

La seconda conversazione verte poi sulla domanda: qual è la “minimal viable company” in questo caso?

È del tutto irrealistico supporre che un’organizzazione, indipendentemente dal proprio budget, sia
in grado di ripristinare rapidamente ogni aspetto dell’attività.

Allora, cosa conta davvero in questo settore?

È una conversazione molto, molto profonda e interessante da affrontare con la maggior parte delle aziende.

La maggior parte delle aziende non riesce a immaginare un mondo senza informatica.

Pertanto, hanno grandi difficoltà a districarsi nella complessità dei processi aziendali e a immaginare come sarebbe la situazione se tornassimo alla carta.

Ma quella conversazione, in un certo senso, deve avvenire.

E questo ci porta a definire ciò che chiamiamo MVC, ovvero una “minimal viable company”.

Cioè, quali elementi sono necessari per tornare ai tempi passati, o qualunque sia la linea temporale che decidiamo
.

Quali sono gli elementi senza i quali questa attività non funzionerebbe affatto, senza i quali non saremmo operativi?

E questa è una discussione molto, molto importante.

Quello che potete poi iniziare a fare è applicare il concetto di MTCR alla “minimal viable company”.

E ora cedo la parola a Duncan, che ci spiegherà in cosa consiste un servizio.

Come possiamo considerare questo aspetto nel contesto dei servizi?

E grazie, Darren.

E, ancora una volta, senza cercare di complicare troppo le cose o di addentrarsi troppo nei dettagli.

L’MTCR consiste nel misurare il tempo medio di Recovery di un processo aziendale,

un servizio aziendale fondamentale che contribuisce a rendere l’azienda nel suo complesso minimamente funzionante.

Pertanto, ci saranno diversi MTCR a seconda dei diversi processi aziendali.

Proprio oggi stavo parlando con un’azienda del settore dei beni di consumo, un produttore di birra, e
Mi dicevano che, se avessimo perso i dati relativi a quattro giorni, avremmo dovuto letteralmente sborsare

quattro giorni di birra nello scarico perché non possiamo dimostrare che sia sicura da bere,
e quindi non possiamo venderla.

Pertanto, nell’ambito di questo concetto, si tratta di analizzare a fondo tali processi aziendali e poi utilizzare l’MTCR
come linguaggio aziendale comune per poter poi dire: “Bene, all’interno del mio processo, ho bisogno

quindi: “Oh, questo processo si basa su diverse tipologie di applicazioni”.

Tutte si basano su servizi fondamentali, come l’identità e la possibilità per gli
ai clienti di accedere alla piattaforma.

Poi ci sono i sistemi di backend, sia nel cloud che on-premise, gli hypervisor,
le soluzioni cloud critiche.

I sistemi front-end che eseguono le applicazioni vere e proprie e poi i sistemi
di accesso degli utenti: in che modo le persone accedono effettivamente a quella soluzione? Tramite PDA, terminali di punto vendita

, ecc.

Tutti questi elementi devono essere disponibili affinché quel servizio aziendale possa funzionare.

L’MTCR è progettato per essere gestito dal titolare dell’azienda.

Il primo passo in questo percorso è quindi effettuare un benchmark.

Qual è il loro MTCR attuale?

Quanto tempo ci vorrebbe attualmente, anche se riuscissero a recuperare dati integri?

Perché il dato scioccante, al momento, è che la maggior parte delle organizzazioni non dispone
di una tecnologia che consenta loro di proteggere i propri backup e di poterli consultare

i propri backup per estrarne dati integri, ed è proprio questo il vero problema aziendale che ci ha portato qui
da risolvere.

È molto interessante.

Hai detto: qual è l’attuale MTCR?

Pertanto, l’MTCR non è una misurazione effettuata a posteriori per valutare l’efficacia del ripristino.

L’MTCR viene rilevato a intervalli regolari durante l’intero attacco.

E questo probabilmente perché

Se ci si affretta a eseguire una Recovery, si rischia di causare ulteriori danni.

Potresti approfondire un po’ questo punto?

Sì, posso sicuramente approfondire l’argomento.

Prima di farlo, però, hai sollevato una questione davvero interessante,
che, a mio avviso, andrebbe approfondito ulteriormente.

Quindi l’MTCR non è solo un parametro che si misura durante la fase di Recovery da un attacco.

È qualcosa che dovresti misurare prima della violazione.

È quello che io chiamo “a sinistra dello scoppio”.

Quando presentiamo questo concetto ai consigli di amministrazione, iniziamo a vederlo prendere piede
in tutta l’organizzazione.

E sorge spontanea la domanda: che cos’è, ad esempio, l’MTCR per la nostra “azienda che funziona a malapena”?

Potremmo ricevere alcune risposte che non vorremmo sentire, come ad esempio che non sappiamo cosa sia un’azienda minimamente funzionante
.

Oppure, anche se lo sapessimo, realisticamente, il nostro MTCR in questo momento è probabilmente di quattro mesi.

Non vogliamo sentire queste risposte, ma dobbiamo ascoltarle per poterci concentrare
sul miglioramento.

E quindi questo è un punto davvero, davvero importante, credo.

E Darren, per approfondire questo punto, penso che sia fondamentale per l’azienda capire quale
È proprio l’MTCR di oggi, perché è proprio questo che guida correttamente il processo di gestione del rischio aziendale.

E non sarà sempre una soluzione tecnologica a ridurre quel MTCR.

Molto spesso, se l’azienda è consapevole di correre questo rischio, ovvero di poter rimanere senza un
sistema critico per

per un certo periodo di tempo, può predisporre un piano alternativo di continuità operativa,
tornare al punto di partenza; sai, potrebbe essere lo scenario peggiore, Darren, ma, sai, al momento,

Le aziende non comprendono i rischi che stanno affrontando.

E questo MTCR è concepito per consentire al consiglio di amministrazione di rivolgersi al CISO e ai team
del CISO e chiedere: «Realisticamente, per quanto tempo resteremo inattivi oggi?».

E poi, se si tratta di un numero accettabile… e ne ho condotti diversi di questi studi, e spesso
si tratta di…

spesso si tratta di 28, 35 o 42 giorni.

L’azienda rimane quindi completamente sconvolta all’idea di dover fare a meno dei servizi IT per tutto quel
tempo.

Ma non ha mai avanzato tali richieste alle organizzazioni del CIO o del CISO, dicendo: “Abbiamo bisogno che
“Affinché l’azienda sia almeno minimamente operativa, queste risorse tornino online entro 24 ore”.

Come si possono progettare tali processi aziendali in modo che siano ripristinabili entro 24 ore?

Devono trattarsi di requisiti funzionali o non funzionali della loro azienda per poter dire: “Questi
Questi sono i nostri requisiti.

IT, CISO, potete aiutarmi a soddisfarli?

E, tornando al punto che ho sollevato prima, tra l’altro, ehm, è davvero importante capire
che, in un certo senso, quella domanda non può nemmeno essere posta a uno o all’altro di quei

squadra.

L’unico caso in cui si può ottenere una risposta sensata, anche se
non è quella che si vorrebbe; è quando il team dell’infrastruttura e il team della sicurezza

nella stessa stanza per rispondere.

Perché a quella domanda nessuna delle due squadre può rispondere da sola.

E questo, ripeto, dal punto di vista culturale, è davvero, davvero importante prima ancora di affrontare la
tecnologia.

Dal punto di vista culturale, ciò che stiamo cercando di fare con questo concetto è promuovere un
un comportamento che oggi non esiste.

Esatto.

Si sta cercando di abbattere i compartimenti stagni.

Quindi ogni organizzazione, che si tratti del team IT, di quello delle infrastrutture o di SecOps, pensa: “La mia
“Ogni parte va bene”, ma tutte queste parti devono funzionare insieme.

Ed è così che MTCR le riunisce e le induce a riflettere su questo

il concetto di rischio ambientale, poiché ogni singola persona ha un ruolo da svolgere in questo ambito.

E poi penso che sia davvero trasformativo, in quanto offre a ciascuno di quei
il leader ha la capacità di comunicare al CEO o al consiglio di amministrazione ciò che

stanno effettivamente affrontando la situazione in termini di Recovery e di rischio aziendale, giusto?

Assolutamente, è fantastico.

Quindi, in che modo si ricollega ai requisiti di base?

Non sono poi così semplici, ma si tratta di requisiti di conformità come DORA e NIST 2.

In che modo l’MTCR si colloca in questo contesto, ammesso che lo faccia?

Beh, se per te va bene, Duncan, comincio io.

Ecco la mia prima riflessione al riguardo: sai, Danielle, io e te abbiamo esaminato
Abbiamo letto insieme quelle sezioni del DORA tantissime volte e abbiamo parlato di conformità.

Una delle cose che stiamo iniziando a notare nel panorama della conformità, che si tratti
di DORA, NIST 2 o altre normative globali, è proprio questo riferimento, in primo luogo, a cosa

la resilienza e il suo significato in contrapposizione alla sicurezza, e, in secondo luogo, i test.

Hai un programma?

Hai provato il piano di Recovery?

Beh, credo che questo sia direttamente collegato a ciò che dovrebbe costituire il parametro di valutazione del piano.

Mi preoccupa un po’ il fatto che molte delle normative che vedo, anche quelle più recenti
e, pur essendo in evoluzione, facciano ancora riferimento a concetti come il ripristino di emergenza.

Non sono ancora molto chiare su ciò che dovrebbe essere testato.

Ho persino visto alcuni riferimenti a RPO-RTO.

E quindi, in una certa misura, sapete, questo è… un concetto come questo è importante man mano che le persone
cominciano ad adeguarsi e si orientano verso quel tipo di conformità che si basa fortemente sulla resilienza

.

In termini di cosa andremo a misurare in questo contesto?

Perché se ci limitiamo a misurare i vecchi indicatori relativi al Disaster Recovery, in realtà non faremo grandi progressi
.

Quello che succederà è che, se subiamo un attacco, ricorreremo al nostro piano di DR,
lo metteremo in pratica e, sorpresa sorpresa, non riusciremo a trovare il nostro backup integro, e ci vorranno 30, 40, 50, 60

giorni per ripristinare il sistema.

Quindi dobbiamo cambiare mentalità.

E per quanto riguarda la conformità, è stato davvero stimolante vedere alcune delle nuove politiche e tempistiche in materia di conformità 

parlassero di resilienza, Recovery e test, ma dobbiamo assicurarci di affrontarli
nel modo giusto e con i giusti quadri di riferimento e contesti.

Sì, sono pienamente d’accordo, Darren.

Pensa, se si considerano molti dei requisiti del DORA e ciò che la Banca centrale europea
ha affermato in merito agli stress test che la maggior parte delle organizzazioni si è preparata a

fallire, poiché è necessario dimostrare di poter ripristinare l’operatività entro i limiti della propria tolleranza all’impatto
ambiente aziendale.

E la maggior parte delle organizzazioni si basa proprio su quella tolleranza all’impatto aziendale

in base alle metriche di disponibilità previste dal vecchio piano di DR, secondo cui: “Posso eseguire il failover dal data center A al
“data center B in quattro ore”.

Non è possibile ripristinare l’intera operatività di una banca o di un istituto finanziario in quattro ore, è
impossibile.

Quindi penso, e questo in un certo senso evidenzia la necessità di questo nuovo vocabolario dell’MTCR, affinché
possano riesaminare quella tolleranza operativa, quella tolleranza all’impatto sul business, per

ridefinirla in modo da poter dire: “Se perdo il mio sistema centrale, ad esempio il mio libro mastro,

Insomma, come faccio a procedere?

Beh, non posso intervenire.

Pertanto, devo predisporre piani di emergenza che mi consentano di ricorrere a procedure alternative per poi poter
ripristinare la situazione una volta che il registro contabile torni online, nell’esempio finanziario citato.

Ma, per quanto riguarda i test, la maggior parte delle organizzazioni, quando ho posto loro la domanda: «Quando avete testato l’CR l’ultima volta?
», rimandano al loro tradizionale piano di DR.

Non fanno riferimento al loro piano di cyber Recovery perché la maggior parte delle organizzazioni non ha ancora

ha progettato e implementato integralmente un piano di cyber Recovery.

E, senza dubbio, questo MTCR deve essere uno degli indicatori chiave all’interno di quel piano di cyber-Recovery
.

Avete previsto gli scenari dai quali vi proteggerete e dai quali vi riprenderete.

Inoltre, esiste una misura dell’MTCR relativa a quei diversi tipi di attacco.

In realtà servono proprio a colmare, come ho detto, quel divario tra il business, l’IT e il CISO.

Sai, Darren, dicevi che si tratta di cambiare la cultura e, Duncan, stavi
proprio dicendo che molti…

i contratti tra, ehm, le organizzazioni richiedono un tempo di ripristino, e questo non ha senso.

Quindi non è solo per i team tecnici, ma anche per i team di gestione
per quanto riguarda il rischio aziendale e per gli avvocati che si occupano di contratti: devono rendersi conto che RTO e RPO non sono sufficienti, ma

il nuovo standard è il Recovery completo.

E tutti devono capire quale debba essere il risultato finale, non le singole fasi
intermedie che

potrebbero essere irrilevanti, giusto?

Sì, penso che sia un’osservazione davvero valida.

E mi aspetto che, man mano che portiamo avanti questa idea e organizziamo workshop sulla
posizione di rischio preferita, su tutte le aziende papabili e sull’MTCR, scopriremo

scopriremo che, forse, molte più persone di quelle che tradizionalmente sarebbero state
Le parti coinvolte nel Recovery del sistema dovranno interessarsi a tali questioni e avere voce in capitolo in merito

laboratorio.

Proprio per i motivi che hai citato, Danielle.

Quindi, ai leader che ci ascoltano,

Vi incoraggio tutti a consultare il rapporto completo.

Si intitola “Ridefinire il Recovery informatico: introduzione al Mean Time to Clean Recovery”.

E ho un’altra domanda per Duncan e Darren: oggi avete parlato di molte
argomenti.

Avete illustrato il tutto sulla base di un caso concreto riguardante un’azienda reale, il che è molto sensato.

Per i dirigenti che ci ascoltano, da dove si comincia?

Da dove cominciamo proprio adesso?

Abbiamo letto il rapporto e desideriamo introdurre questo concetto nelle nostre aziende, nelle nostre
attività.

Da dove possiamo iniziare?

Beh, per quanto mi riguarda, in qualità di dirigente non tecnico, incoraggerei a convocare una riunione
tra i responsabili della fornitura dell’infrastruttura aziendale, solitamente un CIO,

e chi è responsabile della sicurezza informatica in azienda, di solito un CISO, o forse no;
convochi una riunione con queste due persone, questi due leader, e ponga loro la domanda: in quanto

rapidamente, se dovessimo subire un attacco catastrofico da parte di un ransomware                                         �

come esempio, dato che è molto diffuso e ci riguarda tutti.

Quindi, in caso di catastrofe causata da un ransomware, in quanto tempo potreste ripristinare l’attività? 
e assicurarmi che i dati che sto per iniziare a utilizzare per gestire la…

dell’azienda siano integri?

Vi garantisco che da quella singola riunione ne seguiranno altre cinque, perché la
La risposta non è semplice.

Ci vorrà la collaborazione tra quei team.

Ci vorrà anche un cambiamento di mentalità.

E credo che direi qualcosa di molto simile, tranne per il fatto che probabilmente allargherei il pubblico
per coinvolgere in quella conversazione figure quali il Chief Risk Officer e i responsabili degli appalti.

Infatti, la maggior parte delle organizzazioni, quando valuta se si tratti di un contratto SaaS o di
Un contratto di outsourcing, in genere, non fa alcun riferimento a questo aspetto del Recovery dei dati.

Quando potrò recuperare dati integri durante il Recovery?

Poiché nella maggior parte di questi tipi di contratto è il cliente a essere responsabile dei
i propri dati.

I fornitori di infrastrutture e i fornitori SaaS sono responsabili dell’infrastruttura
che supporta il servizio.

Quindi, come sapete, spetta a loro assumersi la responsabilità di recuperare i propri dati integri
.

Ma devono anche trasmetterli abbastanza rapidamente ai propri dirigenti aziendali per cercare
di capire davvero qual è il nostro MVC, perché le organizzazioni, come hai detto prima

Darren, semplicemente non possono permetterselo e non saranno mai in grado di ripristinare l’intero sistema aziendale
in un lasso di tempo molto breve.

La chiave in questo caso sta nel definire le priorità e solo l’azienda può valutare cosa sia più importante
per loro, in una situazione di grave crisi informatica.

Darren, CTO di Commvault, e Duncan, ehm, responsabile del settore Sicurezza e Resilienza presso Kyndryl.

Grazie mille.

Per quanto riguarda i prossimi passi, spero che voi ragazzi diffondiate questo concetto di MTCR e aiutiate i leader
aziendali a discuterne nel corso di un workshop.

E mi aspetto che inizieremo a vederlo diffondersi in tutto il mondo man mano che contribuiamo a
le nostre aziende a definire l’MVC più adatto a ciascuna di esse.

Grazie mille per il tempo che ci avete dedicato oggi.

Grazie, Danielle.