Perché la velocità di ripristino è il vero indicatore della resilienza informatica

Introduzione: Spostare l’attenzione dalla prevenzione al ripristino

Per la maggior parte degli ultimi 20 anni, la principale giustificazione degli investimenti nella sicurezza informatica si è concentrata sulla prevenzione: firewall, protezione degli endpoint, intelligence sulle minacce e impedimento a tutti i costi dell’accesso agli aggressori. Questo approccio aveva senso quando gli incidenti erano meno frequenti e più facilmente contenibili.

Questo approccio ha molto meno senso in un mondo in cui, per molte organizzazioni, la domanda è passata da “Avremo un incidente grave?” a “Quanto velocemente ci riprenderemo dopo un incidente?”.

L’impatto aziendale dei tempi di inattività e degli attacchi ransomware

Man mano che le aziende sono diventate più dipendenti dall’accesso ininterrotto alle informazioni, l’impatto finanziario e operativo dei tempi di inattività non pianificati è aumentato in modo significativo. In settori come la sanità, i servizi finanziari e le infrastrutture critiche, rimanere offline per poche ore può portare a una vasta gamma di eventi dannosi:

• Operazioni rinviate
• Transazioni fallite
• Sanzioni normative
• Reputazione del marchio danneggiata che perdura oltre il tempo di inattività effettivo

Il ransomware moderno ha modificato questa dinamica in modo piuttosto significativo. È ormai prassi comune attaccare i backup insieme ai sistemi primari, se non altro per ridurre le opzioni di ripristino (e il potere contrattuale) dell’organizzazione attaccata. Il pagamento di un riscatto non garantisce nemmeno il ripristino delle operazioni aziendali: le chiavi di decrittazione sono spesso lente o incomplete e i dati ripristinati potrebbero comunque contenere codice dannoso latente. Pertanto, il processo di ripristino non consiste semplicemente nell’invertire il processo di crittografia.

Definizione di resilienza informatica: oltre la protezione e il rilevamento

La resilienza informatica è comunemente vista come sinonimo di sicurezza informatica, anche se sono concettualmente diverse per natura. La sicurezza informatica si concentra sulla riduzione al minimo della possibilità che si verifichi un incidente, mentre la resilienza informatica descrive come un’azienda ripristinerebbe le funzioni necessarie nel caso in cui i controlli preventivi fallissero. Data la sofisticazione delle minacce moderne, la questione del fallimento di questi controlli non riguarda il “se”, ma il “quando”.

Un’organizzazione resiliente non è un’organizzazione priva di incidenti. Un’organizzazione resiliente è quella che si riprende dagli incidenti in modo più rapido, agevole e con un impatto meno prolungato sulle operazioni. Questa differenziazione è significativa per definire la strategia, allocare il budget e valutare se i controlli esistenti siano adeguati fin dall’inizio.

Metriche tradizionali vs. resilienza incentrata sul ripristino

La maggior parte delle metriche che comunemente misurano il livello di sicurezza sono state sviluppate in un’epoca in cui il contenimento era l’obiettivo primario della sicurezza. Sono ancora preziose, ma forniscono un quadro incompleto di come un’organizzazione si comporterà in caso di incidente grave, poiché si fermano una volta che l’autore dell’attacco è stato rimosso. L’approccio di resilienza incentrato sul ripristino, d’altra parte, considera questo punto come l’inizio, non la fine, concentrandosi su quanto efficacemente e senza intoppi un’azienda possa tornare al normale funzionamento.

Breve panoramica di MTTD, MTTR, RPO e RTO

MTTD (Mean Time to Detect) è utilizzato per definire il tempo che intercorre tra il momento in cui si verifica un evento e quello in cui tale evento viene scoperto.

MTTR (Mean Time to Respond, in contesti di sicurezza) è utilizzato per definire il tempo che intercorre tra il rilevamento e il contenimento.

RPO (Recovery Point Objective) definisce la perdita massima accettabile di dati in un determinato momento, mentre RTO (Recovery Time Objective) definisce la rapidità con cui i sistemi devono essere ripristinati.

