Incident Response - Framework e Lifecycle

Mappa Globale

#

Cosa fa

#

L'Incident Response definisce come un SOC gestisce un incidente di sicurezza dall'inizio alla fine. Esistono piu' framework — non si escludono, si usano in modo complementare: NIST per la governance, PICERL per il lavoro operativo degli analisti.

Definizione di IR

#

Esistono due definizioni di riferimento:

• NIST: La remediation o mitigazione di violazioni delle policy di sicurezza e delle pratiche raccomandate.
• SANS: Il processo strutturato di identificazione, gestione e mitigazione degli effetti di un incidente di sicurezza informatica, con l'obiettivo di minimizzare i danni, ripristinare le operazioni e prevenire ricorrenze future.

La definizione SANS e' piu' operativa — quella usata nei SOC. La definizione NIST e' piu' formale — usata in compliance e governance.

Framework a confronto

#

I framework non sono alternativi: operano a livelli diversi dello stesso problema e si usano in modo complementare.

Come si integrano in un programma IR moderno

#

NIST CSF 2.0          → livello policy e framework aziendale
                         "cosa deve fare il programma di sicurezza"
                         Govern / Identify / Protect / Detect / Respond / Recover

  └── NIST SP 800-61r3  → livello processo IR tattico
                           "come gestire un incidente"
                           Preparation → Detection/Analysis → Response → Recovery → Post-Incident

        └── PICERL       → livello operativo SOC / playbook
                           "cosa fa concretamente il team dal ticket alla chiusura"
                           Preparation → Identification → Containment → Eradication → Recovery → Lessons Learned

Come si usano insieme in pratica:

• A livello CISO/audit: usa NIST CSF per dimostrare maturita' del programma di sicurezza
• A livello processo IR: usa NIST SP 800-61 come riferimento formale nella documentazione e nei report
• A livello operativo SOC: segui PICERL come guida durante l'incidente (playbook, runbook, formazione analisti)
• Classificazione tecniche: usa MITRE ATT&CK in ogni fase per descrivere cosa ha fatto l'attaccante
• Misurazione efficacia: usa TBS per verificare che Pt > Dt + Rt

PICERL — dettaglio operativo

#

Le sei fasi PICERL sono il linguaggio operativo degli analisti SOC: non una checklist da scorrere linearmente, ma un ciclo continuo dove Lessons Learned alimenta la Preparation del prossimo incidente.

flowchart LR
    subgraph cycle["Continuous Improvement Cycle"]
        P[Prepare]
    end
    subgraph im["Incident Management"]
        I[Identify]
        C[Contain]
        E[Eradicate]
        R[Recover]
        LL[Lessons Learned]
        I --> C
        I --> E
        C --> R
        E --> R
        R --> LL
    end
    P --> I
    LL -->|Constant Feedback Loop| P

Lettura diagramma: Il ciclo di vita PICERL con due subgraph distinti. A sinistra il ciclo continuo di Preparation. A destra la gestione dell'incidente: Identify avvia sia Contain che Eradicate in parallelo (non necessariamente sequenziali). Entrambi convergono su Recover. Lessons Learned chiude il ciclo tornando a Preparation tramite il feedback loop. La freccia di ritorno e' il punto piu' importante: senza di essa PICERL e' solo una checklist.

1. Preparation (Preparazione)

#

Costruire le fondamenta prima che l'incidente accada.

• Policy, Communication Plan, Response Strategy
• Jump Bag (kit di emergenza), Checklists, Access Control per il CIRT
• Drill periodici — il team deve sapere cosa fare senza improvvisare

2. Identification (Identificazione)

#

Rilevare l'incidente e determinarne lo scope.

• Rispondere alle 5W + 1H: Who, What, Where, When, Why, How
• Determinare se e' un vero incidente o un falso positivo
• Classificare la severity

3. Containment (Contenimento)

#

Fermare la diffusione e limitare i danni.

• Short-term: Isolare l'host (staccare rete, bloccare account)
• System Back-Up: Creare copie forensi PRIMA di pulire — non alterare le evidenze
• Long-term: Patch temporanee per continuita' del business

4. Eradication (Eradicazione)

#

Rimuovere completamente la minaccia e le tracce.

• Metodo preferito: reimaging (ripristino da immagine pulita)
• Chiudere le vulnerabilita' sfruttate
• Rimuovere malware, backdoor, account creati dall'attaccante

5. Recovery (Ripristino)

#

Riportare i sistemi in produzione con monitoraggio intensivo.

