Avere un backup non significa essere pronti a recuperare da un attacco ransomware. Durante un incidente cyber il problema non è soltanto ripristinare dati e sistemi: bisogna capire quali copie siano affidabili, evitare di reintrodurre malware o persistenze, rispettare le dipendenze tra i workload e riportare in produzione i servizi nell’ordine corretto.
È qui che entra in gioco il Cyber Recovery Runbook: una sequenza definita e verificabile di attività che trasforma il recovery da procedura improvvisata a processo operativo ripetibile. Il runbook non sostituisce un Incident Response Plan, ma ne costituisce il braccio tecnico nella fase di ripristino.
Playbook, runbook e Incident Response Plan: non sono la stessa cosa
Nel linguaggio cybersecurity i termini vengono spesso usati in modo intercambiabile, ma conviene separarli.
- Un playbook descrive come l’organizzazione affronta uno scenario: decisioni, ruoli, escalation, comunicazioni e attività tecniche.
- Un runbook traduce una parte del playbook in una sequenza operativa più precisa: quali sistemi recuperare, in quale ordine, da quale punto di ripristino, con quali verifiche e quali condizioni di uscita.
- L’Incident Response Plan governa l’intero ciclo dell’incidente: preparazione, detection, analisi, contenimento, eradicazione, recovery e lezioni apprese.
In un attacco ransomware, quindi, il runbook di cyber recovery deve essere coordinato con il processo di risposta all’incidente, ma non deve tentare di sostituirlo.
Perché il normale Disaster Recovery non basta contro un ransomware
Un piano di Disaster Recovery tradizionale nasce principalmente per recuperare da guasti, indisponibilità di infrastruttura o eventi fisici. In un cyberattacco il presupposto cambia: il dato o il sistema da ripristinare potrebbe essere già compromesso.
Ripristinare semplicemente “l’ultimo backup disponibile” può essere una scelta sbagliata se l’attaccante era presente nell’ambiente da giorni o settimane. Un processo di Ransomware Recovery deve quindi introdurre controlli aggiuntivi: ricerca di un restore point affidabile, scansione, isolamento, validazione e ritorno controllato alla produzione.
Cosa deve contenere un Cyber Recovery Runbook
Un runbook utile non è una lista generica di best practice. Deve essere costruito sull’ambiente reale e indicare almeno:
- chi autorizza l’avvio del recovery e chi può modificarne il piano;
- quali applicazioni e workload sono business-critical;
- le dipendenze tra identità, database, file server, applicazioni e servizi cloud;
- RTO e RPO concordati con il business;
- i criteri per scegliere un punto di ripristino considerato affidabile;
- le scansioni e le verifiche da completare prima di rimettere i dati in produzione;
- l’ordine di recupero dei sistemi;
- i test funzionali post-restore e i criteri di accettazione;
- le evidenze da conservare per audit, assicurazione cyber e post-incident review.
Druva Cyber Recovery Runbooks: cosa cambia nel 2026
La piattaforma Druva ha evoluto questo concetto in una funzione specifica di Cyber Recovery Runbooks. Il modello non è più soltanto “backup + restore”, ma un workflow di recovery threat-aware che può essere predisposto prima dell’incidente e poi eseguito in modo controllato.
Per una panoramica della piattaforma, consulta anche Druva: Cloud Backup e Data Protection. In questa pagina il focus resta invece esclusivamente sull’orchestrazione del cyber recovery.
1. Scheduled Cyber Recovery Testing: testare prima dell’emergenza
Un runbook non dovrebbe essere validato per la prima volta durante un attacco. Druva prevede piani di Scheduled Cyber Recovery Testing che consentono di eseguire prove periodiche del processo di recovery.
Il valore operativo è misurare se il percorso di ripristino funziona davvero: risorse recuperate, tempi di esecuzione, esito delle scansioni, errori e dipendenze non previste. In questo modo il test di restore diventa parte della governance della Data Protection as a Service e non una verifica occasionale.
2. Live Incident Recovery: eseguire il piano durante un incidente reale
Durante un evento ransomware, il Live Incident Recovery Plan consente di applicare il runbook predisposto allo scenario reale. La priorità è recuperare da uno snapshot adeguato, verificare il contenuto e riportare online i workload senza trasformare il restore in una nuova via di reinfezione.
3. Restore point e scansione: recuperare il dato giusto, non soltanto il più recente
Il punto di ripristino deve essere scelto considerando la finestra dell’incidente. Druva può utilizzare criteri di snapshot e controlli di threat scan per individuare dati sospetti prima o durante il processo di recovery.
Questo passaggio è fondamentale perché l’immutabilità del backup protegge la copia dalle modifiche dell’attaccante, ma non garantisce automaticamente che ogni snapshot sia antecedente alla compromissione. Backup immutabile e clean recovery sono due controlli diversi e complementari.
4. Isolated Recovery Environment: quando serve una clean room
Per workload VMware, Druva supporta un Isolated Recovery Environment (IRE): un ambiente separato nel quale ripristinare e validare le macchine virtuali senza collegarle immediatamente alla rete di produzione.
L’isolamento consente di eseguire controlli, verificare applicazioni e servizi ed evitare che un workload ancora compromesso comunichi con la produzione. L’IRE non va però presentato come funzionalità indistinta per tutti i workload: nella documentazione Druva corrente è specifico per VMware.
5. Microsoft 365: runbook anche per Exchange Online, OneDrive e SharePoint
I Cyber Recovery Runbooks Druva supportano anche workload Microsoft 365 come Exchange Online, OneDrive e SharePoint. In questi scenari non si parla di una VM da accendere in una clean room, ma di un piano che stabilisce risorse, snapshot, destinazione e modalità di restore.
Il principio resta lo stesso: predefinire il recovery prima dell’incidente, evitare decisioni improvvisate e poter dimostrare cosa è stato recuperato e con quale esito.
6. Report di recovery: trasformare il test in evidenza
Un piano di recovery deve produrre evidenze. I report dei Cyber Recovery Runbooks possono includere risorse recuperate, snapshot selezionati, durata del recovery, esito delle scansioni, file malevoli individuati ed eventuali errori.
Queste informazioni sono utili non soltanto al team IT, ma anche per audit, verifiche di continuità operativa, assessment interni e confronto con gli obiettivi RTO/RPO.
Un esempio pratico di runbook ransomware
Un runbook reale può essere articolato in una sequenza simile a questa:
- Dichiarazione incidente: Il responsabile autorizza l’attivazione del piano e congela le modifiche non necessarie.
- Definizione perimetro: Si identificano workload compromessi, identità coinvolte, dipendenze e priorità di business.
- Selezione restore point: Si sceglie uno snapshot coerente con la timeline dell’incidente e con le evidenze disponibili.
- Threat scan: Si verificano indicatori, file sospetti e segnali di compromissione prima del rientro in produzione.
- Recovery isolato: Quando previsto, si ripristinano i sistemi in ambiente separato e si applicano controlli di rete e sicurezza.
- Validazione: Si controllano integrità dati, servizi applicativi, identità, dipendenze e configurazioni.
- Rientro controllato: I sistemi vengono riportati in produzione secondo la sequenza definita e monitorati intensivamente.
- Evidenze e review: Si archiviano i risultati del recovery e si aggiornano runbook, controlli e priorità sulla base delle lezioni apprese.
Druva non sostituisce il processo organizzativo
L’automazione riduce errori e tempi, ma non elimina le decisioni che devono essere prese dall’organizzazione. Un Cyber Recovery Runbook deve rimanere coerente con il piano di Incident Response, con gli owner applicativi, con le policy di comunicazione e con le responsabilità di business.
Allo stesso modo, la piattaforma non sostituisce un servizio di backup aziendale correttamente progettato: retention, immutabilità, copie, credenziali amministrative, test e monitoraggio rimangono prerequisiti della capacità di recupero.
Quando ha senso adottare un Cyber Recovery Runbook
- l’azienda ha workload critici e non può affidarsi a procedure di restore “a memoria”;
- il recovery coinvolge più sistemi con dipendenze e sequenze precise;
- sono presenti VMware o workload Microsoft 365 che devono essere ripristinati in modo coordinato;
- esiste un requisito di test periodico della capacità di recovery;
- serve produrre evidenza documentale del recovery per audit o assicurazione cyber;
- l’organizzazione vuole collegare backup, ransomware recovery e Incident Response in un unico processo operativo.
Dal backup alla cyber resilience
Il salto di qualità non consiste nell’aggiungere un’altra copia dei dati, ma nel sapere come tornare operativi quando l’ambiente è sotto attacco. Un backup è una risorsa; il runbook definisce come usarla.
Nexsys integra Druva nei propri servizi di Data Protection as a Service e Ransomware Recovery, collegando protezione dei dati, test di recovery e procedure di risposta all’incidente.
FAQ
Che differenza c’è tra playbook e Cyber Recovery Runbook?
Il playbook descrive l’approccio complessivo a uno scenario, inclusi ruoli e decisioni. Il Cyber Recovery Runbook definisce in modo più operativo come eseguire e verificare il ripristino dei workload.
Un Cyber Recovery Runbook sostituisce l’Incident Response Plan?
No. Il runbook copre principalmente la fase tecnica di recovery e deve essere coordinato con il piano di Incident Response, che governa l’intero incidente.
Druva può testare il recovery prima di un ransomware?
Sì. I Scheduled Cyber Recovery Testing Plan consentono di provare periodicamente il processo di recovery e produrre evidenze dell’esecuzione.
Druva usa sempre un ambiente isolato per il recovery?
No. L’Isolated Recovery Environment documentato da Druva è specifico per VMware. Per Microsoft 365 il runbook utilizza modalità di restore adatte a Exchange Online, OneDrive e SharePoint.
Un backup immutabile garantisce che il dato ripristinato sia pulito?
No. L’immutabilità impedisce la modifica o cancellazione non autorizzata della copia, ma il restore point deve comunque essere scelto e validato rispetto alla timeline della compromissione.
Quali workload supportano i Cyber Recovery Runbooks Druva?
La documentazione Druva corrente indica VMware e, per Microsoft 365, Exchange Online, OneDrive e SharePoint. Disponibilità e funzionalità possono dipendere da licenza, regione e SKU.
Vuoi trasformare il backup in un piano di recovery realmente testabile?
Nexsys può progettare il runbook, definire priorità e dipendenze, configurare Druva e integrare test periodici e recovery ransomware con il tuo processo di Incident Response. Contattaci per una verifica del piano di recovery.