Di Log in Log: un garante è per sempre

Visto che monta la discussione su metadati e posta credo che occorra fare un minimo di chiarezza su alcune cose.

Lo so in parte ho già scritto in merito, ma:

semel in anno licet ribadire 🤣

insomma piu o meno

Vi ricordo che tutto parte dalle indicazioni garantite dal garante di cui parlo qui sotto:

Garante & email: se 7 giorni vi sembran pochi

in cui è solita la crisi sul:

ma allora i metadati?
e l’altra metà dei dati?

I legal e DPO

Insomma la favola dei 7+2 che sta appassionando l’etere.

La questione sarebbe semplice se si sapesse di cosa si parla, ma visto le evoluzioni correnti, dubbi, imprecazioni e salamelecchi vari occorre seguire la cosa con un pochino più di attenzione.

Ora mi balza all’occhio un altra nota del garante su un provvedimento contro un sito di incontri:

https://gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/9983384#2

in questo provvedimento sembrerebbe che il garante chieda esattamente l’opposto di quanto espresso per le email.

Si legge infatti:

Insomma come a dire che i log non li devi tenere ma li devi tenere, ed oltretutto inalterabili, per non tracciare ma tracciare quello che fanno i dipendenti.

Ed oltretutto tracciare anche l’accesso ai Log stessi e medesimi.

Operazione illegittima di modifica dei Log 😂

Altro che monitoraggio delle attività del lavoratore 🤣

Ora il fatto che si tratti di un provvedimento verso un sito che vive di incontri da tenere segreti non credo sia il punto dirimente.

(e comunque lo so con che account vi siete registrati 😂)

l’acaro

Il punto dirimente è che la giustificazione delle motivazioni di ritenzione di log e metadati è, paradossalmente, data dal garante stesso quando fa queste richieste.

Occorre infatti ripetere, repetita iuvant sed secant, che le indicazioni del garante (che in quanto indicazioni NON sono un obbligo) in merito ai metadati della posta elettronica facevano riferimento ad un aspetto specifico inerente lo statuto dei lavoratori

Per quello che concerne il GDPR già l’articolo 32 darebbe ampia giustificazione alla retention di metadati e log nelle esigenze di sicurezza e ripristino:

Art 32: “Sicurezza del trattamento”

1. 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, il titolare del trattamento e il responsabile del trattamento mettono in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio, che comprendono, tra le altre, se del caso:
   => Articolo: 24
   a) la pseudonimizzazione e la cifratura dei dati personali;
   => Articolo: 4
   b) la capacità di assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento;
   c) la capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico;
   d) una procedura per testare, verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento.

E tali richieste sono rimarcate nella esigenza di avere un controllo puntuale dei dati e di chi vi accede.

Ma, per tornare al punto della posta, tali richieste coincidono sia con il doversi tenere i metadati

/che ricordo sono in gran parte, parte integrante del messaggio di posta /

che di gestire con precisione ed efficacia il tracciamento di chi a questi dati accede.

In altre parole, a meno di non voler limitare a 7+2 giorni, le caselle di posta elettronica la risposta alle indicazione del garante è, mi sento di poter affermare con confidenza:

Teneteli questi dati se servono alla sicurezza e mantenimento del sistema (ex Art. 32 GDPR), dati che si trovano NON solo nei log delle soluzioni ma condivisi anche e sopratutto per motivi di sicurezza (pensate anche ai SIEM magari)

Ma, come dovreste comunque fare, giustificate il tutto in maniera sensata.

PS: e ricordatevi del DLP già che ci siete.

Salute

Garante & email: se 7 giorni vi sembran pochi

Non ce la posso farcela!

Ho appena finito di “elogiare” l’AGICOM per l’ennesima implementazione a mentula canis del “piracy shield de no artri”, che mi trovo a dover confrontarmi con la ennesima trovata italica, questa volta del GPDP.

Provvedimento del 21 dicembre 2023 – Documento di indirizzo “Programmi e servizi informatici di gestione della posta elettronica nel contesto lavorativo e trattamento dei metadati” [9978728]

Intendiamoci io capisco che occorra imporre delle limitazioni per legge sull’uso distorto e non autorizzato di dati, e che queste non necessariamente siano coerenti con gli sviluppi tecnologici, ma ogni tanto metterci un po di cervello non guasterebbe. Qui il riferimento più che al garante va ai DPO e responsabili aziendali che, per mettersi in una “posizione sicura” interpretano certi indirizzi in maniera rigida e decontestualizzata.

Allora vediamo di cosa si tratta questa volta:

A seguito di alcune sentenze, e alle considerazioni che già il garante aveva espresso in passato, il garante stesso si è posto il problema dei cosiddetti “metadati” della posta elettronica.

I metadati

I metadati sono, fondamentalmente, tutto quello che concerne la descrizione di un messaggio di posta elettronica, fatta eccezione dei contenuti. Vengono ricavati durante la transazione SMTP (il protocollo che serve al trasferimento dei messaggi della posta elettronica), le intestazioni tecniche del messaggio di posta elettronica stesso (fate riferimento ai miei Email files per capirne di più), e i log dei nodi attraverso cui passa il messaggio fino al raggiungimento (o meno) della casella di posta dell’utente.

Questi dati, se non gestiti correttamente ed usati in maniera non legale, possono dare adito a processi che violano la riservatezza di mittente e destinatario, e possono consentire un monitoraggio non legittimo, ad esempio, delle attività dei lavoratori ai sensi dello statuto dei lavoratori.

I metadati quindi possono e devono essere oggetto di attenta considerazione.

Ma

Ma, ettepareva, c'è un ma.

io me

I metadati sono anche fondamentali per il funzionamento delle soluzioni che gestiscono la posta, e tra queste esigenze vi è una roba che, sempre per esigenze anche delle normicciuole sulla protezione dei dati, si chiama sicurezza.

Esiste quindi un esigenza di capire quanti metadati vanno tenuti per preservare le esigenze di riservatezza verso quanti servano per il corretto funzionamento dei sistemi.

Il garante ci da una prima risposta: 7 giorni

il garante

Infatti, il Garante ha analizzato (in precedenti provvedimenti) quale fosse il tempo di conservazione dei metadati compatibile con l’attività di raccolta e conservazione degli stessi metadati necessari ad assicurare il funzionamento delle infrastrutture del sistema della posta elettronica e che rispettasse il principio di accountability e il comma 2 dell’art. 4 dello Statuto dei Lavoratori. La conclusione del Garante è stata – appunto –  in poche ore o ad alcuni giorni, in ogni caso non oltre sette giorni, estensibili, in presenza di comprovate e documentate esigenze che ne giustifichino il prolungamento, di ulteriori 48 ore.

Sarei curioso di capire quale sia la componente “tecnica” sottesa a tale valutazione. e metto le virgolette a ragion veduta.

Limitarsi a 7 giorni di metadati è, di per se, una stupidata galattica. Non me ne voglia il garante ed i suoi illuminati esperti, ma evidentemente non hanno mai avuto a che fare con la posta elettronica sia dal punto di vista gestionale che tecnico, e si vede.

Sono pronto a discutere della cosa con qualsiasi “esperto” che ritenga che i 7 giorni siano piu che sufficienti.

Vi sono ottime ragioni per considerare tale finestra temporale inadatta, facciamo qualche esempio:

• Cosa succede se occorre fare ricerca di un messaggio, si pensi ad esempio a problematiche legali in cui le email possano essere oggetto della contesa, risalente a problemi anteriori ai 7 (+2) giorni?
• Cosa succede se occorre fare troubleshooting di problematiche che si protraggono nel tempo e che richiedono, ad esempio, l’analisi di log di server e MTA?
• Cosa succede se occorrono informazioni per monitorare i livelli di sicurezza del sistema?
• Cosa succede se per motivi di sicurezza si cerca di capire quale sia la esposizione al rischio degli utenti in funzione delle metriche di attacco che avvengono sulla posta medesima?

Potrei continuare, ma sono sicuro che i più (voglio essere positivo) hanno capito la problematica.

Ma siccome sono duro di comprendonio mi chiedo:

Tali metadati hanno esigenze di vita diverse se si parla di un Mail Server o di un security gateway?  

Le due cose solo marginalmente coincidono (la condivisione, ad esempio, del protocollo SMTP e la modifica degli Header di posta)

Alcuni dei metadati citati sono, quantomeno, da meglio definire ad esempio:

Cosa si intende per mittente? il campo “from: ” nella intestazione tecnica o il campo “from: ” in quella visibile?

No signor tenente non coincidono.

e l’ip mittente si intende quello dell’ultimo HoP o quello indicato come iniziale?

E cosi il dominio di provenienza (HELO/EHLO) quale è?

