Un processo per la gestione dei personal data breach: indicazioni e soluzioni pratiche

Il Regolamento Europeo GDPR individua, tra le “figure soggettive”, coloro che stabiliscono finalità e modalità di gestione dei dati personali (i cosiddetti “titolari del trattamento”), ai quali viene attribuito l’onere di adottare misure tecnico/organizzative atte a minimizzare la probabilità di violazione degli stessi dati (o “personal data breach”) con conseguente possibile impatto sulle persone fisiche (gli “interessati al trattamento” o “interessati”). Tali misure tecnico/organizzative, per quanto incisive, non azzerano mai la probabilità di un incidente e dunque il titolare è tenuto a mettere in atto un processo di gestione del personal data breach che gli consenta di rendere minimo l’impatto sugli interessati dovuto ad una compromissione dei dati personali, ottemperando nel contempo agli obblighi normativi previsti dallo stesso GDPR e da altre normative di settore.

In questo articolo si descrive come impostare un processo di gestione dei personal data breach, mettendone in evidenza le fasi, gli attori e i deliverable previsti. Tutto ciò con l’obiettivo di dare indicazioni pragmatiche per la “messa a regime” operativa il più possibile indipendenti dalle dimensioni dell’organizzazione e dal particolare settore di mercato nel quale essa opera.

Cos’è un personal data breach

Per descrivere cosa si intenda per personal data breach si può ricorrere dapprima alle definizioni riportate nella normativa vigente e, successivamente, si può cercare di contestualizzare questo fenomeno nell’ambito delle “best practice” con l’obiettivo di strutturare un processo di gestione.

La definizione di personal data breach (in italiano “violazione dei dati personali”) è riportata al Capo I – Disposizioni Generali art.4 del GDPR nel quale si definisce come:

“violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso ai dati personali trasmessi, conservati o comunque trattati;”.

Tuttavia, una definizione più dettagliata e pragmatica viene fornita nel documento “Linee guida sulla notifica delle violazioni dei dati personali ai sensi del regolamento (UE) 2016/679” pubblicato in ultima versione il 6 febbraio 2018 dal Gruppo di Lavoro Articolo 29 per la Protezione dei Dati Personali (già EDPB – European Data Protection Board).

In questo documento si afferma in modo chiaro ed esplicito che un personal data breach “è un tipo di incidente di sicurezza” la cui conseguenza “è che il titolare del trattamento non è più in grado di garantire l’osservanza dei principi relativi al trattamento dei dati personali di cui all’articolo 5 del Regolamento”.

Questo passaggio è di estrema importanza dal momento che mette in relazione il concetto di violazione di dati personali con quello dell’incidente di sicurezza e quindi ci fornisce tutta una serie di strumenti e “best practice” per poter definire i processi operativi per la gestione del personal data breach, come vedremo nei successivi paragrafi.

Ancora il documento del Gruppo di Lavoro Articolo 29 definisce quali siano le tipologie di data breach, riprendendo anche quanto riportato nel parere 3/2014 e contestualizzando rispetto ai tre principi ben noti della sicurezza delle informazioni ossia riservatezza, integrità e disponibilità, come di seguito riportato:

“[omissis]

• “violazione della riservatezza”, in caso di divulgazione dei dati personali o accesso agli stessi non autorizzati o accidentali;
• “violazione dell’integrità”, in caso di modifica non autorizzata o accidentale dei dati personali;
• “violazione della disponibilità”, in caso di perdita, accesso o distruzione accidentali o non autorizzati di dati personali.

Va altresì osservato che, a seconda dei casi, una violazione può riguardare contemporaneamente la riservatezza, l’integrità e la disponibilità dei dati personali, nonché qualsiasi combinazione delle stesse. [omissis]”.

Si evidenzia che la “violazione di disponibilità” viene determinata sicuramente dalla perdita o distruzione dei dati, ma anche dall’accesso, cioè dall’impossibilità da parte del titolare e dell’interessato di accedere ai dati ed ai servizi ad essi correlati.

Questo aspetto viene spesso trascurato nella gestione dei data breach ma è di assoluta importanza, dal momento che l’impossibilità ad accedere ai dati può senza dubbio causare danni agli interessati. Si pensi ad esempio all’impossibilità ad accedere ai dati sanitari in occasione di un importante intervento medico o al mancato accesso ai propri dati bancari con conseguente impossibilità a procedere con operazioni di pagamento o di fido.

L’obbligo di notifica del data breach

Altro aspetto importante introdotto dal GDPR (ed ancora prima dal Regolamento (UE) N. 611/2013) è l’obbligo di notifica del data breach all’Autorità Garante entro il termine di 72 ore. Tale obbligo viene sancito al CAPO IV- Titolare del trattamento e responsabile del trattamento – Sezione 2- Sicurezza dei dati personali – articolo 33 ed è in capo al titolare del trattamento che:

“[omissis] notifica la violazione all’autorità di controllo competente a norma dell’articolo 55 senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne è venuto a conoscenza, a meno che sia improbabile che la violazione dei dati personali presenti un rischio per i diritti e le libertà delle persone fisiche. Qualora la notifica all’autorità di controllo non sia effettuata entro 72 ore, è corredata dei motivi del ritardo.”.

Il Gruppo di Lavoro Articolo 29, sempre nel documento “Linee guida sulla notifica delle violazioni dei dati personali ai sensi del regolamento (UE) 2016/679” chiarisce che:

