Cosa fare in caso di attacco hacker: le prime 72 ore

Se state leggendo questa pagina mentre un attacco è in corso, le informazioni che vi servono sono nelle prime due sezioni. Il resto serve dopo.

Un attacco informatico in azienda genera una pressione che porta a due errori opposti: agire d’impulso sui sistemi, oppure attendere che qualcuno decida. Entrambi costano, e il secondo costa anche in termini legali, perché alcuni obblighi hanno termini che iniziano a decorrere dal momento in cui vi accorgete dell’incidente, non da quando avete capito cosa è successo.

1. Le prime ore: contenere senza distruggere le prove
2. Le notifiche obbligatorie e i termini che decorrono subito
3. Chi deve condurre l’indagine
4. Che cosa è stato colpito e chi informare
5. Dopo l’emergenza: verificare cosa è rimasto esposto
6. Costruire il piano che questa volta è mancato

Le prime ore: contenere senza distruggere le prove

L’obiettivo immediato è impedire che l’attacco si propaghi, senza compromettere la possibilità di capire cosa è accaduto. Sono due esigenze in tensione, ed è il motivo per cui l’istinto sbagliato è il più diffuso.

La misura corretta è isolare i sistemi dalla rete senza spegnerli: scollegare il cavo, disattivare la connessione senza fili, separare i segmenti coinvolti. Spegnere una macchina compromessa cancella la memoria volatile, che è il luogo dove risiedono le informazioni più utili a ricostruire l’attacco e, in alcuni scenari, elementi che possono servire al recupero. Un sistema isolato e accesso non fa danno; un sistema spento ha già perso metà delle sue informazioni.

Per la stessa ragione conviene fermarsi prima di tre azioni apparentemente ragionevoli. Non reinstallare né formattare, perché elimina le tracce necessarie a stabilire da dove è entrato l’attaccante e se è ancora presente. Non cancellare i registri di sistema e degli apparati di rete, che vanno invece messi al sicuro subito: su come sono organizzati e perché contano abbiamo scritto nella guida al log management. E non cambiare le credenziali prima di sapere se l’accesso ostile è stato interrotto, perché una rotazione fatta mentre l’attaccante è ancora dentro serve soltanto a segnalargli che è stato scoperto.

Se l’organizzazione dispone di un piano di risposta agli incidenti, questo è il momento di aprirlo e seguirlo. Se non ne dispone, la sequenza è quella descritta sopra, e la prima chiamata va a chi conduce l’analisi, non a chi gestisce i sistemi.

Le notifiche obbligatorie e i termini che decorrono subito

Questa è la parte che nella confusione delle prime ore viene rimandata, e che invece ha scadenze rigide. Gli orologi sono due e sono indipendenti.

Il primo riguarda i soggetti che rientrano negli obblighi introdotti dal decreto legislativo 138 del 2024. Per loro la sequenza di notifica al CSIRT Italia prevede una **pre-notifica entro 24 ore** dal momento in cui si è avuta conoscenza dell’incidente, una **notifica completa entro 72 ore** con la valutazione iniziale e gli eventuali indicatori di compromissione, e una **relazione finale entro un mese** dalla notifica, con la ricostruzione della causa e delle misure adottate. Il regime è pienamente operativo dal gennaio 2026, e l’omessa o tardiva notifica è sanzionabile.

Il secondo orologio è quello del GDPR e vale indipendentemente dal primo: se l’incidente ha comportato una violazione di dati personali, la notifica al Garante va effettuata entro 72 ore dalla conoscenza, indicando i motivi in caso di ritardo. Un’azienda soggetta a entrambi i regimi ha due adempimenti distinti verso due destinatari diversi, e assolverne uno non esaurisce l’altro.

La conseguenza pratica è che la prima riunione dopo l’isolamento dei sistemi non riguarda il ripristino, riguarda chi prepara le notifiche e con quali informazioni. Il termine di 24 ore non richiede di avere capito l’attacco: richiede di aver segnalato che è in corso.

Chi deve condurre l’indagine

Stabilire come è avvenuto l’accesso, quali sistemi sono stati raggiunti e se l’attaccante è ancora presente è un’attività specialistica, e affidarla a chi normalmente amministra i sistemi crea due problemi. Il primo è tecnico, perché le operazioni ordinarie di manutenzione tendono a sovrascrivere esattamente ciò che serve conservare. Il secondo è di posizione: chi ha configurato l’infrastruttura è la persona meno adatta a stabilire dove quella configurazione ha ceduto.

