66 / 84
EMBEDDED
64 • MAGGIO • 2017
66
SOFTWARE
|
MEDICAL SECURITY
Regola n. 2 – Assicurarsi il che software non sia
stato manomesso (Fig. 2)
Ci sono molti modi di inserire un malware in un
dispositivo, ad esempio:
• Utilizzando un’interfaccia di debug hardware
come JTAG.
• Accedendo a interfacce di collaudo e debug, come
Telnet e FTP.
• Sfruttando protocolli di controllo sviluppati senza
considerare la sicurezza.
• Simulando un aggiornamento software che si di-
À 2
.
À
[
À
7
À 2 $
4
l’autenticazione è denominato “root-of-trust” e, per
i sistemi ad alta garanzia, deve trovarsi a livello
[
À 2 V
processo di avvio sicuro (secure boot) inizia dalla
À
'
software prima di consentirne l’esecuzione.
V
(
1
À '
-
'
[ 44
À ' 2 $
[
À
À
ogni volta che viene caricato. Ciò garantisce che un
dispositivo sia privo di malware e operi al livello
di qualità a cui è stato sviluppato. Di conseguenza,
per prevenire l’introduzione di malware, un boot si-
curo impedisce qualsiasi tentativo di accesso dalla
rete esterna: ciò soddisfa le nuove linee guida del-
l’FDA in cui si raccomanda che un dispositivo sia in
grado di accorgersi e segnalare se in esso è presente
software non valido.
Regola n. 3 – Proteggere i dati critici
Dati del paziente, parametri operativi chiave e per-
sino il software devono essere protetti, non solo nel
loro transito sulla rete, ma anche all’interno del
dispositivo. Questo lo si ottiene grazie a una pro-
gettazione della sicurezza che includa operazioni
4
' À '
software e utenti autenticati abbiano accesso ai
dati memorizzati.
La protezione dei dati in transito richiede che i dati
possano essere visualizzati solo dall’endpoint cor-
2 3
' À [
non fornisce una comunicazione sicura: protegge
solamente il collegamento dati, ma non i dati. Qual-
siasi altro sistema che sia in grado di accedere alla
rete wireless è anche in grado di visualizzare i pac-
chetti in forma decrittografata. La protezione dei
dati avviene tramite protocolli di sicurezza di rete,
come TLS, che consentano una comunicazione sicu-
ra tra client e server attraverso sessioni reciproca-
mente autenticate e crittografate in modo univoco.
Regola n. 4 – Proteggere le chiavi in modo affidabile
(Fig. 3)
5
44
' À
-
cazione devono essere protette, perché se queste
chiavi sono compromesse, un utente malintenzio-
nato potrebbe scoprire dati sensibili o emulare un
endpoint valido. Per questo motivo, le chiavi ven-
gono tenute isolate da software non attendibili.
Chiavi archiviate in memorie non volatili devono
sempre essere crittografate, e decrittografate solo
À
44
2
-
tezione dei dati del paziente è di primaria impor-
tanza, soprattutto per l’UE, l’utilizzo di kernel ad
alta garanzia e di moduli di sicurezza offrono anche
una separazione a strati per un progetto fail-safe.
Le chiavi devono essere protette, in fase di fabbri-
cazione e per tutto il ciclo di vita del prodotto, da
Fig. 2 – Autenticare il software dalla root-of-trust