Il backup che non hai mai testato non è un backup
I gruppi ransomware puntano prima ai backup, proprio perché un ripristino funzionante toglie loro la leva. La maggior parte delle organizzazioni scopre il proprio tempo di recupero durante l'incidente.
One stopwatch, nothing else
A single mechanical stopwatch on a seamless bone-white surface, viewed slightly from above. Vast empty space around it. Nothing else in frame.
2400×1350 · WebP · <350KB
Ogni organizzazione che abbiamo accompagnato attraverso un incidente ransomware aveva dei backup. Non è quello che fa la differenza. La differenza sta nell'aver mai ripristinato da quei backup sotto pressione, con la persona che di solito se ne occupa non disponibile, mentre anche il domain controller era cifrato.
Gli attaccanti puntano ai backup deliberatamente
Gli operatori ransomware moderni non sono opportunisti che per caso cifrano una condivisione. Passano prima giorni dentro la rete, e uno dei primi obiettivi è la tua infrastruttura di backup, perché un cliente che può ripristinare non paga. Cancellano snapshot, corrompono repository e, se il tuo server di backup è in dominio con un service account da amministratore di dominio, lo fanno con le tue stesse credenziali.
Se un attaccante con privilegi di amministratore di dominio può cancellare i tuoi backup, non hai backup. Hai copie.
3-2-1-1-0, e la parte che tutti saltano
- 3 copie dei dati
- 2 tipi di supporto diversi
- 1 copia fuori sede
- 1 copia immutabile o isolata: storage con object lock che un attaccante con controllo totale non riesce comunque a cancellare
- 0 errori nella verifica di ripristino
Lo zero finale è quello che cade, perché è l'unico a richiedere sforzo continuo invece di un acquisto. Tutto ciò che viene prima è architettura. Quell'ultima cifra è un'abitudine.
Com'è fatto un vero test di ripristino
Non un job di backup che ha segnalato successo. Un ripristino vero, su infrastruttura isolata, di un sistema che conta, cronometrato, condotto da qualcuno che non è chi l'ha costruito. Stai testando tre cose insieme: che i dati siano integri, che il runbook sia corretto e che un normale membro del tuo team riesca a seguirlo.
Fallo con il runbook stampato. Durante un incidente vero il tuo wiki può essere cifrato, il tuo SSO fuori servizio e il tuo password manager uno dei sistemi che stai cercando di ripristinare.
I numeri che dovresti saper dire
Per ogni livello di sistema: quanti dati puoi permetterti di perdere (RPO), quanto tempo puoi restare fermo (RTO) e — separatamente — il tempo di recupero che hai davvero misurato. La distanza fra gli ultimi due è la tua esposizione reale, ed è l'unico numero di questo articolo che merita di arrivare al consiglio.
La maggior parte delle organizzazioni che valutiamo trova una distanza di tre volte o più. Non perché la tecnologia sia sbagliata, ma perché nessuno aveva contato le ore per ripristinare Active Directory prima dei server applicativi, né notato che la copia fuori sede si ripristina su un collegamento che impiega undici ore a spostare un terabyte.