Incident e data breach response, quali adempimenti alla luce di GDPR e ISO 27035

L’art. 33 del Reg. UE 679/2016 (di seguito “GDPR”) impone al titolare del trattamento di notificare all’Autorità di Controllo entro 72 ore dalla conoscenza gli incidenti che possono comportare violazioni dei diritti e le libertà degli interessati. Il ristretto limite temporale imposto al titolare del trattamento per la notifica del data breach evidenzia la necessità di strutturare all’interno dell’organizzazione un processo di gestione degli incidenti che tenga conto anche della possibilità di dover reagire a fronte di una violazione dei dati personali. Ecco un framework per la gestione degli incidenti classificabili come data breach in conformità alle linee guida dettate dalla ISO 27035-2 “Guidelines to plan and prepare for incident response” e le istruzioni del Working Party 29 n. 250 “Guidelines on Personal data breach notification under Regulation 2016/679”. Altro utile strumento sono le Linee guida del EDPB “Guidelines 01/2021 on Examples regarding Data Breach Notification”, che forniscono una serie di esempi di gestione di alcune categorie di data breach.

Incident e data breach

Gli adempimenti richiesti dall’art. 23 del GDPR trovano applicazione nei confronti di tutti i soggetti qualificabili come “titolari del trattamento”. A fronte di un obbligo generale, troviamo però un tessuto imprenditoriale spesso non preparato a reagire in modo strutturato agli incidenti. Per questo motivo si ritiene utile mettere a disposizione un framework che:

• in primo luogo, funga da guida generale per la gestione di un incidente;
• in secondo luogo, fornisca gli strumenti per la gestione di quei particolari incidenti classificabili come “data breach”.

Per comprendere una simile impostazione del framework, occorre risalire alle definizioni di “incidente” da un canto e di “data breach” dall’altro.

Per “incidente”, in ambito di gestione delle informazioni, si intende un evento che comporti la perdita di integrità, confidenzialità o riservatezza delle informazioni.

Per “data breach” si intende un evento che comporti la perdita di integrità, confidenzialità o riservatezza di un dato personale.

Considerato che i dati personali altro non sono che una particolare categoria di informazioni trattate dall’Organizzazione, il processo di gestione di un incidente e quello di gestione di un data breach sono sovrapponibili, salvo alcuni adempimenti ulteriori richiesti in maniera specifica dal GDPR.

Incident management

La norma ISO 27035 divide il processo di gestione degli incidenti in cinque fasi:

1) plan and prepare;

2) detect and reporting;

3) assessment and decision;

4) responses;

5) learn.

Il processo di gestione di un incidente può essere raffigurato come segue:

Detect and reporting

Assessment and decision:

– Analisi;

– Documentazione;

– Definizione delle priorità.

Responses:

– Notificazioni e comunicazioni;

– Raccolta evidenze;

– Azioni di risposta all’incidente.

Learn:

– Raccolta dati forensi incidente;

– Identificazione e salvataggio lezioni apprese.

Plan & Prepare:

– Policy e procedure;

– Ruoli e responsabilità;

– Incident Response Team;

– Procedure per la gestione dell’incidente;

– Gestione dei rischi;

– Training per la prevenzione degli incidenti

Lo standard ISO 27035 elenca una serie di attività preparatorie da adottare al fine di una corretta gestione degli incidenti.

In particolare, nella prima fase, è necessario:

• stabilire dei criteri di gestione degli incidenti di sicurezza delle informazioni e formalizzarli in policy/politiche aziendali;
• creare una procedura specifica di gestione degli incidenti che contenga anche un criterio di classificazione in termini di gravità;
• definire ruoli e responsabilità nella gestione degli incidenti;
• assegnare le funzioni inerenti al Incident Response Team e le connessioni con le altre funzioni aziendali;
• stabilire, implementare e gestire tecniche e altri meccanismi di supporto in caso di incidente;
• progettare e sviluppare un programma di sensibilizzazione e formazione.

Per la fase di detection and reporting, la ISO 27035 prevede una serie di attività che mirano:

• al rilevamento di vulnerabilità o di incidenti;
• alla raccolta di informazioni e reportistica su eventi e vulnerabilità rilevati.

Lo standard in particolare menziona:

• sistemi di monitoraggio della sicurezza come Intrusion Detection System (IDS) o di prevenzione delle intrusioni – Intrusion Detection Prevention (IDP), software antivirus, honeypot, sistemi di monitoraggio dei log;
• sistemi di monitoraggio della rete come firewall, sistemi di analisi del flusso di rete e filtraggio web.

Dopo il rilevamento, tutte le informazioni sull’evento devono essere raccolte e analizzate nella fase di assessment and decision.

Le attività di analisi devono essere documentate assieme alle prove digitali a loro supporto in un sistema di raccolta delle evidenze inerenti gli incidenti di sicurezza.

In questa fase avviene anche la classificazione dell’incidente sulla base dell’impatto dell’incidente nei confronti degli interessati, degli asset e dei sistemi.

