Table of Contents Table of Contents
Previous Page  65 / 84 Next Page
Information
Show Menu
Previous Page 65 / 84 Next Page
Page Background

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