Happy Holidays

Where have we been?

For quite a long time I have not written anything here and I am truly sorry, but it is holiday seasons so let me wish you all a Merry Christmas, and a wonderful New Year.

merry christmas and happy new year in your language

Related articles

• Wavves – “Christmas Time Is Here” (Vince Guaraldi Cover)
• LED it glow! Ho-Ho-Homes lit up for Christmas, in pictures
• NAN Chapel holds maiden Christmas Carol
• 23 spectacular Christmas gift ideas for travellers
• These are the most in demand Christmas toys from the last 30 years (34 Photos)
• 5 Awesome Charities That Accept Toy Donations

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: la vedi la luce in fondo al tunnel? … è il treno!

Vi rendete conto che alla attivazione del GDPR manca meno di un anno vero?

la vedi la luce in fondo al tunnel? … è il treno!

Allora ho provato un paio di giorni fa a spiegarti come leggere ed interpretare il significato di GDPR. Sono assolutamente certo e sicuro che tutto quanto scritto era già chiarissimo ai tuoi occhi, ma tant’è… provare a parlare amabilmente di un argomento tanto ameno non fa mai male.

Dicevo, in chiusura degli sproloqui nell’articolo precedente, che alcune note andavano premesse per meglio capire il testo.

In effetti se partiamo con il piede giusto magari non diventa una lettura amena, ma almeno comprensibile.

Tra le premesse della volta scorsa ne ho omesso volutamente una importantissima, giusto per darmi una scusa per proseguire a scrivere…

Le norme fissate dal GDPR sono il minimo livello di protezione

Le norme fissate dal GDPR sono il minimo livello di protezione richiesta dalla UE, questo significa che ogni stato membro può decidere norme più protettive che si accompagnino al testo.

In Italia l’esempio che balza subito agli occhi riguarda la gestione dei biscotti…er “…cookie” che da sola potrebbe generare una interessante sequenza di noiosissimi articoli ?

La premessa è necessaria non perché abbia qualcosa contro gli Oreo (anche se preferisco i Krumiri o i cantucci toscani) ma perché il primo capitolo di questo affascinante romanzo che ci accingiamo a leggere è le disposizioni generali.

Il documento è diviso in 99 articoli sparsi in 11 capitoli che contengono diverse sezioni. Ovviamente per poter venirne a capo occorre leggerli in maniera “dinamica” perché spesso ci sono referenze avanti e indietro, a destra e a sinistra, sopra sotto e anche in un altro paio di dimensioni a noi invisibili ma chiaramente descritte dalla teoria unificata delle stringhe di cui vi invito a prendere conoscenza (a meno che non indossiate mocassini, sandali e o ciabatte, cosa che vi preclude gran parte della conoscenza umana) …

Per venirne a capo vi giro due link utili:

https://www.suiteprivacy.it/pages/testoregolamentoue.aspx (in italiano)

https://www.privacy-regulation.eu/en/index.htm (in un sacco di lingue tra cui l’italiano, ma ho messo la referenza in inglese perché fa più professionale…vuoi mettere…)

Capitolo Primo

Era una notte buia e tempestosa

 

Il primo capitolo inizia con l’emozionante articolo 1 che ci racconta di cosa si parla nel testo:

Articolo 1

1. This Regulation lays down rules relating to the protection of natural persons with regard to the processing of personal data and rules relating to the free movement of personal data.
2. This Regulation protects fundamental rights and freedoms of natural persons and in particular their right to the protection of personal data.
3. The free movement of personal data within the Union shall be neither restricted nor prohibited for reasons connected with the protection of natural persons with regard to the processing of personal data.

 

Lo so che in inglese è più sexy, ma se proprio vi difetta la lingua eccolo in linguaggio italico:

 

1. Il presente regolamento stabilisce norme relative alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché norme relative alla libera circolazione di tali dati.

2. Il presente regolamento protegge i diritti e le libertà fondamentali delle persone fisiche, in particolare il diritto alla protezione dei dati personali.

