Sempre più spesso numerose aziende vengono coinvolte in attacchi informatici che compromettono dati sensibili del loro business: in tale contesto, è diventato un fattore critico rispondere rapidamente e in maniera efficace alle violazioni di sicurezza mettendo in pratica le sei fasi del processo di Incident Response. Per questo motivo avere al proprio interno un team specializzato permette di gestire gli incidenti in modo sistematico e tempestivo. Il team preposto alla gestione degli incidenti di sicurezza è definito Incident Response Team (IRT). Spesso all’interno dell’organizzazioni tale capacità è assorbita del tutto o in parte all’interno dei SOC o dei CSIRT.
Indice degli argomenti
Le sei fasi dell’Incident Response: l’analisi
L’Incident Response è una fase del processo di Incident Management e viene definito come la capacità operativa di identificare, preparare e rispondere agli incidenti di sicurezza. Nel contesto dell’Incident Response risulta di fondamentale importanza la definizione di incidente di sicurezza. Si definisce incidente di sicurezza, un qualsiasi evento che comprometta l’integrità, la disponibilità o la riservatezza dei dati all’interno dei sistemi aziendali. Tuttavia, la generalità della definizione prevede numerose casistiche che rendono complesso la creazione di istruzioni universalmente valide ed appropriate per ogni caso. Per questo motivo il processo di Incident Response si avvale di procedure e linee guida da applicare. Di seguito si riportano le fasi che costituiscono il processo di Incident Response, approfondendo per ognuna di essa le azioni più corrette da intraprendere.
Le sei fasi dell’Incident Response: Preparation
In questa fase rientrano non solo le azioni propedeutiche a creare le condizioni migliori per gestire gli incidenti in maniera appropriata ma anche tutte quelle azioni da intraprendere per prevenirli. Le prime fanno riferimento principalmente alla stesura del piano di Incident Response e alla definizione delle procedure operative. Le seconde si riferiscono alla verifica della corretta configurazione dei sistemi di monitoraggio e di sicurezza dell’azienda.
Le sei fasi dell’Incident Response: Identification e Scoping
La fase di Identification è la fase più critica del processo e spesso la più onerosa in termini di tempo. Ciò è dovuto da diversi fattori: in primo luogo le dimensioni e la complessità della rete, in secondo luogo vanno considerate anche le capacità tecniche dell’attaccante. Infatti, statisticamente gli attaccanti avanzati installano malware solo nel 54% dei sistemi compromessi. Questo vuol dire che durante un’incidente esistono un certo numero di macchine compromesse che non hanno malware attivi a bordo, rendendo molto difficile la loro individuazione. Sfortunatamente molte aziende non effettuano una fase di Identification esaustiva, saltando direttamente alla fase di Eradication/Remediation dell’incidente. Questa reazione istintiva al problema potrebbe rimuovere solo parzialmente l’attaccante, che a quel punto adotterebbe delle contromisure aggiuntive per mantenere l’accesso ai sistemi. Inoltre, in questa fase è importante avere un’idea dello scopo dell’attaccante (scoping), iniziando a raccogliere IOC e threat pattern da utilizzare durante le fasi successive. Aspetti che vanno investigati in questa fase sono ad esempio, come ha fatto l’attaccante ad effettuare l’accesso iniziale alla rete, analisi dei movimenti laterali e malware utilizzati.
Le sei fasi dell’Incident Response: Containment
In questa fase viene definito il piano di contenimento dell’incidente sulla base delle informazioni raccolte durante la fase di Identification. Queste informazioni possono essere utilizzate per individuare ulteriori sistemi e per fornire le contromisure necessarie da utilizzare durante la fase di Eradication e Remedietion.
Le sei fasi dell’Incident Response: Eradication e Remediation
Una volta che sono stati identificati i sistemi coinvolti ed è stato stabilito un piano di contenimento, si può passare con la messa in atto delle azioni necessarie per effettuare l’Eradication dell’attaccante e della Remedietion dell’incidente. Tali azioni dovranno essere applicate nel minor tempo possibile e in maniera massiva su tutti i sistemi per evitare di incorrerete in reazioni da parte dell’attaccante. Di seguito si riportano alcune delle azioni più comuni che vengono effettuate in questa fase:
- blocco degli IP malevoli;
- blocco dei domini malevoli;
- reinstallazione dei sistemi compromessi;
- cambio password per tutte le utenze compromesse;
- verifica di tutte le azioni di Remediation applicate.
Le sei fasi dell’Incident Response: Recovery
La fase di recovery prevede di ripristinare l’infrastruttura di rete e i servizi di business alla normalità. Un ripristino di successo solitamente è legato anche all’esistenza di un corretto piano di business continuity e disaster recovery (nei peggiori dei casi la fase di Recovery può durare mesi). Il ripristino può coinvolgere attività sistemistiche e di sicurezza. Di seguito si riportano alcune delle attività più frequenti da effettuare post incidente:
- miglioramento del sistema di autenticazione;
- stabilire un corretto piano di patch management;
- centralizzazione dei log (SIM/SIEM);
- revisione delle password policy;
- hardening dei sistemi e delle reti.
Le sei fasi dell’Incident Response: Follow up
Tipicamente la fase di follow up è finalizzata a verificare che l’incidente sia stato mitigato in maniera corretta, che l’attaccante sia stato rimosso dall’ambiente e che tutte le contromisure siano state implementate correttamente. Questa verifica viene effettuata con strumenti di monitoring, con attività di prevention e con attività di audit sui sistemi e le reti (penetration test e compliance).
Creazione del team e strumenti utilizzati
Il processo di Incident Response solitamente prevede l’analisi di numerosi sistemi allo scopo di identificare tutte le compromissioni e fornire le azioni necessari per fermare l’incidente. Chiaramente in tale contesto la capacità e l’efficacia con cui si analizzano le tracce lasciate dall’attaccante è di fondamentale importanza ed è strettamente legata alle competenze e all’esperienza del team. In accordo con quanto detto, un team di Incident Response deve essere in grado di svolgere le seguenti attività:
- analisi forense sulla componente host;
- analisi forense sulla componente di rete;
- reverse engineering;
- estrapolazione di IOC e creazione del relativo threat model;
- applicazione del threat model creato per individuare nuove compromissioni;
- fornire linee guida per supportare la fase di remediation.
Per far fronte a queste attività, l’IRT dovrebbe comprendere una grande varietà di skill tecniche e comunicative. La composizione di questi team è dimensionata in base alla gravità dell’incidente ma solitamente non vengono superate le 5 unità. Le principali direttive per costituire un IRT vengono fornite dal framework FIRST. A titolo esemplificativo, di seguito si riporta una possibile composizione di un team in grado di ricoprire tutte le competenze necessarie:
- 1 team lead;
- 1-2 esperti di sistemi operativi e system forensics;
- 1-2 esperti di reti e network forensics;
- 1 esperto di reverse engineering e malware analysis.
Delle considerazioni importanti vanno fatte sulla figura del team lead, che ha il delicato compito di stabilire le priorità e dettare i tempi dell’intero gruppo. Inoltre, è il portavoce del gruppo e deve essere in grado di comunicare direttamente con il management aziendale le azioni da intraprendere durante l’incidente. Tuttavia, non tutte le organizzazioni sono dotate di personale con competenze ed esperienza tali da creare un IRT autonomo. In questi casi, è necessario appoggiarsi a società esterne per erogare tale tipologia di servizio. Ad ogni modo, risulta fondamentale la conoscenza dell’ambiente da parte del personale interno che supporterà l’IRT esterno. Per tale ragione, rimane prioritaria la formazione del personale dell’azienda alle tematiche di Incident Response. Per quanto riguarda gli strumenti utilizzati dall’IRT sono a descrizione del team stesso e devono prevedere un deployment rapido su tutti i sistemi. In generale l’insieme degli strumenti deve coprire le seguenti tre macro-aree: analisi degli endpoint, analisi del network e analisi dei log. L’insieme di queste tre componenti consente di effettuare un triage massivo dell’ambiente.