Queste metriche non sono una novità nel campo della sicurezza e non rappresentano di per sé il problema. Il problema risiede nell’importanza che le organizzazioni attribuiscono loro l’una rispetto all’altra.

Limiti della velocità di rilevamento e della spesa per la prevenzione

La velocità di rilevamento è un fattore importante, ma solo fino a un certo punto. Essere immediatamente a conoscenza di un’intrusione è di per sé vantaggioso, ma se l’infrastruttura dell’organizzazione non è in grado di riprendersi in modo chiaro una volta che il problema è stato identificato e contenuto, non vi è alcuna riduzione significativa dell’impatto sul business.

La spesa per la prevenzione si scontra con un limite simile: nessuna singola misura di controllo preventivo può eliminare completamente il rischio, e un budget per la sicurezza fortemente orientato alla prevenzione a scapito della capacità di ripristino lascerà un’organizzazione ben difesa ma allo stesso tempo scarsamente preparata.

Perché il tempo medio di ripristino (MTTR/MTCR) è più importante

La metrica che riflette al meglio la resilienza di un’organizzazione è il tempo effettivamente necessario per ripristinare il normale funzionamento partendo da una situazione verificata e pulita. Questo tipo di approccio va ben oltre la consueta definizione di MTTR nelle operazioni di sicurezza.

Nel contesto del recupero dei dati, il tempo medio di recupero completo (MTCR) è definito dall’intervallo di tempo che intercorre tra la conferma dell’incidente e il funzionamento a piena capacità di un sistema affidabile e privo di malware. Questa distinzione diventa estremamente importante quando si considera l’integrità di ciò che viene ripristinato, e non la mera velocità di ripristino.

Il divario nel recupero informatico: lezioni tratte da incidenti recenti e dalla ricerca

Il divario tra la capacità di recupero ipotizzata e le prestazioni effettive di recupero è spesso piuttosto consistente. Non è raro che le organizzazioni scoprano questa differenza durante un incidente, non durante i test – il che è ben lungi dall’essere il momento più opportuno per scoprirla.

Elevati tassi di fallimento dei ripristini da ransomware nel settore sanitario e in altri settori

Il settore sanitario è uno dei principali obiettivi del ransomware, sia per l’importanza generale delle operazioni sanitarie, sia a causa delle infrastrutture legacy e dei reparti IT sottofinanziati, entrambi comuni in questo campo.

Secondo il rapporto Sophos “Stato del ransomware nel settore sanitario 2024”, solo il 22% delle organizzazioni sanitarie è stato in grado di riprendersi dagli attacchi ransomware entro una settimana o meno, il che rappresenta un calo significativo rispetto al 54% delle organizzazioni che nel 2022 avevano segnalato un ripristino riuscito.

Lo stesso rapporto ha inoltre rivelato che gli aggressori cercano spesso di sfruttare i backup delle organizzazioni sanitarie (segnalato nel 95% dei casi), con i 2/3 di tali tentativi che vanno a buon fine. È stato inoltre riscontrato che le organizzazioni con backup compromessi sono due volte più propense a pagare il riscatto (63% contro 27%).

Dati che evidenziano pratiche di ripristino limitate e backup compromessi

La frequenza dei test di ripristino è di per sé un punto debole persistente. Uno studio del 2021 citato dal professionista del DR Dale Shulmistra ha rilevato che quasi la metà delle aziende testa il disaster recovery una volta all’anno o meno, e il 7% non lo testa affatto.

Gli aggressori imparano a sfruttare tale vulnerabilità: il tempo di permanenza (il tempo che intercorre tra l’accesso dell’intruso e l’avvio del ransomware) può variare da giorni a mesi, lasciando al malware il tempo di entrare nella catena di backup. A meno che il controllo dell’integrità non sia integrato nel processo di backup, non è possibile prevedere quanto tempo occorrerebbe per trovare un backup non compromesso.

Velocità di ripristino tipiche per diversi supporti di archiviazione

