Incident response plan aziendale: quali STEP evitare per non prolungare l’inattività dopo un attacco

La telefonata arrivò mentre il caffè faceva ancora finta di scaldarmi le mani. “Il gestionale è muto, i file hanno nomi strani, cosa facciamo?”. Lì, tra il vapore e l’eco dei server in sala, ho capito che la partita non si giocava sull’eroismo tecnico, ma su ciò che avremmo evitato di fare. Negli anni, tra PMI in corsa verso il cloud e vecchie reti con cerotti digitali, ho visto downtime allungarsi non per la gravità dell’attacco, ma per scelte sbagliate nelle prime ore. Questo è il racconto di quegli errori e di come scansarli.

L’attimo che decide tutto: triage e isolamento

La tentazione più umana è “toccare” subito la macchina compromessa. Un riavvio, una scansione affrettata, un accesso con l’account di amministratore per “dare un’occhiata”. È qui che inizia il tempo perso. Riavviare può spazzare via tracce in memoria e disinnescare gli indizi che serviranno dopo. Un login privilegiato sul nodo sbagliato regala all’attaccante un’autostrada verso il dominio. La fretta di aprire condivisioni per copiare log o strumenti, invece, spesso facilita un movimento laterale silenzioso.

La prima mossa che accorcia l’inattività è non muovere nulla finché non si isola. Segmentare in fretta, staccare dalla rete in modo selettivo, spegnere porte e VLAN mirate, spostare i gateway di emergenza. Non serve spegnere l’intero datacenter, serve disinnescare la dinamica. Se il perimetro è ibrido, fermare tunnel e connettori che fanno da ponte con il cloud prima di qualunque scansione massiva. È un riflesso che si allena con le esercitazioni e che trova linee guida solide in ISO/IEC 27035.

Potrebbe interessarti anche

Minacce informatiche emergenti per le PMI: la tecnica di attacco che si diffonde silenziosamenteCrittografia end-to-end applicata ai dati aziendali: scopri il vantaggio concreto per la privacy dei tuoi clientiCos’è il cloud computing privato? Vantaggi pratici per le medie imprese italianeQual è il miglior hardware a noleggio per smart working? Scelte che riducono stress e imprevisti

Un altro errore classico è inseguire subito il “come è successo”. La caccia all’origine, in quell’istante, è un lusso. Prima si ferma la perdita di sangue, poi si guarda il proiettile. Indagare mentre i processi malevoli girano significa alimentare l’incendio con l’aria del proprio entusiasmo.

Parlare meno, decidere meglio: la catena di comando

L’istinto di “mettere tutti in call” è forte. La chat diventa un fiume, arrivano screenshot, ipotesi, forward da WhatsApp. Intanto i minuti scappano. La confusione di ruoli allunga la coda dell’evento perché nessuno è davvero responsabile di dire stop a un’azione rischiosa. Serve un unico responsabile operativo, la persona che in quell’ora fa da faro e che tutti riconoscono. Gli altri ascoltano, aggiornano, non danno ordini in parallelo.

Comunicare troppo presto ai clienti, senza fatti verificati, è un boomerang; comunicare troppo tardi alle autorità quando ci sono dati personali coinvolti è una miccia legale. Preparare in anticipo i canali, i messaggi e le soglie di attivazione è ciò che impedisce scuse creative in piena crisi. E prendere decisioni su canali non aziendali, magari da cellulari personali, significa perdere controllo e tracciabilità. La trasparenza serve, ma nella giusta sequenza: prima contenere, poi informare con precisione.

Backup, ripristino e l’arte di non rimettere in circolo il veleno

In tanti incidenti la voglia di ripartire spinge a ripristinare ambienti produttivi nelle stesse ore del contenimento. Sembra concreto, ma diventa una trappola. Se l’infrastruttura di identità non è stata ripulita, se le credenziali sono ancora in mano agli attaccanti, il ripristino è benzina sul fuoco. Rientrare con backup non verificati e non immutabili, o montare i repository in scrittura su reti ancora incerte, crea l’illusione del rientro e poi il secondo blackout.

Ho visto più downtime per backup frettolosi che per attacchi sofisticati. La disciplina giusta è validare offline la sanità dei dati, verificare finestre di tempo non contaminate, separare i domini di ripristino, ruotare chiavi e segreti prima di rialzare i servizi esposti. Un ripristino è un ponte, non una scorciatoia: si costruisce su piloni solidi, non su sabbia umida.

