L’attacco hacker al “San Raffaele” di Milano avrà conseguenze di lunga durata, nonostante i tentativi dell’ospedale di minimizzare l’accaduto. E’ quanto risulta da un’analisi delle evidenze finora raccolte – i dati esposti con questo possibile data breach, comprese password di utenti, dati degli utenti – in abbinamento a quanto riporta il Gdpr ed Enisa, autorità in materia.
Parla di data breach il tweet degli hacker di LulzSec Ita, che ha divulgato l’accaduto e ha apportato anche prove dell’accaduto, con un dump dei dati di utenti e pazienti dell’ospedale.
La chiosa del tweet è stata una domanda provocatoria da parte del collettivo hacker: “avete comunicato al Garante il #databreach di due mesi fa?”. Domanda retorica, dato che l’ospedale non l’ha fatto, né secondo gli hacker avrebbe chiuso le falle. Tanto che l’ospedale stesso nega di dover intervenire e che sia un data breach: secondo una prima smentita del San Raffaele, infatti, i dati sembrerebbero riguardare una app “dismessa da anni e circoscritta” e dunque la sottrazione delle informazioni sarebbe limitata a password e utenze non più in uso. Ulteriormente, nella nota ufficiale viene categoricamente escluso che “dati sensibili” siano stati oggetto di accesso abusivo o sottrazione.
Dati dei pazienti, password degli utenti del San Raffaele
I dump rivelati da Anonymous Italia e LulzSec Ita, però, sembrerebbero contenere non soltanto indirizzi e-mail e password di alcuni operatori sanitari ma anche i dati anagrafici (nome, cognome, data di nascita, codice fiscale, nazionalità e residenza) di alcuni pazienti. Per inciso, notevole che alcune password siano di risibile robustezza (quella di Roberto Burioni è nome.cognome).
Dovendo pertanto inquadrare correttamente l’accaduto sotto un profilo giuridico, occorre precisare innanzitutto se tale evento costituisce un effettivo data breach ai sensi del GDPR e la sua gravità, oltre che le conseguenze prospettabili.
Gli obblighi del Gdpr per data breach (come quello presunto del San Raffaele)
Per analizzare il primo aspetto, è bene ricordare che sul piano sostanziale una violazione di dati personali o data breach è un tipo di incidente di sicurezza che porta il titolare del trattamento a non poter più garantire l’osservanza dei principi relativi al trattamento di dati personali di cui all’art. 5 GDPR[1]. Nel caso di specie, l’evento consiste in una violazione di riservatezza, dal momento che si è realizzato un accesso non autorizzato e nelle ore successive una parziale divulgazione[2].
Ebbene: nulla rileva che il database sia obsoleto o risalente, né che non contenga dati “sensibili” o, per meglio dire, riconducibili alle categorie particolari di dati di cui all’art. 9.1 GDPR. Anzi: l’ipotesi di un data breach di dati obsoleti, è bene ricordare, potrebbe far emergere all’esito di un’istruttoria anche una contestazione circa il mancato rispetto del principio di limitazione della conservazione (art. 5.1 lett. e) GDPR).
Il rischio per i diritti e le libertà delle persone fisiche (da cui deriverebbe l’obbligo di notifica, ai sensi dell’art. 33 GDPR) sussiste nel momento in cui la violazione può comportare un danno fisico, materiale o immateriale per le persone fisiche i cui dati sono stati violati (ad esempio: discriminazione, furto o usurpazione d’identità, perdite finanziarie, pregiudizio alla reputazione). Ovviamente, la probabilità di occorrenza del danno è più elevata in caso i dati oggetto di violazione rientrino nelle categorie particolari di cui all’art. 9.1 GDPR o siano dati relativi a condanne penali, reati e misure di sicurezza.
Valutazione d’impatto del databreach per Enisa
Per esaminare la gravità del data breach è opportuno dunque ricorrere ad un metodo per valutarne l’impatto. Uno di questi è offerto direttamente dalle raccomandazioni contenute nel Working Document “Recommendations for a methodology of the assessment of severity of personal data breaches” dell’Agenzia europea per la sicurezza delle reti e dell’informazione (ENISA)[3]. Sebbene il documento sia antecedente al GDPR, non è in contrasto con il Regolamento ma anzi fornisce una metrica per poter determinare quanto grave sia la violazione occorsa.
Secondo tale metodo, nella valutazione di rischio derivante dalla violazione, occorre pertanto considerare non soltanto la probabilità e la gravità di un impatto potenziale, bensì anche le circostanze specifiche e concrete secondo i seguenti criteri:
- tipo di violazione (confidenzialità, integrità, disponibilità)
- natura, carattere sensibile e volume dei dati personali
- facilità di identificazione delle persone fisiche
- gravità delle conseguenze per le persone fisiche
- particolare vulnerabilità dell’interessato
- ambito operativo del titolare del trattamento
- numero di persone fisiche interessate.
Tali criteri, inoltre, trovano dei correttivi mediante l’applicazione di taluni fattori di aggiustamento.
Fra questi, sono ad esempio idonei ad aumentare la gravità dell’impatto:
- il volume dei dati per il singolo interessato, tanto sotto il profilo dell’arco temporale che del contenuto delle informazioni;
- il particolare ambito operativo del titolare del trattamento se idoneo a rivelare informazioni addizionali sull’interessato;
- la particolare vulnerabilità dell’interessato rapportata al tipo di violazione subita;
mentre invece ne causano una diminuzione:
- il coinvolgimento di dati invalidi o non aggiornati.
- il coinvolgimento di dati disponibili da fonti pubbliche.
- la natura dei dati e le informazioni ricavabili sugli interessati.
Databreach di gravità media
Le evidenze che possono emergere dalle notizie disponibili suggeriscono che siano stati esposti intenzionalmente e nei confronti di un numero non limitato di soggetti una serie di dati di tipo comune con un’elevata capacità di identificare univocamente gli interessati. Per quanto risalenti, nominativi, date di nascita e codici fiscali sono informazioni idonee a consentire una precisa identificazione degli interessati. Allo stesso modo, si deve considerare che gli indirizzi e-mail sono nominativi e rivelano l’appartenenza all’organizzazione dell’Ospedale.
Al netto di tali considerazioni, e applicando il conseguente scoring suggerito dal metodo ENISA, la valutazione porterebbe ad un risultato di non irrilevanza (severity score: medium) comportando così, anche in considerazione dell’ampiezza dell’incidente e il numero non esiguo di interessati coinvolti, la sussistenza di quel rischio per cui sussiste l’obbligo di procedere alla notifica all’Autorità Garante.
C’è obbligo di notifica a utenti e pazienti
Facendo riferimento ad alcuni precedenti provvedimenti del Garante su data breach[4], inoltre, sembrerebbe ricorrere anche l’ulteriore obbligo di comunicazione nei confronti degli interessati coinvolti ai sensi dell’art. 34 GDPR riscontrandosi elementi analoghi quali la sottrazione di dati direttamente e univocamente identificativi, nonché la gravità e permanenza delle conseguenze (ad esempio: per la possibilità di impiego illecito dei dati personali per furto di identità o phishing).
Inoltre, dal momento che il titolare ha l’obbligo di predisporre e attuare misure tecniche e organizzative adeguate per valutare la sussistenza della violazione di dati personali ed informare tempestivamente l’autorità di controllo e l’interessato[5], ogni eventuale ingiustificato ritardo nella notifica o una mancata documentazione della violazione esporrebbe ad una contestazione circa il mancato rispetto dell’art. 33 GDPR. Ulteriormente, qualora la notizia della violazione provenga da una fonte terza e si riferisca ad un evento risalente, potrebbe trovare applicazione anche la circostanza di cui all’art. 83.2 lett. h) producendo così un aggravamento di responsabilità in sede sanzionatoria.
Sebbene un approccio di metodo già consenta di profilare le ipotesi rappresentate, solamente all’esito dell’attività istruttoria che sarà svolta da parte dell’Autorità Garante sarà possibile avere una più precisa definizione dell’accaduto grazie al riscontro di fatti ed evidenze.
[1] WP250 Linee guida sulla notifica delle violazioni dei dati personali ai sensi del regolamento (UE) 2016/679.
[2] https://twitter.com/LulzSec_ITA/status/1263873134601609222
[4] https://www.enisa.europa.eu/publications/dbn-severity
[5] Fra cui: https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/9076378 (Unicredit), https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/9344061 (INPS).
[5] Considerando n. 87 GDPR.
