Ransomware: perché avere il backup non basta a ripartire

Avere una copia dei dati è la condizione di partenza, non l'arrivo. Dopo un attacco ransomware — un programma che cifra i file e chiede un riscatto per sbloccarli — per tornare operativi servono tre cose: copie integre e pulite, un ordine di ripristino deciso in anticipo e una persona che stabilisca quando è sicuro riaccendere. Questo articolo percorre i tre passaggi, con uno scenario ragionato e senza allarmismi.

Lo scenario: sistemi cifrati, copie presenti

La situazione tipo è nota: un mattino i file sui server risultano illeggibili, i programmi non si aprono e compare una richiesta di riscatto. I backup, sulla carta, ci sono: i job sono schedulati, i rapporti dicono «completato». Eppure tra «abbiamo le copie» e «siamo di nuovo operativi» c'è un percorso fatto di verifiche tecniche, scelte di priorità e decisioni di responsabilità. È questo percorso che spesso manca, non la copia in sé.

Vale la pena inquadrare il problema nel modo giusto. La pubblicazione NIST SP 800-61 revisione 3, pubblicata nell'aprile 2025, colloca la risposta agli incidenti dentro la gestione complessiva del rischio: preparazione, rilevamento, risposta e recupero sono attività collegate, che coinvolgono persone e terze parti, non un'operazione tecnica isolata. Il ripristino dei dati è una parte del recupero, e il recupero è una parte della risposta all'incidente. Trattare il backup come un fatto a sé è il primo errore.

Cosa può rendere inutilizzabile anche la copia di riserva

La domanda da porsi non è «abbiamo il backup?» ma «quella copia ci permette davvero di ripartire?». Le cause per cui la risposta può essere no sono concrete e verificabili in anticipo:

• La copia era raggiungibile dalla rete compromessa. Se l'archivio di backup è sempre collegato e scrivibile dagli stessi account colpiti, può essere cifrato o cancellato insieme ai dati. È il motivo per cui si parla di copie offline o non modificabili: un requisito da verificare presso il fornitore, come spieghiamo nell'articolo sul backup immutabile e sulle verifiche da fare.
• La copia è integra ma contaminata. Se l'intruso era dentro da settimane, le copie recenti possono contenere già il codice dannoso o le credenziali rubate. Ripristinarle così come sono riporta il problema in casa.
• Le credenziali del backup sono compromesse. Se l'attaccante controlla gli account amministrativi, può aver modificato schedulazioni, conservazione o destinazioni delle copie prima ancora di cifrare.
• La copia non è mai stata provata. Al primo ripristino reale emergono licenze mancanti, configurazioni non salvate, chiavi di cifratura introvabili. Il rapporto «backup completato» non dimostra la recuperabilità.
• Il punto di recupero è troppo vecchio. Se l'ultima copia utile risale a una settimana prima e l'azienda non può perdere una settimana di ordini, il backup esiste ma non rispetta l'obiettivo. Su quanta perdita è tollerabile si decide prima, definendo RPO e RTO in modo consapevole.

La guida NIST SP 1339, pubblicata in versione finale nel giugno 2026, è dedicata al backup negli ambienti industriali (OT, operational technology), ma i suoi punti portanti valgono come ragionamento generale: integrare i backup nella gestione dei cambiamenti, crearli con regolarità, testarli e riesaminarli durante le esercitazioni di recupero. Sono indicazioni volontarie, non obblighi di legge, ma descrivono bene la differenza tra avere copie e avere un percorso di ripristino.

Integrità e pulizia prima del ripristino

Prima di riportare in produzione qualsiasi cosa, occorre rispondere a due domande: da quando l'attacco era in corso? Qual è l'ultima copia precedente a quel momento? La risposta arriva dall'incrocio di registri, allarmi e attività osservate, e spesso richiede il supporto del fornitore di sicurezza o del tecnico che segue l'infrastruttura.

Le copie candidate vanno poi verificate in un ambiente isolato, separato dalla rete di produzione: si ripristina lì, si controllano i file con gli strumenti di sicurezza, si avviano i servizi e si osserva il comportamento. Solo una copia che supera queste verifiche merita di tornare in produzione. È un passaggio che costa ore, talvolta giorni, ma saltarlo significa rischiare di ripristinare l'attacco insieme ai dati.

In che ordine ripristinare i sistemi

Non si ripristina tutto insieme, e non si ripristina nell'ordine in cui i sistemi vengono in mente. Un criterio pratico è ragionare per dipendenze e per impatto:

1. Prima le fondamenta: identità e accessi (dominio, account), rete e servizi di base. Senza di questi, nient'altro funziona in modo affidabile.
2. Poi i sistemi che tengono in piedi l'attività: quello che permette di produrre, spedire, fatturare o erogare il servizio ai clienti.
3. Infine il resto: sistemi secondari, archivi consultabili, postazioni di lavoro.