Ovviamente se fossi un pessimo soggetto potrei ricordare che l’alterazione, o la costruzione malevola, di questi metadati è alla base di diversi attacchi perpetrati attraverso la posta elettronica, e siccome sono, fondamentalmente, un pessimo soggetto lo ricordo

I metadati della posta elettronica sono spesso modificati ed alterati da attori malevoli al fine di perpetrare attacchi attraverso tale canale di comunicazione

un cattivo soggetto

La conseguenza di questo piccolo punto è, quindi, che il monitoraggio di questi elementi è fondamentale per questioni di gestione della posta, troubleshooting di problematiche e analisi di sicurezza. Pensare che tali esigenze possano essere ricondotte a un 7+2 giorni significa non avere la benchè minima ne pallida idea della realtà tecnica e delle esigenze di sicurezza.

E quindi?

Li vedo i puristi della “privacy” già si ergono:

le questioni tecniche non devono prevalere sui legittimi diritti e protezione delle lavoratrici e dei lavoratori

i DPO duri e puri del GDPR e gli avvocati indefessi dello statuto dei lavoratori

In realtà il garante ha un problema: far si che i metadati siano usati in maniera legittima e consapevole da parte dei soggetti.

Il garante stesso da la soluzione al di la della delirante richiesta dei 7+2 giorni:

I datori di lavoro che per esigenze organizzative e produttive o di tutela del patrimonio anche informativo del titolare (in particolare, per la sicurezza dei sistemi) avessero necessità di trattare i metadati per un periodo di tempo più esteso (quindi tutti salvo rarissime eccezioni quali gli esperti del garante), dovranno espletare le procedure di garanzia previste dallo Statuto dei lavoratori (accordo sindacale o autorizzazione dell’ispettorato del lavoro).

L’estensione del periodo di conservazione oltre l’arco temporale fissato dal Garante può infatti comportare un indiretto controllo a distanza dell’attività del lavoratore ma non per il metadato in se, ma per l’uso illecito effettuato di dali dati.

Del resto se vogliamo estendere la vexata quaestio al piu generico mondo della posta elettronica, compreso, quindi, il messaggio intero, potremmo per estensione pensare di chiederci se è possibile tenere nella casella di posta dell’utente un messaggio per piu di 7+2 giorni.

Attenzione che in pancia a quel mail-server le informazioni sono, almeno negli assunti indicati dal garante per indicare il metadato, tutti presenti.

La eliminazione, quindi, dei metadati comporterebbe la necessaria eliminazione dei messaggi archiviati nel server nella casella dell’utente.

Certo possiamo fargli creare archivi locali, ma questa non è certo una soluzione che si accompagni alla sicurezza (e se volete ne possiamo parlare).

Spieghi il garante allora agli utenti il razionale di tale vincolo e limitazione 🙂

Insomma ad essere chiari le finalità primarie per tenere i metadati per oltre 7+2 giorni, ovviamente, restano troubleshooting di problemi e la sicurezza informatica e i necessari accertamenti da fare a seguito di data breach o comunque incidente sulla sicurezza informatica. Elementi più che validi per ritenere che le indicazioni date siano non sufficienti ne adatte al mantenimento e gestione dei sistemi di posta elettronica.

Ma, occorre dire, il garante stesso non indica un vincolo assoluto nei 7 giorni, ma richiede che retention più lunghe siano poste in essere con la garanzia del rispetto delle tutele previste dal GDPR e dallo statuto dei lavoratori.

Non provateci a dire che non ve lo avevo detto.

Etica e DPO, un difficile rapporto?

Caso non comune ma sto ampliando un mio precedente articolo che, nei fatti, costituisce il corpo centrale di questo post.

Stimolato dai feedback sul mio ultimo post sul DPO

e stimolato dalla lettura di un post ed i commenti sagaci di Andrea Monti mi sono rimesso a pensare a certi ruoi aziendali.

Prima di proseguire nella lettura però dovete leggervi di Andrea Monti:

La scomoda sedia del Data Protection Officer, e perché gli avvocati non possono occuparla

La chiusura finale in particolare è interessante dove Andrea nota:

“…o il DPO fa finta di non vedere (e diventa concorrente in un illecito. Formale, ma pur sempre illecito) oppure mette il veto sull’iniziativa e, se l’azienda prosegue, non ha troppe alternative rispetto a segnalare il fatto all’autorità di protezione.”

…

“Quindi il DPO, anche se non segnala in autonomia una violazione normativa, può essere ascoltato dall’autorità (non solo) di protezione dei dati su queste circostanze. E dunque diventare un potenziale teste a carico (dell’accusa, in altri termini).”

…

Andrea Monti

E qui si apre un interessante punto .. ed è una esperienza che ho vissuto come manager in una multinazionale.

image taken from http://elaine.ie/2016/05/27/state-should-pay-whistleblowers/

Ad un certo punto, in una certa azienda, mi è stato detto che certi dati del personale sarebbero stati trasferiti fuori europa semplicemente perchè si, in barba al GDPR, e che non si doveva dire.

La questione mi ha subito dato fastidio per un motivo personale, tra quei dipendenti c’ero anche io. Erano i miei diritti che erano lesi, anche se i dati sarebbero stati trattati in maniera sicura.

Il punto era che invece che provare a discorrere con le autorità europee o trovare delle vie di mezzo percorribili si era scelto di non rispettare alcuni termini del GDPR. sapendo benissimo di violare un regolamento EU e sapendo benissimo di capire di tale regolamento poco o nulla.

Ancora più fastidioso era l’essere messo in mezzo ad un dilemma etico ed economico.

Durante la riunione ho obiettato che:

1. mi si chiedeva esplicitamente di mentire alle mie persone e colleghi
2. mi si chiedeva di non rispettare le leggi del mio paese
3. mi si chiedeva di rendermi complice di un illecito.

Lo scopo era vedere se ci fossero state reazione da parte dei miei colleghi. Aimè solo 2 CSO nord europei mi diedero ragione.

Ovviamente le mie obiezioni furono derubricate a “quello rompe sempre le scatole” il che mi ha portato, assieme ad altre considerazioni (alcune strettamente personali) alla decisione di non rinnovare la collaborazione con quella azienda e contestualmente segnalare la cosa all’authority dopo la fuoriuscita.

Ora la questione è dove deve, eticamente, cadere la mia lealtà in questi casi? Verso la azienda o verso, in questo caso, le leggi del mio paese?

La cosa non è semplice, ne parlavo in un altro post quando osservavo che considero mascalzoni quei CEO/Board che per puro calcolo matematico preferiscono il rischio della sanzione che l’implementazione corretta del GDPR.

La mia obiezione risiede nel fatto che il GDPR è norma per proteggere le libertà di noi cittadini e residenti EU, non rispettarlo quindi implicitamente mette a rischio le mie libertà individuali.

Nel mio caso la mia lealtà va alla protezione dei miei concittadini e al rispetto della legge, anche se parliamo di un illecito amministrativo o formale la questione non è banale.

Un manager potrebbe allinearsi alla richiesta aziendale, potrebbe non allinearsi e prenderne le conseguenze (lo ho vissuto) o fare una via di mezzo, ad esempio denunciare il comportamento in via anonima alla autorità competente dopo aver, almeno, provato a obiettare sul comportamento.

Ancora più delicato, in questo caso, è il dipendente non manager, vaso di coccio.

L’istituto del whistleblowing potrebbe in qualche modo “proteggere” ma diciamocelo se si viene a sapere chi ha cantato…

Il problema etico rimane, in mancanza di obblighi formali a comunicare alla opportuna authority un eventuale illecito.

Il caso del DPO è anche più critico, visto che istituzionalmente ha obblighi chiari in merito al rispetto del GDPR che sono di indirizzo, formazione e controllo. Il punto è che in assenza di segnalazione alla autorità della non aderenza al regolamento il DPO non esercita la sua funzione di controllo.

Supponiamo per un momento che il DPO presenti le sue valutazioni di rischio su di un processo al board dando una valutazione che presenta un piccolo rischio residuale come accettabile, e che il board rifiuti le conclusioni definendo un rischio accettabile più alto. Ora posso comprendere che questo entri in un ambito di contrattazione tra le parti, se il rischio residuale è troppo alto il DPO deve comunicare con l’authority per la valutazione.

Ora il quanto alto sia è il punto dirimente, se il DPO considera il rischio accettato dal board troppo alto fa bene a comunicare al garante la cosa per un parere?

E se non lo fa e accade un incidente? E se non lo fa e viene una ispezione che giunge alle conclusioni del DPO e trova scritto nelle minute dei meeting del board quali erano le posizioni in merito?

Situazione scivolosa persino senza che vi sia un illecito formale come indicato nel post di andrea che vi invitavo a leggere inizialmente.

