Per organizzare un tabletop exercise per la sicurezza informatica bisogna partire da uno scenario realistico, coinvolgere IT, management, legale, comunicazione e fornitori critici, definire ruoli ed escalation, simulare decisioni sotto pressione e chiudere con un debrief operativo. Il valore dell’esercizio non è “superare” la crisi, ma scoprire prima cosa manca.
Conduco da tempo tabletop exercise su scenari ransomware in aziende di diverse dimensioni e c’è una costante che si ripete con una frequenza che dovrebbe preoccupare: nella maggior parte dei casi l’esercitazione non fallisce nella gestione della crisi. Fallisce prima. Fallisce nella fase di rilevamento perché emerge l’assenza di un’organizzazione strutturata attorno alla sicurezza informatica.
Cosa succede se un alert cyber arriva di notte?
Se un alert cyber arriva di notte e nessuno è incaricato di leggerlo, valutarlo e gestirlo, la tecnologia perde gran parte del suo valore. Il problema non è l’EDR in sé, ma l’assenza di una reperibilità strutturata capace di trasformare una segnalazione in una risposta tempestiva.
Se un EDR generasse un alert alle 2:30 di notte sarebbe del tutto inutile se tale alert finisse in una coda di e-mail che nessuno controllerà prima delle 8 del mattino. Questo è uno di tanti esempi che si potrebbero fare in merito alla mancata gestione delle segnalazioni in giorni e orari non lavorativi. La reazione che osservo è quasi sempre la stessa: un misto di imbarazzo e sorpresa perché fino a quel momento nessuno aveva mai formalmente valutato come gestire un alert alle 2 di notte quando la reperibilità IT non è strutturata ma lasciata solo alla disponibilità e buona volontà del personale IT, che in tal caso offre poche garanzie di continuità nel medio e lungo periodo.
Se un’azienda ha la necessità di mantenere l’infrastruttura operativa h24 per esigenze di business, tale infrastruttura dovrà essere presidiata con la stessa continuità. Non è un lusso ma una condizione necessaria: è una superficie di attacco lasciata scoperta per due terzi della giornata.
Il fornitore IT garantisce davvero sicurezza H24?
Un fornitore IT non garantisce automaticamente sicurezza H24: dipende dal contratto, dagli SLA e dal tipo di servizio acquistato. Il supporto infrastrutturale su ticket è diverso da un servizio di monitoraggio, analisi e risposta cyber continuativa, soprattutto quando lo scenario è un ransomware.
Infatti, una scoperta ricorrente durante le esercitazioni riguarda il ruolo dei fornitori. Molte PMI si affidano a un fornitore IT per la gestione dell’infrastruttura, assumendo implicitamente che questo copra anche la sicurezza fuori orario. Quando nell’esercitazione chiedo esplicitamente “chi risponde se questo alert arriva alle 3 di notte”, la risposta più comune è un silenzio, seguito da un “dovremmo chiamare il fornitore”. Verificando i contratti di assistenza si scopre che il fornitore offre supporto su ticket con SLA pensati per problemi in orario lavorativo e non un servizio di monitoraggio e risposta di sicurezza H24. Non è colpa del fornitore: è semplicemente un servizio diverso da quello che l’azienda pensava di aver acquistato.
Come si capisce se un ransomware sta per partire?
Un ransomware spesso si può intuire prima della cifratura osservando segnali come movimenti anomali, escalation di privilegi, accessi fuori contesto o comportamenti preparatori. Il problema è che questi segnali servono a poco se nessuno li analizza in tempo e li collega a uno scenario di attacco reale.
Questo è un punto centrale che le esercitazioni continuano a confermare: una parte significativa degli attacchi ransomware analizzati in fase post-incidente, presentava segnali di preparazione intercettabili ben prima della cifratura. La differenza tra un incidente contenuto in fase iniziale e un attacco ransomware andato a segno non è quasi mai la sofisticazione dell’attaccante: è la presenza o l’assenza di qualcuno in grado di analizzare i segnali giusti al momento giusto, interpretandoli correttamente e rispondendo di conseguenza.
Perché un reparto IT non può gestire tutto da solo?
Un reparto IT non può gestire tutto da solo perché la sicurezza richiede tempo, competenze e continuità che spesso non sono compatibili con la gestione quotidiana di infrastruttura, utenti, ticket, backup, accessi e sistemi aziendali. Senza ruoli dedicati, la sicurezza resta una responsabilità teorica.
Questo è un ulteriore elemento strutturale che le tabletop exercise mettono a nudo, ed è la reale composizione del lavoro quotidiano dei reparti IT nelle aziende di medie dimensioni. Nella maggior parte dei casi lo stesso team che dovrebbe presidiare la sicurezza, gestisce anche le stampanti, i ticket degli utenti, la manutenzione dell’ERP, le richieste di accesso, i backup, il firewall e qualunque altra cosa etichettata genericamente come “informatica”. Chiedere a questo stesso team di dedicare tempo alla sicurezza anche solo durante l’orario lavorativo, è spesso irrealistico: figuriamoci in giorni e orari non lavorativi quando un intervento di sicurezza preventivo non ha nessuno che lo reclami finché non succede qualcosa.
Chi deve gestire una crisi ransomware in azienda?
Una crisi ransomware non dovrebbe essere gestita solo dall’IT. Devono essere coinvolti management, legale, privacy, comunicazione, HR e board, perché un attacco impatta continuità operativa, clienti, dipendenti, reputazione, obblighi di notifica e decisioni aziendali che superano il perimetro tecnico.
Troppe aziende continuano ad approcciare un attacco ransomware come se fosse esclusivamente un problema dell’IT da risolvere senza coinvolgere il resto dell’organizzazione, senza un piano di comunicazione e senza una catena di comando definita che superi il perimetro tecnico.
Perché serve un piano di comunicazione durante un ransomware?
Durante un attacco ransomware serve un piano di comunicazione perché clienti, dipendenti, media e stakeholder iniziano a fare domande prima che l’azienda abbia tutte le risposte. Senza messaggi, ruoli e portavoce già definiti, il rischio è improvvisare proprio nel momento in cui servono controllo, chiarezza e coordinamento.
Un episodio che ho vissuto in aula e che purtroppo non è isolato rende bene l’idea. Durante la discussione relativa alla pressione esterna (es: clienti che chiamano, media che iniziano a fare domande, dipendenti che notano che qualcosa non va, ecc) un partecipante con un ruolo aziendale apicale ha detto letteralmente “non diciamo nulla a nessuno”. Non era una proposta di strategia di comunicazione ponderata con il legale: era l’istinto di chi vede la trasparenza come un rischio invece che come capacità della gestione della crisi. Quando nel debrief ho fatto notare che quella frase comunicherebbe esattamente l’opposto, ovvero non controllo della situazione, disorganizzazione e soprattutto assenza di una vera funzione di governance della crisi: silenzio. Il tema della comunicazione è quasi sempre il grande assente. Non esiste un piano di comunicazione di crisi, non esiste un portavoce designato, non esiste una bozza pre-approvata di comunicato per clienti o dipendenti. Tutto viene improvvisato nel momento peggiore possibile, sotto pressione, con il rischio concreto di dire la cosa sbagliata alla persona sbagliata nel momento sbagliato.
Cosa dimostra davvero una tabletop exercise?
Una tabletop exercise dimostra se l’azienda ha davvero immaginato cosa succederebbe durante una crisi cyber. Non serve solo a capire se le tecnologie funzionano, ma a verificare se esistono ruoli, escalation, governance, comunicazione e decisioni già pensate prima dell’incidente.
Tirando le somme, le evidenze raccolte durante le esercitazioni non indicano generalmente e solamente lacune tecniche specifiche. La maggior parte delle aziende durante una tabletop exercise si accorge per la prima volta di non aver immaginato certi scenari. Non hanno un piano di crisi che superi il perimetro IT, non hanno un processo di escalation che tenga conto degli orari non lavorativi, non hanno mai coinvolto HR, comunicazione, legale e board in una simulazione realistica.
È questo il valore della tabletop exercise al di là dell’esito specifico: non è tanto uno strumento per verificare se l’azienda sa rispondere bene a un attacco ma piuttosto uno strumento per dimostrare se ha pensato a cosa succederebbe in caso di attacco.
Di Andrea Coli – Incident Response Manager, CYBEROO
