Un test di ripristino dei backup da fare prima del ransomware

Prima che sia il ransomware a mettere alla prova i Suoi backup, esegua da solo tre verifiche: se qualcuno può cancellarli, se un account admin rubato può raggiungerli e quanto dura un restore reale rispetto a ciò che l'azienda può tollerare.

La guida dell'NCSC per mitigare malware e ransomware è molto chiara. I backup aggiornati sono il modo più efficace per riprendersi da un attacco ransomware, il ransomware li prende di mira in modo attivo per aumentare la probabilità del pagamento, e gli attaccanti hanno distrutto i file copiati o compromesso il ripristino prima di lanciare l'attacco. Quindi i backup vanno testati come lo farebbe un attaccante.

Test 1: provi a cancellare il Suo stesso backup

Gli esempi qui riportati usano Amazon S3 Object Lock. Con altri prodotti, cerchi l'equivalente blocco di immutabilità o di retention nella Sua soluzione di backup. Verifichi che sia attivo, quale sia il periodo di retention e chi possa accorciarlo o rimuoverlo. Poi tenti una cancellazione definitiva come utente ordinario, come l'amministratore di backup con più privilegi e come un account che un attaccante potrebbe verosimilmente compromettere. Annoti chi ci riesce.

Per S3, lavori in un bucket di prova. Object Lock funziona solo nei bucket con S3 Versioning attivo, quindi lo controlli per primo. Usi la modalità governance, che AWS descrive come un modo per testare le impostazioni di retention prima di creare un periodo di retention in modalità compliance.

Non applichi mai la modalità compliance nel bucket di prova. In modalità compliance la modalità di retention non può essere modificata e il periodo non può essere accorciato, e l'unico modo per eliminare in anticipo un oggetto bloccato in compliance è eliminare l'account AWS associato.

Esegua questi tentativi sia dalla console sia tramite API o CLI, e confronti i risultati:

La seconda riga non è un fallimento: la versione bloccata resta, perché i periodi di retention non impediscono la creazione di nuove versioni o di delete marker. La terza riga è quella preoccupante. La console S3 include per impostazione predefinita l'header x-amz-bypass-governance-retention:true, quindi chiunque abbia quel permesso può cancellare gli oggetti bloccati in modalità governance con pochi clic.

Poi invii la stessa cancellazione definitiva, come quello stesso utente, tramite API o CLI senza l'header. AWS lo richiede in qualsiasi richiesta che aggiri la modalità governance, quindi dovrebbe restituire Access Denied. Se invece riesce, controlli la modalità di retention del bucket e le impostazioni di blocco della versione dell'oggetto.

Poi verifichi chi può annullare il blocco

Elenchi ogni principal le cui policy consentono s3:BypassGovernanceRetention, inclusi ruoli, gruppi e policy inline. Faccia lo stesso per s3:PutObjectLegalHold: un legal hold non ha scadenza e qualsiasi utente con quel permesso può applicare e rimuovere hold liberamente.

Rimuova entrambi i permessi dagli account che un attaccante potrebbe verosimilmente compromettere. Per i dati che non può permettersi di perdere, valuti la modalità compliance con un periodo di retention scelto con cura.

Test 2: provi a raggiungere il backup con le credenziali sbagliate

Lo storage immutabile non serve se l'attaccante controlla la console che lo gestisce. Provi ad accedere alla console di backup e allo storage con un domain admin, un account backup-operator e un utente IAM cloud, e verifichi se ciascuno possa cancellare dati o modificare le impostazioni di retention.

La guida dell'NCSC raccomanda queste protezioni per gli account di backup:

• Privileged Access Workstations e firewall hardware che applichino un'allow list di indirizzi IP.
• MFA, con il metodo MFA non installato sul dispositivo usato per amministrare i backup.
• Privileged Access Management, in modo che gli amministratori non accedano direttamente ai sistemi di backup di maggior valore.

Dischi di backup e chiavette USB non dovrebbero essere collegati in modo permanente alla rete, e i prodotti di backup vanno aggiornati con le patch. Con un servizio cloud, confermi che le versioni precedenti siano protette dalla cancellazione immediata e che sia possibile ripristinarle, perché spesso i servizi si sincronizzano subito dopo che i Suoi file sono stati sostituiti da copie cifrate.

Test 3: ripristini qualcosa, con il cronometro

Scelga un sistema di cui l'azienda sentirebbe la mancanza entro un giorno e lo ripristini dal backup in un ambiente pulito e isolato, in modo che un'eventuale infezione ripristinata non possa raggiungere i sistemi in produzione. Annoti il tempo trascorso, chi ha fatto cosa e ogni punto in cui qualcuno ha dovuto cercare una password, una chiave di licenza o un documento che si trova sui server che state ripristinando.

Se il ripristino fallisce a metà, registri il passaggio, il tempo trascorso, la causa e la correzione, poi riparta da quel passaggio e registri a parte il tempo rimanente. Mantenga identici i passaggi tra un'esecuzione e l'altra, così che i risultati siano confrontabili.

Prima del recupero, colleghi i backup solo a dispositivi noti e puliti, e li scansioni alla ricerca di malware prima di ripristinare i file. Il ransomware potrebbe essersi replicato nei backup prima di essere scoperto, quindi un punto di ripristino dall'aspetto pulito potrebbe non esserlo.

Confronti il tempo misurato con quello che l'azienda dichiara di poter tollerare. Ottenga quel valore dal responsabile del sistema prima del test, per non adattare l'obiettivo al risultato. Un recupero completo da ransomware, se possibile, può richiedere diverse settimane, quindi consideri il dato di un singolo sistema come un valore minimo.

Su carta, ragioni su cosa succede se i sistemi on-premise e i server di backup cloud sono entrambi inutilizzabili e occorre ricostruire da backup offline, e su come manterrebbe operativi i servizi aziendali critici. Verifichi che playbook, checklist e recapiti esistano in un luogo raggiungibile senza i Suoi sistemi informatici. Il nostro servizio di incident response comprende esercitazioni di questo tipo, se desidera un punto di vista esterno.

Da dove iniziare

1. Scelga un sistema critico per il business e chieda al suo responsabile per quanto tempo può restare fermo. Scriva prima di tutto quel numero.
2. Crei un bucket S3 di prova con versioning e Object Lock in modalità governance, mai compliance. Tenti una cancellazione definitiva e una semplice, e registri le risposte.
3. Ripeta la cancellazione definitiva come utente con s3:BypassGovernanceRetention, dalla console e dall'API o dalla CLI senza l'header di bypass. Poi elenchi tutti i titolari di quel permesso e di s3:PutObjectLegalHold, e lo revochi a chi non ne ha bisogno.
4. Provi ad accedere alla console di backup con un domain admin, un backup operator e un utente IAM cloud. Dove un accesso è riuscito, pianifichi MFA su un dispositivo separato e un'allow list di IP. Confermi che esista una copia offline, che non sia collegata in modo permanente e che sia stato fatto un ripristino da essa.
5. Ripristini il sistema scelto in un ambiente isolato da un backup scansionato, cronometrando ogni passaggio, e confronti il risultato con il numero del punto 1.
6. Corregga la lacuna più grande, poi ripeta i test ogni volta che cambia l'architettura dei backup.