Un’intelligenza esecutiva per la sicurezza del software

• 
• Tweet
• Pin It
• Condividi per email

È convinzione diffusa che la sola applicazione dell’analisi statica basti ad evidenziare e debellare i problemi di sicurezza più comuni.

Tuttavia, dato l’elevato numero di falsi positivi segnalati quando si utilizza l’analisi statica, capire se si è rilevato un errore reale è un processo che richiede tempo, e le modifiche messe in atto potrebbero proprio aver nascosto l’errore sotto un falso-negativo. Ma quali sono le alternative?

Fig. 1 – Un caso in cui l’analisi statica può non rilevare il problema

Scopo di questo articolo è evidenziare i vantaggi derivanti dall’analisi dinamica per il rilevamento di potenziali vulnerabilità nei moderni ambienti embedded. Esso descrive anche come l’abbinamento tra l’analisi statica e quella dinamica permetta di creare “actionable intelligence” per gli sviluppatori, e consenta loro di verificare rapidamente l’assenza di ovvi problemi di affidabilità, sullo stile dei siti di rating tipo “Morningstar” della Sicurezza Informatica⁽¹⁾.

Siamo tutti venuti a patti con l’idea di dispositivi in un mondo interconnesso, con la sua incarnazione più recente che cade sotto l’appellativo di “Internet of Things”. Mentre contempliamo un mondo in cui ogni dispositivo è connesso a internet, vi sono crescenti preoccupazioni circa la sicurezza dei nodi di comunicazione e dei loro sistemi di controllo centralizzato.

La società di analisi di settore Gartner prevede che entro il 2020 i terminali IoT con caratteristiche di sicurezza, sia stand-alone che basati su hardware e software, cresceranno dai 103 milioni installati nel 2013 ad un tasso annuale composito del 33,4%, raggiungendo una popolazione globale di 775 milioni⁽²⁾. Molti di questi dispositivi saranno in sistemi racchiusi all’interno di dispositivi e apparecchiature.

Fig. 2 – Esempio di un altro errore, evidenziato nella ”Analytics Dashboard” di VectorCAST

Tuttavia, come conseguenza Gartner prevede anche che il 25% degli attacchi alla sicurezza identificati nelle aziende coinvolgerà dispositivi IoT e che, addirittura entro il 2018, oltre il 50% dei produttori di dispositivi IoT sarà nell’incapacità di affrontare le minacce a causa delle deboli pratiche di sicurezza⁽³⁾.

Le vulnerabilità della sicurezza possono originarsi in un prodotto non appena siano state scrittele prime righe di codice, e il vero pericolo è che non vengano rilevate se non quando è troppo tardi. Questa vulnerabilità può rappresentare un serio pericolo, che può essere sfruttato quando il dispositivo fisico è in funzione o è stato già distribuito sul campo.

Di conseguenza, lo sviluppo di applicazioni sicure e di elevata qualità richiede una vigilanza costante in tutte le fasi di sviluppo. Vale a dire che è necessario utilizzare strumenti in grado di rilevare possibili vulnerabilità già durante la scrittura del codice, l’integrazione dei moduli, e l’analisi dei file binari compilati sul target hardware.

L’adozione di un tool di analisi statica è una buona scelta in teoria, e tra gli sviluppatori è comune voler conoscere i seguenti principi: a) abbiamo dei problemi di qualunque tipo?, b) quanti? e c) quali e dove sono? Valutare il codice con un analizzatore statico vi darà qualche indicazione, ma non è questa la soluzione “pigliatutto”, soprattutto quando è la sicurezza a essere in gioco.

Gli strumenti di analisi statica analizzano sintassi, semantica, stima delle variabili, nonché controllo e flusso dati per identificare problemi legati al codice. I risultati dell’analisi statica, solitamente basati su regole e gestiti tardivamente nel ciclo di sviluppo, quando vengono usati da soli possono creare potenziali falsi positivi, ovvero nascondendo l’errore reale sotto un falso negativo.

Nell’esempio di figura 1, tratto dal Web-server Open Source che alimenta parte di Wikipedia⁽⁴⁾, abbiamo un esempio di codice che contiene una vulnerabilità del puntatore NULL potenzialmente sfruttabile.

