65
EMBEDDED
64 • MAGGIO • 2017
MEDICAL SECURITY |
SOFTWARE
za. L’FDA ha pubblicato una guida formale sulla
gestione della sicurezza per entrambe le fasi di pre-
market e post-market (prima e dopo l’immissione
in commercio) di un dispositivo medicale. Un ele-
mento chiave nella guida di pre-market afferma
che la gestione dei rischi di sicurezza dovrebbe
far parte dell’analisi dei rischi, mentre la guida di
post-market si riferisce chiaramente alla necessità
di procedure di aggiornamento software sicure. La
nuova guida di post-market stabilisce che in ge-
nerale non sarà richiesta alcuna autorizzazione o
4
|T)
À
-
tware sui dispositivi medicali
che abbiano come unico scopo
l’aggiornamento delle carat-
teristiche di sicurezza infor-
matica nel campo. Questo per
consentire una risposta rapida
alle minacce emergenti. Spin-
gendosi oltre, la FDA pubblicò
un comunicato sulla sicurezza
motivato, per la prima volta,
dalle vulnerabilità di sicurez-
za informatica in un tipo di
pompa di infusione. Questo
comunicato raccomandava di
sospendere l’utilizzo di diversi
dispositivi già approvati uni-
camente sulla base della vul-
nerabilità agli attacchi.
Garantire una progettazione
sicura dei dispositivi medicali
Mentre gli sviluppatori di si-
stemi medicali hanno espe-
rienza nello sviluppo di si-
stemi in grado di soddisfare i
requisiti di sicurezza funzionale, la sicurezza infor-
matica aggiunge un’altra dimensione al processo di
progettazione. È consigliabile consultare degli spe-
cialisti per valutare le diverse scelte da operare al
À
'' '
'
44
-
to al prodotto. INTEGRITY Security Services (ISS),
società Green Hills Software, permette agli utenti
di soddisfare i requisiti dell’FDA e dell’UE con una
progettazione embedded della sicurezza di tipo end-
to-end. ISS offre assistenza agli sviluppatori di di-
spositivi medicali nell’applicazione delle seguenti
“Cinque regole per la sicurezza embedded”.
Regola n. 1 – Comunicare senza fidarsi della rete
(Fig. 1)
C’è unapercentuale crescente di dispositivimedicali
sempre connessi, e molti dispositivi devono rima-
nere connessi per le attività di manutenzione o di
aggiornamento. Se è vero che la protezione dei dati
del paziente è essenziale, sono altrettanto fonda-
mentali parametri operativi come i limiti massimi
delle dosi nelle pompe di infusione. Anche in assen-
za di dati sensibili, quando si è connessi a una rete
ospedaliera, si può essere preda di attacchi da parte
di hacker che tentano di intrufolarsi.
Per prevenire violazioni della sicurezza, è necessa-
rio autenticare tutti gli end-point, inclusi il dispo-
sitivo stesso, qualsiasi utente umano che interagi-
sca con esso e qualunque altro sistema connesso.
Una progettazione sicura non dovrebbe mai pre-
supporre che gli utenti e il software di controllo
siano validi solo perché i messaggi ricevuti hanno
il formato corretto.
Parlando delle pompe di infusione, che erano l’og-
getto del comunicato di sicurezza dell’FDA, un
\
y
À
protocollo e inviare comandi formalmente corretti
che avrebbero permesso di somministrare al pa-
ziente una dose letale di farmaco. L’autenticazione
protegge i dispositivi medicali dall’esecuzione di co-
mandi provenienti da fonti sconosciute.
Fig. 1 – Non fidarsi della rete