Che lo vogliate o no… E’ arrivato il GDPR! (Parte 1)

Allora ci siamo.

Dal 14 Aprile 2016 finalmente è stato ratificato il nuovo Regolamento Europeo sul Data Protection (GDPR). E’ stata cosi laboriosa la gestazione e cosi estenuante il travaglio di parto che mi viene alla mente il Big One californiano. Il presunto mare e terremoto che tutti hanno aspettato dall’inizio del secolo dopo quello del 1906 e che non si è mai verificato ma tutti sanno che accadrà e affosserà nella crosta terrestre la California.
In effetti quello del 1989 non è stato una cosa da poco … ma torniamo a noi

PrivacyInCloud
Sono passati diversi decenni dalla Direttiva Europea del 1995; da lì in poi la Legge 675, il DM 318 del 1999 e infine il Dlg.vo 196/2003. In ognuno di questi passi si è cercato di normare seguendo le esigenze e le stringenze della evoluzione tecnologica.

Si è passati dall’era dei fax a 200dpi al Cloud Computing nell’era del BigData degli IoT e della CyberSecurity. In 20 anni quello che nella fisica è successo in un secolo passando da quella newtoniana a quella quantistica, dal pezzo di ferro agli ologrammi, dal mezzo trasmissivo di rame a wi-fi/GPS, dal codice su scheda perforata alle Apps che girano nello smatphone senza che neppure se ne abbia consapevolezza.

Eppure, nonostante questo salto dimensionale e funzionale globale, in fondo i principi ispiratori della Carta di Nizza, da cui la prima direttiva era derivata, sono gli stessi che troviamo oggi in questo nuovo GDPR.

In questo primo articolo riassumo schematicamente soltanto in modo preliminare, alcuni elementi rilevanti e dirompenti; come sempre è stato per le rubriche da noi curate, i contenuti di ogni singola tematica saranno approfonditi e aggiornati con gli specifici pubblicazioni. Non è concepibile esaurire le molte problematiche dell’esteso articolato della Riforma. Interi seminari e copiose pubblicazioni sarebbero necessari anche solo per uno dei molti argomenti influenzati dal GDPR; si pensi al mondo della Sanità e del fascicolo elettronico, alla Identificazione Univoca Digitale, al Data Retention, l’universo del Cyberspace e le veicolazioni di transazioni IoT, BlueTooth, WI-FI e i BYOD promiscui.

L’ordine con il quale commento non è da interpretare secondo priorità. Non esiste infatti un aspetto più critico di altri perchè non esiste un criterio unico per la miriade di attività produttive e di servizi che dovranno adeguarsi. Sia che abbiamo già un ottimo Sistema Privacy sia che comincino dalle fondamenta rischivendone uno isperato alla privacy By Default e By Design.

Ogni azienda ha una proprio situazione ICT, un campo di applicazione e una tipologia di trattamento dati diversa da qualunque altra. E’ la combinazione di molte variabili di impresa che determinerà il Sistema Data Protection Aziendale (SDPA), e la prima considerazione che ne discende è che non esiste un ciclostile per il Manuale del sistema di Data Protection (MDP); ma le persone serie sanno che anche prima con il Dlg.196/03 questo era vero.

REGOLAMENTO NON DIRETTIVA
Prima di tutto invito a riflettere che si tratta di un Regolamento e non di una Direttiva!
La più banale delle considerazioni di questo pertiene la sua applicabilità. In effetti le direttive sono nate con la Comunità Europea quando ancora il Parlamento e il Consiglio avevano compiti settoriali distinti.
La direttiva aveva tipicamente due anni di aspettativa prima di essere recepita dai paesi membri. Con ciò si intende che poi le singole legislazioni locali, intraprendevano un percorso legiferativo, ognuna con i propri iter parlamentari e tempi attuativi.

Il Regolamento è valido in tutti gli stati membri subito, nello stesso modo e allo stesso tempo. Semplicemente, sono previsti due anni dalla ratifica perchè diventino cogenti le sue prescrizioni; in sintesi, a fronte di controlli delle autorità e/o controversie legate agli adempimenti non conformi, si è esposti al sistema sanzionatorio.

UNIFICAZIONE E SOSTANZIALITA’
Essenzialmente il GDPR univica il mondo della Privacy (trattamento e protezione dei dati personali) con quello della Sicurezza Informatica (ICT-SEC). Questa messa a fattor comune di due ambiti intimamente correlati e mutuamente dipendenti è in realtà una cosa antica e ha vissuto negli ultimi due anni nella miriade di provvedimenti da parte della Autorità Garante, da Rodotà, Pizzetti e attualmente Soro, che ha sempre cercato di contenere l’enorma disattenzione e sprovvedutezza tipicamente italiane delle aziende tenute alla conformità e dei potenziali “interessati”, coloro che dovrebbero beneficiare della protezione dei dati personali.

Il termine Privacy non è più elettivo e si è diluito nella più grande accezione del termine Data Protection. In effetti la protezione è un concetto che implica Sicurezza (fisica, logica e di gestione), Confidenzialità, Continuità, Diritto all’Accesso, anti-contraffazione, non repudiabilità, Identificazione Digitale Univoca, Disponibilità, tutela dal furto di identità,

iftOgnuno di questi elementi è una disciplina per il quale sono scritti e saranno scritti volumi interi quindi il GDPR ha comportato uno sforzo enorme di armonizzazione e unificazione normativa, prescrittiva e multidisciplinare. Accanto a questo non ignoriamo la lunga attesa dovuta anche alle attività degli interessi lobbistici ma ne scrivo altrove.

Una seconda parola chiave è la Compliance che è collegabile a due standard internazionali ISO 19600 (l’approccio sistemico alle “obligation”) e la ultima ISO 9001 che comporta  il coinvolgimento degli stakeholder (il Regolamento è parte degli interessi) e l’analisi dei rischi (requisito innovativo del nuovo Regolamento formalizzato come modello di risk assessment e management assimilabile alla famiglia delle ISO 3100x).

Per l’ambito giuridico i cambiamenti sono molto evidenti, l’indirizzo è quello di una  responsabilità che coinvolge sempre di più l’organizzazione come soggetto (approccio della responsabilità “penale” dell’impresa presente stabilmente dal 2001 con il Dlg.231/01. L’ OdV (organismo di vigilanza) implicito nelle prescrizioni legali, recependo una logica della applicazione delle buone pratiche e quelle di riferimento ISO27001 e la BS 10012, dovrebbe altrettando implicitamente annoverare al suo interno la fidura del DPO introdotto dal GDPR (vedi avanti “La finta questione de DPO”).

THE VERY FIRST GLIMPSE
Il titolo di quest paragrafo è provocatoriamente in inglese, perchè si allude al fatto che già dalle prime traduzioni del testo GDPR originale (peraltro il primo in assoluto è in francese), si è avuta la sensazione che alcune porzioni, soprattutto quelle di carattere prescrittorio e legale, avressero quello che internazionalmente è noto come “missing in translation” e che qui in Italia chiamiamo “discrasia”. Detto in termini estremamente riassuntivi, ci sono alcuni articoli che per essere bene interpretati e attesi, è meglio siano studiati dall’inglese. Peraltro, in molti dei 28 paesi della UE, si adotta direttamente il testo della versione inglese (n.d.r.).

Globalmente considerata l’intera “faccenda” è diventata molto meno formale e più sostanziale! Con ciò si intende che sono finiti per sempre i tempi della Privacy comprata a chili di carta. Ispirata alle normazioni contrattuali volontarie, ISO e BSI per citare quelle internazionali storiche, il GDPR deve essere atteso, attuato e dimostrabile con fatti e non solamente qualche foglio di carta.

Quando il GAT (nucleo speciale della GdF) effettuasse una ispezione, ovvero in sede di controversia (denuncia di terzi alla Autorità), non è più sufficiente mostrare una generica informativa, qualche foglio firmato dai dipendenti e un presunto manuale di 10 pagine che ricorda più ad una Carta di Servizi nella home di un sito di una clinica privata.
Si dovrà avere una chiara distribuzione delle nomine e delle designazioni dei ruoli del SDPA, un credibile e pertinente documento di valutazione dei Rischi e degli Impatti (cosidetto Privacy Impact Analisys, PIA), Piano di informazione e formazione attuato, provabile e aggiornato, una politica di qualificazione delle forniture ICT a mezzo di SLA e PLA, un piano di Audit effettivo e comprovabile da terzi, se adottata la strutturazione e l’inquadramento di un Data Protection Officer (DPO), il Disciplinare interno con eventuali certificazioni del Data Center on Premise (ISO20000 per i servizi e ISO27001 per la sicurezza della infrastruttura dei Sistemi Informativi). Naturalmente citiamo a braccio, ma la lista sopra non è esaustiva!

 

NOTIFICAZIONE NO, ANZI SI
E’ vero ! Non esite più la prima Notificazione presso il Registro del Garante a Piazza Monte Citorio. Tuttavia, forse un onere più impegnativo, è previsto che una azienda si doti di un impianto strutturale (sia formale, che procedurale) per far fronte alla tempestiva Notificazione del cosidetto Data Breach.

In definitiva, la Notificazione storica è solo sostituita da quella per la Sicurezza Informatica e Telematica. In sintesi, le società devono dotarsi di un sistema di gestione delle evenienze avverse di danni informatici. Non tanto e solamente per prevenirli, quanto nella escalation di valutazione di un indicente informatico del quale devono entro una settimana avvisare l’Autorità di riferimento e tutti gli Interessati i cui dati sono stati (anche solo presumibilmente) coinvolti nell’incidente. Vediamo meglio nel caso parliamo di operatori del settore delle comunicazioni elettroniche e successivamente presente in diversi provvedimenti specifici riguardanti per esempio la biometria, la condivisione di banche dati particolarmente ampie tra soggetti pubblici, le tutele dei dati sanitari contenuti nel dossier sanitario elettronico.

Nel Regolamento Art. 32 Bis, si adotta il concetto di adempimenti conseguenti ad una violazione di dati personali che coinvolge in modo diretto anche i fornitori di servizi di comunicazione elettronica accessibili al pubblico; tutti hanno l’obbligo della comunicazione all’Autorità Garante di eventuali violazioni di dati personali da essi conservati. Laddove esista poi il pregiudizio ai dati personali o alla riservatezza di un contraente o di altra persona, questi dovranno essere avvisati dell’avvenuta violazione anche se solo per pregiudiziale nocumento.  Il “Provvedimento in materia di attuazione della disciplina sulla
comunicazione delle violazioni di dati personali” già indica :
a) un termine di 24 ore per fornire all’Autorità le prime sommarie informazioni con la possibilità di estendere a ulteriori 3 giorni l’integrazione di eventuali notizie utili;
b) l’istituzione di un registro in cui annotare le violazioni;
c) le modalità di compilazione del modulo di notifica formato da ben 17 punti.