Analogo discorso potremmo farlo per il CISO che non ritenga adatti i meccanismi di protezione messi in atto dall’azienda ed in caso di breach incalzato dalle autorità esprima le sue perplessità (possibilmente scritte in qualche documento ufficiale).

Fa bene?

Fa male?

La questione delle responsabilità è quindi delicata, si prenda il caso INPS, dove alla fine tutto è finito a tarallucci e vino. Possibile che internamente nessuno ha sentito il bisogno di denunciare una situazione che ha portato al disastro? Non voglio credere che il livello di incompetenza sia tale per cui nessuno se ne potesse rendere conto.

Se è vero che vi sono vincoli di riservatezza, fino a dove questi si possono spingere?

Come Whistleblower o per ruolo la questione è non semplice, anche perchè vi sono altri termini da considerare tipo:

1. la necessità di uno stipendio
2. la possibilità di trovare lavoro

Pensate, ad esempio, un DPO che denuncia al garante una non conformità della propria azienda. Tra lui ed il CEO difficilmente sarà il CEO ad essere licenziato.

Ma se il DPO perde il lavoro a seguito della cosa (e i metodi ci sono per farlo) e la cosa si sa (questo è un mondo piccolo)…quante possibilità avrà di trovare una nuova collocazione?

Pensare ad una indipendenza che sia reale diventa estremamente difficile soprattutto in una situazione economica dove la ricollocazione non è ne facile ne garantita.

Meditiamo, Meditiamo

Etica e DPO, un difficile rapporto?

Caso non comune ma sto ampliando un mio precedente articolo che, nei fatti, costituisce il corpo centrale di questo post.

Stimolato dai feedback sul mio ultimo post sul DPO

e stimolato dalla lettura di un post ed i commenti sagaci di Andrea Monti mi sono rimesso a pensare a certi ruoi aziendali.

Prima di proseguire nella lettura però dovete leggervi di Andrea Monti:

La scomoda sedia del Data Protection Officer, e perché gli avvocati non possono occuparla

La chiusura finale in particolare è interessante dove Andrea nota:

“…o il DPO fa finta di non vedere (e diventa concorrente in un illecito. Formale, ma pur sempre illecito) oppure mette il veto sull’iniziativa e, se l’azienda prosegue, non ha troppe alternative rispetto a segnalare il fatto all’autorità di protezione.”

…

“Quindi il DPO, anche se non segnala in autonomia una violazione normativa, può essere ascoltato dall’autorità (non solo) di protezione dei dati su queste circostanze. E dunque diventare un potenziale teste a carico (dell’accusa, in altri termini).”

…

Andrea Monti

E qui si apre un interessante punto .. ed è una esperienza che ho vissuto come manager in una multinazionale.

image taken from http://elaine.ie/2016/05/27/state-should-pay-whistleblowers/

Ad un certo punto, in una certa azienda, mi è stato detto che certi dati del personale sarebbero stati trasferiti fuori europa semplicemente perchè si, in barba al GDPR, e che non si doveva dire.

La questione mi ha subito dato fastidio per un motivo personale, tra quei dipendenti c’ero anche io. Erano i miei diritti che erano lesi, anche se i dati sarebbero stati trattati in maniera sicura.

Il punto era che invece che provare a discorrere con le autorità europee o trovare delle vie di mezzo percorribili si era scelto di non rispettare alcuni termini del GDPR. sapendo benissimo di violare un regolamento EU e sapendo benissimo di capire di tale regolamento poco o nulla.

Ancora più fastidioso era l’essere messo in mezzo ad un dilemma etico ed economico.

Durante la riunione ho obiettato che:

1. mi si chiedeva esplicitamente di mentire alle mie persone e colleghi
2. mi si chiedeva di non rispettare le leggi del mio paese
3. mi si chiedeva di rendermi complice di un illecito.

Lo scopo era vedere se ci fossero state reazione da parte dei miei colleghi. Aimè solo 2 CSO nord europei mi diedero ragione.

Ovviamente le mie obiezioni furono derubricate a “quello rompe sempre le scatole” il che mi ha portato, assieme ad altre considerazioni (alcune strettamente personali) alla decisione di non rinnovare la collaborazione con quella azienda e contestualmente segnalare la cosa all’authority dopo la fuoriuscita.

Ora la questione è dove deve, eticamente, cadere la mia lealtà in questi casi? Verso la azienda o verso, in questo caso, le leggi del mio paese?

La cosa non è semplice, ne parlavo in un altro post quando osservavo che considero mascalzoni quei CEO/Board che per puro calcolo matematico preferiscono il rischio della sanzione che l’implementazione corretta del GDPR.

La mia obiezione risiede nel fatto che il GDPR è norma per proteggere le libertà di noi cittadini e residenti EU, non rispettarlo quindi implicitamente mette a rischio le mie libertà individuali.

Nel mio caso la mia lealtà va alla protezione dei miei concittadini e al rispetto della legge, anche se parliamo di un illecito amministrativo o formale la questione non è banale.

Un manager potrebbe allinearsi alla richiesta aziendale, potrebbe non allinearsi e prenderne le conseguenze (lo ho vissuto) o fare una via di mezzo, ad esempio denunciare il comportamento in via anonima alla autorità competente dopo aver, almeno, provato a obiettare sul comportamento.

Ancora più delicato, in questo caso, è il dipendente non manager, vaso di coccio.

L’istituto del whistleblowing potrebbe in qualche modo “proteggere” ma diciamocelo se si viene a sapere chi ha cantato…

Il problema etico rimane, in mancanza di obblighi formali a comunicare alla opportuna authority un eventuale illecito.

Il caso del DPO è anche più critico, visto che istituzionalmente ha obblighi chiari in merito al rispetto del GDPR che sono di indirizzo, formazione e controllo. Il punto è che in assenza di segnalazione alla autorità della non aderenza al regolamento il DPO non esercita la sua funzione di controllo.

Supponiamo per un momento che il DPO presenti le sue valutazioni di rischio su di un processo al board dando una valutazione che presenta un piccolo rischio residuale come accettabile, e che il board rifiuti le conclusioni definendo un rischio accettabile più alto. Ora posso comprendere che questo entri in un ambito di contrattazione tra le parti, se il rischio residuale è troppo alto il DPO deve comunicare con l’authority per la valutazione.

Ora il quanto alto sia è il punto dirimente, se il DPO considera il rischio accettato dal board troppo alto fa bene a comunicare al garante la cosa per un parere?

E se non lo fa e accade un incidente? E se non lo fa e viene una ispezione che giunge alle conclusioni del DPO e trova scritto nelle minute dei meeting del board quali erano le posizioni in merito?

Situazione scivolosa persino senza che vi sia un illecito formale come indicato nel post di andrea che vi invitavo a leggere inizialmente.

Analogo discorso potremmo farlo per il CISO che non ritenga adatti i meccanismi di protezione messi in atto dall’azienda ed in caso di breach incalzato dalle autorità esprima le sue perplessità (possibilmente scritte in qualche documento ufficiale).

Fa bene?

Fa male?

La questione delle responsabilità è quindi delicata, si prenda il caso INPS, dove alla fine tutto è finito a tarallucci e vino. Possibile che internamente nessuno ha sentito il bisogno di denunciare una situazione che ha portato al disastro? Non voglio credere che il livello di incompetenza sia tale per cui nessuno se ne potesse rendere conto.

Se è vero che vi sono vincoli di riservatezza, fino a dove questi si possono spingere?

Come Whistleblower o per ruolo la questione è non semplice, anche perchè vi sono altri termini da considerare tipo:

1. la necessità di uno stipendio
2. la possibilità di trovare lavoro

Pensate, ad esempio, un DPO che denuncia al garante una non conformità della propria azienda. Tra lui ed il CEO difficilmente sarà il CEO ad essere licenziato.

Ma se il DPO perde il lavoro a seguito della cosa (e i metodi ci sono per farlo) e la cosa si sa (questo è un mondo piccolo)…quante possibilità avrà di trovare una nuova collocazione?

Pensare ad una indipendenza che sia reale diventa estremamente difficile soprattutto in una situazione economica dove la ricollocazione non è ne facile ne garantita.

Meditiamo, Meditiamo

Shrems II, Data transfer, and the USA: wheels are rolling.

Probably everyone now has, at least, heard about the EJC sentence called Shrems III that basically rules out the possibility to use Privacy Shield infamous agreement to allow data transfer between EU and USA based on the fact that the USA does not provide enough guarantees EU data will be protected.

If you don’t know (but you should) here my previous article:

https://thepuchiherald.com/2020/07/17/ops-privacy-shield-bye-bye/

After the sentence one of the question was: what now?

Will a Grace period be offered to survive this? (lot of companies were transferring data using privacy shield to USA)

And most of all does SCC will be enough?

The answer my friend, is blowing in the wind...

