Di come gli attacchi nella sanità digitale non siano fanta-fiction

Paolo Perliti
Sep 2, 2018 · 7 min read

Qualche giorno fa mi sono imbattuto in un articolo interessante, il quale — lo ammetto — ha virato con decisione la mia attenzione sulle questioni legate alla sicurezza dei dati, dandomi una chiave di lettura diversa.

Murder, She Wrote —Armed response (Clinica di lusso)

Chiunque opera nell’informatica sanitaria sa bene che molti degli applicativi e dei dispositivi medici utilizzati negli ospedali (dalla radiologia per immagini alle macchine per le analisi di laboratorio, dalla gestione degli ordini all’archiviazione di referti clinici) dialogano verso il mondo esterno tramite una sorta di “esperanto” chiamato HL7, un protocollo di comunicazione che consente di strutturare i dati sanitari di un paziente affinché risultino immediatamente e universalmente intellegibili a qualsiasi altro programma (un po’ come l’inglese rappresenta ancora oggi la scelta preferenziale nel dialogo tra persone di nazionalità diversa, con la differenza che l’HL7 è uno standard ufficialmente riconosciuto a livello mondiale).

Gli standard HL7 vengono spesso implementati (ossia calati nella realtà quotidiana) secondo la logica del “minimo indispensabile”, procrastinando, vale a dire tralasciando, tutta la parte relativa alla sicurezza (“ce ne occuperemo dopo, adesso dobbiamo correre” — alzi la mano chi non l’ha mai detto/sentito dire!). Aspetto non proprio trascurabile se pensiamo che stiamo parlando di dati sensibili (i nostri dati sanitari, per esempio), magari trasmessi su canali non sicuri, privi di qualsiasi forma di autenticazione e/o validazione, e utilizzando testo in chiaro (per intenderci, la versione 2 di HL7 fa uso di tracciati di testo delimitati da pipe). È una consuetudine pericolosa, che rende i sistemi informativi ospedalieri vulnerabili e li espone a una serie di potenziali attacchi dall’esterno.

Esempio di un messaggio HL7v2 di accettazione, dimissione e trasferimento (ADT)

In realtà la privacy, per quanto importante*, passa in secondo piano rispetto alla possibile corruzione dell’integrità dei dati dolosa e premeditata, in grado di portare al peggioramento del quadro clinico di un degente, finanche alla morte.

Esagerazione? Fanta-fiction?
Non credo. Perché, come vedremo, in questo caso il colpevole (*allarme spoiler*) non è una macchina senziente o un hacker incappucciato in una stanza buia, ma lo stesso soggetto che dovrebbe preoccuparsi della nostra salute.

Partiamo dai fatti. Poiché non è prevista by design alcuna crittografia a livello di composizione dei messaggi da scambiare (i messaggi HL7, ricordiamolo, trasportano dati personali e/o sensibili, proprio come una mail o una raccomandata possono contenere informazioni private e riservate), il Comitato per gli Standard HL7 presuppone che tale operazione venga delegata alla fase di invio (ossia al di sotto del livello applicativo). In pratica lo standard di HL7 non fa altro che “suggerire” un incapsulamento dei messaggi mediante una “qualche forma di sicurezza” a livello di trasporto.
Tutto a posto, quindi? No, perché molti applicativi clinici che utilizzano il protocollo HL7 non offrono alcun supporto per la crittografia (e quando lo prevedono, magari risulta disabilitato in via predefinita). A peggiorare le cose, il fatto che gli standard HL7 non vincolano il destinatario del messaggio ad una verifica della fonte (il mittente), né all’autenticazione del mittente in fase di trasmissione delle informazioni.

In pratica, ad oggi, molti sistemi interoperativi acquisiscono, archiviano e confidano in una mole di dati clinici basandosi unicamente sulla fiducia.

A tutto questo va aggiunto che non tutti gli apparati che utilizzano HL7 (inclusi molti dispositivi medici) dispongono di aggiornamenti di sicurezza sufficientemente recenti — in alcuni casi non sono nemmeno stati progettati in origine per un aggiornamento del firmware (e l’obsolescenza informatica di un sistema interconnesso ormai si misura nell’ordine di qualche mese, un paio d’anni quando va bene) — oppure non vengono volutamente “patchati” per timore che un aggiornamento non andato a buon fine possa rendere inutilizzabile una macchina diagnostica, impattando sull’organizzazione del reparto operativo e sulle liste di attesa.

Fin qui lo scenario che rende il sistema informatico ospedaliero un obiettivo allettante per un attacco informatico.

E adesso il delitto perfetto.

Al Black Hat 2018 di Las Vegas, a inizio agosto, un team di tre ragazzi di San Diego (un esperto di sicurezza informatica, un medico di pronto soccorso, un pediatra e anestesista) ha presentato i risultati di una ricerca svolta presso l’Università della California.
Sfruttando proprio la mancanza nativa di crittografia e di autenticazione nelle implementazioni HL7 vagliate, Maxwell, Christian e Jeffrey hanno sviluppato un software in grado di eseguire un attacco automatico di tipo “man-in-the-middle” (un’intrusione in cui un soggetto terzo ritrasmette o altera segretamente la comunicazione tra due parti che credono di comunicare direttamente fra loro) al fine di manipolare maliziosamente i dati contenuti nei messaggi scambiati.

Attacco MITM con intercettazione e manipolazione di messaggi HL7

Intercettando la trasmissione di messaggi HL7 inviati da un dispositivo di analisi del sangue di laboratorio a un motore di interfaccia HL7 multipiattaforma, e successivamente modificando il messaggio HL7 per alterarne le informazioni contenute, sono riusciti a simulare l’innalzamento di valori nella norma a livelli compatibili con il quadro di una patologia più seria.