La velocità di ripristino è fortemente influenzata dal supporto di archiviazione utilizzato.

Il livello più veloce comprende gli SSD NVMe e la memoria di classe storage (SCM). Le unità SAS/SATA tradizionali sono molto più lente in confronto, le prestazioni dello storage a oggetti dipendono dalla rete e dalle dimensioni degli oggetti, mentre i nastri introducono una notevole latenza di recupero (fino a diverse ore per set di dati di grandi dimensioni).

I dati precisi relativi alla velocità di trasmissione dipendono dall’ambiente e si trovano tipicamente nei benchmark dei fornitori piuttosto che in ricerche indipendenti – ma il divario tra i livelli è abbastanza ampio da determinare se un RTO documentato sia effettivamente possibile o meno.

La velocità di ripristino come vera metrica della resilienza

Definizione del tempo medio di ripristino (MTTR) rispetto al tempo medio di ripristino completo (MTCR)

Poiché abbiamo già definito sia l’MTTR che l’MTCR, è importante anche approfondire le loro differenze, che diventano più evidenti in condizioni di attacco. La tabella seguente mostra come l’MTTR differisca dall’MTCR a seconda del tipo di incidente:

In che modo un ripristino rapido ed efficiente riduce l’esposizione normativa e i costi dei tempi di inattività

Il costo di un incidente aumenta nel tempo e la velocità di ripristino è uno dei fattori principali che ne determinano il valore finale. Le stime dei costi dei tempi di inattività che vengono pubblicate tendono a variare in modo significativo a seconda del settore, delle dimensioni dell’organizzazione e della metodologia utilizzata – da decine di migliaia a diverse centinaia di migliaia di dollari all’ora nei settori ad alta intensità di dati (con una variazione che riflette in parte quanto sia raro che le organizzazioni rendano pubblici i costi effettivi).

Tutte le fonti di dati concordano sul fatto che ogni ora di inattività comporta un costo finanziario misurabile, mentre i processi di ripristino testati e collaudati riescono anche a ridurre l’esposizione normativa in situazioni in cui il ripristino tempestivo della disponibilità dei dati costituisce un fattore di conformità.

Pressioni normative: la legge UE sulla resilienza informatica e altri quadri normativi

Vale la pena approfondire l’esatta portata della legge UE sulla resilienza informatica (Regolamento (UE) 2024/2847).

Il CRA è entrato in vigore il 10 dicembre 2024, mentre gli obblighi principali entreranno in vigore l’11 dicembre 2027. Si applica specificamente ai prodotti che incorporano elementi digitali – sia hardware che software messi a disposizione nell’UE – con i produttori responsabili della sicurezza informatica durante tutte le fasi del ciclo di vita del prodotto.

I quadri normativi più direttamente rilevanti per la capacità di ripristino organizzativo sono la NIS2 (Network and Information Systems), che copre i settori critici e le catene di approvvigionamento, e la DORA (Digital Operational Resilience Act), che impone specifici requisiti di resilienza operativa e di test agli enti finanziari.

Fattori che influenzano la velocità di ripristino

La velocità di ripristino non è solo una singola variabile isolata, ma il prodotto di diversi fattori interconnessi. Per migliorare in modo significativo l’MTCR, è necessario comprendere dove è più probabile che si verifichino i colli di bottiglia.

Infrastruttura e prestazioni di archiviazione (SCM, SSD, SAS, Object, Tape)

Le velocità massime di ripristino sono determinate principalmente dalla capacità di throughput del supporto su cui vengono scritti i dati recuperati.

Il tiering dello storage (utilizzando supporti ad alta velocità per le applicazioni mission-critical e riservando lo storage più lento ai dati meno sensibili al fattore tempo) può essere impiegato per ottenere una velocità di ripristino accettabile per i dati chiave senza incorrere nei costi di uno storage ad alte prestazioni su tutta la linea.

Allo stesso modo, la larghezza di banda di rete diventa il collo di bottiglia del ripristino se un set di dati di grandi dimensioni viene ripristinato su una rete trafficata: anche i dati provenienti da supporti di archiviazione ad alte prestazioni richiederebbero più tempo per il recupero se fossero limitati dalle capacità dell’infrastruttura di rete.