er no actually there have been some FAQ form the EDPB that should call to action fel local authorities.

According to the new FAQs of the European Data Protection Board on #SchremsII decision, if you want to transfer personal data to the US under the SCCs or other means, you will have to notify the data protection supervisory authority. This approach will oblige companies to perform a massive amount of work since the notification will have to be definitely accompanied by an assessment as to the adequacy of the data transfer mechanism. Are companies and SA ready to handle this large amount of work?

https://edpb.europa.eu/news/news/2020/european-data-protection-board-publishes-faq-document-cjeu-judgment-c-31118-schrems_en

While some Authorities do have not yet reacted (and this is not a surprise for Italians, I am afraid) some others (wonder who) have made a statement that clarifies the doubts that can eventually rise up and not solved by the EDPB’s FAQ.

The Conference of German Supervisory Authorities (DSK) issued its statement yesterday about the consequences of the #Schrems II judgment that, as we can imagine, is completely aligned with the EDPB position. There are some points that are critical on the matter:

dskshremsDownload

Data transfers based on the Privacy Shield are no longer allowed and all companies must immediately suspend them

This is a critical point since I am quite sure there are companies that do not even know their data were delivered to the USA under Privacy Shield. I would like to remind you that if an audit from the authority knock at your door something like: “I don’t know”, “I don’t remember” will not save you. GDPR requires that you, company, prove you have done your duty in a concrete, effective way, so not paper compliance here allowed. Just to make life easier I would love to remind you also that this is not just the German way, and sooner or later the other authorities will align with such requirements.

Transfers based on the SCC require an assessment of the adequacy of the context and the supplier

And here we have the headache since it is not “optional” the assessment is mandatory. This comes as an obvious consequence to the fact in the EDPB FAQ it is written to be allowed SCC’s transfer should be communicated to the authority. Now this means, for some of you so naive that was thinking, I can send a mail to the authority telling, “hey chap I use SCC do not worry” does not work like this. For some reason they want you to prove you did your duty.

The use of SCC for the transfer of data to the United States, in the absence of additional guarantee measures, it is not sufficient to legitimize the activity

And of course, if you send your data to a country that does not guarantee the privacy of EU citizens and residents, well, your duty is kind of complex. And let be clear and brutally honest (while usually I am obscure but kind rotfl) this will require the active cooperation of the vendors that offer you services because you need solid proofs and not just paperBS.

There is no “grace period”

And this means you need to do this right fucking now.

And just for the sake of my Italian fellow countrymen, this means that even if our authority is under a sleeping spell and did not react yet, you have to act nevertheless because again an audit will knock and you will have show you’ve done the right thing. But the “garante” did not tell us nothing will not be an excuse to avoid non-compliance (with the relative consequences).

Time for DPO to start working and earn their money 😂🤣 (Is a joke I know many DPOs already do something)

Guida al GDPR per chi non ne vuol sapere: ma quante carrozze ha questo treno?

Ho appena finito di parlarvi amabilmente degli articoli 1 e 2 del primo capitolo di quell’avvincente romanzo che è il GDPR che già siamo arrivati all’articolo 3, e sembrava solo ieri che stavamo leggendo il titolo….

Beh torniamo quindi a noi.

Articolo 3

L’articolo 3 introduce, in un legalese da paura, l’ambito territoriale di pertinenza del GDPR che, tradotto in italiano, significa dove deve risiedere un soggetto per finire invischiato in tutto questo.

La lettura puntuale dell’articolo è un esercizio semantico interessante e non banale. Come a dire che è scritto in maniera abbastanza incomprensibile.

Cerchiamo di tirare un sospiro e capiamo cosa questo articolo ci porta, perché, purtroppo, è interessante.

Se leggiamo i 3 punti che compongono l’articolo capiamo che il regolamento si applica a coloro che “processano” i dati di persone fisiche residenti in Europa sia che siano in EU o meno. In particolare:

Se sei un soggetto in EU devi rispettare il GDPR anche se fai il trattamento dei dati all’estero, quindi se sei una società con ragione sociale in EU e stai raccogliendo dati di residenti europei ma hai i server in “Cina” o in “USA” devi rispettare il GDPR.

Se non sei un soggetto in EU ma lavori con dati di europei (cittadini o residenti) in Europa allora sei vincolato al GDPR, e non importa se il trattamento ha fini commerciali o meno. Questo significa, ad esempio, che Linkedin o Facebook o Google devono rispettare il GDPR per raccogliere i dati in EU.

La domanda che sicuramente tutti si pongono è: ma allora posso mettere i miei dati su Baidu? E Baidu è vincolato al rispetto del GDPR?

Ora a parte che non è detto che tutti sappiano chi è questo Baidu, il punto è interessante. Leggendo l’articolo 3 mi verrebbe da dire che si, anche Baidu (il Google cinese, vi aiuto) dovrebbe conformarsi. Il punto è, eventualmente, come esercitare il diritto di controllo e quindi le eventuali multe se il soggetto che raccoglie i dati europei risiede completamente al di fuori dell’UE senza avere in UE una rappresentanza legale.

Considerando la natura di Internet la domanda non è peregrina, andare a batter cassa o chieder conto del rispetto delle regole in Cina o USA non è decisamente un esercizio di facile applicazione.

Almeno l’articolo 3 ci definisce il perimetro territoriale cui fare riferimento: se hai a che fare con dati personali di cittadini eo residenti dell’Unione Europea anche se non sei una entità EU dovresti rispettare le regole.

Diciamo, per contro, che se un cittadino europeo va al di fuori dell’unione e lascia i suoi dati a aziende che niente hanno a che fare con l’unione europea non è coperto dal GDPR, il che non ci dovrebbe stupire… In teoria quando siamo, ad esempio, in un paese extra UE dobbiamo seguire le leggi del paese che ci ospita. Ad esempio, se ti mandano andiamo a quel paese, diciamo in UK, e guidi come in Italia poi non stupirti se questi ti dicono che stavi guidando contromano … a meno che guidi regolarmente contromano anche in Italia, allora sei il proprietario della Ford Focus bianca che tutte le mattine mi sorpassa e si fa un paio di km contromano per evitare la coda sulla statale della val Tidone ?.

Ma torniamo al GDPR che, come al solito, ho divagato. Per finire la comprensione dell’articolo al solito vi suggerisco la lettura dei seguenti “recitals”:

22, 23, 24, 25

In particolare ci viene comodo leggere il numero 22

(22) Qualsiasi trattamento di dati personali effettuato nell’ambito delle attività di uno stabilimento di un titolare del trattamento o responsabile del trattamento nel territorio dell’Unione dovrebbe essere conforme al presente regolamento, indipendentemente dal fatto che il trattamento avvenga all’interno dell’Unione. Lo stabilimento implica l’effettivo e reale svolgimento di attività nel quadro di un’organizzazione stabile. A tale riguardo, non è determinante la forma giuridica assunta, sia essa una succursale o una filiale dotata di personalità giuridica.

In cui si specifica al di la di qualsiasi ragionevole dubbio (ma quelli irragionevoli sono sempre accetti) che lo stabilimento (non balneare)

Dopo l’articolo 3 troviamo, incredibile a dirsi:

Articolo 4

Commovente a dirsi, le definizioni di quanto troviamo dopo arrivano con l’articolo 4.

Le varie definizioni possono essere accompagnate da i relativi “recitals” in particolare:

26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, , 42, 43, 48, 67, 85, 86, 86, 87, 88, 91, 124, 150

Ovviamente i 26 punti fanno riferimento a diversi capitoli, quindi lacune definizione non le abbiamo incontrate ancora ma arriveranno solo dopo.

Attenzione attenzione, sapete cosa c’è dopo l’articolo 4?

Ovvio l’articolo 5 ma sopratutto:

Il capitolo 2, dove si parlerà dei principi su cui si basa il GDPR. 7 articoli che ci definiranno il bi ed il ba

Articolo 5 – Principi applicabili al trattamento di dati personali (39)
Articolo 6 – Liceità del trattamento (40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50)
Articolo 7 – Condizioni per il consenso (32, 33, 42, 43)
Articolo 8 – Condizioni applicabili al consenso dei minori in relazione ai servizi della società dell’informazione (38)
Articolo 9 – Trattamento di categorie particolari di dati personali (51, 52, 53, 54, 55, 56)
Articolo 10 – Trattamento dei dati personali relativi a condanne penali e reati
Articolo 11 – Trattamento che non richiede l’identificazione (57)

Che dite li dobbiamo vedere tutti uno per uno o possiamo solo saltare la dove ci sono coe interessanti da capire?

Buona lettura…. ?

Guida al GDPR per chi non ne vuol sapere: ma quante carrozze ha questo treno?