3. La libera circolazione dei dati personali nell’Unione non può essere limitata né vietata per motivi attinenti alla protezione delle persone fisiche con riguardo al trattamento dei dati personali.

Dalla lettura impariamo innanzi tutto che al punto 1 stiamo parlando di persone fisiche in relazione ai dati personali.

La cosa è importante per 2 motivi:

a: le persone giuridiche, le aziende, non sono soggette al GDPR…che tradotto vuol dire che il mio nome e cognome ed il mio indirizzo di casa sono GDPR, il nome della società “Pizza & Fichi INC.” e la sua sede legale non sono oggetto di GDPR

ci può venire incontro alla comprensione il “recital 14” che cita:

(14) È opportuno che la protezione prevista dal presente regolamento si applichi alle persone fisiche, a prescindere dalla nazionalità o dal luogo di residenza, in relazione al trattamento dei loro dati personali. Il presente regolamento non disciplina il trattamento dei dati personali relativi a persone giuridiche, in particolare imprese dotate di personalità giuridica, compresi il nome e la forma della persona giuridica e i suoi dati di contatto.

b: i fantasmi, i personaggi storici e quelli di fantasia non sono soggetto al GDPR (quindi potete condividere liberamente il numero di telefono di Wonder Woman).

Se vogliamo meglio definire cosa significhi il concetto di protezione citato nel punto ci viene incontro il “recital” 1

(1) La protezione delle persone fisiche con riguardo al trattamento dei dati di carattere personale è un diritto fondamentale. L’articolo 8, paragrafo 1, della Carta dei diritti fondamentali dell’Unione europea («Carta») e l’articolo 16, paragrafo 1, del trattato sul funzionamento dell’Unione europea («TFUE») stabiliscono che ogni persona ha diritto alla protezione dei dati di carattere personale che la riguardano.

Al punto 2 troviamo invece l’oggetto di questo esercizio, la protezione delle libertà individuali con il focus sui dati personali.

Il secondo punto è importante perché definisce chiaramente quale ambito va considerato quando consideriamo un rischio all’interno del GDPR.

L’oggetto del regolamento è la protezione dei diritti fondamentali dell’individuo, questo significa che questo è il parametro di rischio da valutare quando si considerano le implementazioni del GDPR …

L’ultimo punto ci ricorda che all’interno della Unione Europea abbiamo conquistato il diritto alla libera circolazione delle persone, delle merci e anche dei dati. Chiaro che se non vi siete mai mossi da Vigevano potreste non apprezzare la cosa, ma tant’è …

Chiaro che se non vi siete mai mossi da Vigevano potreste non apprezzare la cosa, ma tant’è …

Come referenza vi suggerisco anche di leggervi i seguenti “recitals”:

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13

Articolo 2

 

L’articolo due ci porta in un viaggio esotico in lande inesplorate, ove una brezza leggera ci accarezza e le onde del mare….

Er..credo di essermi un attimo lasciato trasportare, morfeo mi ha catturato… torniamo alla cruda realtà.

L’articolo due ci dice dove viene applicato sto benedetto GDPR.

Il punto uno ci dice dove si applica, gli altri punti dove non si applica.

Ovviamente ci interessa il primo punto…

1. Il presente regolamento si applica al trattamento interamente o parzialmente automatizzato di dati personali e al trattamento non automatizzato di dati personali contenuti in un archivio o destinati a figurarvi.

Si perché questo punto è fondamentale per capire l’ambito di applicazione, al solito iniziamo dalle parole per vedere se ne traiamo un senso …

Trattamento (Processing)

L’espressione generica indica che si ha a che fare con qualsiasi forma di trattamento eo manipolazione dei dati. Raccolta, archiviazione e lettura rientrano in questa descrizione…. Insomma qualsiasi cosa …

interamente automatizzato

Tradotto vuol dire tutti i sistemi che non richiedono intervento umano alcuno. Si pensi alla raccolta di dati via web per, ad esempio, una newsletter o un sito di marketing. I processi anche se non richiedono intervento umano sono soggetti al GDPR

parzialmente automatizzato

