Incident Response:
cos’è e come organizzarlo
Cosa si intende con Incident Response
Il cosiddetto Incident Response, abbreviato con IR, è un approccio organizzato e strategico per rilevare e gestire gli attacchi informatici in modo da ridurre al minimo i danni, i tempi di ripristino e i costi totali.
Volendo essere più precisi, la risposta agli incidenti è un sottoinsieme della gestione degli incidenti generali di un’organizzazione, un termine per indicare la governance degli attacchi informatici che prendono di mira un’azienda e che coinvolge diverse parti interessate, dai manager ai legali, risorse umane, persino marketing e comunicazione, oltre ovviamente all’IT.
La risposta agli incidenti è la parte della gestione degli incidenti che gestisce le attività e le considerazioni tecniche sulla sicurezza informatica.
Molti esperti usano i termini “Incident Response” e gestione degli incidenti in modo intercambiabile, visto che entrambi lavorano per garantire la continuità aziendale di fronte a una crisi di sicurezza, come una violazione dei dati.
Chi si occupa dell’Incident Response in azienda?
Dietro ogni grande programma di risposta agli incidenti c’è un team di risposta efficiente ed efficace.
Dopotutto, senza le persone giuste che li supportino e li mettano in pratica, le politiche, i processi e gli strumenti di sicurezza significano ben poco.
Questo gruppo interfunzionale è composto da figure provenienti da diverse parti dell’organizzazione, che sono responsabili del completamento delle fasi e dei processi coinvolti nella risposta agli incidenti.
I tre tipi più comuni di team di risposta agli incidenti sono i seguenti:
- Team di risposta agli incidenti di sicurezza informatica (CSIRT).
- Team di risposta agli incidenti informatici (CIRT).
- Squadra di risposta alle emergenze informatiche (CERT).
Questi acronimi sono spesso usati in modo equivoco sul campo, perché le squadre generalmente hanno gli stessi obiettivi e responsabilità.
Una nota importante è che il nome CERT è un marchio registrato della Carnegie Mellon University, quindi, le aziende devono richiedere l’autorizzazione per utilizzarlo.
Un altro termine comunemente sentito durante una conversazione del team di risposta agli incidenti è centro operativo di sicurezza (SOC).
Un SOC comprende le persone, gli strumenti e i processi che gestiscono il programma di sicurezza di un’organizzazione.
Sebbene i team SOC possano essere responsabili della risposta agli incidenti, non è il loro unico compito all’interno di un’organizzazione. Gli altri possono includere la conservazione dei registri delle attività e la garanzia della conformità normativa dell’azienda.
La dimensione di un team di risposta agli incidenti e i membri inclusi variano in base alle esigenze della singola organizzazione.
Alcuni possono persino ricoprire più ruoli e responsabilità.
In generale, un team di risposta agli incidenti è composto dai seguenti membri:
Team tecnico
Questo è il team principale di risposta agli incidenti, con competenze tecniche nei sistemi aziendali.
Spesso include un responsabile della risposta agli incidenti, un coordinatore, un capo del team, analisti della sicurezza, ricercatori di minacce e analisti forensi.
Manager Esecutivo
Questo è un dirigente o un membro del consiglio, spesso il CSO o CISO
Squadra di Comunicazione
Include i rappresentanti delle pubbliche relazioni e altri che gestiscono le comunicazioni interne ed esterne.
Stakeholder esterni
I membri includono altri dipendenti o dipartimenti all’interno dell’organizzazione, come i team IT, legale o generale, risorse umane, pubbliche relazioni, continuità aziendale e ripristino di emergenza, sicurezza fisica e strutture.
Terzi
Questi membri esterni potrebbero includere consulenti per la sicurezza o la risposta agli incidenti, rappresentanza legale esterna, MSP, fornitori di servizi di sicurezza gestiti, fornitori di servizi cloud (CSP) e partner.
Gli obiettivi principali di un team di risposta agli incidenti sono rilevare e rispondere agli eventi di sicurezza e ridurre al minimo il loro impatto sul business.
Pertanto, le responsabilità si allineano ampiamente con le fasi delineate in un quadro e un piano di risposta agli incidenti, che vedremo più avanti.
Le attività del team includono:
- Prevenire gli incidenti di sicurezza
- Creare il piano di risposta agli incidenti
- Testare, aggiornare e gestire il piano di risposta agli incidenti prima dell’uso
- Esegui esercitazioni da tavolo sulla risposta agli incidenti
- Sviluppare metriche per analizzare le iniziative del programma
- Identificare gli eventi di sicurezza
- Contenere gli eventi di sicurezza, mettere in quarantena le minacce e isolare i sistemi
- Sradicare le minacce, scoprire le cause alla radice e rimuovere i sistemi interessati dagli ambienti di produzione
- Ripristino dalle minacce con il ritorno online dei sistemi interessati
- Condurre attività di follow-up, compresa la documentazione, l’analisi degli incidenti e l’identificazione su come prevenire eventi simili e migliorare gli sforzi di risposta futuri
- Rivedere e aggiornare regolarmente il piano di risposta agli incidenti
L’Incident Response Plan: cos’è e a che cosa serve
Sebbene la necessità di avere piani di risposta agli incidenti sia chiara, una maggioranza di organizzazioni non ne ha uno o non sa come usarlo.
Secondo un sondaggio di Ponemon, il 77% degli intervistati afferma di non disporre di un piano formale di risposta agli incidenti applicato in modo coerente in tutta l’organizzazione e quasi la metà afferma che il proprio piano è inesistente.
Tra coloro che hanno piani IR, solo il 32% descrive le proprie iniziative come “mature”.
Queste cifre sono preoccupanti, soprattutto se si considera che per molte organizzazioni il tempo necessario per risolvere gli incidenti informatici si sta allungando, in uno scenario che vede un aumento degli attacchi.
Piano di risposta agli incidenti
Un piano di risposta agli incidenti è il set di documentazione di riferimento di un’organizzazione che descrive in dettaglio quanto segue:
- Che cosa. Quali minacce, exploit e situazioni si qualificano come incidenti di sicurezza perseguibili e cosa fare quando si verificano.
- Chi. In caso di incidente di sicurezza, chi è responsabile di quali compiti e come gli altri possono contattarli.
- Quando. In quali circostanze i membri del team dovrebbero svolgere determinati compiti.
- Come. In particolare, come i membri del team dovrebbero completare tali attività.
Un piano di risposta agli incidenti funge da mappa dettagliata e autorevole, guidando i team dal rilevamento iniziale alla valutazione di un incidente, contenimento e risoluzione.
Una risposta agli incidenti di successo richiede la stesura, il controllo e il test proattivi dei piani prima che si verifichi una crisi.
Le Best Practices
Le best practices includono quanto segue:
- Stabilire le policy
Una politica di riparazione e risposta agli incidenti dovrebbe essere un documento sempreverde che descriva le priorità generali di gestione degli incidenti di alto livello.
Una buona politica dà potere ai soccorritori e li guida nel prendere decisioni valide quando i proverbiali escrementi colpiscono il ventilatore.
- Creare un team di risposta agli incidenti.
Un piano di risposta agli incidenti è forte quanto le persone coinvolte.
Bisogna allora stabilire chi si occuperà di quali compiti e assicurarsi che tutti dispongano di una formazione adeguata per adempiere ai propri ruoli e responsabilità.
- Creare playbook.
I playbook sono la linfa vitale della risposta agli incidenti.
Sebbene una politica di risposta agli incidenti offra una visione di alto livello, i playbook entrano nel dettaglio, delineando le azioni standardizzate e dettagliate che i team dovrebbero intraprendere in scenari specifici.
- Creare un piano di comunicazione.
Un piano di risposta agli incidenti non può avere successo senza un solido piano di comunicazione tra le diverse parti interessate.
Questi possono includere i team di risposta agli incidenti, dirigenti, dipartimento marketing & comunicazione, legali, risorse umane, nonché clienti, partner di terze parti, forze dell’ordine e il pubblico in generale.
In generale, un piano di risposta agli incidenti dovrebbe includere i seguenti componenti:
- Una panoramica del piano
- Un elenco di ruoli e responsabilità
- Un elenco di incidenti che richiedono un’azione
- Lo stato attuale dell’infrastruttura di rete e dei controlli di sicurezza
- Procedure di rilevamento, indagine e contenimento
- Procedure di sradicazione
- Procedure di recupero
- Il processo di notifica della violazione
- Un elenco di attività di follow-up post-incidente
- Un elenco di contatti
- Test del piano di risposta agli incidenti
- Revisioni in corso
Fasi dell’Incident Response
Secondo il National Institute of Standards and Technology (NIST), ci sono quattro fasi chiave per dar seguito ad un IR:
1. Preparazione/Pianificazione
Creare un team di risposta agli incidenti e politiche, processi e playbook; implementare strumenti e servizi per supportare la risposta agli incidenti.
2. Rilevamento/Identificazione
Utilizzare il monitoraggio IT per rilevare, valutare, convalidare e classificare gli incidenti di sicurezza.
3. Contenimento
Adottare misure per impedire il peggioramento di un incidente e riprendere il controllo delle risorse IT.
4. Eradicazione
Eliminare l’attività delle minacce, inclusi malware e account utente dannosi; identificare eventuali vulnerabilità sfruttate dagli aggressori.
5. Recupero
Ripristinare le normali operazioni e mitigare le vulnerabilità rilevanti.
6. Lezioni imparate
Rivedere l’incidente per stabilire cosa è successo, quando è successo e come.
Etichettare i controlli, le politiche e le procedure di sicurezza che hanno funzionato in modo non ottimale e identificare i modi per correggerle.
Aggiornare di conseguenza il piano di risposta agli incidenti con quanto appreso, per ottimizzarlo di volta in volta.
Non esiste uno strumento di risposta agli incidenti valido per tutti.
Piuttosto, è necessario un mix di strumenti e tecnologie per aiutare i team di risposta agli incidenti a prevenire, rilevare, analizzare, contenere, eliminare e recuperare dagli incidenti.
Strumenti e processi di risposta agli incidenti
La maggior parte delle organizzazioni dispone già di una varietà di strumenti e processi di risposta agli incidenti in fase di implementazione.
Tipicamente classificati in base alle loro funzionalità di rilevamento, prevenzione e risposta, questi includono:
- Software antimalware
- Strumenti di backup e ripristino
- Broker di sicurezza per l’accesso al cloud
- Strumenti di classificazione dei dati
- Prevenzione della perdita di dati
- Mitigazione DoS
- Formazione sulla sicurezza dei dipendenti
- Rilevamento e risposta degli endpoint
- Firewall
- Analisi forense
- Sistemi di prevenzione e rilevamento delle intrusioni
- Informazioni sulla sicurezza e gestione degli eventi (SIEM)
- Orchestrazione, automazione e risposta della sicurezza (SOAR)
- Gestione delle vulnerabilità
La gestione di tutti questi strumenti può essere molto impegnativa per un team di sicurezza.
Molte organizzazioni si stanno rivolgendo all’automazione nella risposta agli incidenti per ridurre lo sforzo sugli avvisi, per eseguire procedure preliminari in autonomia, come l’invio di ticket, indagare e rispondere automaticamente alle minacce, e preservare le risorse umane per attività di maggior valore.
Con la proliferazione dell’uso del cloud, aumenta anche l‘importanza di includere la nuvola nei processi di risposta agli incidenti.
Gli obiettivi della risposta agli incidenti nel cloud sono gli stessi dell’IR tradizionale, ma con alcuni avvertimenti.
Si consideri, ad esempio, il modello di responsabilità condivisa.
Con applicazioni, piattaforme e infrastrutture locali, i team IT e di sicurezza di un’organizzazione sono generalmente responsabili di tutte le attività di gestione e security.
Con SaaS, PaaS e IaaS, invece, alcune o tutte le responsabilità passano ai CSP. Ciò può rendere il rilevamento e l’indagine degli incidenti più difficili o addirittura impossibili, a seconda dell’implementazione.
La risposta agli incidenti nel cloud può anche richiedere nuovi strumenti e set di competenze, nonché una conoscenza più approfondita degli incidenti stessi.
Ultimi post
- Intranet aziendale
- Sprint Execution
- Network Access Control
- Container as a Service
- Red team e Blue team
Categorie
Tag