Log degli incidenti di sicurezza: come creare log conformi al GDPR e alle autorità di controllo

La parte più difficile di un incidente di sicurezza di solito si verifica dopo che l’incidente stesso è finito: quando l’azienda deve spiegare cosa è successo, quando è stato scoperto, quali dati sono stati coinvolti, chi è stato interessato e perché sono state prese determinate decisioni.

Per molte PMI, questi registri non esistono in forma completa. I dettagli possono essere sparsi tra messaggi di chat, caselle di posta in arrivo, ticket di helpdesk, screenshot e ricordi dei membri del team. Le aziende restano a galla durante un incidente con questi registri frammentari, ma diventano un problema quando un’autorità di controllo, un assicuratore, un cliente o un membro del consiglio chiede una cronologia chiara.

Le aziende di tutte le dimensioni hanno bisogno di un log completo degli incidenti di sicurezza. Dovrebbe essere un’unica fonte di verità per registrare cosa è successo, come è stato gestito l’incidente e quali prove supportano le decisioni prese lungo il percorso.

Il registro è prezioso anche quando non devi segnalare un incidente. Spiegheremo perché i log degli incidenti di sicurezza sono utili per la tua azienda e come crearne di tuoi.

Perché i log degli incidenti di sicurezza sono importanti

Log degli incidenti e piani di risposta agli incidenti

Cosa deve contenere un log degli incidenti di sicurezza

Un semplice modello di log degli incidenti per PMI

Come registrare le decisioni di notifica

Cosa si aspettano le autorità di controllo dai log degli incidenti di sicurezza

Il log di accesso alle credenziali

Perché i log degli incidenti di sicurezza sono importanti

I log degli incidenti di sicurezza creano responsabilità nel momento in cui è più probabile che un’azienda perda traccia dei dettagli. Durante un incidente, le azioni avvengono rapidamente: le password vengono reimpostate, gli account vengono disabilitati, i fornitori IT vengono contattati, i dati dei clienti vengono controllati e la leadership viene informata. Questi passaggi possono essere esattamente ciò di cui l’azienda ha bisogno al momento, ma diventano molto più difficili da spiegare in seguito se nessuno registra quando si è verificata ogni azione, chi l’ha approvata e quali prove hanno supportato la decisione.

Per le aziende con sede in Europa, questa non è solo una buona pratica. Ai sensi del Regolamento generale sulla protezione dei dati (GDPR), sia nel Regno Unito che nell’UE, le violazioni di dati personali devono essere valutate e alcune devono essere segnalate all’autorità di controllo competente.

Nel Regno Unito, la guida dell’ICO sulla segnalazione di una violazione(nuova finestra)⁠ spiega che le organizzazioni devono valutare il rischio probabile per i diritti e le libertà delle persone e notificare all’ICO quando tale rischio è probabile. L’articolo 33 richiede inoltre ai titolari del trattamento di documentare le violazioni di dati personali, inclusi i fatti della violazione, i suoi effetti e le azioni correttive adottate. Gli stessi requisiti si applicano ai sensi del GDPR dell’UE.

Ad esempio, l’ICO non si aspetta che ogni PMI disponga di sistemi di livello enterprise, ma si aspetta registri adeguati. Il suo quadro di risposta e monitoraggio delle violazioni afferma che le organizzazioni dovrebbero avere procedure per assicurarsi che gli incidenti e le violazioni di dati personali siano rilevati, gestiti e registrati in modo appropriato. Ciò significa che un log degli incidenti non dovrebbe essere creato solo quando si è già verificata una violazione grave. Dovrebbe far parte del normale processo di risposta.

Dei buoni registri supportano anche le richieste di risarcimento assicurativo. Gli assicuratori cyber possono chiedere prove di quando è stato scoperto l’incidente, quali misure di contenimento sono state adottate, quali account sono stati coinvolti e se l’azienda ha seguito il proprio processo di risposta agli incidenti. Un log ben tenuto può dimostrare che l’azienda ha agito prontamente e in modo coerente.