Ho appena finito di parlarvi amabilmente degli articoli 1 e 2 del primo capitolo di quell’avvincente romanzo che è il GDPR che già siamo arrivati all’articolo 3, e sembrava solo ieri che stavamo leggendo il titolo….

Beh torniamo quindi a noi.

Articolo 3

L’articolo 3 introduce, in un legalese da paura, l’ambito territoriale di pertinenza del GDPR che, tradotto in italiano, significa dove deve risiedere un soggetto per finire invischiato in tutto questo.

La lettura puntuale dell’articolo è un esercizio semantico interessante e non banale. Come a dire che è scritto in maniera abbastanza incomprensibile.

Cerchiamo di tirare un sospiro e capiamo cosa questo articolo ci porta, perché, purtroppo, è interessante.

Se leggiamo i 3 punti che compongono l’articolo capiamo che il regolamento si applica a coloro che “processano” i dati di persone fisiche residenti in Europa sia che siano in EU o meno. In particolare:

Se sei un soggetto in EU devi rispettare il GDPR anche se fai il trattamento dei dati all’estero, quindi se sei una società con ragione sociale in EU e stai raccogliendo dati di residenti europei ma hai i server in “Cina” o in “USA” devi rispettare il GDPR.

Se non sei un soggetto in EU ma lavori con dati di europei (cittadini o residenti) in Europa allora sei vincolato al GDPR, e non importa se il trattamento ha fini commerciali o meno. Questo significa, ad esempio, che Linkedin o Facebook o Google devono rispettare il GDPR per raccogliere i dati in EU.

La domanda che sicuramente tutti si pongono è: ma allora posso mettere i miei dati su Baidu? E Baidu è vincolato al rispetto del GDPR?

Ora a parte che non è detto che tutti sappiano chi è questo Baidu, il punto è interessante. Leggendo l’articolo 3 mi verrebbe da dire che si, anche Baidu (il Google cinese, vi aiuto) dovrebbe conformarsi. Il punto è, eventualmente, come esercitare il diritto di controllo e quindi le eventuali multe se il soggetto che raccoglie i dati europei risiede completamente al di fuori dell’UE senza avere in UE una rappresentanza legale.

Considerando la natura di Internet la domanda non è peregrina, andare a batter cassa o chieder conto del rispetto delle regole in Cina o USA non è decisamente un esercizio di facile applicazione.

Almeno l’articolo 3 ci definisce il perimetro territoriale cui fare riferimento: se hai a che fare con dati personali di cittadini eo residenti dell’Unione Europea anche se non sei una entità EU dovresti rispettare le regole.

Diciamo, per contro, che se un cittadino europeo va al di fuori dell’unione e lascia i suoi dati a aziende che niente hanno a che fare con l’unione europea non è coperto dal GDPR, il che non ci dovrebbe stupire… In teoria quando siamo, ad esempio, in un paese extra UE dobbiamo seguire le leggi del paese che ci ospita. Ad esempio, se ti mandano andiamo a quel paese, diciamo in UK, e guidi come in Italia poi non stupirti se questi ti dicono che stavi guidando contromano … a meno che guidi regolarmente contromano anche in Italia, allora sei il proprietario della Ford Focus bianca che tutte le mattine mi sorpassa e si fa un paio di km contromano per evitare la coda sulla statale della val Tidone ?.

Ma torniamo al GDPR che, come al solito, ho divagato. Per finire la comprensione dell’articolo al solito vi suggerisco la lettura dei seguenti “recitals”:

22, 23, 24, 25

In particolare ci viene comodo leggere il numero 22

(22) Qualsiasi trattamento di dati personali effettuato nell’ambito delle attività di uno stabilimento di un titolare del trattamento o responsabile del trattamento nel territorio dell’Unione dovrebbe essere conforme al presente regolamento, indipendentemente dal fatto che il trattamento avvenga all’interno dell’Unione. Lo stabilimento implica l’effettivo e reale svolgimento di attività nel quadro di un’organizzazione stabile. A tale riguardo, non è determinante la forma giuridica assunta, sia essa una succursale o una filiale dotata di personalità giuridica.

In cui si specifica al di la di qualsiasi ragionevole dubbio (ma quelli irragionevoli sono sempre accetti) che lo stabilimento (non balneare)

Dopo l’articolo 3 troviamo, incredibile a dirsi:

Articolo 4

Commovente a dirsi, le definizioni di quanto troviamo dopo arrivano con l’articolo 4.

Le varie definizioni possono essere accompagnate da i relativi “recitals” in particolare:

26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, , 42, 43, 48, 67, 85, 86, 86, 87, 88, 91, 124, 150

Ovviamente i 26 punti fanno riferimento a diversi capitoli, quindi lacune definizione non le abbiamo incontrate ancora ma arriveranno solo dopo.

Attenzione attenzione, sapete cosa c’è dopo l’articolo 4?

Ovvio l’articolo 5 ma sopratutto:

Il capitolo 2, dove si parlerà dei principi su cui si basa il GDPR. 7 articoli che ci definiranno il bi ed il ba

Articolo 5 – Principi applicabili al trattamento di dati personali (39)
Articolo 6 – Liceità del trattamento (40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50)
Articolo 7 – Condizioni per il consenso (32, 33, 42, 43)
Articolo 8 – Condizioni applicabili al consenso dei minori in relazione ai servizi della società dell’informazione (38)
Articolo 9 – Trattamento di categorie particolari di dati personali (51, 52, 53, 54, 55, 56)
Articolo 10 – Trattamento dei dati personali relativi a condanne penali e reati
Articolo 11 – Trattamento che non richiede l’identificazione (57)

Che dite li dobbiamo vedere tutti uno per uno o possiamo solo saltare la dove ci sono coe interessanti da capire?

Buona lettura…. ?

Guida al GDPR per chi non ne vuol sapere: raschia raschia rimane il rischio ?

Ma se ti dico “rischio” tu che mi rispondi?

Er… no non intendo la sequela di insulti o le minacce più o meno velate a cu stai quasi sicuramente pensando, stavo cercando di parlare di GDPR…

No, no, GDPR non è una parolaccia, calmiamoci.

Insomma volevo solo chiedere che cosa associate alla idea di rischio indicata dal GDPR.

Ne parlo qui perché ultimamente ho avuto modo di vedere come molti non hanno bene chiaro cosa sia questo fantomatico rischio di cui si parla.

Allora cerchiamo di fare un poco di chiarezza ad un livello che persino io possa capire di cosa stiamo parlando, quindi estremamente basso.

Genericamente quando parliamo di rischio facciamo riferimento alla eventualità di subire un danno (più incerto di quello implicito in pericolo).

In termini estremamente generici questo significa dover analizzare una serie di cose associate ad un evento che comporti rischi:

• la prima è: chi subisce il danno
• la seconda è: l’entità del danno
• la terza è: la probabilità che l’evento si possa verificare.

Il primo punto è fondamentale, i quanto il soggettooggetto del rischio determina pesantemente le altre due occorrenze sia in termini di valutazione quantitativa che qualitativa e quindi guida le scelte rivolte a ridurre, mitigare il rischio, trasferirlo o comunque gestirlo in toto o la sua parte residua.

Il secondo punto afferisce alla entità del danno. A seconda del tipo di rischio che stiamo analizzando l’entità viene solitamente parametrizzata attraverso valori di facile lettura, come ad esempio la perdita economica associata.

Il terzo punto va ovviamente ad indirizzare la esigenza di calcolare quante possibilità ci siano che l’evento infausto che causa il danno possa accadere. Laddove ci fosse la certezza non si parlerebbe di rischio e quindi le analisi di cui sopra sarebbero inutili e parleremmo, semplicemente, di pericolo.

L’analisi del rischio ci consente di mettere in atto quelle procedure e comportamenti che possano minimizzare gli effetti dannosi. Questo può essere effettuato attraverso diverse scelte NON mutuamente esclusive tra di loro.

Ad esempio:

• Si può scegliere di indirizzare gli sforzi in direzione dell’abbassamento dell’entità del danno subito in caso di evento infausto
• Si può scegliere altrimenti di indirizzare gli sforzi in direzione dell’abbassamento della probabilità che l’evento infausto possa accadere.

Potrebbe accadere che uno specifico evento si possa semplicemente eliminare dalla nostra tabella dei rischi a seguito delle azioni intraprese ma più spesso accade che i costi per l’eliminazione del rischio siano così alti che conviene invece accettare un rischio residuale.

Le azioni per abbassare il rischio possono essere ad esempio di mitigazione (vedi i due punti precedenti) o di trasferimento.

La soglia di accettabilità del rischio dipende ovviamente da valutazioni soggettive e oggettive e dipende dall’ambito di cui stiamo parlando.

Non esiste azione umana che sia esente dal rischio, ma la percezione e l’accettazione del rischio dipende ovviamente dal dominio cui stiamo facendo riferimento.