Nel caso vi sia intervento umano (ad esempio raccogli moduli scritti e li immetti in un sistema) il GDPR va comunque applicato. La norma prevede anche la parte umana di gestione, qualsiasi sia la forma. Anche il cartaceo è soggetto a GDPR.

non automatizzato

E qui ci casca l’asino …nel senso che se non lo hai ancora capito anche i tuoi documenti cartacei vanno considerati qui, non ci si scappa. Quindi non è che se pensi d fare il furbo e scrivi tutto su un block notes sei al sicuro…

archivio (originale Filing System)

Non facciamoci ingannare dalla terminologia. La traduzione archivio qui deriva da “Filing System” e non File System. Non parliamo di archiviazione digitale, ma di archiviazione tout court. C’hai presente i bei faldoni che lasci accessibili a chiunque…non puoi più farlo.

Insomma il regolamento si occupa della gestione e processo dei dati personali in qualunque loro forma indipendentemente dalla modalità di processo, archiviazione o raccolta.

Vi lascio l’emozionante esercizio di capire dove non si applica, io già ho faticato su questo.

E non dimenticativi i “recitals” per capire di cosa si parla: 14, 15, 16, 17, 18, 19, 20, 21

Ciaooo

 

 

 

 

Privacy Shield just born already dead

The new move coming from the other side of the Ocean (and yes I mean the USA) is aligned with Mr. Trump approach to international agreements.

After the Paris climate agreement, Donald Trump’s presidency is shining again in its confrontation with old Europe.

The target now is the Privacy Shield Agreement, the agreement that has been reached between the USA and EU in order to protect the privacy of EU citizens whose data are collected by the USA company.

It should not comes out as a surprise, historically the two sides of the ocean have had a deep different approach to personal data protection.

Now according to section 14 of the just signed Trump’s executive order “Executive Order on Public Safety”, USA law enforcement agencies have to explicitly strip out from their privacy policies all non-US citizen and Resident.

In other words, no protection is assured to the data associated with EU citizens stored in USA datacenters.

Under the Privacy Shield, EU citizens have rights to redress – including judicial redress – for improper disclosure of their data. The Judicial Redress Act (JRA) of 2015, which extended to EU citizens the protections of the Privacy Act of 1974, was critical to European acceptance of the Privacy Shield.

Last month, with a stroke of the pen that could unsettle EU privacy watchdogs, President Trump issued an executive order directing that federal agencies craft their privacy policies to exclude non-US citizens from Privacy Act protections.

This clearly broke the Privacy Shield agreement. For the few of you that remember the story, this agreement comes out after the crashing of the previous safe harbor agreement.

Safe Harbor was declared ineffective by the European supreme court of justice after the Prism activity from the USA government was exposed. Now while Europe is moving towards GDPR adoption and a strict set of rules in order to protect the privacy of EU citizens and residents, the USA has loosened once again the rules exposing, as a matter of fact, EU citizen’s data to risk.

Considering the amount of data (from Facebook to Google, from Microsoft to Apple) that are under this protection act the magnitude of this is enormous, basically this unilateral USA decision put at stake most of the digital economy.

And just to be clear Privacy Shield was not perfect even from a European point of view: in September, an advocacy group known as Digital Rights Ireland asked the second-highest European Court to annul the agreement on the grounds that it doesn’t provide enough privacy protection for EU data. Shortly thereafter, a French civil liberties group filed a similar suit. So the new Trump administration moves hardly will encounter an easy acceptance in the EU.

Now to be fair the impact of the new Executive Order against the Privacy Shield is not clear, someone in Trump administration is suggesting that eventual access to EU citizen data would be not due to mass surveillance and therefore the agreement is not in jeopardy, but considering precedents and the current relationships between USA and EU those sound more like empty words to address the internal USA electoral base (see us EU fault, we’re doing right) than a clear and honest analysis.

Some legal experts, however, have downplayed that concern by pointing out that the order seems to include an exception for Privacy Shield. But given the recent skittishness of European regulators about U.S. surveillance, calls are mounting for the White House to publicly reassure Europeans the order doesn’t affect their data.