A questo punto potrebbero verificarsi differenti scenari:

1. l’evento occorso non è classificabile come incidente;
2. l’evento occorso è classificabile come incidente di sicurezza, ma non come data breach;
3. l’evento occorso è classificabile come incidente di sicurezza e anche come data breach.

Nel primo caso l’Incident Response Team deve confermare il fatto che l’evento non sia classificabile come incidente. In questa eventualità verranno comunque conservate le evidenze raccolte e verranno valutate eventuali azioni da intraprendere per evitare il ripetersi dell’evento.

Nel secondo caso l’Incident Response Team confermerà in primo luogo che l’incidente non coinvolge dati personali.

Giunti a questa valutazione occorrerà reagire all’incidente. Nella fase di response, l’incidente viene affrontato come pianificato nella fase di valutazione e decisione. Anche in questo momento è importante raccogliere le evidenze a supporto delle attività compiute.

La ISO 27035 identifica alcune attività specifiche come fondamentali per questa fase:

• stabilire se l’incidente è sotto controllo;
• assegnare le risorse interne e identificare risorse esterne necessarie alla risoluzione;
• condurre analisi forensi, se necessario;
• effettuare le necessarie comunicazioni.

Man mano che sono disponibili ulteriori informazioni, è possibile diventi necessario modificare la classificazione data nella fase di assessment.

Una volta risolto l’incidente, è importante formalizzarne la chiusura in un report dove registrare non solo le azioni immediate, come l’interruzione o l’arresto di sistemi o reti, ma anche le attività da compiere successivamente, come il ripristino del sistema e le attività di formazione da svolgere per prevenire che incidenti simili si ripetano.

La fase di learn avviene dopo che l’incidente è stato risolto. Le attività possibili in questa fase sono molteplici:

• esecuzione di ulteriori analisi forensi, se necessario;
• identificazione delle lezioni apprese;
• revisione, aggiornamento e miglioramento dell’attuazione di controlli di sicurezza, delle politiche di gestione degli incidenti di sicurezza, della valutazione dei rischi esistenti;
• riesame dell’efficacia del processo di risposta e delle procedure di incident management;
• aggiornamento dei database degli incidenti e delle vulnerabilità.

Data breach management

Nel precedente paragrafo abbiamo visto che nella fase di assessment and decision l’incidente di sicurezza deve essere classificato. Come già detto, talvolta un incidente può configurare anche un data breach, quindi una perdita di integrità, confidenzialità o riservatezza di dati personali.

In questa ipotesi, oltre alle Linee Guida ISO 27035, occorre tenere in considerazione gli adempimenti richiesti dal GDPR.

L’art. 33 impone al Titolare del trattamento un obbligo di notifica della violazione all’autorità di controllo entro 72 ore dal momento della conoscenza nel caso in cui la violazione possa compromettere i diritti o le libertà degli interessati.

Si pongono immediatamente due questioni:

1. come valutare se una violazione compromette i diritti o le libertà degli interessati?
2. da quando iniziano a decorrere i termini per la la notifica?

Data breach impact assessment

Per rispondere al primo quesito occorre espandere la fase di assessment and decision analizzata nel paragrafo precedente.

In primo luogo, occorre classificare i livelli di rischio per i diritti e le libertà degli interessati e le conseguenze derivanti dalla classificazione adottata.

In linea di massima può essere utilizzato lo schema seguente:

Ad ogni livello di rischio deve essere associato un valore.

Ad es.:

• Rischio basso: valore da 1 a 3
• Rischio medio: valore da 3.1 a 6
• Rischio alto: valore maggiore a 6.1

Una volta classificati i livelli di rischio, l’organizzazione deve determinare i parametri su cui calcolare la gravità dell’incidente occorso.

Alcuni esempi:

Tipologia di dati:

• dati pubblici comuni (es. nome, cognome, indirizzo) > livello di rischio = 1
• dati finanziari che non consentono di effettuare operazioni (es. IBAN, estremi conto corrente) > livello di rischio 2
• dati particolari o dati che consentono di effettuare operazioni finanziarie (es. dati su orientamento religiosi, politico, sessuale, dati biometrici, n. carta di credito) > livello di rischio

Valutazione dell’identificabilità dell’interessato in relazione al tipo di dato:

• scarsa probabilità di identificazione > livello di rischio = 1
• improbabile (es. nome e cognome) > livello di rischio =2
• probabile (es. nome, cognome, codice fisale) > livello di rischio =3

Attualità del dato:

• dato di oltre 5 anni > > livello di rischio = 1
• dato riferibile ad una situazione precedente da 1 a 5 anni, ma ancora valido > livello di rischio = 2
• dato attuale > livello di rischio = 3

A questo punto occorre sommare i risultati

R=a+b+c.