Ok ok ti sei annoiato con cose che sai benissimo meglio di me, anche se non sai di saperle (dopotutto tutti attraversano la strada e quindi gestiscono rischi….)

Torniamo al GDPR.

Il rischio in termini di GDPR è il rischio di danneggiare la privacy e le libertà fondamentali di un soggetto.

Usando i tre punti di cui si parlava all’inizio del mio sproloquio potremmo dire che:

chi subisce il danno è l’utenteutenti i cui dati personali vengono in qualche maniera indirizzati dall’evento in analisi (copia, cancellazione, modifica e via dicendo)

l’entità del danno è quanto l’utente possa essere danneggiato dall’evento specifico ed è, ovviamente, legato alla natura dei dati in oggetto e a quello che a questi dati è accaduto.

La probabilità che l’evento infausto possa accadere è invece legata ai processi in uso per la gestione dei dati raccolti.

Non facciamo i soliti errori per favore:

Innanzi tutto per poter implementare correttamente il GDPR occorre fare una valutazione del rischio implicito nella gestione dei dati personali, utilizzando come riferimento quello descritto sopra.

Chi deve fare queste valutazioni è chi si occupa di questa cosa. In ultima analisi spetta al responsabile dell’azienda utilizzando il DPO quando presente come fonte autorevole di indicazioni in merito.

Spetta al responsabile aziendale o “data controller” quindi decidere:

• quale sia il rischio residuo accettabile
• quale siano le azioni da intraprendere per mitigare, minimizzare i rischi legai al GDPR.

Questa cosa è di fondamentale importanza da capire. Nella nomenclatura del GDPR il Data controller o responsabile della gestione dei dati personali è la fonte delle decisioni. Il o i data processor pur condividendo una responsabilità operativa nella gestione della sicurezza del dato non sono responsabili delle scelte operate per proteggerli come tali.

Come a dire che non sta alle strutture IT decidere cosa fare, al più all’IT possono essere demandate le scelte implementative, una volta individuata la via di mitigazione che il “data Controller” ritiene più adatta ad abbassare la soglia di rischio fino ad un livello di rischio residuale accettabile, laddove queste richiedano una opzione tecnologica e non di processo.

Questa osservazione implica la comprensione di una cosa non sempre chiara in chi si occupa di GDPR:

il rischio in termini di GDPR è cosa diversa dal rischio di Business o dal rischio di Cyber Security.

Mescolare questi 3 domini assieme senza avere chiara a distinzione tra i 3 tipi di rischio comporta semplicemente l’indirizzamento verso scelte errate in quanto:

o non indirizzano la natura del rischio in oggetto (e quindi rappresentano una duplice voce di costo in termini di spese effettuate inutilmente e di rischio ancora presente)

o non mitigano correttamente tale rischio entro la soglia di accettabilità (rischio residuo accettabile).

o portano a scelte non ottimali e quindi più costose rispetto il necessario.

Purtroppo la non esatta comprensione del GDPR sta portando molte aziende a vedere la cosa solo in termini meramente tecnologici, associando il rischio GDPR al rischio tipico della Cyber Security. Questo rischia di far intraprendere alle aziende percorsi errati o eccessivamente onerosi.

Ma che differenza c’è?

Per capire la differenza tra un rischio di cyber security, di business e di uno legato al GDPR occorre pensare attentamente alla natura intrinseca del rischio in senso del GDPR.

Il GDPR si preoccupa delle libertà fondamentali dell’individuo espresse attraverso la difesa della sua “privacy”.

Ora prendiamo un paio di eventi esemplificativi dei domini di Cyber Security: DoS (Denial of Service) e attacco Ransmomware.

L’attacco  dDos

In caso di attacco DoSdDoS che blocchi una struttura, siamo in presenza di un evento dannoso che potrebbe impattare il business di una azienda nel caso colpisca, ad esempio, una interfaccia di e-commerce o una di mera presenza marketing online.

Dal punto di vista del business a seconda della interfaccia impattata le valutazioni di rischio potrebbero essere diverse ma potremmo dire che, se siamo in presenza di un attacco su di una interfaccia di E-commerce l’impatto (ed il rischio) è alto mentre in caso di una interfaccia di puro marketing potrebbe essere di medio livello

Dal punto di vista meramente Cyber, un attacco Dos è tanto più grave quanto maggiore sia la probabilità che esso avvenga e che impatti diverse strutture. In caso di un attacco ad un servizio online di E-commerce siamo in presenza di tutti gli elementi per definirlo un rischio elevato (probabilità, impatto, facilità di attacco….), ma la stessa analisi vale per un sito marketing. Dal punto di vista cyber quindi abbiamo valutazioni discordanti rispetto a quello di business.

Ora se ci mettiamo nei panni del GDPR in entrambi casi il rischio di esposizione dei dati dell’utente sono minimi o nulli, dono quindi in entrambi i casi eventi di basso rischio in termini di GDPR che potrebbero quindi essere considerati accettabili in termini in di rischio residuale.

 

L’attacco Ramsonware

Ricordate wannacy? Giusto per nominare l’ultimo?

In caso di business gli effetti di un ransomware che attacchi, ad esempio, le strutture di billing potrebbero essere disastrose, mentre l’attacco ad una serie limitata di PC potrebbe essere ininfluente.

Dal punto di vista Cyber invece la probabilità di attacco ad un terminale di un utente è più alta, e potenzialmente potrebbe dare adito ad attacchi diffusi interni, ne consegue che dal punto di vista cyber ci si potrebbe attendere addirittura una valutazione più alta di rischio sul pc dell’utente che sul sistema di billing.

