La capacità di rispondere a un eventuale attacco informatico rappresenta un valore fondamentale per le aziende di tutto il globo. Un valore in grado di determinare il successo o il fallimento dell’impresa: la sicurezza informatica, infatti, è essenziale per il business, per diverse motivazioni e sotto differenti punti di vista.
Saper gestire gli incidenti di sicurezza in modo tempestivo, quindi, è estremamente importante. Per far ciò, molte imprese scelgono di creare un team specializzato ad hoc, in grado di portare a termine le 7 diverse fasi del processo di incident response.
Ma cos’è l’incident response? Scopriamo tutto quel che c’è da sapere al riguardo: le 7 fasi del processo di incident response, come creare un efficace incident response plan e il ruolo del team dedicato al progetto.
Indice dei contenuti
Cos’è l’incident response?
L’incident response è l’insieme dei processi utili per rispondere, in modo rapido ed efficace, ai possibili incidenti di sicurezza informatica. L’obiettivo dell’incident response plan è quello di ridurre al minimo i possibili danni, favorendo il ripristino immediato delle attività, dei dati aziendali e dei sistemi.
L’incident response plan ha lo scopo di risolvere gli incidenti di sicurezza informatica, riportando il livello di sicurezza e le attività ad una condizione “normale” (ovvero, alla condizione precedente all’incidente).
Le imprese adottano strategie di sicurezza informatica predisponendo un preciso piano di incident response (IRP), il quale viene affidato al cosiddetto CSIRT (Computer Security Incident Response Team). Il piano di incident response è costituito dall’insieme di istruzioni operative e di modelli di comportamento utili in caso di incidente. Il team di lavoro si occuperà di seguire le procedure di emergenza determinate dall’incident response plan qualora si verifichi, o ci sia il sospetto che stia per verificarsi, un incidente di sicurezza informatica.
L’incident response plan
L’incident response plan deve essere estremamente puntuale, chiaro ed efficace. Questo piano strategico raccoglie le informazioni riguardo procedure e comportamenti da seguire per risolvere le situazioni di emergenza, rispondendo ad attacchi malware, ransomware, phishing, denial-of-service (DDoS), intrusioni nei sistemi della rete o internal threats (sabotaggio, errori umani ed errori comportamentali interni).
Lo scopo del piano di incident response è quello di rispondere tempestivamente agli incidenti, rilevandoli con puntualità affinché possano verificarsi danni e rischi informatici limitati. La classica struttura dell’incident response plan prevede 7 fasi.
| Fase | Obiettivo |
| Preparation | Predisposizione delle condizioni ideali per l’attuazione del piano di incident response. |
| Identification e scoping | Rilevamento degli incidenti e analisi dei comportamenti dell’attaccante. |
| Containment | Contenimento dei rischi associati all’incidente. |
| Eradication e remediation | Rimozione della minaccia. |
| Recovery | Recupero dell’attività e dei sistemi. |
| Follow up | Analisi dell’incidente, delle sue cause e dei suoi effetti. |
| Test | Esecuzione di penetration test e valutazioni pratiche riguardo la sicurezza informatica. |
Le 7 fasi dell’incident response
L’incident response plan prevede un percorso end-to-end, sequenziale e generalmente dalla natura ciclica. Questo piano mira a garantire un ottimo livello di resilienza alle aziende.
Generalmente, il piano di incident response non deve limitarsi a procedure inerenti all’ambito IT, ma deve considerare anche qualsiasi altro incidente che possa compromettere, anche in modo indiretto, la sicurezza informatica aziendale.
Il piano di incident response viene realizzato dal team dedicato, sia esso in-house oppure in outsourcing. Questo piano non va confuso con il piano di continuità del business, contenente le indicazioni utili alla gestione di guasti e imprevisti di natura generale.
Valutiamo, adesso, le 7 fasi dell’incident response plan in modo dettagliato.
Preparation
Durante la fase di preparazione vengono eseguite attività propedeutiche, mirate alla creazione delle migliori condizioni utili per la gestione degli incidenti. La preparation è una fase fondamentale, durante la quale vengono predisposte le azioni da intraprendere per prevenire o risolvere un incidente di sicurezza informatica. Durante questo frangente, vengono definite le procedure operative e vengono configurati i sistemi di monitoraggio e sicurezza aziendali.
Identification e scoping
Questa seconda fase del piano di incident response rappresenta uno dei passaggi più critici e onerosi (in termini temporali). Identificare l’incidente e tutto ciò che a esso è correlato non è semplice. Bisogna analizzare lo scenario, determinando quanto è complessa la rete, le sue dimensioni, le capacità tecniche di chi sta attaccando, quante e quali sono le macchine compromesse.
La fase di identification è fondamentale poiché è solo identificando la natura del problema che sarà possibile risolverlo e rimuovere ogni sua traccia. Passare alla fase di eradication e remediation senza aver eseguito in modo esaustivo la fase di identification potrebbe generare molti più problemi. L’attaccante, se il problema non viene risolto in modo radicale, potrebbe attuare delle contromisure negative per continuare a manomettere i sistemi.
Anche per questo alla fase di identification viene sempre associata anche la fase di scoping, utile per comprendere l’obiettivo dell’attaccante. Vengono, quindi, raccolti i threat pattern e gli IOC che verranno successivamente utilizzati per la rimozione della problematica. Devono essere analizzati anche altri fattori, come: modalità di accesso alla rete da parte dell’attaccante, analisi dei movimenti laterali e dei malware utilizzati durante l’attacco.
Containment
La fase di contenimento dell’incidente viene svolta sulla base delle analisi eseguite durante la fase di identification. Le informazioni derivanti da questa fase, infatti, permettono di stabilire quali siano le migliori contromisure da attuare nella successiva fase di eradication e remediation.
Eradication e remediation
Stabilito il piano di contenimento, si eseguono le azioni utili all’eradicazione dell’attaccante e alla risoluzione dell’incidente. La tempestività rappresenta un’alleata indispensabile durante questa fase. Le azioni devono essere svolte in maniera massiva su tutti i sistemi, in modo da poter ridurre al minimo la possibilità di reazione da parte dell’attaccante. Durante la fase di eradication e remediation possono rendersi indispensabili le seguenti attività:
- cambio password per le utenze compromesse;
- reinstallazione dei sistemi danneggiati;
- blocco di domini malevoli;
- blocco di IP malevoli;
- verifica delle azioni di remediation applicate.
Recovery
La quinta fase dell’incident response plan mira a ripristinare l’infrastruttura di rete e tutte le attività e i servizi. È fondamentale, per un ripristino veloce e definitivo, attuare anche le misure del piano di business continuity e di disaster recovery.
Durante il ripristino possono essere svolte attività di sicurezza e sistemistiche. Generalmente, a seguito di un incidente possono essere necessarie le seguenti attività:
- creazione di un piano di patch management;
- miglioramento dei sistemi di autenticazione;
- revisione delle password policy;
- centralizzazione dei log;
- hardening dei sistemi e delle reti.
Follow up
Questa sesta fase è utile per verificare se l’incidente sia stato risolto correttamente, se l’attaccante e i rischi a esso associati siano stati rimossi completamente dalla rete e se le contromisure attuate siano state implementate in modo efficace.
Test
L’ultima, essenziale verifica viene svolta mediante l’ausilio di tools di monitoring. Successivamente si procede con le attività di prevention e di audit su reti e sistemi (tra cui i penetration test).
Incident response: perché è importante
L’importanza di questa pratica è riconosciuta dalle aziende di tutto il mondo. Predisporre un piano accurato e il più chiaro possibile permette all’impresa di reagire in modo efficace e tempestivo, evitando tensioni e nervosismi generalmente associati a un incidente già avvenuto.
Durante questi frangenti, infatti, lo stress potrebbe compromettere le attività e portare il team a commettere errori: ciò si tramuterebbe in una perdita di dati, di informazioni o di credibilità da parte dell’intera azienda.
Un incidente di sicurezza informatica mal gestito potrebbe comportare una grave perdita dal punto di vista economico o reputazionale, che potrebbe mettere in serio pericolo la sopravvivenza del business.
Tipi di team dell’incident response
L’incident response team deve essere composto da figure altamente specializzate. Questo team di lavoro dovrebbe coinvolgere professionisti dalle consolidate skill tecniche e comunicative. In genere, i teams comprendono 5 unità. Il numero dei membri può variare in funzione dell’incidente, della sua gravità e dei rischi a esso associati.
Le figure che compongono un incident response team sono:
- un team lead, responsabile della gestione e predisposizione di tutte le attività;
- uno o due esperti di sistemi operativi e di system forensics;
- uno o due esperti di network forensics e reti;
- un esperto di malware analysis e reverse engineering.
Gli IRT possono essere composti da professionisti:
- assunti in modalità part-time;
- assunti in modalità full-time;
- in outsourcing.
Interno o esternalizzato, i teams devono saper garantire un’operatività 24 ore su 24, 7 giorni su 7, in modo da gestire i possibili incidenti evitando qualsiasi attesa.
Il numero degli incident responder viene adeguato al livello di rischio associato all’incidente e alle possibilità, in termini di competenze e di budget, dell’azienda. Potrebbe essere utile integrare le competenze di un esperto in pubbliche relazioni, laddove l’impresa sia particolarmente sensibile dal punto di vista della reputazione. Questo professionista ha il compito di gestire la comunicazione relativa all’incidente, predisponendo una strategia ad hoc e controllando che le informazioni fornite non vadano a danneggiare l’immagine dell’azienda.
Due i principali modelli di incident response team: vediamoli nel dettaglio.
Incident response team centralizzato
Questo modello di incident response team è diffuso tra le aziende e organizzazioni non particolarmente soggette a criticità dal punto di vista dell’analisi dei rischi. Queste imprese, in genere strutturate presso un’unica sede, creano un team centralizzato che si occupa di tutta l’infrastruttura IT.
Incident response team distribuito
In questo secondo caso, invece, il team deve gestire attività più complesse. Le imprese che necessitano di un IRT distribuito sono generalmente grandi organizzazioni, che per l’esecuzione delle pratiche di sicurezza informatica hanno bisogno anche di più di un team. L’IRT in questo caso ha l’obiettivo di gestire il comparto fisico/logico dell’infrastruttura IT. Le aziende di importanti dimensioni creano un IRT distribuito per ogni sede aziendale. Tutti i micro team vengono coordinati e gestiti da un’unità centrale in remoto.
Cosa sono e tipologie di security incidents
Gli incidents security rappresentano momenti particolarmente critici per un’organizzazione. Questi eventi, infatti, mettono a rischio dati sensibili e possono provocare danni gravissimi all’azienda. Gli incidenti di sicurezza informatica più frequenti sono associati ad attacchi DDoS, ransomware, accessi non autorizzati alla rete, malware, attacchi interni e phishing.
Queste violazioni minacciano l’integrità e la disponibilità dei dati: approfondiamo le tipologie di security incidents nel seguente schema.
| Tipologia | Caratteristiche |
| Ransomware | Trattasi di un software malevolo che blocca il dispositivo informatico o i dati, tenendoli bloccati fin quando la vittima non paga un riscatto. |
| Attacchi DDoS | Grazie a questo attacco, il cybercriminale riesce a ottenere il controllo da remoto di uno o più computer, sovraccaricando i server o la rete. |
| Phishing e ingegneria sociale | Messaggi digitali tesi a ingannare l’utente, che viene convinto a scaricare un software malevolo, a cedere denaro o a condividere informazioni sensibili. |
| Internal threats | In questo caso sono i dipendenti la leva attraverso la quale si compie l’attacco. L’attacco interno può essere volontario o involontario. |
| Attacchi alla supply chain | Attacchi eseguiti mediante la rete di venditori: il criminale si infiltra all’interno dell’organizzazione con lo scopo di rubare dati sensibili, distribuendo malware attraverso i servizi di un distributore. |
Strumenti e risorse utili
Per poter intervenire nel minor tempo possibile, l’incident response team deve poter contare su un pacchetto di strumenti e risorse all’avanguardia. Queste risorse sono utili anche per l’automatizzazione dei flussi di lavoro, per la raccolta dei dati di sicurezza, per la correlazione dei dati e per il rilevamento real time degli incidenti.
Tra le tecnologie maggiormente utilizzate ed efficienti rientrano:
- SOAR (Security Orchestration, Automation and Response). Queste risorse permettono ai team di formulare un playbook. In questo modo, si potranno formalizzare i flussi di lavoro, automatizzando le operazioni e l’utilizzo dei tools di sicurezza disponibili;
- SIEM (Security Information and Event Management). Queste tecnologie aggregano e mettono in correlazione i dati inerenti agli eventi di sicurezza. Tale strumento riduce il fenomeno dell’affaticamento da avvisi dovuto all’enorme mole di notifiche generate dagli strumenti di sicurezza interni e dai dispositivi sulla rete;
- XDR (Extended Detection and Response). Questa tecnologia rappresenta il punto di contatto tra sicurezza, telemetria, analytics, punti di controllo e fonti dei dati. Permette di creare un sistema aziendale centrale in grado di unificare reti, cloud privati/pubblici ed endpoint, teso a prevenire, rilevare e rispondere alle minacce di sicurezza;
- EDR (Endpoint Detection and Response). Questo software mira a proteggere in automatico, dalle possibili minacce informatiche, l’utente, gli asset IT di un’azienda e i dispositivi endpoint. EDR è un’ulteriore protezione disponibile, nel caso in cui tali minacce superino la barriera del software antivirus (e di altri tools di sicurezza degli endpoint classici);
- ASM (Attack Surface Management). Queste soluzioni permettono di automatizzare il processo di analisi, rilevamento, monitoraggio e correzione delle vulnerabilità e delle falle che potrebbero rappresentare i vettori di attacco;
- UEBA (User and Entity Behavior Analytics). Questo strumento utilizza l’analytics comportamentale, l’automazione e gli algoritmi di machine learning per l’identificazione dei comportamenti anomali e pericolosi di utenti e dispositivi. Uno strumento essenziale soprattutto per identificare le minacce interne.
