“Backup completato con successo.”
È probabilmente una delle notifiche più rassicuranti che un amministratore possa ricevere.
I dati sono stati copiati. Il job non ha restituito errori. La copia esiste.
Ma c'è una domanda molto più importante:
se domani l'intera infrastruttura venisse compromessa, riusciremmo davvero a ripartire?
Perché avere un backup e avere una strategia di recovery non sono la stessa cosa.
Quando l'attaccante cerca anche i backup
Un attacco ransomware moderno non deve necessariamente limitarsi a cifrare i file presenti sui computer.
Se l'attaccante riesce a ottenere privilegi sufficienti e a muoversi lateralmente nell'infrastruttura, può cercare repository di backup, server dedicati, sistemi NAS, console di amministrazione e credenziali utilizzate per gestirli.
Il problema diventa particolarmente serio quando produzione e infrastruttura di backup condividono lo stesso dominio di fiducia, credenziali privilegiate o percorsi di amministrazione.
In quel momento il backup, invece di rappresentare l'ultima linea di difesa, rischia di trovarsi all'interno dello stesso raggio di compromissione.
Produzione compromessa.
Credenziali compromesse.
Backup raggiungibile.
E improvvisamente la domanda non è più quanto velocemente possiamo ripristinare?
Diventa:
da cosa possiamo ancora ripristinare?
Backup ≠ Recovery
Un backup è una copia dei dati.
Il recovery è la capacità concreta di utilizzare quella copia per ricostruire un sistema funzionante.
La differenza sembra sottile, ma è fondamentale.
Un backup può esistere ed essere inutilizzabile.
Può essere corrotto.
Può essere incompleto.
Può contenere dati già compromessi.
Può dipendere da credenziali che non sono più disponibili.
Oppure può trovarsi su un'infrastruttura che l'attaccante ha già raggiunto.
Per questo il semplice messaggio “backup completato con successo” non dimostra che un'organizzazione sia realmente recuperabile.
Dimostra soltanto che, in quel momento, un processo di copia è terminato senza rilevare errori.
Immutabile non significa invulnerabile
Una delle risposte più importanti a questo problema è l'immutabilità.
Un backup immutabile impedisce che una determinata copia venga modificata o eliminata durante il periodo previsto dalla policy.
È una protezione estremamente utile, soprattutto contro ransomware e cancellazioni intenzionali.
Ma anche qui bisogna evitare una semplificazione:
immutabilità non significa automaticamente sicurezza assoluta.
Bisogna chiedersi chi può modificare le policy, chi controlla le credenziali amministrative, come vengono protette le chiavi, quali sistemi possono raggiungere il repository e cosa accade se viene compromesso il piano di controllo.
La sicurezza del backup, quindi, non dipende da una singola funzione.
Dipende dall'architettura che la circonda.
Il principio 3-2-1-1-0
Una strategia moderna può partire dall'evoluzione della nota regola 3-2-1:
3 copie dei dati
2 tipologie di supporto differenti
1 copia off-site
1 copia offline, air-gapped o immutabile
0 errori rilevati durante la verifica dei backup
L'ultimo numero è forse il più interessante.
Zero.
Perché una copia non verificata rappresenta, in parte, una promessa.
Una copia verificata attraverso controlli di integrità e procedure periodiche di restore fornisce invece una prova molto più concreta della possibilità di recupero.
Il vero test arriva prima dell'incidente
Molte organizzazioni verificano attentamente che i backup vengano eseguiti.
Molte meno verificano con la stessa attenzione che quei backup possano essere realmente ripristinati.
Ed è una differenza enorme.
Un sistema di recovery dovrebbe essere testato quando tutto funziona, non quando l'infrastruttura è già ferma e ogni minuto di downtime ha un costo.
Questo significa verificare periodicamente almeno:
- integrità delle copie;
- disponibilità delle versioni necessarie;
- procedure e tempi di ripristino;
- dipendenze necessarie al recovery;
- credenziali e chiavi;
- capacità di ricostruire i sistemi anche in scenari di compromissione grave.
Il disaster recovery non dovrebbe essere una procedura teorica conservata in un documento.
Dovrebbe essere una capacità verificabile.
Progettare assumendo la compromissione
Qui il problema del backup incontra un principio fondamentale della cybersecurity moderna:
assume breach.
Non progettare soltanto pensando a come impedire l'attacco.
Progetta anche chiedendoti cosa rimarrà affidabile dopo che alcune delle tue difese avranno fallito.
Se un endpoint viene compromesso, il backup rimane protetto?
Se vengono rubate credenziali privilegiate?
Se cade un server?
Se viene compromessa una parte dell'infrastruttura?
Se alcuni componenti non sono più considerabili attendibili?
Una buona architettura di recovery dovrebbe cercare di ridurre il più possibile le dipendenze dal sistema che potrebbe essere stato compromesso.
Separazione dei privilegi, autenticazione forte, copie off-site, immutabilità, verifica dell'integrità, isolamento e test periodici diventano quindi parti dello stesso problema.
Non si tratta più semplicemente di salvare dei file.
Si tratta di progettare la capacità di sopravvivere alla perdita di fiducia nell'infrastruttura primaria.
La domanda sbagliata
Per anni abbiamo chiesto:
“Abbiamo un backup?”
Oggi questa domanda, da sola, non basta più.
Dovremmo chiederci:
“Qual è il nostro ultimo punto di recovery affidabile?”
“Come sappiamo che è integro?”
“Chi può modificarlo o eliminarlo?”
“Da quali credenziali e sistemi dipende?”
E soprattutto:
Se domani tutto il resto fosse compromesso, riusciremmo comunque a ripartire?
Perché il valore di un backup non si misura nel momento in cui viene creato.
Si misura nel momento in cui tutto il resto ha smesso di funzionare.
Fonti
- [1] CISA
