In breve: una buona comunicazione di crisi dopo un attacco informatico è rapida, onesta e uniforme. Informi prima internamente, poi gli interessati e i partner, e dica solo ciò che è accertato, tenuto chiaramente distinto da ciò che è ancora in fase di indagine. Gli obblighi di comunicazione, ad esempio ai sensi dell'art. 34 GDPR, vanno concordati con il responsabile della protezione dei dati e con la consulenza legale; questa pagina non è consulenza legale.
Perché la comunicazione fa parte della gestione dell'incidente
Un attacco a un web server è dapprima un problema tecnico. Molto rapidamente diventa però anche una questione di fiducia: i clienti notano un sito non raggiungibile, i partner ricevono e-mail anomale, i collaboratori fanno domande. Chi allora tace o risponde in modo contraddittorio perde più fiducia che per l'incidente stesso.
La situazione attuale intorno a PHP2Shell lo rende tangibile. Molte aziende hanno messo i propri siti offline in via precauzionale o li hanno sottoposti a manutenzione in tempi brevi. Ciò non significa automaticamente che siano state violate. Proprio questa distinzione dovrebbe saperla spiegare verso l'esterno in modo chiaro e pacato.
Comunicazione di crisi dopo un attacco informatico: l'ordine giusto
Un ordine collaudato evita che gruppi importanti vengano a sapere le cose dalla stampa o da terzi:
- Unità di crisi interna: direzione, tecnica, protezione dei dati, eventualmente consulenza legale e assicuratore. Qui si decide che cosa si dice.
- Collaboratori: breve informazione interna con la richiesta di inoltrare le richieste al referente designato e indicazioni di prudenza con le e-mail sospette.
- Autorità, dove necessario: ad esempio l'autorità di controllo della protezione dei dati ai sensi dell'art. 33 GDPR, il BSI (l'Ufficio federale tedesco per la sicurezza informatica) in caso di obbligo NIS2, la polizia in caso di denuncia. L'ordine lo concordi con la Sua consulenza legale.
- Clienti e partner interessati: direttamente e prima di una dichiarazione pubblica, se possibile.
- Pubblico: avviso sul sito web, eventualmente comunicato stampa.
Ai sensi dell'art. 34 GDPR gli interessati vanno informati senza ritardo se una violazione dei dati comporta probabilmente un rischio elevato per loro. Le linee essenziali sono spiegate nella pagina Obbligo di notifica GDPR: 72 ore.
Che cosa deve contenere una comunicazione
Una buona comunicazione è breve e risponde alle domande che si pongono gli interessati. Questa struttura si è dimostrata valida:
| Sezione | Contenuto |
|---|---|
| Che cosa è successo? | Descrizione oggettiva in parole semplici, con il periodo |
| Che cosa sappiamo, che cosa no? | Fatti accertati distinti dall'indagine in corso |
| Chi è interessato? | Gruppi di persone o di dati, per quanto noto |
| Che cosa abbiamo fatto? | Misure immediate, coinvolgimento di esperti e autorità |
| Che cosa dovreste fare? | Raccomandazioni concrete, ad esempio cambiare la password, fare attenzione al phishing |
| Come potete raggiungerci? | Punto di contatto fisso per domande |
Annunci quando informerà di nuovo e rispetti questo impegno. Anche un «ancora nessuna novità» all'ora annunciata crea fiducia.
Prepari modelli per l'informazione interna, la comunicazione ai clienti e l'avviso sul sito prima che accada qualcosa. Nel caso concreto basterà allora inserire i fatti.
Che cosa è meglio evitare
Alcune formulazioni e comportamenti danneggiano regolarmente:
- Falso allarme rientrato: «Non sono stati sottratti dati» è ammissibile solo se comprovato. Una patch applicata non prova che prima non sia successo nulla.
- Minimizzazione: espressioni come «piccolo inconveniente tecnico» appaiono disoneste se in seguito si viene a sapere di più.
- Attribuzione di colpa: i riferimenti a hoster, fornitori di servizi o produttori non aiutano gli interessati e possono avere conseguenze legali.
- Dettagli tecnici utili agli attacchi: vulnerabilità concrete dei Suoi sistemi non rientrano nelle comunicazioni pubbliche.
- Garanzie: affermazioni come «completamente sicuro» o «inattaccabile» non si possono mantenere.
Sito web, motori di ricerca e ondata di phishing
Dopo un attacco a un sito web si aggiungono spesso due fenomeni collaterali. Primo, Google può mostrare un avviso se è stato trovato codice dannoso; come farlo rimuovere dopo la bonifica è spiegato alla pagina Rimuovere l'avviso di Google. Secondo, i truffatori sfruttano gli incidenti noti per e-mail false a nome dell'azienda interessata. Avvisi attivamente i Suoi clienti e indichi attraverso quali canali comunica realmente.
Se mette il sito offline in via precauzionale, basta una semplice pagina statica con un breve avviso e un canale di contatto che non dipenda dal server interessato.
Una volta concluso l'incidente, vale la pena inviare una comunicazione conclusiva a tutti coloro che aveva informato in precedenza: che cosa ha accertato l'indagine, quali misure sono state attuate in modo duraturo e a chi ci si può rivolgere ancora. Molte aziende omettono questo passaggio perché la pressione diminuisce. Proprio questo mostra però che ha preso sul serio l'incidente. Valuti inoltre internamente che cosa nella comunicazione è andato bene e che cosa no, e adegui di conseguenza modelli e responsabilità nel Suo piano di emergenza.
Come aiuta concretamente PHP SOS?
- Forniamo i fatti tecnici in forma comprensibile e distinguiamo chiaramente tra comprovato, probabile e sconosciuto.
- Verifichiamo le bozze delle Sue comunicazioni sotto il profilo della correttezza tecnica e dei dettagli che potrebbero aiutare gli aggressori.
- Mettiamo a disposizione in tempi brevi una pagina statica di manutenzione che gira indipendentemente dal sistema interessato.
- Con l'incident response teniamo la tecnica al passo con la Sua comunicazione, in modo che gli impegni sullo stato delle informazioni possano essere rispettati.
Domande frequenti
Dobbiamo rendere pubblico un attacco finché non è tutto chiaro?
Dipende da situazione, obblighi e persone coinvolte. Spesso una comunicazione breve e oggettiva con lo stato noto è meglio del silenzio, perché altrimenti clienti e partner lo apprendono da altre fonti. Concordi il momento con la consulenza legale e l'assicuratore.
Che cosa non dovrebbe assolutamente comparire in una comunicazione ai clienti?
Supposizioni che appaiono come fatti, attribuzioni di colpa a terzi, dettagli tecnici che aiutano gli aggressori e promesse che non può mantenere con certezza. Formulazioni come completamente escluso andrebbero usate solo se comprovate.
Chi dovrebbe parlare verso l'esterno?
Una persona designata, di solito della direzione o della comunicazione aziendale, supportata da tecnica e consulenza legale. Tutti gli altri rimandano a questo referente. Così le dichiarazioni restano uniformi.
Dobbiamo mettere offline il nostro sito e spiegarlo?
Se mette il sito offline in via precauzionale, aiuta un breve avviso, ad esempio su una pagina statica di manutenzione. Non deve essere tecnico. Una messa offline precauzionale non significa automaticamente che un attacco sia riuscito.