Indice dei contenuti
- Cos’è l’incident response e perché oggi è una priorità aziendale
- Evento, alert, incidente e data breach: le differenze
- Incident Response Plan, Disaster Recovery e Business Continuity: cosa cambia
- Le fasi dell’incident response secondo le best practice NIST
- Quando attivare il piano di incident response
- Il ruolo del team: CSIRT, legal, comunicazione e forensics
- GDPR, data breach e obblighi di notifica
- Ransomware: cosa fare nelle prime ore
- Strumenti utili: SIEM, EDR, XDR, SOAR e MDR
- Checklist essenziale per un Incident Response Plan
Cos’è l’incident response e perché oggi è una priorità aziendale
L’incident response, o risposta agli incidenti informatici, è l’insieme di procedure, ruoli, strumenti e decisioni che un’organizzazione attiva quando rileva o sospetta un incidente di sicurezza. Non riguarda solo la tecnologia: coinvolge sicurezza informatica, direzione aziendale, ufficio legale, comunicazione, compliance, fornitori esterni e, nei casi più delicati, anche attività di digital forensics.
In termini semplici, l’incident response serve a rispondere a una domanda critica: cosa dobbiamo fare, subito, quando qualcosa compromette sistemi, dati o continuità operativa?
Un incidente può derivare da un attacco ransomware, un accesso abusivo, un furto di credenziali, una compromissione email, una fuga di dati, un malware, una frode interna, un errore umano o un’attività sospetta collegata a reati informatici. In tutti questi casi, la rapidità non basta: serve metodo. Agire senza una procedura può peggiorare l’incidente, cancellare prove, rallentare il ripristino o esporre l’azienda a responsabilità legali.
La guida NIST SP 800-61 Rev. 3, pubblicata nel 2025, inquadra la risposta agli incidenti all’interno del cybersecurity risk management e la collega alle funzioni del NIST Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond e Recover. Questo significa che la risposta agli incidenti non è più un’attività isolata, ma parte integrante della governance del rischio aziendale.
Evento, alert, incidente e data breach: le differenze
Prima di costruire un Incident Response Plan, è necessario chiarire alcuni concetti.
| Termine | Significato | Esempio |
|---|---|---|
| Evento | Qualsiasi attività osservabile su sistemi o reti | Login utente, aggiornamento software |
| Alert | Segnale generato da uno strumento di sicurezza | Avviso EDR su file sospetto |
| Incidente di sicurezza | Evento che mette a rischio riservatezza, integrità o disponibilità | Account amministratore compromesso |
| Data breach | Violazione di dati personali | Esfiltrazione di database clienti |
| Crisi cyber | Incidente con impatto grave su business, reputazione o compliance | Ransomware su sistemi critici |
Non ogni alert è un incidente. Un SIEM, un EDR o una piattaforma XDR possono generare centinaia di segnalazioni, molte delle quali non indicano una reale compromissione. La fase iniziale di triage serve proprio a distinguere un falso positivo da un evento che richiede l’attivazione del piano.
Incident Response Plan, Disaster Recovery e Business Continuity: cosa cambia
Uno degli errori più frequenti è confondere incident response, disaster recovery e business continuity.
Sono collegati, ma non coincidono.
| Aspetto | Incident Response Plan | Disaster Recovery Plan | Business Continuity Plan |
|---|---|---|---|
| Obiettivo | Gestire e contenere l’incidente | Ripristinare sistemi e dati | Garantire continuità ai processi critici |
| Quando interviene | Minuti/ore dalla rilevazione | Ore/giorni dopo l’impatto | Durante e dopo la crisi |
| Focus | Containment, eradicazione, prove, analisi | Backup, restore, RTO, RPO | Operatività aziendale |
| Team principale | CSIRT, SOC, sicurezza, legal | IT operations, infrastruttura | Direzione, operations, risk management |
L’Incident Response Plan gestisce il “fuoco mentre brucia”: identifica, contiene e rimuove la minaccia. Il Disaster Recovery Plan entra in gioco quando occorre ripristinare sistemi, infrastrutture e dati. Il Business Continuity Plan stabilisce invece quali attività aziendali devono continuare anche in condizioni degradate.
Il punto critico è il coordinamento: ripristinare troppo presto un sistema senza aver chiuso il vettore d’attacco può significare rimettere online un ambiente ancora compromesso.
Le fasi dell’incident response secondo le best practice NIST
Le fasi operative più usate derivano dal modello NIST e vengono spesso adattate in sei passaggi: preparazione, rilevamento, analisi, contenimento, eradicazione, recupero e attività post-incidente. Alcuni framework le raggruppano in quattro macrofasi, ma la logica resta la stessa.
Preparazione
La preparazione è la fase che determina l’efficacia della risposta. Include inventario degli asset, classificazione dei dati, definizione dei ruoli, canali di comunicazione alternativi, policy, playbook, strumenti di monitoraggio e contatti di emergenza.
Un buon piano deve rispondere prima dell’incidente a domande come:
- chi decide se attivare il piano;
- chi può isolare un server;
- chi contatta legale, assicurazione cyber o consulenti esterni;
- dove sono conservati backup e documentazione;
- quali sistemi sono prioritari per il business.
Detection & Analysis
La fase di detection serve a individuare anomalie, indicatori di compromissione e comportamenti sospetti. Le fonti principali sono log di firewall, VPN, endpoint, Active Directory, cloud, email, DNS, proxy e sistemi EDR/XDR.
L’analisi deve ricostruire cosa è successo: quando è iniziato l’evento, quali sistemi sono coinvolti, quali account sono stati usati, se vi è stata esfiltrazione e se l’attaccante è ancora presente.
Contenimento
Il contenimento mira a impedire che l’incidente si espanda. Può includere isolamento di host compromessi, blocco di credenziali, segmentazione di rete, disattivazione temporanea di servizi o regole firewall dedicate.
Uno dei dubbi più frequenti è: meglio spegnere un server compromesso o isolarlo? La risposta dipende dallo scenario. Spegnere può fermare un’attività dannosa, ma può anche cancellare dati volatili utili all’indagine. Per questo, quando possibile, è preferibile isolare il sistema preservando log, memoria, processi attivi e stato della macchina.
Eradicazione
L’eradicazione rimuove la causa dell’incidente: malware, backdoor, account compromessi, configurazioni errate, vulnerabilità sfruttate o accessi non autorizzati. Non basta eliminare il sintomo: occorre individuare la root cause.
In un ransomware, ad esempio, non è sufficiente ripristinare i file cifrati. Bisogna capire se l’accesso iniziale è avvenuto tramite phishing, VPN compromessa, credenziali rubate, RDP esposto o vulnerabilità non corretta.
Recovery
Il recupero riporta online i sistemi in modo sicuro. Qui entrano in gioco backup, restore, test di integrità, monitoraggio rafforzato e criteri di priorità.
Due parametri sono fondamentali:
- RTO, Recovery Time Objective: entro quanto tempo un servizio deve tornare operativo;
- RPO, Recovery Point Objective: quanti dati l’azienda può permettersi di perdere.
Un backup non testato non è una garanzia. Per essere utile in un incidente reale deve essere verificato, isolato, protetto da cancellazione e possibilmente immutabile o offline.
Post-incident review
Dopo il ripristino, il lavoro non è finito. La post-incident review serve a documentare timeline, decisioni, impatto, costi, errori, punti di forza e azioni correttive.
Questa fase consente di aggiornare playbook, controlli tecnici, formazione, contratti con fornitori, policy e metriche. Un piano di risposta agli incidenti deve essere un documento vivo, non un file creato per superare un audit.
Quando attivare il piano di incident response
Un piano efficace deve includere criteri chiari di attivazione. Non tutto richiede una mobilitazione completa, ma alcuni segnali devono far scattare immediatamente l’escalation:
- accesso non autorizzato a sistemi critici;
- compromissione di account privilegiati;
- cifratura o cancellazione anomala di file;
- sospetta esfiltrazione di dati;
- malware con movimento laterale;
- interruzione di servizi essenziali;
- coinvolgimento di dati personali;
- impatto su clienti, fornitori o continuità operativa.
Una matrice di severità aiuta a classificare l’incidente come basso, medio, alto o critico, considerando impatto tecnico, dati coinvolti, numero di utenti, obblighi normativi, reputazione e capacità di contenimento.
Il ruolo del team: CSIRT, legal, comunicazione e forensics
L’Incident Response Team non dovrebbe essere composto solo da tecnici.
Un incidente può avere impatti investigativi, contrattuali, reputazionali e normativi.
| Ruolo | Responsabilità |
|---|---|
| Incident Manager | Coordina attività, priorità e decisioni |
| Responsabile tecnico | Analizza log, sistemi, minacce e contenimento |
| Digital forensic analyst | Conserva, acquisisce e interpreta prove digitali |
| Legal/DPO | Valuta obblighi GDPR, NIS2, contratti e responsabilità |
| Comunicazione/PR | Gestisce messaggi interni, clienti, media e stakeholder |
| Management | Decide priorità di business, budget e rischio accettabile |
Per un’agenzia investigativa specializzata, la preservazione delle prove è centrale: nei casi di trafugamento dati e indagini digitali, Phersei evidenzia l’utilizzo della Digital Forensics per recuperare informazioni cancellate o sottratte e produrre elementi probatori utilizzabili.
Questo aspetto è decisivo anche nei casi collegati a frodi finanziarie, accessi abusivi, sottrazione di dati aziendali o tecniche più sofisticate come il ghost pairing, dove la corretta acquisizione delle evidenze può fare la differenza tra un sospetto e una prova tecnicamente sostenibile.
GDPR, data breach e obblighi di notifica
Quando un incidente coinvolge dati personali, non si parla più solo di cybersecurity, ma anche di data protection. Il GDPR prevede che il titolare del trattamento notifichi una violazione al Garante senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla conoscenza, salvo che sia improbabile un rischio per i diritti e le libertà delle persone. Le notifiche oltre il termine devono essere motivate.
Per questo il piano deve indicare:
- chi valuta se l’incidente è un data breach;
- chi coinvolge DPO e consulente legale;
- quali informazioni raccogliere;
- come documentare le decisioni;
- quando informare gli interessati;
- come coordinarsi con fornitori, assicurazione e autorità.
Documentare anche gli incidenti non notificati è una buona pratica di accountability.
Ransomware: cosa fare nelle prime ore
Il ransomware è uno degli scenari più critici perché combina interruzione operativa, cifratura, possibile esfiltrazione e pressione estorsiva.
Nelle prime ore occorre:
- isolare i sistemi coinvolti senza cancellare evidenze;
- bloccare account sospetti e credenziali privilegiate;
- preservare ransom note, log, hash, indirizzi IP e indicatori di compromissione;
- verificare stato e integrità dei backup;
- identificare il punto di ingresso;
- valutare se ci sono dati esfiltrati;
- coinvolgere legal, management, assicurazione e specialisti forensi;
- ripristinare solo da backup verificati e in ambiente pulito.
La domanda “pagare o non pagare” non dovrebbe mai essere trattata come scelta solo tecnica: coinvolge profili legali, assicurativi, reputazionali, investigativi e di continuità aziendale.
Strumenti utili: SIEM, EDR, XDR, SOAR e MDR
Gli strumenti non sostituiscono il piano, ma lo rendono eseguibile. Un’organizzazione può usare:
- SIEM per centralizzare e correlare log;
- EDR per rilevare e isolare minacce sugli endpoint;
- XDR per correlare segnali da endpoint, rete, cloud ed email;
- SOAR per automatizzare playbook ripetitivi;
- MDR/MSSP per monitoraggio esterno e risposta gestita.
La scelta dipende da budget, maturità, settore, esposizione al rischio e capacità interna. Per una PMI, spesso è più realistico un modello ibrido: competenze interne per decisioni e governance, supporto esterno per monitoraggio, analisi e risposta tecnica.
Checklist essenziale per un Incident Response Plan
Un piano completo dovrebbe contenere almeno:
- definizione di incidente e livelli di severità;
- ruoli, responsabilità e sostituti;
- contatti interni ed esterni;
- criteri di escalation;
- canali di comunicazione alternativi;
- playbook per ransomware, phishing, data breach, account compromessi e DDoS;
- procedure di conservazione delle prove;
- integrazione con DRP e BCP;
- obblighi GDPR/NIS2;
- registro delle decisioni;
- metriche MTTD, MTTA, MTTR e tempo di contenimento;
- calendario di test e tabletop exercise.
Il piano deve essere disponibile anche se email, SharePoint, VPN o sistemi aziendali non sono accessibili. Copie protette offline, password manager sicuro e canali out-of-band possono essere decisivi.
Conclusione
L’incident response non è solo una procedura tecnica: è una capacità organizzativa. Serve a contenere l’attacco, preservare prove, ridurre l’impatto, rispettare gli obblighi normativi e riportare l’azienda in condizioni di sicurezza.
La vera resilienza nasce dall’integrazione tra Incident Response Plan, Disaster Recovery Plan e Business Continuity Plan. Il primo gestisce la minaccia, il secondo ripristina sistemi e dati, il terzo protegge la continuità dei processi aziendali.
In un contesto in cui ransomware, data breach, accessi abusivi e compromissioni digitali sono sempre più frequenti, la domanda non è se serva un piano. La domanda corretta è: se un incidente iniziasse oggi, l’organizzazione saprebbe chi decide, cosa fare, quali prove conservare e quando ripristinare?