“Il momento esatto in cui il titolare del trattamento può considerarsi “a conoscenza” di una particolare violazione dipenderà dalle circostanze della violazione. In alcuni casi sarà relativamente evidente fin dall’inizio che c’è stata una violazione, mentre in altri potrebbe occorrere del tempo per stabilire se i dati personali sono stati compromessi. Tuttavia, l’accento dovrebbe essere posto sulla tempestività dell’azione per indagare su un incidente per stabilire se i dati personali sono stati effettivamente violati e, in caso affermativo, prendere misure correttive ed effettuare la notifica, se necessario.”.

Questo è un ulteriore passaggio importante che verrà richiamato più avanti nel corso del presente articolo: nella gestione del personal data breach è necessario far precedere le eventuali azioni di notifica con l’analisi e la contestualizzazione dell’incidente occorso. Come vedremo, in seguito questo è uno degli step previsti nel processo che andremo ad illustrare.

Le comunicazioni previste dal GDPR non si esauriscono alla sola Autorità Garante ma si estendono anche agli interessati, ai sensi dell’art. 34 paragrafo 1:

“[omissis] Quando la violazione dei dati personali è suscettibile di presentare un rischio elevato per i diritti e le libertà delle persone fisiche [omissis]”.

Si tratta di un altro adempimento a carico del titolare del trattamento che agisce sempre in coordinamento con l’eventuale responsabile del trattamento.

L’obbligo di notifica di un personal data breach, dunque, potrebbe non esaurirsi con una comunicazione all’Autorità Garante ed agli interessati al trattamento. È infatti necessario far riferimento alle normative vigenti nel proprio settore di attività, che potrebbero indicare ulteriori incombenze di questo tipo a carico dei soggetti coinvolti nel trattamento di dati personali, e del titolare del trattamento in primis.

Solo per rimanere in ambito europeo si possono considerare, ad esempio, le seguenti normative:

• Regolamento (UE) n. 910/2014 in materia di identificazione elettronica e servizi fiduciari per le transazioni elettroniche nel mercato interno (regolamento eIDAS). L’articolo 19, paragrafo 2, del regolamento eIDAS fa obbligo ai prestatori di servizi fiduciari di comunicare all’organismo di vigilanza qualsiasi evento che comporti un impatto sul servizio offerto o sui relativi dati; qualora tali dati siano personali, il prestatore di servizi fiduciari deve comunicare anche all’Autorità Garante per la Protezione dei Dati Personali.
• Direttiva (UE) 2016/1148 recante misure per un livello comune elevato di sicurezza delle reti e dei sistemi informativi nell’Unione (direttiva NIS). Gli operatori di servizi essenziali ed i fornitori di servizi digitali sono obbligati a notificare gli incidenti di sicurezza alle rispettive autorità competenti ai sensi degli articoli 14 e 16. Tali incidenti possono interessare anche dati personali ed, in caso di compromissioni degli stessi, si rende necessaria una comunicazione all’Autorità Garante da parte degli stessi soggetti ai sensi del GDPR ed in maniera distinta rispetto a quanto previsto dalla direttiva NIS.
• Direttiva 2009/136/CE (direttiva sui diritti dei cittadini) e regolamento (UE) n. 611/2013 (regolamento sulla notifica delle violazioni). I fornitori di servizi di comunicazione elettronica accessibili al pubblico devono notificare le violazioni alle autorità nazionali competenti nel contesto della direttiva 2002/58/CE52.

I titolari sono ovviamente tenuti a considerare anche gli obblighi di notifica previsti dalle normative nazionali.

Misure di sicurezza per mitigare il rischio privacy

L’art. 33 del GDPR, al paragrafo (d) obbliga il titolare del trattamento dei dati personali a comunicare all’Autorità Garante:

“[omissis] le misure adottate o di cui si propone l’adozione da parte del titolare del trattamento per porre rimedio alla violazione dei dati personali e anche, se del caso, per attenuarne i possibili effetti negativi.”.

In questo articolo, come in tutto il GDPR, si richiama l’obbligo del titolare a mettere in atto tutte le misure tecniche e/o organizzative adeguate a mitigare il rischio di impatto sugli interessati (o meglio sui loro diritti e sulle libertà). Tali misure (che nelle normative ISO vengono denominate “Controlli”) sono essenzialmente presidi di sicurezza delle informazioni che vanno messi in atto sia in modo preventivo sia a seguito di un personal data breach.

L’effetto di queste misure deve essere costantemente misurato e monitorato ai fini della gestione del rischio privacy come ho avuto modo di illustrare in un mio precedente articolo citato in Bibliografia.

Il GDPR non indica specifiche misure di sicurezza da adottare, ma lascia al titolare del trattamento la scelta e le modalità di applicazione delle stesse secondo un approccio pragmatico, “tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, [omissis]” secondo quanto prescritto all’art. 32 paragrafo 1 – Sicurezza del trattamento.

L’importanza del Cybersecurity Framework

Prima di passare alla descrizione del processo di gestione di un personal data breach, si vuole fare menzione di uno dei pilastri alla base di tale processo: il Cybersecurity Framework.

Abbiamo già detto che il Gruppo di Lavoro Articolo 29 ha ricondotto il personal data breach ad un incidente di sicurezza con impatto sui dati personali oggetto di trattamento. Questa considerazione ci consente di ricorrere ai framework attualmente esistenti nella gestione degli incidenti di sicurezza quale base per la definizione di un efficace processo di gestione delle violazioni dei dati personali.

Come noto, il NIST ha messo a punto nel 2018 un Framework per il miglioramento della Cybersecurity delle infrastrutture critiche. Non si vuole qui descrivere tutto l’impianto proposto dal NIST, ma richiamare alcuni concetti che costituiscono la base per la definizione di un processo di gestione dei Personal data breach.

