In breve: un'esercitazione tabletop in ambito IT simula a tavolino un incidente di sicurezza: un moderatore fornisce passo dopo passo nuove informazioni sulla situazione, i partecipanti decidono come nell'emergenza e alla fine c'è un elenco di miglioramenti concreti. Per i server web è adatto uno scenario sul modello di PHP2Shell, perché tocca insieme tecnica, decisioni in condizioni di incertezza, protezione dei dati e comunicazione.
Perché un piano funziona solo se lo si prova
Molte aziende hanno ormai un piano di emergenza. Se funzioni lo si vede però solo quando qualcuno lo usa sotto pressione di tempo. Contiene il numero di telefono giusto? La direzione sa di dover decidere su uno spegnimento? Il fornitore conosce gli accessi? Domande simili le chiarisce in poche ore un'esercitazione a tavolino.
La settimana di ottobre 2026 ha mostrato con quanta rapidità una situazione possa degenerare: preavviso da parte di php.net il 20/10, patch il 21/10 alle 16:00 ora tedesca, livello di allerta arancione del BSI (l'Ufficio federale tedesco per la sicurezza informatica), spegnimenti di siti pubblici secondo i media. Chi aveva provato prima questa sequenza ha dovuto improvvisare meno. La procedura nel dettaglio è descritta nella Cronologia di PHP2Shell. Come costruire il piano lo spiega Creare un piano di emergenza IT per i server web; qui si tratta di esercitarsi.
Esercitazione tabletop in ambito IT: ruoli e preparazione
Una buona esercitazione richiede poco materiale, ma ruoli chiari. Il moderatore conduce attraverso il copione, introduce le informazioni e tiene il tempo. Non discute, ma pone domande. Un verbale annota decisioni, questioni aperte e ogni punto in cui qualcuno dice «questo adesso non lo saprei». Facoltativamente un'altra persona osserva come procede la comunicazione.
I partecipanti sono le persone che nell'emergenza agiscono davvero: direzione, IT interna o fornitore esterno, responsabili della protezione dei dati, comunicazione, se necessario acquisti o ufficio legale. È importante che siano presenti i sostituti, perché gli incidenti non rispettano i piani ferie.
Alla preparazione appartengono: il piano di emergenza aggiornato su carta, l'elenco dei contatti, un prospetto di siti e server e una sala senza interruzioni. Stabilisca prima che si tratta di imparare, non di dare voti. Chi teme di fare brutta figura non dice ciò che non sa.
Un copione pronto: falla PHP critica il venerdì pomeriggio
Lo scenario seguente è fittizio, ma si ispira al modello di una situazione reale. Adatti sistemi e nomi al Suo ambiente. A ogni input si dedicano da dieci a venti minuti di discussione.
| Passo | Input del moderatore | Domanda guida al gruppo |
|---|---|---|
| 1 | La stampa specializzata segnala una falla critica in PHP, le patch sono annunciate ma non ancora disponibili. | Chi lo viene a sapere per primo e chi deve essere informato? |
| 2 | Le patch escono nel pomeriggio. Il BSI raccomanda l'aggiornamento immediato, altrimenti lo spegnimento temporaneo. | Quali dei nostri sistemi sono interessati e come lo sappiamo? |
| 3 | L'hoster non si fa sentire. Un server proprio gira con una versione di PHP senza aggiornamento ufficiale. | Applicare la patch, spegnere o attendere, e chi decide? |
| 4 | Lo shop deve fare un'azione nel fine settimana. Le vendite insistono per non spegnere nulla. | Come bilanciamo fatturato e rischio e come documentiamo la decisione? |
| 5 | Lunedì un admin trova un file PHP sconosciuto nella cartella degli upload. | Che cosa facciamo per prima cosa, che cosa lasciamo deliberatamente? Chi conserva le prove? |
| 6 | Non è chiaro se siano stati sottratti dati dei clienti. | Chi valuta un possibile obbligo di notifica e quando decorre il termine? |
| 7 | Una giornalista chiede perché il sito sia offline. | Chi parla all'esterno e che cosa diciamo finché sappiamo poco? |
Il passo 6 tocca il GDPR. Nell'esercitazione basta chiarire la procedura: chi coinvolge i responsabili della protezione dei dati e quando. La valutazione giuridica resta agli specialisti; le linee generali sul termine sono nell'art. 33 GDPR.
Conoscenze tipiche e come annotarle
Certe lacune emergono quasi a ogni prima esercitazione. Manca un elenco completo di quali siti girano su quali server con quale versione di PHP. I dati di contatto dell'hoster sono obsoleti o salvati solo in una casella di posta che nell'emergenza non è raggiungibile. Nessuno sa con certezza se la direzione possa ordinare da sé uno spegnimento o se qualcuno debba approvare.
Annoti ogni conoscenza in tre parti: che cosa abbiamo constatato, che cosa cambiamo e chi lo fa entro quando. Per esperienza, una conoscenza senza responsabile resta lì. Ordini i punti per effetto: un numero di emergenza mancante si risolve in fretta e aiuta subito, una nuova soluzione di monitoraggio richiede pianificazione.
Per la valutazione strutturata dopo l'esercitazione si adatta lo stesso metodo usato dopo un incidente reale. È descritto nell'articolo Lessons learned: migliorare dopo l'incidente. L'elenco dei contatti, che nell'esercitazione mostra di solito le debolezze, è trattato in Contatti di emergenza: chi va informato e quando?.
Ripeta l'esercitazione dopo sei-dodici mesi con uno scenario diverso, ad esempio un sito violato con reindirizzamento verso siti esterni. Così verifica se le misure del primo giro sono state davvero attuate.
Come aiuta concretamente PHP SOS?
- Adattiamo il copione ai Suoi siti, server e fornitori effettivi e prepariamo gli input.
- Moderiamo l'esercitazione da remoto o in videoconferenza e ci asteniamo da valutazioni finché il gruppo non ha deciso.
- Forniamo poi un verbale con conoscenze, misure, responsabili e scadenze.
- Su richiesta esercitiamo in seguito la parte tecnica, cioè rilevamento della situazione, patch e ricerca di tracce, così come la svolge la nostra incident response nell'emergenza.
Conclusione
Un'esercitazione di emergenza a tavolino è la via più economica per trovare le debolezze di un piano di emergenza prima che lo faccia un incidente reale. Un pomeriggio, un copione realistico e una valutazione onesta bastano per cominciare. Decisivo è che da ogni conoscenza nasca un compito con nome e data.
Domande frequenti
Che cos'è un'esercitazione tabletop?
Un'esercitazione in cui i partecipanti discutono insieme un incidente a tavolino, senza lavorare su sistemi reali. Un moderatore introduce passo dopo passo nuove informazioni, il gruppo decide e motiva. Così emergono le lacune in piano, responsabilità ed elenchi dei contatti.
Chi dovrebbe partecipare a un'esercitazione di emergenza?
Tutti coloro che nell'emergenza decidono o agiscono: direzione, IT o fornitore, protezione dei dati, comunicazione e, se presente, la persona responsabile delle questioni assicurative. Più di otto-dieci persone rendono il giro pesante.
Quanto dura un'esercitazione tabletop?
Per un primo svolgimento bastano due o tre ore, valutazione compresa. Più importante della durata è che i risultati vengano annotati e che le misure siano assegnate con una scadenza.
Lo scenario deve essere realistico?
Dovrebbe adattarsi al Suo ambiente, ma non essere esatto nei dettagli. Uno scenario sul modello di una situazione reale come PHP2Shell appare credibile e orienta la discussione sulle decisioni anziché sui dettagli tecnici.