Privacy by design e GDPR, soluzioni per proteggere i dati in azienda

Il Regolamento Generale sulla Protezione dei Dati (Regolamento UE 679/2016, noto anche come GDPR) ha introdotto con l’articolo 25 l’obbligatorietà per tutte le organizzazioni di applicare il principio di protezione dei dati fin dalla progettazione (dall’inglese data protection by design). Un principio, sintetizzato come privacy by design, completamente nuovo per le aziende italiane, ma non in linea generale in quanto enunciato per la prima volta nel 1996 da Ann Cavoukian (allora membro dell’Information and Privacy Commissioner of Ontario, Canada) e poi ripreso nella 32^° Conferenza Internazionale dei Data Protection and Privacy Commissioners/Authorities tenutasi nel 2010 a Gerusalemme.

Proteggere i dati personali: cosa dice la normativa

Avendo ben oltre 20 anni di storia alle spalle, il principio di privacy by design dovrebbe essere facile da applicare, ma nella realtà quotidiana purtroppo non è così! La normativa, infatti, non fornisce indicazioni pratiche su che cosa bisogna fare come faceva l’allegato B del D.lgs. 196/2003.

L’articolo 25 del GDPR è estremamente sintetico essendo composto da soli tre capoversi. Al primo capoverso parla del principio della privacy by design, nel secondo della privacy by default e nel terzo di un possibile meccanismo di certificazione per questi due aspetti. Non è nelle poche righe dell’articolo, quindi, che si può avere un’indicazione pratica di cosa bisogna effettivamente fare per applicare il principio di privacy by design: occorre cercare in altri punti della norma.

Purtroppo, però, il GDPR e le altre direttive e regolamenti connessi, nonché le diverse opinion del Working Party 29 (attualmente evoluto nell’European Data Protection Board) non sono sempre di semplice lettura. Il GDPR, però, ci indirizza abbastanza bene su che cosa deve essere la privacy by design.

Il primo comma dell’articolo 25 del GDPR dice: “Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento, come anche dei rischi aventi probabilità e gravità diverse per i diritti e le libertà delle persone fisiche costituiti dal trattamento, sia al momento di determinare i mezzi del trattamento sia all’atto del trattamento stesso il titolare del trattamento mette in atto misure tecniche e organizzative adeguate, quali la pseudonimizzazione, volte ad attuare in modo efficace i principi di protezione dei dati, quali la minimizzazione, e a integrare nel trattamento le necessarie garanzie al fine di soddisfare i requisiti del presente regolamento e tutelare i diritti degli interessati”.

I punti chiave per la privacy by design

La richiesta del comma 1 dell’articolo 25 può essere sintetizzata in cinque punti importanti che sono:

1. tenere conto dello stato dell’arte;
2. tenere conto dei costi di attuazione;
3. mettere in atto misure tecniche adeguate;
4. mettere in atto misure organizzative adeguate;
5. attuare in modo efficace i principi di protezione dei dati.

Quindi la normativa chiede, di fatto, di soddisfare questi cinque punti chiave e, se applicati in modo adeguato, si è messo in atto correttamente il principio di privacy by design. Andiamo ad analizzarli nel dettaglio in modo da comprendere che cosa serve effettivamente fare.

Privacy by design significa misure di sicurezza aggiornate

Partiamo analizzando i primi due aspetti: stato dell’arte e costi di attuazione. Stiamo parlando di misure di sicurezza, ma bisogna comprende qual è lo stato dell’arte delle misure di sicurezza. Quello che possiamo considerare stato dell’arte oggi e che quindi rispetterebbe la normativa, non lo è domani. Questo punto porta dietro di sé un aspetto estremamente importante del principio di privacy by design: lo stato dell’arte non è un concetto statico ma evolve con il tempo, è dinamico. Questo punto ha anche un rovescio della medaglia importante e, soprattutto, positivo: misure di sicurezza che ieri non erano accessibile (ad esempio perché troppo costose o di solo dominio militare) oggi potrebbero esserle e potremmo quindi adottarle per proteggere i dati personali.

Da questo si può dedurre un aspetto importante: la corretta implementazione del principio di privacy by Design deve avere due componenti: una valida al momento di progettazione del trattamento o del sistema, o insieme di sistemi, che lo supporta; una seconda componente valida invece nel corso della vita del trattamento stesso. Stiamo parlando quindi presumibilmente di almeno due processi: uno che segue la progettazione e uno (o più di uno) che seguono l’esercizio del sistema sia con un’anima reattiva che proattiva di adeguamento allo stato dell’arte.