Il Framework NIST si pone l’obiettivo di integrare le attività di cybersecurity nell’ambito dei processi di business considerando i rischi della cyber security come parte integrante dei processi di risk management dell’organizzazione.

Il Framework NIST è stato ripreso dal “Framework Nazionale per la Cybersecurity e la Data Protection versione 2 Febbraio 2019” che, rifacendosi alla versione 1.1 del NIST, introduce anche aspetti relativi alla “corretta gestione dei dati personali, con specifico riferimento alla sicurezza degli stessi a fronte di possibili attacchi informatici”.

Nella fattispecie vengono indirizzati elementi relativi a:

• processi di data management, con particolare riferimento a quelli applicabili ai dati personali;
• modalità di trattamento dei dati personali;
• ruoli e responsabilità nella gestione dei dati personali;
• valutazione di impatto sulla protezione dei dati personali;
• modalità di documentazione e comunicazione a seguito di incidenti che si configurino come violazione dei dati personali.

Questi elementi non erano stati considerati nelle precedenti versioni del Framework e lo allineano di fatto ai principali standard in tema di protezione dei dati personali rendendolo applicabile anche in ambiti in cui le regolamentazioni generali, o quelle specifiche di settore, impongono adempimenti relativi al trattamento dei dati.

Il Framework Nazionale, così come quello del NIST, è composto da tre parti:

1. Framework Core – il core descrive il processo di gestione della cybersecurity considerando sia gli aspetti tecnici sia quelli organizzativi. Questo elemento riporta sia le fasi del processo di gestione (denominate “function”) sia le attività di dettaglio e le tecnologie (category e subcategory) facendo riferimento agli standard ed alle “best practice” in tema di gestione della sicurezza (ISO, SP800-53r4, COBIT-5, SANS20 e altri) ed alle regolamentazioni generali vigenti (Regolamento UE 2016/679 General Data Protection Regulation, Direttiva UE 2016/1148 NIS).
2. Profili – è l’allineamento di function, category e subcategory con i requisiti aziendali, la tolleranza al rischio e le risorse dell’organizzazione. Il profilo consente alle organizzazioni di stabilire una “tabella di marcia” per ridurre il rischio di cybersecurity che sia ben allineato con gli obiettivi organizzativi e settoriali, considera i requisiti legali/normativi e le migliori pratiche del settore e riflette le priorità di gestione del rischio.
3. Implementation Tier –forniscono una fotografia di come un’organizzazione gestisca il rischio di cybersecurity ed i relativi processi in atto. Dai livelli parziali (livello 1) a quelli adattivi (livello 4), i livelli descrivono un grado crescente di rigore nella gestione del rischio di sicurezza informatica. Aiutano a determinare in che misura la gestione del rischio di cybersecurity sia allineata alle esigenze aziendali e sia integrata nelle pratiche generali di gestione del rischio.

Ai fini della definizione del processo di gestione del personal data breach, ci interessa qui considerare le cinque function del “Core”. Si tratta delle cinque macro-attività o fasi che sono alla base del processo di gestione degli eventi di cybersecurity e del relativo rischio. Riportiamo di seguito la descrizione di queste fasi mutuandola dal Cybersecurity Framework Nazionale (paragrafo 2.1):

1. IDENTIFY – La function IDENTIFY è legata alla comprensione del contesto aziendale, degli asset che supportano i processi critici di business e dei relativi rischi associati. Tale comprensione permette a un’organizzazione di definire risorse e investimenti in linea con la strategia di gestione del rischio e con gli obiettivi aziendali. Le category all’interno di questa Function sono: Asset Management, Business Environment, Governance, Risk Assessment, Risk Management Strategy, Supply Chain Risk Management e Data Management.
2. PROTECT – La function PROTECT è associata all’implementazione di quelle misure volte alla protezione dei processi di business e degli asset aziendali, indipendentemente dalla loro natura informatica. Le category all’interno di questa function sono: Identity Management, Authentication and Access Control, Awareness and Training, Data Security, Information Protection Processes and Procedures, Maintenance, Protective Technology.
3. DETECT – La function DETECT è associata alla definizione e attuazione di attività appropriate per identificare tempestivamente incidenti di sicurezza informatica. Le category all’interno di questa function sono: Anomalies and Events, Security Continuous Monitoring, Detection Processes.
4. RESPOND – La function RESPOND è associata alla definizione e attuazione delle opportune attività per intervenire quando un incidente di sicurezza informatica sia stato rilevato. L’obiettivo è contenere l’impatto determinato da un potenziale incidente di sicurezza informatica. Le category all’interno di questa function sono: Response Planning, Communications, Analysis, Mitigation, Improvements.
5. RECOVER – La function RECOVER è associata alla definizione e attuazione delle attività per la gestione dei piani e delle attività per il ripristino dei processi e dei servizi impattati da un incidente. L’obiettivo è garantire la resilienza dei sistemi e delle infrastrutture e, in caso di incidente, supportare il recupero tempestivo delle business operations. Le category all’interno di questa function sono: Recovery Planning, Improvements, Communications.

Quanto illustrato finora, aiuta ad inquadrare il processo che viene di seguito proposto per la gestione dei Personal data breach. Tale processo è strutturato in fasi per le quali vengono descritte le attività, gli attori coinvolti ed i deliverable. Ciascuna fase è messa in relazione con le functions del Cybersecurity Framework appena descritto.

Creare un processo di gestione dei personal data breach