Integrità dei dati: garantire backup puliti e privi di malware

La velocità senza integrità nel contesto della sicurezza informatica è in realtà peggio che inutile, poiché un ripristino rapido utilizzando un backup compromesso non farà altro che prolungare l’incidente.

Un ripristino efficace dipende dal fatto che sia la verifica dell’integrità che la scansione antimalware facciano parte del processo di backup, non solo da un controllo una tantum durante il processo di ripristino.

I backup su supporti WORM non possono essere crittografati o modificati dal ransomware, anche se il sistema di backup stesso è sotto il controllo di un aggressore.

Tutto ciò, combinato con la conservazione con versioni, crea uno stato recuperabile difficile da infettare – se il periodo di conservazione è sufficientemente lungo da contenere l’infezione iniziale.

Automazione, orchestrazione e definizione delle priorità dei processi di ripristino

I processi di ripristino manuali generano una variabilità con cui è difficile lavorare sotto pressione. I playbook standardizzati possono aiutare a dare priorità ai sistemi critici, a sequenziare correttamente le dipendenze e a eseguire i processi di ripristino in parallelo ove possibile – senza che sia necessario un giudizio umano in ogni fase durante un’emergenza.

Il punto qui non è quello di eliminare la supervisione umana, ma di garantire che le decisioni che richiedono un giudizio umano vengano prese durante la pianificazione invece di essere improvvisate sul momento.

Fattori umani: testare regolarmente i piani di ripristino e le competenze

Un piano di ripristino che esiste solo sulla carta non è affidabile quanto un piano che è già stato eseguito. Le esercitazioni teoriche evidenziano le debolezze nella comunicazione e nel processo decisionale all’interno di un’organizzazione, mentre i test di ripristino completo mettono in luce potenziali guasti tecnici: dipendenze non documentate, sistemi che non saranno in grado di ripristinarsi correttamente, tempistiche che non soddisferanno le aspettative iniziali.

Questi test devono essere effettuati con una frequenza sufficiente a stare al passo con i cambiamenti dell’infrastruttura, ed è inoltre importante che tali test simulino il più possibile scenari di minaccia reali, anziché concentrarsi esclusivamente sui guasti hardware.

Selezione delle metriche e dei KPI corretti

Combinazione di RPO, RTO, MTTR e MTCR per una visione olistica

In questo caso, nessuna singola metrica è in grado di cogliere il quadro completo.

• L’RPO definisce la perdita di dati accettabile e determina la frequenza dei backup
• L’RTO definisce l’obiettivo di ripristino
• L’MTTR monitora le prestazioni effettive rispetto a tale obiettivo
• L’MTCR aggiunge la dimensione dell’integrità, che è la più importante negli scenari di cyber-recupero

Se combinate, queste metriche consentono a un’organizzazione di individuare specifici punti deboli. Ad esempio, una combinazione di RTO solido e MTCR scarso indica che l’integrità del backup è il problema principale. In alternativa, un MTCR elevato con un MTTR non rispettato significa che il problema risiede nelle risorse o nel reparto responsabile dei processi.

Allineamento delle metriche agli obiettivi di continuità operativa e conformità

Le metriche sono più utili quando possono essere collegate a risultati che contano davvero per l’azienda. Gli RTO basati sull’analisi dell’impatto aziendale (che evidenziano il costo operativo reale dei tempi di inattività) sono più attuabili rispetto agli RTO impostati per corrispondere alle impostazioni predefinite dei fornitori o copiati da framework generici.

Allo stesso modo, gli obiettivi MTCR dovrebbero riflettere i requisiti pratici di integrità dei dati in questione, insieme agli obblighi normativi ad essi applicabili.

Perché Bacula eccelle nel ripristino rapido e pulito