Se il valore attesta un possibile scenario ad alto rischio (valore maggiore a 6.1) è bene anche valutare la numerosità dei soggetti coinvolti in relazione al numero totale degli interessati di cui si trattano i dati.

1. Soggetti coinvolti:

• meno del 25% > livello di rischio = 1
• meno del 50% > livello di rischio = 2
• oltre il 50% > livello di rischio = 3

A questo punto:

R= a+b+c+d

Determinato il valore assoluto del rischio, occorre ponderarlo (Rp= Rischio ponderato) in relazione alle misure di sicurezza attuate per contenere le conseguenze dell’incidente.

1. Contromisure adottate:

• nessuna contromisura: valore 1
• misure che consentono di ripristinare integrità, disponibilità e riservatezza entro 3 giorni: valore 2
• misure che consentono di ripristinare integrità, disponibilità e riservatezza entro 24h: valore 3

Calcolo del rischio ponderato:

Rp= a+b+c+d*

e

d*: solo in caso di R alto.

Ovviamente questa metodologia d’analisi deve essere condotta da personale addestrato ed esperto in materia privacy per adeguarla al contesto specifico di riferimento. Se ad esempio l’organizzazione di riferimento è un’azienda sanitaria, il ripristino dei dati in 24h potrebbe comunque comportare gravissime conseguenze.

Una volta ricavato il dato Rp è possibile stabilire le conseguenze del data breach. Si passa quindi alla fase di response, in cui il Titolare del Trattamento è tenuto, se opportuno, a inviare la comunicazione al Garante e agli interessati.

Per scenari di rischio bassi la comunicazione non è dovuta. Per quelli medi o alti invece è necessario inviarla. Il Garante della protezione dei dati mette a disposizione nel proprio sito il modello di notifica. Le informazioni con cui compilare il modello devono essere raccolte nelle fasi di detect and reporting e di assessment e decision.

È sempre possibile integrare la comunicazione inviata al Garante nel caso si dovesse disporre di informazioni aggiuntive successivamente (ad esempio nella fase di response).

Il Titolare del Trattamento deve conservare un registro dei data breach gestiti, anche di quelli che non hanno scaturito alcun obbligo di notifica.

Le evidenze dei data reach serviranno infatti per la fase di learn successiva alla chiusura dell’incidente.

Termini per la notifica al Garante

Per rispondere al secondo quesito, ovvero “da quando iniziano a decorrere i termini per la notifica del data breach?”

Il tempo di riferimento da cui iniziano a decorrere i termini della notifica viene individuato dall’art. 33 GDPR nel momento in cui il Titolare acquisisce consapevolezza dell’avvenuta violazione.

Il Working party 29 ritiene che debba considerarsi “a conoscenza” il titolare che abbia un ragionevole grado di certezza in merito alla verificazione di un incidente di sicurezza. È evidente che, in base alle specifiche circostanze, mentre alcune violazioni saranno facilmente rilevabili, per altre sarà necessario instaurare un’indagine più approfondita. In questi casi, durante la fase di detection, il titolare può essere considerato come privo di un grado di conoscenza tale da far scattare immediatamente l’obbligo di notifica. Tuttavia, il diligente comportamento del titolare sarà in ogni caso valutato sulla base della sua tempestiva attivazione in caso venga informato di una possibile infrazione. La fase di detection, quindi, non deve essere prolungata al fine di protrarre il termine per la notifica.

In particolare, sarà considerato diligente il Titolare che abbia predisposto un piano di sicurezza che evidenzi le procedure organizzative interne da adottare nella gestione di eventuali violazioni e l’organigramma dei soggetti o dei livelli direttivi a cui è necessario fare riferimento per riportare l’accadimento. In tal caso, se la procedura di gestione viene attivata immediatamente, la notifica del data breach avvenuta oltre le 72 ore dal primo avviso di possibile infrazione può comunque considerarsi in termini.

In caso di affidamento di un trattamento ad un responsabile, il titolare deve considerarsi a conoscenza della violazione nel momento in cui il proprio responsabile ne dà comunicazione. È fondamentale quindi vincolare i Responsabili del Trattamento a una tempestiva comunicazione degli incidenti.

Per quanto attiene alla notifica agli interessati, l’art. 34 GDPR afferma che quando la violazione dei dati personali è suscettibile di presentare un rischio elevato per i diritti e le libertà delle persone fisiche, il titolare del trattamento comunica la violazione all’interessato senza ingiustificato ritardo. Non esiste quindi un termine preciso per la notifica. Tuttavia, deve ritenersi puntuale la notifica giunta all’interessato immediatamente dopo a quella obbligatoria inoltrata al Garante.

Conclusioni

L’aumento costante dei dati personali trattati e degli incidenti di sicurezza che coinvolgono i sistemi aziendali mettono in risalto la stretta connessione tra le tematiche di incident e data breach management. Integrare le procedure è fondamentale per rendere efficiente la gestione degli eventi, sia che si tratti di incidenti relativi alle informazioni, sia che si tratti di data breach.