Nell'aprile 2023 CISA ha pubblicato una nuova guida congiunta per la sicurezza del software denominata Spostare l’equilibrio dei rischi legati alla sicurezza informatica: principi di sicurezza fin dalla progettazione e principi di default. La Guida è stata redatta con la collaborazione di 9 diverse agenzie tra cui la NSA, l'Australian Cyber Security Centre (ACSC) e l'Ufficio federale tedesco per la sicurezza informatica (BSI), tra gli altri. Il fatto che più agenzie di tutto il mondo abbiano collaborato alla preparazione di una guida alla sicurezza informatica dovrebbe essere una forte testimonianza dell’importanza che il tema della sicurezza informatica riveste a livello mondiale in questo momento.
Jen Easterly, direttrice del CISA, ha condiviso i suoi pensieri sul tema della sicurezza informatica in un recente discorso tenuto agli studenti e ai docenti della Carnegie Mellon University di Pittsburgh. Secondo il direttore della CISA, questi principi guida dovrebbero aiutare a guidare l’industria globale del software nei prossimi anni:
- L’onere della sicurezza non dovrebbe mai ricadere esclusivamente sul cliente. I produttori di software dovrebbero assumersi la responsabilità dei propri prodotti e codici.
- I produttori di tecnologia dovrebbero abbracciare la trasparenza radicale come impegno di responsabilità per i loro prodotti.
- I produttori di tecnologia dovrebbero concentrarsi sulla realizzazione di prodotti sicuri, sviluppando prodotti che siano sicuri fin dalla progettazione e sicuri per impostazione predefinita.
La guida CISA riprende questi principi di base e li amplia, includendo un elenco completo di suggerimenti pratici che i produttori di software possono adottare per immettere sul mercato prodotti più sicuri.
È interessante notare che molti dei suggerimenti espliciti sono basati su Il quadro SSDF del NIST ma formulato in modo più pratico e meno volontario.
Uno dei suggerimenti contenuti nella guida, direttamente correlato alla trasparenza radicale, è che i produttori di software includano la produzione di un file SBO nel loro SDLC per fornire visibilità sui componenti del loro software.
Ma creare una SBOM e persino pubblicarla è davvero sufficiente? Cosa può effettivamente fare un produttore o un consumatore di software con un file SBOM JSON o XML?
In questo articolo esamineremo gli usi che oggi una SBOM può offrire a un produttore di software, le informazioni che possono essere aggiunte a una SBOM per arricchirla e la business intelligence che può essere ottenuta dall'esame di tali documenti arricchiti. Daremo una rapida occhiata agli aspetti di conformità legati all'utilizzo di una SBOM e alle tue responsabilità in qualità di produttore di software, aggregatore di software o manutentore di software open source. Concluderemo parlando della gestione del rischio e di come i principi CISA di sicurezza fin dalla progettazione e sicurezza per impostazione predefinita si integrano con la conformità normativa in materia di sicurezza informatica e una gestione illuminata del rischio.
Non tutte le SBOM sono state create uguali
Sono molti gli strumenti disponibili oggi per la creazione di SBOM, dalle soluzioni open source a quelle proprietarie, una persona o un'azienda che desideri includere la creazione di SBOM nella propria SOP potrebbe farlo facilmente. Si poteva scegliere tra i diversi standard quello più adatto alle loro esigenze, ma anche in questo caso potresti trovarti di fronte a troppi strumenti per prendere una decisione informata. Quindi, cosa potresti cercare di più quando decidi quello giusto Generazione della SBOM strumento per te?
Innanzitutto, controlla quali informazioni sono incluse o omesse nella creazione della SBOM. Una distinta base che include strumenti e codice che facevano parte del processo di sviluppo ma non del prodotto vero e proprio conterrebbe probabilmente molte informazioni ridondanti che è molto difficile "ripulire" dal file risultante per consentirti di conservare solo le informazioni più rilevanti. Allo stesso modo, gli strumenti o il codice che non sono inclusi o omessi di proposito verrebbero mancati in modo evidente quando si desidera eseguire la scansione delle vulnerabilità, ad esempio.
L'elenco degli ingredienti e delle dipendenze del software, di per sé, è per lo più privo di significato. Serve a ben poco scopo oltre a quello che puoi scegliere di farne. L'uso più diffuso delle SBOM oggi è quello di scansionare i componenti software per ottenere un elenco di vulnerabilità che potrebbero influenzare il prodotto.
È importante ricordare che circa il 95% delle vulnerabilità scoperte non sono sfruttabili nel tuo prodotto. Il trucco sta nel trovare quell’inafferrabile 5%, elaborare un piano di lavoro e iniziare ad affrontare queste vulnerabilità sfruttabili. Come distinguere cosa è sfruttabile e cosa no? Questa è la grande domanda che tiene svegli la notte gli addetti alla sicurezza e all'ingegneria. Un suggerimento attuale è quello di utilizzare una soluzione chiamata VEX – un Vulnerability Exploitability eXchange, una forma di avviso di sicurezza il cui obiettivo è comunicare la sfruttabilità dei componenti con vulnerabilità note nel contesto del prodotto in cui vengono utilizzati. Lascia ancora gran parte del lavoro di vagliare il pagliaio delle informazioni sulle vulnerabilità e trovare l'ago delle vulnerabilità sfruttabili, principalmente al team di ingegneri. Dopotutto, chi conoscerebbe il proprio prodotto meglio delle persone che lo hanno codificato?
Ci sono però altre cose che puoi fare, soprattutto quando si tratta di vulnerabilità ereditate che provengono da immagini principali della tua immagine docker o da dipendenze molto indietro nella catena di dipendenze. Utilizzando strumenti open source come parentimage puoi capire quali vulnerabilità sono presenti con l'immagine principale e quali sono il risultato diretto del tuo codice. Ciò dovrebbe eliminare un pool potenzialmente ampio di vulnerabilità e rendere più semplice il lavoro di vagliatura. Anche l'uso di vari avvisi su diverse vulnerabilità è una buona idea poiché una volta stabilito che una vulnerabilità non è sfruttabile, ha senso farlo sapere agli altri membri del tuo team o ai tuoi utenti in modo da non continuare a controllare la stessa vulnerabilità in ogni versione del tuo prodotto dove non hai nemmeno modificato il modulo in cui è stato trovato. È inoltre consigliabile seguire le dipendenze open source e di terze parti in modo che una volta trovate e risolte le vulnerabilità sfruttabili sia possibile aggiornare quel codice nel tuo prodotto per renderlo sicuramente sei protetto anche da quel particolare potenziale problema.
Cos'altro puoi aggiungere a una SBOM?
Come affermato in precedenza, uno degli usi più comuni delle SBOM oggi è come lista di controllo per la scansione delle vulnerabilità. Utilizzando vari database disponibili gratuitamente come NVD (National Vulnerability Database) è possibile scansionare un elenco di componenti, simile a quello fornito da un SBOM, e vedere quali vulnerabilità contiene. Una volta che hai un elenco di vulnerabilità, puoi ordinarle per gravità, controllare se sono presenti correzioni esistenti e così via.
Un altro livello di informazioni utili sui componenti è la loro licenza. Molti componenti open source vengono forniti con una licenza non compatibile con l'uso commerciale. È importante assicurarsi che tutti i tuoi componenti open source, anche quelli che non hai incluso tu stesso ma che sono stati inclusi da qualche altro componente, siano compatibili con qualsiasi cosa tu stia cercando di realizzare in termini di licenza.
Un ultimo suggerimento è quello di seguire i misuratori di "salute" della sicurezza open source per le proprie dipendenze come Scheda punteggi OpenSSF. Avere una misura oggettiva e relativamente semplice per lo stato di salute della sicurezza informatica delle biblioteche open source potrebbe essere di grande aiuto nel decidere quali biblioteche includere o omettere dal proprio prodotto. Questi punteggi combinati con la gravità delle vulnerabilità sono un buon modo per aiutare a ordinare le vulnerabilità su cui vuoi lavorare per prime.
La gestione del rischio come esercizio di business intelligence
Ne esistono molteplici rischi per la sicurezza che qualsiasi produttore di software deve affrontare in questi giorni. Tra malware, crypto miner, ladri di password e ransomware è sorprendente che i produttori si sentano sicuri nel portare qualsiasi cosa sul mercato. Nessuno può gestire tutto in una volta, quindi le aziende creano modelli di minaccia e cercano di gestire i rischi in base a quelli che considerano i loro anelli più deboli. Il primo passo più semplice è assicurarsi che il codice e il processo di sviluppo siano conformi a tutte le normative e le migliori pratiche pertinenti. SSDF di Nist e OpenSSF SLSA sono un buon punto di partenza così come i requisiti statunitensi per cose come una SBOM. Seguire le normative e le migliori pratiche potrebbe almeno promettere una relativa sicurezza dalle controversie ai sensi del Porto sicuro programma. Ma questo è solo l'inizio.
La guida CISA incoraggia i produttori ad avvicinarsi alla costruzione dei propri prodotti pensando innanzitutto alla sicurezza. Una certa sicurezza "integrata" dopo la realizzazione del prodotto non può mitigare alcune debolezze fondamentali che fanno parte dell'architettura del prodotto. Secondo la guida, i prodotti Secure-by-Design sono quelli in cui la sicurezza dei clienti è un obiettivo aziendale fondamentale, non solo una caratteristica tecnica. Anche i produttori sono incoraggiati ad abbracciare trasparenza radicale e responsabilità. Ciò significa, tra le altre cose, garantire che gli avvisi di vulnerabilità e la vulnerabilità e l’esposizione comuni associate (CVE) i registri sono completi e accurati. Significa anche che i componenti del codice, le sue dipendenze e le vulnerabilità sono incoraggiate a essere condivise come un modo per mostrare a utenti e clienti che il produttore è almeno consapevole dei potenziali problemi del prodotto.
Secondo Wikipedia, business intelligence (BI) comprende le strategie e le tecnologie utilizzate dalle imprese per il analisi dei dati e gestione delle informazioni aziendali. Come puoi immaginare, raccogliere una SBOM per ogni build, nonché il rapporto sulle vulnerabilità, le informazioni sulla licenza e gli avvisi che analizzano quali vulnerabilità sono e non sono sfruttabili: sono molte informazioni. Il numero di punti di informazione aumenta quando si tiene conto della durata di vita di un tipico prodotto software e del fatto che si desidera avere queste informazioni per qualsiasi codice o strumento di terze parti che si sta utilizzando, nonché per i pacchetti open source che si includono, direttamente o transitoriamente. Per dare un senso a tutto questo in un modo che sia utilizzabile dai poteri di sicurezza dell'organizzazione (probabilmente il CISO e le persone sotto di loro) è necessario un sistema, un'unica piattaforma "pannello di vetro" che ti consente di organizzare tutte quelle informazioni, ricercarle in modo efficace e presentarle in report utili quando necessario. Per fornire solo un esempio di quanto possa essere critica una piattaforma BI per una piattaforma di sicurezza informatica, immagina il Log4J dramma dell'anno scorso. Non sarebbe fantastico cercare questa "nuova" minaccia in tutti i tuoi prodotti, comprese le dipendenze e gli strumenti di terze parti, premendo pochi tasti? Che ne dici di verificare la presenza di un diverso nuovo CVE minaccioso appena uscito? Oppure preparare un rapporto su come il numero complessivo di vulnerabilità della tua azienda sta progressivamente diminuendo nel tempo (o almeno non aumentando). Questo è il tipo di informazioni utili sul "quadro generale" che solo un sistema di BI su una piattaforma di raccolta arricchita con SBOM per la sicurezza informatica può offrire.
Solo una volta in possesso di tutte le informazioni rilevanti potresti veramente valutare il tuo rischio, sia nel tuo codice attuale, nelle tue dipendenze, sia nella scelta di includere o omettere alcuni strumenti o codici di terze parti dal tuo prodotto. Se eseguita in modo continuo, è possibile utilizzare questa valutazione del rischio anche per proteggere le build e interromperne la produzione o la consegna nel caso in cui venga rilevata un'attività sospetta.
Guardando al futuro
La tecnologia continua ad avanzare continuamente. Se un tempo i progetti di codice monolitico residenti su server situati negli uffici dell'organizzazione erano la norma, oggi sono l'architettura di microservizi multi-cloud e i LLM ad aprire la strada. Le SBOM devono continuare a progredire per essere in grado di supportare qualunque architettura complessa o software infrastrutturale utilizzi per mantenere la loro rilevanza e utilità. CycloneDX di OWASP, ad esempio, sta già lavorando per includere Trasparenza ML nel loro formato SBOM. Lo stesso formato garantisce inoltre l'inclusione delle funzionalità VEX e di un'API di condivisione SBOM durante la pianificazione futura. Prevedo che sempre più piattaforme come quella creata da Scriba sarà creato per l'accumulo e la condivisione di informazioni relative alla sicurezza, comprese le SBOM, sia per motivi normativi che per il vantaggio e il valore che tali informazioni arricchite apportano alle organizzazioni che le utilizzano correttamente.
La piattaforma di Scribe sta per rilasciare un nuovo strumento BI come parte della piattaforma di sicurezza esistente con tutte le funzionalità che ho suggerito e altro ancora. Ti incoraggio a farlo Provaci, scopri l'utilità di tali informazioni accumulate nel tempo e scopri per cosa puoi utilizzare tali informazioni. Indipendentemente dal fatto che tu scelga o meno di incorporare la piattaforma Scribe nel tuo SDLC, la corsa per un ecosistema più sicuro e una SBOM più completa e utile è lungi dall'essere finita. È meglio salire sul carro della trasparenza adesso piuttosto che farsi imporre una trasparenza radicale dalla regolamentazione o dalla pressione del mercato.
Questo contenuto è offerto da Scribe Security, un fornitore leader di soluzioni di sicurezza end-to-end per la catena di fornitura di software, che offre sicurezza all'avanguardia per artefatti di codice e processi di sviluppo e distribuzione del codice attraverso le catene di fornitura di software. Per saperne di più.
Post Correlati