We will see what will happen.

For sure the distance between the USA and the EU has not been bigger, and at the moment (but I am on the EU side) we are on the side to protect our planet from climate change, protect privacy and freedom of citizens from unwanted access.

Dataprotection #EU-U.S. #Privacy Shield  #TrumpPrivacyAct #GDPR

Guida al GDPR per chi non ne vuol sapere: e se provate a leggerlo il GDPR vi cala la palpebra?

 

Domanda: Che vuol dire GDPR?

 

Se otteniamo questo tipo di risposte:

• Grandiosa Donazione Per Riluttanti?
• Geniale Dono Per Repubblicani?
• Generosa Dotazione Per Remittenti?
• …

Allora abbiamo un piccolo problemino.

 

GDPR significa

General Data Protection Regulation

 

Allora proviamo a capirci:

almeno cosa significhi l’acronimo (che non richiede acredine nella lettura) dovrebbe essere assodato.

Insomma, ma lo avete sfogliato?

Se davvero volete implementarlo sto benedetto GDPR dovreste almeno provare a leggerlo, ma, vi assicuro, è una lettura non proprio amena.

Mettiamola così, se riuscite a non addormentarvi dopo la prima pagina siete già a buon punto, ma dopo averlo letto senza abbandonarvi tra le braccia di Morfeo (no non è il nome di un immigrato), viene il compito difficile: capirlo.

E si perché oltre ad essere una lettura non proprio divertente occorre anche capire che cavolo significhi tutta quella roba scritta in un legalese europeo.

Vediamo se ancora una volta, nel mio piccolo, riesco a darti una mano.

Iniziamo dal titolo:

General Data Protection Regulation.

General

Indica che si tratta di qualcosa di comprensivo, non nel senso che vi capisce, ma nel senso che comprende un sacco di cose.

Data

Ben lungi dall’essere Data il “robot umanoide” che in Start Trek Next Generation fungeva da ufficiale scientifico al servizio del comandante Picard, qui per data si intende, semplicemente, “i dati”.

Protection

Qui il termine fa riferimento alla protezione in senso lato delle risorse citate al termine precedente.

Il che significa che, utilizzando quanto appreso fino ad ora, stiamo parlando di un qualcosa che parla in maniera comprensiva della protezione dei dati.

Regulation

L’ultimo termine è Regulation. Questo termine merita un attimo più di attenzione, dal momento che è un termine specifico.

Directive Vs. Regulation

Ovviamente da buoni cittadini europei avete ben chiara la differenza tra Directive e Regulation. Fa parte della base minima di conoscenza civica che ognuno di noi dovrebbe avere (sono buono, non vi chiedo la differenza tra legge quadro e decreto legislativo).

Siccome io sono malfidente per definizione, mi permetto di supporre che non tutti abbiano chiaro la differenza tra “Directive” e “Regulation” e quindi provo a spiegarla.

Chiedo già scusa a giudici ed avvocati, legulei assortiti e giuristi vari per il linguaggio non proprio tecnico, ma lo scopo che mi propongo è quello di far capire le cose, non scrivere in “gergo” diventa quindi un obbligo.

Regulation

Quando ci troviamo di fronte a questa roba ci troviamo di fronte a una “legge” Europea che diventa parte integrante delle leggi di tutti gli stati membri.

In presenza di una “Regulation” gli stati membri non sono chiamati a legiferare. Il testo così come è (eventualmente tradotto nella lingua del paese) diventa parte integrante del suo corpo giuridico. Questo significa che vincoli, multe, azioni e altre cose alla legge collegate indicate nel testo sono immediatamente attuate nel momento in cui la “Regulation” diventa “attiva”

Come a dire dal 25 Maggio 2018 ti potresti aspettare un controllo e se non in regola ti potresti vedere comminata una multa pari al 4% del tuo giro d’affari… io ci starei attento…

Directive