Quindi  già dal 2015 anche le pubbliche amministrazioni che detengono banche dati di  grandi dimensioni a cui possono legittimamente accedere plurimi soggetti pubblici, devono comunicare al Garante, nelle 48 ore dalla conoscenza del fatto, le violazioni occorse ai dati  personali detenuti e gli incidenti informatici. Tutti gli altri hanno 72 ore.

TUTTO SCHIACCIATO E SEMPLIFICATO, FORSE…
Una delle parole chiave molto di moda non solo per la Privacy, ma anche per molti altri ambiti legislativi parlamentari è quella della “Semplificazione”. In effetti anche per il nuovo Regolamento, alcune semplificazioni possono essere identificate… Attenzione però, che non necessariamente una semplificazione rende più “semplice” l’attendere gli adempimenti. Ciò che sicuramente si è semplificato è lo stile di emanazione degli articolati che secondo la tendenza internazionale, mira non tanto alla legiferazioni dettagliate di “cosa” si può e di “come” si deve fare riferendosi a tabelle prescrittive definite; piuttosto, cosi come accade con le linee guida (Guide Lines), le norme di buona operatività (good practisies) e le pratiche dovute (due diligence) indicano le direttive di condotta e i criteri da soddisfare per conformarsi ai requisiti di legge e agli adempimenti sul campo.

Uno tra i molti aspetti precocemente riscontrabile di questa filosofia riguarda la semplificazione della gestione delle nomine e delle deleghe dei soggetti e dei ruoli all’interno di un SDPA. In un certo senso ci si emancipa verso una semplificazione della articolata gerarchia fatta di Titolari del Trattamento, Responsabili del trattamento (esterni nel caso di fornitori), gestori delle chiavi, amministratori di sistema (interni o esterni), operatori del trattamento verso due fondamentali soggetti : Data Controllers e Data Processors.etica
Non conviene pensare di tradurli, tanto nel manuale del SDP converrà citarli cosi anche inconsiderazione della internazionalizzazione delle procedure (vedi più avanti “Dove vanno i dati transfrontalieri ma soprattutto da dove vengono“)

Altra cosa che non conviene interpretare è che sia tutto quì. A parte il caso del DPO di cui parliamo dopo, comunque occorreranno gli Amministratori di Sistema come figure se stanti, ma, nel caso di una terzializzazione di servizi ICT (Es. Cloud SaaS, PaaS, Sec-aaS, Storage-aaS ecc.) diventano Joint-Controllers (precedenti co-titolari). Peraltro, un corretto inquadramento negoziale dell’istituto del Joint Controller
rispetto ai trattamenti condivisi, se non vissuto solamente come prescrizione legale per i gruppi di imprese, è una occasione per definire responsabilità specifiche sui dati, e potrebbe rappresentare un vantaggio competitivo strategico per le corporates.

La cosa rivoluzionaria è che in caso di controversia (denuncia di un Interessato), danno informatico ai dati o di breccia/intrusione ICT queste figure, siano esse interne alla organizzazione o società esterne saranno congiuntamente responsabili e perseguibili ai fini della comminazione di sanzioni.

Questa si che è una entusiasmante nuova prospettiva…

 

 

DOVE FINISCONO LE AUTORITA’ NAZIONALI?
Alle organizzazioni che trattano dati personali, di qualunque classe e dimensione, saranno concessi due anni per adeguarsi. Questa è la notizia più direttamente connessa con la domanda frequente posta dalle aziende che negli ultimi anni ha aspettato la Riforma Europea : ma che fine fanno le Autorità a livello Nazionale?

GDPRNonostante le profonde e storiche diversità tra gli Stati membri, in maniera idiosincratica l’Europa si appresta ad avere nuove norme ancora più uniformi in materia di circolazione dei dati personali e la concertazione tra autorità nazionali, come conferma anche il piano
d’azione per il 2016 annunciato ad inizio febbraio dall’art. 29 Working Party (WP29).
Il piano prevede, tra i vari punti, la costituzione di una task-force WP29- European Data Protection Board (organo di coordinamento delle autorità Garanti nazionali), nonché l’implementazione di sistemi informatici nell’ambito del c.d. One stop shop (sportello unico).

Molta importanza ha il ruolo che le Autorità locali avranno nel periodo di inter-regno di validità delle precedenti versioni nazionali fino al decorrere della cogenza vera e propria del nuovo European Regulation. Nel proprio Paese, le autorità avranno ampia facoltà di emanazione di provvedimenti e norme di interpretazione e applicazione dell’articolato nel GDPR. Ad esempio in merito agli obblighi distinti tra Pubblico e Privato nella nomina obbligatoria del DPO sulla base di trattamenti di dati particolarmente sensibili.

 

 

LA FINTA QUESTIONE DEL DPO
Quella del Data Protection Officer è una questione molto controversa e decisamente non chiara. Diversamente da molti altri adempimenti esplicitamente cogenti e mandatori, questo è stato discusso per anni. Più che per un problema di accountability, il DPO rappresenta un problema nel caso di trattamenti “particolari” (quelli che prima erano i dati sensibili) e nelle organizzazioni disseminate e dipartimentalizzate. Non è solo un risparmio economico, piuttosto la necessità di una competenza interdisciplinare e terza che in prima approssimazione ricorda il ruolo dell’ Auditor Interno e/o il Responsabile AQ di un Sistema di Qualità e Sicurezza in ambiente ISO.

turistaNella prima fase di elaborazione del GDPR, il DPO fu pensato come indispensabile, poi ci si è resi conto del fatto che questo Cristo deve conoscere tutte le normazioni europee, essere un esperto di leggi e di giurisprudenza (Es. Dlg231/01), essere certificato in almeno tre ambiti di Sicurezza Informatica (IT-ISO27001/ISO20000, Cyber Security e Risk Analysis NIST-CLUSIT, Cloud Computing – CSA/ENISA, Gestione di Processo – ITIL/CoBIT), essere un esperto certificato di progettazione e analisi dei rischi, deve essere esperto di docenza e formazione, deve essere terzo rispetto alla Proprietà aziendale più un’altra decina di expertise secondarie solo in ordine di excursus professionale per Sistemi di Qualità e Sicurezza.
Una simile profilazione individua qualcosa come 4 o 5 persone in tutta Italia, e se esistono si  tratta di persone che su LinkedIn troviamo felicemente accasate all’interno di una organizzazione. Difficilmente, passerebbero al mondo del libero professionismo per girare come trottole e guadagnare molto meno.
Insomma, l’adozione di un DPO è definita non mandatoria ma raccomandabile ed eventualmente figura giuridica esterna.

A livello di comunità europea (Parlamento, Consiglio e Commissione o Trilogo), per un certo periodo gli emendamenti controversi hanno riguardato i DPO e le discussioni sembravano orientate a rendere questa figura mandatoria in ragione della dimensione della organizzazione (tipo numero di dipendenti), ma è stato fatto notare di come alcune attività di agenzia (Per es.: Centrali di rischio o studi di investigazione ), seppure con pochi dipendenti può effettuare controlli estremamente critici e dannosi sui dati personali. Quindi ha preso piede la metrica basata sulla quantità di records detenuti. Ma anche  in questo senso si andava incontro a discriminazioni ed elusioni irragionevoli.

