Perché il ransomware fa dei backup il bersaglio, non la rete di sicurezza
Per anni il backup è stato l'eccezione che rendeva il ransomware sopportabile: si cifrava la produzione, si ripristinava dal backup, si andava avanti. Gli attaccanti si sono adeguati. Il 2025 Ransomware Trends report di Veeam ha intervistato 1.300 organizzazioni, 900 delle quali avevano subito almeno un attacco ransomware nei 12 mesi precedenti. Veeam riporta che l'89% delle organizzazioni ha visto i propri repository di backup presi di mira dall'attaccante e che, in media, il 34% dei repository di backup è stato modificato o eliminato. Distruggere o corrompere la via di ripiego toglie alla vittima potere negoziale ancor prima che arrivi la richiesta di riscatto.
Il risultato si vede nei numeri sul ripristino. Lo State of Ransomware 2025 di Sophos ha intervistato 3.400 responsabili IT e della sicurezza le cui organizzazioni erano state colpite da ransomware nell'anno precedente. Tra le organizzazioni i cui dati erano stati cifrati, solo il 54% li ha ripristinati usando i backup, il tasso più basso nei sei anni in cui Sophos ha condotto l'indagine. Delle 151 organizzazioni che hanno finito per pagare più della richiesta iniziale dell'attaccante, il 38% ha dichiarato che i propri backup non avevano funzionato o erano malfunzionanti (in genere i rispondenti hanno indicato due motivi). Un backup che esiste sulla carta non equivale a un backup che si ripristina senza problemi sotto pressione.
Quel divario, tra "abbiamo i backup" e "abbiamo backup resilienti al ransomware", si riduce a tre pilastri: immutabilità, isolamento e ripristino testato. Non sono controlli indipendenti da combinare a piacere. Se ne manca uno, gli altri due non lo compensano. Un backup immutabile che un attaccante non può raggiungere è utile solo se si ripristina davvero, e un piano di restore ben testato non vale nulla se il backup da cui dipende è stato eliminato prima ancora che iniziasse l'esercitazione.
I tre pilastri, nel dettaglio
1. Immutabilità: backup che un attaccante non può toccare
Immutabilità significa che un backup non può essere modificato né eliminato entro la sua finestra di retention: non da uno script di retention configurato male, non da un account amministratore compromesso e non da un attaccante che possiede già credenziali di domain admin. In pratica si impone tramite Object Lock sull'object storage, hardware Write Once Read Many (WORM) o un hardened repository Linux con la retention imposta a livello di storage, indipendentemente dai controlli di accesso dell'applicazione di backup.
La distinzione conta perché gli operatori ransomware vanno a cercare i backup che possono raggiungere con credenziali rubate. La #StopRansomware Guide della CISA lo dice chiaramente: "Ransomware actors often hunt for and collect credentials stored in the targeted environment and use those credentials to attempt to access backup solutions" (gli attori ransomware spesso cercano e raccolgono le credenziali memorizzate nell'ambiente preso di mira e le usano per tentare di accedere alle soluzioni di backup). Se lo stesso account amministrativo che gestisce il software di backup può anche eliminare i restore point del mese scorso, l'immutabilità in realtà non è in vigore. È un'impostazione che un attaccante con privilegi sufficienti può disattivare in pochi minuti.
Il consiglio della CISA stessa in materia di backup è di "maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario" (mantenere backup offline e cifrati dei dati critici e testare regolarmente la disponibilità e l'integrità dei backup in uno scenario di disaster recovery). La stessa guida è cauta sullo storage cloud immutabile usato da solo: "Use immutable storage with caution as it does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost" (usare lo storage immutabile con cautela, perché non soddisfa i criteri di conformità di alcune normative e una configurazione errata può comportare costi significativi). L'immutabilità è un controllo forte. Non sostituisce una copia offline né un restore testato.
2. Isolamento: un piano di identità separato e una copia che gli attaccanti non possono raggiungere affatto
L'immutabilità protegge un backup dall'essere modificato. L'isolamento lo protegge dall'essere raggiunto in primo luogo. I due sono complementari, non intercambiabili, e le aziende che ne implementano solo uno tendono a scoprire la lacuna durante un incidente reale anziché durante una revisione del progetto.
L'isolamento ha due componenti. La prima è un piano di identità separato: l'infrastruttura di backup non dovrebbe fidarsi dello stesso dominio Active Directory, delle stesse credenziali amministrative o dello stesso segmento di rete piatto della produzione. Un domain controller compromesso non dovrebbe significare automaticamente un ambiente di backup compromesso; se è così, l'attaccante ha dovuto compromettere una sola cosa, non due. La seconda è una copia davvero offline o in air gap: almeno una copia dei dati critici che non abbia alcun percorso di rete permanente dalla produzione. Può trattarsi di una rotazione di nastri offline, di una destinazione di replica scollegata che resta online solo brevemente per ricevere i dati, o di un tier cloud senza credenziali persistenti memorizzate in cache in qualsiasi punto raggiungibile dall'ambiente di produzione.
Il report 2025 di Veeam afferma che le organizzazioni che danno priorità alla data resilience "can recover from attacks up to seven times faster and experience significantly lower data loss rates" (possono riprendersi dagli attacchi fino a sette volte più velocemente e registrano tassi di perdita di dati significativamente più bassi). Veeam attribuisce questo risultato alla data resilience nel suo complesso (backup e ripristino, sicurezza proattiva, incident response), non al solo isolamento. L'isolamento resta comunque una parte importante del quadro: è la differenza tra un attaccante che deve fare un reale lavoro aggiuntivo per raggiungere il vostro punto di ripristino e uno che ha già una sessione aperta verso di esso perché condivide un piano di identità con i sistemi appena compromessi.
3. Ripristino testato: dimostrare la ripristinabilità prima che serva
Il meno affascinante dei tre pilastri è anche quello più facile da lasciare a metà. Nel report 2025 di Veeam, il 98% dei rispondenti aveva un playbook per il ransomware, ma solo il 44% vi aveva incluso verifiche dei backup e relative frequenze. Il 2024 Ransomware Trends report di Veeam, basato su 1.200 organizzazioni colpite da almeno un attacco nel 2023, ha rilevato che il 63% delle organizzazioni rischiava di reintrodurre l'infezione durante il ripristino, perché i team sotto pressione per ripristinare in fretta saltano passaggi come la nuova scansione dei dati in quarantena.
I restore non testati falliscono in modi che restano invisibili fino al momento in cui contano di più: catene di backup interrotte, dipendenze mancanti per la coerenza applicativa, credenziali di service account scadute da mesi o runbook scritti per una topologia infrastrutturale che non esiste più. Saltare le scansioni di integrità e antimalware comporta un rischio più grave del downtime: ripristinare lo stesso payload che ha causato l'interruzione.
Un vero programma di ripristino testato significa esercitazioni di restore completo pianificate in un ambiente di ripristino isolato, non semplici notifiche di "job di backup completato". Misurate quelle esercitazioni rispetto agli RTO di cui l'azienda ha davvero bisogno, non a valori che si limitano a sembrare rassicuranti in una presentazione.
Cosa dicono davvero i numeri sul ripristino
I dati 2025 di Sophos hanno un titolo che sembra rassicurante: il 97% delle organizzazioni i cui dati erano stati cifrati è riuscito a recuperarli. Il dettaglio è meno confortante. Poco più della metà (54%) ha ripristinato dai backup, il 49% ha pagato il riscatto e ha riavuto i dati, e il 29% ha usato altri mezzi; molti hanno percorso più di una strada. Riavere i dati e riaverli dai propri backup sono esiti diversi. È nella distanza tra i due che emergono i pilastri deboli: un blocco di retention che il ruolo sbagliato poteva scavalcare, una rete di backup "separata" che si fidava ancora dello stesso dominio, o un restore mai provato dall'inizio alla fine.
Il costo di sbagliare
I tre pilastri non sono una checklist astratta di best practice. Si traducono direttamente in quanto costa e quanto dura un incidente ransomware. Il report 2025 di Sophos indica il costo medio di ripristino da un attacco ransomware, escluso l'eventuale riscatto pagato, in 1,53 milioni di dollari, in calo rispetto ai 2,73 milioni di dollari del 2024. Il 53% delle vittime si è ripreso completamente entro una settimana, contro il 35% dell'anno precedente. Gli altri hanno trascorso più di sette giorni in una qualche condizione di disservizio, con downtime, perdita di produttività e lavoro di incident response che si accumulavano giorno dopo giorno.
La postura di backup è una delle poche variabili di quell'equazione che un'organizzazione controlla completamente. Il successo o il fallimento della prima mossa di un attaccante contro il vostro repository di backup è deciso in gran parte da scelte fatte mesi prima, non durante l'incidente. Quando un attaccante possiede credenziali di domain admin e sta sondando la vostra piattaforma di backup, immutabilità, isolamento e ripristino testato o sono già in atto o non lo sono; non c'è modo di introdurli a posteriori sotto pressione.
Errori comuni che minano silenziosamente tutti e tre
Alcuni schemi ricorrono spesso nelle analisi post-incidente:
- Scambiare gli snapshot per backup. Uno snapshot VMware è un change log del disco virtuale originale, non una copia indipendente. L'articolo di Broadcom sulle best practice per gli snapshot è netto: "Do not use VMware snapshots as backups" (non usate gli snapshot VMware come backup). Il file di snapshot continua a crescere quanto più a lungo viene conservato, il che può riempire il datastore e peggiorare le prestazioni, e se i dischi di base vanno persi, "the snapshot files alone are not sufficient to restore a virtual machine" (i soli file di snapshot non bastano a ripristinare una macchina virtuale). Gli snapshot sono una funzionalità di comodo per rollback di breve durata (Broadcom consiglia di non conservare un singolo snapshot per più di 72 ore), non una strategia di ripristino.
- Trattare l'"immutabile" come una casella da spuntare anziché come una proprietà verificata. Object Lock e policy di retention devono essere testati proprio contro il ruolo amministrativo che gestisce la piattaforma di backup, non solo documentati in una guida di configurazione.
- Definire "isolata" una seconda copia nello stesso dominio di identità. Se le stesse credenziali compromesse in produzione possono autenticarsi sul repository di backup, la separazione geografica o di piattaforma non fornisce un vero isolamento.
- Misurare il successo in base al completamento del backup, non alla verifica del restore. Un segno di spunta verde sul job di ieri notte vi dice che i dati sono stati scritti da qualche parte. Non vi dice che quei dati sono recuperabili, coerenti a livello applicativo e privi del malware che ha reso necessario il restore.
Il ruolo di BackupSec
BackupSec non sostituisce la vostra piattaforma di backup. Tre dei nostri servizi corrispondono ai pilastri descritti sopra:
- ZeroMON monitora Veeam Backup & Replication. Gira on-premises come OVA, si connette con un account in sola lettura e non invia nulla a BackupSec né a terze parti. Tiene traccia dello stato di salute dei job, registra le modifiche di configurazione nel suo modulo Forensic & Audit (chi ha cambiato cosa e quando), esegue una checklist del Security Analyzer, produce report e invia alert via email e tramite notifica in-app. Mostra lo stato di immutabilità di ciascun repository così come lo riportano le impostazioni dei repository di Veeam stesso e segnala quando quell'impostazione cambia. Legge la configurazione di Veeam; non verifica i lock a livello di oggetto sullo storage stesso.
- ZeroTAM è un advisor dedicato alla sicurezza dei backup, non un software: progettazione dell'architettura e dell'isolamento, capacity planning, pianificazione del ripristino da ransomware e supporto prioritario durante una crisi.
- ZeroPEN è un penetration test guidato dalle minacce su Veeam Backup & Replication, Veeam ONE ed Enterprise Manager. Simula una kill chain ransomware mappata su MITRE ATT&CK in otto fasi: accesso iniziale, discovery e inventario, abuso di credenziali, compromissione del server Veeam, accesso ai repository, neutralizzazione dei backup, simulazione di esfiltrazione e prova della capacità di cifratura. Non elimina mai backup reali, non esegue cifrature reali e non arresta servizi di produzione o di backup. Ottenete evidenze pronte per l'audit e le criticità gravi vengono sottoposte a retest. L'engagement include anche la verifica dell'integrità del ripristino e dell'immutabilità. È un test puntuale, per cui le esercitazioni di restore regolari del pilastro 3 vanno comunque eseguite.
Parlate con BackupSec della vostra postura di sicurezza dei backup →
Volete vedere come reggerebbero i vostri backup? Il Backup Security Assessment gratuito pone 28 domande in sette aree, dalla strategia di backup e dal controllo degli accessi fino ai test di ripristino.