Sanità e Sicurezza delle Informazioni: una chiacchierata a due voci

News 16/12/2011

di Raoul Chiesa (Founder, President @ Security Brokers ScpA) e  Lino Fornaro (Direttivo ABIRT - Net1)
pubblicato su e-Health, novembre 2011

Introduzione
"Una rivista dedicata all'e-health nel nostro Paese? E addirittura un evento dedicato, l'ISH-Information Security Hospital (http://www.ehealthforum.it/eventi/3159)?? Che bello!!"
Questo il mio "commento" quando Barbara Ferraris di Celle - amica di lunga data e persona che stimo tantissimo - mi contattò diversi mesi fa, per informarmi di questa sua nuova iniziativa: accolsi la notizia con vero, sincero piacere.

Vi sono infatti dei motivi, più di uno a dire il vero, per i quali questa notizia mi riempie di gioia. Innanzitutto, credo che ve ne sia la necessità. Il mondo della sanità è differente, per ovvie ragioni, dal mondo dell'Information Security: i modi di pensare, le necessità, gli approcci sono sostanzialmente diversi. Inoltre, la sanità italiana si sta, lentamente, ma improrogabilmente, muovendo verso la c.d. e-health, ovverosia una completa fase di digitalizzazione e transizione dal "cartaceo" al digitale ed all'on-line.

Tutto questo comporta però la necessità di riconsiderare alcuni aspetti, estremamente importanti quando si parla di sanità e cittadini. Parole chiave come sicurezza dei dati, privacy e riservatezza divengono quindi prioritarie, forse anche di più rispetto a quanto lo siano già in altri settori.
Ecco il motivo di questo articolo "a quattro mani" con l'amico e collega Lino Fornaro, sempre attento all'evoluzione della tecnologia ed ai suoi impatti verso il mondo della sicurezza logica.

H&H: Health & Hacking
Il secondo motivo per cui ho gioito è invece un altro. Sono oramai quasi due anni che, insieme a colleghi ricercatori, ethical hacker ed esperti di sicurezza informatica, in Europa come negli USA, in Canada, India ed Australia, lavoriamo su questi aspetti. E le notizie provenienti dagli USA – certamente uno dei Paesi che per primo ha iniziato questa trasformazione, questa evoluzione digitale – non sono affatto rassicuranti.