Aiuta anche l’azienda a imparare. I ricordi e i resoconti orali non sono affidabili, ma un registro che mostra che l’incidente è iniziato con una password riutilizzata, la mancanza di autenticazione a più fattori (MFA), l’accesso di fornitori o un offboarding ritardato offre all’azienda qualcosa di concreto da correggere e una direzione più chiara per rafforzare la sicurezza nel tempo.

Log degli incidenti e piani di risposta agli incidenti

Un log degli incidenti di sicurezza e un piano di risposta agli incidenti sono collegati, ma non sono lo stesso documento.

Un piano di risposta agli incidenti spiega cosa dovrebbe fare l’azienda quando qualcosa va storto. Assegna ruoli, percorsi di escalation, misure di contenimento, responsabilità di comunicazione e procedure di recupero. Il log degli incidenti registra ciò che è realmente accaduto. È la cronologia, la traccia delle prove, il registro delle decisioni e il file di follow-up per un evento specifico.

Questa distinzione è importante perché anche un buon piano può fallire senza documentazione. Un’azienda può seguire i passaggi giusti ma avere comunque difficoltà a dimostrarlo in seguito. Il log dovrebbe rendere possibile rispondere a domande pratiche: quando lo abbiamo saputo, chi ha agito, cosa abbiamo contenuto, quali dati erano a rischio, cosa abbiamo deciso e cosa è cambiato in seguito?

Cosa deve contenere un log degli incidenti di sicurezza

Un log degli incidenti utile deve essere sufficientemente coerente da consentire a un’azienda di ricostruire l’evento in seguito e spiegare le decisioni prese durante la risposta.

Data e ora della scoperta

Registra quando l’azienda è venuta a conoscenza dell’incidente per la prima volta, chi lo ha notato e come è stato scoperto. Se l’ora è approssimativa, contrassegnala come approssimativa. L’ora della scoperta è importante perché le tempistiche di segnalazione del GDPR e i requisiti assicurativi spesso dipendono da quando l’azienda è venuta a conoscenza del problema.

Natura dell’incidente

Descrivi ciò che è accaduto in un linguaggio semplice. Evita etichette vaghe come “problema di sicurezza” o “possibile violazione” senza contesto. Il log dovrebbe spiegare quali sistemi sono stati coinvolti e se l’incidente ha riguardato credenziali, email, file, dati dei clienti, sistemi di pagamento, endpoint o accessi di terze parti.

Dati coinvolti

Se i dati personali possono essere stati interessati, registra che tipo di dati è stato coinvolto: nomi, indirizzi email, numeri di telefono, indirizzi, dettagli dell’account, informazioni finanziarie, registri dei dipendenti, comunicazioni con i clienti, credenziali di accesso o qualsiasi altra categoria pertinente. Stima quante persone possono essere interessate e chiarisci se il numero è confermato o ancora in fase di indagine.

Causa probabile

Registra la causa nota o sospetta, anche se l’indagine è ancora in corso. Man mano che emergono nuovi dettagli, il log può essere aggiornato da “causa sconosciuta” a “email di phishing che ha portato alla compromissione delle credenziali” o “l’account di un ex collaboratore è rimasto attivo”. Il log dovrebbe mostrare come è cambiata la comprensione dell’azienda nel tempo.

Azioni di contenimento immediate

Documenta ciò che è stato fatto per limitare i danni. Ciò può includere la reimpostazione delle password, la revoca della sessione, l’applicazione dell’MFA, la sospensione dell’account, la rimozione delle regole della casella email, l’isolamento del dispositivo, la rimozione dell’accesso dei fornitori, modifiche al firewall o interruzioni temporanee del servizio. Ove possibile, includi il responsabile e la marca temporale per ogni azione.

Decisioni di notifica

