I controlli di sicurezza sul codice possono nascondere diverse insidie: procedere con criterio e rigore scientifico è necessario per evitare errori che possano cambiare il risultato.
Ci racconta le modalità di analisi, gli strumenti di supporto e i risultati di questa corposa attività, Elisa Bertino, professore ordinario di informatica negli Usa alla Purdue University, ruolo in cui si occupa di sicurezza e privacy delle reti cellulari, sicurezza delle applicazioni mobili e dei sistemi IoT, architetture zero-trust e tecniche di apprendimento automatico per la sicurezza informatica.
È considerata un’autorità nel campo della sicurezza informatica.
Indice degli argomenti
Test di sicurezza del codice
Si intitola “The persistent problem of software insecurity” il paper di ricerca pubblicato dalla IEEE Security and Privacy e fulcro della lectio magistralis tenuta da Elisa Bertino su questo stesso tema, in occasione del conferimento del dottorato di ricerca Honoris Causa in informatica dall’Università degli Studi di Salerno nel 2023, anno in cui proprio questo ateneo ha celebrato il cinquantenario del corso di laurea in informatica (già scienze dell’informazione).
L’importanza spiegata dalla professoressa ricercatrice in materia d’insicurezza del codice che permane e perdura nel tempo, è tutto concentrata nelle parole “persistenza” e “insicurezza”, riferite al codice digitale; i termini infatti, rispettivamente sottolineano come, a fronte di una continua estensione della digitalizzazione (quindi del codice digitale), in diversi contesti, ambiti e settori di mercato e tecnologici, il problema del codice non sicuro, resta insistente e assiduo.
Il ruolo del CISO in Italia, tra competenze tecniche e normative: le sfide da affrontare
L’insicurezza che persiste
Esempi significativi di trasformazione digitale risiedono nella “softwarizzazione” delle reti informatiche, comprese le reti di comunicazione wireless, nello sviluppo forsennato di app per dispositivi mobili e di applicazioni e componenti per i contesti cloud. Il tema del codice non sicuro è presente da anni e sebbene la pratica del patching cerchi di ovviare e chiudere alcune falle di sicurezza il problema sembra più radicato e più “strutturale”.
Ma andiamo con ordine e proviamo a capire grazie alla professoressa Bertino il tipo di test che è necessario svolgere per sondare il grado di non sicurezza del codice odierno. “Eseguiamo delle analisi di vario tipo sul codice sorgente e/o oggetto per individuare difetti (bugs) nel codice che possono rappresentare delle vulnerabilità, ovvero difetti che possono essere sfruttati da attacchi”, spiega la docente.
Le tecniche di analisi
E continua: “Il nostro lavoro considera specifiche categorie di difetti: nella gestione della memoria, nella verifica dei certificati da parte delle applicazioni, nella generazione di numeri pseudo-random (spesso usati per one-time authentication tokens) e usa diversi strumenti di analisi a seconda del tipo di vulnerabilità considerata”.
“Le tecniche che usiamo sono di vario tipo ed includono analisi statica e dinamica del codice e/o di “code slicing” (permettono di determinare le istruzioni di un programma che hanno un impatto sui valori di un una o più variabili ad un certo punto di interesse, chiamato criterio di slicing n.d.r.), ma anche tecniche di machine learning”.
“In alcuni casi usiamo anche tutte le precedenti fra loro combinate. Per esempio, in recente lavoro focalizzato sull’individuazione automatica di errori nella gestione della memoria in programmi open source di grandi dimensioni, abbiamo usato una tecnica di Natural Language processing (NLP) basata su machine learning in combinazione con tecniche di analisi statica”.
Luoghi digitali non sicuri
Ovunque la digitalizzazione sia adottata, si verifica una trasformazione che introduce tecnologia scritta con codice di programmazione. Poco più di un decennio fa principali problemi di sicurezza venivano indirizzati mediante la protezione del perimetro a mezzo di un server firewall, mantenendo aggiornate le autorizzazioni per i dispositivi e le posizioni fisiche ed effettuando un utilizzo di internet perlopiù limitato ad una visibilità sul web e ad un ristretto insieme di comunicazioni.
Oggi l’interconnessione globale di dispositivi e risorse smart garantisce l’accesso alle informazioni digitalizzate praticamente da dovunque in qualsiasi momento, ma questo significa anche che il software capace di abilitare tutto questo, è cresciuto esponenzialmente in termini di reti, protocolli, applicazioni abilitanti.
Le categorie a rischio
Abbiamo chiesto alla professoressa Bertino quali siano le categorie di software maggiormente a rischio di difetti di programmazione e come sono scelte per i test di sicurezza che lei e il suo team svolgono, e ci ha risposto così: “Principalmente la nostra scelta degli ambiti da considerare è basata su un’analisi dello stato corrente dell’arte. Tali analisi ci permette di determinare ambiti e tipi di difetti per cui non è stato fatto alcun lavoro di analisi oppure per cui gli approcci di analisi proposti hanno delle evidenti limitazioni”.
“Ad esempio, un’area per noi di grande interesse è rappresentata dai protocolli di comunicazioni per le reti cellulari 5G e next-gen. Questi protocolli sono molto complessi e specificati in linguaggio naturale, pertanto non sono formalmente definiti. Queste descrizioni, che potremmo chiamare ‘specifiche molto informali’, hanno vari problemi, tra cui le ‘inconsistenze’. A questi problemi si aggiungono errori introdotti nella implementazione in software dei protocolli. Per fornire delle soluzioni alla verifica di questi protocolli, abbiamo sviluppato una metodologia sistematica, basata su metodi formali, per la verifica delle descrizioni dei protocolli, ed altre metodologie per la verifica dell’implementazione. Questo è però un ambito in cui c’è ancora molto da fare”.
Molti degli ambienti a cui la professoressa si rivolge per le analisi riguardano anche tecnologie di uso massivo: come le applicazioni per cellulari, il codice abilitante dei droni, le applicazioni open source. Dal lavoro pubblicato con la IEEE, apprendiamo che in relazione alle applicazioni mobili: “Un’analisi relativamente recente di oltre 13.000 applicazioni mobile che utilizzano l’autenticazione tramite login e password – spiega – ha mostrato che circa il 18% di queste applicazioni non controllava correttamente il certificato inviato dal server o non lo controllava affatto”.
Ci si aspetterebbe ad esempio, conoscendo le vulnerabilità che possono causare l’attacco SQL injection (iniezione di codice SQL per provocare comportamenti del codice a vantaggio dell’attaccante n.d.r.), il codice prodotto in questi ultimi anni potesse essere adeguatamente sviluppato per non contenerle. E invece purtroppo il numero di vulnerabilità SQL rimane elevato anche oggigiorno. Questo ragionamento vale anche per altre coppie vulnerabilità/mezzo di sfruttamento (exploit).
Shellter: così Red Team e penetration tester verificano la sicurezza dei sistemi informatici
Strumenti a supporto dei test di sicurezza
Nella prassi di revisione del codice sorgente (Secure Code Review), si esegue una verifica del codice sorgente di un’applicazione per verificare che siano presenti controlli di sicurezza adeguati, che funzionino come previsto e che siano stati richiamati in tutti i posti giusti. Esistono anche delle guide come ad esempio in ambito mobile, quella a cura della OWASP foundation che garantiscono una metodologia affidabile per procedere in modo controllato e senza perdere elementi importanti per l’analisi. I test possono essere fatti manualmente o mediante strumenti di supporto.
Ma poiché l’introduzione di altro codice può aumentare l’incertezza del risultato, abbiamo voluto chiedere a Elisa Bertino quali siano i sistemi usati per i test e come lei e il suo team abbiano potuto garantire che questi sistemi di test fossero affidabili per il lavoro richiesto: “Per verificare che le tecniche da noi sviluppate siano accurate – spiega – usiamo diversi approcci a seconda del tipo di tecnica. Per esempio, in alcuni casi, una volta individuato un difetto, usiamo testbeds per verificare che sia possibile fare un attacco che sfrutti il difetto”.
“In altri casi, per esempio quando usiamo tecniche di machine learning, creiamo dei datasets di test. In altri casi informiamo le aziende interessate (nel caso di software di aziende) dei difetti da noi individuati e dei possibili attacchi per averne conferma. Ovviamente nel caso di uso di metodi formali da noi usati per l’analisi dei protocolli di comunicazione specificati in linguaggio naturale, l’accuratezza dipende molto dal livello di astrazione usato quando si rappresenta formalmente il protocollo. Più si astrae e più si perdono dettagli e quindi alcuni difetti possono non essere individuati; quindi, tali metodi possono non assicurare la completezza dell’analisi”.
Le evidenze riscontrate sull’insicurezza del codice
Il risultato delle analisi su tutte le applicazioni prese a campione e analizzate alla Purdue University dalla professoressa e dal suo team, è che nonostante tutto buona parte del software è ancora non sicuro: “Ci si sarebbe almeno aspettati – osserva – che, data la maggiore consapevolezza della necessità di una migliore sicurezza del software, le applicazioni sviluppate in questi ultimi anni sarebbero state più sicure. Tuttavia, non sembra questa la tendenza dominante. Le evidenze delle analisi sono di due tipi: da un lato l’individuazione di specifici difetti che danno luogo a vulnerabilità per specifiche categorie di applicazioni e come secondo risultato un set di strumenti automatici per l’analisi di tipi specifici di difetti per categorie specifiche di applicazioni (per esempio applicazioni mobili e sistemi di IoT)”.
Ai fini della risoluzione, infine, Elisa Bertino spiega che “per quanto riguarda il patching (prassi di chiusura delle vulnerabilità introducendo codice aggiuntivo n.d.r.) a livello di ricerca sono stati sviluppati approcci per la generazione automatica del patching delle applicazioni ed ovviamente le aziende produttrici di software hanno i loro processi per generare le patches ed aggiornare il codice. Il problema, tuttavia, nell’applicazione di patches è l’introduzione di potenziali errori in applicazioni funzionanti; il patching è quindi un’operazione costosa che richiede la pratica sistematica di test di regressione, per essere sicuri che le applicazioni, impattate dalle patches, continuino a funzionare.
L’intelligenza artificiale potrebbe aiutarci
“Lo sviluppo di strumenti automatici per la gestione del patching è quindi ulteriormente importante e le tecniche di AI potrebbero aiutare. Per quanto riguarda il codice generato dall’AI (ad esempio nel progetto Copilot), il problema è che questi sistemi sono addestrati su grandi quantità di codice, tipicamente reperito da repositories GitHub; molto spesso questo codice non è di buona qualità e presenta esso stesso delle vulnerabilità (il che significa che l’AI verrebbe addestrata su codice sbagliato n.d.r.). Tuttavia, vista l’importanza di strumenti effettivi ed efficienti per la generazione automatica di codice, penso che la ricerca svilupperà quanto presto delle tecniche per assicurare una buona qualità del codice generato ed in particolare l’assenza di vulnerabilità”.
Motivi noti della Software insecurity globale, riguardano la mancanza di responsabilità del fornitore, la mancanza di formazione di ingegneri e sviluppatori di software, l’uso di linguaggi non sicuri e altre cause imputabili all’impostazione dello sviluppo di codice. In sostanza oltre a prendere il buono ed i benefici della digitalizzazione si dovrebbe anche investire nelle sue conseguenze.
Infatti, l’introduzione di applicazioni digitali solitamente apporta benefici di: semplificazione dei processi lavorativi, velocità efficacia ed efficienza dei cicli produttivi, spesso anche un abbattimento dei costi.
Ma immancabilmente l’introduzione di codice produce un cambiamento nei processi lavorativi e vulnerabilità del codice. Allora si rende necessario rispettivamente un investimento in change management per semplificare i processi lavorativi grazie alla digitalizzazione e un approccio sistematico alla gestione della sicurezza del software adottando anche tecniche di protezione dei dati: crittografia, misure di autenticazione a più fattori, controllo errori e convalida degli input, check dei certificati.
Ma da sole queste tecniche non bastano se non si interviene anche nelle catene di fornitura del software e nelle modalità di costruzione di infrastrutture digitali ridondate e robuste, soggette a back up sistematici e protette nelle comunicazioni dei dati.