Se la Regulation è un atto legislativo che entra immediatamente nel corpo giuridico del paese “cosi come è”, una direttiva (come quella che era in vigore prima del GDPR, la “Directive 95/46/EC” del 1995) è invece uno strumento tramite cui la UE setta gli obiettivi che ogni stato deve implementare attraverso la introduzione di leggi locali che devono regolare la materia in oggetto della “Directive”

La principale differenza tra le due è che in caso di “Regulation” tutti i paesi membri dell’UE si trovano di fronte ad una legislazione omogenea in termini di obiettivi, adempimenti e struttura, mentre nel caso della “Directive” è dato al singolo stato la potestà legislativa per legiferare in merito agli obiettivi definiti. Va da se che, anche se alla fine l’obiettivo deve essere raggiunto in maniera il più possibile omogenea tra i vari membri, la reale modalità di raggiungimento può variare sensibilmente da stato a stato in caso di “Directive”.

Il fatto che una “Regulation” entri in vigore cosi come è stata emanata dagli organismi UE non significa, in realtà, che lo stato che la applica non deve legiferare in alcun modo…alcune attività accessorie possono essere richieste per adeguare il corpus legislativo alla “Regulation” in maniera che questa sia applicabile. Attenzione che questo potrebbe erroneamente portare a pensare che la “Regulation” non sia quindi in vigore, sbagliato… funziona anche se ne mancano i pezzi accessori, non si scappa questa parte il prossimo anno volenti o nolenti.

Fatto questo doveroso cappellino introduttivo siamo ora in grado di leggere il titolo.

GDPR significa:

 

Legge EU comprensiva e vincolante sulla protezione dei dati

Bene abbiamo passato il primo scoglio nella lettura del documento. Adesso manca tutto il resto, ma si sa chi ben comincia è a metà dell’opera.

GDPR un po di chiarimenti prima di leggere

Visto che siamo riusciti a leggere il titolo (bravi bravi) è meglio fissarci in testa un paio di cose prima di proseguire la lettura, giusto per essere in grado di interpretare quel misterioso testo.

• se non lo sai sallo

la prima cosa che dobbiamo metterci in testa è che il testo non è scritto per novizi o principianti, sta a noi andare a recuperare e capire le referenze nel testo. una cosa importante è ricordarsi che il GDPR è l’evoluzione della direttiva sulla privacy del 95, e quindi dobbiamo aspettarci almeno una somiglianza nella nomenclatura ed alcune assunzioni del tipo…questo è evidente era già presente nella legislazione precedente.

• non aspettarti il dettaglio tecnico

NOn troverete nel testo un dettaglio o un manuale di istruzioni modello Ikea. purtroppo la norma va interpretata, molti dei riferimenti fatti in merito alle implementazioni IT ad esempio parlano di misure “adeguate” senza il dettaglio che vorresti vedere. Temo che questo significhi che tu hai una certa responsabilità implementativa che richiede anche di fare scelte consapevoli ed informate. Intendiamoci la cosa è voluta per rendere la norma attuabile ad un mondo tecnologico in continua evoluzione. Ma non pensare per un momento che questa indeterminatezza ti autorizzi ad usare sistemi operativi obsoleti tipo Windows Millenium o robe del genere, fallo e poi prova a dimostrare che hai messo in piedi misure “ragionevoli” di protezione.

• Anche se sei piccolo devi seguire le regole

Non importa quale che sia la tua dimensione, le regole vanno seguite da tutti. Ognuno avrà l’obbligo di implementare le misure adatte in maniera “ragionevole” e confacente alle proprie possibilità. tradotto questo significa che non puoi fare finta di niente e relegare, ad esempio, l’it ad un retropensiero… sempio: i backup li devi fare e devono funzionare e lo devi poter provare…preparati.

• Vale ‘inversione dell’onere della prova: sei colpevole fino a che non provi la tua innocenza

Ebbene secondo il GDPR sei tu che devi dimostrare di essere allineato ai dettami di legge. Il non essere in grado di farlo è già di per sé una ammissione di colpa. Chi ti viene a controllare (il garante in Italia? vedremo) ti chiede di dimostrargli che hai fatto le cose bene, non è li che deve cercare il fatto che non lo hai fatto. Questo è esplicitamente detto nel testo e più volte rinforzato come quando si specifica chiaramente che il rischio residuo se troppo grande deve essere concordato con l’autorità di riferimento.

