Come costruire un piano di risposta agli incidenti intorno al processo di risposta agli incidenti SANS, esempi per iniziare e un picco sull’automazione della risposta agli incidenti.
Hai bisogno di una soluzione di risposta agli incidenti? Clicca qui per una demo sulla risposta agli incidenti.
In questo post imparerai:
- Cos’è un piano di risposta agli incidenti e perché ne hai bisogno?
- Il ciclo di risposta agli incidenti
- Perché è importante un piano di risposta agli incidenti?
- Il piano di risposta agli incidenti rispetto al piano di disaster recovery
- Le sei fasi della risposta agli incidenti
- Modello del piano di risposta agli incidenti
- Esempi di piano di risposta agli incidenti
- La prossima generazione di risposta agli incidenti
Cos’è un piano di risposta agli incidenti e perché ne avete bisogno?
Un piano di risposta agli incidenti è un insieme di strumenti e procedure che il vostro team di sicurezza può utilizzare per identificare, eliminare e recuperare dalle minacce alla sicurezza informatica. È progettato per aiutare il vostro team a rispondere in modo rapido e uniforme contro qualsiasi tipo di minaccia esterna.
I piani di risposta agli incidenti assicurano che le risposte siano il più efficaci possibile. Questi piani sono necessari per ridurre al minimo i danni causati dalle minacce, tra cui la perdita di dati, l’abuso di risorse e la perdita di fiducia dei clienti.
Un piano di risposta agli incidenti costituisce la base del vostro ciclo di risposta agli incidenti:
Figura 1: Gli elementi di un ciclo di risposta agli incidenti
Un piano di risposta agli incidenti non è completo senza un team che lo porti a termine: il Computer Security Incident Response Team (CSIRT). Un team di risposta agli incidenti è un gruppo di persone – sia personale IT con una certa formazione sulla sicurezza, sia personale di sicurezza a tempo pieno in organizzazioni più grandi – che raccolgono, analizzano e agiscono in base alle informazioni di un incidente.
Sono il punto focale dell’incidente e sono responsabili della comunicazione con altre parti interessate all’interno dell’organizzazione e con parti esterne, come consulenti legali, stampa, forze dell’ordine, clienti interessati, ecc.
Perché è importante un piano di risposta agli incidenti?
Il Ponemon Institute’s 2017 Cost of Cyber Crime Study ha mostrato che l’organizzazione media perde 11,7 milioni di dollari all’anno a causa dei danni dei cyber-attacchi. Un processo di risposta efficace può agire per ridurre significativamente questi costi.
I piani di risposta agli incidenti sono importanti anche per proteggere i vostri dati. La protezione delle risorse di dati durante il processo di risposta agli incidenti include backup sicuri, l’utilizzo di log e avvisi di sicurezza per rilevare attività dannose, una corretta gestione delle identità e degli accessi per evitare minacce interne e una forte attenzione alla gestione delle patch.
Infine, la pianificazione della risposta agli incidenti protegge la reputazione dell’azienda. IDC ha scoperto che l’80% dei consumatori porterebbe i propri affari altrove se colpiti direttamente da una violazione dei dati. Se una violazione della sicurezza non viene gestita correttamente e rapidamente, l’azienda rischia di perdere affari. La fiducia degli investitori e degli azionisti può diminuire drasticamente in seguito a una violazione dei dati pubblicizzata.
Un piano di risposta agli incidenti (IRP) aiuta a prepararsi e idealmente a prevenire gli incidenti di sicurezza. Le risposte dettate dall’IRP possono anche avere alcuni effetti positivi meno ovvi sulla vostra organizzazione, tra cui:
- La protezione dei dati – la protezione dei dati e dei sistemi è al centro dell’IRP. La protezione si ottiene mettendo in sicurezza i backup, assicurando una gestione sufficiente delle identità e degli accessi e applicando tempestivamente le patch alle vulnerabilità. Queste misure sono supportate da una risposta rapida agli avvisi e da un’attenta analisi dei log e dei dati degli eventi.
- Rafforza la reputazione: una risposta efficace agli incidenti dimostra l’impegno di un marchio verso la sicurezza e la privacy. Gli attacchi con conseguente perdita di dati possono far dubitare i clienti della competenza di un’organizzazione, portando all’abbandono del marchio. Allo stesso modo, gli azionisti e gli investitori possono abbandonare un’azienda che ha subito una violazione. L’IRP può prevenire o minimizzare queste perdite.
- Riduce i costi: le violazioni sono costose, a causa delle multe normative, del risarcimento dei clienti o semplicemente del costo delle indagini e del ripristino dei sistemi. Secondo uno studio del 2019 di IBM, il costo medio di una violazione è di quasi 4 milioni di dollari. Gli IRP possono aiutare a ridurre il rischio di violazione e a limitare i danni causati dagli attacchi, limitando i costi.
Qual è la relazione tra un piano di risposta agli incidenti e un piano di recupero di emergenza?
Un piano di risposta agli incidenti dovrebbe essere integrato da un piano di recupero di emergenza. Quest’ultimo prescrive come un’organizzazione gestisce un evento catastrofico come un disastro naturale o una perdita accidentale di dati. Mentre un piano di risposta agli incidenti si concentra sull’identificazione di un evento di sicurezza e sulla sua chiusura, il disaster recovery mira a riportare i sistemi online, nel rispetto di un obiettivo di tempo di recupero (RTO).
Considerazioni chiave per la pianificazione della risposta agli incidenti
Un piano di risposta agli incidenti dovrebbe includere i seguenti elementi per essere efficace:
- Il supporto del senior management-il supporto del management vi permetterà di reclutare i membri più qualificati per il vostro team di risposta e di creare processi e flussi di informazioni che vi aiuteranno a gestire efficacemente un incidente.
- Test consistenti-un piano di risposta agli incidenti non vale molto se è solo sulla carta, deve essere messo alla prova. Condurre un’esercitazione di sicurezza pianificata (o meglio ancora, non pianificata), esaminando il piano e identificando i punti deboli, sarà molto importante per convalidare che il team sia pronto per un vero incidente.
- Equilibrio tra dettaglio e flessibilità: il piano deve avere passi specifici e fattibili che il team può seguire rapidamente quando si verifica un incidente. Allo stesso tempo, creare processi rigidi porta alla complessità e all’incapacità di affrontare scenari inaspettati. Creare un piano dettagliato, ma consentire la flessibilità per supportare una vasta gamma di incidenti. Aggiornare frequentemente il piano può anche aiutare con la flessibilità: rivedere il piano ogni sei mesi o giù di lì può aiutarvi a tenere conto dei nuovi tipi di problemi di sicurezza e degli attacchi che colpiscono il vostro settore.
- Chiarire i canali di comunicazione: il piano dovrebbe chiarire con chi il team che si occupa degli incidenti deve comunicare, attraverso quali canali di comunicazione e quali informazioni devono essere trasmesse. Questa è una parte critica e a volte trascurata del processo di risposta. Per esempio, ci dovrebbero essere linee guida chiare su quale livello di dettaglio deve essere comunicato al management IT, al senior management, ai dipartimenti interessati, ai clienti interessati e alla stampa.
- Conoscete i vostri stakeholder: quali sono i ruoli chiave all’interno dell’organizzazione che dovrebbero preoccuparsi ed essere coinvolti in un incidente di sicurezza? Questi potrebbero cambiare a seconda del tipo di incidente e delle risorse organizzative interessate. Le parti interessate potrebbero includere i responsabili di reparto, il senior management, i partner, i clienti e l’ufficio legale.
- Mantenere il piano semplice: un noto principio di gestione, “Keep it Simple Stupid” (KISS), dovrebbe essere applicato anche ai piani di risposta. Un piano complicato, anche se ben pensato, non è probabile che venga seguito accuratamente in tempo reale. Mantenete i dettagli, i passi e le procedure al minimo assoluto, per garantire che il team possa elaborarli e applicarli all’incidente mentre entra nella “nebbia di guerra”.
I 6 passi dell’Incident Response del SANS Institute
Secondo l’Incident Handbook del SANS Institute, ci sono sei passi che dovrebbero essere fatti dal team di Incident Response, per gestire efficacemente gli incidenti di sicurezza. Il vostro piano di risposta dovrebbe affrontare e fornire un processo strutturato per ciascuna di queste fasi.
1. Preparazione
Nella fase di preparazione, è necessario rivedere e codificare la politica di sicurezza sottostante che informa il piano di risposta agli incidenti. Eseguire una valutazione dei rischi e dare priorità ai problemi di sicurezza, identificare quali sono le risorse più sensibili e, per estensione, quali sono gli incidenti di sicurezza critici su cui il team dovrebbe concentrarsi. Create un piano di comunicazione e preparate una documentazione che indichi chiaramente e brevemente i ruoli, le responsabilità e i processi.
La pianificazione non è sufficiente: dovete anche reclutare i membri del CIRT, formarli, assicurarvi che abbiano accesso a tutti i sistemi rilevanti e agli strumenti e alle tecnologie di cui hanno bisogno per identificare gli incidenti e rispondere ad essi.
2. Identificazione
Il team dovrebbe essere in grado di rilevare efficacemente le deviazioni dalle normali operazioni nei sistemi organizzativi e identificare se tali deviazioni rappresentano veri e propri incidenti di sicurezza.
Quando viene scoperto un potenziale incidente, il team dovrebbe immediatamente raccogliere ulteriori prove, decidere il tipo e la gravità dell’incidente e documentare tutto ciò che sta facendo. La documentazione dovrebbe rispondere alle domande “Chi, Cosa, Dove, Perché e Come” per permettere agli aggressori di essere perseguiti in tribunale in una fase successiva.
3. Contenimento
Una volta che il team identifica un incidente di sicurezza, l’obiettivo immediato è quello di contenere l’incidente e prevenire ulteriori danni. Questo comporta:
- Contenimento a breve termine-questo può essere semplice come isolare un segmento di rete che è sotto attacco o togliere i server di produzione che sono stati violati e stanno deviando il traffico ai server di backup.
- Contenimento a lungo termine-applicare correzioni temporanee ai sistemi colpiti per permettere loro di essere usati in produzione, mentre si ricostruiscono sistemi puliti, preparandosi a portarli online nella fase di recupero.
4. Eradicazione
Il team deve identificare la causa principale dell’attacco, la rimozione del malware o delle minacce, e prevenire attacchi simili in futuro. Per esempio, se un meccanismo di autenticazione debole è stato il punto di ingresso dell’attacco, dovrebbe essere sostituito con un’autenticazione forte; se una vulnerabilità è stata sfruttata, dovrebbe essere immediatamente patchata.
5. Recupero
Il team riporta online i sistemi di produzione colpiti con attenzione, per assicurarsi che un altro incidente non abbia luogo. Decisioni importanti in questa fase sono l’ora e la data in cui ripristinare le operazioni, come testare e verificare che i sistemi interessati siano tornati alla normalità e per quanto tempo monitorare i sistemi per assicurarsi che l’attività sia tornata alla normalità.
6. Lessons Learned
Questa fase dovrebbe essere eseguita non più tardi di due settimane dalla fine dell’incidente, per garantire che le informazioni siano fresche nella mente del team. Lo scopo di questa fase è quello di completare la documentazione che non ha potuto essere preparata durante il processo di risposta e indagare ulteriormente sull’incidente per identificarne l’intera portata, come è stato contenuto e sradicato, cosa è stato fatto per recuperare i sistemi attaccati, le aree in cui il team di risposta è stato efficace e quelle che richiedono un miglioramento.
Modello del piano di risposta all’incidente
Seguono quattro modelli dettagliati che potete utilizzare per dare il via alla pianificazione della risposta all’incidente:
Il modello del piano di risposta all’incidente di TechTarget (14 pagine) include la portata, gli scenari di pianificazione e gli obiettivi di recupero; una sequenza logica di eventi per la risposta all’incidente e ruoli e responsabilità del team; procedure di notifica, escalation e dichiarazione; e liste di controllo della risposta all’incidente.
>> Scarica il modello
Il modello di risposta agli incidenti di Thycotic (19 pagine) include ruoli, responsabilità e informazioni di contatto, classificazione delle minacce, azioni da intraprendere durante la risposta agli incidenti, normative specifiche del settore e dipendenti dalle aree geografiche e un processo di risposta, oltre a istruzioni su come personalizzare il modello in base alle proprie esigenze specifiche.
>> Scarica il modello (richiede la registrazione)
Il piano di risposta agli incidenti di sicurezza di Sysnet (11 pagine) include come riconoscere un incidente, ruoli e responsabilità, contatti esterni, fasi iniziali di risposta e istruzioni per rispondere a diversi tipi di incidenti comuni, come malware e accesso wireless non autorizzato.
>> Scarica il modello (richiede la registrazione)
Il piano di risposta agli incidenti del Dipartimento della Tecnologia del governo della California (4 pagine) include una lista di controllo in 17 fasi da seguire per i membri del team degli incidenti, con riferimenti a procedure più dettagliate per tipi specifici di incidenti (che dovrai creare tu stesso).
>> Scarica il modello
Esempi di piani di risposta agli incidenti
Quando si sviluppa un piano per gli incidenti, è utile vedere esempi reali di piani creati da altre organizzazioni. Alcuni degli esempi non saranno applicabili agli scenari di incidenti del tuo settore, ma possono darti qualche ispirazione.
Guarda gli esempi di piani delle seguenti organizzazioni:
- Carnegie Mellon University-inclusi definizioni, ruoli e responsabilità, metodologia, fasi di risposta agli incidenti, linee guida per minacce interne e interazione con le forze dell’ordine, e documentazione.
- Tulane University-inclusa la portata, i ruoli e le responsabilità, le definizioni degli incidenti, i livelli di escalation e le fasi di risposta per livello di criticità.
- Write State University-inclusa la portata, le fasi di risposta, l’uso di strumenti di sicurezza e una lista di controllo delle intrusioni.
La prossima generazione di Incident Response: Security Orchestration and Automation (SOAR)
Non c’è nessun sostituto per la creazione di un piano di risposta agli incidenti e l’assegnazione di individui dedicati ad esserne responsabili. Tuttavia, per rendere la risposta agli incidenti più efficace e permettere di affrontare più incidenti di sicurezza, si è evoluta una nuova categoria di strumenti che aiuta ad automatizzare la risposta agli incidenti di sicurezza.
Gli strumenti di Security Orchestration and Automation (SOAR) possono:
- Integrarsi con altri strumenti di sicurezza, orchestrarli per consentire una risposta complessa a un attacco
- Automatizzare le procedure di risposta multi-fase utilizzando i playbook di sicurezza
- Supportare la gestione dei casi registrando tutte le informazioni relative a un incidente di sicurezza specifico, creando una timeline completa dell’evento, e aiutando gli analisti a collaborare e ad aggiungere dati e approfondimenti all’evento
Per vedere un esempio di una soluzione di sicurezza integrata che include SOAR e funzionalità UEBA (User Entity Behavioral Analytics) e SIEM (Security Information and Event Management), vedi Incident Responder di Exabeam.
Vuoi saperne di più sull’Incident Response?
Guarda questi articoli:
- I tre elementi dell’Incident Response: Piano, squadra e strumenti
- La guida completa all’organizzazione del CSIRT: Come costruire un Incident Response Team
- 10 Best Practices per creare un efficace Computer Security Incident Response Team (CSIRT)
- Come implementare rapidamente un’efficace Incident Response Policy
- Sicurezza IT: Quello che dovresti sapere
- Passi di risposta agli incidenti: 6 suggerimenti per rispondere agli incidenti di sicurezza
- Beat Cyber Threats with Security Automation
- Sicurezza IPS: come la sicurezza attiva fa risparmiare tempo e blocca gli attacchi sul nascere
Hai bisogno di una soluzione di incident response? Clicca qui per una demo sulla risposta agli incidenti.