Uno schema esemplificativo del processo di adeguamento dinamico delle misure di sicurezza per il rispetto del principio di privacy by design.

Per quanto riguarda il secondo aspetto chiave necessario per soddisfare le richieste dell’art. 25 del GDPR (costi di attuazione), c’è da dire subito che è strettamente correlato al primo (stato dell’arte). Le organizzazioni non sono tutte uguali e non tutte hanno le stesse capacità di acquisto. Pensiamo ad esempio a due comuni, il primo molto grande e sopra al milione di abitanti e l’altro più piccolo dell’ordine di qualche decina di migliaia di abitanti. Se guardiamo la tipologia di dati personali che questi trattano sono esattamente gli stessi essendo entrambi due comuni e quindi con gli stessi trattamenti o comunque con trattamenti molto simili fra di loro; quello che cambia è prevalentemente la quantità di dati personali trattati. La capacità di acquisto che hanno queste due organizzazioni è molto differente fra di loro, quindi la valutazione dei costi di attuazione di alcune misure di sicurezza potrebbe dare esito positivo per il comune di grandi dimensioni ed esito negativo per quello di piccole dimensioni. Questa differenza certo può essere attenuata, almeno in parte, attraverso le convenzioni stipulate a livello nazionale per le organizzazioni pubbliche. Diventa probabilmente più evidente se si confronta una grossa realtà con alto budget per la sicurezza (ad esempio, il settore militare o dei servizi di sicurezza nazionali) e realtà di altro tipo quali ad esempio un ospedale.

Principi di protezione dei dati personali

Prima di analizzare le metodologie necessarie per mettere in atto le misure tecniche e organizzative richieste dall’art. 25 del GDPR, è opportuno soffermarci su cosa intende la normativa per “principi di protezione dei dati personali”. L’articolo 5 del GDPR parla di “Principi applicabili al trattamento dei dati personali”. Al punto 1.f l’articolo dice testualmente:

<omissis> trattati in maniera da garantire un’adeguata sicurezza dei dati personali, compresa la protezione, mediante misure tecniche e organizzative adeguate, da trattamenti non autorizzati o illeciti e dalla perdita, dalla distruzione o dal danno accidentali («integrità e riservatezza») <omissis>

L’articolo 32 parla più esplicitamente di sicurezza del trattamento:

<omissis> il titolare del trattamento e il responsabile del trattamento mettono in atto misure tecniche e organizzative adeguate a garantire un livello di sicurezza adeguato al rischio <omissis>

Sempre l’articolo 32 elenca alcuni altri aspetti importanti, infatti indica che le misure di sicurezza tecniche ed organizzative comprendono:

1. la pseudonimizzazione e la cifratura dei dati personali;
2. la capacità di assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento;
3. la capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico;
4. una procedura per testare, verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento.

Il paragrafo d conferma il fatto che, per la normativa, la protezione dei dati personali non si ferma con la fase di progettazione ma continua per tutto il ciclo di vita del trattamento e dei relativi sistemi che lo supportano. I paragrafi b e c indicano che gli aspetti che devono essere protetti sono quattro: la riservatezza, l’integrità, la disponibilità e la resilienza. La protezione del RID (Riservatezza, Integrità e Disponibilità) è la stessa che viene richiesta dalla sicurezza delle informazioni e dai principi di base della cyber security, quindi almeno alcune misure di sicurezza possono essere di tipo trasversale all’organizzazione e non solo limitate alla protezione dei dati personali.

Misure tecniche e organizzative: quali sono e come adottarle

Le misure tecniche ed organizzative che l’organizzazione deve andare a mettere in atto sono finalizzate ad andare a proteggere la riservatezza, l’integrità, la disponibilità e la resilienza del dato personale. Vediamo ora alcuni esempi di possibili misure di sicurezza che è possibile adottare.

Un approccio pratico alla privacy by design in azienda

Come abbiamo introdotto precedentemente ci sono due macro ambiti in cui è necessario applicare il principio di privacy by design: nella fase di progettazione del trattamento e nella fase di esercizio.

Privacy by design nella fase di progettazione del trattamento

Esistono all’interno dell’organizzazione una serie di misure di sicurezza di tipo generale che sono trasversali a tutti gli ambiti e che, se adottate, sono applicate indipendentemente dalla tipologia di dati che sono gestiti all’interno di quel processo o trattamento aziendale o nei relativi sistemi e applicazioni. Esempi di queste tipologie di misure di sicurezza “di base” possono essere:

