EMB_86

EMBEDDED 86 • NOVEMBRE • 2022 56 ne delle CVE avvengono mediante uno sforzo congiun- to da parte della MITRE Corporation e del NVD (US National Vulnerability Database), un database gestito a cura dello US Department of Homeland Security. La scoperta di nuove CVE può essere il risultato di una cosiddetta analisi post-mortem, effettuata a seguito di un evento dannoso, oppure emergere dall’attività di in- dagine di un ingegnere coscienzioso che scopre un po- tenziale nuovo meccanismo di attacco, comunemente denominato exploit. Se da un lato è vero che la maggior parte degli exploit vengono scoperti senza la presenza di un iniziale danno rivelatore è evidente che, una volta che un exploit è stato reso pubblico mediante il mecca- nismo delle CVE, questo può essere facilmente sfrutta- to dagli hacker di tutto il mondo. Il tempismo, quindi, svolge un ruolo cruciale per l’efficacia della protezio- ne. Fortunatamente, il processo delle CVE riserva agli sviluppatori ed ai programmatori un congruo anticipo nella comunicazione, prima che l’exploit venga annun- ciato pubblicamente, in modo che essi possano agire tempestivamente per implementare le dovute correzio- ni e mantenere la sicurezza del dispositivo. Una volta che una CVE viene scoperta, ad essa viene assegnato un codice identificativo (CVE Identification ID). Inoltre, se si stabilisce che la CVE rappresenta una minaccia, ad essa viene anche assegnato, da parte del NVD, un punteggio (Vulnerability Score), costituito da un numero compreso tra 1 e 10; più alto è il numero, maggiore è la pericolosità della vulnerabilità per i di- spositivi interessati. Il database NVD contiene inoltre ogni altra informazione nota sulla problematica, come anche i link a tutti i siti pertinenti contenenti ulteriori approfondimenti oltre che, naturalmente, i meccanismi correttivi disponibili. Il principale beneficio offerto dal processo di reporting delle CVE è rappresentato dalla conoscenza del problema, delle sue potenziali correzio- ni, e dalla gravità della minaccia che esso può rappre- sentare nei confronti dei propri prodotti. Le vulnera- bilità di sicurezza possono produrre numerosi effetti avversi, tra i quali: - Perdita o alterazione di dati critici del paziente, il che potrebbe condurre a lesioni per il paziente stesso, oppure per il personale medico. - Esposizione di dati del cliente o dell’utilizzatore finale, il che può portare a furti di identità, a vio- lazioni delle normative sulla protezione delle infor- mazioni sanitarie (ad es. la normativa HIPAA negli Stati Uniti), o ad altre serie conseguenze. - Infiltrazione all’interno del dispositivo da parte di attori malintenzionati, il che può consentire l’inse- rimento di malware, la disattivazione dell’apparec- chio, l’estensione dell’infezione ad altre parti della rete della struttura sanitaria e così via. Le problematiche di sicurezza e la progettazione del prodotto Nello sviluppo di apparecchiature che devono essere il più sicure possibile, è importante distinguere tra dif- ferenti momenti di origine delle potenziali problemati- che di sicurezza: • Problematiche già note alla community al momen- to dello sviluppo del dispositivo • Problematiche scoperte dopo il rilascio del dispo- sitivo • Problematiche introdotte dal software scritto spe- cificamente per il dispositivo, a causa di un insuffi- ciente utilizzo di tecniche di prevenzione nel corso dello sviluppo La protezione del dispositivo dalle problematiche note Molti dei potenziali exploit utilizzabili dagli hacker per violare i dispositivi sono già noti alla comunità mon- diale degli esperti di sicurezza e sono già stati corretti. Ciononostante, è comunque possibile che un dispositi- vo medicale venga violato mediante una vulnerabilità già nota e corretta al momento del rilascio di quell’ap- parecchiatura: impedire che ciò accada richiede infatti un impegno. Tale impegno, tuttavia, sebbene oneroso, consentirà di risparmiare tempo, di proteggere la re- putazione del costruttore, nonché di limitare i costi e la potenziale esposizione a contenziosi legali in caso di violazioni. Gli enti regolatori, infatti, esigono che il SOFTWARE | SAFETY&SECURITY