Si prevede che la vulnerabilità del software Log4j causi gravi problemi su Internet nei mesi e negli anni a venire. L’applicazione delle patch è diventata una vera e propria corsa agli armamenti per le imprese e gli enti governativi. Il successo dipenderà dalla visibilità della rete, dalla rapidità nell’applicazione delle patch e dai flussi di lavoro.
Log4j è un'utilità di registrazione. Viene utilizzato da quasi tutti i servizi cloud e le reti aziendali del mondo per accedere ai server. Si tratta semplicemente dell’ultima vulnerabilità della catena di approvvigionamento del software (come quella emersa nel massiccio attacco a SolarWinds) che sta ora mettendo a dura prova le nostre vite digitali.
Ma la verità riguardo a queste vulnerabilità della catena di approvvigionamento è la seguente: esse possono — e devono — essere controllate prima che possano causare danni.
[Legga anche: Che cos’è la norma Log4j e come posso proteggere la mia organizzazione?]
Nick Selby, ex responsabile della sicurezza presso la società di servizi blockchain Paxos, non è disposto a correre rischi inutili quando si tratta di software e della sicurezza della catena di approvvigionamento. Ecco perché è preoccupato per il modo in cui molte organizzazioni si proteggono attualmente.
«Stiamo cercando di proteggere gli ambienti moderni più o meno allo stesso modo in cui lo facevamo 20 anni fa, e ciò sta alimentando una totale incomprensione della superficie di attacco», avverte Selby. «È un aspetto che il settore deve cambiare – e in fretta», aggiunge.
Gran parte di tale malinteso è dovuto alla mancanza di visibilità sui rischi per la sicurezza legati al software di terze parti, ai servizi software cloud e al software open source. “Il rischio legato a terze parti, derivante da vulnerabilità della catena di approvvigionamento o da componenti software di terze parti, continua a rappresentare un fattore determinante nelle violazioni causate da fattori esterni”, ha avvertito Sandy Carielli, analista principale presso Forrester Research, in occasione del recente evento “ Security & Risk Forum 2021” organizzato dalla società. «Probabilmente le organizzazioni hanno più soggetti terzi nel proprio ecosistema che mai», ha aggiunto.
Gli attacchi alle catene di approvvigionamento del software hanno registrato un’impennata durante il periodo della pandemia. Proprio la scorsa estate, lo strumento di Atlassian per la gestione agile dei progetti e il monitoraggio dei bug software è stato oggetto di un attacco “con un solo clic” che ha consentito a un hacker di accedere al sistema di pianificazione agile o al repository del codice, rendendo possibile l’iniezione di exploit nel codice di un utente ignaro.
Come ha affermato Chris Condo, analista di sicurezza di Forrester, in occasione del forum sulla sicurezza e sui rischi organizzato dalla società: «Non si avrebbe modo di sapere che qualcuno abbia effettuato l’accesso e modificato il proprio software». “Questi sono i tipi di problemi che si verificano quotidianamente.”
Secondo l’Agenzia dell’Unione europea per la sicurezza informatica (ENISA), gli attacchi alla catena di approvvigionamento (non tutti resi pubblici) sarebbero quadruplicati nel 2021 rispetto al 2020. Nel 66% di tali attacchi, osserva l’ENISA, gli autori hanno preso di mira innanzitutto il codice sorgente del fornitore per estendere i propri attacchi fino all’obiettivo finale.
Poiché gli autori degli attacchi si concentrano sempre più su attacchi di tipo “supply chain”, le organizzazioni devono comprendere come proteggersi al meglio. Consideri questo come il primo passo in qualsiasi processo di gestione delle vulnerabilità basato sul rischio.
Adattare le tattiche per far fronte agli attacchi in continua evoluzione
Gli attacchi alla catena di approvvigionamento sono in aumento poiché riescono a colpire grandi organizzazioni che da decenni non hanno modificato il proprio approccio alla gestione dei rischi legati alle tecnologie aziendali e alle terze parti. «Le aziende non sono riuscite a stare al passo con il modo in cui le imprese moderne acquistano, sviluppano e gestiscono la tecnologia», afferma Selby, co-conduttore del podcast “ : Tech Debt Burndown” ( ), che recentemente ha lasciato Paxos per entrare a far parte di Trail of Bits, società di ricerca e consulenza nel campo della sicurezza informatica. «Stiamo ancora effettuando la due diligence di terze parti sulla base di fogli di calcolo redatti nel corso ’90s da parte di commercialisti.»
«Probabilmente le organizzazioni hanno più soggetti terzi nel proprio ecosistema che mai.»
Tali strategie si sono rivelate efficaci in un’epoca in cui il principale rischio per la sicurezza derivante da violazioni da parte di terzi era rappresentato dalla divulgazione di dati riservati o dall’interruzione dei servizi. Tuttavia, non se la cavano bene quando si tratta di rischi legati a soggetti terzi che mirano a un attacco diretto volto a paralizzare o bloccare la vostra organizzazione tramite ransomware. Una strategia di gestione delle vulnerabilità basata sul rischio deve tenerne conto.
Ecco come funzionano gli attacchi alla catena di approvvigionamento. Anziché prendere di mira direttamente le organizzazioni, i criminali informatici e gli hacker al servizio di Stati nazionali prendono di mira i produttori di software e i fornitori di servizi software. Essi inseriscono codice dannoso nel software che viene poi utilizzato da altre organizzazioni. Questi aggressori prendono di mira in modo specifico le pipeline di sviluppo software vulnerabili e le configurazioni cloud non sicure, oppure sfruttano i processi di aggiornamento del software.
A seguito del devastante attacco informatico ai danni di SolarWinds, i funzionari federali hanno cercato di aiutare le agenzie e le organizzazioni del settore privato a gestire meglio i rischi legati alla catena di approvvigionamento dell’ e software. Con l’ordinanza presidenziale n. maggio 2021, il Presidente Biden ha emanato un’ordinanza esecutiva denominata “ ” (Miglioramento della sicurezza informatica nazionale), che impone ai fornitori che forniscono software al governo federale di includere una distinta dei materiali software (SBOM) per tutti i componenti dei propri prodotti.
Un SBOM è simile a una ricetta che elenca i componenti e le dipendenze presenti all’interno di un’applicazione o di un pacchetto software, compreso il codice proprietario e quello open source.
«Il decreto presidenziale prevede alcune misure senza precedenti», ha dichiarato Alla Valente, analista di ricerca senior presso Forrester, al pubblico del forum sulla sicurezza e sui rischi organizzato dall’azienda. Sebbene non si tratti di una soluzione miracolosa né di un sostituto delle buone pratiche di sicurezza informatica , il provvedimento ha accelerato gli sforzi volti a garantire la sicurezza della catena di approvvigionamento.
Allan Friedman è d'accordo. Friedman, sostenitore dell’SBOM presso la Cybersecurity and Infrastructure Security Agency (CISA), ha dichiarato in occasione di una recente tavola rotonda dei CISO organizzata da SecurityWeek sul tema della trasparenza nella sicurezza della catena di fornitura nell’ambito dell’ : «Uno degli aspetti che mi sta particolarmente a cuore è il miglioramento dell’analisi e della sorveglianza della catena di fornitura».
Realizzare un dosso stradale
La valutazione dei fornitori terzi di servizi cloud e software inizia con la comprensione del loro livello di maturità in materia di sicurezza. Prima di avviare una collaborazione con un fornitore di software, Selby esegue un test semplice e diretto volto a scremare coloro che dispongono di programmi di sicurezza non ancora maturi.
«In Paxos, la nostra valutazione preliminare consisteva in un questionario di 10 domande, che riveste un’importanza fondamentale. «Abbiamo adottato questa misura come un ostacolo provvisorio, non come la nostra valutazione definitiva in materia di sicurezza o conformità», afferma.
«Se [il vostro responsabile della sicurezza è] il vicepresidente del reparto di ingegneria, allora non avete un programma di sicurezza.»Nick Selby, ex responsabile della sicurezza informatica (CSO) di Paxos
Tra le domande preliminari figurano: “Dispone di politiche e procedure di sicurezza in forma cartacea e scritta? Posso vederli? Mi parli del Suo programma di allenamento. Dispone di un dirigente designato la cui unica responsabilità sia la sicurezza delle informazioni?
«Se la risposta è sì, e si tratta del vicepresidente del reparto di ingegneria», afferma Selby, «allora non disponete di un programma di sicurezza». Vorrei sentire dire: «Sì, ho un responsabile della sicurezza, un responsabile della sicurezza informatica, un direttore della sicurezza informatica» — qualcuno che sia direttamente responsabile e tenuto a rispondere della garanzia della sicurezza.”
Una parte essenziale di qualsiasi valutazione della sicurezza del software dovrebbe includere anche revisioni del codice di terze parti. Selby consiglia alle organizzazioni che stanno valutando l’adozione di un software per la catena di approvvigionamento di concentrarsi sulla comprensione del processo di sviluppo del software del fornitore e delle pratiche di programmazione sicura adottate dal suo team di ingegneri. «Sta seguendo un corso di formazione sulla programmazione sicura? E di cosa si occupa?» chiede Selby. «Ci parli del Suo programma di allenamento.»
Il superamento di un controllo di sicurezza non implica che il fornitore si aggiudicherà l’appalto. Ciò significa tuttavia che hanno superato la soglia di verifica più elementare e cruciale. «Sappiamo almeno di poter contare sul fatto che supereranno i nostri controlli in materia di conformità, sicurezza e aspetti legali», afferma Selby.
«Ed è proprio questo, a mio avviso, che le organizzazioni dovrebbero fare: coinvolgere il reparto sicurezza sin dalle prime fasi dei processi di inserimento dei nuovi fornitori. «Purtroppo, le aziende continuano a non coinvolgere il reparto sicurezza se non all’ultimo momento.»
L'open source è gratuito, ma non esente da rischi
Una corretta sicurezza della catena di approvvigionamento richiede inoltre di individuare e comprendere quali servizi software e quali applicazioni, sia on-premise che nel cloud, siano in esecuzione nell’ambiente di rete. «Si tratta di una sfida più complessa di quanto possa sembrare a prima vista», afferma Selby.
L’utilizzo di componenti open source rende il tutto ancora più impegnativo. «Poiché le organizzazioni utilizzano l’open source per creare applicazioni, oppure lo impiegano all’interno di software disponibili in commercio – che a loro volta contengono fino al 90% di codice open source –, stanno introducendo nel proprio ambiente una quantità preoccupante di rischi legati a terze parti», ha dichiarato Valente al forum sulla sicurezza e sui rischi.
«Il software disponibile in commercio contiene fino al 90% di codice open source, il che comporta un livello preoccupante di rischio legato a terze parti.»
La gestione dei rischi legati al software open source richiede che i team di sicurezza esaminino attentamente il codice del software. Ciò non significa limitarsi a verificare la presenza di vulnerabilità note e ritenere che non vi siano rischi se tutte le patch di sono aggiornate.
«Il più delle volte, è proprio questo che accade» durante una revisione del team di sicurezza, afferma Selby. «Verificano la presenza di CVE [vulnerabilità e esposizioni comuni] nel progetto open source e, se non vi sono vulnerabilità critiche, lo ritengono idoneo.» "È una follia."
I team di sicurezza devono invece esaminare tutti i componenti e le dipendenze software all’interno di un progetto open source e comprendere in che modo i vari componenti siano stati valutati e testati per individuare eventuali vulnerabilità di sicurezza.
«Open source significa che il codice sorgente è accessibile affinché possiate utilizzarlo, valutarlo e migliorarlo», afferma Selby. «L’open source non significa “prendere o lasciare”».
La sicurezza della catena di fornitura del software nella pratica
Mentre il decreto presidenziale del presidente Biden prevede nuovi requisiti per le agenzie federali al fine di migliorare i propri programmi di sicurezza — quali l’implementazione di un modello di gestione delle risorse ( ) basato sul principio “zero trust”, il potenziamento delle strategie di sicurezza nel cloud e l’adozione delle SBOM — l’Istituto Nazionale di Standard e Tecnologia (NIST) sta lavorando per rendere tali strumenti una realtà.
“Stop using the same spreadsheets that procurement weasels have used since the ’90s.”Nick Selby
Nel corso di un recente seminario, l’ NIST ha illustrato gli aggiornamenti apportati alla propria pubblicazione speciale “ ” (SP 800-218). Pubblicato nel settembre 2021, il documento illustra in dettaglio una serie di pratiche fondamentali di alto livello per lo sviluppo di software sicuro che le organizzazioni possono integrare nei propri cicli di vita dello sviluppo software. Le linee guida definitive sull’utilizzo degli SBOM saranno pubblicate su “ febbraio 2022”.
Nel frattempo, la National Telecommunications and Information Administration (NTIA) ha recentemente definito gli elementi minimi richiesti negli SBOM. Tali informazioni dovrebbero includere il nome del produttore del software, i dati relativi alla versione del software, gli identificativi univoci dei componenti del software, un elenco delle dipendenze tra i componenti e un registro che indichi chi ha creato l’SBOM e quando è stato creato. La NTIA ha riconosciuto tre standard aperti per la condivisione delle informazioni relative agli SBOM: SPDX, CycloneDX e SWID.
Secondo gli analisti, ciascuno dei tre standard presenta caratteristiche distintive. Mentre lo standard SWID è stato concepito per tracciare le licenze software e i diritti commerciali, lo standard SPDX riguarda le licenze, i componenti software, le informazioni sulla sicurezza e altri metadati. Allo stesso tempo, lo standard CycloneDX è orientato alla sicurezza del software.
“"CycloneDX è stato progettato specificamente per gestire una serie di casi d’uso nel campo della sicurezza informatica che vanno ben oltre i requisiti minimi pubblicati dalla NTIA", ha affermato Steve Springett in occasione del recente panel dei CISO organizzato da SecurityWeek. Springett è presidente del CycloneDX SBOM Standard, un gruppo di lavoro dell’Open Web Application Security Project (OWASP), l’ Community e online che produce articoli, metodologie, documentazione, strumenti e tecnologie gratuiti per la sicurezza delle applicazioni web.
[Legga anche: La Sua agenzia è pronta per la fine del ciclo di vita del software?]
Man mano che gli standard continuano ad evolversi, le organizzazioni che intendono migliorare l’efficacia dello sviluppo sicuro del software dovranno accontentarsi di ciò che è disponibile. Tali processi non sono facili da attuare e gli strumenti a supporto sono in continua evoluzione.
Ciononostante, è fondamentale che le organizzazioni inizino ad adottare misure per garantire la sicurezza della propria catena di fornitura del software. «Le aziende dovrebbero valutare come sfruttare al meglio il software di cui già dispongono, che si tratti di una piattaforma GRC o di una piattaforma di gestione dei rischi di terze parti», ha dichiarato Valente al pubblico del forum.
Sebbene la sicurezza della catena di approvvigionamento del software inizi con un’attenta verifica dei processi di sicurezza e del ciclo di vita dello sviluppo del software, i criminali informatici e gli Stati continueranno a sferrare attacchi contro i fornitori di servizi, utilizzandoli poi come trampolino di lancio per attaccare i clienti. I clienti che hanno adottato le migliori pratiche generali in materia di sicurezza riusciranno meglio a garantire la sicurezza all’interno delle proprie organizzazioni.
Ciò comporta la comprensione del software in uso all’interno della vostra organizzazione e il suo aggiornamento costante con le patch, il mantenimento di una corretta gestione delle configurazioni , nonché la disponibilità di efficaci capacità di monitoraggio e di risposta agli incidenti .
Per quanto riguarda Selby, egli afferma che una delle cose più importanti che le organizzazioni possano fare ora è abbandonare il più rapidamente possibile i vecchi metodi di gestione dei rischi legati al software di terze parti e alla catena di approvvigionamento.
“Stop using the same spreadsheets that procurement weasels have used since the ’90s,” he says. «È giunto il momento di modificare tali domande per concentrarsi sul modo in cui queste organizzazioni gestiscono i rischi per l’ambiente.»