Dal punto di vista del GDPR se sono in piedi processi che consentano il recupero dei dati in tempi accettabili (non è richiesta la immediatezza) un ransomware presenta un livello di rischio medio ed addirittura basso nel caso di un sistema di billing che tenga le anagrafiche separate (e quindi non impattate dall’attacco cui stiamo facendo riferimento nell’esempio.

 

È interessante notare che data la diversa natura del rischio anche le azioni di mitigazione da intraprendere sono diverse nei due casi a seconda del tipo di rischio di cui parliamo.

Nel caso del ransomware, ad esempio, dal punto di vista del GDPR potrebbe essere sufficiente una buona struttura di backup isolata dal sistema, mentre nel caso di business la business continuity richiederebbe una serie ben diversa di sforzi implementativi.

Mescolare e fare confusione non è una buona strada da seguire.

Fare confusione sui diversi domini di rischio, anche se afferenti ad un medesimo evento, può portare a scelte non corrette di mitigazione eo trasferimento.

Se questo è vero in generale, nel caso del GDPR assume un significato ancora più grande in quanto occorre capire che il soggetto a rischio è esterno alla azienda e quindi le azioni da intraprendere sono concettualmente diverse.

Non definire sin dall’inizio le responsabilità e modello di calcolo del rischio comporta scelte, nella migliore delle ipotesi, sbagliate.

 

Meditate gente meditate

Ciao

Antonio

 

 

 

 

 

 

Guida al GDPR per chi non ne vuol sapere: raschia raschia rimane il rischio ?

Ma se ti dico “rischio” tu che mi rispondi?

Er… no non intendo la sequela di insulti o le minacce più o meno velate a cu stai quasi sicuramente pensando, stavo cercando di parlare di GDPR…

No, no, GDPR non è una parolaccia, calmiamoci.

Insomma volevo solo chiedere che cosa associate alla idea di rischio indicata dal GDPR.

Ne parlo qui perché ultimamente ho avuto modo di vedere come molti non hanno bene chiaro cosa sia questo fantomatico rischio di cui si parla.

Allora cerchiamo di fare un poco di chiarezza ad un livello che persino io possa capire di cosa stiamo parlando, quindi estremamente basso.

Genericamente quando parliamo di rischio facciamo riferimento alla eventualità di subire un danno (più incerto di quello implicito in pericolo).

In termini estremamente generici questo significa dover analizzare una serie di cose associate ad un evento che comporti rischi:

• la prima è: chi subisce il danno
• la seconda è: l’entità del danno
• la terza è: la probabilità che l’evento si possa verificare.

Il primo punto è fondamentale, i quanto il soggettooggetto del rischio determina pesantemente le altre due occorrenze sia in termini di valutazione quantitativa che qualitativa e quindi guida le scelte rivolte a ridurre, mitigare il rischio, trasferirlo o comunque gestirlo in toto o la sua parte residua.

Il secondo punto afferisce alla entità del danno. A seconda del tipo di rischio che stiamo analizzando l’entità viene solitamente parametrizzata attraverso valori di facile lettura, come ad esempio la perdita economica associata.

Il terzo punto va ovviamente ad indirizzare la esigenza di calcolare quante possibilità ci siano che l’evento infausto che causa il danno possa accadere. Laddove ci fosse la certezza non si parlerebbe di rischio e quindi le analisi di cui sopra sarebbero inutili e parleremmo, semplicemente, di pericolo.

L’analisi del rischio ci consente di mettere in atto quelle procedure e comportamenti che possano minimizzare gli effetti dannosi. Questo può essere effettuato attraverso diverse scelte NON mutuamente esclusive tra di loro.

Ad esempio:

• Si può scegliere di indirizzare gli sforzi in direzione dell’abbassamento dell’entità del danno subito in caso di evento infausto
• Si può scegliere altrimenti di indirizzare gli sforzi in direzione dell’abbassamento della probabilità che l’evento infausto possa accadere.

Potrebbe accadere che uno specifico evento si possa semplicemente eliminare dalla nostra tabella dei rischi a seguito delle azioni intraprese ma più spesso accade che i costi per l’eliminazione del rischio siano così alti che conviene invece accettare un rischio residuale.

Le azioni per abbassare il rischio possono essere ad esempio di mitigazione (vedi i due punti precedenti) o di trasferimento.

La soglia di accettabilità del rischio dipende ovviamente da valutazioni soggettive e oggettive e dipende dall’ambito di cui stiamo parlando.

Non esiste azione umana che sia esente dal rischio, ma la percezione e l’accettazione del rischio dipende ovviamente dal dominio cui stiamo facendo riferimento.

Ok ok ti sei annoiato con cose che sai benissimo meglio di me, anche se non sai di saperle (dopotutto tutti attraversano la strada e quindi gestiscono rischi….)

Torniamo al GDPR.

Il rischio in termini di GDPR è il rischio di danneggiare la privacy e le libertà fondamentali di un soggetto.

Usando i tre punti di cui si parlava all’inizio del mio sproloquio potremmo dire che:

chi subisce il danno è l’utenteutenti i cui dati personali vengono in qualche maniera indirizzati dall’evento in analisi (copia, cancellazione, modifica e via dicendo)

l’entità del danno è quanto l’utente possa essere danneggiato dall’evento specifico ed è, ovviamente, legato alla natura dei dati in oggetto e a quello che a questi dati è accaduto.

La probabilità che l’evento infausto possa accadere è invece legata ai processi in uso per la gestione dei dati raccolti.

Non facciamo i soliti errori per favore:

Innanzi tutto per poter implementare correttamente il GDPR occorre fare una valutazione del rischio implicito nella gestione dei dati personali, utilizzando come riferimento quello descritto sopra.

Chi deve fare queste valutazioni è chi si occupa di questa cosa. In ultima analisi spetta al responsabile dell’azienda utilizzando il DPO quando presente come fonte autorevole di indicazioni in merito.

Spetta al responsabile aziendale o “data controller” quindi decidere:

• quale sia il rischio residuo accettabile
• quale siano le azioni da intraprendere per mitigare, minimizzare i rischi legai al GDPR.

Questa cosa è di fondamentale importanza da capire. Nella nomenclatura del GDPR il Data controller o responsabile della gestione dei dati personali è la fonte delle decisioni. Il o i data processor pur condividendo una responsabilità operativa nella gestione della sicurezza del dato non sono responsabili delle scelte operate per proteggerli come tali.

Come a dire che non sta alle strutture IT decidere cosa fare, al più all’IT possono essere demandate le scelte implementative, una volta individuata la via di mitigazione che il “data Controller” ritiene più adatta ad abbassare la soglia di rischio fino ad un livello di rischio residuale accettabile, laddove queste richiedano una opzione tecnologica e non di processo.

Questa osservazione implica la comprensione di una cosa non sempre chiara in chi si occupa di GDPR:

il rischio in termini di GDPR è cosa diversa dal rischio di Business o dal rischio di Cyber Security.

Mescolare questi 3 domini assieme senza avere chiara a distinzione tra i 3 tipi di rischio comporta semplicemente l’indirizzamento verso scelte errate in quanto:

o non indirizzano la natura del rischio in oggetto (e quindi rappresentano una duplice voce di costo in termini di spese effettuate inutilmente e di rischio ancora presente)

o non mitigano correttamente tale rischio entro la soglia di accettabilità (rischio residuo accettabile).

o portano a scelte non ottimali e quindi più costose rispetto il necessario.

Purtroppo la non esatta comprensione del GDPR sta portando molte aziende a vedere la cosa solo in termini meramente tecnologici, associando il rischio GDPR al rischio tipico della Cyber Security. Questo rischia di far intraprendere alle aziende percorsi errati o eccessivamente onerosi.

Ma che differenza c’è?

Per capire la differenza tra un rischio di cyber security, di business e di uno legato al GDPR occorre pensare attentamente alla natura intrinseca del rischio in senso del GDPR.

Il GDPR si preoccupa delle libertà fondamentali dell’individuo espresse attraverso la difesa della sua “privacy”.

Ora prendiamo un paio di eventi esemplificativi dei domini di Cyber Security: DoS (Denial of Service) e attacco Ransmomware.

L’attacco  dDos

In caso di attacco DoSdDoS che blocchi una struttura, siamo in presenza di un evento dannoso che potrebbe impattare il business di una azienda nel caso colpisca, ad esempio, una interfaccia di e-commerce o una di mera presenza marketing online.

Dal punto di vista del business a seconda della interfaccia impattata le valutazioni di rischio potrebbero essere diverse ma potremmo dire che, se siamo in presenza di un attacco su di una interfaccia di E-commerce l’impatto (ed il rischio) è alto mentre in caso di una interfaccia di puro marketing potrebbe essere di medio livello

Dal punto di vista meramente Cyber, un attacco Dos è tanto più grave quanto maggiore sia la probabilità che esso avvenga e che impatti diverse strutture. In caso di un attacco ad un servizio online di E-commerce siamo in presenza di tutti gli elementi per definirlo un rischio elevato (probabilità, impatto, facilità di attacco….), ma la stessa analisi vale per un sito marketing. Dal punto di vista cyber quindi abbiamo valutazioni discordanti rispetto a quello di business.

Ora se ci mettiamo nei panni del GDPR in entrambi casi il rischio di esposizione dei dati dell’utente sono minimi o nulli, dono quindi in entrambi i casi eventi di basso rischio in termini di GDPR che potrebbero quindi essere considerati accettabili in termini in di rischio residuale.

 

L’attacco Ramsonware

Ricordate wannacy? Giusto per nominare l’ultimo?

In caso di business gli effetti di un ransomware che attacchi, ad esempio, le strutture di billing potrebbero essere disastrose, mentre l’attacco ad una serie limitata di PC potrebbe essere ininfluente.

Dal punto di vista Cyber invece la probabilità di attacco ad un terminale di un utente è più alta, e potenzialmente potrebbe dare adito ad attacchi diffusi interni, ne consegue che dal punto di vista cyber ci si potrebbe attendere addirittura una valutazione più alta di rischio sul pc dell’utente che sul sistema di billing.

Dal punto di vista del GDPR se sono in piedi processi che consentano il recupero dei dati in tempi accettabili (non è richiesta la immediatezza) un ransomware presenta un livello di rischio medio ed addirittura basso nel caso di un sistema di billing che tenga le anagrafiche separate (e quindi non impattate dall’attacco cui stiamo facendo riferimento nell’esempio.

 

È interessante notare che data la diversa natura del rischio anche le azioni di mitigazione da intraprendere sono diverse nei due casi a seconda del tipo di rischio di cui parliamo.

Nel caso del ransomware, ad esempio, dal punto di vista del GDPR potrebbe essere sufficiente una buona struttura di backup isolata dal sistema, mentre nel caso di business la business continuity richiederebbe una serie ben diversa di sforzi implementativi.

Mescolare e fare confusione non è una buona strada da seguire.

Fare confusione sui diversi domini di rischio, anche se afferenti ad un medesimo evento, può portare a scelte non corrette di mitigazione eo trasferimento.

Se questo è vero in generale, nel caso del GDPR assume un significato ancora più grande in quanto occorre capire che il soggetto a rischio è esterno alla azienda e quindi le azioni da intraprendere sono concettualmente diverse.

Non definire sin dall’inizio le responsabilità e modello di calcolo del rischio comporta scelte, nella migliore delle ipotesi, sbagliate.

 

Meditate gente meditate

Ciao

Antonio

 

 

 

 

 

 

Guida al GDPR per chi non ne vuol sapere: dice il controller "lei non sa chi sono io"

Manca un anno al GDPR Doom’s Day e ovviamente siamo ancora impreparati ad affrontare la cosa.

Non lo dico io, ovvio, ma lo dicono le statistiche. E se i nostri amici al di la delle alpi sono messi non benissimo leggendo queste statistiche, vi lascio immaginare come siamo messi noi.

Siccome è un po che mi occupo della faccenda devo dire che mi sembra evidente che la comprensione di cosa sia il GDPR latita tra i responsabili aziendali, e le idee su come implementarlo sono spesso poche ma ben confuse.

Ho parlato in articoli precedenti diffusamente sul GDPR in tono lieve e talvolta ironico, ci provo ancora, anche se confesso che incomincio a provare un vago senso di inquietudine quando parlo di questi argomenti.

iniziamo dai alcuni errori di comprensione comuni

Il Bestiario GDPR

• Il GDPR mi impedisce di collezionare i dati personali

lo ho sentito dire parecchie volte, ed ovviamente la risposta più corretta a questa osservazione è:

…ma la finiamo di dire pirlate?

Il GDPR è un regolamento che impone regole stringenti di gestione e processo dei dati personali, ma non ne impedisce ne la raccolta ne l’utilizzo. il punto è: sappiamo che ti servono, ma devi proteggere l’identità delle persone legate ai dati che hai raccolto.

• Il GDPR è una roba IT, non mi interessa

e si …

…ma le multe le paghi tu non l’IT

Ovviamente tutto quello che non ci piace diventa un problema IT, peccato che l’IT sia impattata dal GDPR in maniera strumentale. Mi spiego meglio, l’IT deve implementare quelle misure che qualcuno decide debbano essere implementate per garantire il rispetto della normativa, ma non è l’IT che decide cosa implementare.

• Il GDPR è una roba da avvocati, l’IT non centra

Ovviamente duale al precedente esiste la versione IT che si declina con un

ma a me cosa importa di sta roba?

peccato che una corretta implementazione dei dettami del GDPR imponga anche all’IT a ripensare i propri processi ed iniziare a gestire le cose in maniera adulta.

• Io Faccio HR non mi devo occupare di queste cose

Ora notoriamente la mia posizione nei confronti della moderna interpretazione delle funzioni HR è abbastanza “critica” (lo so è un eufemismo).

…Il GDPR fa riferimento ai dati personali, ma anche quelli dei dipendenti…mi spiace ma ci sei dentro fino al collo caro HR manager…

Purtroppo per gli amici HR il GDPR non fa distinzioni tra clienti, fornitori o dipendenti. il GDPR si occupa di preservare le libertà fondamentali dell’individuo, essere impiegato non ne inficia né gli obiettivi né gli obblighi. Si, le funzioni HR devono tenere conto del GDPR.

e via scemenzando ne ho sentite fin troppe, anche da sedicenti personaggi che si offrono come esperti. Ok Ok loro dicono lo stesso di me 🙂

GDPR e Processi

Il primo che dovrebbe preoccuparsi del GDPR non è altri che il Board della azienda. La corretta implementazione del GDPR richiede infatti la esplicita presa in carico della azienda della implementazione della conformità alla nuova legge.

Nel dettato del GDPR viene esplicitato diverse volte che spetta all Data Controller di fare le valutazioni inerenti a quale sia il rischio legato alla getione dei dati personali tenendo presente da un lato le esigenze del business dall’altro le libertà individuali da proteggere.

In altre parole il motore della analisi è il Business. e questo non è un dominio che attiene all’IT ma al board della azienda.

l’implementazione del GDPR richiede che si sia in grado di fare una valutazione di Business dell’impatto del processo di raccolta ed elaborazione di dati personali. è il business che determina anche come devono essere gestiti e protetti questi dati.

Il soggetto utilizzato nella nomenclatura GDPR per fare queste valutazioni è il Data Controller. Il responsabile ultimo del trattamento, il CEO della azienda.

in altre parole chiedere alle funzioni IT di gestire il GDPR è come chiedere ad un pilota di progettare una macchina.

Alla fine della fiera la corretta implementazione della normativa richiede la definizione di processi definiti tracciabili e sicuri che consentano di gestire tutta la vita del dato personale all’interno della azienda. questo comporta:

1. la definizione delle responsabilità all’interno della struttura (ruolo che spetta per definizione al management)
2. la definizione del livello di rischio accettabile in relazione all’attività aziendale ed alla natura dei dati raccolti (che secondo il GDR spetta al management aziendale)
3. la implementazione di misure correttive atte a minimizzare il rischio ANCHE dal punto di vista informatico, cosa che richiede l’intervento delle funzioni IT e di sicurezza

Data Controller e Data Processor

Non si può capire cosa sia il GDPR senza aver capito appieno chi è il Data controller, chi è il Data processor e come gira il fumo 🙂

Data Controller

chi cavolo è il data controller?

Il Data controller secondo il GDPR è il responsabile del trattamento dei dati, insomma quello che decide:

• che dati raccogliere
• per cosa utilizzarli
• valutare e gestire il rischio (attraverso lo strumento della DPIA)

In quanto responsabile, spetta al Data Controller (il CEO aziendale o chi per lui) definire quale sia il livello di rischio accettabile e quindi quali siano le misure di mitigazione corrette da mettere in piedi tenendo presente i vincoli dettati dal GDPR.

Questo non significa che altre funzioni aziendali non siano coinvolte nel processo di definizione; HR, MKTG, Sales ed IT sono componenti attive del processo. Ma alla fine la decisione spetta a chi ha la responsabilità, e questa ricade, secondo il GDPR, sul Data Controller in quanto è l’owner delle attività di business e quindi l’unico che possa valutare, come richiede GPR esposizione e rischio.

Data Processor

Ma allora chi o cosa cavolo è un data processor?

Il data Processor altri non è che chi materialmente si occupa delle attività di raccolta e processo dei dati. In quest’ottica, ad esempio, il data processor può essere sia l’operatore marketing che fa le interviste telefoniche e raccoglie i dati, che la struttura IT che gestisce la struttura informatiche che questi dati manipola e gestisce seguendo le istruzioni impartite dal Data Controller..

Mentre il Data controller è una funzione aziendale interna, il data processor può essere anche una entità esterna. è il caso di servizi offerti da terzi: dai cloud providers, alle agenzie di marketing la variabilità dei data processor dipende da come i dati ed il business è stato disegnato ed implementato.

Essendo il Data controller chi decide quale sia il livello di rischio accettabile e quindi le opportune misure di mitigazione il processo di implementazione del GDPR non può partire dai data processor che invece sono le funzioni “implementative”.

Per esemplificare al data controller spetta la definizione dei parametri di business e il livello di rischio accettabile. questo comporta assumersi la responsabilità di come i dati vengono raccolti, gestiti e protetti.

Al Data processor invece spetta l’implementazione operativa delle misure di sicurezza richieste dal Data controller e le operazioni generiche di gestione dei dati.

Insomma il GDPR non dice che devi usare encryption, ma dice che spetta al Data Controller decidere se questa sia una misura adatta a proteggere le libertà individuali associate an un non corretto uso dei dati raccolti in funzione degli imperativi di business.

ovviamente il Data Controller è libero di andare dalle funzioni IT per chiedere:

1. si può fare?
2. quanto costa?

ma non spetta all’IT decidere in seno alla implementazione o meno della misura.

Altri aspetti del GDPR richiedono attività che coinvolgono un corretto disegno della struttura manageriale e di reporting che sono di delicata implementazione vista la storica sclerosi delle strutture manageriali italiane storicamente avverse a qualsiasi cambiamento. ma questo è un punto su cui il GDOR non transige, pur non dando indicazioni specifiche richiede l’esplicita responsabilità aziendale nei confronti della implementazione del dettato di legge. alcuni vincoli tuttavia sono esplicitati in termini di legislazione locale anche in italia, ad esempio come si sta definendo la figura del DPO che, è chiaro dal dettato del GDPR, non ha responsabilità diretta sulla implementazione del GDPR che rimane in toto al data controller, e che deve avere il garantito livello di autonomia ed indipendenza dalle altre funzioni aziendali (il che taglia fuori, ad esempio, it managers, sales managers o ruoli simili).

L’inversione dell’onere della prova

Un aspetto probabilmente non ancora ben digerito della nuova normativa è il concetto sottointeso di inversione dell’onere della prova.

Spetta al Data controller dimostrare di essere compliant al GDPR in caso di controlli e o di incidenti.

in altre parole:

sei colpevole se non dimostri la tua innocenza

Questo significa che gli obblighi indicati dal GDPR non sono formali ma sostanziali, e la loro implementazione deve essere formalmente dimostrabile, altrimenti, indipendentemente che ci si sia comportati bene o meno, si è formalmente e sostanzialmente non conformi e quindi perseguibili a termini della normativa.

Insomma non possiamo “ciurlare nel manico” più di tanto, ma siamo obbligati a mettere in piedi processi dimostrabili in maniera chiara, attraverso documentazione, reporting, funzioni aziendali correttamente definite.