Il primo passo nella gestione degli incidenti di sicurezza è la consapevolezza che qualsiasi organizzazione possa subire nel tempo delle violazioni e che quindi debba predisporre degli adeguati presidi a salvaguardia delle proprie informazioni in termini di metodologia, processi e strumenti a supporto. Naturalmente il livello di presidio potrà essere di diversa entità in funzione delle dimensioni dell’organizzazione stessa.

Una risposta rapida, strutturata ed efficace ad un evento di sicurezza, in grado di minimizzare le conseguenze dell’evento stesso, dipende dalla misura in cui un’organizzazione intende investire nella gestione degli incidenti oltre che dalle dimensioni dell’organizzazione stessa, dalla tipologia delle informazioni trattate e dalle caratteristiche del trattamento.

Una corretta gestione delle violazioni di sicurezza non può prescindere, inoltre, dalla documentazione delle stesse violazioni nel momento in cui esse si presentano. È infatti una buona prassi (addirittura uno dei controlli dell’Annex A della normativa ISO/IEC 27001) oltre che un adempimento ai sensi dell’articolo 33 del GDPR.

In ogni caso i titolari del trattamento devono mettere in atto procedure e piani d’azione in risposta agli incidenti di sicurezza. Queste procedure possono essere di vario genere e dipendere sia dalle dimensioni e dalla struttura dell’organizzazione, sia dalla natura tecnica e/o organizzativa. Più in generale una efficace politica di gestione del patrimonio informativo e dei dati deve tenere in considerazione gli aspetti legati alla gestione degli incidenti di sicurezza, assegnando a tale ambito le corrette risorse ed i mezzi per l’implementazione.

Lo stesso dicasi per i responsabili del trattamento che non solo sono sottoposti agli stessi obblighi dei Titolari (ai sensi dell’art 32 del GDPR), ma devono anche trattare i dati secondo le istruzioni fornite dai Titolari stessi e sono tenuti alla segnalazione tempestiva delle violazioni di sicurezza oltre che alla collaborazione nella relativa soluzione (ai sensi dell’art. 33 paragrafo 2 del GDPR).

In definitiva, indipendentemente dalle dimensioni e dalla complessità delle organizzazioni, e che si tratti di titolari o responsabili del trattamento dei dati personali, è necessario stabilire chiaramente come procedere in caso di violazione della sicurezza, sia che la gestione degli incidenti sia svolta completamente all’interno dell’organizzazione sia che essa sia demandata a terzi che agiscono su indicazione del committente.

Lo schema che segue descrive in forma grafica come possa essere strutturato un processo di gestione dei personal data breach. Risulta evidente come le fasi del processo corrispondano in massima parte a quelle indicate nel “Core” del Cybersecurity Framework (NIST e/o Nazionale).

Tale schema, in particolare, è stato ripreso dal documento “Guide to Personal data breach Management and Notification” pubblicato a maggio 2018 dall’Autorità Garante Spagnola (AEPD) in collaborazione con l’Associazione per la Promozione della Sicurezza delle Informazioni (ISMS forum) ed il National Criptologic Center (NCC).

Blueprint Processo di Gestione dei Personal data breach

Come è già stato evidenziato, il processo proposto rappresenta una specializzazione del processo di gestione degli incidenti di sicurezza, del quale riprende finalità, struttura e modalità. Per questo motivo, dal punto di vista organizzativo, uno dei fattori di successo nella “messa a regime” è la collaborazione tra le funzioni del titolare preposte rispettivamente alla sicurezza (Security Manager o CISO) ed alla privacy (Privacy Manager e Chief Data Officer). Queste figure/funzioni devono a loro volta operare in stretto contatto con il DPO (Data Protection Officer).

In questo modo è possibile realizzare una adeguata politica di salvaguardia del patrimonio informativo aziendale e di quello specifico relativo alle informazioni personali nel rispetto dei vincoli normativi vigenti.

Passiamo ora ad analizzare le singole fasi del processo. Ciascuna fase sarà descritta nel dettaglio e messa in relazione con le Functions del Cybersecurity Framework che abbiamo esaminato in precedenza.

Processo di gestione dei personal data breach: fase di preparazione

Il primo step nel processo di gestione dei personal data breach è quello della preparazione. Corrisponde alla Function “Identify” del Cybersecurity Framework; è la fase in cui si definisce l’ambito di intervento contestualizzando il processo di gestione degli eventi di sicurezza.

In questa fase vengono identificati i processi di business critici sui quali focalizzare l’attenzione. Per ciascuno di essi vengono individuati gli asset ed identificati i criteri di valutazione del rischio, andando a definire anche le soglie di tolleranza al rischio stesso in funzione delle strategie aziendali.

Come già evidenziato nel corso del presente articolo, parte integrante del rischio aziendale è quello connesso agli spetti di cyber security e quindi anche quello relativo alla protezione dei dati personali, laddove le minacce individuate possano compromettere il patrimonio informativo aziendale ed i dati personali in particolare (valutazione del rischio privacy).

Quanto sopra esposto guida l’organizzazione nella definizione delle risorse e dei mezzi necessari ad una corretta gestione dei personal data breach, orientando, di conseguenza, la definizione del budget, i piani implementativi, lo staffing, i piani di formazione e di awareness.

Deve anche essere impostato tutto l’apparato di governance attraverso l’emanazione di policy interne a governo dei vari settori e funzioni coinvolte, e declinate a diversi livelli: strategico/direzionale (policy), di indirizzo (circolari, ordini di servizio) ed operativo (guide operative).

Volendo contestualizzare ulteriormente l’apparato di governance, a questo livello vengono definiti e descritti nel dettaglio anche i flussi di comunicazione a seguito di un personal data breach, i ruoli e le responsabilità di ciascuna funzione aziendale, gli eventuali comitati (di direzione ed operativi) gli strumenti a supporto, le modalità ed i tempi di notifica verso l’Autorità Garante e le altre entità istituzionali previste dagli obblighi di legge.