• politica per l’utilizzo dei sistemi informativi aziendali;
• assegnazione di ruoli e responsabilità;
• sistema antincendio;
• controllo degli accessi fisici all’edificio;
• protezione anti intrusione dell’ufficio (porte, finestre, ecc.);
• allarme anti intrusione;
• vigilanza;
• videosorveglianza;
• utilizzo di badge;
• sicurezza perimetrale della rete aziendale;
• separazione fra le reti;
• sistema antivirus/antimalware;
• sistema antispam;
• formazione;
• monitoring dei sistemi;
• access management;
• patching management;
• disponibilità di armadi e cassettiere;
• hardening dei sistemi

Esiste quindi un battente di sicurezza basilare che l’organizzazione garantisce indipendentemente dalla tipologia di dati gestiti dai processi e dai trattamenti. Diciamo che un po’ di sicurezza non la si nega a nessuno.

Cosa succede quando l’organizzazione valuta di effettuare un nuovo trattamento di dati (1)? Come prima cosa si dovrà valutare se questo nuovo processo o trattamento gestirà dati personali (2). Se gestisce dati personali allora rientra nell’ambito della protezione dei dati personali e quindi bisogna andare a valutare se questo nuovo trattamento potenzialmente presenta un rischio elevato per i cittadini secondo l’opinion 248 del WP29 (3). Ma cosa significa che presenta un alto rischio per i cittadini? Relativamente a questo punto, molti ironizzano sul fatto che per sapere se è necessario effettuare un Data Protection Impact Assessment (DPIA) andrebbe effettuata una DPIA: quindi di fatto questa andrebbe svolta sempre. Questo è un approccio fattibile in quanto i nuovi trattamenti non sono all’ordine del giorno all’interno di un’organizzazione.

Comunque sia, un possibile approccio a questo primo step di valutazione di alto rischio per i cittadini è quello di andare valutare se le misure di sicurezza di base sono reputate sufficienti per proteggere i dati personali gestiti all’interno del trattamento. Ad esempio, in un trattamento di tipo amministrativo dei fornitori sono trattati solo dati personali quali il nome del contatto presso il fornitore ed i suoi riferimenti aziendali: per un trattamento di questo tipo potrebbero essere sufficienti le misure di sicurezza di base dell’organizzazione. L’effettuazione della DPIA (4) mira a identificare più in dettaglio il rischio per gli interessati e quali misure di sicurezza (oltre a quelle di base comunque presenti) dovrebbero essere messe specificatamente per questo trattamento per attenuare il rischio sugli interessati. Successivamente a questa valutazione di misure di sicurezza aggiuntive per attenuare il rischio sugli interessati l’organizzazione dovrebbe (qui si utilizza volutamente il condizionale in quanto non è un obbligo di legge) valutare il rischio sull’organizzazione stessa (5) andando ad identificare delle eventuali misure di sicurezza aggiuntive per l’organizzazione. Dopo l’OK alla messa in esercizio del nuovo trattamento si passa alla fase di sviluppo vero e proprio (6) che dovrà tradurre in funzionalità i requisiti funzionali espressi per il trattamento e per i sistemi così come dovrà rendere effettive le misure di sicurezza aggiuntive rispetto a quelle di base provenienti sia dalla DPIA che dall’analisi dei rischi dell’organizzazione. Prima del go-live della piattaforma (8) dovranno essere verificate sia la correttezza delle funzionalità sviluppate che quella delle misure di sicurezza (7).

La privacy by design in fase di sviluppo di un nuovo trattamento può essere sintetizzata in questi otto passi.

Privacy by design nella fase di esercizio del trattamento

Ci sono alcune certezze relativamente alla sicurezza:

• la sicurezza al 100% non esiste: ci sono diversi casi celebri di “campioni” sulla sicurezza che sono stati violati;
• le misure di sicurezza “invecchiano”: basti pensare alle chiavi di cifratura, qualche anno fa si lavorava a 128 bit oggi il “minimo sindacale” è 1024.

Alcune delle misure di sicurezza di base elencate prima (ad esempio: antivirus, antispam, patch management ecc.) sono delle misure tecniche che tendono a mantenere “aggiornato” il livello di sicurezza dei sistemi. Come introdotto in precedenza, la privacy by design nella fase di esercizio ha due anime: la prima reattiva che solitamente parte da eventi, incidenti di sicurezza e data breach avvenuti nell’organizzazione che devono essere gestiti e risolti, mentre la seconda è proattiva.

