11 / 28
XI
MEDICAL 15 -
OTTOBRE 2017
SICUREZZA
hardware tutte le funzioni necessarie per autenticare il
software prima dell’esecuzione, per codificare i dati a
riposo, per firmare i dati garantendone l’integrità, non-
ché per partizionare il dispositivo in modo da preveni-
re le intrusioni nel sistema da parte di malware. Tra le
fondamentali funzionalità di sicurezza da ricercare in un
SoC vi sono: il secure boot, i boot fuses, i motori critto-
grafici e il partizionamento del dispositivo.
Trend #2:
La crescente adozione di Linux come sistema operativo
Grazie alla maggiore disponibilità di piattaforme basate
su SoC multicore, gli sviluppatori del software sono ora
in grado di seguire la tendenza oggi domi-
nante nel mercato embedded, che è quella
di adottare Linux come sistema operativo
principale. Linux viene ormai utilizzato in
una vasta gamma di apparecchi medicali:
dagli strumenti di monitoraggio dei parametri vitali, ai
sistemi di monitoraggio specifici per letti ospedalieri,
fino alle più complesse apparecchiature di diagnostica
per immagini.
Alcuni dei motivi della crescente popolarità di Linux
sono:
lo sviluppo delle apparecchiature medicali.
-
tuite, che possono anche essere modificate e ridi-
-
ral Public License (GPL) che sotto altre licenze.
Intorno a Linux ruota un esteso ecosistema di fornitori
di semiconduttori, di schede e di software, che utilizzano
strumenti di sviluppo ed API (Application Programming
Interfaces) di provata efficacia.
-
luppo, funzioni per la connettività, per la sicurezza e la
grafica.
Poiché le apparecchiature medicali devono essere certi-
ficate a livello di sistema dalla FDA statunitense, la sfida
consiste soprattutto nel progettare un sistema capace di
far leva su quanto già presente in Linux, ma ottemperan-
do al contempo a tutti gli stringenti requisiti di sicurezza.
Trend #3:
La conformità ai requisiti di sicurezza e riservatezza introdotti
dalla IoT
La estesa connettività e l’appartenenza alla IoT rendono
questi sistemi multicore e multi-OS (in cui uno degli OS
è Linux) più facilmente accessibili ad attori esterni. La
garanzia che la connettività non comprometta i vincoli
di riservatezza è naturalmente un requisito fondamen-
tale. Tutti i trend di mercato tendono dunque inevita-
bilmente a portare in primo piano le questioni relative
alla sicurezza ed alla privacy, arrivando spesso anche a
rallentare l’adozione dei più moderni dispositivi medi-
cali dotati di funzionalità IoT.
Esistono, tuttavia, dei modi per affrontare queste pro-
blematiche.
Valutazione della “superficie di attacco” del dispositivo
-
recchio medicale connesso alla IoT è importante iden-
tificare quali siano le sue aree vulnerabili ad eventuali
attacchi. Tale “superficie di attacco” varia naturalmente
da un dispositivo all’altro ma, generalmente, più sofi-
sticato è il dispositivo, più estesa è la sua
superficie di attacco. È inoltre importante
rendersi conto che la maggior parte degli
attacchi portati ai dati, oggi, non mirano
tanto all’acquisizione dei dati stessi, quan-
to piuttosto alla possibilità di manipolarli.
Un esempio di manipolazione dei dati è rappresentato
dall’attacco ad un algoritmo che condiziona l’operativi-
tà dell’intero sistema su cui esso basa il proprio funzio-
namento, come nel caso di una applicazione bancaria
eseguita sullo sportello automatico ATM di una banca,
oppure su un terminale POS all’interno di un negozio.
Restando in campo medicale, un esempio potrebbe es-
sere la corruzione delle informazioni trasmesse da un
sensore che sono utilizzate per monitorare le funzioni
vitali di un paziente.
!
-
vono essere consapevoli dell’esistenza di tre stadi distinti
ma ugualmente critici del ciclo di vita dei dati all’interno
del dispositivo: dati a riposo, dati in uso e dati in transito.
Protezione dei dati a riposo
I requisiti per la protezione dei dati a riposo sono re-
lativi a tutto ciò che avviene nel dispositivo durante il
passaggio dallo stato di “spento” a quello di “acceso e
pienamente operativo”. Tra le problematiche da tenere
in considerazione in questa delicata fase vi sono le se-
guenti:
Archiviazione sicura
– Dov’è archiviata l’immagine del
codice da eseguire al boot? È su un supporto che può
essere crittografato? L’hardware supporta metodolo-
gie anti-manomissione che consentano di informare
il dispositivo se esso è stato violato? E in tal caso, esiste
la possibilità di impedirne il boot, che lo lascerebbe
in uno stato di vulnerabilità? Gli eseguibili sono stati
crittografati? E ancora: sarebbe possibile, per qualcu-
no che abbia accesso al dispositivo, rimuovere la EE-
PROM, oppure fare un dump della memoria, o tentare
di effettuare un reverse-engineering dell’applicazione?
Quellosanitarioèunsettore
soggetto a una stringente
regolamentazione