Il supplizio della supply chain

Quando la nostra sicurezza dipende anche da ciò che compriamo

Come è stato detto più volte, la misura della sicurezza di una organizzazione è data dalla sicurezza dell’anello più debole della catena. Negli anni gli enti hanno investito e studiato soluzioni per poter migliorare la propria postura di sicurezza e cercare di tenere fuori i criminali dai propri dati e servizi. I criminali però continuano ad ingegnarsi con sistemi sempre più complessi e sofisticati per trovare brecce, vulnerabilità e raggiungere i propri scopi, per esempio andando a cercare gli anelli più deboli, che sempre più spesso non sono all’interno dell’organizzazione da attaccare, ma nella rosa dei propri fornitori di hardware, di software e di servizi. Mi riferisco ad una tematica di sicurezza ancora poco esplorata, ma che sta diventando sempre più importante: la sicurezza nella supply chain o catena di approvvigionamento.

L’impatto di una compromissione o vulnerabilità di un fornitore nella sicurezza di una organizzazione sta diventando sempre maggiore. Il rapporto Verizon sui data breach nel 2023 ci racconta che il 15% della perdita di dati è dovuto a problemi sul software e hardware acquisito da terzi. Anche se la percentuale non è (ancora) altissima, c’è da notare che nello stesso rapporto per il 2022 la supply chain non compariva proprio, il che significa che l’aumento (oppure “la comparsa di quella voce” oppure “quel 15%”) è molto significativo. In questi ultimi tempi ce ne siamo anche accorti, dato che ci sono stati episodi di impatto notevole che hanno coinvolto brecce di sicurezza nella supply chain.

La vicenda SolarWind alza sull’intero globo l’asticella della minaccia

Il primo esempio eclatante che tutti ricorderanno è avvenuto nel 2020, in cui criminali sono entrati nell’azienda SolarWind, un fornitore di software per la gestione IT e sono riusciti ad iniettare codice malevolo in un aggiornamento dei loro programmi, utilizzati da molte aziende e pubbliche amministrazioni. Queste organizzazioni, pensando di installare un aggiornamento legittimo del software SolarWind, hanno in realtà inconsapevolmente installato anche il malware, che da marzo a novembre è rimasto silente a raccogliere dati su ciascuna struttura, per poi sferrare l’attacco ed esfiltrazione dei dati in dicembre.

L’impatto enorme di questo incidente di sicurezza ha portato per primi i legislatori USA ad emanare l’Executive Order on America’s Supply Chains (24 febbraio 2021) e i legislatori europei ad emanare una nuova direttiva NIS, la NIS2, in cui uno degli aspetti preponderanti è proprio l’attenzione alla catena dei fornitori.

Impatto su enti governativi in tempi incerti

Fra la stesura della NIS2, la sua emanazione e il recepimento, è accaduto un altro incidente grave, che ha coinvolto istituzioni governative danesi ed europee: quello di Ivanti. Anche Ivanti è un software di gestione IT, in particolare il loro modulo per la distribuzione delle patch aveva un bug RCE (esecuzione di codice arbitrario da remoto), che permetteva di ottenere privilegi elevati sul server di patch. In questo caso, dal momento che il software vulnerabile si occupa di distribuire le patch a tutti i sistemi del parco IT, avrebbero potuto inserire codice malevolo in tutti i sistemi dell’organizzazione. Il governo danese ha fatto sapere che di essere stato compromesso dal bug di Ivanti, e che dati sensibili di alcuni membri del governo e parlamento erano stati esfiltrati. Non sono stati rivelati ulteriori dettagli, ma la preoccupazione, dovuta anche all’incertezza geopolitica e a possibili attacchi “state-sponsored”, è elevata.

Impatto sui cittadini

Il problema di attacchi alla supply chain ci coinvolge non solo come enti che forniscono un servizio ai propri utenti, ma anche come cittadini. Ne abbiamo avuto esperienza durante lo scorso 19 luglio, quando CrowdStrike ha rilasciato un update del proprio software di EndPoint Detection and Response (EDR) che ha provocato un’epidemia di schermate blu e disservizi in tutto il mondo. In questo caso non era stato compromesso niente, semplicemente l’azienda aveva distribuito un aggiornamento non funzionante che bloccava le macchine. Questo blocco si è propagato in pochissimo tempo in numerosi servizi essenziali, fra cui trasporti, aeroporti, banche e ospedali, che sono stati indisponibili per lungo tempo.

Supply Chain nel “piccolo”

