Un attacco informatico coglie la maggior parte delle aziende impreparate. Non perché la minaccia sia sconosciuta, ma perché lo scenario di emergenza non è mai stato concretamente simulato. Secondo l’IBM Cost of a Data Breach Report 2024, il costo medio di una violazione dei dati è di 4,88 milioni di dollari, un aumento del 10% rispetto all’anno precedente. La velocità di reazione è determinante: le violazioni rilevate e contenute entro 200 giorni costano in media 3,93 milioni di dollari. Se ci vuole più tempo, i costi salgono a 4,95 milioni di dollari, una differenza di oltre un milione di dollari.
Le prime 24 ore dopo la scoperta di un attacco determinano il corso degli eventi. Ogni decisione sbagliata in questa fase aumenta il danno in modo esponenziale. Questo articolo descrive cosa deve accadere in queste ore critiche e cosa non deve assolutamente accadere.
Il framework NIST come guida
Il NIST SP 800-61 definisce lo standard riconosciuto per l’incident response con quattro fasi: Preparation, Detection & Analysis, Containment/Eradication/Recovery e Post-Incident Activity. Nella pratica, queste fasi non sono strettamente sequenziali: nelle prime 24 ore, Detection, Analysis e Containment procedono spesso in parallelo. L’aspetto decisivo è che ogni fase venga affrontata consapevolmente e non si perda nel caos.
Le prime 24 ore – passo dopo passo
1. Confermare il rilevamento
Si tratta davvero di un incidente di sicurezza? Non ogni anomalia è un attacco. Un server guasto, un aggiornamento difettoso o un falso positivo nel SIEM possono produrre sintomi identici. Prima di mobilitare il team di incident response, è necessaria una triage qualificata: quali sistemi sono coinvolti? Ci sono indicatori di compromissione (IoC)? I log mostrano modelli di accesso insoliti? Questa valutazione iniziale non dovrebbe richiedere più di 30-60 minuti.
2. Attivare il team di Incident Response
Una volta confermato l’incidente, il team IR viene attivato, idealmente tramite un piano di allertamento predefinito con ruoli chiaramente definiti. Chi dirige l’incidente? Chi comunica internamente? Chi coordina le misure tecniche? Chi è il referente legale? Se queste domande vengono affrontate solo durante l’incidente, si perdono ore preziose. IBM stima il vantaggio economico di team IR preparati in una media di 248’000 dollari per incidente.
3. Contenimento (Containment)
La priorità immediata: limitare il danno senza distruggere le prove. Isolare i sistemi compromessi dalla rete, bloccare gli account compromessi, limitare le possibilità di movimento laterale dell’aggressore. È importante distinguere tra contenimento a breve termine (isolamento dalla rete) e contenimento a lungo termine (correzioni temporanee che consentono l’operatività mentre viene preparata la bonifica vera e propria).
4. Preservare le prove
La conservazione forense ha priorità assoluta, prima di qualsiasi bonifica. Creare dump della RAM prima di spegnere i sistemi. Mettere in sicurezza i file di log e verificarne l’integrità. Creare immagini dei dischi. Salvare le catture di rete. La catena di custodia deve essere documentata fin dall’inizio, soprattutto se si prendono in considerazione azioni penali o richieste assicurative. Chi prima bonifica e poi analizza distrugge le prove in modo irreversibile.
5. Gestire la comunicazione
La comunicazione durante un incidente deve essere coordinata e controllata. Internamente: informare la direzione, notificare i reparti coinvolti, stabilire un messaggio coerente. Esternamente: clienti, partner, eventualmente i media, ma solo con informazioni concordate. Sul piano legale: coinvolgere il responsabile della protezione dei dati, verificare gli obblighi di notifica. Un punto critico: non comunicare attraverso canali potenzialmente compromessi. Se il server di posta potrebbe essere coinvolto, utilizzare canali di comunicazione alternativi.
6. Rispettare gli obblighi di notifica
In Svizzera, dal 1° aprile 2025 vige un obbligo legale di notifica per gli attacchi informatici alle infrastrutture critiche. Gli operatori devono segnalare gli incidenti all’Ufficio federale della cibersicurezza (BACS) entro 24 ore, come stabilito dalla Legge sulla sicurezza delle informazioni (LSIn). Dopo la segnalazione iniziale, le organizzazioni hanno 14 giorni per presentare un rapporto completo. Da ottobre 2025 la mancata notifica può comportare multe fino a CHF 100’000. Inoltre, la nLPD (nuova Legge sulla protezione dei dati) richiede la notifica delle violazioni della protezione dei dati all’IFPDT qualora sussista un rischio elevato per le persone interessate. Le organizzazioni soggette al GDPR dispongono di 72 ore per la segnalazione all’autorità di controllo competente.
7. Prima analisi e scoping
Parallelamente al contenimento inizia l’analisi: come è penetrato l’aggressore? Quali sistemi sono effettivamente compromessi? Quali dati sono coinvolti? Lo scoping determina la portata dell’incidente e quindi l’impegno necessario per l’eradicazione e il ripristino. Senza uno scoping accurato si rischia di trascurare sistemi compromessi, consentendo all’aggressore di tornare attraverso un accesso non scoperto.
Gli errori più comuni nelle prime ore
Spegnere immediatamente i sistemi. Il riflesso naturale, e uno dei più dannosi. Lo spegnimento distrugge la memoria volatile (RAM), che spesso contiene le prove forensi più preziose: connessioni di rete attive, processi in esecuzione, dati decrittografati, malware in memoria.
Comunicare attraverso canali compromessi. Se un aggressore è nella rete, potrebbe leggere le Sue e-mail e i messaggi Teams. La comunicazione di incident response deve avvenire su canali separati e verificati come sicuri: telefoni cellulari personali, comunicazione out-of-band.
Pagare prematuramente il riscatto. Negli attacchi ransomware, la richiesta è immediata. Il pagamento non garantisce né il recupero dei dati né la prevenzione di un attacco successivo. Inoltre, i pagamenti a gruppi sanzionati possono avere conseguenze legali. Prima analizzare, poi decidere, e sempre con consulenza legale.
Bonificare prima di analizzare. Chi elimina il malware, cambia le password e reinstalla i sistemi prima che la conservazione forense sia completata rende impossibile una successiva analisi delle cause. Senza un’analisi delle cause profonde, la vulnerabilità effettiva resta aperta.
Perché il piano deve esistere prima dell’incidente
Improvvisare l’incident response sotto pressione non funziona. Le organizzazioni con i costi di violazione più bassi hanno una cosa in comune: un piano di incident response testato. IBM dimostra che le aziende con team IR e piani regolarmente testati rilevano gli incidenti in media 61 giorni prima e subiscono danni inferiori di quasi un milione di dollari. Il piano non deve essere perfetto. Deve esistere, essere conosciuto dai partecipanti e simulato almeno una volta all’anno in un esercizio tabletop.
Come Zerberos La supporta
La aiutiamo a essere preparato prima che si verifichi un incidente. Nel nostro Risk Assessment identifichiamo le vulnerabilità e valutiamo la Sua attuale postura di sicurezza. Con una Security Roadmap su misura definiamo misure concrete, inclusa la pianificazione dell’incident response. E quando conta, siamo pronti come partner competente. Ci contatti prima che si verifichi l’emergenza.
Fonti
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management – csrc.nist.gov
- IBM: Cost of a Data Breach Report 2024 – ibm.com
- Ufficio federale della cibersicurezza BACS: Obbligo di notifica per attacchi informatici – ncsc.admin.ch
- Legge sulla sicurezza delle informazioni LSIn: Obbligo di notifica per infrastrutture critiche dal 1° aprile 2025 – admin.ch
- nLPD: Nuova Legge sulla protezione dei dati della Svizzera – fedpol.admin.ch