L’apparato di governance sarà tanto più articolato quanto più è strutturata l’organizzazione. Si pensi ad esempio ai gruppi imprenditoriali o alle società multinazionali, dove ciascun passaggio va stabilito e condiviso almeno a livello locale e con l’head quarter.

Ulteriore livello di complessità, in questi casi, può essere rappresentato da un personal data breach che coinvolga diverse aziende dello stesso gruppo imprenditoriale eventualmente anche collocate in distinti contesti nazionali.

Appare evidente, dagli esempi appena riportati, che un apparato di governance sia assolutamente indispensabile in queste situazioni, ma appare altrettanto evidente che tale apparato debba essere il più possibile snello e pragmatico per evitare di impattare sulle tempistiche di comunicazione che la normativa attuale richiede (GDPR in primis – si vedano a tal proposito gli articoli 33 e 34 del Regolamento).

Tale obiettivo si raggiunge principalmente definendo, proprio in fase di preparazione, criteri condivisi ed oggettivi basati su analisi del rischio e che consentano di assumere decisioni rapide (es. griglie di valutazione) e con pochi passaggi decisionali.

Appare evidente che questa fase sia di assoluta importanza per orientare una corretta gestione dei data breach e deve essere oggetto di revisione continua per consentire un costante allineamento alle linee strategiche dell’organizzazione.

Processo di gestione dei personal data breach: fase di rilevazione/identificazione

La fase di rilevazione/identificazione corrisponde alle Function “Protect” e “Detect” del Cybersecurity Framework.

Durante questa fase dovrebbero essere specificate le situazioni considerate incidenti di sicurezza, così come gli strumenti, i sistemi di rilevazione ed allarme che il titolare del trattamento dei dati (per sé e/o coordinandosi con il responsabile del trattamento) utilizzerà per rilevare un evento, classificarlo come incidente ed analizzare le informazioni fornite dagli strumenti stessi.

Il momento in cui viene rilevata e identificata una violazione dei dati personali è critico, poiché, come noto, il GDPR stabilisce che il responsabile del trattamento dei dati deve informare l’Autorità di controllo competente senza indebito ritardo e, se possibile, entro 72 ore dalla conoscenza dell’evento; in alcuni casi si dovrebbero anche informare gli interessati (ai sensi degli articoli 33 e 34 del GDPR).

Tuttavia, in questa fase potrebbero non essere note tutte le informazioni necessarie a classificare l’evento di sicurezza come personal data breach e potrebbe essere necessario spostare il conteggio delle 72 ore nella successiva fase di analisi e classificazione dell’incidente.

Gli incidenti di sicurezza possono essere identificati in modi diversi a seconda che ci si riferisca all’interno oppure all’eterno dell’organizzazione.

All’interno potranno essere utilizzati meccanismi di difesa e di rilevazione di eventi che possono compromettere la sicurezza (IT e fisica) quali ad esempio (e non a carattere esaustivo):

• politiche specifiche per la pulizia della scrivania, blocchi dello schermo, accesso tramite nome utente e password ecc.;
• controlli fisici come rilevamento di intrusi, videosorveglianza, controllo e monitoraggio degli accessi in aree particolari ecc.;
• controlli e procedure riguardanti danni ambientali o calamità naturali.

I metodi e gli strumenti di controllo possono essere più o meno automatizzati a seconda delle caratteristiche dell’organizzazione.

Possono quindi essere previsti metodi manuali (es. notifica da parte del personale previa adeguata formazione) nel caso di PMI oppure metodi automatici di diversa tipologia e complessità (dagli antivirus ai SIEM che correlano dati relativi ai log) nelle organizzazioni con dimensioni più consistenti.

È importante che la sicurezza sia analizzata a tutto tondo, evitando compartimentazioni tra IT e sicurezza fisica, dal momento che molto spesso gli eventi delle due nature sono correlati. Dunque, è fondamentale, in questa fase del processo, che anche a livello organizzativo ci sia una forte collaborazione tra tutte le funzioni che operano sui vari aspetti della sicurezza.

Si riporta di seguito un elenco (non esaustivo) di eventi che, rilevati in modo manuale o automatizzato, possono essere utili a segnalare il verificarsi di un incidente di sicurezza:

• notifiche dagli utenti: presenza di file con caratteri insoliti, ricezione di e-mail con allegati sospetti, comportamento strano nei dispositivi, incapacità di accedere a determinati servizi, perdita/furto di dispositivi di archiviazione o apparecchiature contenenti informazioni;
• avvisi generati da software antivirus;
• consumo eccessivo o imprevisto di memoria o unità in server e apparecchiature;
• anomalie del traffico di rete o picchi di traffico in orari insoliti;
• avvisi di sistema per rilevamento/prevenzione di intrusi (IDS/IPS);
• avvisi di sistema per la correlazione degli eventi;
• analisi delle registrazioni delle connessioni effettuate tramite proxy aziendali o connessioni bloccate dal firewall;
• analisi dei record di server e applicazioni con tentativi di accesso non autorizzati;
• analisi dei record degli strumenti DLP (Data Loss Prevention).

Nessun segnale, seppur apparentemente poco significativo, dovrebbe essere ignorato nemmeno eventuali annunci di soluzioni progettate per sfruttare ed attaccare vulnerabilità di sistema.

Ai segnali interni si affiancano spesso quelli rilevati da fonti esterne quali fornitori di servizi IT, clienti o enti pubblici quali organi di polizia (es. Polizia postale e delle comunicazioni).

