Cyber event recovery: strutturare un piano d’azione per ripristinare dati, sistemi e servizi

Tradizionalmente le misure di sicurezza aziendali si sono concentrate soprattutto sulla prevenzione dalle minacce: ammesso che questo approccio potesse funzionare in passato, è chiaro come oggi non possa più essere così in quanto, nonostante le misure preventive implementate, un’azienda può in qualsiasi momento diventare vittima di un cyber attacco e deve quindi essere preparata ad affrontare tale eventualità anche mediante un corretto piano di cyber event recovery.

Le misure di sicurezza devono quindi essere implementate su più livelli, per far sì che quando uno dei livelli fallisce possa intervenire il livello successivo. Questo approccio è suggerito anche dai principali standard e framework di sicurezza, come ad esempio il Cybersecurity framework (CSF) del NIST. Il CSF suddivide le misure di sicurezza nelle diverse funzioni qui elencate:

• Identify: si riferisce alla comprensione del contesto aziendale, degli asset che supportano i processi critici di business e dei relativi rischi associati.
• Protect: si riferisce all’implementazione di quelle misure volte alla protezione dei processi di business e degli asset aziendali, indipendentemente dalla loro natura informatica.
• Detect: si riferisce alla definizione e attuazione di attività appropriate per identificare tempestivamente incidenti di sicurezza informatica.
• Respond: si riferisce alla definizione e attuazione delle opportune attività per intervenire quando un incidente di sicurezza informatica sia stato rilevato.
• Recover: si riferisce alla definizione e attuazione delle attività per la gestione dei piani e delle attività per il ripristino dei processi e dei servizi impattati da un incidente.

Cyber event recovery e disaster recovery: le differenze

Fra tutte le funzioni previste dal Cybersecurity framework probabilmente la meno considerata è proprio il recovery, o almeno è considerata solo dal punto di vista del disaster recovery e non del cyber event recovery.

Spesso si tende a confondere disaster recovery e cyber event recovery ma, sebbene ci siano aspetti simili e alcune sovrapposizioni, gli obiettivi sono diversi: scopo principale del disaster recovery è il ripristino dei servizi in seguito ad interruzioni dovute a cause naturali od artificiali garantendo i requisiti di business, mentre il fine principale del cyber event recovery è il ripristino di dati e servizi aziendali dopo un incidente di sicurezza.

Nel campo del cyber event recovery le minacce evolvono molto più velocemente rispetto alle minacce considerate dal disaster recovery; scenari di attacco come i nuovi ransomware che hanno la capacità di distruggere anche i dati di backup richiedono piani di ripristino specifici che devono essere rivisti molto frequentemente.

Il documento del NIST sul cyber event recovery

Nell’ottobre del 2015 il Cybersecurity Strategy Implementation Plan (CSIP), sviluppato da un pool di agenzie governative statunitensi, constatava come le policy e le pratiche, sia a livello federale che delle agenzie, in tema di cyber recovery fossero carenti e disomogenee, dando perciò mandato al National Institute for Standards and Technologies (NIST) di sviluppare una guida per il ripristino rapido dagli incidenti di sicurezza, che fosse focalizzata, ma non limitata, su data breach e campagne distruttive di malware. Nel giugno del 2016 il NIST ha quindi pubblicato il documento “SP 800-14 Guide for Cybersecurity Event Recovery”.

Il CSIP definisce il recovery come “the development and implementation of plans, processes, and procedures for recovery and full restoration, in a timely manner, of any capabilities or services that are impaired due to a cyber event”.

Il NIST, all’interno della SP 800-184 definisce il cyber event (evento di sicurezza) come un incidente di sicurezza, tanto da utilizzare i due termini in maniera interscambiabile e così faremo anche in questo articolo.

La SP 800-184 è focalizzata sull’ultima funzione del CSF, ovvero il Recover e in parte sulla funzione Respond ma, come schematizzato nella figura sottostante, da un lato il Recovery deve dipendere da tutto quanto l’azienda ha implementato nelle altre funzioni e, dall’altro lato, quanto realizzato nell’ambito della funzione Recover attraverso meccanismi di feedback può tradursi in modifiche di quanto implementato nell’ambito delle altre funzioni.

