Cosa c'è all'interno del software commerciale e open source che uso? Quanto è stato scritto dal fornitore e quanto è codice di terze parti? Tutto quel codice può essere considerato attendibile?
Le minacce sono reali
La recente ondata di attacchi informatici di alto profilo dimostra ampiamente che sugli effetti di incidenti informatici aggressivi. L'hack di SolarWinds ha esposto i suoi clienti’ reti alla minaccia di compromissione da parte dei criminali informatici. L'attacco Codecov ha esposto i suoi utenti’ ambienti di integrazione continua/distribuzione continua per gli attori delle minacce.
CORRELATOSolarWinds Hack: cosa è successo e come proteggersi
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 l'esterno in settori non correlati e nella società in generale.
L'attacco ransomware del maggio 2021 alla Colonial Pipeline Company ha portato alla chiusura di un oleodotto di 5.500 miglia. Tra gli altri combustibili raffinati, il gasdotto fornisce il 45% della fornitura di benzina —2,5 milioni di barili al giorno di benzina—alla 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 dei tassi di cambio, per ripristinare i loro sistemi.
Ma se questo fosse stato un atto di cyberterrorismo o guerra cibernetica , non ci sarebbe stata alcuna opzione per acquistare il programma di decrittazione necessario per riportare online i sistemi danneggiati. Uno stato nazionale con capacità di cyber-offensiva può rendere un altro paese incapace di funzionare internamente attraverso una campagna di attacchi informatici strategici.
RELAZIONATO: Devi pagare il riscatto? Negoziare prima
Rispondere alle minacce
Il 21 marzo 2021, il presidente Biden ha firmato un ordine esecutivo sul miglioramento del 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'ordinanza riguarda le modalità per migliorare la sicurezza della catena di fornitura del software. Ciò pone i dipartimenti governativi doveri vincolati a una data per fornire guida, 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 un 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 attraverso 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 specificamente. 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 del 2021 sulla sicurezza open source ha rilevato che il numero medio di componenti open source in progetti commerciali non banali è di ben 528. Questo è un aumento del 259% rispetto a cinque anni fa, quando la media era di 84 componenti open source per progetto.
RELAZIONATO: Come utilizzare in modo sicuro il codice open source nel tuo progetto
Open-Source come consumabile
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, questa si chiama distinta base software o SBOM.
La distinta materiali software
RELATEDCome difendersi dai rootkit
La sicurezza inizia con conoscenza. Devi sapere cosa hai per assicurarti di averlo protetto. Ecco perché i registri delle risorse IT e i registri dell'elaborazione dei dati sono così importanti. Una SBOM—pronunciata ess-bomb—è un documento specifico dell'applicazione che elenca tutti gli elementi software che compongono un prodotto software.
Questa è una conoscenza preziosa. Averlo consente agli utenti di quel software di prendere decisioni sulla sicurezza. Se conosci le parti componenti presenti nel software, il rischio associato a ciascuna di esse e la gravità di ciascun rischio, puoi fare scelte ponderate e informate.
Potresti leggere l'elenco degli ingredienti su un involucro di una barretta di cioccolato e scoprire 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 uno SBOM dettagliato è’ 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, uno SBOM dovrebbe contenere:
- Nome fornitore: il venditore o le persone che hanno scritto il software.
- Nome componente: il nome del componente.
- Identificatore univoco: Un identificatore univoco universale (UUID).
- Stringa di versione: i dettagli di build e versione del componente.
- Hash del componente : un hash crittografico del componente. Ciò consente a un destinatario di verificare, se ha dei sospetti, se un file 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 collegati in altri componenti.
- Licenza: 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 in competizione. I tre leader in questo spazio sono Software Package Data Exchange (SPDX), lo standard ISO 19770-5:2013 Software Identification (SWID) e CycloneDX. Sarà interessante vedere se uno di questi sarà adottato dal governo federale come standard preferito.
L'automazione può aiutare
RELATEDCos'è il Typosquatting e come I truffatori lo usano?
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 pacchetto software, proprio come un “readme” file. Una volta che sei in possesso dello SBOM di qualcun altro, devi esaminarlo.
Ci vorrà del tempo. Ciascun componente dovrà essere verificato per assicurarsi che sia consentito in base ai criteri stabiliti dalla tua organizzazione e che la licenza di ciascun componente non causi conflitti per te.
< p>È 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 la conoscenza
La provenienza di pacchetti software e 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 o che gli utenti finali possano utilizzare.