TrioPrivacyInsomma alla fine il DPO si è reso facoltativo a discrezione del Data Controller (principale nel caso di joint Controllers).

Di fatto un DPO potrebbe essere indispensabile per una azienda che habbia un Data Center intramurale (on premise), in quanto più efficace ed economico rispetto alla consulenza di una delle Big Four o di un lungo percorso certificativo che comunque non può garantire dalle prescrizioni legali. Si legga, non è che perchè abbiamo una certificazione ISO9001 significa che scongiuriamo le sanzioni del GDPR.

Il DPO è un finto problema perchè in realtà rappresenta un vantaggio competitivo per la società risolvendo e armonizzando ambiti legislativi, progettuali e di governo della Informatica e integrando gli obblighi delle normazioni di compliance.

 

MA QUANTO MI COSTA E COSA RISCHIO
Questa è la domanda che tutti noi consulenti ci sentiamo fare dai clienti. E va suddivisa su due voci di costo : quella del disegno, della progettazione e della implementazione di un nuovo SDPA e quella della esposizione nel caso di sanzione.

gatLa seconda preoccupazione è piuttosto banale da chiarire. Tutte le cifre precedenti sono più che raddoppiate. Sono cioè possibili multe milionarie in quanto si è inteso valutare la rilevanza del danno provocato più che la solita considerazione amministrativa (che peraltro non ha funzionato mai come terrorismo minatorio presso le società). Per un senso di pudore dell lobby che hanno condizionato il Trilogo, si è concesso che nel caso delle multinazionali, a discrezione del giudice, per avere un conclamato effetto di deterrenza, si può arrivare dino al 4% dell’ultimo fatturato dichiarato a bilancio societario. E’ cioè sensibilizzata anche la multi-nazionale ala quale pagare qualche migliaia di Euro non cambia molto.

Forse perchè consulente, penso al mio primo Disciplinare Tecnico e DPS nel 1998 per una Clinica Privata nelle campagnie del Piacentino, mi concentro sui costi di realizzazione di un Sistema di Data Protection aziendale (SDPA).
Come spiegato in incipit, un sistema privacy non è ciclostilabile, soprattutto perchè i controlli saranno orientati alle verifiche sui sistema ICT :  procedure di backup, misure di protezione perimetrale, formazione specifica per ogni ruolo, controllo delle forniture ICT, dove presente della compliance della impiantistica anti-intrusione e videosorveglianza per citare le prima a mente.

Ulteriore considerazione generale causale rispetto al precedente punto, il fatto che la tipologia di trattamenti (cartacei, digitali, DB distribuiti o pubblicati), la classe della dotazione informatica e delle piattaforme software utilizzate (LAN,WAN BladeSystem, virtualizzazione ecc), le finalità del trattamento (Legali, profilazione ecc.), il trasferimento e la condivisione con l’esterno dei dati (scambio transfrontaliero), l’ambito del processo di business (e-commerce, pubblicitario, assicurazioni, produzione, servizi ICT ecc.) rendono non plausibile pensare ad un lavoro uniforme e ripetitivo.

tuttofareChe sia nominato DPO o si conporti come fornitore di prestazione consulenziale, un professionista deve svolgere attività comparative e multi disciplinarie di GRC (Governance, Risk and Compliance management).

Quindi per esaurire in modo riassuntivo, il costo e la quantità di lavoro consulenziale e di affiancamento, se possibile è decuplicato rispetto ai precedenti Sistemi Privacy. E che non sembri paradossale, ma questo è dovuto proprio al fatto che non si chiede più di avere una postura formale cartacea, ma un effettiva e attuata pletora di procedure e istruzioni operative comprovate e comprovabili di Sicurezza Informatica. Come abbiamo visto sopra nel paragrafo della Notificazione, per rendere obbligatoria e non eludibile questo ultimo adempimento si è previsto un articolato specifico per il rispetto del provvedimento sul Data Breach. Era in realtà previsto da prima con il Dlg.196/03, ma ora è posto alla stregua della Informativa e del Consenso al trattamento.

 

L’ARTICOLO 17 E IL DIRITTO ALL’OBLIO
La questione tanto dibattuta del diritto all’oblio è apparentemente legata ad uno scontro ideologico della civiltà delle persone come individui nei confronti del cyberspace. In merito all’indiscutibile posizione che sia o meno giusto, esauriamo la discussione dicendo semplicemente che si tratta di una ipocrisia, vissuta in quella linee di confine mai definita tra l’esigenza della tutela del singolo e il diritto di sapere de molti.

Affrontiamo in vece secondo lo spirito molto pratico di questo articolo mirato a capire cosa operativamente comporta l’adozione del Data Protection.

E’ sempre esistito il diritto dell’interessato all’esercizio dell’Art. 7 del Dlg.196/03 per la richiesta di accesso ai propri dati, al loro aggiornamento… Adesso è del tutto esplicito che l’interessato (chiunque) possa rivolgersi ad una organizzazione richiedendo in qualunque momento la completa, definitiva e retrospettica cancellazione dei dati che lo riguardano.

Chi sa’ cosa comporta la gestione di grandi repertori di DataBase, può incorrere in uno svenimento!!! Pensiamo cosa accadrebbe se tutti scrivessero ad una qualunque delle istituzioni pubbliche.

L’ARTICOLO 18 E IL DIRITTO ALLA PORTABILITA’

Non a caso dopo l’oblio (Art.17), troviamo l’articolo successivo relativo alla portabilità
Ci sarebbe un discorso molto articolato, soprattutto di natura giurisprudenziale, ma per farla breve e sempre coerenti con lo spirito riassuntivo di questa pubblicazione, una società deve approntare dimostrabili procedure che attestano come, a fronte della richiesta di cancellazione dagli archivi, è in grado di effettuarla dandone peraltro riscontro in tempi veloci ed in formati standardizzati fruibili secondo portabilità da un Interessato.
La esigenza di standardizzare formati fruibili in risposta alla richiesta di un interessato è finalizzata e finalizzabile alle esigenze di portabilità
Si intende con ciò la facoltà di conservare un proprio record di dati personali spostandolo da un repertorio ad un altro.

 

Nella migliore delle pochissime policies ufficialmente documentate, i grandi player danno la possibilità di esportare dei dati (CSV,XLM,ASCII o simile), ma con metriche di tracciato record del tutto arbitrarie… Quindi, come sempre è stato nell mondo dei DBs, gli oneri sono sempre dalla parte della struttura recipient. Che equivale a dire, tutti affari dell’ Interessato… Se vuole portarsi via i dati ne faccia quello che crede con chi gli pare.

Di questo, e molte altre cose, potremo solo etologicamente osservare la evoluzione ! Al momento nessuno sa’ cosa potrà realisticamente succedere perchè anche in un mondo come quello del Cloud Computing, di fatto la portabilità è pressocchè mitologia.

 

continua nella Parte 2

 

 

 

Annunci

Cosa c’entra la Block Chain con il GDPR?

La prima cosa necessaria da capire per affrontare la questione è che la Block Chain  (BC) non è il Bitcoin!

Si tratta di una metodologia di “hashing ricorsivo” (riassunto all’osso), che è precedente al Bitcoin, anche se alle monete elettroniche si deve la esplosione di notorietà dell’argomento.

GDPR

Essenzialmente la BC, che in Italia giustamente da molti viene associata funzionalmente al “libro mastro” mutuato al mondo della contabilità, permette informaticamente una “Notarizzazione“. Lo so, di per sé non è una bella parola, ma tecnologicamente ci sono parole in informatichese che rendono l’idea e anche il senso di cose complesse in modo essenziale.

Mai come in questi tempi, bisogna semplificare le cose ai Titolari del Trattamento! Diversamente non solo non “scuciono” una lira, ma soprattutto non comprendono loro stessi quali scelte corrette fare per le aziende che devono essere in compliance con il Reg.679/16 (il GDPR della UE).

Sono molte le attività che riguardano un Sistema di Privacy e Protezione dei Dati che possono beneficiare della BC. qui citiamo alcuni esempi basandoci non tanto su un ordine di fattibilità, quanto su un ordine di priorità di adempimenti che i TDT dovranno inevitabilmente considerare.

Primo fra tutti certamente il Registro dei Trattamenti (Art.30). Questo pilastro di un Sistema di Protezione dei Dati (SPD), che in questo contesto diamo per conosciuto, è una evidenza documentale (cartacea e/o elettronica) che comprova (Accountability by Design – Artt. 24 e 25) che dopo una Analisi dei Rischi ed eventuale Valutazione degli impatti Privacy, l’Azienda abbia classificato tutti i trattamenti di dati personali in base alle priorità di rischio cosi da individuare e pianificare un Piano di Adeguamento (misure e investimenti) per raggiungere la compliance di cui sopra.

ScolaroBravo

Purtroppo non è recepito correttamente, ma il Registro dei Trattamenti non è una cosa che si fa una volta! Si tratta di un sistema documentale vivo che deve essere manutenuto e sottoposto a controllo di misure organizzative (Procedure, prassi, registrazioni ecc.) 

 

