93 / 100
93
EMBEDDED
61 • SETTEMBRE • 2016
SECURITY |
SOFTWARE
À 9
À
'
essere facilmente decriptata da un hacker sem-
plicemente scaricando un copia dell’immagine
À 9
À
autoprodotto distribuito dalla fabbrica, l’utente
'
-
mento di rischio è rappresen-
tato dal fatto che le immagini
À 9
molti software e librerie di terze
parti che presentano frequenti
À`
La linea guida Owasp sottolinea
nella sua Top Ten che quando
si utilizzano delle componenti
con vulnerabilità note il loro
aggiornamento a nuove versioni
è un fattore critico. In alcun casi
vengono invece usati kernel non
aggiornati, esponendo l’intero
dispositivo alle vulnerabilità in essi contenute.
*
À
?
£
Y
À 9 £
come l’impiego di indirizzi ip e nomi host pubblici
'
è molto comodo perché consente di avere ristretti
tempi di prototipaggio e realizzazione. È opportu-
À
web server embedded (ad esempio in immagini
À 9
Y
devono essere impostati per essere eseguiti con
utente privilegiato (es. superuser root). Eseguire
un servizio di web server con elevati privilegi non
necessari è un comportamento rischioso in quan-
'
compromessa trovando una vulnerabilità in una di
queste componenti.
Soluzioni
Innanzitutto occorre determinare quali possono
essere i dati e gli scenari di rischio da fronteggiare
effettuando una adeguata analisi dei rischi.
È indispensabile inoltre analizzare bene e nel caso
rivedere i processi e le procedure di sviluppo e
À 9
À
build
management
(ad esempio processo di build esegui-
to interamente come superuser) all’
infrastructu-
re management
(realizzare host raggiungibili su
reti pubbliche e così via) al
release management
(mancata rimozione di username e hostname dalla
release di produzione e così via). Si deve operare
poi implementando i necessari accorgimenti a
livello di software per ottenere livelli intrinseci
di sicurezza elevati e proteggendo i dati duran-
te la memorizzazione degli stessi nel dispositivo
e il loro trasferimento. In fase
di progettazione e realizzazione
software è indispensabile crea-
re codice dotato di controlli che
minimizzino il rischio di essere
vulnerabile (ad esempio utiliz-
zando le linee guida Owasp per
lo sviluppo di codice sicuro), e
laddove si utilizzino componenti
o librerie esterne, utilizzare le
À 9
-
tware per garantire che almeno
le vulnerabilità universalmente
note risultino adeguatamente
coperte. Se fattibile, è anche opportuno prevedere
sempre la possibilità di consentire al dispositivo di
effettuare aggiornamenti software per garantire
À
anche in futuro. È consigliabile impiegare processi
À
À
(come utente, come amministratore e così via) alle
varie funzionalità, prediligendo ovunque possibile
accessi in modalità non-superuser. Per i processi
di autenticazione è opportuno evitare di utilizzare
le password di default per i componenti esterni,
impiegando invece password complesse (combina-
zioni di maiuscole, minuscole, numeri e caratteri
speciali) di lunghezza adeguata o, meglio ancora
se possibile, meccanismi basati su scambio di cer-
À À
§
e utilizzare zone crittografate, in particolare per i
dati e il bootloader. Anche nel trasferimento dei
dati (via cavo o wireless) va considerata la possibi-
À &
esempio TLS - Transport Layer Security, IPSEC
< + X Z<
À
<* ^ £
À [
-
À 9
À
test attraverso tool e terze parti specializzate, per
determinare e correggere in tempo i bug eventual-
mente trovati.
Le linee guida Owasp sono state
create per lo sviluppo di codice
sicuro