Il lavoro consiste nell’analisi dei registri, nella ricostruzione della sequenza temporale, nell’individuazione del punto di ingresso e nella verifica che l’accesso sia stato effettivamente interrotto — attività che rientrano nelle competenze di un blue team. L’ultima parte è quella che viene saltata più spesso, ed è la più importante: dichiarare chiuso un incidente senza aver confermato l’eliminazione dell’accesso significa ritrovarsi nella stessa situazione poche settimane dopo.

Che cosa è stato colpito e chi informare

Parallelamente all’indagine tecnica serve stabilire il perimetro dell’impatto: quali sistemi, quali archivi, quali dati e quali persone. È l’informazione su cui si costruiscono entrambe le notifiche, e nella maggior parte dei casi si scopre in questa fase che l’inventario aziendale non corrispondeva alla realtà.

Sul fronte esterno la trasparenza è la scelta che regge meglio nel tempo. Clienti, fornitori e partner commerciali che scoprono l’incidente da altre fonti reagiscono peggio di quelli informati direttamente, e per i soggetti in perimetro esistono comunque obblighi di comunicazione verso i destinatari dei servizi quando l’incidente può ripercuotersi su di loro. Vale la pena preparare una comunicazione essenziale e verificata prima che circolino versioni approssimative, e sapere che la disponibilità di copie di sicurezza non equivale alla capacità di ripristinare: è una distinzione che in questa fase determina cosa potete promettere.

Dopo l’emergenza: verificare cosa è rimasto esposto

Chiuso l’incidente, l’errore più comune è considerare risolto il problema perché è stata corretta la falla utilizzata. Nella maggior parte dei casi quella falla non era l’unica: era semplicemente la prima che qualcuno ha trovato, e chi l’ha trovata lo ha fatto perché stava guardando.

Il passaggio utile è quindi una verifica sistematica di ciò che resta raggiungibile dall’esterno e di ciò che, dall’interno, permette di spostarsi tra i sistemi. Le criticità individuate vanno ordinate per gravità effettiva e affrontate secondo un calendario, che nella pratica significa mettere ordine anche nella gestione degli aggiornamenti — la lacuna che sta all’origine di una quota consistente degli incidenti.

Se l’attacco ha comportato l’esposizione di credenziali, il percorso di rientro richiede attenzioni proprie, che abbiamo raccolto tra i consigli per contenere il rischio di esposizione, insieme al rafforzamento dell’autenticazione a più fattori sugli accessi che ne erano privi.

Costruire il piano che questa volta è mancato

Chi ha attraversato un incidente senza una procedura scritta sa quanto costi improvvisare: le decisioni prese sotto pressione da persone che non sapevano di doverle prendere sono la parte più costosa dell’intera vicenda.

Un piano di risposta utile è breve e nomina le persone. Chi decide l’isolamento dei sistemi, chi è autorizzato a fermare un servizio in produzione, chi prepara le notifiche e in quali tempi, chi parla con i clienti, chi conserva le prove. Le stesse informazioni vanno replicate per i sostituti, perché gli incidenti non aspettano che il responsabile sia in sede. E il piano va provato almeno una volta, altrimenti resta un documento che nessuno ha mai aperto.

Su tutto questo pesa un fattore che nessuna procedura sostituisce: chi si accorge per primo di un’anomalia è quasi sempre una persona che lavora, non un sistema di monitoraggio. Le ore che passano tra il primo segnale e la segnalazione al reparto giusto sono spesso le ore in cui l’attacco si consolida, e ridurle è una questione di cultura interna prima che di strumenti.

In conclusione

Nella gestione di un attacco informatico le prime ore contano più delle settimane successive, e contano soprattutto per ciò che non si fa: non spegnere, non reinstallare, non cancellare, non cambiare le credenziali prima del momento giusto. Accanto a questo corrono due scadenze di notifica che non attendono la comprensione dell’accaduto.

Quello che rimane, una volta chiuso l’incidente, è un’informazione che prima non avevate: come si entra nella vostra infrastruttura. Vale la pena usarla per sapere da quali altri percorsi si potrebbe entrare, invece di limitarsi a chiudere quello utilizzato.