Qualunque sia la fonte, una volta classificato l’evento come incidente di sicurezza, e personal data breach in particolare, è buona prassi mantenerne traccia in un archivio che ne riporti la tipologia, la gravità, lo stato e le misure adottate per la risoluzione.

Mantenere un simile archivio è importante sia dal punto di vista delle così dette “lessons learned”, cioè per disporre di una base informativa necessaria a rispondere velocemente ad eventuali situazioni ricorrenti, sia per avere una visione d’insieme che consenta, ad esempio, di mettere in correlazione uno o più eventi per identificare azioni strutturate di attacco.

Processo di gestione dei personal data breach: fase di analisi e classificazione

Le fasi che seguono (a partire da quella di analisi e classificazione) vanno a comporre il cosiddetto piano di azione cioè l’insieme delle attività di diversa natura (manageriali, tecniche, di comunicazione, di notifica a norma di legge) che concorrono alla gestione del personal data breach.

La predisposizione del piano di azione corrisponde alle Function “Respond” e “Recover” del Cybersecurity Framework.

L’analisi e la classificazione degli eventi di sicurezza può essere effettuata sulla base di diversi fattori quali:

• tipologia della minaccia: codice dannoso, intrusione, frode ecc.;
• origine della minaccia: interna o esterna;
• categoria di sicurezza dei sistemi e dei dati interessati (es. dati personali);
• profili degli utenti interessati;
• numero e classificazione dei sistemi interessati;
• impatto dell’incidente sull’organizzazione (es. danno di immagine) e sui diritti e le libertà degli interessati;
• requisiti legali e normativi;
• vettore o metodo di attacco: questo parametro è spesso il più utilizzato nella classificazione di un incidente (es. DoS/DDos Denial of Service, APT Advanced Persistent Threat, Defacement, utilizzo di account privilegiati, sfruttamento delle vulnerabilità applicative e/o di sistema, ingegneria sociale).

Qualora l’evento di sicurezza sia classificato come incidente, e siano compromessi dati personali, siamo in presenza di un personal data breach. La classificazione di un personal data breach viene effettuata sulla base di due parametri fondamentali (oltre a quelli che caratterizzano in generale un incidente di sicurezza): la tipologia di violazione ed il rischio di impatto sui diritti e sulle libertà degli interessati.

Per quanto riguarda la tipologia di violazione abbiamo già riportato in un precedente paragrafo del presente articolo la classificazione proposta dal Gruppo di Lavoro Articolo 29 in funzione dei consueti parametri di sicurezza delle informazioni: riservatezza, integrità e disponibilità (RID).

La sola classificazione sulla base dei parametri RID non è sufficiente, dal momento che è necessario effettuare una valutazione di impatto sugli interessati come richiesto dal GDPR per determinare la gravità dell’accaduto e soprattutto le conseguenze.

Si tratta di valutare il cosiddetto “rischio privacy” secondo la metodologia adottata dall’organizzazione. Di questo tema ho già trattato in un precedente articolo (citato in bibliografia) al quale rimando per maggiori dettagli. Riprendiamo qui solamente alcuni concetti espressi anche dal Gruppo di Lavoro Articolo 29 nelle “Linee guida sulla notifica delle violazioni dei dati personali ai sensi del regolamento (UE) 2016/679” in merito ai fattori da considerare nella valutazione del rischio. Tali fattori vengono di seguito indicati:

• tipo di violazione;
• natura, carattere sensibile (ex articolo 9 e 10 del GDPR) e volume dei dati coinvolti;
• facilità di identificazione delle persone fisiche;
• gravità delle conseguenze per le persone fisiche;
• caratteristiche particolari dell’interessato (es. minore, dipendente);
• numero di persone fisiche interessate;
• altri aspetti generali che contestualizzano l’impatto dovuto alla violazione.

Da ultimo, si vuole evidenziare che è questa la fase in cui solitamente il titolare non solo viene a conoscenza dell’accaduto ma ha gli elementi che gli consentono di classificare l’incidente come personal data breach valutandone impatti ed azioni di risposta.

È quindi lecito supporre, come anche indicato dal Gruppo di Lavoro Articolo 29 nello stesso documento sopra citato, che sia questo il momento dal quale far partire il termine delle 72 ore indicato dall’art 33 paragrafo 1 del GDPR.

Processo di gestione dei personali data breach: fase di risposta

La fase di risposta prevede una serie di attività che si pongono i seguenti obiettivi:

1. contenimento dell’incidente mediante azioni di recupero con effetto immediato;
2. recupero a regime delle funzionalità, dei servizi e dei dati compromessi (corrispondente alla Function di “Recover” del Cybersecurity Framework);
3. raccolta e memorizzazione strutturata degli elementi caratterizzanti l’evento e le azioni intraprese.

In questa fase è determinante la definizione di un team di risposta che avrà la responsabilità operativa di intervenire nel breve termine mettendo in atto le attività necessarie a contenere gli effetti dell’incidente di sicurezza. Allo stesso team è poi demandato lo studio per l’eliminazione delle cause che hanno determinato l’incidente.

Il team di risposta è spesso composto da tecnici IT e di Sicurezza (IT e fisica); in alcuni casi possono essere coinvolti rappresentanti di altre funzioni di business a seconda della struttura organizzativa, per identificare le migliori azioni da mettere in atto per il ripristino dei prodotti/servizi minimizzando gli impatti sulla clientela.

