Le aziende possono seguire consigli dettagliati e applicare le patch esistenti e applicare le best practice in risposta immediata a log4j. Ma in una seconda fase, dovrebbero dare uno sguardo generale ai processi relativi alle catene di fornitura del software.
Dopotutto, anche Log4Shell, indipendentemente da quanto rilevante possa essere il divario per la sicurezza, è "solo" un componente difettoso nella catena di fornitura del software", afferma Udo Schneider, IoT Security Evangelist Europe presso Trend Micro.
Log4Shell - Conosci la tua catena di fornitura software?
Naturalmente, la minaccia critica rappresentata dalla vulnerabilità Log4Shell richiede una risposta immediata. Ma nella seconda fase, le aziende generalmente devono porsi domande sui processi relativi alle catene di fornitura del software e alle dipendenze documentate (?).
La vulnerabilità Log4Shell divenuta nota qualche giorno fa è sulla bocca di tutti e tiene all'erta gli esperti di sicurezza di tutto il mondo. Il BSI parla di una "situazione di minaccia estremamente critica" perché la vulnerabile libreria Log4J è, per così dire, "lo" standard di log negli ambienti Java. Di conseguenza, viene utilizzato anche in migliaia di applicazioni e servizi Internet. Inoltre, è facile abusare della vulnerabilità e in molti casi può essere sfruttata da remoto, consentendo in ultima analisi l'esecuzione di comandi arbitrari. Un vero incubo dal punto di vista della sicurezza informatica! Le organizzazioni possono seguire i nostri consigli dettagliati e applicare le patch esistenti e applicare le best practice per una risposta immediata. Ma in una seconda fase, dovrebbero dare uno sguardo generale ai processi relativi alle catene di fornitura del software. Dopo tutto, anche Log4Shell, non importa quanto la vulnerabilità possa essere rilevante per la sicurezza, è "solo" un componente difettoso nella catena di fornitura del software.
Log4Shell il building block difettoso
Per comprendere le catene di fornitura del software e il loro contesto, è utile guardare al mondo "reale", come la produzione di prodotti elettronici. Le cosiddette “distinta base” (BOM – Bill of Material) per gli assiemi sono all'ordine del giorno. Se consideri un singolo circuito stampato come un assieme, l'elenco delle parti appropriato contiene un elenco di tutti i componenti utilizzati, come resistori, condensatori, diodi, circuiti integrati e molto altro. Per ogni componente vengono memorizzati anche parametri esatti, produttori, prezzi, fonti di approvvigionamento e infine anche numeri di serie o almeno informazioni sul lotto.
Se ci sono informazioni dal produttore di uno dei componenti che alcuni componenti di un lotto non corrispondono ai valori di temperatura specificati, è possibile risalire esattamente a quali schede (ciascuna con il proprio numero di serie) sono a) interessate e b ) se sia necessario intervenire. Se devono essere avviate misure appropriate, l'informazione su quali gruppi sono interessati (in base al numero di serie) è ovviamente di grande aiuto. Alla fine, questa procedura continua con "assemblaggi" quasi a volontà... fino a quando non si finisce con installazioni massicce come l'LHC al CERN. Anche con una macchina così grande, il guasto di un minuscolo componente SMD può causare il guasto dell'intera macchina. Se, ad esempio, vengono rilevati lotti difettosi, alla fine è necessario essere in grado di verificare ogni singola resistenza installata.
Distinta base software (SBOM)
Questo è esattamente il modo in cui funzionano le catene di fornitura del software, ovvero le SBOM” — e in particolare tornando a Log4Shell: puoi dire rapidamente se sei interessato da questa lacuna? Con il tuo software che utilizza Log4J, forse è possibile rispondere rapidamente alla domanda. Spesso anche i servizi SCM come GitHub o GitLab offrono direttamente tali funzioni. Ma per quanto riguarda le dipendenze transitorie? Una libreria di terze parti che utilizzi utilizza Log4J internamente? O peggio ancora: una libreria che usi utilizza una libreria che a sua volta dipende da (ecc.) Una libreria che utilizza Log4J? Il software acquistato da un fornitore di servizi si basa su Log4J? Un servizio cloud acquistato utilizza Log4J?
Contenuto SBOM (Immagine: Trend Micro).
Domande su domande che richiedono risposte che richiedono di affrontare le SBOM. Log4Shell mostra chiaramente i problemi che sorgono quando la catena di fornitura del software non è documentata. Ma non lasciarti ingannare. Log4Shell è certamente una specie di scenario peggiore in questo momento. Ma anche con semplici "difetti" che non sono direttamente rilevanti per la sicurezza, la questione se sei interessato è importante!
Dipendenze del documento
Fondamentalmente, gli SBOM riguardano la documentazione delle dipendenze. Queste possono essere dipendenze sotto forma di software (componenti) ma anche servizi, licenze, server e molto altro. Soprattutto quando si tratta di modellare le dipendenze del software, nel tempo sono emersi due formati di scambio: CycloneDX e SPDX. Entrambi consentono la descrizione di diversi componenti software comprese le possibili dipendenze:
Ma il linguaggio descrittivo non è sufficiente. Piuttosto, anche l'ambiente specifico deve essere descritto e tenuto aggiornato. Naturalmente, queste descrizioni possono essere create manualmente e talvolta, ad esempio quando si dipende da servizi esterni, non c'è altra scelta. Tuttavia, quando si tratta di creare descrizioni per il software, lo sforzo manuale non ha senso. In questo caso, la creazione e la manutenzione di queste descrizioni devono avvenire in modo completamente automatico come parte della pipeline CI/CD. Esistono fondamentalmente due approcci: integrazione nel processo di compilazione e scansione degli artefatti di compilazione.
Integrazione CI/CD: processo di creazione
Creazione SBOM durante il processo di compilazione (Immagine: Trend Micro).
Sia CycloneDX che SPDX dispongono di strumenti che possono essere integrati direttamente nel processo di compilazione. Questi estraggono direttamente le dipendenze "alla fonte" (transitori). Questi possono essere librerie, file eseguibili, ma anche contenitori o livelli contenitore. L'integrazione diretta consente inoltre di tenere traccia delle dipendenze che esistono, ad esempio, solo durante la creazione stessa, ma non nel prodotto finito.
Integrazione CI/CD: crea artefatto
Anche se non ti è permesso intervenire direttamente nel processo di compilazione, ci sono strumenti per CycloneDX e SPDX che scansionano il risultato finale "dopo". Ciò significa che questi strumenti estraggono le dipendenze dall'applicazione Java, ad esempio, e le documentano. Poiché questi strumenti vedono sempre solo il risultato finale, è del tutto possibile che alcune dipendenze vengano semplicemente trascurate, poiché non possono più essere dedotte dal risultato finale.
Monitoraggio della vulnerabilità
Creazione SBOM dopo il processo di compilazione (Immagine: Trend Micro).
Per le aziende interessate solo al monitoraggio delle vulnerabilità, molti di questi strumenti offrono anche una correlazione diretta con i database delle vulnerabilità. Ciò significa che l'output non contiene solo i componenti trovati, ma anche un elenco di vulnerabilità. Ciò è paragonabile, ad esempio, all'integrazione di snyk, Trend Micro Application Security o Trend Micro Container Security nella pipeline CI/CD.
Traccia delle dipendenze OWASP
Se anche il monitoraggio e la documentazione delle licenze, dell'inventario o del grado di distribuzione svolgono un ruolo, sono disponibili altre soluzioni (in aggiunta). In questo ambiente, lo strumento di tracciamento delle dipendenze dell'OWASP (Open Web Application Security Project) è sicuramente uno dei cani migliori. Come soluzione open source, di solito è integrato nelle pipeline CI/CD e lì riceve i dati SBOM, tramite i dati CycloneDX/SPDX (manuale, API) o direttamente dal processo di compilazione. Inoltre, Dependency Track memorizza automaticamente i dati di vulnerabilità da vari database di vulnerabilità e correla continuamente i dati da build (storiche) e vulnerabilità. Le corrispondenze vengono visualizzate di conseguenza in una dashboard o segnalate direttamente tramite chat e integrazione CI/CD o facoltativamente inoltrate a strumenti per la correzione automatica.
Integrazione della traccia delle dipendenze (immagine: https://github.com/DependencyTrack/dependency-track )
Dependency Track è un database con il quale è possibile rispondere facilmente alla domanda: "Dove sono interessato da Log4Shell". Questa risposta non include solo le versioni correnti del software, ma vengono fornite anche le descrizioni delle vecchie versioni. Una possibile scoperta può quindi essere che un'azienda non è interessata nella versione attuale (poiché è sufficientemente patchata), ma sono interessate 34 versioni precedenti. Se ora tenete traccia anche delle informazioni sul numero di versioni installate, si tratta di dati quasi perfetti per una valutazione del rischio fondata.
Conclusione su Log4j, Log4Shell e supply chain
Infine, è importante essere in grado di rispondere alle domande poste all'inizio: noi (direttamente o nella nostra catena di fornitura del software) utilizziamo Log4J? In caso affermativo, in che misura (versione, distribuzione) siamo interessati da Log4Shell? Lo sforzo richiesto per rispondere a questa domanda è un indicatore della misura in cui si ha una visione approfondita della catena di fornitura del software e se vale la pena utilizzare gli strumenti per aiutarla.
Per quanto riguarda gli strumenti, è importante chiarire se si tratta "solo" della domanda "sono interessato". In tal caso, strumenti come snyk o le opzioni integrate in GitHub e GitLab saranno d'aiuto. D'altra parte, se si desidera una visione più completa, esistono altre soluzioni per l'acquisizione e la catalogazione degli artefatti software. Questi sono sia commerciali che gratuiti. Dal campo open source, Dependency Track è sicuramente il più diffuso qui.
In definitiva, tuttavia, va notato che le lacune di sicurezza sono un argomento importante per la gestione della supply chain del software, ma certamente non l'unico!
Altro su TrendMicro.com
Informazioni su TrendMicro In qualità di uno dei principali fornitori mondiali di sicurezza IT, Trend Micro contribuisce a creare un mondo sicuro per lo scambio di dati digitali. Con oltre 30 anni di esperienza nella sicurezza, ricerca sulle minacce globali e costante innovazione, Trend Micro offre protezione per aziende, agenzie governative e consumatori. Grazie alla nostra strategia di sicurezza XGen™, le nostre soluzioni beneficiano di una combinazione intergenerazionale di tecniche di difesa ottimizzate per ambienti all'avanguardia. Le informazioni sulle minacce in rete consentono una protezione migliore e più rapida. Ottimizzate per carichi di lavoro cloud, endpoint, e-mail, IIoT e reti, le nostre soluzioni connesse forniscono visibilità centralizzata in tutta l'azienda per un rilevamento e una risposta più rapidi alle minacce.