È ormai un mantra del settore: non è più questione di se un’organizzazione subirà un incidente informatico, ma di quando e quanto bene sarà pronta a reagire. In un panorama dominato da ransomware-as-a-service, supply-chain compromise e phishing chirurgico, la differenza fra un evento da prima pagina e un disservizio tenuto sotto controllo dipende dalla qualità del processo di incident response.
1. Che cos’è un incidente informatico?
Un incidente di sicurezza è qualunque evento che comprometta riservatezza, integrità o disponibilità di dati e sistemi. Può trattarsi di un malware banale, di un data breach massivo o di un DDoS che mette in ginocchio l’e-commerce nel Black Friday.
La norma internazionale ISO/IEC 27035-1:2023 estende la definizione a “qualsiasi evento singolo o serie di eventi indesiderati o inaspettati con ragionevole probabilità di compromettere le operazioni dell’organizzazione”.
1.1 Incidente vs violazione dei dati
Un’incursione può restare “incidente” finché viene contenuta senza esfiltrazione; quando implica esposizione di informazioni personali, si trasforma in personal data breach e scatta l’art. 33 GDPR: notifica al garante entro 72 ore. In pratica, stessa frittata, padelle (e multe) diverse.
1.2 Tipologie comuni
Categoria | Esempi tipici | Impatto prevalente |
---|---|---|
Malware/Ransomware | Crypto-locker, wiper | Disponibilità |
Phishing & BEC | Mail spoofate, fake invoice | Riservatezza / integrità contabile |
DDoS | Botnet IoT, amplificazione DNS | Disponibilità |
Insider & errori umani | USB infette, allegati aperti | Variabile |
Vulnerabilità non patchate | CVE “n-day” su VPN, ESXi | Porta d’ingresso per attaccanti |
2. Perché succedono: cause profonde
- Comportamenti umani (clic improvvidi, password “1234”).
- Tecnologia obsoleta non aggiornata.
- Processi mancanti – assenza di logging, backup non testati.
- Fornitori: una libreria compromessa nella software-supply-chain infetta centinaia di clienti.
Quattro cavalli dell’apocalisse cyber che cavalcano spesso in branco.
3. I grandi riferimenti (framework & standard)
Framework/Standard | Punti chiave | Perché serve |
---|---|---|
NIST SP 800-61r3 (2025) | Ciclo Prepare → Identify → Contain → Eradicate → Recover → Lessons Learned, integrazione CSF 2.0 | Reference de-facto, gratis e pragmatico |
ISO/IEC 27035 (serie 2023-2024) | Processi formali, ruoli e KPI; parte 4 copre gestione multi-organizzazione | Perfetta per governance e certificazioni |
ENISA Best Practices for Cyber Crisis (2023) | Scale-up da “incidente” a “crisi” nazionale, coordinamento CERT-EU | Utile per enti pubblici e grandi gruppi |
4. Le sei fasi della gestione degli incidenti
4.1 Preparazione
- Policy, run-book, playbook e formazione continua del personale.
- Asset inventory e classificazione dati.
- Metrica chiave: Mean Time to Detect (MTTD) auspicabilmente in minuti, non in mesi.
Nerd-tip: un tabletop exercise trimestrale vale più di un firewall luccicante.
4.2 Identificazione & Analisi
- Monitoraggio con SIEM/EDR e threat-intel.
- Triage: priorità basata su impatto business, non solo su CVSS.
- Conservazione log forense (immutabili).
4.3 Contenimento
- Short-term: isolare host compromessi, bloccare IP malevoli.
- Long-term: patch, regole IDS/IPS, password reset mirati.
Contenere ≠ staccare la spina al data-center alla cieca: serve bilanciare rischio e continuità operativa.
4.4 Eradicazione
- Rimozione malware, chiavi di persistenza e backdoor.
- Validazione con scansione completa e “gold image”.
4.5 Recupero
- Ripristino da backup testati; hardening post-incident.
- Monitoraggio rafforzato per almeno 2–4 weeks.
4.6 Lessons Learned & Miglioramento continuo
- Post-mortem blameless entro 10 giorni.
- Aggiornamento playbook e formazione.
NIST pone il continuous improvement al centro dell’intero CSF 2.0, non più in coda.
5. Ruoli & responsabilità
Ruolo | Compiti essenziali |
---|---|
Incident Responder | Analisi tecnica, containment, forensics. |
Incident Manager/Coordinator | Decide priorità, comunica con C-level e ufficio legale. |
CSIRT/CERT interno | Gestione knowledge base, threat-intel, supporto ad altre BU. |
DPO/Privacy Officer | Valuta obblighi di notifica GDPR e verso interessati. |
6. Strumenti a supporto
- SIEM & SOAR per correlare eventi e orchestrare playbook automatici.
- Endpoint Detection and Response (EDR) e Network Detection and Response (NDR).
- Sandbox e threat-intel feed per analizzare payload.
- Piattaforme ticketing integrate con ITSM per tracciare azioni e tempi.
7. Documentare, comunicare, notificare
Una cronologia accurata di chi-ha-fatto-cosa-quando è il salvagente in tribunale (o davanti al garante). Durante l’incidente:
- War-room virtuale con canale dedicato (no e-mail!).
- Aggiornamenti a cadenza regolare verso stakeholder.
- Se data breach, notifica entro 72 ore (art. 33 GDPR) e valutazione di comunicazione agli interessati.
8. Normativa & conformità italiana/europea
- GDPR (UE 2016/679) – articoli 32-34.
- Direttiva NIS2 (2023) – impone piani di risposta certificabili alle “entità essenziali”.
- AgID Linee guida CERT regionali per la PA italiana.
9. Esercitazioni, KPI e miglioramento continuo
KPI | Target realistico | Note |
---|---|---|
MTTD | < 30 min | Con SIEM + alerting ben tarati |
MTTR (Mean Time to Respond) | < 4–8 h per incidenti critici | Dipende da risorse on-call |
% playbook coperti | > 80 % scenari top-10 | Aggiornare ogni 6 mesi |
Le simulazioni devono includere fornitori e terze parti: la supply-chain è il nuovo perimetro.
Gestire un incidente informatico non è un atto eroico “da film” ma un processo disciplinato che unisce persone, procedure e tecnologia. Applicare i framework NIST o ISO, allenarsi con esercitazioni regolari e coltivare una cultura di sicurezza condivisa trasforma l’incidente da catastrofe annunciata a opportunità di apprendimento.
In fin dei conti, la sicurezza perfetta non esiste; ma una risposta rapida, coordinata e documentata è ciò che distingue le organizzazioni resilienti da quelle destinate alle breaking-news (e alle sanzioni). Meglio sudare in un tabletop che piangere davanti al ransom-note.