Il contenimento dell’incidente consente di mettere in atto azioni immediate e tempestive nell’attesa di sviluppare una strategia risolutiva. Tali azioni possono essere di varia natura (es. spegnere un sistema, isolarlo dalla rete, disattivare specifiche funzioni ecc.) e sono tanto più efficaci quanto più sono già codificate all’interno dell’organizzazione.

La definizione di procedure operative connesse alle principali e più consuete tipologie di incidente può consentire già all’utente l’attuazione di misure di contenimento; altre situazioni più complesse richiedono l’intervento di tecnici che, in presenza di procedure operative, possono operare secondo protocolli definiti evitando tempi di “ricerca” delle migliori azioni attuabili.

Le misure di contenimento possono anche essere organizzate ed attuate in modo progressivo, in funzione delle caratteristiche dell’evento di sicurezza che si presenta.

Una volta risolta la violazione dei dati personali e verificata l’efficacia delle misure adottate, inizia la fase di recupero. L’obiettivo della fase di recupero è ripristinare completamente i servizi ai loro livelli normali ed evitare, per quanto possibile, eventuali nuovi incidenti che si possano verificare per la stessa causa.

A questo fine sarà necessario non soltanto intraprendere ulteriori azioni operative ed implementative ma anche mettere in atto dei controlli su base regolare che consentano un efficace monitoraggio dei processi ad alto rischio.

Quanto sopra si realizza attraverso quattro principali attività:

1. identificazione delle possibili soluzioni da mettere in atto (a breve, medio e/o lungo termine) associando a ciascuna di esse un valore di adeguatezza in termini di efficacia nel contenimento del rischio futuro ed un’indicazione di costo implementativo e di manutenzione;
2. definizione della strategia che l’organizzazione vuole perseguire effettuando un bilanciamento tra impatti determinati dall’evento di sicurezza, costi delle soluzioni proposte e tolleranza al rischio, ossia percentuale di rischio che l’organizzazione è disposta ad accettare;
3. implementazione della strategia definita ed avvio dei progetti implementativi (o delle azioni di manutenzione) necessari a risolvere la situazione a regime. Le misure temporanee di contenimento potranno essere mantenute (se parte integrante della strategia finale) oppure dismesse progressivamente;
4. verifica del ripristino ed attuazione delle misure di controllo. Questa attività ha l’obiettivo di confermare l’effettivo ripristino dei prodotti/servizi/funzioni/dati impattati, di rivalutare il livello di esposizione dell’organizzazione alla luce di quanto implementato e la messa in opera di un piano di controlli volti a mantenere un costante monitoraggio della situazione.

Da ultimo, la documentazione strutturata di quanto avvenuto (incidente, azioni di contenimento, strategia, controlli) consente sia di fornire un quadro organico e completo al Top Manangement aziendale, sia di mantenere un patrimonio informativo utile in fase di Preparazione e nelle successive fasi operative (per estrarre le “Lessons Learned” evitando di ripercorrere in futuro attività già effettuate).

Di seguito un elenco (anch’esso non esaustivo) delle principali informazioni che dovrebbero essere incluse nel rapporto finale:

• descrizione obiettiva dell’incidente;
• controlli esistenti al momento dell’incidente;
• elenco delle misure di risposta efficaci;
• ripetibilità dell’incidente in circostanze simili;
• metodi di rilevazione utilizzati;
• composizione team di governance e di risposta e comunicazioni intervenute.

Processo di gestione dei personali data breach: fase di notifica

La fase di notifica è parte integrante del piano d’azione e rappresenta un momento importante al pari delle azioni di contenimento e recupero dell’incidente. Dell’obbligo di notifica da parte del titolare del trattamento abbiamo già ampiamente trattato nel corso del presente articolo. Si vuole tuttavia richiamare quanto prescritto dagli artt. 33 e 34 del GDPR e cioè che, indipendentemente da eventuali notifiche interne che devono essere inviate durante la gestione di un incidente di sicurezza (secondo l’apparato di governance predisposto in fase di preparazione), il GDPR stabilisce che, in caso di violazione della sicurezza dei dati personali, il titolare del trattamento dei dati debba informare l’Autorità di controllo competente senza indebito ritardo e, ove possibile, entro 72 ore dall’intervenuta conoscenza della violazione, a meno che non sia improbabile che la violazione della sicurezza possa rappresentare un rischio per i diritti e le libertà fondamentali delle persone.

In aggiunta, nelle condizioni identificate dall’art. 34, il Titolare è tenuto alla comunicazione anche agli Interessati al trattamento.

A questa incombenza si aggiungono anche tutti gli altri obblighi derivanti da normative Europee o locali che afferiscono all’ambito di attività dell’organizzazione (si rimanda alla sezione “Obbligo di Notifica” del presente articolo per un maggiore dettaglio).

Nel caso di organizzazioni complesse e di dimensioni rilevanti (es. gruppi imprenditoriali, multinazionali) è cruciale che anche l’attività di notifica interna ed esterna sia normata attraverso policy che stabiliscano ruoli, funzioni coinvolte, modalità e tempistiche. Ciò per evitare incertezze e sovrapposizioni anche alla luce degli stringenti tempi di comunicazione posti dalla normativa vigente.

Processo di gestione dei personali data breach: fase di monitoraggio e chiusura

La fase di monitoraggio e chiusura rappresenta l’ultimo atto del processo di gestione del personal data breach. In questa fase vanno identificate eventuali azioni che fanno sempre parte del piano d’azione anche se non direttamente correlate al contenimento ed al ripristino.

Si tratta, ad esempio, di azioni di natura legale (procedimenti) oppure di azioni di comunicazione verso gli organi di stampa, qualora ci possano essere ripercussioni sulla reputazione e/o sull’immagine del soggetto coinvolto.

