Cybersecurity nei dispositivi medici connessi
Dal ransomware WannaCry agli attacchi alle pompe di insulina: i dispositivi medici connessi richiedono nuovi paradigmi di sicurezza multimodali.
Il National Health Service (NHS) britannico sta spingendo verso una trasformazione digitale radicale: senza digitalizzazione completa, il servizio sanitario nazionale non può reggere le crescenti pressioni sistemiche. Intelligenza artificiale, Internet of Medical Things (IoMT), digital twins — tutte tecnologie che promettono di rivoluzionare la medicina. Ma questa interconnessione crescente porta con sé un rischio poco discusso: i dispositivi medici connessi (CMD, Connected Medical Devices) stanno trasformando vulnerabilità informatiche in vere e proprie minacce cliniche dirette.
Non stiamo parlando solo di “rubare” dati sensibili: un attacco informatico può alterare il dosaggio di insulina di una pompa impiantata, bloccare un defibrillatore cardiaco, o manipolare i risultati di un monitor glicemico…con conseguenze facilmente immaginabili.
Il problema: attacchi bi-direzionali che attraversano i livelli
La maggior parte della ricerca sulla sicurezza dei dispositivi medici ha analizzato componenti isolati: il dispositivo fisico, la rete, il cloud. Ma gli attacchi moderni non rispettano queste divisioni. Sono bi-direzionali: possono originare a qualsiasi livello — fisico, rete o cloud — e propagarsi in entrambe le direzioni, attraversando l’intera infrastruttura dei dispositivi medici connessi.
Prendiamo, ad esempio, un sistema di gestione del diabete connesso: monitor glicemico continuo (CGM), pompa insulinica (IP), smartphone controller, cloud per l’analisi dei dati. Un attacco Man-In-The-Middle (MITM) può iniziare a livello di rete, intercettando la comunicazione non criptata tra CGM e pompa. Da lì, l’attaccante può propagare verso il basso (livello fisico), inviando comandi falsi alla pompa per alterare l’erogazione di insulina, o verso l’alto (livello cloud), manipolando i dati inviati ai sistemi di monitoraggio remoto. Il paziente e i clinici vedono dati falsificati, e prendono dunque decisioni su informazioni compromesse.
Nel 2017, il ransomware WannaCry ha colpito l’NHS partendo dal livello cloud e propagandosi verso il basso, disabilitando sistemi radiologici, cartelle cliniche elettroniche e dispositivi di monitoraggio. Oltre 13.500 appuntamenti ambulatoriali cancellati, servizi di emergenza deviati, ospedali costretti a procedure manuali. Nello stesso anno, l’attacco MedJack è partito invece dal livello fisico — workstation radiologiche e pompe infusionali vulnerabili — scalando verso l’alto nelle reti cloud ospedaliere attraverso interfacce non sicure.
Più recentemente, il CrowdStrike outage del 2024 ha dimostrato che anche errori non malevoli possono avere effetti devastanti: un aggiornamento difettoso nell’infrastruttura di cybersecurity ha propagato dal cloud ai sistemi clinici, disabilitando piattaforme di imaging, cartelle cliniche e monitor in centinaia di ospedali.
Rischi al livello fisico e di rete
I dispositivi medici connessi coprono uno spettro ampio: penne intelligenti per insulina, inalatori smart, ausili acustici connessi, monitor ECG indossabili, defibrillatori impiantabili (ICD), ecografi connessi. Ogni dispositivo presenta vulnerabilità diverse, ma il rischio che queste vulnerabilità vengano sfruttate con successo — causando danno al paziente — dipende da tre variabili: contesto, tecnica, invasività fisica.
La variabile contestuale riguarda l’ambiente di utilizzo: una pompa infusionale in terapia intensiva, cablata alla rete Ethernet ospedaliera sicura, presenta un rischio moderato. Lo stesso dispositivo operante in una clinica rurale tramite Wi-Fi pubblico o offline con supporti rimovibili presenta rischi molto più elevati.
La variabile tecnica riguarda come il dispositivo si connette: metodi a corto raggio come Bluetooth Low Energy (BLE) riducono il rischio di attacco remoto ma sono vulnerabili a interferenze locali. Connessioni a lungo raggio come Wi-Fi e cellulare aumentano la funzionalità ma espandono la superficie di attacco.
Un esempio concreto: nel 2019, Medtronic ha richiamato migliaia di pompe insuliniche MiniMed per vulnerabilità che permettevano a un attaccante nel raggio wireless di intercettare, modificare o iniettare dati, alterando le impostazioni della pompa e controllando l’erogazione di insulina. La vulnerabilità, classificata CVE-2019-10964, ha ricevuto un punteggio CVSS di 8,8/10 (severità alta) dal National Institute of Standards and Technology (NIST).
Nota: il CVSS quantifica la gravità delle vulnerabilità su scala 0,0-10,0, considerando sfruttabilità, impatto su confidenzialità/integrità/disponibilità, interazione utente richiesta.
La variabile fisica riguarda l’invasività del dispositivo: maggiore è l’integrazione con il corpo del paziente, più gravi sono le conseguenze di un attacco. Un flacone di pillole intelligente presenta rischio fisico minimo. Un pacemaker impiantato chirurgicamente, essenziale per la funzione cardiaca, rappresenta una minaccia critica se compromesso.
Rischi al livello cloud
Il cloud funge da nodo centrale per raccogliere, processare e instradare dati dai dispositivi medici. Si interfaccia con il livello fisico tramite protocolli di integrazione, tipicamente API (Application Programming Interfaces) o gateway on-premises (OPG). Mentre le vulnerabilità cloud sono spesso inquadrate come problemi software, firmware o hardware, la realtà è che il rischio di compromissione cloud — e la sua capacità di propagarsi a valle causando danno ai pazienti — è più accuratamente un problema socio-tecnico.
Questo significa che il rischio emerge dall’interazione tra persone (sviluppatori, operatori di sicurezza, dirigenti), processi organizzativi (verifica supply chain, gestione identità), e tecnologie (sistemi di gestione identità, dispositivi medici connessi).
Uno dei rischi più comuni è la misconfiguration a livello cloud (CLM): vulnerabilità nei meccanismi di autenticazione e controllo accessi che permettono agli attaccanti di bypassare la sicurezza e accedere alle API dei dispositivi, esponendo dati sensibili dei pazienti. Le cause di CLM nei grandi vendor di dispositivi medici sono meno legate a sistemi di autenticazione tecnicamente difettosi e più a sfide organizzative: carenza di professionisti qualificati, pratiche obsolete.
Un altro rischio critico sono i fallimenti nella gestione identità e accesso (IAM), specialmente i permessi eccessivi (EAP): utenti o servizi con accessi più ampi del necessario. Il principio del minimo privilegio (PoLP) offre un framework consolidato per mitigare questi rischi, ma la sua implementazione è spesso inadeguata. Cultura organizzativa, compiacenza, negligenza minano ulteriormente la sicurezza cloud.
Le minacce cross-domain sono un’altra preoccupazione significativa: attacchi provenienti dall’esterno dell’organizzazione attraverso vendor compromessi, strumenti di terze parti, sistemi di identità condivisi. L’attacco ransomware Synnovis nel 2024 ha colpito un fornitore terzo dell’NHS, causando gravi interruzioni a ospedali e cure primarie. Con l’NHS sempre più dipendente da servizi interconnessi e piattaforme esterne, la capacità di rilevare e rispondere a minacce cross-domain diventa cruciale.
Raccomandazioni alla MHRA: verso un framework unificato
La Medicines and Healthcare products Regulatory Agency (MHRA) britannica ha recentemente compiuto passi significativi per rafforzare cybersecurity e sicurezza dei dispositivi medici, inclusa l’implementazione del programma Future Regulation of Medical Devices (FRMD) per riformare le normative post-Brexit. Il programma si concentra su dispositivi digitali e connessi, dove la cybersecurity è una priorità. La Fase 1 (giugno 2025) ha rafforzato la sorveglianza post-market; la Fase 2 si concentra sui requisiti pre-market.
Tuttavia, gli standard attuali valutano principalmente i rischi all’interno di singoli livelli e non richiedono analisi sistematiche di minacce bi-direzionali o a cascata attraverso componenti interconnessi. I produttori di CMD dovrebbero essere obbligati a presentare valutazioni di rischio cross-layer esplicite come parte del processo di approvazione.
La FDA americana, pur non usando il termine “cross-layer security risk assessment” come artefatto discreto, richiede nelle sue linee guida pre-market aggiornate “security architecture views” che mostrano il dispositivo nel suo sistema più ampio, incluse reti e connessioni cloud, spiegando come i controlli mitigano il rischio attraverso quel sistema. Richiede anche una “Global System View” che identifica infrastruttura di aggiornamento, impatti su reti sanitarie, connessioni cloud.
La FDA richiede anche ai produttori di fornire una Software Bill of Materials (SBOM) come parte di questo processo, dando visibilità su tutti i componenti software e dipendenze usati nel dispositivo. La MHRA attualmente non richiede SBOM. Incorporarli come parte dell’evidenza SPDF migliorerebbe la trasparenza della supply chain e allineerebbe il Regno Unito alle pratiche internazionali.
La MHRA dovrebbe anche rafforzare la governance chiarendo le responsabilità a livello operativo: la normativa UK attuale non definisce chi è responsabile, accountable, consultato o informato (RACI) per attività chiave come patching, controllo accessi, recovery o gestione vulnerabilità una volta che un dispositivo connesso è implementato. Questo gap sfuma la linea tra dominio del prodotto (responsabilità del produttore) e dominio operativo (responsabilità dei provider sanitari).
Affrontare questo richiede superare barriere strutturali dove i regolatori, come la FDA, supervisionano i dispositivi ma non hanno mandato per regolare le reti ospedaliere. Senza coordinamento, regole di sicurezza troppo rigide possono accidentalmente bloccare nuove tecnologie medicali dal Regno Unito senza migliorare effettivamente la sicurezza del sistema.
Cybersecurity come mandato di sicurezza clinica
I dispositivi medici connessi stanno ridefinendo la cura nell’NHS, ma stanno anche dissolvendo il confine tra sicurezza informatica e sicurezza del paziente. Le vulnerabilità non sono più solo problemi IT: sono rischi clinici diretti. Un attacco informatico può uccidere tanto quanto un errore chirurgico.
Il paradigma attuale — che tratta la cybersecurity come una questione tecnologica secondaria, valutata layer per layer, senza visione d’insieme — è inadeguato. Serve un approccio unificato, socio-tecnico, che riconosca che la sicurezza dei dispositivi medici connessi dipende dall’interazione tra persone, processi organizzativi e tecnologie, attraverso tutti i livelli dell’infrastruttura.
La MHRA ha l’opportunità di guidare questa trasformazione: richiedendo valutazioni di rischio cross-layer come condizione di approvazione pre-market, imponendo framework secure-by-design con SBOM obbligatori, e definendo chiaramente le linee di responsabilità una volta che i dispositivi sono implementati. Queste misure stabilirebbero una base regolamentare coerente per la sicurezza dei CMD nel Regno Unito, trattando cybersecurity e sicurezza del paziente come una cosa sola.
Basato su: Toparti, O., Rajput, K., Darzi, A. & Ghafur, S. Cybersecurity in connected medical devices: a policy agenda for the NHS. npj Digital Medicine 9:204 (2026). https://doi.org/10.1038/s41746-026-02534-4