Il 21 maggio 2020 alle ore 09:28 AM, il collettivo di hacker LulzSec_ITA ha pubblicato su Twitter un messaggio nel quale era possibile visione degli screenshot di alcune tabelle riguardanti utenti che gli hacker definiscono pazienti ed infermieri dell’ospedale San Raffale Milano.
Clicca per spostarti velocemente:
Aggiornamento del 22/05/2020 – 22:00
Aggiornamento del 22/05/2020 – 19:41
Aggiornamento del 22/05/2020 – 11:10
Aggiornamento del 21/05/2020 – 18:43
La Sanità italiana e le problematiche di sicurezza ICT
Il Tweet pubblicato dal collettivo apre, nuovamente, un fronte di riflessione assai penoso da affrontare. Nel dicembre 2018 molti ricorderanno che la stessa LulzSec_ITA aveva impartito un duro colpo a diverse ASL italiane (Viterbo, Rieti, Caserta), nonchè alcuni ospedali (San Giovanni di Roma). Fu un attacco duro perchè portava alla luce dati ed informazioni degli obiettivi, non opportunamente conservati. Dal 2018 ad oggi ci si sarebbe aspettato, quantomeno per buonsenso e responsabilità professionale, che le politiche di sicurezza delle unità ospedaliere, fossero incrementate al punto da non permettere più, ad esempio, che la username coincida con la password e che entrambe coincidano con il nome e cognome dell’utente. L’attacco è stato condotto sfruttando una falla del sistema informativo dell’ospedale, successivamente chiusa, come dimostrato dal Tweet riportato di seguito.
Gli screenshot del data breach al San Raffaele mostrano credenziali conservate in chiaro, senza alcuna aderenza ai requisiti minimi di sicurezza esponendo così gli account a gravi rischi di sicurezza. Il data breach sarebbe avvenuto a fine marzo 2020 ma non pubblicato nel rispetto di una tregua dovuta allo stato di emergenza causato dal COVID-19.
Tra gli screenshot mostrati a video ne spicca uno che sembrerebbe contenere diversi file CSV tra cui alcuni appartenenti al SPP (Servizio di Prevenzione e Protezione) che, dal titolo, sembrerebbe suggerire la presenza di 1.200 record attinenti a credenziali utenti. Il file si chiama: dbHSR_SPP_1200_users.csv
Al momento (14:20) gli screenshot pubblicati rappresentano solo una piccola parte dei dati in possesso degli hacker che hanno deciso di “giocare” con la struttura ospedaliera minacciando di pubblicare la restante parte dei file se non vedranno la partecipazione della struttura ospedaliera.
Conclusioni
Al di fuori della problematica di datazione e dei dati particolari: è indubbio che conservare password in chiaro, senza alcuna forma di occultamento e senza il rispetto dei requisiti minimi di robustezza, non è una buona prassi, meno che mai se ad operare questa scelta è una struttura sanitaria.
Vi è poi un problema di aderenza alla legge. Il GDPR impedisce a qualsiasi soggetto di trattenere dati personali se sono ritenuti obsoleti. Tali dati devono essere distrutti o protetti dalla possibilità di identificare univocamente le identità degli interessati. Il GDPR a questo proposito scrive:
I dati personali sono: conservati in una forma che consenta l’identificazione degli interessati per un arco di tempo non superiore al conseguimento delle finalità per le quali sono trattati; i dati personali possono essere conservati per periodi più lunghi a condizione che siano trattati esclusivamente a fini di archiviazione nel pubblico interesse, di ricerca scientifica o storica o a fini statistici, conformemente all’articolo 89, paragrafo 1, fatta salva l’attuazione di misure tecniche e organizzative adeguate richieste dal presente regolamento a tutela dei diritti e delle libertà dell’interessato («limitazione della conservazione»);
GDPR, Art.5 Par. 1 comma E
L’articolo 89 paragrafo 1 dice, in merito alle metodologie di protezione:
Tali misure possono includere la pseudonimizzazione, purché le finalità in questione possano essere conseguite in tal modo. Qualora possano essere conseguite attraverso il trattamento ulteriore che non consenta o non consenta più di identificare l’interessato, tali finalità devono essere conseguite in tal modo.
GDPR, Art 89 Par. 1
Da quanto emergerebbe dalle evidenze pubblicate su internet le utenze, anche se obsolete, non avrebbero subito alcun processo di protezione del dato mantenendo i dati di identificazione dell’utente, rimanendo memorizzate all’interno dei sistemi dell’unità ospedaliera.
Aggiornamento del 22/05/2020 ore 22:00
Da un Tweet dell’utente Enrico Ferraris si evince che i dati potrebbero provenire dalla piattaforma di formazione online messa a disposizione della ENGITEL.
La cosa, tra l’altro, avrebbe riscontro anche nella descrizione riportata sul sito della ENGITEL
Attraverso il sistema di e-learning sviluppato da Engitel i dipendenti dell’Ospedale possono seguire i corsi organizzati dal servizio Prevenzione e Protezione e fare i questionari e gli esami obbligatori. Il sistema infatti prevede un’iscrizione ai corsi da parte del responsabile, la possibilità di visualizzare i veri e propri corsi (testi, immagini, video, ecc) e accedere ai quiz con domande/risposte.
Fonte: Engitel.com
Non si tratterebbe quindi di dati di pazienti, bensì di dati di corsisti che hanno partecipato alla piattaforma online della Engitel.
Aggiornamento del 22/05/2020 ore 19:41
LulzSec_ITA pubblica, come promesso, i link da cui scaricare i file CSV contenenti le banche dati trafugate dall’Ospedale San Raffaele di Milano. In molti di questi sono presenti password in chiaro senza alcun requisito di sicurezza. Quanto alle date è opportuno notare che, ad esempio, il file contrassegnato con il nome “SPP_codici_fiscali_accettazione.csv” contiene record con datazione che va dal 09 settembre 2009 fino al 06 febbraio 2020 (su campo “Data_Creazione”)
Anche da altri file provengono date riferite al 2020. Nella fattispecie dal file “dbHSR_ETI_1200_users.csv” come mostrato dall’immagine seguente. È da notare però come le date che si riferiscono al 2020 appartengano alla colonna “_tsM” che sembrerebbe suggerire il nome “Time Stamp Modified” ossia data di modifica.
In effetti, approfondendo l’analisi si scopre che, ad esempio, un utente elencato nella lista ha come data di creazione il 22/01/2009 e come data di modifica il 27/01/2020.
Aggiornamento del 22/05/2020 ore 11:10
Il collettivo hacker LulzSec_ITA ha pubblicato su internet un’immagine riportante alcune stringhe in cui sembrebbe presente un utente con nome 6Lulzsecita. Non ci sono riferimenti circa data e tempo dell’aggiunta ma il collettivo ha pubblicato un tweet nel quale chiede al San Raffaele se fossero sicuri di aver cancellato proprio tutto.
Aggiornamento del 21/05/2020 ore 18:43
L’Ospedale San Raffaele di Milano, sollecitato dai giornalisti tra cui Arturo Di Corinto, ha smentito l’efficacia dell’attacco pubblicato dal collettivo LulzSec_ITA in quanto le utenze sarebbero state dismesse anni prima.
Anche l’AGI pubblica al riguardo un pezzo a firma di Arcangelo Ròciola in cui viene dichiarato che:
Contattato dall’AGI, il nosocomio milanese conferma il tentativo di intrusione ma nega qualsiasi “accesso a dato sensibile”, definendo “inattendibili” le informazioni messe online.
La battaglia quindi si gioca su due fronti:
- I dati particolari che includono le informazioni che appartenevano all’ex categoria “dati sensibili”
- La data delle informazioni che sarebbe vetusta.
Dati particolari (dati sensibili)
In merito ai dati particolari per prima cosa è opportuno ricordare che il GDPR all’art.9 comma 1 dice:
È vietato trattare dati personali che rivelino l’origine razziale o etnica, le opinioni politiche, le convinzioni religiose o filosofiche, o l’appartenenza sindacale, nonché trattare dati genetici, dati biometrici intesi a identificare in modo univoco una persona fisica, dati relativi alla salute o alla vita sessuale o all’orientamento sessuale della persona
Fonte: GDPR
Non risulta che vi sia un’esplicito riferimento in merito alle categorie di cui sopra. Generalmente si confonde il “sesso” inteso come “genere” con l’orientamento sessuale, o dati riferiti, per l’appunto, alla vita sessuale della persona.
In merito alla data
Gli screenshot pubblicati dagli stessi hacker al momento non evidenziano date “recenti”. Fanno riferimento ad una datazione che, nel caso di un file sembra arrivare al 2017 mentre nel caso di un secondo file si spingerebbe fino al 2019 e riguarderebbe stringe SQL di un database.
Nel secondo caso la data viene dedotta dal testo della password adottata.