Mentre uno delle variabili di ingresso viene controllata se è NULL, l’altra viene utilizzata senza tale verifica. Nei test con alcuni comuni strumenti di analisi statica Open Source, questo problema è stato ignorato, mentre l’analizzatore commerciale Lintlo ha rilevato ma solo come un possibile errore. Tuttavia, utilizzando uno strumento di analisi dinamica, è stata immediatamente trovata la violazione Segmentation Fault che, se non corretta, avrebbe potuto essere sfruttata portando ad un indesiderato impatto funzionale⁽⁵⁾.

L’analisi dinamica abbinata all’analisi statica può dare un immediato ritorno. L’analisi dinamica del programma è diversa dato che è attuata mediante l’esecuzione di programmi su una architettura del processore, vera e propria o simulata. Questo modalità di analisi del software sottopone il programma ad un numero di input di prova sufficienti a riprodurre le condizioni reali ed eccezionali, così il suo comportamento può essere osservato e testato per le sue falle nella sicurezza.

Esiste un elenco formale, sviluppato dalla comunità e che gode di alta considerazione, nota come “Common Weakness Enumeration” (CWE) che serve come linguaggio comune per la descrizione dei punti deboli della sicurezza software, nell’architettura e nel codice, ed è un lessico comune, standard, per gli strumenti di rilevazione di tali potenziali punti deboli.

Nella tassonomia CWE, ci sono numerosi punti deboli dove l’uso di prove dinamiche può evidenziare le vulnerabilità, in particolare qualsiasi cosa manifesti errori gravi come l’uso di puntatori NULL, Buffer Over- oUnder-Runs, e Stack Overflow.

Nella figura 2 è stato evidenziato un problema rilevato nel codice di uno dei nostri clienti del settore Automotive. Nel codice in questione, sono stati effettuati i vari controlli nei confronti di una variabile, che è stata poi ancora utilizzata nel denominatore di un’espressione matematica. Anche in questo caso, lasciata così senza controllo, questa debolezza potrebbe avere un impatto reale sul business dell’azienda. Mentre gli strumenti statici possono solo dare un suggerimento sulla potenziale esistenza di tali errori, con l’analisi dinamica possiamo costruire un test e dimostrare immediatamente la vulnerabilità.

Ogni team di sviluppo ha bisogno di un processo per raggiungere i propri obiettivi di sicurezza per le applicazioni. Credo che gli sviluppatori abbiano bisogno di prendere in considerazione il fatto che ci sono tre fasi per la creazione di un sistema che gestisca il rilevamento delle vulnerabilità. In primo luogo, costruire un portfolio completo di tutti i componenti / moduli nell’applicazione incluso qualsiasi codice precedente e di terze parti ed assumerlo come riferimento per evidenziare cosa è stato testato e cosa deve essere fatto.

In secondo luogo, una volta che i dati siano stati raccolti gli sviluppatori hanno bisogno di visibilità su eventuali vulnerabilità nell’applicazione attraverso l’esecuzione dell’analisi statica e dinamica. Ciò permetterà quindi agli sviluppatori di comprendere i rischi presenti nell’applicazione.

Infine, da questo punto in poi, gli sviluppatori possono decidere di aumentare la quantità di copertura del codice, dando visibilità alla qualità del loro software. Il vantaggio di tutto questo lavoro sta nel fatto che l’applicazione sarà di facile manutenzione e le eventuali modifiche al codice potranno essere rianalizzate nel minor tempo possibile.

In conclusione, per i team di sviluppo è importante comprendere che nessun singolo strumento si adatta ad ogni circostanza, e che l’approccio più pragmatico è quello di utilizzare più strumenti. L’analisi statica ha il suo ruolo, ma l’esecuzione dinamica può trovare alcune vulnerabilità con maggiore certezza e, insieme, creeranno un prodotto più sicuro.

Note

1. http://www.securitymetrics.org/attachments/Metricon-2-Lee-Chess-Enterprise-Metrics.ppt
2. http://www.gartner.com/newsroom/id/3291817    
3. http://www.gartner.com/newsroom/id/3291817    
4. https://www.lighttpd.net/2007/4/4/powered-by-lighttpd/
5. CWE-476 -: NULL Pointer Dereference

Niroshan Rajadurai, VectorCast

• 
• Tweet
• Pin It
• Condividi per email