I problemi sopra descritti – backup compromesso, ripristino lento, incertezza sull’integrità, variabilità dei processi manuali – sono esattamente gli stessi problemi che soluzioni come Bacula Enterprise sono state progettate per affrontare. La sua architettura riflette chiaramente l’idea che la correttezza del backup e le prestazioni di ripristino non possano essere trattate come aspetti separati.

L’architettura modulare e la scalabilità di Bacula

Il design modulare di Bacula contribuisce a garantire che le organizzazioni non abbiano un singolo punto di errore, anche quando gestiscono ambienti di grandi dimensioni e distribuiti. La piattaforma è costituita da tre componenti principali: il director, lo storage daemon e il file daemon. Ciascun componente può scalare in modo indipendente in base alle esigenze di throughput e capacità dell’organizzazione.

Questo design aiuta a supportare ambienti di grandi dimensioni e complessi (comprese le implementazioni ibride e multi-cloud) senza il prerequisito di un’infrastruttura monolitica che diventa un singolo punto di errore.

Ripristino granulare: ripristino rapido di singoli file e sistemi

Non tutti i problemi richiedono un ripristino completo del sistema. Il più delle volte, ripristinare solo determinati file, database o servizi è un modo più rapido per tornare a uno stato operativo rispetto al ripristino di interi sistemi da zero.

Il ripristino granulare di Bacula consente all’amministratore di sistema di selezionare esattamente quale elemento ripristinare, limitando i tempi di ripristino e il rischio di reintrodurre dati potenzialmente infetti.

Integrazione con lo storage WORM, l’immutabilità e la scansione antimalware

Bacula Enterprise consente l’integrazione con dispositivi di storage WORM e destinazioni di backup immutabili, riducendo il rischio sia di manomissione del backup che di crittografia del backup. Le sue funzionalità di scansione antimalware verificano l’integrità del backup prima che venga eseguito un ripristino, mitigando così il rischio di ripristinare da un punto di backup danneggiato.

Queste funzionalità affrontano direttamente la sfida MTCR, aiutando a verificare se il ripristino avrà inizio da una copia di backup affidabile.

Priorità dei processi di ripristino e automazione dei flussi di lavoro di ripristino

Le funzionalità di scripting e API offerte da Bacula possono facilitare i flussi di lavoro di ripristino automatizzati e i runbook sequenziali. I processi di ripristino del sistema possono essere classificati in base alla priorità aziendale, con la gestione delle dipendenze di sistema per garantire che tutto torni online nella sequenza corretta. Ciò può contribuire a migliorare l’MTTR effettivo e anche a migliorare gli RTO quando se ne presenta la necessità.

Strategie per accelerare il ripristino e migliorare la resilienza

Testare regolarmente i backup e verificare l’integrità dei dati

Un’operazione di backup riuscita non equivale a un backup che può essere ripristinato in modo pulito. La verifica dell’integrità consiste nell’eseguire test di ripristino periodici: non si tratta semplicemente di controllare che il processo di backup sia in esecuzione, ma di assicurarsi che i dati prodotti siano recuperabili, integri e privi di malware.

La frequenza dei test di ripristino dovrebbe riflettere due fattori principali:

• La criticità dei sistemi coinvolti
• Il ritmo con cui cambia l’infrastruttura

Utilizzo di storage a più livelli e supporti ad alta velocità per i dati critici

Non tutti i dati devono essere archiviati sul supporto più veloce a disposizione dell’azienda, ma quelli che richiedono RTO brevi dovrebbero certamente essere archiviati in questo modo. L’adozione di un approccio a più livelli – con supporti ad alte prestazioni e ad alto throughput utilizzati per le applicazioni che lo richiedono, mentre i dati meno critici vengono collocati su storage più lento ed economico – aiuta le organizzazioni a ottimizzare la velocità di ripristino dove conta di più, senza dover sostenere i costi di uno storage ad alte prestazioni su tutta la linea.

Automazione delle procedure di risposta agli incidenti e di disaster recovery