Registra se l’azienda ha notificato all’autorità di controllo competente (l’ICO nel Regno Unito o l’autorità nazionale per la protezione dei dati altrove nell’UE), alle persone interessate, ai clienti, ai fornitori, agli assicuratori, ai consulenti legali o alle forze dell’ordine. Se la decisione è stata di non notificare, documenta la motivazione. Tale spiegazione è spesso importante quanto la notifica stessa.

Misure correttive e cronologia

Il contenimento affronta l’incidente immediato. La correzione riduce la probabilità che lo stesso problema si verifichi di nuovo. Registra le azioni di follow-up come l’applicazione dell’MFA, la rimozione delle credenziali condivise, l’aggiornamento delle politiche di accesso, il miglioramento dell’offboarding, la correzione di una configurazione errata o la modifica del modo in cui i backup sono protetti.

Lezioni apprese

Concludi con ciò che l’azienda ha imparato e ciò che cambierà. Non dovrebbe essere scritto come un’accusa. Dovrebbe identificare la debolezza, il miglioramento necessario e chi è responsabile del follow-up.

Un semplice modello di log degli incidenti per PMI

Un software specialistico non è necessario per documentare gli incidenti. Un foglio di calcolo, un modulo interno sicuro, un sistema di ticketing o un registro condiviso possono funzionare se l’accesso è controllato e le voci sono mantenute coerenti.

Un log degli incidenti efficace dovrebbe includere questi campi:

• ID incidente: un numero di riferimento univoco.
• Data e ora della scoperta: quando l’azienda è venuta a conoscenza dell’incidente.
• Segnalato da: dipendente, fornitore, cliente, venditore, avviso di monitoraggio o parte esterna.
• Tipo di incidente: phishing, malware, compromissione delle credenziali, perdita di dati, accesso non autorizzato, ransomware, incidente del fornitore, perdita del dispositivo, email inviata per errore o altro.
• Riepilogo: cosa è successo, descritto in linguaggio semplice.
• Sistemi interessati: applicazioni, account, dispositivi, database, caselle di posta in arrivo o servizi di terze parti coinvolti.
• Dati coinvolti: se sono stati interessati dati personali, di quale tipo e quante persone potrebbero essere coinvolte.
• Causa probabile: nota, sospetta o in fase di indagine.
• Azioni di contenimento: cosa è stato fatto immediatamente.
• Decisione di notifica: autorità di controllo, persone interessate, clienti, assicuratore o nessuna notifica con relativa motivazione.
• Link alle prove: screenshot, ticket, log, email, registrazioni degli accessi, file esportati o report dei fornitori.
• Azioni di rimedio: passaggi intrapresi dopo il contenimento.
• Responsabile: persona incaricata del follow-up.
• Stato: aperto, in monitoraggio, contenuto, risolto, chiuso.
• Lezioni apprese: cosa dovrebbe cambiare.

Come registrare le decisioni di notifica

Le decisioni di notifica meritano uno spazio dedicato in un registro degli incidenti di sicurezza, perché vengono spesso riesaminate dopo l’incidente.

Ai sensi del GDPR del Regno Unito e dell’UE, le organizzazioni devono valutare il rischio probabile per i diritti e le libertà delle persone quando si verifica una violazione dei dati personali. Se il rischio è probabile, l’autorità di controllo deve essere notificata il prima possibile e, ove possibile, entro 72 ore: l’ICO(nuova finestra) nel Regno Unito, l’autorità nazionale per la protezione dei dati in ciascuno Stato membro dell’UE. Se il rischio è elevato, anche le persone interessate devono essere notificate senza ingiustificato ritardo. Le soglie e i tempi sono gli stessi su entrambi i fronti; cambia solo l’autorità.

Un buon registro degli incidenti dovrebbe dimostrare che l’azienda ha effettuato questa valutazione. Dovrebbe registrare se sono stati coinvolti dati personali, quale tipo di danno potrebbe derivarne, quali protezioni erano in atto e perché l’azienda ha deciso di segnalare o non segnalare.

