Cos’è un piano di risposta agli incidenti e come crearne uno

Un piano di risposta agli incidenti assicura che, in caso di violazione della sicurezza, siano presenti il personale e le procedure giuste per affrontare efficacemente una minaccia. Avere un piano di risposta agli incidenti assicura che un’indagine strutturata possa avere luogo per fornire una risposta mirata per contenere e porre rimedio alla minaccia.

È venerdì pomeriggio e dopo una settimana costante di lavoro per l’helpdesk IT della vostra azienda i vostri pensieri sono rivolti a quella bottiglia di vino freddo che avete in frigo, l’accompagnamento perfetto per una serata tranquilla a guardare Netflix. Il pensiero viene interrotto quando squilla il telefono della tua scrivania, probabilmente un altro dipendente che richiede il reset della password.

Tuttavia, il panico nella voce del chiamante diventa rapidamente evidente, non possono aprire nessuno dei loro file e stanno chiedendo se sai cos’è un pagamento in bitcoin? Probabilmente non è un grosso problema, il malware su un singolo portatile non è la fine del mondo. Tuttavia, ti giri e vedi più telefoni che squillano in giro per l’ufficio, la situazione ora sembra un po’ più seria di un singolo portatile infettato da un malware. A peggiorare le cose, un collega si china per dirvi che anche un server contenente i dati dei clienti è stato infettato da un ransomware.

Questo scenario si è verificato molte volte in tutto il mondo, l’efficacia della vostra risposta a questa situazione dipende dalla risposta a una domanda: “Avete un piano di risposta agli incidenti?”

Perché hai bisogno di un piano di risposta agli incidenti

È fondamentale che un’azienda abbia un piano di risposta agli incidenti in modo che sotto la pressione di un incidente possano essere prese le decisioni corrette per riportare la situazione sotto controllo. Un incidente di cybersecurity può essere una situazione molto scoraggiante, se la risposta non è condotta in modo orchestrato allora il potenziale risultato potrebbe portare a gravi danni alla reputazione di un marchio.

Per affrontare efficacemente un incidente di cybersecurity, la vostra azienda avrà bisogno di un team specializzato nella risposta agli incidenti. Alcune organizzazioni chiamano questo team il Computer Security Incident Response Team (CSIRT) – ci sono altre permutazioni di questo acronimo là fuori come Security Incident Response Team (SIRT) o Computer Incident Response Team (CIRT). La missione di questo team è la stessa, non importa come lo si chiami: mettere in atto il piano di risposta agli incidenti stabilito dall’azienda quando il bat-segnale si alza.

Se si lavora nella sicurezza dei dati, si ha a che fare con incidenti di sicurezza su base giornaliera. Di tanto in tanto, un piccolo problema di sicurezza si trasforma in una vera e propria situazione di panico. Quando il bat-segnale si accende, tutti sapranno cosa fare? Ogni membro del CSIRT conoscerà il proprio ruolo e le proprie responsabilità e seguirà il piano approvato?

Quando la posta in gioco diventa alta e la pressione si intensifica, il CSIRT si comporterà come si è esercitato. Se non c’è un piano in atto, non c’è garanzia che saranno in grado di rispondere correttamente a un incidente di cybersecurity.

Tuttavia, avere semplicemente un piano IR non è sufficiente: il team CSIRT deve avere le competenze e l’esperienza per affrontare una situazione potenzialmente ad alto stress come questa. Gli esperti di Digital Forensics, gli analisti di malware, gli Incident Manager e gli analisti SOC saranno tutti pesantemente coinvolti e saranno gli uomini sul campo che si occuperanno della situazione. Ciò implica prendere decisioni chiave, condurre un’indagine approfondita, fornire un feedback ai principali stakeholder e, infine, dare rassicurazioni al senior management che la situazione è sotto controllo.

In cima a tutto questo, c’è spesso una stretta temporale. Le leggi sulla notifica delle violazioni dei dati stanno diventando più comuni: il GDPR, per esempio, richiede che le aziende segnalino gli incidenti di sicurezza dei dati entro 72 ore dalla scoperta.

