Table of Contents Table of Contents
Previous Page  69 / 86 Next Page
Information
Show Menu
Previous Page 69 / 86 Next Page
Page Background

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