Sempre più spesso, in grandi organizzazioni, si parla di Sviluppo Sicuro del Codice (di seguito SSC) ovvero strumenti automatici a supporto dei programmatori che consentono di analizzare il software prodotto alla ricerca di vulnerabilità (tipicamente Owasp TOP10 o SANS25) da sanare prima del rilascio per rendere un software robusto a prova di intrusione.
Ma questo approccio premia davvero?
Esistono differenti modi di effettuare test di sicurezza applicativi, tutti basati nel rilevare errori di programmazione e di implementazione delle logiche applicative, ma la pratica dello sviluppo sicuro risulta sempre lo strato più delicato ed “insicuro” per produrre applicazioni “rock-solid”.
Occupandomi di verifiche di sicurezza, molto spesso mi sono imbattuto nel rilevare negli assessment impatti derivanti l’abuso di vulnerabilità non sanate nello SSC e molto spesso di tali vulnerabilità non vi era traccia nei report prodotti dagli strumenti di scansione statica. Ma prima di darvi una visione di dettaglio delle mie considerazioni dobbiamo porci una domanda: “che cosa è una scansione statica del codice?” Se per voi la risposta è “un tool che consente di identificare tutte le problematiche di sicurezza applicative che possono mettere a rischio la nostra applicazione”, siete completamente fuori strada.
Infatti gli strumenti di scansione statica (ma come vedremo successivamente anche dinamica, tralasciando quanto dichiarato dai fornitori dei tool) consentono di rilevare, con buona confidenza, vulnerabilità tipiche di depurazione dell’input quali XSS ed *Injection.
La tabella in calce (Fonte Owasp con qualche arricchimento) pone attenzione su questo problema, ma lascio a voi le dovute considerazioni.
Il problema principale, analizzando nel dettaglio le TOP10 Owasp, è che esistono vulnerabilità con impatti molto severi che non vengono rilevate dagli strumenti automatici e tali vulnerabilità sono comportamenti “applicativi” o errori (spesso orrori) di progettazione che non possono essere rilevati dagli strumenti di oggi.
Ad esempio Broken Authentication e Broken Access Control sono vettori di attacco formidabili che conducono ad impatti molto severi senza pensare ad una SQL Injection difficile da rilevare, quindi la scansione statica porta con se dei limiti in quanto:
Ma il “cattivo” non lavora in sviluppo ma in produzione e magari dalla Cina o dalla Russia, quindi potrebbe venire lecita la seconda domanda: “…ma se sposto il controllo in produzione utilizzando scanner dinamici potrei avere maggiori margini di confidenza?” La risposta è la stessa di quando si confronta un uomo e una macchina. Ma al netto della risposta la scansione dinamica (ad esempio gli strumenti di web scanning) sono utili come tutti i Vulnerability Assessment perché spostano il controllo più vicino all’attività illecita ma anche in questo caso sono presenti una serie di limitazioni da considerare:
Quindi siamo arrivati alla terza domanda: “… ma allora, forse è meglio lasciare perdere tutto per avviare dei Penetration Test Applicativi?”. Potrebbe essere una soluzione, ma anche in questo caso ci sono dei punti di attenzione da prendere in considerazione in quanto:
Quindi ci posizioniamo sulla quarta domanda …“e allora? … quale è la soluzione migliore da adottare?”, la risposta come al solito è “dipende” in quanto:
Concludendo, tutte e tre le tecniche (scansione statica, dinamica e PT Applicativo) sono tecniche che forniscono raramente risultati sovrapponibili, sarà la nostra esperienza metterle a fattor comune per individuare il livello di sovrapposizione e i delta delle vulnerabilità rilevate.
Il rischio Zero non esiste (pensiamo all’incidente del 28/09/2019 di Facebook denominato “view as” che ha portato al reset di 100mln di token) ma esiste il rischio “tollerabile”. Tutte e tre le tecniche dovranno quindi essere misurate per comprendere dove una sia migliore dell’altra, dove dovranno essere scelte tecniche miste, anche in funzione dell’appetibilità dei dati contenuti all’interno delle nostre applicazioni. Su applicazioni con dati critici, personalmente utilizzo tutte e tre le tecniche mentre su applicazioni con dati non critici, anche la sola scansione statica può risultare una scelta sensata.
E’ chiaro che chi sviluppa software non può limitarsi all’utilizzo di uno strumento di scansione ma deve essere guidato dall’esperienza e dall’applicazione delle migliori best practices conosciute in termini di sviluppo sicuro del codice. Per chi usa e abusa di forniture esterne, risulta di focale importanza l’aspetto contrattuale articolato su deliverable differenti a seconda della criticità dei sistemi.
Effettuando un paragone, mi viene da pensare ai guasti difficili da identificare in una macchina di oggi e i meccanici che collegano la centralina al computer e fanno solo quello che lui dice nelle attività di riparazione. Altri meccanici invece che conoscono a fondo tutte le componenti del veicolo comprendono che quanto fornito dallo scanner potrebbe essere una indicazione di un difetto presente in un’altra parte non chiaramente identificata, identificabile univocamente dalla loro esperienza.
Articolo a cura di Massimiliano Brolli
Nel panorama odierno della sicurezza informatica, la protezione degli endpoint rappresenta un obiettivo imprescindibile per…
I numeri dell’evento Oltre 1000 ospiti, 42 relatori, 20 interventi tematici e 5 Tavole Rotonde:…
Group-IB è un fornitore, con sede a Singapore, di sistemi ad elevata attendibilità per il…
Le interazioni di natura digitale, su rete pubblica o all’interno di reti private, hanno assunto…
La Commissione Europea ha di recente ricordato come “Artificial intelligence (AI) is not science fiction;…
Di seguito il programma della Cyber Crime Conference 2024, che avrà luogo a Roma nei…