Ecco dove viene utile un meccanismo di BC. Ogni trattamento definito nel Registro, può cambiare  in qualunque momento. Non solo in sè e per sè, ma anche semplicemente perché, ad esempio, cambia la tecnologia sw o degli apparati, cambiano le esigenze del cliente che in quel Trattamento è coinvolto, o ancora, e più semplicemente, cambia perché il soggetto autorizzato (ricordiamo che gli incaricati non esistono nel nuovo Regolamento) è stato licenziato.

 

Per il monitoraggio continuo dello “status” del Registro è indispensabile comprovare sia il time-stamp che la identità digitale del cambiamento e/o modifica. Solo così il Titolare potrà fronteggiare una eventuale ispezione della Autorità di Controllo (Dal 26 Maggio 2018 non esisterà più il Garante Privacy!)

Un’altro ambito estremamente critico per la coerenza di un SPD riguarda quello della gestione dei Log; anche se nella percezione comune questo sembra essere un problema che riguarda solo gli informatici, così non è.

I log traversano molti adempimenti, alcuni completamente nuovi. E’ questo il caso del Data Breach (Art.33). Non si tratta della installazione di un anti-virus e/o un firewall. Solo chi è rimasto alla medioevale e soporifera filosofia del DPS e delle misure minime, può crederlo.

Si tratta di un sistema completo di gestione per la resilienza continua nei confronti degli incidenti informatici. Anche in questo caso non ci sogniamo di dire oltre e rimandiamo agli altri nostri articoli, ma riallacciamo qui la BC che calza perfettamente.

Se la Azienda usa sistemi IDS/IPS o DLP (oltre alle misure procedurali previste dal Regolamento), tutte le attività di alerta e/o contromisure a difesa dei beni societari (non solo dati personali ma anche di business) devono essere “notarizzate” per poter essere valutate Ex Post dal gruppo di gestione degli incidenti. La BC assiste non solo gli informatici ma anche il Responsabile e il Titolare del Trattamento in caso di incidente informatico grazie alla ricostruzione esatta della time-line di tutti gli eventi monitorati dal sistema.

L’adempimento del “Data breach” prescrive che le Autorità di controllo siano informate tempestivamente ed esaurientemente. Occorre quindi, anche in questo caso, poter comprovare l’esattezza della sequemza degli accadimenti in modo terzo, oggettivo e sicuro… Ecco perchè marcare temporalmente (notarizzare) e in modo identificativo univoco i processi sottoposti a controllo, è l’unico sistema per non venir meno agli obblighi legali.

In sintesi abbiamo fatto due esempi di integrazione tra la block-chain e il GDPR, ma solo a scopo di paradigma potremmo considerare anche :

  1. nomine e designazioni organigramma privacy
  2. validazione censimenti infrastrutture IT
  3. validazione verbali di Piani di formazione
  4. governo proattivo di contromisure legittime su email e navigazione internet
  5. validazioni contrattuali SLA e PLA con Responsabili Esterni/Contitolari
  6. Data Transfer Agreements e accordi vincolanti di azienda 

 

E’ chiaro che non si potrà mai avere una Accountability vera senza una tracciabilità vera.

Chi scrive è perfettamente consapevole che questo articolo è diretto a chi il Regolamento deve aiutare ad applicarlo. Le aziende, sia a livello imprenditoriale che di staff non hanno consapevolezza di questo ordine di complessità!

Che dire, buon lavoro e buona privacy con i nostri webinars nel corso multimediale su youtube!

Per chi poi desidera approfondire il tema della Data Protection sul campo segnaliamo anche il primo sforzo editoriale pubblicato di un Fac Simile elettronico di un Manuale di Sistema Privacy cosi come reso fruibile via web Intralan aziendale

 

 

Salvo Reina

CaimansT22ore - Copia

Sicurezza IoT: e chi se ne frega 4.0!

Non sarà sfuggito agli amici del Blog, informatici, managers, imprenditori, Titolari del Trattamento ma anche folle di Interessati, che dal 2017, tutto ciò che accade è diventato “Qualcosa 4.0″
Nulla di cui scandalizzarsi per chi da decenni segue l’evoluzioni tecnologiche nei processi aziendali. Quello che è singolare che pochi fanno rilevare di come si sia passati dall’era 2.0 a quella 4.0. Dove e quando abbiamo maturato l’epoca del “tutto 3.0“?

L’internet degli oggetti (IoT), o meglio ancora “di ogni oggetto” (IoE) si impossesserà della vita umana che popola il globo. E ‘, e sarà, ovunque: controllo dell’illuminazione, distributori automatici, parcheggi, semafori, telemedicina, sicurezza domestica, bancario, contatori intelligenti, ecc, ecc  Chiedersi quali rischi comporta questo tzunami tecnologico è illusorio perché la maggior parte dei rischi ancora non sono neppure congetturabili.
Altrettanto ridicolo è chiedersi se o meno siamo pronti per un malfunzionamenti, violazioni della Privacy o arresti di sistemi e infrastrutture. La risposta è già conosciuta: assolutamente no!

Siamo disposti ad affrontare un paradigma fantascientifico con cacciaviti e martelli?
In Italia navighiamo nella palude di una “Cyber Ignorance” il cui approccio è quello del “e chi se ne frega?”
A parte le discussioni in circoli e convegni di esperti (o presunti tali), la consapevolezza pubblica semplicemente non esiste.

La ragione di questo è la cattiva abitudine di non studiare pro-attivamente l’evoluzione tecnologica IT mondiale, subendo il vassallaggio dei grandi players HW/SW incombenti  a scapito del terzo mondo tecnologico. A questo si aggiunge che pochi “artigiani dell’ IoT”, per quanto coraggiosi e illuminati, non possono trascinare le coscienze di un popolo e di Istituzioni che prestano attenzione alle “disastri informatici” solo quando visibilmente distruttivi. Quindi, quando sono oramai irrimediabili.

Gli specialisti ICT sanno del famoso caso Stuxnet, quando le agenzie USA/Israele hanno compromesso le apparecchiature nucleari iraniane dello SCADA, incorse poi in avaria. La realtà è che quell’incidente non è l’unico. Ci sono stati molti incidenti che per motivi di controllo della politica geo-tetica, non sono stati resi noti.
Mentre scriviamo, sono già stati comprovati difetti di sicurezza IOT nei prodotti di consumo, come giocattoli per bambini, monitor per bambini, automobili e pacemaker!
Tutti pensiamo al fatto che è giustificabile questa filiera di target perché si tratta di “end consumers”. Magari!

Alla fine di Ottobre 2016, Dyn®, un grande fornitore di infrastrutture Internet, ha subito un attacco DDoS ottenuto sfruttando malware su dispositivi IoT come webcam e stampanti collegate alla rete Dyn.

In sintesi estrema: NESSUNO E’ INDENNE!

Quando vediamo progetti con l’incorporazione di piattaforme proprietarie per IoT, leggiamo opuscoli di marketing e di vendita dicevano tipo

“Il nostro internet degli oggetti è sicuro” 

Parliamo di un fornitore del servizio universale del prodotto praticamente incontrollato e incontrollabile. Eppure, quando si fa un progetto reale si dovrebbero mettere in discussione le dichiarazioni di marketing e comprovare la QA con dovuta diligenza.

Cosa succederebbe se potessi rivolgere queste domande al product manager e al suo team:

  • Può mostrami in che modo i vostri prodotti sono sicuri?
    Come vengono identificati i dispositivi?
    Come vengono autenticati?
    Dove sono memorizzati un ID e/o il relativo certificato?
    ID e certificato sono in una locazione di memoria protetta e sicura del chip?
    Quale autorità rilascia questi certificati?
    Nel caso fossero proprietari, come sono coniati?
    Come posso recuperare dati critici di una sessione?
    Quale algoritmo di crittografia viene utilizzato?
    Il generatore di numeri casuali è probabilistico, deterministico o stocastico?
    Il dispositivo prevede un processo di revoca?

Nessun produttore risponderebbe. Anche peggio, di alcune delle domande sconoscerebbe anche il senso.

Se ripetessi l’esperimento con un Security Architect o un Pre-sales otterrei lo stesso risultato.
Sembra che nell’era dell Industry 4.0, dove tutto è “Open”, tutti, inesorabilmente ripetono lo stesso identico mantra:

il nostro prodotto è sicuro!

Tutti sanno ce le dichiarazioni di marketing sono pura finzione. Nella migliore delle ipotesi  qualche caratteristica di sicurezza del prodotto è effettivamente realizzata: ad esempio hanno utilizzato un collegamento TLS.
Il problema è che l’ IoT deve essere considerato un sistema e non un prodotto sé stante. In molti casi, l’IoT si potrebbe addirittura qualificare come un sistema di sistemi!

In questo scenario, la sicurezza del sistema è forte quanto il suo anello più debole. Come instancabilmente ripetiamo nei nostri seminari: “in una catena di acciaio la resistenza è quella dell’anello di alluminio

La metafora che sfrutto è molto meno aleatoria di quanto sembri, quando pensiamo alla catena : progettazione > implementazione > solution provider > integratore di sistemi >  operatore assemblaggio > venditore > utente finale.