• Validare che il sistema non venga re-infettato
• Monitoraggio aumentato nelle prime ore/giorni
• Approvazione formale prima del ripristino in produzione

6. Lessons Learned (Lezioni Apprese)

#

Analisi post-mortem per migliorare il processo.

• Play-by-play review dell'incidente
• Output: report finale con timeline, impatto, azioni correttive
• Aggiornare playbook, regole SIEM, policy in base a quanto appreso
• Root Cause Analysis formale (RCA): risponde a "perche' i controlli hanno fallito?", non solo "cosa e' successo?"
• Idealmente entro 2 settimane dall'incidente, mentre la memoria e' fresca

Il ciclo PICERL e' identico al ciclo di sviluppo software: Preparation = design + setup CI/CD. Identification = alert di un test fallito in prod. Containment = rollback del deploy difettoso. Eradication = fix del bug nel codice. Recovery = redeploy e verifica. Lessons Learned = post-mortem scritto (RFC o blameless post-mortem Atlassian/Google). La differenza e' che in security il "bug" e' un attaccante con intenzioni malevole.

Incident Handler's Checklist

#

IRP vs BCP vs DRP

#

Tre piani distinti che si sovrappongono ma hanno scope diversi. L'esame Security+ li testa separatamente perche' la distinzione e' critica in fase di risposta.

Il BCP e' l'equivalente di avere un deployment rollback plan in produzione. Quando tutto si rompe (non solo un bug di sicurezza, ma il datacenter intero), sai come mantenere il servizio. L'IRP e' il security incident runbook: specifico, tecnico, focalizzato sulla minaccia. Sono complementari: un breach ransomware attiva sia l'IRP (risposta security) che il BCP (continuita' del business durante la risposta).

Esercitazioni IR

#

Le esercitazioni testano se il piano funziona prima che sia necessario usarlo davvero. Esistono tre livelli di intensita', con costi e realismo crescenti.

Regola sequenziale esame: Dopo aver creato o aggiornato un piano IR o BCP, il passo successivo corretto e' sempre tabletop exercise. Non si archivia un piano senza averlo testato almeno a tavolino.

Il tabletop exercise e' il refinement meeting prima di un go-live critico: "cosa succede se il deploy fallisce a mezzanotte di un venerdì?". Si discute senza toccare nulla. La simulation e' il chaos engineering (Netflix Chaos Monkey, AWS GameDay): si inietta il fallimento in modo controllato per vedere se il team regge davvero. Il tabletop raffina il piano, la simulation lo prova.

Letture di approfondimento

#

• ISO/IEC 27035 — Information Security Incident Management
• ENISA Incident Management Guidelines
• ASD Strategies — Australian Signals Directorate, mitigazioni pratiche
• NIST SP 800-61 — Computer Security Incident Handling Guide (gratuito)

Scenario Reale

#

Lab 2026-05-10 — Reverse Shell da Kali su Ubuntu:

Identification  → Wazuh alert: auditd syscall connect() su bash
Analysis        → raccogli IoC: IP 192.168.64.200, porta 4444,
                  processo bash, durata 205s, syscall 203 ARM64
Containment     → kill -9 $(lsof -t -i:4444) + ufw deny out 4444
Eradication     → rimuovi il vettore iniziale (servizio vulnerabile)
Recovery        → ripristina e monitora
Lessons Learned → ROOT CAUSE ANALYSIS:
                  "perché Ubuntu era vulnerabile?"
                  → servizio esposto non patchato sulla porta 8080
                  → quella è la porta d'ingresso, non la 4444

Un analista rileva un'esecuzione anomala di PowerShell tramite Wazuh (alert SIEM):

1. Identification — risponde alle 5W+1H, classifica come True Positive, severity High
2. Containment — isola la workstation, crea forensic backup
3. Eradication — reimaging del sistema, chiude la vulnerabilita' sfruttata
4. Lessons Learned — scrive una regola Sigma per rilevare quel pattern in futuro, aggiorna il playbook

Strumenti usati: Wazuh (SIEM) per Identification, MITRE ATT&CK per classificare le tecniche, PICERL come guida al processo.

Collegato a

#

• soc-tiers — chi esegue le fasi (Tier 1/2/3)
• mitre-attack-framework — classifica le tecniche dell'attaccante
• incident-report-reverseshell — esempio reale di IR applicato
• investigazione-linux — comandi per la fase Identification su Linux
• red-blue-purple-team — ruoli nel processo IR (Blue Team = IR team operativo)
• siem-soar — strumenti usati in Identification e Containment