Per anni, la cybersecurity nei dispositivi medici è stata trattata come un’appendice della sicurezza elettrica o una nota a piè di pagina nella gestione del rischio. Tuttavia, con la guida definitiva del settembre 2023, la FDA ha inviato un messaggio inequivocabile: la sicurezza informatica è ora un pilastro fondamentale della Safety and Effectiveness del dispositivo, al pari della validazione clinica
Mentre l’MDR europeo si muove ancora su linee guida meno prescrittive, la FDA ha acquisito poteri legali stringenti (Sezione 524B del FD&C Act) che le permettono di rifiutare — senza appello — le sottomissioni che non dimostrino un controllo rigoroso del ciclo di vita della sicurezza. Non basta più dichiarare che il software è sicuro; occorre dimostrare l’esistenza di un Secure Product Development Framework (SPDF).
Che cos’è un “Cyber Device”: Identificare il perimetro
Il primo passo è capire se il proprio software rientri nella definizione legale di “Cyber Device”. La FDA ha tracciato un confine netto basato su tre caratteristiche fondamentali:
- Presenza di Software: Il dispositivo include software, firmware o logica programmabile, incluse App mediche (SaMD) e software integrato (SiMD)
- Capacità di Connessione: Il software può connettersi a Internet o a una rete tramite Wi-Fi, Bluetooth, connessioni cellulari o porte fisiche come USB e Ethernet
- Vulnerabilità alle Minacce: Il software è progettato in modo tale che una potenziale minaccia informatica potrebbe comprometterne la sicurezza o l’efficacia
Questa definizione è un vero game changer: la FDA non guarda più solo a cosa fa il dispositivo, ma a com’è costruito. In passato, molti produttori cercavano di minimizzare i rischi di cybersecurity sostenendo che il dispositivo fosse “chiuso”: oggi, la sola presenza di una porta USB per la manutenzione tecnica basta a far scattare l’etichetta di Cyber Device e i relativi obblighi legali
Security-by-Design: L’approccio SPDF
Se il concetto di Cyber Device definisce “chi” deve sottostare alle regole, il Secure Product Development Framework (SPDF) spiega “come” farlo. L’SPDF trasforma il fabbricante da semplice costruttore a custode della sicurezza informatica: non è un singolo documento, ma un vero e proprio ecosistema di processi che assicura che il dispositivo nasca e rimanga sicuro
In passato, l’approccio comune era: “Sviluppiamo il software e, alla fine, facciamo un test di sicurezza per vedere se regge”. L’SPDF ribalta questa logica, introducendo il concetto di Security-by-Design
I pilastri di questo framework includono:
- il Threat Modeling, che non è una semplice analisi dei rischi legati al malfunzionamento del software, ma un’analisi “avversariale” per anticipare le mosse di un attaccante prima ancora di scrivere il codice.
- la Gestione delle Vulnerabilità, che é il processo con cui si identificano e si correggono i punti deboli del software durante lo sviluppo dove si richiede, ad esempio, un monitoraggio costante delle librerie di terze parti,
- il Security Testing, dove si passa dalla semplice verifica funzionale a veri e propri Penetration Test per simulare attacchi reali.
Avere un SPDF significa che l’azienda non ha solo creato un prodotto sicuro “una tantum”, ma ha installato un motore organizzativo capace di rispondere alle minacce che ancora non esistono . Un software sicuro oggi potrebbe non esserlo più domani perché è stata scoperta una nuova vulnerabilità globale. Non basta più che un software medico sia utile: deve essere intrinsecamente resiliente
Il Cybersecurity Documentation Bundle
Al momento della sottomissione, il fabbricante deve consegnare una sorta di “carta d’identità digitale” del software. Se il pacchetto documentale è incompleto, si rischia il temuto Refuse to Accept. I componenti chiave sono:
- SBOM (Software Bill of Materials): Una lista dettagliata di ogni componente (librerie open-source, framework, moduli proprietari) che funge da etichetta degli ingredienti del software. La FDA vuole sapere cosa c’è “dentro” per capire quanto sia facile, per un attaccante, sfruttare una vulnerabilità nota in un componente che magari é stato scaricato da internet anni fa
- Vulnerability Assessment: Un’analisi critica che prova la ricerca di falle conosciute (CVE) nei componenti elencati nella SBOM
- Security Assessment di terze parti: Risultati di test eseguiti da esperti esterni per garantire un giudizio imparziale sulla robustezza del sistema
- Piano di Mitigazione: La strategia tecnica per rispondere a ogni minaccia identificata, bilanciando il rischio con difese solide
Spesso i produttori vedono la preparazione del Bundle come una “burocrazia inutile”. In realtà, è uno scudo legale e clinico. Se un domani una vulnerabilità venisse scoperta in uno dei componenti utilizzati all’interno del software, avere un Bundle aggiornato permette di sapere esattamente chi è colpito, come è stato protetto e quanto velocemente si può intervenire
Quindi il Bundle non è solo un requisito per superare l’esame dell’FDA: è la prova che é stato impostato un controllo totale sulla architettura digitale della applicazione software
Il Post-Market Management Plan
Per la FDA, il rilascio del software è solo l’inizio. Un dispositivo medico connesso deve essere sorvegliato per anni attraverso un Post-Market Management Plan. Questo piano deve prevedere un monitoraggio proattivo delle nuove vulnerabilità emergenti e stabilire tempistiche di patching rapide per le criticità
Infatti un software sicuro oggi potrebbe diventare vulnerabile tra sei mesi, perché magari, nel frattempo, gli hacker potrebbero aver scoperto una nuova falla in una delle librerie che sono state elencate nella SBOM
Tale piano dovrebbe essere basato su tre pilastri operativi:
- Monitoraggio Proattivo : L’azienda deve monitorare attivamente le fonti di informazioni sulle vulnerabilità (come i database CVE – Common Vulnerabilities and Exposures) in quanto se una libreria utilizzata viene segnalata come “insicura”, é necessario saperlo prima che diventi un rischio reale
- Tempistiche di Patching : che determina la modalità con cui si reagisce velocemente ad una situazione critica. Non avere un protocollo di rilascio rapido degli aggiornamenti, soprattutto in caso di criticità, è considerata una lacuna di sicurezza grave
- Coordinated Vulnerability Disclosure (CVD): é necessario avere un canale aperto verso il mondo dei ricercatori di sicurezza, hacker etici e utenti, attraverso il quale segnalare falle che permettono di risolvere i problemi prima che vengano sfruttati da malintenzionati
Il vero nodo critico però è come distribuire queste correzioni. Un dispositivo medico non è un PC che si aggiorna da solo nella notte. Spesso richiede validazioni cliniche e tecniche prima di poter essere installato . Per cui il piano deve descrivere come conciliare l’urgenza di una patch di sicurezza con la necessità di mantenere il dispositivo in uno stato di validazione clinica costante
Trasparenza per l’utente finale
La cybersecurity riguarda anche chi usa il dispositivo in prima linea. La FDA richiede che l’utente riceva informazioni attuabili (actionable information) per essere messo nelle condizioni di configurare, utilizzare e manutenere il dispositivo in modo sicuro
La documentazione deve perciò fare chiarezza su tre fronti critici:
- Configurazione Sicura: La documentazione deve spiegare chiaramente come disattivare funzioni non necessarie (es. porte di debug, connessioni Bluetooth non usate), come gestire le password di default (che devono essere obbligatoriamente cambiate) e come configurare il firewall della rete ospedaliera
- Supporto e Fine Vita : I produttori devono dichiarare esplicitamente quando il dispositivo smetterà di ricevere aggiornamenti di sicurezza : un dispositivo che non riceve più patch è, di fatto, un rischio crescente. Per questo motivo l’utente deve sapere in anticipo quanto tempo ha a disposizione prima di dover pianificare una sostituzione o un upgrade
- Gestione degli Incidenti: è necessario che le istruzioni per l’uso (IFU) contengano indicazioni chiare sui contatti di supporto, su come isolare il dispositivo dalla rete in caso di sospetto malware e su come ricevere gli aggiornamenti di sicurezza
Se un dispositivo è potenzialmente vulnerabile e il produttore non ha informato l’ospedale su come mitigare tale rischio (es. “non collegare questo dispositivo a reti non protette”), la responsabilità legale in caso di incidente ricade pesantemente sul fabbricante
Una documentazione trasparente non è solo un obbligo, ma uno strumento per costruire fiducia con la controparte sanitaria.
Conclusioni
GRAZIE PER L’ATTENZIONE
Commenti recenti