Ogni stakeholder  dell’ IoT, tendono ad una distribuzione disoggetti interessati molto più complessa rispetto ad altri sistemi TIC.

Altra domanda da un milione di Euro:

Chi diventa responsabile della sicurezza?

NESSUNO FINCHE’ NELLA CATENA DI FORNITORI I CLIENTI FINALI NON LA ESIGONO!

Cosa? Perché ai clienti non importa? Non si preoccupano di tutti i rischi aziendali e degli aspetti legati alla privacy? Non inciderebbe sul loro reddito o sulla loro reputazione?

L’abbiamo scritto nel titolo: e chi se ne frega!

Alcune società di consulenza hanno iniziato a promuovere un controllo dello stato di salute dell’internet degli oggetti. Purtroppo, non vi sono ancora molti fornitori di questo servizio, data la diversità e le dimensioni del mercato dell’internet degli oggetti. Inoltre, è improbabile che i consumatori si rivolgano a società di consulenza specializzate.

Le società antivirus hanno iniziato a sviluppare piattaforme di sicurezza per l’internet degli oggetti. Probabilmente ci vorranno 5-10 anni prima che diventino così ampiamente usati come antivirus tradizionali. Il mercato degli antivirus ha richiesto circa 10-15 anni per maturare. Speriamo che il mondo non crolli nel frattempo

Concludo per non annoiare
Anche se la sicurezza e le attività di CyberSec realmente sostenute dalle istituzioni non sono direttamente legate in responsabilità rispetto a quanto scritto sopra, ci sono delle implicazioni pressoché identiche di responsabilità nei confronti delle persone che sono consumatori per il mercato, cittadini per lo stato, pazienti per le strutture sanitarie.
Consapevole di citare un esempio estremo, e tuttavia concretamente recepito dalle popolazioni mondiali, pensiamo alla NSA che ha creato il virus WannaCry, causando devastazione alle aziende normali e cittadini.
Ulteriori domande nascono ineludibili: ma nella guerra Cyber, dove si trova il fronte? Chi sono i nemici?

Ad oggi IoT 4.0 è possibile solo se artigianale
Ciò che sembra paradossale dovrà essere abbracciato come un paradigma. L’unico futuro possibile per un IoT “umano” sarà quello artigianale. Peraltro, la rivoluzione europea sulla protezione dei dati, nota con l’acronimo GDPR, rende mandatorio per i costruttori (di ogni ordine e dimensione), progettare la sicurezza sin dalla concezione del prodotto sviluppando intelligenza euristica di sw che formalizza la così detta “protezione per impostazione predefinita” (Art. 25 Reg.679/16 – GDPR/16/EU)

Chi scrive ha fatto una scelta di campo e crede che nel mondo IoT, una rivoluzione sia possibile se parte dal basso. Ho quindi scelto una piccola azienda di Genova dove gli IoT si pensano, si disegnano, si progettano e si fanno!

Esatto, si fanno. Cosi come un ebanista fa un tavolino, un artista fa la scultura, un panettiere fa il pane. A costoro importa, importa molto!

Per Qxperts Srl – Dr Salvo Reina

Bollettino medico italiano Cyber Health: solo malesseri stagionali

Ospedali e sanità: disservizi all’ordine del giorno. Non virus piuttosto guasti e l’obsolescenza. Incognita delle macchine diagnostiche. Viaggio nella cybersicurezza delle strutture sanitarie italiane

 

Sanità italiana la cybersicurezza è ancora un patchwork raffazzonato, composto da interventi stratificati, coperture a macchia di leopardo e aree quali i macchinari biomedicali in cui, non si sa bene come e quanto intervenire. Una realtà che sta cercando velocemente di adeguarsi alla crescita improvvisa di attacchi informatici in generale, e in particolare contro le strutture sanitarie. Le quali, dal loro canto, sono sempre più digitalizzate e quindi esposte a possibili minacce.

Intrusione amicale: ad avercela!
È chiaro che l’aumento delle informazioni registrate nei sistemi informatici sta rendendo più appetibili i dati sanitari. Anche per questo sarebbe utile avere più strumenti, ad esempio un ente terzo che provasse a bucarci, cioè a testare le nostre difese.

Lo spettro del guasto informatico
In Italia non abbiamo vicende eclatanti come in Gran Bretagna con Wannacry ; la nostra sanità è comunque costellata da piccoli disservizi informatici. Emergono solo quando vanno in tilt pronto soccorso e accettazioni, quando le ambulanze sono mandate altrove e le prenotazioni non funzionano.
E’ sempre difficile capire cosa sia successo. Dettagli sono pochi, nebulosi e tutto ricade nella categoria universale e antica del “guasto informatico”.
In Italia nessuno sembra raccogliere o avere questi dati o statistiche certe. Il primo gruppo di studio a livello nazionale per la costruzione di un sistema di sicurezza dei dati informatici nei servizi sanitari, coordinato dall’Istituto Superiore di Sanità (Iss), è nato solo in Marzo 2018. In sintesi si procede per aneddoti ed episodi.

Italica coincidenza: Maggio 2017 i giorni della epidemia Wannacry
Strutture sanitarie di tutta Europa hanno dichiarato perdite di dati, e pagato per ripristino servizi.
In Italia registrati ufficialmente riportati molti sporadici problemi informatici negli ospedali italiani. Alcuni portavoce ufficiali di Ospedali hanno parlato di una coincidenza! Più che il Malware, in Italia sembra avere la meglio il guasto; il server che si rompe; il blackout.

Pronto soccorso, ospedale di Arzignano, Vicenza.
Prime cure d’emergenza, computer gestiscono i dati dei pazienti e le richieste di esami. In crisi anche il pronto soccorso.

Metà marzo 2018, blocco del sistema informatico dell’Asst Valle Camonica
Alcuni giorni vari disservizi agli ospedali di Esine e di Edolo (provincia di Brescia). Prenotazioni e referti.

Febbraio 2018 Osp. Galliera, Genova.
Non meglio precisato guasto al sistema informatico che gestisce gli accessi dell’ospedale Galliera, Genova, ha creato disagi, rallentando pronto soccorso con dirottamento ambulanze in altre strutture.

Febbraio 2018 Osp. Santissima Annunziata di Savigliano (Piemonte)
Problema causato da un attacco informatico, un virus individuato in un’applicazione del Centro trasfusionale e di averlo circoscritto senza perdite di dati o pericolo per gli stessi.

Febbraio 2018 Osp. di Novara
Registrati guasti, code e ritorno alla carta per alcune ore.

Febbraio 2018 Osp.li Torino, Martini, Maria Vittoria e San Giovanni Bosco
Uno o due giorni rallentamento registrazioni amministrative degli utenti causate da un non meglio definito guasto informatico; forse, derivato dalle attività di unificazione delle procedure delle aziende sanitarie.

Dicembre 2017 blocco server Insiel (Ict in-house) regione Friuli Venezia Giulia
Ripercussioni sul sistema informatico delle strutture ospedaliere, sanitarie e perfino sui medici di medicina generale. Personale ricorso a carta e penna.

Il 17 maggio 2017, in piena fase Wannacry, va in tilt il punto prelievo hub OSp. Rovigo.
Un guasto tecnico informatico, comunicherà poi una nota della Ulss 5 Polesana

13 maggio all’ospedale di San Bonifacio (Verona),
Il pronto soccorso, il laboratorio di analisi, cardiologia e radiologia colpiti da una serie di disservizi, con il blocco delle accettazioni, rallentamenti e disguidi dovuti «alla necessità di sostituire l’attività informatica con una modalità cartacea». La causa è un blocco dei sistemi informatici. “No Wannacry», riferisce comunicazione Ulss 20 Verona. Problema di server, per accorpamento tre aziende sanitarie in una“.

17 maggio, disagi presidi sanitari province di Siena e Grosseto,
Al policlinico Santa Maria alle Scotte, ai punti prelievo dell’AOU senese, degli ospedali e di tutti i presidi territoriali della provincia di Siena. La causa sono forti rallentamenti nella procedura informatica che gestisce prenotazioni, accettazioni e pagamenti per un guasto a un componente del server. “… problema di malfunzionamento di un software in comune con l’azienda sanitaria“, commento di Infrastrutture Sud Est di Estar, l’ente di supporto tecnico-amministrativo regionale della Toscana.

Non solo virus, ma obsolescenza e incompatibilità

Fine Cennaio 2018, a Foligno, all’ospedale San Giovanni Battista
Per una sera è andato in crisi il sistema informatico, con difficoltà per il personale sanitario. «È stato un guasto elettrico nel nostro centro elaborazione dati”, comenta dirigente del servizio informatico Usl Umbria 2. “… scattato un interruttore che non doveva saltare, si sono spenti i server, si è bruciato qualche componente e siamo ripartiti. Non abbiamo avuto perdite di dati, inoltre è successo di notte. Ma ora stiamo rafforzando la parte elettrica per avere più ridondanza”.
Il problema della sicurezza informatica è molto sentita da noi anche per la delicatezza dei dati che trattiamo», prosegue. «Ma è un settore che richiede ingenti investimenti e tempi rapidi, mentre i tempi di approvvigionamento della Pubblica amministrazione non sono velocissimi. In generale le risorse sono meno delle esigenze crescenti».