La mia esperienza di lavoro sugli incidenti di cybersecurity mi ha mostrato il valore di avere un piano di risposta agli incidenti. Sono stato chiamato nelle prime ore del mattino in un incidente per scoprire che si era verificata una violazione della cybersecurity, il CEO sta cercando il CSIRT per avere risposte e indicazioni su come evitare il disastro. Il piano di risposta agli incidenti significa che le persone giuste, con le giuste competenze ed esperienze saranno su quella chiamata, ognuno sa cosa ci si aspetta da loro e quali procedure devono essere seguite per contenere e rimediare con successo alla minaccia. Avere questa struttura sul posto si è sempre dimostrato inestimabile.

Considerazioni per la pianificazione della risposta agli incidenti

Il piano di risposta agli incidenti sarà composto da criteri chiave che possono essere sviluppati man mano che la postura di sicurezza di un’azienda matura. Ci sono diverse considerazioni da fare quando si costruisce un piano di risposta agli incidenti.

Il sostegno del senior management è fondamentale. Costruire un piano di risposta agli incidenti non dovrebbe essere un esercizio di spunta delle caselle. Se non è sostenuto dal senior management, allora rischia di essere archiviato fino a quando non sarà necessario. L’alta dirigenza dovrebbe delineare ciò che è necessario dal punto di vista dei processi e delle persone e garantire che venga fornito tutto il supporto necessario.

Definire gli stakeholder chiave. I dettagli di contatto per gli individui e i team chiave dentro e fuori l’orario di lavoro devono essere documentati.

Comunicare chiaramente. La proprietà dell’invio delle comunicazioni, l’assegnazione dei compiti e le azioni appropriate devono essere stabilite. Inoltre, considerate chi deve essere incluso in qualsiasi comunicazione di un incidente e quanti dettagli sono necessari a seconda del pubblico. I compiti assegnati ai team di sicurezza devono essere precisi e tecnici, mentre gli aggiornamenti al consiglio dovranno essere chiari e privi di qualsiasi gergo tecnico.

Definire cosa costituisce un incidente. Specificare quali eventi possono essere gestiti come business as usual o quando è tutto un gioco di prestigio e una chiamata per incidente deve essere messa in piedi.

• CONSIGLIO CHIAVE: Una matrice di triage fornirà una comprensione della gravità di un incidente in modo da poterne dare la priorità rapidamente e correttamente.

Piani e procedure sono importanti. Tuttavia, è il CSIRT che eseguirà il piano di risposta agli incidenti e il recupero dell’incidente. Il CSIRT sarà composto da vari team e ogni ruolo è fondamentale per trasformare un incidente da un potenziale disastro a una storia di successo. Il CSIRT è un mix di personale esperto, tecnico e non tecnico che lavora insieme per capire la portata dell’incidente, come può essere mitigato e infine rimediato. Le persone giuste devono essere assunte e messe sul posto.

Anche l’automazione è la chiave per la pianificazione della risposta agli incidenti, capire quali strumenti di sicurezza sono in atto insieme alla loro capacità e copertura significa che un certo livello di automazione sarà possibile. I controlli di sicurezza finemente sintonizzati assicurano che la vostra prima linea di difesa, il Security Operations Center (SOC), stia rispondendo ad allarmi significativi e legittimi. Avere avvisi affidabili e finemente sintonizzati significa che alcune aree del processo di risposta agli incidenti possono essere avviate automaticamente e che può essere possibile che il triage iniziale e la raccolta di prove per un incidente siano generati automaticamente. Se la vostra automazione sta generando un gran numero di falsi positivi, non solo questo causerà affaticamento in un’area chiave del vostro IRP, ma è anche più probabile che perdiate un allarme chiave se si perde tra il rumore dei falsi positivi.