• Il rischio di cui ti devi preoccupare è al di fuori della azienda, questo cambia i parametri della valutazione.

Quando nel testo si parla di rischio deve essere chiaro che il rischio è che si danneggi la libertà dell’individuo a cui i dati sono correlati. in altre parole non devi valutare solo quanto sia facile che ti buchino la rete o ti rubino i faldoni con i dati, ma anche che può accedere se quei dati vengono usati male nei confronti del soggetto a cui sono riferiti.

• Le multe non sono una per tutto, sono multe su punti specifici. E rimane poi il danno arrecato a terzi

qui mi sembra che molti non abbiano chiaro il fatto che la struttura delle multe del GDPR non ti garantisce di prenderne solo una che copra tutte le inadempienze. Rischi di beccartene piu di una se sei una multinazionale o se sei beccato con le mani nella marmellata in più aree… ed in ogni caso le multe fanno riferimento alla non attuazione della normativa, ma non coprono i danni procurati alle persone a cui i dati sono riferiti, e le eventuali cause civili eo penali associate.

• I soggetti non sono solo i tuoi clienti

Il GDPR fa riferimento ai cittadini e residenti in UE. in questa categoria rientrano non solo i tuoi clienti,ma i tuoi contatti di marketing, i tuoi fornitori ed anche i tuoi dipendenti.

 

beh che dite abbiamo fatto abbastanza premesse? se si buona lettura:

http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679

ciaooooo

a

 

Related articles

• UK firms ‘failing to prepare’ for regulation changes after Brexit (telegraph.co.uk)
• EU Proposals Could Force Vendors to Release Stored Data (cmswire.com)
• Queen’s Speech: Here Are The Government’s Tech Plans For The Next Two Years (gizmodo.co.uk)
• GDPR: Are you prepared? (helpnetsecurity.com)
• Low GDPR preparedness represents revenue threat (helpnetsecurity.com)
• GDPR and the technology market | The Puchi Herald Magazine (thepuchiherald.com)
• Are you ready for the EU GDPR? (helpnetsecurity.com)

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.

 

 

 

 

hit by "wannacry" (may be you deserve it) ...

Guys

Again a ransomware outbreak on the news.

May I say I am not surprised at all?

And may I say that the media coverage has been ridiculous and instead of presenting the event as something that should highlight the incompetent behaviour of managers targeted by this issue they claims about “cyberattack” which is a completely different thing.

And yet people asking why? how come? how this can be possible? again really?

We know that CyberSecurity is always a side though from most of the management no matter where. The proof, beside the claims from CEO, IT Managers and generally speaking CxO, is always there, on the data of the malware spreading.

Today is wannacry (wannacryptor or whatever you want to call it), tomorrow will be something else.

 

But for once let us try to be serious on those stuff….

First dig it a little on the specific here:

https://securityintelligence.com/wannacry-ransomware-spreads-across-the-globe-makes-organizations-wanna-cry-about-microsoft-vulnerability/

not ask ourselves a few questions.

Why Ransomware Strike?

ransomware are becoming increasingly common. The spread is due to 3 main reasons:

1. a ransomware is a damn easy peace of code to write, because it leverage the read, write and modify rights to access files so does need any Rocket Science behind to make damage.
2. the cryptocurrency gave to ransomware what was needed, the possibility to monetize the attack in a fairly secure way. Before bitcoin and co was quite difficult to make money transfers without being caught…
3. the security level of the IT in the world is still at the caveman age surrounded and filled by incompetence and a great deal of stupidity.

Let us be clear, the patch to close the vulnerability used by this last piece of ransomware was available since a few… but it is quite interesting to notice how, as of now, patching is still considered a minor activity in many IT infrastructures.

Who is responsible of this situation? Of course of a higher management blind and irresponsible that does not even think for a moment (till it is too late) that nowadays we all depend of our digital infrastructure.