NIST SPNIST SP 800-184 Guide for Cybersecurity Event Recovery Relationship with the NIST CSF (fonte NIST).

Pianificazione del cyber event recovery

Le aziende possono migliorare la loro resilienza rispetto ad eventi di sicurezza assicurando che i loro processi di gestione del rischio includano la pianificazione del recovery in aggiunta alla risposta agli eventi.

Una pianificazione efficace è una componente fondamentale della preparazione di un’azienda per il ripristino da incidenti di sicurezza, in quanto permette all’azienda di riprendersi rapidamente da tali eventi e di ridurre al minimo l’impatto.

Le informazioni raccolte nell’ambito della funzione Identify sono molto importanti per la comprensione dei sistemi aziendali e delle dipendenze necessarie per fornire servizi a supporto della missione. La funzione Identify del CSF suggerisce all’organizzazione di identificare le risorse critiche che sono centrali per la sua missione. Queste risorse devono essere identificate e valutate prima di un incidente, in modo che le risorse e le dipendenze dalla sicurezza siano ben comprese e le priorità di ripristino assegnate correttamente.

Alcuni elementi che costituiscono prerequisiti all’attivazione del cyber event recovery sono elencati di seguito:

• Identificazione delle risorse chiave (es. risorse umane, informazioni, sistemi, partner esterni) che consentono di raggiungere la mission aziendale.
• Classificazione e prioritizzazione delle risorse in base al potenziale impatto di una loro indisponibilità o alla loro criticità; da tale classificazione deriverà la sequenza e la tempistica di ripristino durante o dopo un incidente di sicurezza.
• Mappatura delle dipendenze fra le risorse; ciò permetterà di capire in che modo i servizi critici dell’azienda dipendano da risorse di supporto a diversi livelli.
• Mappatura delle identità; ciò permetterà di evitare di iniziare il restore quando alcune identità aziendali sono ancora compromesse.
• Implementazione di processi e strumenti validi per proteggere l’integrità dei dati mission-critical e il controllo e la gestione dei dati dell’infrastruttura; ciò comporterà la definizione di meccanismi di convalida dell’integrità, strumenti di backup e replica, e strumenti di monitoraggio periodico delle modifiche dei dati.

Il recovery plan

Una componente fondamentale del cyber event recovery è la predisposizione di un recovery plan, in linea con la prima categoria della funzione Recover del CSF, Recovery Planning (RC.RP): “I processi e le procedure di ripristino sono eseguite e mantenute per assicurare un recupero dei sistemi o asset coinvolti da un incidente di cyber security”.

Il recovery plan deve supportare le priorità e gli obiettivi di ripristino sviluppando processi e procedure che ne assicurino il rispetto su tutte le risorse coinvolte da eventuali incidenti di sicurezza.

I processi e le procedure contenute nel recovery plan devono essere completi e modulari, con le procedure utilizzate frequentemente rappresentate in un playbook, ovvero un elenco dettagliato dei passi e delle azioni richiesti dalla procedura.

Per la predisposizione del recovery plan occorre innanzi tutto identificare e documentare il personale chiave che sarà responsabile della definizione dei criteri di ripristino e dei piani associati e assicurarsi che questo personale comprenda i propri ruoli e responsabilità.

Contestualmente alla predisposizione del recovery plan, le politiche, i processi e le procedure di rilevamento e risposta agli incidenti dovranno essere adattate di conseguenza, per garantire che il ripristino non ostacoli una risposta efficace (ad esempio, allertando un avversario o distruggendo erroneamente le prove forensi).

All’interno del piano dovranno essere definiti chiaramente gli obiettivi e l’ambito di comunicazione del ripristino, comprese le regole e i metodi di condivisione delle informazioni.

Un tipico recovery plan include quindi i seguenti argomenti:

• Accordi sugli SLA: dettagli relativi all’accordo sui livelli di servizio che devono essere garantiti e quelli concordati con eventuali fornitori che partecipano al ripristino.
• Attivazione del piano: definizione formale delle condizioni in base alle quali il Recovery Plan deve essere invocato, di chi ha l’autorità di invocarlo e di come deve essere notificata al recovery team la necessità di eseguire attività di ripristino.
• Costituzione del recovery team: formalizzazione dei membri del team dedicato all’implementazione del piano.
• Dettagli e procedure di ripristino specifici: dettagli delle attività di ripristino specifiche che devono essere effettuate dai membri del team di ripristino, compresi eventuali ripristini su sistemi o ambienti alternativi.
• Comunicazioni out of band: modalità di comunicazione alternativi all’interno e all’esterno dell’azienda che non utilizzano i sistemi aziendali, che potrebbero essere non disponibili o controllati da avversari.
• Piano di comunicazione: procedure di notifica e/o escalation interne ed esterne all’azienda prima, durante e dopo il ripristino. Il piano di comunicazione deve essere completo e completamente integrato in politiche, piani, processi e procedure di ripristino.
• Dettagli sull’archiviazione offline o offsite: l’archiviazione offline o offsite è particolarmente utile in caso di ransomware.
• Soluzioni operative alternative: procedure alternative approvate se il sistema informativo non può essere ripristinato entro il Recovery Time Objective (RTO).
• Dettagli sul ripristino di strutture fisiche: informazioni rilevanti per la resilienza di strutture fisiche come uffici o data center.
• Infrastruttura, hardware e software dedicate al ripristino: dettagli relativi ad infrastruttura, hardware e software che hanno lo scopo di fornire servizi durante il processo di ripristino, come ad esempio un sistema di staging per validare l’integrità dei dati ripristinati dal backup.

Cyber event recovery: miglioramento continuo del recovery plan

Il recovery plan non è un’attività da eseguire una tantum. I piani, le politiche e le procedure create devono essere continuamente migliorati applicando le lezioni apprese durante le situazioni di emergenza gestite o i test effettuati e convalidando periodicamente le capacità di ripristino stesse.

Questo aspetto è previsto anche nella categoria “Improvements (RC.IM)” del CSF, che afferma: “I piani di ripristino ed i relativi processi sono migliorati tenendo conto delle ‘lesson learned’ per le attività future”.

Il ripristino dovrebbe quindi essere utilizzato come meccanismo per identificare i punti deboli nelle tecnologie, nei processi e nelle persone che dovrebbero essere affrontati per migliorare la sicurezza dell’azienda e la capacità di soddisfare la sua missione. Poiché il risultato di questi tipi di identificazioni aiuterà a definire obiettivi a lungo termine per l’azienda, il miglioramento continuo del piano di ripristino fa parte della fase strategica.

Affinché il recovery plan possa essere migliorato è fondamentale verificarlo periodicamente mediante varie tipologie di test ed esercitazioni; occorre inoltre che tutto il personale chiave venga formato sui contenuti del piano. A tal proposito ci viene in aiuto un’altra pubblicazione del NIST, ovvero la Special Publication 84, “Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities”, che illustra appunto diverse tipologie di training, esercizi e test.

Training

In questo contesto, con training ci si riferisce alle iniziative che hanno lo scopo di informare il personale rispetto ai propri ruoli e alle proprie responsabilità all’interno del piano IT.

Il training ha lo scopo di preparare il personale alla partecipazione ad esercitazioni, test e situazioni di emergenza reali legate al piano.

Exercises

Un esercizio è una simulazione di un’emergenza progettata per convalidare la fattibilità di uno o più aspetti del piano. Gli esercizi aiutano a identificare le lacune e le incongruenze all’interno dei piani e delle procedure, nonché i casi in cui il personale necessita di ulteriore formazione oppure è necessario modificare la formazione.

In un esercizio, il personale con ruoli e responsabilità in un piano si riunisce per convalidare il contenuto di tale piano attraverso la discussione dei propri ruoli e delle proprie risposte a situazioni di emergenza, l’esecuzione delle risposte in un ambiente operativo simulato o altri mezzi per convalidare le risposte che non implica l’utilizzo dell’effettivo ambiente operativo per l’impiego del personale.