La pressione psicologica spinge anche a “trattare” con gli aggressori per recuperare in fretta. Pagare non è una leva di business: è un azzardo che spesso allunga la dipendenza, non garantisce la cancellazione dei dati e mette l’azienda in un cono d’ombra difficile da spiegare a partner e assicurazioni. Sul terreno scivoloso del Ransomware, la lucidità operativa vince sull’impazienza.

Forensics e legge: cosa non calpestare mentre corri

Raccogliere prove non è un esercizio da telefilm, è la cintura di sicurezza per il dopo. Cancellare log “per pulire”, riformattare macchine in fretta, aggiornare software nel mezzo dell’evento solo per “mettere in sicurezza” cancella le tracce utili a capire la portata, le responsabilità e la conformità. Se ci sono dati personali, ci sono obblighi precisi e finestre temporali da rispettare; scordarlo o confidare in annunci vaghi mette l’azienda in una posizione fragile davanti ai regolatori e ai clienti.

È qui che il coordinamento con legale, DPO e assicurazione cyber dovrebbe essere previsto in anticipo, nel piano. Non dopo. Chiamarli in corsa è come imparare a frenare sul ghiaccio quando sei già in curva. Anche con le forze dell’ordine la relazione va costruita prima dell’emergenza: sapere chi contattare e con quali modalità evita corse a vuoto e aiuta a preservare ciò che servirà a raccontare l’evento con rigore.

Il fattore umano: eroi solitari e memoria corta

Un altro acceleratore di disastri è l’eroe solitario. Il tecnico che conosce tutto, che tiene in testa password, eccezioni, topologie non documentate. Quando cade lui, cade mezzo perimetro. Nel mezzo di un attacco, contare su una persona sola rallenta ogni scelta, perché ogni consulto diventa singolare. La ridondanza non è solo nei server, è nei cervelli e nelle procedure. Documentare davvero, rendere ripetibili i passaggi critici, scrivere runbook che un collega può seguire alle tre di notte senza interpretazioni creative: è questo che accorcia i tempi di fermo quando la pressione sale.

La memoria corta fa il resto. Chiudere l’incidente senza una revisione a freddo, senza un debrief strutturato, significa mettere in conto l’effetto yo-yo. Le stesse falle, tra sei mesi, torneranno a bussare, magari con una firma diversa. La fase di lezioni apprese non è un orpello: è la parte che trasformare una ferita in tessuto cicatriziale più resistente.

Cloud, fornitori e l’invisibile che decide i minuti

Nelle PMI che ho seguito nella migrazione al cloud, l’errore che più allunga il buio è dare per scontato che “lì è tutto protetto”. In realtà l’ecosistema di applicazioni SaaS, identity federation, integrazioni via API e connettori ibridi è una ragnatela dove un nodo tirato male vibra lontano. Dimenticare i terzi nelle prime ore, non coinvolgere il fornitore di connettività, il partner del gestionale, il cloud provider per le quote d’emergenza o per bloccare token sospetti, significa lasciare aperte porte che non si vedono dalla propria console.

Ci vuole un inventario vero, aggiornato, con ownership chiari e contatti d’emergenza che rispondono davvero. E ci vuole il coraggio di spegnere selettivamente pezzi di integrazione senza la colpa di “far cadere” altri processi. Meglio un fermo controllato oggi che un cantiere infinito domani.

Dalla simulazione alla realtà: come non prendere tempo contro

La parte più noiosa del mestiere è anche quella che regala minuti quando serve. Le esercitazioni tabletop, le prove di failover, i test di isolamento in orari scomodi, i dry run di comunicazione con la stampa e con i clienti. Sembra tempo perso finché, nel lunedì del blackout, quella coreografia si attiva con naturalezza. All’opposto, improvvisare ruoli, tool e linguaggio in piena emergenza crea frizioni invisibili: accessi che non funzionano, autorizzazioni mancanti, strumenti forensi da scaricare quando la rete è già zoppa.

Un piano che non si prova è un romanzo. Un piano che si prova, invece, è un copione che taglia i silenzi imbarazzanti e fa scivolare la storia nel verso giusto. E ogni prova deve mettere al centro ciò che non fare: non accedere da account privilegiati non necessari, non aggiornare sistemi mentre si raccoglie evidenza, non ripristinare prima di sanificare identità, non comunicare fatti non verificati.

Ripenso a quella chiamata di prima mattina. È finita con server rialzati in giorni, non in settimane, non perché fossimo più bravi degli altri, ma perché abbiamo rifiutato scorciatoie. Abbiamo resistito alla voglia di “toccare”, imposto silenzi dove serviva, scelto il tempo giusto per parlare e per ripartire. In un incidente, spesso, la vera bravura sta nelle omissioni strategiche. È la differenza tra una mattinata storta e tre settimane di buio.