Allo stesso tempo vanno messe in atto azioni di monitoraggio periodico per valutare l’efficacia nel tempo dei controlli identificati e soprattutto tenere sotto costante controllo il livello di rischio, valutando l’allineamento rispetto alla tolleranza della propria organizzazione.

Una volta completate le azioni previste dal piano d’azione ed impostato il monitoraggio, è possibile procedere alla chiusura della violazione dei dati personali (personal data breach). Il monitoraggio può essere impostato su livelli successivi (operativo e di controllo) coinvolgendo in questa fase anche il Data Protection Officer (DPO), al quale il titolare potrà anche demandare l’invio di una notifica finale all’Autorità Garante a seguito della chiusura del personal data breach.

Si raccomanda di chiudere il personal data breach con un rapporto che ripercorra le attività effettuate secondo il processo indicato. Tale rapporto ha particolare valenza anche ai fini del principio di accountability.

Conclusioni

Nel presente articolo abbiamo analizzato quali siano le implicazioni derivanti dal verificarsi di un personal data breach e come questo evento sia da classificarsi tra gli incidenti di sicurezza.

Sulla base di tali considerazioni è stato proposto un processo per la gestione dei personal data breach derivato dal Cybersecurity Framework NIST che fornisce le indicazioni per strutturare processi, strumenti ed organizzazione a supporto della cyber security.

Nel descrivere tale processo sono stati presi in considerazioni non soltanto i requisiti del GDPR ma anche le indicazioni fornite dal Gruppo di Lavoro Articolo 29 (già EDPB – European Data Protection Board) in tema di Data breach e le best practice raccolte e pubblicate dall’Autority Spagnola (AEPD).

Le indicazioni fornite possono essere adattate a qualsiasi organizzazione indipendentemente dalle dimensioni e dal settore di intervento. Ovviamente il grado di strutturazione delle singole fasi di processo potrà essere più o meno sofisticato, in funzione delle caratteristiche organizzative di ciascuna entità.

Bibliografia

1. Data breach Response: A Guide for Business – Federal Trade Commission – Maggio 2019.
2. DIRETTIVA (UE) 2016/1148 DEL PARLAMENTO EUROPEO E DEL CONSIGLIO del 6 luglio 2016 recante misure per un livello comune elevato di sicurezza delle reti e dei sistemi informativi nell’Unione.
3. DIRETTIVA 2008/114/CE DEL CONSIGLIO dell’8 dicembre 2008 relativa all’individuazione e alla designazione delle infrastrutture critiche europee e alla valutazione della necessità di migliorarne la protezione (Testo rilevante ai fini del SEE).
4. DIRETTIVA 2009/136/CE DEL PARLAMENTO EUROPEO E DEL CONSIGLIO del 25 novembre 2009 recante modifica della direttiva 2002/22/CE relativa al servizio universale e ai diritti degli utenti in materia di reti e di servizi di comunicazione elettronica, della direttiva 2002/58/CE relativa al trattamento dei dati personali e alla tutela della vita privata nel settore delle comunicazioni elettroniche e del regolamento (CE) n.  2006/2004 sulla cooperazione tra le autorità nazionali responsabili dell’esecuzione della normativa a tutela dei consumatori (Testo rilevante ai fini del SEE).
5. Framework for Improving Critical Infrastructure Cybersecurity versione 1.1 – NIST National Institute of Standards and Technology – 16 aprile 2018.
6. Framework Nazionale per la Cybersecurity e la Data Protection – Cyber Intelligence and Information Security Center Università La Sapienza Roma e CINI Cybersecurity National LAB – Febbraio 2019
7. Guide on Personal data breach Management and Notification – AEPD Agencia Española de Proteción de Datos, ISMS Forum Spain in collaborazione con CCN Centro Criprologico National e INCIBE Istituto Nacional de Ciberseguridad – Maggio 2018.
8. ISO/IEC 27701:2019 – Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management — Requirements and guidelines.
9. Linee guida sulla notifica delle violazioni dei dati personali ai sensi del regolamento (UE) 2016/679 – Versione emendata e adottata in data 6 febbraio 2018 – GRUPPO DI LAVORO ARTICOLO 29 PER LA PROTEZIONE DEI DATI.
10. Parere 03/2014 sulla notifica delle violazioni dei dati personali adottato il 25 marzo 2014 – GRUPPO DI LAVORO ARTICOLO 29 PER LA PROTEZIONE DEI DATI
11. REGOLAMENTO (UE) 2016/679 DEL PARLAMENTO EUROPEO E DEL CONSIGLIO del 27 aprile 2016 relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (regolamento generale sulla protezione dei dati) (Testo rilevante ai fini del SEE)
12. REGOLAMENTO (UE) N. 611/2013 DELLA COMMISSIONE del 24 giugno 2013 sulle misure applicabili alla notifica delle violazioni di dati personali a norma della direttiva 2002/58/CE del Parlamento europeo e del Consiglio relativa alla vita privata e alle comunicazioni elettroniche.
13. REGOLAMENTO (UE) N. 910/2014 DEL PARLAMENTO EUROPEO E DEL CONSIGLIO del 23 luglio 2014 in materia di identificazione elettronica e servizi fiduciari per le transazioni elettroniche nel mercato interno e che abroga la direttiva 1999/93/CE.
14. UNI CEI EN ISO/IEC 27001:2017 – Information technology – Security techniques – Information security management systems – Requirements
15. Valutazione del rischio e accountability: come “mettere a terra” gli adempimenti del GDPR – Marco Toiati – Agenda Digitale – Luglio 2019.