Ogni applicazione ha le sue dipendenze interne — un gestionale non riparte se prima non è attivo il suo database — e anche questa sequenza va scritta prima dell'emergenza, come vediamo nell'articolo dedicato al ripristino di un'applicazione intera e all'ordine di riavvio. L'importante, qui, è il principio: l'ordine di ripristino è una decisione presa a freddo, con chi conosce l'attività, non un'improvvisazione durante la crisi.

Chi decide quando è sicuro riaccendere

Riaccendere troppo presto è il rischio speculare di ripartire troppo tardi: se la via d'ingresso dell'attacco è ancora aperta — un account compromesso, un accesso remoto non protetto, un dispositivo infetto — i sistemi ripristinati possono essere cifrati di nuovo. La decisione spetta a una persona con responsabilità chiara, in genere il titolare o il responsabile IT, sulla base di due condizioni: il contenimento è stato eseguito e verificato, e le copie ripristinate sono state controllate.

Il contenimento, a sua volta, non è un riflesso automatico: è un piano con autorizzazioni chiare, che indica quali misure prendere (per esempio bloccare account specifici o isolare parti di rete), quali impatti operativi comportano e chi le approva. Misure decise al buio possono interrompere attività legittime o disperdere evidenze utili a ricostruire l'accaduto. Anche la comunicazione durante l'incidente — chi avvisa i clienti, i fornitori, i dipendenti — va gestita come parte del piano, come trattiamo nell'articolo sulla comunicazione durante un incidente informatico.

Esempio illustrativo: il lunedì della distribuzione

Esempio illustrativo. Lo scenario seguente è inventato e serve a mostrare il percorso; non racconta un incidente avvenuto presso un cliente.

Un'azienda di distribuzione alimentare con una trentina di dipendenti trova, di lunedì mattina, cifrati il server degli ordini e quello della fatturazione. I rapporti del backup sono regolari, ma il disco di rete su cui arrivavano le copie è stato cifrato anche lui: era sempre collegato e scrivibile. Resta una copia su supporto esterno, staccato il venerdì sera, e una serie di copie presso un fornitore cloud con conservazione non modificabile per trenta giorni.

Il tecnico, con il titolare, ricostruisce la sequenza: dagli allarmi del fornitore di sicurezza l'attività anomala risulta iniziata il giovedì precedente. La copia di venerdì è quindi a rischio; si sceglie di partire dalla copia cloud di mercoledì sera, ripristinata in un ambiente isolato. Lì i file risultano puliti e il gestionale funziona. Solo a quel punto si pianifica il rientro: prima il dominio e gli account, con le password azzerate; poi il database degli ordini; poi l'applicativo; infine le postazioni. Il titolare autorizza la riaccensione dopo che il contenimento — blocco dell'account usato dall'intruso e chiusura dell'accesso remoto scoperto durante l'indagine — è stato eseguito e verificato. L'azienda perde i dati da giovedì a domenica: un costo reale, che il piano aveva reso prevedibile e che la direzione aveva implicitamente accettato scegliendo la frequenza delle copie. È il genere di conseguenza che conviene conoscere prima.

Come si inserisce OverZeus in questo percorso

OverZeus non è un motore di backup e non sostituisce la piattaforma di copia che già usi. Sul tema intervengono in particolare due agenti, nel rispetto del principio «lui si accorge, tu decidi»:

• Penelope sorveglia backup, conservazione e preparazione al ripristino tramite le piattaforme collegate: rileva un job fallito, segnala quando l'ultimo punto di recupero supera l'obiettivo concordato e propone prove di recupero in ambiente isolato. Lo stato del backup, da solo, non dimostra la recuperabilità: per questo le prove di ripristino rientrano nel programma di verifiche periodiche che Penelope aiuta a tenere visibile e tracciato.
• Ares organizza la risposta all'incidente: raccoglie le evidenze, propone priorità e prepara un piano di contenimento con misure specifiche e impatti dichiarati. Ogni intervento attivo segue il piano e richiede l'approvazione prevista; nessuna misura parte da sola e il silenzio non autorizza.

Le decisioni arrivano ai responsabili tramite Hermes, l'app che raccoglie approvazioni e rifiuti; Mnemosyne conserva fonti, proposte, autorizzazioni ed esiti, in modo che dopo l'incidente si possa ricostruire chi ha deciso cosa e perché. Queste evidenze supportano attività richieste da quadri come NIS2 o ISO 27001, senza che questo equivalga a una conformità automatica.

La differenza tra copie e ripartenza

Il backup è una materia prima: diventa ripartenza solo se le copie sono protette dall'attacco, verificate nella loro integrità, ordinate in una sequenza pensata prima e riattivate quando qualcuno, con le informazioni giuste, decide che è sicuro. Tutti questi passaggi si preparano a freddo. Il momento peggiore per scoprire cosa manca è il lunedì mattina in cui i file non si aprono.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus