75 / 84
75
SAFETY & SECURITY |
software
EMBEDDED
58 • NOVEMBRE • 2015
curezza richiedono che le funzioni di sicurezza
del software siano identificate e specificate nei
requisiti di sicurezza del sistema, classificate in
funzione della loro criticità, progettate facendo
riferimento a tale classificazione, sviluppate e
verificate per dimostrare la conformità con i re-
quisiti di sicurezza del sistema.
Le migliori procedure per la “safety” e la “security”:
un approccio comune
Questa comunanza di intenti tra “safety” e “secu-
rity” è evidente in molti altri modi. Per esempio
nel settore del software a elevata integrità, gli
standard focalizzati sulla sicurezza sono menzio-
nati da parecchi Enti come una solida base per
il software per applicazioni “security-critical”, a
condizione che le considerazioni di rischio per la
protezione completino la valutazione dei rischi
per la sicurezza.
Un esempio di questo tipo è riscontrabile nelle
raccomandazioni stilate dall’” Automation Stan-
dards Compliance Institute”. Esse suggeriscono
l’implementazione di un Software Development
Security Assessment (1) , facendo riferimento a
standard di sicurezza esistenti come IEC 61508
e sovrapponendo misure di sicurezza implemen-
tate seguendo le migliori procedure possibili
(best practice). In questo modo è facile scorgere
lo sviluppo di un’applicazione sicura e protetta.
Un altro esempio di sovrapposizione delle “best
practice” per la “safety” e la “security” lo si ot-
tiene dal confronto tra gli standard IEC 61508 e
ISO 15408 (che definisce i criteri per la valuta-
zione della sicurezza in ambito IT). Esaminando
quest’ultimo standard appare chiara la similitu-
dine tra lo sviluppo del software legato alla “sa-
fety” e quello legato alla “security”: i sette livelli
EAL (Evaluation Testing Assurance Levels) di
ISO 15408 sono praticamente analoghi al con-
cetto di SIL Safety Integrity Levels) adottato
dallo standard ISO 61508.
Nel momento dello sviluppo del codice, entram-
bi gli standard appena sopra menzionati fanno
riferimento agli standard di codifica come mezzi
per ottenere un software caratterizzato da eleva-
ta integrità. Esempi di sottoinsieme di linguaggi
come CERT C, secureC e MISRA C:2012 eviden-
ziano ancora una volta una notevole sovrappo-
sizione tra i principi dello sviluppo software fo-
calizzati rispettivamente sulla “security” e sulla
“safety”.
Applicazione dei principi dell’LPSK per soddisfare
i requisiti della sicurezza funzionale
Se i requisiti di sicurezza funzionale richiedono
una difesa contro le vulnerabilità della protezio-
Fig. 1 – L’abbinamento della sicurezza fornita da un SK e la praticità di un hypervisor consente
di soddisfare molti requisiti di sicurezza funzionale legati alla protezione