Agosto 2017 Osp. San Martino, Genova
Per diverse ore, un guasto al sistema informatico dell’ospedale San Martino ha causato disagi nella gestione di accettazioni, ricoveri e dimissioni; e il personale è tornato a compilare a mano moduli e referti. «È stato un guasto del server per obsolescenza tecnica ma ci siamo mossi subito», commenta direttore sistemi informativi e ingegneria clinica all’azienda ospedaliera universitaria San Martino di Genova. “C’è un tema più generale della mancanza di fondi rispetto alle necessità, per cui a volte bisogna tenersi due anni di più sistemi vecchi che per loro stessa natura non sono aggiornati. Noi ci siamo mossi in anticipo e 5-6 anni fa abbiamo fatto una gara europea per cambiare tutte le macchine periferiche (tranne i server), in modo da avere un parco omogeneo di dispositivi. E questo ha alzato l’asticella di sicurezza dell’ospedale; ad esempio non abbiamo avuto problemi di ransomware. Prima infatti tutti i computer aziendali erano diversi e il processo di manutenzione era poco efficiente. Inoltre prima ognuno poteva installarsi il software che voleva, ora abbiamo chiuso tutte le porte, le porticine e i portoni. Spesso Il problema non sono solo i guasti dell’hardware. Molti blocchi nel funzionamento in realtà nascono da conflitti di software, e da errori di configurazione”.

Candida posizione di Claudio Telmon, direttivo Clusit
“I sistemi informativi della sanità, sia pubblica che privata, sono sistemi complessi che si sono stratificati nel tempo, con situazioni difficili da sanare. E anche se la situazione sta migliorando, negli anni c’è stato poca attenzione su questo aspetto da parte delle strutture sanitarie. Molti incidenti, notano gli analisti dell’azienda, si sono verificati perché spesso le aziende sanitarie non sono in linea con le migliori pratiche di sicurezza e non pongono rimedio alle vulnerabilità note nel software medicale.”

Il rischio biomedicale? La sindrome da Silos
Come gestire le macchine biomedicali, che fanno esami, raggi, analisi?
La cybersicurezza in sanità è ancora affrontata in modo settoriale.  I macchinari diagnostici, gestiti dall’ingegneria clinica: tac, risonanze, ecografi, apparecchi elettromedicali negli ultimi anni si sono evoluti in sistemi informativi che memorizzano i dati clinici dei pazienti, che si collegano alla rete aziendale, ma che rischiano di avere un livello di protezione più basso. E spesso fanno capo a responsabili diversi rispetto a chi protegge i sistemi dell’ospedale.
Problema simile quello emerso con l’industria 4.0. I Sistemi di fabbrica isolati che a un certo punto si ritrovano in rete senza adeguate misure di sicurezza; il produttore non è mai stato messo sotto pressione per evoluzione», aggiunge.
Poche aziende a livello mondiale, per cui è anche difficile per una struttura sanitaria rimettere in discussione una fornitura sulla base di un aspetto (la cybersicurezza) ritenuto marginale.

La vera battaglia è quindi quella della contrattualità di PLA e dei problemi di budget, sostituzione di macchine e di server, funzionamento dei data center, unificazioni di procedure, software e applicativi diversi. E quando scatta l’emergenza, si ricorre alla vecchia carta.

Aggiungiamo alla fine, soprattutto il paziente non sa mai di chi è la colpa anche quando tutte le responsabilità formali sono assegnate in organigramma.

SR

Quotato dall’Autrice dell’articolo originale

La gestione dei sistemi informativi degli ospedali e quella dell’ingegneria clinica sono ancora mondi separati, che fino a poco tempo fa si ignoravano cordialmente” commenta Padrone (San Martino, di Genova). “… una Tac non è più solo hardware come una volta, ma anche software. Tutte le tecnologie biomedicali si stanno informatizzando, e c’è l’esigenza di collegarle in rete, per cui diventano delle porte. E anche quando non sono collegate, sono infarcite di software, e quindi potenzialmente possono avere dei bachi. Infatti non a caso negli ultimi anni gli avvisi di sicurezza di tipo informatico inviati dai produttori di queste macchine sono aumentati; prima erano quasi nulli“.

Riferimenti e fonti primarie:  le informazioni riportate in estratto sono derivate dall’articolo di Carola Frediani da “La Stampa” sotto Creative Commons con alcuni diritti riservati:  GNN — GEDI Gruppo Editoriale S.p.A. – P.Iva 00906801006 — Società soggetta all’attività di direzione e coordinamento di CIR SpA

 

La sicurezza e-mail: aziende e organizzazioni e-Health non comprendono il danno per i pazienti

Ottenere la sicurezza e-mail end-to-end senza impatto sulla routine dell’utente è per alcuni settori pura mitologia. Pensiamo ad esempio all’assistenza sanitaria e i servizi finanziari, la privacy e i dati dei consumatori. La sicurezza è diventata una priorità  assoluta per la maggior parte dei reparti ICT e i regolamenti e le sanzioni per non conformità sembrano onerosi ma sono nulla rispetto alla perdita di fiducia da parte dei clienti/pazienti quando si verifica una violazione della sicurezza.

L’e-mail è il modo in cui le organizzazioni comunicano de facto soprattutto al di fuori dei loro firewall. Se non adeguatamente protetto, il server e-mail può essere uno dei più vulnerabili sistemi nell’infrastruttura di un’azienda. La sfida consiste nell’implementare un sistema di posta elettronica sicuro che è conforme a tutte le normative oltre che integrabile con i sistemi aziendali già esistenti.

La crittografia e-mail tradizionale è inadeguata
La maggior parte degli approcci di crittografia e-mail tradizionali deve basarsi su più  metodi di recapito, che consentono di nelle lacune in materia di sicurezza dovute alla separazione dei messaggi. S/MIME e PGP PKI di eredità sono complessi per ESSO e incompatibile con Gmail, Yahoo e Android. La chiave simmetrica proprietaria richiede una configurazione complessa chiave di gestione del database, e può anche portare alla perdita di dati se una chiave è danneggiata. Proprietario i navigatori della posta elettronica dalla confusione dell’utente finale con più caselle di posta, link bloccati o scaduti, e nessun accesso ai contatti.
Come dovrebbe funzionare una infrastruttura doi Posta Elettronica
La nuova soluzione e-mail deve essere crittografata end-to-end già disponibile per il desktop a livello di interfaccia utente; quindi ci riferiamo ad un qualunque client ma anche interfaccia cloud indipendentemente che sia Web o mobile. Un altro aspetto è la scalabilità a milioni di utenti, pur mantenendo una gestione trasparente e integra del così detto  “Personalmente Identificabile Informazioni (PII) e Informazioni sulla salute personale (PHI) sicuro e privato.

Solo questo livello di sicurezza la comunicazione via e-mail dà fiducia alle organizzazioni nella transizione dalla carta all’elettronica comunicazione. Grazie ad una soluzione unica per desktop, cloud e mobile la decrittografia su desktop, Web e mobile, da parte di utenti interni ed esterni lo strato di logica delle applicazioni del futuro potranno effettuare la scansione e l’analisi di filtraggio di tutte le e-mail in entrata e in uscita.

Evidentemente la visione della Protezione dei Dati (PII o PHI) deve essere incentrata sia sui dati del corpo della e-mail che sugli allegati come un unico contenuto crittografato; infatti, in caso di violazione della sicurezza, il contenuto crittografato non abbia alcun valore per l’attaccante.

ALter sito secondo GDPR europeo
Gli allegati vanno memorizzati su server interni, non su server esterni di terze parti.
Gestione delle chiavi apolide: il sistema di gestione delle chiavi alla base di questo sistema è probabilmente il fattore più importante che governa le prestazioni e la qualità dell’esperienza di un sicuro sistema di posta elettronica. Utilizzando la crittografia basata su algoritmi standard ma gestione di chiavi proprietarie, i messaggi sono sicuri ed è possibile inviare una comunicazione a qualsiasi destinatario, senza richiedere prima al destinatario di intraprendere azioni speciali. Nuove interfacce di piattaforme libere (Open Source) possono permettere  alla organizzazione di implementare sistemi in cui non ci sono chiavi da gestire o archiviare, conciliando gli applicativi on-line che richiedono  un’amministrazione ICT minima. Chiaramente il discorso è scalabile per grandi organizzazioni dove l’infrastruttura deve operare su scala globale.

Attento ! Non toccare

Perchè il “fingerprint” e i dispositivi che lo usano sia critico ai fini della privacy è scontato, meno evidente di come questo abbia a che fare con il BigData e la rivoluzione della IoT (Internet delle Cose).

fingerprintTutti ormai da mesi scriviamo di come sarà invasiva l’adozione di frigoriferi che comunicano con lavatrici e portachiavi perchè, abbiamo ormai capito, che dietro c’è un gioco perverso per il quale non i dati personali e sensibili, ma anche le “meta-informazioni” raccolte in ordine temporale singolarmente innoque, posso condurre ad un profilo di identificazione che ci da’ comunque dati e costumi della persona più che sensibili !

