La capacità di rispondere in modo strutturato a un attacco distingue un’organizzazione resiliente da una che subisce danni evitabili. L’incident response (IR) è il processo disciplinato con cui un team rileva, contiene e recupera da un evento di sicurezza, minimizzando l’impatto su riservatezza, integrità e disponibilità. Il riferimento standard è il NIST SP 800-61 (“Computer Security Incident Handling Guide”), la cornice su cui la CCST Cybersecurity costruisce le proprie domande.
Policy, plan e procedure: tre livelli distinti
Un errore frequente è confondere questi tre documenti. Hanno scopi e livelli di dettaglio diversi.
| Documento | Cosa definisce | Livello |
|---|---|---|
| Policy | Il “perché”: mandato, autorità, ruoli, cosa è considerato un incidente, obiettivi generali | Strategico |
| Plan | Il “cosa”: struttura del team (CSIRT/SOC), metriche, roadmap, risorse, priorità | Tattico |
| Procedure | Il “come”: passi operativi dettagliati, playbook, comandi, escalation | Operativo |
La policy è approvata dal management e conferisce l’autorità formale al team; senza di essa, chi risponde non ha legittimazione a isolare un host o sospendere un account. Le procedure (spesso chiamate playbook o runbook) traducono il piano in azioni ripetibili per scenari specifici (es. ransomware, phishing, data exfiltration).
Le quattro fasi del ciclo NIST SP 800-61
Il ciclo è iterativo, non lineare: le lezioni della fine alimentano nuovamente l’inizio.
1. Preparation
Tutto ciò che si fa prima dell’incidente. Include formazione del team, creazione dei playbook, hardening dei sistemi, deployment di strumenti (SIEM, EDR, Cisco ISE per il controllo accessi, Firepower/Secure Firewall per l’ispezione, NetFlow per la visibilità), definizione delle catene di comunicazione e delle informazioni di contatto. Una preparazione solida riduce drasticamente i tempi delle fasi successive.
2. Detection and Analysis
Identificazione dell’evento e sua qualificazione. Le fonti sono precursori (segnali che un attacco potrebbe avvenire) e indicatori (segnali che è in corso o avvenuto): alert IDS/IPS, log di ACL e firewall, anomalie NetFlow, avvisi antivirus. Qui si stabiliscono scope, gravità e priorità, si documenta tutto e si preserva la chain of custody delle evidenze. Un’analisi accurata evita di trattare un falso positivo come crisi o, peggio, di sottovalutare un compromesso reale.
3. Containment, Eradication and Recovery
- Containment: fermare la diffusione. Può essere short-term (isolare rapidamente un host, es. quarantena tramite Cisco ISE con Change of Authorization, blocco su firewall, VLAN di isolamento) o long-term (soluzioni temporanee che tengono i sistemi operativi mentre si prepara la bonifica). Un containment rapido è cruciale: ogni minuto di ritardo amplia la superficie compromessa, il numero di host infetti e il volume di dati esfiltrati.
- Eradication: rimuovere la causa — malware, account compromessi, vulnerabilità sfruttata.
- Recovery: ripristinare i sistemi in produzione in sicurezza, validandone l’integrità e monitorandoli per recidive.
4. Post-Incident Activity (Lessons Learned)
L’analisi retrospettiva, tipicamente entro pochi giorni dalla chiusura, con una riunione lessons learned: cosa è successo, quanto bene ha reagito il team, cosa migliorare in policy, plan e procedure. Da qui nascono aggiornamenti ai playbook e nuovi controlli. Saltare questa fase significa perdere le lezioni apprese e ripetere gli stessi errori: è la fase che chiude il ciclo e alimenta di nuovo la Preparation.
Perché il containment rapido conta
Un containment tempestivo limita l’impatto prima di avere una comprensione completa dell’attacco. La strategia va decisa in anticipo (nei playbook), bilanciando la necessità di fermare il danno con quella di preservare evidenze forensi. Isolare un host può cancellare artefatti in memoria: per questo la scelta tra “spegnere” e “isolare mantenendo attivo” deve essere una decisione pianificata, non improvvisata.
Trappole tipiche d’esame
- Scenario: l’attacco è risolto e i sistemi ripristinati, ma nulla viene documentato per il futuro → Risposta giusta: manca la Post-Incident Activity; senza lessons learned gli stessi errori si ripeteranno. È la fase più trascurata e più chiesta.
- Scenario: domanda su quale documento conferisce autorità al team e definisce cosa è un incidente → Risposta giusta: la policy, non il plan né le procedure.
- Scenario: rilevato ransomware che si propaga in rete; qual è l’azione immediata? → Risposta giusta: containment (isolare gli host), non eradication o recovery. Prima si ferma la diffusione.
- Scenario: un playbook dettagliato passo-passo per gestire il phishing va classificato come → Risposta giusta: procedura, il livello operativo, non plan (tattico) né policy (strategico).
- Scenario: hardening dei sistemi, training del team e stesura dei playbook → Risposta giusta: appartengono alla Preparation, l’unica fase interamente antecedente all’incidente.