Accanto a un piano di risposta agli incidenti, un’azienda deve anche considerare di avere un piano di disaster recovery. Mentre un IRP è progettato per rimediare alla minaccia di un incidente, un DRP è progettato per ripristinare la funzionalità di un’azienda e riportarla online dopo un grave disastro naturale o causato dall’uomo. Se l’azienda non può funzionare, allora il DRP delineerà i passi necessari per riportare l’azienda online.

Un’azienda potrebbe anche aver bisogno di considerare se è interessata dal Payment Card Industry Data Security Standard (PCI DSS). Questo è applicabile se un’azienda elabora, archivia o trasmette i dati delle carte di credito dei clienti.

Chi è responsabile all’interno di un piano di risposta agli incidenti

Il CSIRT è composto da team specializzati che hanno ciascuno un ruolo importante da svolgere quando si tratta di un incidente.

I Security Operations Center (SOC) sono la prima linea di difesa. Sono i soldati sul campo che operano 24 ore al giorno, 7 giorni alla settimana. Il loro ruolo è quello di smistare ogni allarme di sicurezza, raccogliere le prove e determinare l’azione appropriata. Lavorando a turni, gli analisti SOC devono avere una vasta comprensione delle minacce alla sicurezza informatica, avranno accesso a varie piattaforme e strumenti di sicurezza come le soluzioni SIEM (Security Incident Event Manager) e EDR (Endpoint Detection & Response). Questi strumenti possono generare una vasta gamma di avvisi che possono variare da attacchi DDoS a comandi malevoli eseguiti su un dispositivo, gli analisti del SOC devono essere in grado di capire e interpretare questi dati. Se un incidente è considerato ad alta priorità o non rientra nelle competenze del SOC, allora il loro punto di escalation è il team di Incident Management.

Il ruolo di un Incident Manager mi è stato descritto da un collega come “L’arte di guidare i gatti”. Il loro lavoro consiste nel mettere le braccia intorno a un incidente, riunire le principali parti interessate e guidare la discussione per determinare il miglior piano d’azione. Il team di Incident Management è il generale, gli vengono fornite prove, consigli e opinioni e stabilisce il ritmo di un incidente. Identificano quali compiti devono essere completati, chi deve completarli e quando devono essere completati. Tutte le chiamate e le comunicazioni dell’incidente che devono essere programmate sono completate dall’Incident Management.

Il team CIRT sono i soldati delle operazioni speciali, sono coinvolti solo in incidenti di alto profilo e ad alta priorità e quando non sono coinvolti in incidenti stanno affinando e sviluppando le loro competenze. Mentre gli analisti del SOC avranno un ampio set di competenze, il team CIRT sarà composto da individui con competenze e interessi specializzati come analisti di malware ed esperti di digital forensics. Questo team fornisce consulenze e analisi tecniche esperte e viene assegnato da Incident Management ai compiti che non possono essere svolti dal SOC.

Il team Threat Intelligence sono gli scout che valutano e comprendono il panorama delle minacce informatiche. Se l’incidente si riferisce a un server compromesso contenente dati sensibili, allora perlustreranno il dark web alla ricerca di prove che i dati siano in vendita. Se l’incidente si riferisce a un’infezione da malware, il team di intelligence condurrà una ricerca OSINT (Opensource Intelligence) sulla famiglia di malware e consiglierà sulla probabilità che si tratti di un attacco mirato contro la vostra organizzazione.

6 passi per creare un Incident Response Plan

SANS ha pubblicato il suo Incident Handler’s Handbook qualche anno fa, e rimane lo standard per i piani IR. Si tratta di una struttura in 6 passi che potete usare per costruire il vostro piano aziendale specifico.

Preparazione

La preparazione per ogni potenziale incidente di sicurezza è la chiave per una risposta di successo. Raccomando vivamente di sviluppare alcuni playbook che forniscano una guida al SOC durante il triage di un incidente, questi daranno chiare istruzioni su come dare priorità a un incidente e quando dovrebbe essere escalation. Questi dovrebbero essere di alto livello e focalizzati su aree specifiche come DDoS, Malware, Insider Threat, accesso non autorizzato e Phishing. I playbook e le procedure dovrebbero essere testati sulle persone e sui team che li utilizzeranno. Gli esercizi da tavolo sono un modo eccellente per solidificare le conoscenze e vedere se è possibile apportare dei miglioramenti.