Nel nostro piccolo altri fattori di rischio legati alla supply chain sono nell’utilizzo di sistemi cloud per macchine e/o servizi, forniti da terze parti, oppure semplicemente un software di gestione delle fatture in cui, grazie ad alcune vulnerabilità, vengono cambiate al volo le coordinate bancarie del beneficiario in modo che venga pagato qualcun altro al posto del fornitore, oppure l’utilizzo di piattaforme come WordPress per pubblicare contenuti web, che sono controllate, ma che possono utilizzare plugin di terze parti vulnerabili, mai aggiornati, o addirittura malevoli di per sé.

Ma questo è solo l’ingresso della tana del Bianconiglio.

Il mondo open source

Uno dei più grossi problemi dovuti alla supply chain è occorso a dicembre 2021, con la vulnerabilità nel software open source log4j, una libreria Apache per i log applicativi. Anche in questo caso la vulnerabilità (CVE-2021-44228) era riconducibile ad un RCE. L’impatto è stato devastante nel numero di dispositivi affetti. Il software open source è generalmente utilizzato non solo da migliaia di utenti che non vogliono utilizzare strumenti commerciali o a codice chiuso, ma è largamente utilizzato anche da quelle stesse aziende commerciali che prendono software aperto di ottimo livello e lo riutilizzano per i propri prodotti, rivendendolo. In questo caso, le strutture che utilizzavano log4j vulnerabile erano i maggiori fornitori di cloud (Microsoft, AWS, Google Cloud), software finanziario di applicazioni bancarie, applicazioni e dispositivi medici, i server Minecraft e la gran parte di sistemi e applicativi web, sia open che a pagamento. Come risultato si stima che il bug log4j abbia impattato su miliardi di dispositivi, milioni di aziende e utenti.

Inoltre, quest’anno per la prima volta è successa una cosa mai vista prima: uno degli sviluppatori della libreria XZ, libreria open source di compressione, dopo oltre un anno che lavorava come sviluppatore, ha inserito del codice malevolo nel github della libreria, facendolo passare come fix di un bug. Questa persona godeva di piena fiducia da parte del manutentore della libreria XZ e la sua richiesta di pubblicare il fix è stata accettata. Ma il fix era malware, in una libreria utilizzata su scala globale da moltissimi software, tanto che non si è neanche riusciti a capire l’impatto sul numero di device affetti o compromessi.

Il problema più difficile da risolvere, nel caso di librerie open source vulnerabili, è il fatto che molto spesso è difficile capire quale sia la versione utilizzata e da chi all’interno di una struttura, perché molto spesso sono utilizzate da software commerciali, che sono chiusi, o vengono chiamate all’interno del codice di software autoprodotto, e non si sa quale versione abbiano usato né se siano vulnerabili.

Tutto questo ha portato alla ribalta il rischio sull’utilizzo non solo di software e programmi vulnerabili, ma anche solo di librerie utilizzate poi da numerosi programmi, in cui diventa impossibile risalire alla catena di approvvigionamento, sapere se ce l’abbiamo, se possiamo censirla, se siamo vulnerabili.

Ci siamo resi conto che avere vulnerabilità in librerie piuttosto che nel software è un salto di qualità e cambio di paradigma a cui dobbiamo essere preparati.

E l’hardware?

Pensiamo a tutto l’hardware che acquistiamo. Più volte è stato dimostrato che oggetti collegati ad internet, ad esempio televisori, telecamere di videosorveglianza, giocattoli, apparati IoT o di domotica, comunicano costantemente con indirizzi sconosciuti (perlopiù cinesi), inviando loro tutti i dati che riescono a raccogliere. Come possiamo essere sicuri che un oggetto che compriamo per un servizio erogato dalla nostra struttura, non contenga delle backdoor “di fabbrica” che al momento opportuno consentano lo sfruttamento di quell’hardware da parte di altri?

Ci aiuta il CyberSecurity Act

La questione, sia per quanto riguarda il software che hardware, è talmente importante che i legislatori europei hanno emanato un regolamento apposito, il Cybersecurity Act, che si occupa proprio di creare, a livello di ciascuna nazione, agenzie che stabiliscano degli standard di sicurezza per l’hardware e software, e che si occupino di controllare che tali standard siano rispettati mediante audit e laboratori di test. Una sorta di marchio CE di sicurezza cyber per hardware e software.