Eventi e incidenti di sicurezza sono la quotidianità all’interno delle organizzazioni, mentre i data breach che necessitano una comunicazione al Garante della Protezione dei Dati Personali si spera non siano così frequenti anche se è innegabile che accadano. Incidenti di sicurezza e data breach possono avvenire sia a seguito di misure di sicurezza non adeguate sia per misure di sicurezza obsolete. Misure di sicurezza non adeguate può voler dire sia che per garantire il rispetto del principio di privacy by design nella fase di progettazione non si è lavorato in modo corretto sia che la necessità di misure di sicurezza non era prevedibile o che queste non erano disponibili o accessibili in quel momento. A prescindere dalla motivazione bisogna rispondere all’incidente di sicurezza e al data breach andando a gestire, contrastare e valutare l’evento fino a prendere la decisione della comunicazione al Garante. Gestito e contrastato il data breach, bisogna analizzarlo e far si che non si ripeta: ad esempio applicando un semplice aggiornamento oppure realizzando un nuovo progetto più complesso (ad esempio sostituendo l’algoritmo di cifratura rilevatosi debole). Quest’anima reattiva è ben illustrata da ITIL (Information Technology Infrastructure Library: è un insieme di linee guida nella gestione dei servizi IT) nei processi di “Incident Management” e “Problem Management” del Service Operation e, per gli incidenti di sicurezza, nelle “ISO/IEC 27035-part 1, 2 e 3 Information security incident management” e “ISO/IEC 27043 Incident investigation principles and processes”.

La parte reattiva è semplice: succede qualche cosa, capisco cosa non va e la risolvo. Nella risoluzione è importante ricordarsi di risolvere nell’ambito dove è successo l’evento ma anche dove non è successo ma potrebbe succedere. Ad esempio, se il problema è un algoritmo di cifratura debole e se questo è adottato anche da altre parti, il progetto di aggiornamento dovrà necessariamente comprendere tutti gli ambiti dove quell’algoritmo di cifratura oggi è adottato.

Questo ragionamento ha già introdotto un primo aspetto di proattività, il capire se la vulnerabilità è presente anche da altre parti e, se si, risolverla anche li. Il Problem Management di ITIL parla di un’anima proattiva di identificazione di potenziali problemi prima che questi accadano. Nell’ambito della gestione sistemistica questo è molto complicato immaginarselo ma nella sicurezza molto meno: esistono delle attività di verifica che possono essere fatte come gli audit di sicurezza, i vulnerability assessment, i penetration test, le simulazioni di attacchi phishing, stress-test e le simulazioni di attacchi social engineering. Sono tutte attività proattive, cioè non svolte a seguito di eventi specifici che mirano a comprendere se ci sono delle vulnerabilità nei trattamenti o nei sistemi che potenzialmente potrebbero essere sfruttate da un malintenzionato o che potrebbero causare violazioni intenzionali o non intenzionali della riservatezza, dell’integrità o della disponibilità dei dati personali. Lo svolgimento regolare e coordinato di un opportuno mix di queste attività può permettere proattivamente di mantenere aggiornate ed allo stato dell’arte le misure di sicurezza a protezione dei dati personali.

Privacy by design e security by design: un approccio integrato

In sintesi, quindi, possiamo concludere che il senso del principio di privacy by design è che la protezione dei dati personali non è un optional dei trattamenti e dei sistemi che li supportano ma ne è parte integrante. Inoltre, la protezione dei dati personali deve nascere insieme al trattamento ed ai sistemi e non è un add-on che si aggiunge in un secondo momento. Per fare un paragone, è come se noi volessimo rendere “sicura” una vecchia automobile andando ad aggiungerci sopra i dispositivi di sicurezza moderni (airbag, scocca deformabile, ABS ecc.). Possiamo sicuramente farlo, però queste misure di sicurezza perderanno di efficienza rispetto a quelle paritetiche delle auto moderne. Inoltre, i costi di adattamento della vecchia macchina alle nuove misure di sicurezza saranno alti e bisogna comunque tener conto del fatto che non tutte le misure di sicurezza potranno essere adottate (rimanendo sull’esempio della vecchia automobile, sarebbe impensabile adottare una scocca deformabile).

Quello che si è proposto in questa sede è un approccio integrato fra data protection by design e security by design che permette di andare ad ottimizzare le, spesso poche, risorse economiche a disposizione delle organizzazioni. L’approccio è “a mattoncini” che aggiungono misure di sicurezza dove servono completate da un approccio reattivo e proattivo per il mantenimento allo stato dell’arte delle misure di sicurezza così come richiesto dall’articolo 25 del GDPR.