Incident Response - Framework e Lifecycle

Cosa fa

#

Definisce come un SOC gestisce un incidente di sicurezza dall'inizio alla fine. Esistono piu' framework — non si escludono, si usano in modo complementare.

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

#

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

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

Incident Handler's Checklist

#

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

#

• observability — SIEM e monitoring nella fase Identification
• network — Digital Forensics nella fase Containment
• 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