Identificazione

È possibile rimuovere con successo una minaccia alla sicurezza solo quando si conoscono le dimensioni e la portata di un incidente. Iniziate con il “paziente zero”, il dispositivo iniziale compromesso. L’obiettivo è quello di capire la causa principale della compromissione, tuttavia non concentratevi solo su un dispositivo, la minaccia potrebbe essersi diffusa e spostata lateralmente?

La vera identificazione di un incidente deriva dalla raccolta di indicatori utili di compromissione (IOC). Piuttosto che limitarsi a ricostruire il dispositivo originale infetto, cercate di identificare qualsiasi IOC unico che possa essere utilizzato per cercare ulteriori prove di compromissione in tutta la vostra proprietà. Se l’incidente si riferisce a un’infezione da malware, porre le seguenti domande: quali connessioni di rete genera il malware? Il malware si collega a qualche dominio? Quali file vengono creati su disco? Quali processi in esecuzione vengono creati? Ci sono chiavi di registro uniche che sono state create? Questi dati possono essere utilizzati per cercare ulteriori prove di compromissione e identificare qualsiasi altra macchina infetta nella vostra proprietà.

Contenimento

Una volta che la portata di un incidente è stata identificata con successo, il processo di contenimento può iniziare. Questo è il momento in cui i dispositivi compromessi all’interno della proprietà vengono isolati dal resto della rete per fermare la diffusione di un attacco.

Il contenimento a breve termine può essere utilizzato per isolare un dispositivo che è stato preso di mira dal traffico di attacco. Il contenimento a lungo termine può essere necessario quando è richiesta un’analisi in profondità che può richiedere molto tempo. Questo può comportare la presa di un’immagine del dispositivo e la conduzione di analisi forensi del disco rigido. Questo può generare ulteriori CIO e la fase di identificazione può dover essere rivisitata.

Eradicazione

Una volta che l’incidente è contenuto con successo, può iniziare l’eliminazione della minaccia. Questo varia a seconda di ciò che ha causato la compromissione di un dispositivo. Patchare i dispositivi, disarmare il malware, disabilitare gli account compromessi sono tutti esempi di ciò che può essere richiesto nella fase di eliminazione di un incidente.

Recupero

L’obiettivo della fase di recupero di un incidente è quello di ripristinare il normale servizio al business. Se sono disponibili backup puliti, questi possono essere utilizzati per ripristinare il servizio. In alternativa, qualsiasi dispositivo compromesso dovrà essere ricostruito per garantire un recupero pulito. Potrebbe essere necessario implementare un monitoraggio aggiuntivo dei dispositivi colpiti.

Lezioni apprese

Una volta che la minaccia è stata completamente rimediata, il passo successivo prevede di rispondere alla domanda “come facciamo a impedire che questo accada di nuovo? Un incontro noto come Post Incident Review (PIR) dovrebbe avere luogo e coinvolgere i rappresentanti di tutti i team coinvolti nell’incidente. Questa è la piattaforma per discutere cosa è andato bene durante l’incidente e cosa può essere migliorato. È qui che il piano di risposta all’incidente viene perfezionato sulla base dei risultati del PIR, e le procedure e i libri di gioco vengono modificati per riflettere qualsiasi cambiamento concordato.

Incident Response Plan Best Practices

Creare libri di gioco. La creazione di playbook guiderà il SOC su come trattare i vari incidenti e raccogliere le prove pertinenti. Concentratevi sui principali scenari di attacco che le aziende devono affrontare: malware, DDoS, accesso non autorizzato, phishing e minaccia interna. Questi documenti dovrebbero delineare cosa fa scattare un’escalation al team di gestione degli incidenti e consigliare quali prove devono essere raccolte. Manteneteli di alto livello, non dovrebbero essere troppo granulari e diventare troppo complessi.