the infection start with a mail or a usb infected key…. really?

How long we will avoid to train properly our workforce to teach them how to deal with email and attachment?

the infection leveraged a vulnerability on windows that were already covered by a patch from Microsoft… really?

How long we will consider patching the systems a useless activity or, at least, a minor one?

Sad truth sometimes would be easy to protect from those outbreak just simply implementing a minimum sound IT system, good backup policies, good patch management and … but we are telling those things since the very beginning of time.

The whole point is that till we will not manage the security aspects of our digital infrastructure in a serious and comprehensive way we will be exposed to this spread of junk again and again. And the more we rely on computers and digital infrastructure the more we will become targets.

So when you ask yourself who is to blame for this or other outbreaks, who is behind this worldwide attack?

 

Blame our stupidity.

Next could be worse.

 

 

Related articles

• NSA tools at center of ransomware attacks hitting UK hospitals: report (mashable.com)
• Researcher finds ‘kill switch’ for cyberattack ransomeware (japantimes.co.jp)
• Telefonica WannaCry Ransomware: One Of Spain’s Largest Telecom Companies Hit By Cyberattack (ibtimes.com)
• Intuit Confirms Information Requests From Government (turbotax.intuit.com)
• Intuit’s Fight Against Tax Fraud (turbotax.intuit.com)
• Ransomware based on leaked NSA tools spreads to dozens of countries (techcrunch.com)
• 38% of consumers affected by ransomware pay up (helpnetsecurity.com)
• WannaCry Ransomware: Webroot protects you. (webroot.com)
• British 22-year-old jumped around in excitement after finding way to stop global cyber attack (telegraph.co.uk)
• How to protect yourself from ransomware (telegraph.co.uk)

It is time for research to think about security and privacy

We usually talk about cyber security and privacy related to the world of industry and personal, but today I would make some points related to research in universities.

how much security aware are universities?

This is an interesting topics, looking at the statistics on cyber security attacks I would say security and privacy awareness is not at the first point in their needs.

So bad …

well first of all let’s make a little distinction:

engineering vs the rest

it is out of doubt that engineering universities and research are more cyber security savvy than the rest. Some of them are also actively working and studying the the issue.

but nevertheless the overall cyber security and privacy approach, beside the ones actively working on the subject, is poorly implemented. on the other end engineering universities are full of guys playing with the fire … some will be the defenders of tomorrow, some are the hacker of today (hacker is not necessarily a bad term).

the rest is in a questionable situation, both cyber security and privacy lack of vision and willingness to address the point. even if there are areas that deal with very sensitive data, think healthcare industry.

the result is under our nose, a lot of people with great skills and knowledge on a lot of different subject completely unaware of the consequences of digitalization…. why do you think is so easy to break into healthcare systems, law firms and so on?….

The research issue

there was a time where being a scientist was putting your life at stake, was not easy to be Galileo Galilei at his time. But I hope that anyone with a brain can agree on the fact that science was mandatory to develop our society and way of life.  Science play an important role on human development, and I took science with the largest meaning…not only technology or physics, but medicine,  economy, social science, history, literature, philosophy … in a way culture … the connection and ramification of science with art, as an example, are undeniable… so we should ask ourselves if there can be a world without science.

But science is based on theories more than faith, trials more than prayers, and therefore need a solid trusted based …

the trust is no more here

In this security and privacy unaware environment seldom researchers that are not security focused put attention to security, but nowadays research environment and criminal landscape and geo_political warfare would suggest a different approach. if some years ago the word of a scientist was respected, nowadays seems that politics take over science and data and result are not what they are, consequences of studies and trial, but things are what your political beliefs want it to be.

so we see a rising of “creationists” or other religious para-scientific accreditation as “scientific”, as well the denial of scientific evidence in the name of political or religious beliefs (think at global warming as an example).

When you start a research you need, basically, to start collecting and managing data, use some computational power, share those data with peers…. but those data, those exchanges are what we should take a look for also in terms of privacy and security.