In questo contesto il “fingerprint” ha un ulteriore preoccupazione. Nell’immaginario pensiamo al cerchietto illuminato sul quale dobbiamo poggiare il dito e attendere il responso. Se siamo in banca che si apra la porta scorrevole per accedere, se siamo in ufficio per apporre una firma ad un documento, ecc.

Ma chi l’ha detto che sia sempre cosi evidente? Nel mio elettrodomestico domotico anche l’interruttore o un qualunque punto della superficie potrebbe rilevare la mia identità e a quel punto la mia presenza la conosce anche il mio iPhone che sta preparando la doccia calda in bagno e accende il microwave con lo stufato messo li’ la mattina quando si è usciti di corsa.

Molto bello, ma è chiaro cosa implica queste scenetta?

Meglio riflettere che farsi spiegare…

 

Intanto il gruppo dell’Articolo 29 ha emanato un vademecum di come dovrà essere concepita la privacy by design dei dispositivi e quella by default per il software che gestiranno i dati da fingerprint

http://www.salvoreina.it/miascienza/privacy-article-29-wp-fingerprint.html

SR

Signori siamo seri. Eludere la Guardia di Finanza è banale !

Una volta c’erano i floppy disk e chi voleva occultare i propri dati, doveva risolvere il problema fisico del disco. Si dirà oggi è lo stesso solo che i supporti si chiamano penne USB e possono contenere un intero sistema operativo.

floppy

Rispondo, infatti chi oggi nasconde le proprie cose non se le porta dietro in un supporto USB. Ovvio, può farlo,ma è come una persona nella tasca del portafoglio del bancomat tiene anche il PIN.
Quindi il punto non è dove mette le proprie fatture e i conti in nero quanto in quale formato e come li legge. Per escludere ipocrisie nel resto dell’articolo, diremo che il problema di fondo era proprio quello di come “la Legge legge i nostri contenuti”. Nella accezione del titolo di questo scritto, ci riferiamo alla Guardia di Finanza.

Come d’abitudine su queste colonne seguiamo uno stile pratico senza fronzoli accademici, quindi di seguito raccontiamo una storia immaginifica e, come nei migliori film di spionaggio diremo, “ogni riferimento a persone e cose degli avvenimenti qui riportati è del tutto casuale e fantasiosa”. Chi comprende bene.

Quando negli anni 90 un medico e/o un avvocato si rivolgeva a me per risolvere il problema eterno di mettere dati confidenziali dentro un computer e di conservare copie sicure di questi, il mio approccio creava imbarazzo e dubbio.

Generalmente, tutti gli smanettoni e/o hacker e/o ingegneri informatici raccontavano di nuove tecniche di cifratura digitale  mirate a oscurare e/o mascherare i files; sostanzialmente si rendevano “Neri i files del Nero”. Io ho sempre criticato l’approccio Bianco, Grigio e Nero prediligendo quello “trasparente”.

Ciò che segue è in presente storico, più o meno adiacente, con quello che accaddeva e che ancora oggi risulta vincente. Cambiate le tecnologie, gli strumenti, i protocolli, le infrastrutture trasmissive ma l’uomo e sempre più le donne, sono rimasti l’anello debole della evoluzione.

La logica “trasparente”
Come abbiamo già riportato in un nostro articolo su OmniaCloud, se un informatico intelligente, seppure esperto di criptologia e cifratura (le due cose cono distinte), vuole nascondere/oscurare/offuscare o qualunque altro sia lo scopo non rendere intelleggibile i contenuti, non ricorrerà alla filosofia del Nero.

trasparenteInnanzitutto se davvero immaginiamo un finanziere che vede un disco rigido e/o un floppy o più di recente una pennetta USB con un grosso buco nero (sia esso un shift reading, un settore, una replica di FAT e/o un MFT, o anche un tutto vuoto), la prima cosa che fa è quella di intimare di fornire la password e/o la chiave di lettura del supporto e/o del file e/o del settore MBR. Questa evenienza è talmente provinciale e beota (popolazione di pastori della Beozia con incidenza di demenza ambientale da metalli pesanti nelle acque), da non meritare commento.

Chiarito che non ha senso mascherare l’intero hard-disk e o volume, analoghe considerazioni si applicano alle cartelle e/o folders. Queste sono presenti in tutti i sistemi operativi che abbiano una GUI, ma anche nei Linux essenziali senza shell grafica, comunque ci sono le ataviche e ancestrali directories. Per questi volumi l’occultamente è primo di senzo perchè nessuna utility e/o protocollo di sistema permette di rimuovere gli entry point nelle tabelle di allocazione e contenuto del HTFS/NTFS (ma questo è vero per qualunque altro sistema operativo).

Arriviamo inevitabilmente e inesorabilmente al punto : i files.
Solo a questo livello è congetturabile una forma di manipolazione del dato che si intende nascondere. Questa ultima asserzione ci permette di spiegare la prima delle criticità risolte dalla logica “trasparente”; perchè nascondere?

Riflettendo, il vero scopo è quello di non rendere intelleggibile il significato dei contenuti. Detto in questo modo, la prima illusione di potenza ci riporterebbe alla cifratura! Ma abbiamo detto che se un finanziere (o come più di recente accade un perito forensic), si rende conto che il contenuto in chiaro non ha senso, dopo una scanzione di pochi secondi avrà identificato la mappa delle traslocazioni di un migliaio di algoritmi di cifratura. Dopo averli riconosciuti non farà nulla altro che sottoporre il file al brute-force e/o scanner semantico dei kit in commercio. Peraltro, un simile procedimento è utilizzabile per le tecniche di cancellazione controllata. Ci sono undeleters in grado di sfruttare strati magnetici diversi dei media di storage, ma questi sono rilevati da scanners stratigrafici bit-a-bit e poi questa tecnica è plausibile in un disco rigido, ma pericolosissima su media rimovibili perchè il dato può essere non ricostruibile anche per chi lo ha nascosto.

Ma allora come faccio a nascondere i miei files di nero se non posso nascondere i files ?
Seconda riflessione… In realtà non si vuole nascondere un file, piuttosto dei contenuti !

Vebiamo al punto della “trasparenza” con un esempio pratico, e praticato sul campo. Il primo punto vincolante è l’origine dei dati. Se abbiamo un avvocato dovremo trattare documenti testuali e a meno di qualche “eccentrico” appassionato che usa un wordprocessor proprietario, avremo i classici file di Word o di una sua variante open source (Smart Office, Open Office ecc). Statisticamente il caso di un medico è più interessante perchè troviamo anche l’uso dei fogli di calcolo dove le segretarie hanno messo in colonne ordinate i conti che non sono registrati nel software di faturazione. I medici erano  notevoli perchè spesso trattavano anche file di banche dati portabili  con dati delle visite e dati anamnestici e clinici. Storicamente si trovavano i classici DBIII, Clipper, MS Access; qualcuno più originale usava Paradox e FileMaker perchè medici e architetti si sono sempre distinti con gli Apple. Comunque la si metta, dati in files sensibili che non dovevano cadere in mani nemiche.

In accordo all’approccio “trasparente” i dati venivano in primis scramblati anche in modo blando come per esempio un compressore qualunque (ZIP, ARC, LHR,  ecc). Questo indispensabile passo era necessario per evitare che con un semplice DUMP di memoria di un viewer di sistema, si potesse riconosce in chiaro i caratteri ASCII e, nel caso dei db, la metrica (anche solo approssimativa) del tracciato record ad accesso diretto. Cosi facendo,  si otteneva anche un secondo benefico effetot. La dimensione del file si riduceva notevolmente.

stegoaA questo punto non rimaneva che usare un approccio steganografico, ossia non si marcava come invisibile il file, non si cancellava, e non si blindava con una password in chiave di cifratura, ma si trovava un file contenitore più grande nel quale inoculare (diluire) uno o più blocchi del file da secretare.

Ciò che a questo punto bisognava fare, ha poco di informatico e molto di stupido. Selezionare un filmato AVI o una immagine BMP o un gioco EXE tipo PacMan. Bastava infine incollare  opportunamente (binariamente) il nostro file segreto al film, alla immagine o al giochino ed era fatta ! Nella economia di queste righe è di scarsa importanza spiegare cosa si intende per “opportunamente”, basti sapere che quando il finanziere (o chi per lui), guardando il contenuto del disco (rigido o rimovibile) il pac-man partiva, la fotografia della famiglia si visualizzava sullo schermo e il video delle vacanze aveva anche il sonoro.

Cosi siamo andati avanti per decenni, oggi tutto questo non ha senso, ma la logica del “contenuto trasparente” è ancora la migliore e anche la più conveniente. Ciò che prima accadeva in un floppy, poi sugli HD e quindi nelle pennette USB, ora non occorre più.

Non serve più neppure portarsi dietro nulla (quindi nn esiste più il reato in flagranza), basta parcheggiare su un social, su un CC storage remoto, o su un area privata del proprio web non indicizzato e i contenuti di fatto non esistono più neppure ad un controllo.

