La domanda non è se la tua organizzazione subirà un incidente di sicurezza. La domanda è quando, e se quando accadrà avrai un piano o improvviserai. La differenza tra un incidente contenuto in 4 ore e una crisi che dura settimane spesso si riduce a un documento scritto, testato e aggiornato.
Perché la maggior parte delle aziende non ce la fa senza un piano
Durante un incidente attivo, la pressione è massima. Il management vuole aggiornamenti ogni ora. I dipendenti non capiscono cosa sta succedendo. Il team IT è sovraccarico. La stampa potrebbe chiamare. In questo contesto, prendere decisioni razionali senza un framework predefinito è praticamente impossibile.
Le organizzazioni senza un IRP (Incident Response Plan) tendono a:
- Distruggere prove forensi nel tentativo di "pulire" i sistemi
- Non notificare il Garante entro le 72 ore richieste dal GDPR
- Comunicare informazioni errate o contraddittorie verso l'esterno
- Rimettere online sistemi ancora compromessi
- Non imparare nulla dall'incidente per prevenire il successivo
Le sei fasi del ciclo di risposta agli incidenti
Il framework di riferimento è il NIST SP 800-61, adottato come standard internazionale. Ecco come applicarlo in modo pratico.
Fase 1: Preparazione
Tutto ciò che fai prima che l'incidente accada. È la fase più importante e quella più spesso trascurata.
- Definire il team di risposta (CSIRT): chi fa cosa, con nome e cognome, non "il team IT"
- Albero delle comunicazioni: chi avvisare, in quale ordine, con quale messaggio
- Canali di comunicazione alternativi: se l'email aziendale è compromessa, come vi parlate?
- Strumenti e accessi predisposti: licenze forensi, accessi ai log, contatti del provider
- Classificazione degli asset critici: sapere cosa proteggere prima aiuta a prioritizzare durante
Fase 2: Identificazione
Riconoscere che un incidente è in corso, non sempre ovvio quanto sembra. Un ransomware si annuncia da solo; un APT silenzioso potrebbe essere nella rete da settimane.
- Monitoraggio attivo di log, alert SIEM, segnalazioni utenti
- Classificazione dell'incidente per tipo e gravità (P1/P2/P3)
- Documentazione immediata: timestamp, sistemi coinvolti, sintomi osservati
- Attivazione del CSIRT e notifica ai livelli appropriati
Fase 3: Contenimento
Impedire che l'incidente si espanda. La decisione chiave: contenimento immediato (isola tutto) vs. contenimento strategico (osserva per capire meglio). Dipende dal tipo di incidente.
- Isolamento di rete: disconnettere i sistemi compromessi senza spegnerli (preserva la memoria RAM)
- Blocco account compromessi senza avvisare l'attaccante che è stato scoperto
- Snapshot forensi dei sistemi prima di qualsiasi operazione di pulizia
- Continuità operativa: identificare quali sistemi possono continuare a operare in sicurezza
Fase 4: Eradicazione
Rimuovere completamente la presenza dell'attaccante dai sistemi. Questa fase richiede la massima cura: un'eradicazione incompleta porta a recidive.
- Analisi forense completa per identificare tutti i sistemi compromessi
- Rimozione malware, backdoor, account non autorizzati
- Identificazione e chiusura del vettore di attacco iniziale
- Applicazione patch e hardening dei sistemi coinvolti
Fase 5: Ripristino
Riportare i sistemi all'operatività in modo controllato. Non tutto in una volta: prioritizzare i sistemi critici e monitorare attentamente per recidive.
- Ripristino da backup verificati come non compromessi
- Verifica dell'integrità dei sistemi ripristinati
- Monitoraggio intensificato nelle settimane successive
- Comunicazione agli stakeholder sul ritorno alla normalità
Fase 6: Lezioni Apprese
La fase più spesso saltata, e la più preziosa per il lungo termine. Un'analisi post-incidente onesta è il miglior investimento in sicurezza che un'organizzazione possa fare.
- Post-mortem blameless entro 2 settimane dall'incidente
- Timeline completa: come è entrato, come si è mosso, come è stato scoperto
- Aggiornamento del piano di risposta con ciò che non ha funzionato
- Formazione specifica sulle lacune emerse
Il GDPR e la notifica al Garante
Se l'incidente coinvolge dati personali, il GDPR impone la notifica all'Autorità Garante entro 72 ore dalla scoperta, non dalla risoluzione. Questo elemento normativo deve essere esplicitamente integrato nel piano, con template di notifica predisposti e referente legale identificato.
La notifica tardiva o mancata è una delle violazioni GDPR più sanzionate: fino al 2% del fatturato annuo globale.
Come testare il piano: le tabletop exercise
Un piano non testato è peggio di nessun piano, perché dà una falsa certezza. Le tabletop exercise sono simulazioni in cui il team di risposta affronta uno scenario di incidente realistico senza che i sistemi siano effettivamente compromessi.
Ogni esercitazione rivela gap che nessun documento teorico avrebbe identificato: il responsabile IT in ferie, il backup che non funziona, il canale di comunicazione alternativo che nessuno sa usare.
Raccomandazione: almeno una tabletop all'anno, con scenario diverso ogni volta. Il nostro team facilita queste esercitazioni per i clienti: contattaci per pianificarne una.