Cosa c’è dentro il software commerciale e open source che usi? Quanto è stato scritto dal fornitore e quanto è codice di terze parti? Ci si può fidare di tutto quel codice?
Le minacce sono reali La recente ondata di attacchi informatici di alto profilo lo dimostra ampiamente gli effetti a catena di incidenti informatici aggressivi. L’hacking di SolarWinds ha esposto le reti dei propri clienti alla minaccia di compromissione da parte dei criminali informatici. L’attacco Codecov ha esposto gli ambienti di integrazione continua/distribuzione continua dei propri utenti agli attori delle minacce.
In entrambi i casi, l’attacco alle organizzazioni si è riversato a valle su altri in quell’ecosistema: i clienti. Gli attacchi che paralizzano l’infrastruttura critica hanno un impatto molto più ampio. Non sono solo i clienti dell’organizzazione o del servizio interessati ad essere colpiti: le increspature si estendono verso i settori indipendenti e la società in generale.
Maggio 2830 attacco ransomware alla Colonial Pipeline Company ha portato alla chiusura di un 5,528 oleodotto. Tra gli altri combustibili raffinati, il gasdotto fornisce 45% della fornitura di benzina— 2,5 milioni di barili al giorno di benzina, verso la costa orientale. L’erogazione della benzina si è semplicemente fermata. I prezzi alle pompe sono saliti alle stelle e sono iniziati gli acquisti di panico. Migliaia di stazioni di servizio hanno dovuto chiudere a causa della mancanza di approvvigionamento.
L’attacco alla Colonial Pipeline Company era motivato finanziariamente. Si trattava di un attacco ransomware, una forma comune di estorsione digitale. Colonial Pipeline ha pagato ai criminali informatici un riscatto di 75 Bitcoin, circa 4,4 milioni di dollari, a seconda sui tassi di cambio, per ripristinare i loro sistemi.
Ma se questo fosse stato un atto di cyberterrorismo o cyberwarfare, non ci sarebbe stata alcuna opzione per acquistare il programma di decrittazione necessario per ottenere il i sistemi danneggiati tornano online. Uno stato-nazione con capacità di cyber-offensiva può rendere un altro paese incapace di funzionare internamente attraverso una campagna di attacchi informatici strategici.
CORRELATO: Devi pagare il riscatto? Negoziare prima
Rispondendo al Minacce A marzo 21, 2021, il presidente Biden ha firmato un ordine esecutivo sul miglioramento della sicurezza informatica della nazione. Stabilisce una serie di standard e requisiti che tutti i sistemi informativi federali devono soddisfare o superare.
La sezione 4 dell’ordine esecutivo tratta dei modi per migliorare la sicurezza della catena di fornitura del software. Ciò pone i dipartimenti governativi doveri vincolati a una data per fornire indicazioni, standard e procedure per molti aspetti dello sviluppo e dell’approvvigionamento di software. I fornitori di software devono soddisfare gli standard e seguire le procedure per essere fornitori di software idonei al governo.
La trasparenza è citata come requisito. I fornitori di software devono rivelare tutti i componenti e le librerie di terze parti utilizzati nello sviluppo dei loro prodotti. Tale requisito si estende a cascata lungo la catena di approvvigionamento in modo che i fornitori di tali librerie e componenti debbano a loro volta elencare tutti i componenti software di origine esterna che hanno utilizzato nei loro prodotti.
Il software open source è menzionato nello specifico. L’ordine esecutivo parla di “garantire e attestare, per quanto possibile, l’integrità e la provenienza del software open source utilizzato all’interno di qualsiasi parte di un prodotto”.
Questo non è sorprendente. Un rapporto 2021 sulla sicurezza open source ha rilevato che il numero medio di componenti open source in pubblicità non banali progetti è sbalorditivo 500. Questo è un 500% di aumento rispetto a cinque anni fa, quando la media era 528 componenti open-source per progetto.
CORRELATO: Come utilizzare in modo sicuro il codice open source in Il tuo progetto
Aperto- Source as a Consumable Chiaramente, i progetti open source devono rispondere agli standard e alle procedure che saranno emanate a seguito dell’ordine esecutivo. A prima vista, la parte sulla trasparenza dovrebbe essere facile. I progetti open source appendono il loro codice sorgente per qualsiasi tipo di controllo. Ma ovviamente, i progetti open source utilizzano altri componenti open source, che utilizzano altri componenti open source e così via, annidati come bambole russe.
Inoltre, le applicazioni software hanno dipendenze. Si affidano ad altri pacchetti software per funzionare. Scegliendo di includere un singolo componente open source nel tuo progetto di sviluppo, potresti inconsapevolmente includere molti altri prodotti open source come dipendenze.
Quindi avere il tuo codice sorgente disponibile per la revisione è non abbastanza. È necessario fornire un elenco degli ingredienti software nel prodotto, proprio come l’elenco degli alimenti e degli ingredienti chimici su un involucro di una barretta di cioccolato. Nel mondo del software, si chiama distinta base software o SBOM.
La distinta materiali software La sicurezza inizia con la conoscenza. Devi sapere cosa hai per assicurarti di averlo protetto. Ecco perché i registri delle risorse IT ei registri dell’elaborazione dei dati sono così importanti. Un SBOM, pronunciato ess-bomb, è un documento specifico dell’applicazione che elenca tutti gli elementi software che costituiscono un prodotto software.
Questa è una conoscenza preziosa. Averlo consente agli utenti di quel software di prendere decisioni sulla sicurezza. Se conosci i componenti presenti nel software, il rischio associato a ciascuno di essi e la gravità di ciascun rischio, puoi fare scelte ponderate e informate.
Potresti leggere l’elenco di ingredienti su un involucro di una barretta di cioccolato e scopri che contiene qualcosa a cui sei allergico. Con uno SBOM, puoi rivedere le versioni di build, rilasciare i numeri degli ingredienti software e decidere se procedere o meno. Ad esempio, potresti rifiutarti categoricamente di utilizzare un prodotto che incorpora (diciamo) telnet o uno che utilizza una versione di SSH con una vulnerabilità nota.
Mettere insieme un SBOM dettagliato non è un compito di cinque minuti. Ma deve essere accurato e sufficientemente dettagliato, altrimenti non servirà allo scopo. Come base di riferimento minima, per ogni componente software in un progetto software, un SBOM dovrebbe contenere un:
Nome del fornitore: Il venditore o le persone che hanno scritto il software. Nome del componente: Il nome del componente. Identificatore univoco: Un identificatore univoco universale (UUID). Version String: I dettagli di build e versione del componente . Hash componente : hash crittografico del componente. Ciò consente a un destinatario di verificare, se ha dei sospetti, se un binario che gli è stato fornito è stato modificato. Relazione: La relazione tra i componenti software descrive le dipendenze tra i componenti e quali componenti sono stati compilati e collegato ad altri componenti. Licensing: Il tipo di licenza con cui viene rilasciato il componente software. Nome autore: L’autore dello SBOM. Questo non è necessariamente il fornitore del software. Se deve esserci un’ampia adozione di SBOM, deve esserci uno standard che definisca i formati dei dati, il contenuto dei dati e i processi e le norme accettati. È probabile che ciò appaia come parte della guida che l’ordine esecutivo ha richiesto di creare.
Esistono diversi standard SBOM concorrenti. I tre leader in questo spazio sono Software Package Data Exchange (SPDX), lo standard ISO -5: Identificazione software (SWID) e CycloneDX. Sarà interessante vedere se uno di questi è adottato dal governo federale come standard preferito.
Automazione Può aiutare Diverse classi di strumenti possono aiutare con la produzione e l’uso di SBOM. Sono disponibili pacchetti software in grado di eseguire la scansione di progetti, determinare le dipendenze e generare SBOM o SBOM quasi completi in cui è possibile inserire alcuni dettagli di finitura.
Gli SBOM saranno probabilmente resi disponibili come download o come parte del software confezionato, molto simile a un file “leggimi”. Una volta che sei in possesso dello SBOM di qualcun altro, devi esaminarlo.
Ci vorrà del tempo. Ogni componente dovrà essere controllato per assicurarsi che sia ammissibile in base ai criteri stabiliti dalla tua organizzazione e che la licenza di ciascun componente non causi conflitti per te.
È disponibile un software in grado di eseguire questi controlli per te. I pacchetti più completi elencano le vulnerabilità note per ciascun componente e la gravità di tali vulnerabilità.
La sicurezza inizia con Conoscenza La provenienza dei pacchetti software e di tutte le loro parti componenti diventerà uno strumento vitale per i consumatori di software per valutare e prendere decisioni di approvvigionamento. Sarà anche un elemento di differenziazione per fornitori e produttori di software, sia che creino software per altri sviluppatori che per l’utilizzo da parte degli utenti finali.