Come è possibile confutare dei contenuti in files la cui esistenza non è tracciabile. Si aggiunga che oggi è possibile entrare in un internet cafè col mio portatile, mettere una penna USB con un LiveOS, effettuare una connessione DHCP con IP transitorio via WiFi senza che della mia transazione. Posso usare processi in memoria senza scrivere sul disco. una SandBox temporanea e/o addirittura una macchina virtuale il cui snapshot posso cancellare alla fine dei miei scopi.

 

 

 

 

Anche io apostata del backup : DR virtualisation

Sappiamo tutti che facciamo i backup perché “ci tocca !”. In genere, la postura verso di un sistemista le misure di Disaster Recovery è in genere quasi ideologica e religiosa. Ciò che enfatizziamo in questo articolo è la diffusione della “virtualizzazione” come tecnologia che spinge anche i sistemisti più ostinati e recalcitranti, a cambiare religione e abitudini fossilizzate.

Nell’ICT un dato originale può essere accidentalmente eliminato o modificato, esistono le possibilità di un guasto del sistema ma anche un crash del disco sul dispositivo di un utente a un data center che ultimamente in Italia può essere “alluvionato”.

Quando si verifica un evento indesiderato che si riteneva cosi remoto da non essere prevedibile, il DS non riguarda solo i dati da ripristinare, ma l’intero ambiente di lavoro. Il ripristino di emergenza è tipicamente un fatto di Sistema nella sua accezione più larga.apostata

Backup e disaster recovery sono termini non direttamente intercambiabili anche se esiste una direzionalità :  il ripristino di emergenza non è possibile senza il backup.

Il crescente utilizzo di virtualizzazione ha cambiato il modo di ripristino di emergenza viene effettuata perché, in un mondo virtuale, un sistema può essere recuperato duplicando immagini di macchine virtuali (VM) e ricreare altrove.

Per capire la replica di una VM finalizzata al disaster recovery e il modo in cui il mercato si è adeguato alla virtualizzazione partiamo da una analisi di confronto.

Ai vecchi tempi, se un server andava giù, probabilmente le cose andavano cosi :

Passo 1 : ottenere un nuovo server. La speranza di avere un “ferro” di ricambio a portata di mano e non un modello “out-of-date”
Passo 2 :  Installare tutto il software di sistema e delle applicazioni, cercando di ottenere tutte le impostazioni come erano prima, a meno che naturalmente si fosse fatto in anticipo (uno o due server ridondanti in stand-by), però sappiamo di riferirci ad una misura molto poco diffusa. In genere uno “stand-by a caldo”, viene adottato per una applicazione e non a livello di sistema per via dei costi di proprietà di applicazione, con tutti i costi hardware e software pagati due volte.
Passo 3 : Ripristino operativo del backup più recente dei dati, per un database che potrebbe essere quasi fino ad oggi, ma per un file server, un backup notturno può essere tutto ciò che è disponibile, soltanto fino all’ultimo giorno lavorativo. Tutto ciò che era in memoria al momento del black-out è probabile ovviamente  perso. In pratica si arriva a coprire un piano di backup in ragione del punto di ripristino (RPO), sempre che fosse stato pianificato.

La nuova profezia
La virtualizzazione cambia tutto e aumenta il numero di opzioni. In primo luogo, sui dati possono essere facilmente eseguiti  backups come parte di un’immagine di una data macchina virtuale (VM); con ciò implicando  software applicativo, dati locali, impostazioni e memoria RAM al tempo della interruzione. Secondo, non vi è alcuna necessità di un server fisico di ricostruzione perchè la VM può essere ricreata (o semplicemente propagata) in qualsiasi altro ambiente virtuale compatibile. Inoltre questo può essere fatto sia con risorsa di spazio disco in-house o acquisito da un fornitore di servizi di cloud di terze parti. Evidente che la maggior parte dei costi dei sistemi ridondanti scompaiono.

Per ciò che attiene il ripristino di emergenza diventa più conveniente, più veloce, più facile e più completo. I cosiddetti “obiettivi di backup” in termini di recupero più veloce (RTO) sono più realistici da raggiungere.

Ovviamente, come in tutte le cose, questa è la teoria, che si può complicare e sofisticare quando esiste la necessità di coordinare le diverse macchine virtuali che si basano una sull’altra (ad esempio un’applicazione VM e un database VM),  per cui testare il recupero è fondamentale per prevenire problemi ai sistemi di tipo “live”.

Il terzo livello
Con la virtualizzazione applicata al DR, si dispone di una serie di approcci differenti:

1) livello di hypervisor integrato
2) replica VM
3) DR come servizio (DRaaS)

I principali fornitori di piattaforme di virtualizzazione – tra cui VMware, Microsoft Hyper-V e Citrix Xen – offrono diversi livelli di servizi di replica VM insiti nei loro prodotti. Essi sono strettamente integrati nell’hypervisor stesso e quindi limitati ad un determinato ambiente virtuale. Tuttavia, questo non sempre le ottenere le prestazioni sui tempi sono quelle richieste dalla protezione continua dei dati (CDP). In proposito esistono tecnologie e soluzioni come  la VM “ombra”e gli standbys caldi di VM che perlomeno riducono igli aspetti dei costi RPO e RTO.

Esistono poi altri prodotti integrabili come VM repliche a livello di hypervisor come “RecoverPoint”; ad esempio EMC, che supporta la replica e il recupero di più VM coordinata, in modo che possa garantire che una VM in esecuzione un programma sia coerente con un database associato VM.  Quest’ultima comunque è solo disponibile per VMware, mentre su Hyper-V si ricorre alla gestione di un “cloud stack” tipo OpenStack che sempre di più è spinto dalla filosofia Open.

Per completezza possiamo citare Zerto, che sostiene di aver costruito una migliore automazione e orchestrazione rispetto ai fornitori di piattaforme di virtualizzazione, e di aver ridotto ulteriormente l’impatto sull’ambiente di runtime. Zerto supporta attualmente solo VMware, ma ha in programma di estendere il supporto per Hyper-V e Amazon Web Services (AWS), quindi  in futuroavremo un “failover” da un sistema in-house VMware, e AWS in un altro “non-VMware”. Il prodotto può essere utilizzato anche per la pre-programmazione della migrazione dei carichi di lavoro. Questo è particolarmente gradito dai piccoli che fanno attenzione agli investimenti di “ferro”

Esistono infine, altri strumenti “virtuali-aware” che lavorano prendendo istantanee (snapshot) di macchine virtuali per periodi fissati mettendo in pausa la macchina virtuale per un tempo sufficiente per copiare i suoi dati, le impostazioni e la memoria prima di tornare al suo stato precedente.
E’ chiaro che lo snapshot cosi ottenuto può essere utilizzato per ricreare la macchina virtuale più e più volte ma la RPO dipende da quanto spesso vengono prese le istantanee (che potrebbe essere abbastanza spesso per essere vicino a CDP). In merito alla RTO dipende da quanto rapidamente può essere ottenuto l’accesso ad una risorsa virtuale alternativa. In effetti a seconda delle struttura di business e le necessità funzionali, con una giusta preparazione, i tempi di “transfert” dovrebbe essere pressocchè immediati.

Un certo numero di nuovi fornitori specializzati in ambiente virtuale di backup, come Veeam (Svizzera), hanno lanciato un prodotto nel 2008 e che supporta VMware e Microsoft Hyper-V.
Nel caso di Nakivo (fondata nel 2012) che supporta solo VMware, questi prodotti sono stati costruiti per un mondo virtuale, hanno molti degli adattamenti richiesti incorporati nativamente, ad esempio la creazione di VM snapshot e l’accelerazione di rete per la replica off-site che sono piuttosto efficienti.

I fornitori di backup tradizionali hanno adattato i loro prodotti,  come ad esempio Symantec che ha appena rilasciato Backup Exec 2014, dichiarano  capacità e prestazioni confrontabili alle ultime tecnologie. Dell sostiene che le sue prestazioni cono confrontabili con AppAssure CDP grazie ad un “agente intelligente” che evita il congelamento della VM e prende un’istantanea almeno una volta ogni cinque minuti.

In ultimo, e per completezza del quadro, citiamo Simplana di CommVault e Arcserve che hanno abbracciato la crescente sfida nel mondo del DR.

Ricordiamo che un punto di forza per i fornitori “tradizionali” è la loro capacità di supportare anche ambienti fisici “legacy” oltre ai virtuali, e questo è una situazione che resta vincolante in molte organizzazioni. Significa, inoltre, i loro prodotti sono spesso utilizzati per la migrazione, cioè, per il backup di un server fisico e ripristino come una VM.

Molti fornitori di servizi di infrastrutture di cloud, ad esempio Rackspace e Amazon offrono la replica di VM, consentendo ai clienti di mettere il proprio failover in atto, ma in generale questo è limitato alle proprie piattaforme.

Articolo correlato Disaster recovery as a service (DRaaS)

SR

Image14542 - Copia

 

 

Dallo stesso autore su rubrica Omnia Cloud

Annunci