Organizzi questa settimana un tabletop di incident response

Un tabletop exercise richiede una sala, uno scenario, due ore e qualcuno che annoti ciò che va storto. Non servono un fornitore, un budget o un piano di incident response già completo. Lo scopo è scoprire, finché nulla è in fiamme, chi decide davvero di staccare un server dalla rete e dove sono conservati i numeri di telefono.

Scelga uno scenario e le persone giuste

Scelga un solo scenario. Il ransomware su un file server e l'account takeover della casella di posta dell'amministrazione finanziaria sono i due più utili per un team piccolo, perché entrambi impongono decisioni su isolamento, comunicazione e ripristino. Non cerchi di coprirli entrambi nella stessa sessione.

Non è necessario scrivere lo scenario da zero. Exercise in a Box dell'NCSC è gratuito, comprende tabletop exercise su temi come ransomware e phishing e fornisce il materiale per impostare, pianificare, condurre e individuare le azioni successive all'esercizio. I Tabletop Exercise Packages di CISA offrono obiettivi modello, domande di discussione, un modulo di feedback e un After Action Report, con scenari che includono ransomware e pubblica amministrazione locale. Li utilizzi come impalcatura e ne adatti i dettagli ai Suoi sistemi.

Inviti le persone che sarebbero realmente presenti alla chiamata:

• chi amministra la directory e i backup
• la persona che può autorizzare un fermo dei sistemi (un responsabile, non solo l'IT)
• qualcuno che gestisce la comunicazione esterna, anche se si tratta dell'office manager
• un facilitatore che non partecipa al gioco e non risponde alle domande

Il facilitatore è importante. Se la stessa persona conduce lo scenario e difende la propria configurazione, l'esercizio si trasforma in una demo.

L'agenda di due ore

Fissi una regola all'inizio: le risposte devono descrivere ciò che farebbe davvero con gli accessi e gli strumenti di cui dispone oggi, non ciò che prevede la policy. Se qualcuno dice "controlleremmo i log", il facilitatore chiede quali log, dove e chi vi ha accesso alle 07:40 di un lunedì.

Inject per la versione ransomware

Proponga lo scenario a passi successivi, non tutto insieme. Una sequenza praticabile:

1. Un utente segnala che i documenti di un'unità condivisa hanno cambiato estensione e che in ogni cartella compare un file di testo con una richiesta di riscatto.
2. Altri due utenti segnalano lo stesso problema. Il file server è lento.
3. La console di backup mostra che l'ultimo job è terminato, ma il server di backup è aggiunto al dominio.
4. La nota dell'attaccante minaccia di pubblicare i dati entro 72 ore.
5. La posta elettronica è inattiva perché il connettore di posta gira su un host compromesso.

A ogni passo corrisponde una domanda. Chi può isolare l'host e serve un'approvazione? I backup sono raggiungibili con le stesse credenziali di amministratore che l'attaccante potrebbe possedere? Dove si trova l'elenco dei contatti se directory e posta non sono disponibili? Chi decide se coinvolgere la polizia o un'autorità di controllo e chi contatta la compagnia assicurativa?

Inject per la versione account takeover

Cominci con un utente dell'amministrazione che segnala ripetute richieste MFA che non ha avviato. Aggiunga poi un accesso da un Paese sconosciuto, quindi la scoperta di una regola della casella di posta che inoltra i messaggi a un indirizzo esterno e infine una fattura con coordinate bancarie modificate inviata a un cliente. Chieda come si revocano sessioni e token, non solo come si reimposta la password. Chieda fino a quando risalgono i log di accesso e chi verifica la presenza di regole e deleghe nella casella di posta. Se desidera un controllo rapido per sapere se le credenziali dei dipendenti compaiono già in data breach pubblici, il nostro verificatore di password compromesse è un passo preliminare ragionevole.

Registri le lacune finché sono fresche

Lo scriba tiene un registro semplice. Non lo riordini durante la sessione. Una riga si presenta così:

Inject 3 | Backups reachable with domain admin | Gap: backup server domain-joined,
no offline copy confirmed | Owner: infra lead | Fix by: 30 days | Severity: high

Ogni lacuna richiede un responsabile e una data, altrimenti resta un desiderio. Le classifichi in base a ciò che Vi avrebbe impedito di lavorare, non in base a quanto sono state imbarazzanti. I riscontri tipici sono banali: nessuno conosceva le credenziali del registrar, il numero di reperibilità era obsoleto, la persona con l'autorità di spegnere la produzione era in ferie e non aveva un sostituto.

Chieda ai partecipanti un feedback scritto prima che se ne vadano. Il pacchetto di CISA include un modello di modulo di feedback e un After Action Report, il che Le evita di doverli progettare.

Trasformi il registro in un runbook

Entro una settimana converta il registro in un runbook breve. Una o due pagine per scenario sono sufficienti. Un runbook che nessuno legge durante un incidente è peggio di nessun runbook.

Includa:

• La prima ora: azioni numerate, ciascuna con un ruolo indicato, non il nome di una persona.
• Poteri decisionali: chi può isolare i sistemi, chi può approvare la spesa per un supporto esterno, chi parla con i clienti.
• Contatti: stampati o conservati offline, con dipendenti, fornitori, ISP, compagnia assicurativa e responder esterni.
• Gestione delle evidenze: che cosa non cancellare né riavviare prima che qualcuno abbia acquisito immagini e log.
• Ordine di ripristino: quali sistemi tornano operativi per primi e che cosa dimostra che sono puliti.

Per una struttura più ampia, la Computer Security Incident Handling Guide del NIST, SP 800-61 Rev. 2, è ampiamente citata, ma il NIST l'ha ritirata il 3 aprile 2025 sostituendola con la Rev. 3, quindi usi la revisione attuale come riferimento. Se desidera un parere esterno sul runbook o un supporto nella conduzione della sessione, consulti i nostri servizi di incident response e di consulenza.

Pianifichi poi la ripetizione. Esegua l'altro scenario entro tre-sei mesi e verifichi nuovamente le correzioni emerse dal primo registro delle lacune.

Da dove iniziare

1. Prenoti due ore questa settimana e blocchi le agende delle quattro o cinque persone che sarebbero presenti alla chiamata.
2. Scarichi uno scenario ransomware o phishing da Exercise in a Box o da un pacchetto CISA e lo modifichi in modo che corrisponda ai Suoi sistemi reali.
3. Nomini un facilitatore che non partecipa al gioco e uno scriba che tenga il registro delle lacune.
4. Svolga la sessione con gli strumenti reali aperti: console di backup, directory, log di accesso, elenco dei contatti.
5. Assegni un responsabile e una data a ogni lacuna prima che la sala si svuoti.
6. Scriva il runbook di una pagina entro sette giorni e ne conservi una copia in un luogo che funzioni anche quando la rete non funziona.