Ad esempio, un incidente che coinvolge una password di amministratore esposta potrebbe non rivelare immediatamente se sono stati effettuati accessi ai dati personali. Il registro dovrebbe riflettere tale incertezza. Può registrare la preoccupazione iniziale, le fasi dell’indagine, l’esame dell’attività dell’account e la conclusione finale una volta disponibili le prove.

A questo punto del processo, molte aziende si concentrano sull’organizzazione della correzione tecnica e dimenticano di registrare le motivazioni di conformità. Le password vengono reimpostate, gli account vengono messi in sicurezza e le operazioni proseguono. Settimane dopo, l’azienda non è in grado di spiegare perché ha deciso che l’incidente non era segnalabile.

Cosa si aspettano le autorità di controllo dai registri

Le autorità di controllo non guardano solo se una violazione è stata segnalata. Potrebbero anche chiedere in che modo l’azienda:

• Ha identificato l’incidente
• Ha valutato il rischio
• Ha deciso se la notifica era necessaria
• Ha documentato le azioni intraprese

Un buon registro dovrebbe rendere chiara la storia dell’incidente dall’inizio alla fine. Dovrebbe mostrare cosa è successo, quali dati personali sono stati coinvolti, quale danno potrebbe derivarne, cosa ha fatto l’azienda per contenere il problema e perché ha segnalato o non ha segnalato la violazione.

Il livello di dettaglio dovrebbe corrispondere alla gravità dell’incidente. Un’email inviata per errore non avrà bisogno dello stesso registro di un attacco ransomware, ma deve comunque essere documentata per dimostrare che l’azienda l’ha valutata correttamente.

Questi registri dovrebbero anche essere archiviati in modo sicuro. I registri degli incidenti possono includere dettagli sensibili sulle persone interessate, sui sistemi esposti, sulle azioni dei dipendenti, screenshot, log di accesso o fasi di rimedio. L’accesso dovrebbe essere limitato alle persone che ne hanno bisogno e la conservazione dovrebbe essere in linea con la più ampia politica di conservazione dei dati dell’azienda.

Il registro degli accessi alle credenziali

Molti incidenti coinvolgono le credenziali: possono essere innescati da una password riutilizzata, un account condiviso, una casella di posta compromessa, un login di amministratore esposto, una richiesta MFA sospetta o un dipendente per cui non è stato eseguito correttamente l’offboarding.

Per questo motivo, i registri degli accessi alle credenziali possono diventare un input diretto per la documentazione degli incidenti di sicurezza informatica. Quando un incidente coinvolge un login condiviso o un account sensibile, l’azienda deve sapere chi aveva accesso, come è stato condiviso l’accesso, se le autorizzazioni sono cambiate e se la credenziale è stata ruotata dopo l’incidente.

Un gestore di password aziendale⁠ come Proton Pass for Business aiuta i team a gestire le credenziali in cassaforti crittografate, generare password univoche, utilizzare il riempimento automatico, condividere le credenziali in modo sicuro, gestire le chiavi di accesso e utilizzare l’autenticazione a due fattori integrata. Per la documentazione degli incidenti, il valore più forte è la traccia di accesso relativa alle credenziali: chi aveva accesso a cassaforti/account condivisi, come è stato gestito l’accesso e chi lo ha utilizzato, e cosa è cambiato dopo l’incidente.

Un gestore di password per i team IT aggiunge funzionalità di amministrazione come policy, report, log, controllo degli accessi basato sui ruoli, provisioning SCIM e integrazione SSO. Queste funzionalità possono aiutare le aziende a dimostrare come viene controllato l’accesso alle credenziali e a fornire prove quando viene indagato un incidente legato alle credenziali.

Un gestore di password non può sostituire un registro degli incidenti, una valutazione legale, un processo di notifica normativa o un piano di risposta agli incidenti. Ma fornisce prove sulle credenziali che possono alimentare tali processi.

Mantieni una traccia di controllo completa degli accessi alle credenziali con un gestore di password aziendale⁠.