Cosa fa#
Descrive il processo completo di gestione di un incidente di sicurezza (IH — Incident Handling) con le fasi operative, gli strumenti e i criteri decisionali usati in un SOC reale.
TL;DR#
IH (Incident Handling) è il contenitore che racchiude tutto il processo. IR (Incident Response) è il sottoinsieme operativo. Le fasi di Modiga seguono la stessa logica di PICERL ma con nomi diversi — per l'esame Security+ usa PICERL.
IH vs IR#
- IH (Incident Handling): tutto il processo — persone, procedure, strumenti, comunicazione, ticketing.
- IR (Incident Response): il team/processo tecnico di risposta all'incidente. È un sottoinsieme di IH.
Le fasi operative di Modiga (cap 9):
- Detection
- Analysis
- Containment
- Eradication
- Recovery
- Post-incident activity
Corrispondenza con PICERL (SANS): le fasi centrali sono identiche. Modiga non nomina Preparation come fase esplicita; usa Detection+Analysis dove SANS usa Identification; chiama Post-incident activity quello che SANS chiama Lessons Learned.
9.1.1 — Detection (Rilevazione)#
La rilevazione di un incidente avviene tramite più canali:
Automatici:
- SIEM (es. Wazuh) — raccoglie log da tutta l'infrastruttura, applica regole, genera alert
- EDR/XDR — agent installato sugli endpoint che monitora processi, file system e connessioni in tempo reale
- IDS/IPS — intercettano traffico anomalo o tentativi di intrusione
Umani:
- NOC team — può rilevare anomalie operative (server lento, picchi di traffico)
- Threat Hunter — cerca proattivamente minacce non ancora rilevate dagli alert automatici
- Utenti — segnalazioni di comportamenti anomali
Tutto confluisce nel SIEM come punto centrale. Ogni evento genera un ticket nel sistema di ticketing — ogni passo dell'analisi viene documentato nel ticket stesso.
9.1.2 — Analysis (Analisi) — IN CORSO (p. 495)#
Triage#
Prima attività dell'analisi. Composto da tre passi:
- Analisi iniziale — capire contesto, origine e dinamica dell'evento
- Categorizzazione — classificare il tipo di incidente
- Prioritizzazione — determinare urgenza e impatto
Le 5 domande del triage:
| Domanda | Cosa cerca |
|---|---|
| Who | Macchine, utenti, server coinvolti |
| What | Attività rilevate (download sospetto, login fallito, ecc.) |
| When | Timestamp e frequenza — capisce se è sporadico, brute force, beaconing |
| Where | Origine geografica o di rete — IP estero sconosciuto = sospetto |
| How | Vettore e metodo — verso la comprensione tecnica dell'attacco |
Fonti per l'analisi#
Interne:
- Log di sistema, firewall log
- SIEM, EDR, XDR
Esterne (OSINT):
- VirusTotal — analisi file, URL, IP, domini
- Any.run — sandbox online per eseguire file sospetti
- Shodan — motore di ricerca per dispositivi esposti su internet
- Servizi premium (threat intel feed)
Categorizzazione#
Fondamentale per applicare il playbook corretto. Si usa una tassonomia:
- Interna — definita dall'organizzazione
- ENISA — standard europeo per linguaggio comune tra organizzazioni
- Ibrida — la più diffusa: tassonomia interna + ENISA
Se l'incidente è nuovo → ticket separato. Se è già noto → i ticket vengono accorpati.
Prioritizzazione#
Ogni incidente riceve un livello di priorità. Schema comune:
| Livello | Nome | Descrizione |
|---|---|---|
| P0 / L1 | Critico | Rischio malfunzionamento totale — intervento immediato |
| P1 / L2 | Alto | Può diventare critico — intervento tempestivo |
| P2 / L3 | Medio | Non urgente ma non ignorabile |
| P3 / L4 | Basso | Nessuna minaccia immediata — spesso falso positivo. Basso non significa trascurabile |
Fattori che influenzano la priorità:
- Tipologia host — server critico di produzione vs workstation utente
- Tipologia account — CEO, dirigente, account di servizio con privilegi elevati
- Numero di host e utenti — incidente circoscritto vs diffuso
- Stato di mitigazione — malware bloccato da EDR ha priorità inferiore a uno non rilevato
- Vincoli normativi — sistemi con dati GDPR, PCI-DSS, HIPAA, NIS2 → priorità automaticamente più alta
- Applicazioni coinvolte — CRM, DB, ERP impattano il business in modo diverso
- Impatto su business — impedisce di lavorare?
- Esfiltrazione dati — dati sensibili usciti dalla rete?
- Coinvolgimento supply chain — origine esterna (fornitore, software terzo) allarga il perimetro → priorità più alta
- Tipologia minaccia — ransomware, APT (Advanced Persistent Threat), compromissione account hanno gravità diverse
Il tempo nell'analisi è critico: prima si contiene, meno il malware si espande. Analysis e Containment possono sovrapporsi quando il rischio è alto.
SIEM tuning — falsi positivi e falsi negativi#
Falsi positivi: alert su eventi innocui. Se numerosi saturano il SOC e rischiano di scalare a Tier superiori sprecando tempo. Il tuning calibra le regole sull'ambiente specifico.
Falsi negativi: minacce reali classificate come innocue — il problema più grave. Aprono la strada agli APT, attaccanti con risorse elevate che restano nascosti a lungo nella rete.
Contromisure contro i falsi negativi:
- Defence in depth — difesa multi-livello lungo tutta la Kill Chain: se un layer non rileva, il successivo lo fa
- Threat intelligence — raccolta e analisi continua di informazioni sulle minacce per aggiornare IoC e IoA
- Threat hunting — ricerca proattiva di minacce non ancora rilevate dagli alert automatici
- Audit e penetration test periodici — verificano che i controlli funzionino davvero
IoC (Indicator of Compromise) = traccia di compromissione già avvenuta (IP C2, hash malware, dominio). IoA (Indicator of Attack) = segnale di attacco in corso prima della compromissione (comportamento anomalo, sequenza sospetta). Rilevare IoA permette di intervenire prima.
9.1.3 — Containment (Contenimento)#
Due obiettivi paralleli — entrambi obbligatori:
- Limitare il perimetro — bloccare propagazione, movimento laterale, escalation di privilegi
- Mantenere il business operativo — isolare la minaccia senza fermare l'azienda
Chi esegue: Tier 2 SOC o team IR dedicato. Il Tier 1 rileva e scala, il Tier 2 contiene.
Le azioni di contenimento non vengono scritte in real time — sono già nei playbook. Un analista non va a scrivere una regola firewall a mano durante un incidente: clicca un pulsante che applica una regola pre-scritta e testata.
Azioni di contenimento#
Firewall / blocco rete:
- Blocco bidirezionale delle connessioni C2 (reverse shell, beaconing)
- Blocco outbound verso domini o IP malevoli noti
- Regole già pronte — esecuzione centralizzata in un click
EDR / blocklist:
- Inserimento hash del malware nella blocklist dell'EDR — impedisce esecuzione su tutti gli endpoint gestiti simultaneamente
- Blocco process name o firma del file sospetto
Account e sessioni:
- Disabilitazione dell'utenza compromessa
- Terminazione di tutte le sessioni attive: logout forzato, revoca token, kill sessioni SSO, RDP, VPN
- Non basta disabilitare l'account — le sessioni già aperte rimangono attive finché non vengono terminate esplicitamente
Isolamento macchina:
- Isolare l'host dalla rete (EDR può farlo in un click — network isolation mode)
- Criticità: se la macchina è un server business-critical, l'isolamento totale può bloccare l'azienda. In quel caso si valuta isolamento parziale (solo traffico di gestione consentito) o si accetta il rischio temporaneamente
Il processo di contenimento avviene in modo centralizzato tramite EDR/XDR. L'EDR agisce sul singolo endpoint (blocca un processo, isola la macchina). L'XDR ha visibilità cross-environment e può bloccare simultaneamente su più fonti — endpoint, rete, cloud — impedendo che il movimento laterale si propaghi prima che ogni singolo EDR venga aggiornato.
Da completare#
- 9.1.3 Containment
- 9.1.4 Eradication
- 9.1.5 Recovery
- 9.1.6 Post-incident activity
- 9.2 Scenari reali (account, ransomware, phishing, port scan)
Collegato a#
- incidents — il processo che porta a un incident report
- log — fonti primarie per detection e analysis
- incident-response-lifecycle — framework PICERL di riferimento per Security+
- glossario-cyber — IH, IR, triage, OSINT, telemetria, tassonomia ENISA
- settimana-11 — lettura mercoledi 06/05