Depending on the nature of the research you can have direct evident privacy and security implications, but even if you are working on not apparently key areas you should put some precautions on the table. Let quickly try to explain why:

data are important

Data are what you have to work on, you sample, collect, store, analyze, transform data.

In a trusted environment you can avoid to care too much, come on i trust you and you trust the others so what can be wrong… but this is no more the reality.

1. if your data have some kind of value (and i think they have, or you would not use them) you should protect them
2. if your data are needed to prove your point you should be able to ensure they are reliable
3. if your data need to be exchanged with others you should be sure what you transmit is what they get, and what you receive comes from a equally trusted source and data itself are trustable.
4. if you work worth something may be you want some intellectual property on it, and therefore you have to be sure your result are not repudiable, subject to copy or used and\or modified without your knowledge

those 4 points are the the main areas where you should put privacy and security into the equation no matter what your research is.

what is the value?

Every time you have to invest something you make a tradeoff between the invested monetary resources and the expected output. in science this is a hard exercise so i understand most of the time you do not want to look for data protection but try to think how much you depend on those data..

what happen to your research if a ransomware encrypt you data?

what happen if a attacker or a incident poison your data with some bias?

sometimes you can also be a “collateral damage” and not the direct target but, does it make any different to you?

if you are not able to put those consideration on the table you can start wonder what is the value of your job.

protecting means?

usually you set up things using what comes to your hands. this does not means crappy thing but…how much planning have you put on this?

have you considered what happens if you lost your data for a mechanical crash?

or for a hacking attempt?

of for a genuine honest mistake of your developer that write the code that manage your data?

or if your shared repository have to give space to something more important?

and what if someone tamper your data?

and what if someone copy your data?

and what if ….

this kind of scenarios are not your research field, I know, but nevertheless are connected to your job and you should start to consider them.

backup, storage, encryption, access management, Intellectual Property protection, data exchange, computational requirements… all those thing should be managed in a sound reliable plan that foresee current and future needs…

the problem of exchange

another aspect that is really critical is how you can be sure that the data you are exchanging are managed correctly.

the first point when there is an exchange between to point is to be able to trust the point itself. this basically means you want to exchange data with this subject, but may be not with another one (i know you are not all friendly one to the other).

so the point is how you can be sure you are sending the data to the correct source…

When you send something you should assure the counterpart that what he\she\it will receive is what you are sending, data should be managed in a non repudiation and anti tampering way, and also maintain the ownership if needed.

now they can be a genoma of a rock, a clinical trial result on the effect of mars over alopecia, a set of data on relationship between gun distribution and bird control rate, the climate data of the last 100 years in neverland…whatever… you need your data be recognized as:

1) yours

2) truthful even after the transfer

the point here is that otherwise anyone can change assumption and therefore conclusion making you part of a fraud. you should always be able to say, they those were not my data….

and in a moment where politics and science collide once again this is not a minor issue.

food for thought

privacy and cyber security are sons of the current expansion of the digitalization. Those issues are not a side tough but real component of your everyday job even if you are a researcher in areas way far from cyber security, information technology or whatever.

you should also start thinking if those data should be kept public how to maintain, store and allow access to them in a consistent and secure way. Sure you can post them on facebook and tweet them but maybe, just maybe, this would not be the optimal solution.

And you should start thinking about those things before it’s too late. no matter who you are, what you do digital life is here for you too and you should start acting accordingly.

just think about it.

Antonio

 

 

Related articles

• Carnegie Mellon privacy clinic aims to help protect you from hackers (triblive.com)
• Protect Your Company’s Data (coloradotech.edu)
• The Constitutional Right to Privacy (coloradotech.edu)
• Researchers Lambast Daily Mail’s Climate Change Article (blogs.discovermagazine.com)
• Scientists disprove global warming took a break (japantimes.co.jp)
• Sure, Nature Changes The Climate, But Not Nearly As Much As Humans Do (newsy.com)
• Demand for Cybersecurity Experts is Growing Faster than Supply (coloradotech.edu)
• US panel says research editing the human genome to cure disease may be acceptable (businessinsider.com)