Gli esercizi sono basati su scenari, come per esempio un data breach con esfiltrazione di dati personali oppure un ransomware.

È bene che lo scenario considerato sia piuttosto definito e siano definiti anche il modo in cui l’azienda è venuta a conoscenza dell’incidente, le modalità con cui gli attaccanti sono entrati nella rete aziendale, quali movimenti laterali hanno effettuato, quali sistemi sono stati compromessi. Nell’ambito del recovery plan sono utili due tipologie di esercizi.

Tabletop exercises

Gli esercizi da tavolo sono esercizi basati su una discussione. Le persone coinvolte si incontrano in una stanza per discutere i loro ruoli durante un’emergenza e le risposte a una particolare situazione di emergenza.

Un facilitatore presenta uno scenario e pone ai partecipanti all’esercizio domande relative allo scenario stesso e avvia una discussione tra i partecipanti su ruoli, responsabilità, coordinamento e processo decisionale. Un esercizio da tavolo è basato solo sulla discussione e non implica la distribuzione di attrezzature o altre risorse.

Functional exercises

Gli esercizi funzionali consentono al personale di convalidare in un ambiente simulato la propria preparazione all’operatività richiesta durante la gestione delle emergenze.

Gli esercizi funzionali sono progettati per esercitare i ruoli e le responsabilità di membri del team, procedure e risorse specifici coinvolti in uno o più aspetti funzionali del piano (ad esempio, comunicazioni, notifiche di emergenza, configurazione delle apparecchiature IT).

Gli esercizi funzionali variano in complessità e portata, dalla convalida di aspetti specifici di un piano a esercizi su vasta scala che affrontano tutti gli elementi del piano.

Tests

Un test è uno strumento di valutazione che utilizza una o più metriche con lo scopo primario di convalidare gli aspetti tecnologici del piano e verificare le capacità di ripristino.

Le metriche vengono create sviluppando un piano di test che identifica i sistemi o componenti da testare e gli obiettivi generali del test.

I test che determinano il malfunzionamento o il non funzionamento di componenti o sistemi potrebbero indicare problemi nella formazione del personale o nei piani e nelle procedure di ripristino.

Cyber event recovery: la definizione di metriche

Durante il processo di pianificazione, di test ed esercizio ed esecuzione delle attività di ripristino sopra descritte, la raccolta di metriche specifiche può aiutare al miglioramento continuo del processo.

Tali metriche andrebbero determinate in anticipo, scegliendo metriche che forniscano informazioni utili a supportare i miglioramenti, in modo da capire cosa debba essere misurato e da implementare i processi che permettano di raccogliere i dati rilevanti.

Sarebbe bene che la raccolta dei dati fosse un output automatico delle attività di ripristino.

Naturalmente non tutto può essere misurato, quindi è importante anche identificare quali attività non lo possano essere in modo accurato e ripetibile.

Cyber event recovery: costruzione di un piano d’azione

In caso di un evento di sicurezza i processi e le procedure sviluppate devono essere presentati in modo da essere utilizzabili per ripristinare efficacemente le funzioni aziendali in modo rapido. Il playbook è un modo per esprimere i passi e le azioni necessarie, nonché gli obiettivi da raggiungere per il ripristino da specifiche tipologie di incidente.

Le attività di ripristino possono essere organizzate in due fasi. La prima è la fase tattica, ottenuta soprattutto attraverso l’esecuzione del playbook sviluppato durante la pianificazione; la fase tattica si occupa quindi delle azioni di ripristino stesse che dipendono dalle attività di protezione, rilevamento e risposta implementate nell’ambito del processo del ciclo di vita della gestione del rischio aziendale. Le azioni della fase tattica possono essere organizzate in tre diverse sottofasi: avvio, esecuzione e conclusione.

