software
|
SAFETY & SECURITY
74
EMBEDDED
58 • NOVEMBRE • 2015
O
gni sistema dotato di un’interfaccia ver-
so il mondo esterno deve affrontare problemi di
sicurezza di notevole entità. In particolar modo,
l’accessibilità attraverso Internet richiede una
strategia che permetta di contrastare gli attacchi
condotti non un nucleo ristretto di specialisti, ma
dal mondo degli hacker nel suo complesso
Nel campo del software embedded per applicazio-
ni “safety-critical” (un sistema si definisce safety-
critical se un suo malfunzionamento può causare
danni fisici a persone a all’ambiente circostante),
questi problemi legati alla protezione sono spes-
so percepiti come un dominio separato rispetto
a quello della sicurezza funzionale. Ma nel 2011
Barnaby Jack, un ricercatore nel settore del-
la sicurezza, tramite un software e un’antenna
modificata condusse un attacco in modalità wi-
reless e prese il controllo delle pompe di insulina
impiantabili di Medtronics e dimostrò come una
di tali pompe potesse essere controllata per rila-
sciare una dose fatale di insulina. Chiaramente
questa vulnerabilità nella protezione (security)
mette a rischio la sicurezza (safety) dei pazienti
affetti da diabete e in un contesto come questo la
differenza tra i due termini non è chiaramente
distinguibile.
Altri esempi di sinergia tra i termini “security”
e “safety” sono reperibili nel mondo del softwa-
re per applicazioni “safety-critical”. Quando una
violazione della protezione può interferire con il
funzionamento di sistemi e/o infrastrutture cri-
tiche, come ad esempio treni, stabilimenti indu-
striali, servizi di pubblica utilità o autovetture,
la distinzione tra sicurezza e protezione diventa
priva di significato.
Una situazione di questo tipo è implicitamente
riconosciuta dagli standard che disciplinano la
sicurezza.
Nel momento in cui si verifica la possibilità che
si verifichino vulnerabilità nella protezione che
potrebbero minacciare la sicurezza, standard
come IEC 61508 / EN 61508 (per l’industria di
processo), ISO 26262 (per il settore automotive),
IEC 62304 / EN 62304 (per il settore medicale),
IEC 62278 / EN 50128 (per il settore ferroviario)
e DO-178 (per il settore aerospaziale) richiedo-
no requisiti di sicurezza funzionale per poterle
affrontare queste minacce. Senza eccezione alcu-
na, tutti questi standard che disciplinano la si-
Software
per applicazioni
“safety”
e “security-
critical”: alcune
considerazioni
Nonostante la tradizionale
divisione tra lo sviluppo di
applicazioni connesse alla “safety”
e quelle correlate alla “security”,
un’analisi degli standard e delle
norme di codifica suggerisce che
vi sono notevoli sovrapposizioni
tra le migliori procedure adottate
nei due casi
Mark Pitchford
Technical manager, EMEA
Lynx Software Technologies