Prima della sua emanazione comprendeva una sezione che obbligava anche gli sviluppatori di software open source ad intraprendere le procedure per ottenere la certificazione del proprio software, ma questo avrebbe portato alla morte del software libero, dal momento che molti sviluppatori non hanno le risorse umane e finanziarie per poter testare e certificare i loro programmi. Per fortuna è passato un emendamento che obbliga soltanto le aziende commerciali che utilizzano software libero ad ottenere la certificazione di sicurezza, non gravando sui singoli sviluppatori e contribuenti all’open source. Ritengo che lo sviluppo del software libero sia di fondamentale importanza, e che sia meglio utilizzare un software libero con le sue vulnerabilità nella supply chain che piano piano vengono scoperte, piuttosto che un software chiuso che non possiamo sapere se abbia vulnerabilità non divulgate (e di solito ce l’ha). Avremmo potuto fare di meglio, per esempio spingendo le nazioni a supportare attivamente, mediante contributi, lo sviluppo del software libero, magari anche contribuendo economicamente alla sua certificazione, cosa che avrebbe portato ad avere software libero più sicuro.

Ma noi, alla fine, cosa possiamo fare per difenderci?

Dal punto di vista normativo abbiamo la NIS2, che per sistemi nel Perimetro di sicurezza cibernetica nazionale obbliga alla fornitura di materiale certificato. Abbiamo il Cybersecurity Act che stabilisce le procedure per la certificazione. Per alcune pubbliche amministrazioni abbiamo anche la legge 90 del 2024, che per acquisti informatici obbliga gli enti ad indicare nel capitolato misure precise di sicurezza che il fornitore deve mettere in opera per vincere la gara e in ogni caso nelle gare non si può guardare al prezzo più basso ma anche alla garanzia dei requisiti minimi di sicurezza del fornitore.

La situazione purtroppo è complicata, e in un ambiente libero come quello di università e ricerca è veramente difficile capire quali siano tutte le catene di approvvigionamento per ciascun ufficio, servizio, dipartimento, docente o ricercatore. Il nostro più grande sforzo dovrebbe essere inizialmente censire le varie tipologie di supply chain: fornitori hardware, fornitori software, ma anche settore DevOps e programmatori per capire quali librerie di terze parti vengano utilizzate nel software autoprodotto.

Una volta censita tutta la catena sarà necessario, come sempre, approcciarsi a districare la matassa effettuando un’analisi del rischio, poi stabilire delle priorità e successivamente affidarsi agli strumenti che possiamo utilizzare facilmente, per esempio utilizzando prodotti certificati, effettuando scansioni di vulnerabilità e/o pen-test, monitorando i sistemi.

Per quanto riguarda la catena “open source, DevOps e librerie” sarà necessario cambiare paradigma: non possiamo più aspettare che lo sviluppatore pubblichi una patch, ma dobbiamo intervenire prima, attraverso analisi del software autoprodotto, e lavorando sulla singola vulnerabilità: sapere quanto è grave, sapere se esiste un exploit, sapere se è facilmente sfruttabile, sapere se ce l’abbiamo.

Ma non solo, nell’ambiente di sviluppo è molto importante il contesto: abbiamo bisogno di sapere se la vulnerabilità è nell’ambiente di produzione o test, se il servizio è esposto, che tipo di dati processa e come si relaziona agli altri sistemi, sapere il raggio di azione. Il contesto è multidimensionale e importante per capire la priorità di intervento. Dobbiamo anche tenere in conto il fatto che con l’AI il cosiddetto time to exploit, cioè il tempo che serve ad un attaccante a scrivere codice per l’exploit una volta individuata una vulnerabilità, sta diventando pericolosamente basso, è stato appena stabilito il record di 22 minuti, rispetto ai mesi che ci volevano per scriverlo a mano. Quindi è fondamentale trovare soluzioni che facilitino l’identificazione e la correzione del problema in tempi concorrenziali con l’attaccante.

Questo ultimo punto è cruciale, dato che i software di scansione vulnerabilità attualmente sul mercato non riescono a capire quali librerie sono utilizzate da un programma e la loro versione. D’altra parte non possiamo richiedere ai nostri programmatori né ai fornitori di software di fare una lista delle librerie utilizzate con la relativa versione. Ci sono al momento tentativi di approcciarsi a questo problema, ma è un mondo ancora tutto da inventare.

Conclusioni

Fare la sicurezza è sempre stato un “inseguire i nuovi modi di attacco”, ma con i rischi sulla supply chain in qualche modo dovremmo iniziare ad essere più veloci e sistemare le vulnerabilità prima che esca l’exploit.