Eseguite esercizi sulle minacce informatiche. Preparatevi per la cosa reale facendo wargaming con alcuni scenari di attacco, questo può essere anche semplice come organizzare alcuni esercizi da tavolo. Creare alcuni scenari di attacco che possono essere discussi dai team interessati è un ottimo modo per testare qualsiasi playbook che è stato messo in atto, questo aiuterà anche a identificare eventuali lacune in un piano di risposta agli incidenti e dovrebbe essere rivisto almeno una volta all’anno.

Avviare la caccia alle minacce. Aspettare che scatti un allarme su una nuova piattaforma scintillante è una cosa, ma cercare proattivamente attività sospette è il punto in cui i team di risposta agli incidenti iniziano a maturare. Non solo è probabile che un potenziale compromesso venga trovato prima, ma gli individui che stanno eseguendo queste indagini ad hoc stanno sviluppando la loro mentalità investigativa. Queste abilità e questo tipo di mentalità sono esattamente ciò che è richiesto durante la fase di identificazione di un incidente, interrogando il traffico di rete, guardando le porte insolitamente utilizzate e i processi insoliti per capire le dimensioni di un incidente. Se il SOC ha una forte comprensione di ciò che è “normale”, diventa molto più facile individuare le attività dannose.

Modelli di piani di risposta agli incidenti

Creare un piano per gli incidenti può sembrare abbastanza scoraggiante. Tuttavia, l’utilizzo di un modello fornirà la struttura e la direzione su come sviluppare un piano di risposta agli incidenti di successo.

Guida alla pianificazione NCSC – Il NCSC (National Cyber Security Centre) è un’organizzazione del governo britannico che fornisce supporto alla sicurezza informatica alle organizzazioni critiche del Regno Unito. Essendo una grande autorità in materia di sicurezza informatica, le loro raccomandazioni si riveleranno preziose quando si pianifica un piano di risposta agli incidenti.

Sysnet’s Incident Response Template – Delinea come riconoscere un incidente di sicurezza, ruoli e responsabilità delle principali parti interessate, fasi del piano di risposta agli incidenti e ciò che deve essere considerato per i vari tipi di incidenti.

Incidentresponse.com ha fornito diversi modelli di playbook che coprono scenari come malware, phishing, accesso non autorizzato, e sono tutti mappati al NIST incident response framework. Questi saranno documenti separati a sé stanti, ma dovrebbero essere referenziati nel piano di risposta agli incidenti.

Per aiutare a capire quando un piano di risposta agli incidenti potrebbe essere utilizzato il webinar di Varonis sulla risposta agli incidenti mostra una simulazione di attacco dal vivo. Durante questa simulazione, i nostri analisti della sicurezza offrono un breve tour di Varonis per Office 365, eseguono l’attacco dall’intrusione all’escalation dei privilegi all’esfiltrazione, quindi mostrano come utilizzare DatAlert per rilevare e rispondere.

Cosa fare dopo un incidente informatico?

La polvere si deposita, i cattivi sono stati sconfitti e il team CSIRT ha seguito il piano IR alla lettera. Cosa fare dopo? Fare il punto della situazione e rifornirsi per il prossimo incontro.

Rafforzare il piano IR o cercare di migliorare il monitoraggio che è già in atto, ci sono registri aggiuntivi che non erano disponibili durante un incidente e devono essere abilitati? C’è un gap di competenze all’interno del team di sicurezza? La politica di patching dell’azienda deve essere rivista? Rivedere e perfezionare costantemente il processo degli incidenti assicura che non solo venga migliorata la risposta a un incidente, ma che venga anche ridotta la superficie di attacco. Se vengono effettuati controlli e miglioramenti aggiuntivi alla postura di sicurezza di un’azienda, allora questo si tradurrà in un minor numero di incidenti di sicurezza.