EO_488

XXXI MEDICAL 20 - SETTEMBRE 2020 SAFETY& SECURITY Linux (come anche altri importanti pacchetti software quali OpenSSL o SQLite) può interagire in modo im- prevedibile con ogni altro software in esecuzione nel sistema. A ciò si aggiunga il fatto che molte delle possi- bili anomalie sono difficili da identificare con normali attività di revisione del codice, o di testing, o mediante l’analisi statica dei sorgenti – sono quindi virtualmente non rilevabili, a meno di associare all’analisi del software anche tecniche di task switching e di inter-process com- munication . In sostanza, nessuna best practice (che defi- nisce un modus operandi basato sull’esperienza pregres- sa) è in grado di identificare ogni possibile anomalia o falla di sicurezza, e inoltre la maggior parte del software open source oggi in uso non è stato originariamente svi- luppato tenendo conto delle best practice odierne. I più importanti componenti software open-source pre- senti nei dispositivi di tutto il mondo sono comunque oggi molto più stabili e più sicuri di quanto non lo fosse- ro cinque anni fa. Ciò è dovuto soprattutto al duro e dili- gente lavoro svolto da ingegneri di tutto il mondo, impe- gnati nell’identificare e porre rimedio ai diversi possibili meccanismi di intrusione come anche all’impegno della comunità mondiale degli sviluppatori, concentrata su analoghi problemi nei propri progetti. Diventa quindi sempre più difficile trovare vulnerabilità all’interno di questa importante infrastruttura software, tuttavia l’atti- vità di controllo non cala di intensità. Individuare le problematiche di security Solitamente, le problematiche di security di Linux (ivi incluse quelle relative a software come OpenSSL) ven- gono scoperte dagli ingegneri o in modo casuale (scoprendo un errore nel corso delle proprie attività di sviluppo), oppure me- diante sforzi organizzati e con- giunti per la ricerca di possibili falle (con cosiddette attività di un “hacker” – white hat –, che conduce attività volte a violare i sistemi per testarne la sicurezza). Può inoltre capitare che una vul- nerabilità venga riconosciuta nel corso di una analisi post-mor- tem, appositamente condotta in seguito a un attacco. Chi individua uno di questi pro- blemi provvede ad informare la comunità di riferimento del componente violato, e nella maggior parte dei casi al suo in- serimento in un apposito dizio- nario pubblico delle cosiddette CVE (Common Vulnerability and Exposures). Tale di- zionario è gestito dal MITRE, una organizzazione lega- ta allo U.S. National Vulnerability Database (NVD), a sua volta gestito dal National Institute of Standards and Technology (NIST). Una volta che una nuova vulnerabilità è stata totalmen- te studiata e ne è stato anche individuato un rimedio, essa viene resa pubblica mediante l’inserimento nei det- ti elenchi di CVE; se la problematica è particolarmente seria, essa verrà successivamente dibattuta da parte della comunità mondiale specializzata nei temi legati alla se- curity. Questo è il momento in cui le apparecchiature medicali rischiano di essere più vulnerabili. Dal momen- to che la maggior parte delle vulnerabilità vengono sco- perte dai “buoni” e condivise con il resto del mondo, anche i “cattivi” hanno in questo momento l’occasione per venirne a conoscenza, e per sviluppare delle tecni- che che sfruttino la nuova falla appena scoperta. Ciò detto, rendere pubblico il problema è comunque indispensabile, poiché permette sia di allertare la comu- nità mondiale sulla sua esistenza sia di fornire il relativo rimedio, in modo tale che ogni organizzazione possa determinare se quella particolare vulnerabilità possa in- teressare anche i propri dispositivi. In tal caso sarà pos- sibile mitigare il rischio, provvedendo ad applicare le dovute modifiche prima che essi vengano attaccati. Non tutti saranno in grado di aggiornare per tempo i propri dispositivi, e quindi alcuni resteranno esposti a possibili attacchi, ma poiché difficilmente certi segreti rimango- no tali a lungo, questa trasparenza, a conti fatti, previene più problemi di quanti non ne causi. Un sistema operativo come Linux, pur non essendo classificabile tra i meccanismi di sicurezza, rende possibile la loro azione, e per questo motivo viene considerato un elemento del sistema di sicurezza