La seconda è la fase strategica, focalizzata sul miglioramento continuo del ciclo di vita del processo di gestione del rischio dell’azienda guidato dalle attività di ripristino, con l’obiettivo di ridurre la superficie di attacco e di minimizzare i rischi. Le azioni della fase strategica possono essere ulteriormente organizzate in tre diverse sottofasi: pianificazione ed esecuzione, definizione e revisione delle metriche, miglioramento del recovery plan. Le lezioni apprese identificano le lacune e aiutano la pianificazione e l’esecuzione delle altre funzioni del CSF.

La seguente checklist dovrebbe essere inclusa in un playbook per una determinata tipologia di incidente di sicurezza.

Fase tattica

I seguenti passaggi riassumono le attività del team di recupero nella fase tattica.

Avvio:

• Ricevere un briefing dal team di risposta agli incidenti per comprendere l’entità dell’evento.
• Determinare la criticità e l’impatto dell’evento.
• Formulare un approccio e una serie di azioni specifiche.
• Intensificare il monitoraggio e gli alert della rete e dei sistemi.
• Comprendere la motivazione dell’avversario.
• Identificare l’impronta dell’avversario sull’infrastruttura, sui canali di command and control, sugli strumenti e sulle tecniche.
• Informare tutte le parti che le attività di ripristino sono state avviate
• Utilizzare tutte le informazioni disponibili raccolte per creare il piano di ripristino.

Esecuzione

• Iniziare le attività di ripristino convalidando e implementando contromisure in coordinamento con il team di risposta agli incidenti e altro personale addetto alla sicurezza delle informazioni.
• Ripristinare servizi aziendali aggiuntivi e comunicare lo stato del ripristino a parti predefinite.
• Tenere traccia del tempo effettivo di indisponibilità o di capacità diminuita dei servizi critici, confrontando l’interruzione effettiva con i livelli di servizio e i tempi di ripristino concordati.
• Documentare eventuali problemi che si presentano, eventuali indicatori di compromissione e dipendenze appena identificate.
• Coordinarsi con i rappresentanti della direzione, top management, risorse umane e legale per discutere le attività di notifica appropriate.
• Avvio di ulteriori fasi di ripristino, come interazioni esterne e servizi per ripristinare la fiducia e proteggere i componenti.
• Accertarsi che le risorse ripristinate siano completamente funzionanti e soddisfino i requisiti di sicurezza richiesti dal team di sicurezza dell’azienda.

Conclusione

• Verificare che i criteri di ripristino siano stati soddisfatti e dichiarare la conclusione del ripristino tattico.
• Smobilitare il recovery team e far tornare il personale alle normali funzioni lavorative.
• Continuare a monitorare l’infrastruttura per la potenziale persistenza di attività dannose e informare il team di risposta agli incidenti e il recovery team di eventuali prove in tal senso.
• Finalizzare le metriche raccolte durante l’evento.

Fase strategica

I passaggi seguenti riassumono le attività svolte durante la fase strategica.

Pianificazione ed esecuzione

• Supportare i vari team di comunicazione mentre interagiscono con utenti interni e clienti.
• Chiudere i punti sospesi con eventuali entità esterne coinvolte durante la fase tattica.
• Sviluppare un piano per correggere la causa principale dell’evento.
• Implementare modifiche per rafforzare la sicurezza dell’azienda.

Metriche

• Una volta completato il ripristino, rivedere le metriche raccolte.
• Rivedere il raggiungimento dei traguardi chiave e le ipotesi che sono state fatte prima del recupero.

Miglioramento del Recovery Plan

• Utilizzare le lezioni apprese dal processo di ripristino per migliorare il piano.

Conclusione

In questo articolo si è inteso presentare il tema non molto conosciuto del cyber event recovery a partire dai contenuti della SP 800-184 del NIST.

Tale pubblicazione, come rimarcato in più punti, non ha lo scopo di fornire un documento pronto all’uso per il ripristino dagli eventi di sicurezza, ma rappresenta una guida per lo sviluppo di piani di ripristino sotto forma di playbook personalizzati sulle caratteristiche e le peculiarità dell’azienda.

Come indicato in questo articolo, un playbook è un piano d’azione che documenta una serie di passi attuabili che l’azienda deve seguire per ripristinare con successo dati sistemi e servizi in seguito ad un evento di sicurezza.