Comincia a delinearsi un quadro un po’ inquietante, vero? Alterazioni “trasparenti” come questa possono influenzare il processo decisionale clinico, facendo sì che il personale medico ritenga (erroneamente, eppure supportato e giustificato dalle evidenze numeriche) che un paziente abbia una malattia tale da richiedere un trattamento che può in realtà danneggiarlo (in quanto incompatibile col reale quadro clinico).

Nel caso specifico, l’attacco ha portato a suggerire la comparsa di chetoacidosi diabetica (DKA), una complicanza grave del diabete mellito caratterizzata da iperglicemia. Il trattamento della DKA prevede somministrazione di liquidi per via endovenosa e un’infusione di insulina, la quale, in un paziente non in DKA, causa il blocco dei livelli di glucosio nel sangue che potrebbe portare a crisi convulsive, coma e arresto cardiaco.

Condotto all’interno di una vera struttura sanitaria, potrebbe un attacco simile provocare un peggioramento (apparentemente inspiegabile) delle condizioni cliniche del paziente, fino a comportarne — in casi estremi — il decesso? Difficile forse, ma non del tutto impossibile.

A proposito, il software sviluppato dal team di San Diego si chiama “Pestilence”.

Una dimostrazione di “Pestilence” in azione

I recenti attacchi ransomware (ricordate WannaCry?) hanno attirato l’attenzione dei media (sempre alla ricerca di sensazionalismo facile) spingendo la comunità informatica a interrogarsi su cosa accadrebbe se minacce di questo tipo si diffondessero in una rete ospedaliera (pensate a uno specialista che non è in grado di refertare la visita che vi ha appena erogato perché il monitor del suo computer mostra una schermata nera e la scritta a caratteri gotici rossi “i dati nel tuo disco sono in mano nostra, per riaverli devi versare 600 dollari su questo conto cifrato”). Certo, le ricadute sarebbero negative — un’indisponibilità temporanea dei dati, qualche disagio a macchia di leopardo e un po’ di giustificato nervosismo da parte dei pazienti — ma ben poca cosa rispetto ad attacchi meno “appariscenti” e mirati a compromettere l’integrità dei dati (resto dell’idea che malfunzionamenti operativi o strutturali emergono immediatamente, per contro un’anomalia “strisciante” può richiedere mesi prima di manifestarsi in tutta la sua perniciosità).

Poiché il personale IT dell’ospedale è spesso non addestrato e non competente in termini di specifiche operative di interconnessione in rete tra i molteplici dispositivi e applicativi (talvolta non è nemmeno così netta la linea di demarcazione tra parte applicativa e sistemistica), è comprensibile che il “suggerimento” del Comitato HL7 non venga a conti fatti messo in pratica, restando dunque un’indicazione. Il risultato è che gli ospedali vengono lasciati a se stessi, dovendo barcamenarsi tra segmentazioni di rete, VLAN e VPN, e trovandosi a dover mettere in piedi soluzioni in-house (magari imperfette) per garantire l’integrità dei messaggi inviati attraverso la propria infrastruttura.

A chi pensa che qui si stia fantasticando di ipotesi remote o congetture romanzate faccio notare che questi scenari non sono più relegati a episodi di Black Mirror da molto tempo ormai. Fanno già parte della realtà.
Viviamo nell’epoca dell’Internet delle Cose (IoT) e, in questa fase d’innamoramento (nonché di transizione), è tutto nuovo: scenari inimmaginabili fino a un decennio fa, progressi scientifici senza precedenti; ma anche implicazioni e ricadute sociali non sempre chiare, processi organizzativi assodati che vanno ripensati e rimodularizzati in ragione di esigenze e modalità mutate, brecce tecnologiche che possono essere sfruttate come strumento di ricatto verso privati e istituzioni o per pilotare situazioni a proprio vantaggio (prima di gridare alla cospirazione e alla fantapolitica, andate a rileggervi il caso Litvinenko).
E se oggi ci preoccupiamo della sicurezza delle nostre transazioni elettroniche su un qualsiasi sito di e-commerce, perché mai non dovremmo farlo quando si parla dei dati relativi alle nostre condizioni di salute, supporto fondamentale per un medico che debba formulare risoluzioni sulla terapia da somministrarci?

La sottovalutazione degli aspetti legati alla sicurezza è una questione complicata: è figlia della carenza di un’informazione adeguata, di un’enfasi troppo sbilanciata a favore dell’interoperabilità senza tenere in debita considerazione le implicazioni dell’interconnettività, di una mancanza di visione a tutto tondo.

Siamo tutti chiamati (medici, pazienti, istituzioni) a una grande opera di sensibilizzazione in materia di protezione dei dati; occorre capire che non è più solo questione di essere infettati da un virus e ripristinare una copia di backup (o, alla peggio, riformattare tutto); è questione di potersi vedere rimosse le allergie dalla propria cartella clinica mentre siamo in sala operatoria. Da un giorno all’altro, senza preavviso.

* Con l’avvento del GDPR probabilmente anche la vostra ex vi avrà scritto per comunicarvi che ha modificato la sua privacy policy, invitandovi a prenderne visione.

Fonti:

Pestilential Protocol: How Unsecure HL7 Messages Threaten Patient Lives

80 to 0 in Under 5 Seconds: Falsifying a Medical Patient’s Vitals

La sicurezza dei dispositivi medici è diventato un problema serio: come rimediare

Health Level Seven (HL7)

HL7 Data Interfaces in Medical Environments

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade