In breve: lessons learned dopo un incidente IT significa: a conclusione tecnica avvenuta, tutti i soggetti coinvolti si siedono insieme, ricostruiscono lo svolgimento, indicano senza attribuire colpe che cosa è andato bene e che cosa no, e ne ricavano misure con responsabili e scadenze. Vale anche per i quasi-incidenti come una settimana PHP2Shell conclusa senza danni. Decisivo non è il verbale, ma il successivo controllo che le misure siano state attuate.
Perché la settimana dopo l'incidente è così importante
Quando il server funziona di nuovo e le patch sono installate, la tentazione di tornare in fretta alla quotidianità è forte. Proprio allora va perso il sapere più prezioso: chi ha notato che cosa e quando? Dove mancava un'informazione? Quale decisione ha richiesto troppo tempo? Tra qualche settimana nessuno lo saprà più con precisione.
La settimana di ottobre 2026 ne è un buon esempio. Molte aziende hanno applicato patch ai server PHP, scritto agli hoster, spento i siti in via precauzionale o conservato i log. Anche se non è stata rilevata alcuna intrusione, c'è molto da imparare. Quanto tempo è occorso per stabilire quali sistemi fossero interessati? Chi doveva autorizzare lo spegnimento ed era raggiungibile?
I passaggi tecnici dopo un attacco li tratta la Checklist dopo un hack. Questo articolo parte da lì: che cosa impariamo?
Lessons learned nell'incidente IT: regole di base per la riunione
Una riunione di valutazione non è un tribunale. Chi teme che gli errori abbiano conseguenze personali racconta solo metà della storia. Vale quindi il principio: cerchiamo le cause in procedure, strumenti e informazioni, non i colpevoli. Le persone hanno agito con le conoscenze che avevano in quel momento.
Inviti tutti i soggetti coinvolti, anche esterni come hoster, agenzia o fornitori, per quanto possibile. Preveda due ore. Chieda prima del materiale: ticket, cronologie di chat, e-mail, appunti, estratti di log. Da qui nasce la cronologia, la spina dorsale della riunione. Come costruirla in modo pulito lo descrive Creare la cronologia di un incidente.
La moderazione non dovrebbe essere assunta dalla persona che ha guidato l'incidente sul piano operativo. Altrimenti valuterebbe le proprie decisioni. È neutrale, ad esempio, una persona di un altro reparto o un partner esterno.
Lo svolgimento in sei passaggi
- Presentare la cronologia: che cosa è successo e quando, dalla prima segnalazione alla chiusura? Contrassegnare le lacune nella cronologia, non tirare a indovinare.
- Che cosa è andato bene? Cominci deliberatamente dal positivo. Mostra che cosa va mantenuto e distende il gruppo.
- Dove si è inceppato? Ogni ritardo, ogni informazione mancante, ogni incertezza viene raccolta, dapprima senza discutere le soluzioni.
- Chiarire le cause: per i punti principali chieda più volte il perché. «La patch è arrivata tardi» è un riscontro, «nessuno sapeva che sul vecchio server girava ancora PHP» è una causa.
- Definire le misure: per ogni causa una misura concreta, una persona responsabile e una scadenza.
- Concordare il controllo successivo: un appuntamento tra quattro e otto settimane, in cui si verifica che cosa è stato attuato.
Domande e misure tipiche dopo una situazione PHP
La tabella seguente mostra domande che si pongono spesso dopo una situazione come PHP2Shell e possibili risposte sotto forma di misure. Non ogni misura si adatta a ogni azienda; serve ad affinare lo sguardo.
| Domanda nella riunione | Riscontro tipico | Misura possibile |
|---|---|---|
| Come siamo venuti a conoscenza della falla? | Per caso, dalle notizie | Sottoscrivere in modo mirato le segnalazioni di sicurezza di php.net e del BSI (l'Ufficio federale tedesco per la sicurezza informatica) |
| Sapevamo quali sistemi erano interessati? | Elenco incompleto, sistema legacy dimenticato | Inventario di tutti i siti e server con versione di PHP |
| Chi poteva decidere lo spegnimento? | Poco chiaro, decisione ritardata | Fissare nel piano di emergenza la facoltà di decidere |
| L'hoster ha confermato la patch? | Solo a voce o per niente | Richiedere conferma scritta, integrare il contratto |
| Tutti i processi PHP sono stati riavviati? | Non verificato | Inserire riavvio e controllo come passaggio fisso |
| I log dal 20/10 erano disponibili? | In parte già sovrascritti | Prolungare il tempo di conservazione, mettere in sicurezza i log in modo centralizzato |
| Come è andata la comunicazione interna ed esterna? | I collaboratori l'hanno saputo dalla stampa | Preparare un'informazione interna iniziale |
Annoti anche ciò che deliberatamente non modifica. A volte un riscontro è noto, ma la misura sarebbe sproporzionata. Una decisione documentata è meglio di una dimenticanza silenziosa.
Nel verbale separi fatti provati, ipotesi probabili e questioni aperte. Proprio dopo PHP2Shell, per cui non esistono Indicators of Compromise pubblicati e confermati, questa distinzione è importante.
Dal verbale al cambiamento
Il fallimento più frequente dei lessons learned è banale: il verbale viene inviato e poi non succede nulla. Tre abitudini aiutano. Primo: ogni misura va nel sistema in cui comunque si lavora, cioè il sistema di ticket o la lista dei compiti, non in un documento separato. Secondo: il controllo successivo riceve un appuntamento fisso nel calendario della direzione. Terzo: i risultati confluiscono in piano di emergenza, elenco dei contatti ed esercitazioni.
Chi vuole verificare le conoscenze acquisite senza aspettare il prossimo incidente reale può simularle in un'esercitazione di emergenza a tavolino. E dove la riunione mostra che gli aggiornamenti dipendevano troppo dal caso, vale la pena trasformarli in un patch management come processo.
Per protezione dei dati, assicurazione ed eventualmente autorità, la relazione finale è inoltre un documento importante. La valutazione giuridica, ad esempio se fosse necessaria una notifica ai sensi dell'art. 33 GDPR, spetta però al responsabile della protezione dei dati o all'avvocato, non alla riunione tecnica.
Come aiuta concretamente PHP SOS?
- Ricaviamo da log, ticket e appunti una cronologia dell'incidente e contrassegniamo le lacune.
- Moderiamo la riunione come parte neutrale e badiamo a cercare le cause anziché i colpevoli.
- Traduciamo i riscontri tecnici in misure con stima dell'impegno e priorità.
- Accompagniamo il controllo successivo e, su richiesta, attuiamo noi stessi le misure tecniche, come previsto nella nostra incident response.
Conclusione
Un incidente costa già abbastanza. Chi non lo analizza paga di nuovo la volta successiva. Una riunione onesta senza attribuzione di colpe, una cronologia pulita e misure con nome e scadenza trasformano una settimana difficile in un guadagno duraturo di sicurezza.
Domande frequenti
Quando dovrebbe svolgersi la riunione di lessons learned?
Quando l'incidente è concluso dal punto di vista tecnico, ma il ricordo è ancora fresco. In pratica si è dimostrato valido un appuntamento circa una o due settimane dopo la chiusura. Prima manca spesso la distanza, dopo i dettagli sbiadiscono.
Serve una riunione anche dopo un quasi-incidente?
Vale la pena. Una situazione come PHP2Shell, in cui alla fine non è successo nulla, mostra comunque dove le procedure si sono inceppate. Queste conoscenze sono particolarmente preziose perché sono nate senza danno.
Chi conduce la riunione?
Meglio una persona che non ha guidato personalmente l'incidente sul piano operativo. Così la moderazione resta neutrale e nessuno deve difendere le proprie decisioni. Può essere anche un fornitore esterno.
Che cosa succede ai risultati?
Ogni conoscenza diventa una misura con persona responsabile e scadenza. Piano di emergenza, elenco dei contatti e documentazione vengono adeguati. Dopo alcune settimane qualcuno verifica che cosa è stato realmente attuato.