Basta infatti fare delle ricerche con Google, utilizzando keyword quali "health and hacking", per scoprire come proprio negli USA la sanità abbia già ricevuto diversi "duri colpi": dispositivi pacemaker che "parlano" in BlueTooth e Wireless (e che possono essere "attaccati"), ospedali brutalmente "bucati" da script-kiddie o da cyber criminali, alla ricerca di identità da rubare e, non ultimo, persino una "gara di hacking", promossa dai tipi di HealthTap (http://www.healthtap.com/hacking-4-health/), al fine di individuare insicurezze e bachi in dispositivi ed applicazioni nel mondo sanitario (il quale, negli USA, è prettamente privato). Torneremo più avanti su questo punto.

Lo scenario
La sicurezza delle informazioni è ormai un fattore importante, se non abilitante, per una buona e corretta conduzione dei processi di gestione e trattamento delle informazioni.
Dietro il termine "sicurezza dei dati", o dell'informazione, si nasconde, però, un insieme di fattori della cui complessità a volte siamo inconsapevoli.
Già solo garantire i quattro requisiti fondamentali della sicurezza del dato (Disponibilità, Autenticazione, Integrità, Riservatezza) sottintende una grande complessità, qualunque sia la natura o struttura del dato (database, file audio, immagini, ecc.), in quanto per farlo, occorre mettere in sicurezza tutto l'ambiente in cui questa informazione è trattata, partendo dagli aspetti di sicurezza fisica e interessando tecnologie, persone, processi, management e strategie.

Il quadro si fa decisamente più complesso quando l'ambito del trattamento del dato è quello sanitario, in quanto la natura dell'informazione diventa intrinsecamente "pericolosa" per via degli effetti che può generare, per esempio con la perdita del carattere di "confidenzialità", sia sull'interessato (paziente) in merito al rispetto della sua dignità e delle sue libertà personali, che per chi  è responsabile del trattamento del dato per le  responsabilità civili e penali che ne conseguono (artt.11,15, 31, 33 e succ. Dlgs 196/03).
Se si pensa poi agli effetti di indisponibilità del dato, di non correttezza o completezza, oppure addirittura di perdita dell'informazione, gli effetti si traducono in mancato rispetto del "diritto alla salute" del cittadino/paziente, costituzionalmente garantita all'art.32, di lesioni gravi e chi più ne ha, più ne metta.

Norme & Attori
Queste "banali" considerazioni, mi sono utili come spunto per sottolineare come nel trattamento dei dati in ambito sanitario, le necessità di garanzie in merito agli aspetti di sicurezza e di privacy, binomio ormai inseparabile, ma anche l'obbligo di tutela della salute, sono condizioni imprescindibili per la tutela dei diritti fondamentali ed inviolabili dell'individuo e per la tutela stessa degli operatori sanitari e della struttura cui appartengono.
L'applicazione, però, delle misure di sicurezza in ambito sanitario, anche delle più elementari norme (mi riferisco alle cd "misure minime di sicurezza" di cui all'art.34 nei modi specificati nell'All. Sub B) del Dlgs 196/03), non è sempre compatibile, o facilmente adattabile, alle preminenti condizioni di operatività di reparto (penso a postazioni condivise ove vi operano contemporaneamente più operatori sanitari che dovrebbero utilizzare ognuno il proprio account) o applicabili talvolta alle cd "apparecchiature medicali", con le quali si trattano dati personali sensibili,  perchè eventuali modifiche da apportare per renderle "compatibili" o "compliant", con le misure minime, potrebbero causarne la perdita del requisito di "certificazione" che  queste hanno e devono mantenere.

Chiusa questa premessa, introduciamo altri elementi che intervengono nella determinazione dei requisiti del sistema di sicurezza inerente  il trattamento di dati in forma elettronica di informazioni riferite alla salute, che sono:
• il ruolo dell'interessato/paziente e la conseguenza della manifestazione, mutabile nel tempo, della Sua volontà (consenso, oscuramento);
• il diritto di accesso ai propri dati (art. 7 Dlgs 196/03, di seguito "codice") e la separazione dei dati riferibili a più soggetti in cartella clinica (vedi art. 92 e 93 del codice);
• le modalità di comunicazione dei dati riferiti alla salute allo stesso interessato (art. 84 del codice);
• il principio di necessità (art. 3) ed il rispetto delle "modalità di trattamento" (art.11) espressamente richiamato dall'Art 31 (misure di sicurezza) del codice;
• gli obblighi di separazione dei dati sensibili dagli altri dati (art.22 comma 7) e cifratura degli stessi (art.22 comma 6 ; art 24 del Disciplinare tecnico);
• le responsabilità medico-legali negli interventi sanitari e la conseguente necessità di identificazione certa dell'autore;
• le caratteristiche intrinseche di validità di una cartella clinica (consequenzialità delle annotazioni, garanzia della loro integrità e paternità, completezza);
• etc....

tali requisiti, come evidente, interessano sia aspetto funzionali delle applicazioni che gestiscono il dato, ma che inevitabilmente riflettono problematiche di sicurezza, che architetturali e quindi più vicini alla concezione di soluzioni di sicurezza in senso stretto (Identity e access management, crittografia, log management e audit. Storage security, etc), oltre che ad aspetti organizzativi e di processo.

Europa VS Italia
Sotto un profilo più propriamente giuridico, coscienti delle problematiche sollevate dal trattamento dei dati personali sanitari, già i Garanti europei per la protezione dei dati avevano adottato il 15 febbraio 2007 un documento di lavoro (00323/07/EN WP 131, "Working Document on the processing of personal data relating to health in electronic health records" - EHR), che spiega quali parametri applicativi dovrebbero essere rispettati nell'implementazione e nella gestione dei dati sanitari.
Nelle Linee Guida dei Garanti UE sono state richieste elevate tutele per i dati sanitari, accessi sicuri e autodeterminazione dei pazienti. Infatti, è stato osservato che la creazione di un sistema nazionale di sanità elettronica è un obiettivo di rilevante interesse pubblico e il relativo trattamento dei dati personali deve avvenire nel pieno rispetto dei principi di protezione a tutela dei dati stessi.
Partendo dalle tematiche affrontate in sede europea, la nostra Autorità Garante per la Privacy ha a sua volta adottato due documenti di grande attualità: le Linee Guida in tema di Fascicolo Sanitario Elettronico (FSE) e di Dossier Sanitario (DS) con una delibera del 5 marzo 2009 e le più recenti  Linee guida in tema di referti on-line del 19 novembre 2009.

In particolare nelle Linee guida per il FSE viene sancito all'art.3 il "diritto alla costituzione di un Fascicolo sanitario elettronico o di un dossier sanitario" rifacendosi al Codice dell'Amministrazione Digitale (CAD)  che a sua volta sancisce il diritto dei cittadini  all'uso delle tecnologie (art 3 CAD); questo Fascicolo prevede la condivisione informatica, da parte di distinti organismi o professionisti, di dati e documenti sanitari che vengono formati, integrati e aggiornati nel tempo da più soggetti, al fine di documentare in modo unitario e in termini il più possibile completi un'intera gamma di diversi eventi sanitari riguardanti un medesimo individuo e, in prospettiva, l'intera sua storia clinica

In relazione a quanto richiesto dal Provvedimento del Garante che detta queste Linee guida, sono stati previsti specifici accorgimenti tecnici per assicurare idonei livelli di sicurezza (ai sensi dell'art. 31 del Codice), che includono:
• la sicurezza del dato, ovunque ed in qualunque forma esso si trovi (strutturata in un database o destrutturata su filesystem), con l'utilizzo di tecniche di cifratura tali da limitare la comprensibilità ai soli autorizzati ma che ne consenta anche un utilizzo condiviso;
• la separazione dei dati (identificativi, amministrativi, sanitari, sociali, genetici) con opportune  misure di controllo accesso e auditing;
• la sicurezza nelle trasmissione in rete;
• la sicurezza e solidità di meccanismi di autenticazione che diano garanzie certe sull'identità dichiarata (strong authentication)
• un sistema di autorizzazione a "grana fine";
• una meccanismo di controllo e gestione dei consensi e degli oscuramenti che tenga anche conto dell'autodeterminazione informativa del paziente e consenta  di conseguenza di modificare le autorizzazioni di accesso ai dati sanitari tra reparti ed in un contesto di FSE ;
• un meccanismo di logging e auditing delle azioni compiute e degli accessi (log e change management);
• misure di sicurezza per garantire la riservatezza dei dati sui supporti di memorizzazione esterni, attraverso tecniche di cifratura;
• un meccanismo di auditing

 garantendo comunque l'accesso a tali dati direttamente da parte dell'interessato/paziente, nel rispetto di quanto stabilito dall'art.84 secondo cui gli esercenti le professioni sanitarie e gli organismi sanitari possono comunicare all'interessato informazioni inerenti al suo stato di salute (es. referti, esiti di consulti medici) per il tramite di un medico - individuato dallo stesso interessato o dal Titolare e- o di un esercente le professioni sanitarie, che nello svolgimento dei propri compiti intrattiene rapporti diretti con il paziente

Pare evidente che sia l'infrastruttura di sicurezza da progettare ed implementare, sia l'organizzazione per la gestione ed il rispetto di questi principi siano quantomeno complessi e richiedano parecchia attenzione e pianificazione.
In uno scenario di questo tipo, dove tra l'altro, interagiscono più soggetti autonomi (FSE) è importante fare scelte ponderate e misurare con una certa periodicità l'effettivo livello di sicurezza raggiunto, sia con azioni di auditing, già citate in precedenza, che attraverso dei test di sicurezza per verificare l'effettiva robustezza dell'infrastruttura e del sistema nel suo complesso.

Perché tutto questo succede?
Tornando a quanto raccontavamo all'inizio di questo focus, l'amico Shawn Merdinger, Information Security Analyst alla University of Florida, Health Science Center di Gainesville (USA) lavora oramai in questo settore da un paio di anni e, nonostante ciò, nella sua ultima email mi diceva "Sai Raoul, siamo davvero all'inizio di una nuova era, ed i concetti di sicurezza in questo campo sono anch'essi all'inizio".

Infatti il NIST (National Institute for Security & Technology, USA) ha recentemente rilasciato la versione 1.0 delle procedure da loro approvate sugli "Health Record", ovverosia tutti i dati clinici riguardanti un paziente e, prontamente, l'Office of the National Coordinator for Health Information Technology (http://healthit.hhs.gov/) ha lavorato non poco sulla sezione del sito relativa a "Sicurezza e Privacy", creando il primo White Paper su questa delicata tematica, scaricabile da qui: http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_11673_911198_0_0_18/CoverPageandExecutiveSummary032610.pdf 

Parlando con Shawn è però emerso come il problema, quantomeno negli USA, parta da approcci differenti.

Hey Raoul!

[…]

Something else concerning the legal liability of medical devices in
the US came up in my research, which is the 2008 Riegel v. Medronic
ruling by the US Supreme Court -- bottom line with the ruling is that
it limits the liability of device makers. 
That basically means since no one will have to pay very much if there's problems//vulns, then there is no incentive to do proactive security testing on these devices.

http://www.startribune.com/business/15801117.html
http://www.law.cornell.edu/supct/html/06-179.ZS.html

Cheers,
--scm

Verifiche di sicurezza
Quando si ha la necessità di capire fattivamente se la propria infrastruttura è idonea a fornirci quel livello di sicurezza da noi atteso, e abbiamo bisogno di verificare se il livello di sicurezza teorizzato è reale, l'unico sistema che personalmente ritengo utile per dare una risposta idonea a certi interrogativi è la conduzione di un test di sicurezza.

Ora, senza volere aprire un lungo capitolo in merito ai test di sicurezza e alle loro differenze (occhio però a non confondere un Vulnerability Assessment con un pen test), né sul come "riconoscere" un buon fornitore di servizi di sicurezza da chi lo è diventato con la stessa velocità con cui si stampa una brochure, vorrei evidenziare alcuni fattori critici relativi ai test di sicurezza (a partire dai penetration test) e a quali "metodologie" ricorrere per risolvere tali limiti.

Per anni il problema dei pen test è stato fondamentalmente legato ad alcuni importanti fattori:
1 i risultati dei test principalmente legati alle capacità dei singoli tester
2 la difficoltà nel far ripetere un test ad esecutori diversi
3 l'assenza di garanzia sulla completezza del test
4 la non confrontabilità dei risultati di test nel tempo e tra fornitori diversi
5 il falso senso di sicurezza che un test di sicurezza fornisce
6 varie ed eventuali (inserite qui quanto non previsto nei punti precedenti ;)

Tutto questo perché, fondamentalmente, un servizio finalizzato alla "misura del livello di sicurezza" non era a sua volta misurabile (o confrontabile se preferite).
Per dare risposta a questi non irrilevanti quesiti, per fortuna oggi (da qualche anno) esiste una metodologia nata in seno all'attuale ISECOM (Institute for Security and Open Methodologies, http://www.isecom.org) chiamata OSSTMM (Open Source Security Testing and Methodology Manual, http://www.osstmm.org).

L'OSSTMM è applicabile sia a verifiche di sicurezza "live" (infrastruttura IT medica) sia a verifiche di tipo "Black-Box Security Testing", le quali hanno cioè l'obiettivo di testare la sicurezza intrinseca dei dispositivi utilizzati in campo medico.

Certamente, siamo ancora agli inizi di questo processo, il mondo della sanità è affetto da ben altre problematiche ed urgenze, ma riteniamo di estrema importanza la valutazione dell'effettiva sicurezza di un device in questi ambienti. Infatti, mentre nel mondo "normale" una insicurezza può causare problemi noti e, tutto sommato, gestibili ed arginabili, nel campo medico parliamo di vite umane… un qualcosa che non si può, purtroppo, "ripristinare".

 

Tag: Information Security, e-health, hacking, script-kiddie, cyber crime, privacy, sicurezza dato, sanità elettronica, Garante Privacy, fascicolo sanitario elettronico, dossier sanitario