Le procedure di ripristino che devono essere assemblate in condizioni di incidente sono molto meno affidabili di quelle create e testate in anticipo. L’automazione, in quanto funzionalità, contribuisce a ridurre la dipendenza dal giudizio in tempo reale per decisioni che possono essere predefinite – che si tratti dell’ordine di ripristino del sistema, della sequenza delle dipendenze o dell’esecuzione parallela dei processi. L’automazione porta inoltre a risultati più prevedibili, rendendo la revisione e il miglioramento post-incidente significativamente più utili.

Misurare e migliorare MTTR e MTCR nel tempo

La resilienza migliora quando viene misurata in modo coerente. Il monitoraggio di MTTR e MTCR sia nei test che negli incidenti reali (anziché trattare ogni esercizio come un evento isolato) consente alle aziende di individuare dove si verificano le perdite di tempo – che si tratti di rilevamento, verifica dell’integrità dei backup, sequenza di ripristino o coordinamento umano.

Sono proprio questi dati che contribuiscono a trasformare la pianificazione del ripristino da un esercizio di conformità a un programma utile con risultati misurabili.

Conclusione: adottare una mentalità incentrata sul ripristino

Riassumendo perché la velocità di ripristino definisce la resilienza informatica

Sebbene la prevenzione e il rilevamento siano necessari, la velocità e la completezza del ripristino determinano il costo reale di un incidente. L’MTCR – il tempo necessario per raggiungere uno stato verificato, non infetto e funzionante – è un indicatore di resilienza molto più attendibile rispetto alle sole metriche relative alla postura di sicurezza, ed è anche la metrica più controllabile a disposizione di un’organizzazione durante un attacco.

Incoraggiare le organizzazioni a valutare e migliorare le proprie metriche di ripristino

Le organizzazioni non sarebbero in grado di avere un quadro accurato del loro MTCR effettivo se non avessero recentemente testato le proprie capacità di ripristino in scenari realistici, quali catene di backup compromesse o tempi di permanenza prolungati.

Bacula Enterprise offre l’architettura, i controlli di integrità e le capacità di automazione necessari per ridurre in modo significativo tale divario anche negli ambienti più complessi e su larga scala, contribuendo al contempo a sviluppare una postura di ripristino che possa essere dimostrata anziché semplicemente ipotizzata.

Domande frequenti

La velocità di ripristino è più importante della prevenzione delle violazioni?

Nessuna delle due opzioni si esclude a vicenda. La prevenzione riduce al minimo il rischio che si verifichino incidenti; una solida capacità di ripristino riduce al minimo l’impatto qualora un incidente dovesse effettivamente verificarsi. Il motivo pratico per dare al ripristino maggiore enfasi rispetto a quanto avviene di solito è che la prevenzione ha un certo limite massimo – attacchi complessi, ad un certo punto, avranno successo anche contro gli obiettivi più robusti – mentre la capacità di ripristino è direttamente proporzionale a quanto un incidente costerà in generale.

In che modo gli assicuratori informatici valutano le capacità di ripristino?

Ultimamente gli assicuratori sono diventati più rigorosi in questo ambito. La maggior parte di essi ora chiede esplicitamente informazioni sulla frequenza dei backup, sulla disponibilità di backup offsite e immutabili, sulla frequenza con cui viene testato il processo di ripristino e se i backup sono isolati dalla rete di produzione. Le organizzazioni con processi di ripristino documentati e regolarmente testati e catene di backup verificabili tendono a ricevere condizioni più favorevoli rispetto a quelle la cui strategia di backup esiste principalmente sulla carta.

A quali metriche di ripristino prestano effettivamente attenzione le autorità di regolamentazione e i revisori?

Sebbene l’ambito normativo differisca tra i vari quadri normativi e settori, gli impegni e la dimostrazione della fattibilità per RTO e RPO sono universalmente applicabili. La capacità di ripristinare l’accesso ai dati personali entro un lasso di tempo accettabile dopo una violazione è un requisito specifico del GDPR e delle legislazioni comparabili in materia di protezione dei dati. Nel frattempo, il DORA fornisce specifiche di test per gli enti finanziari. I revisori desiderano sempre più spesso vedere i risultati dei test, non solo gli obiettivi documentati.