Portare la sicurezza della catena di fornitura del software a un livello superiore con l'ultima nota OMB

Tutti i messaggi

La catena di fornitura globale del software è sempre in difficoltà minaccia da parte dei criminali informatici che minacciano di rubare informazioni sensibili o proprietà intellettuale e di compromettere l'integrità del sistema. Questi problemi potrebbero avere un impatto sulle società commerciali e sulla capacità del governo di fornire servizi al pubblico in modo sicuro e affidabile. 

L’Office of Management and Budget (OMB) degli Stati Uniti ha pubblicato nel luglio 2022 una nota sull’argomento, di cui abbiamo parlato qui in dettaglio. Nel settembre 2022 è stata pubblicata una nuova nota, questa volta incentrata sulla sicurezza e l'integrità della catena di fornitura del software, sottolineando il ruolo significativo delle SBOM. Presenta un elenco di requisiti precisi e, per la prima volta, condivide una tempistica vincolante per l’implementazione delle modifiche. 

La nota contiene due punti principali relativi all'Ordine Esecutivo (EO) 14028, Migliorare la sicurezza informatica della nazione:

  • L'EO ordina al National Institute of Standards and Technology (NIST) di condividere linee guida per lo sviluppo di pratiche volte a rafforzare la sicurezza della catena di fornitura del software. Per contribuire a raggiungere questo obiettivo, il NIST ha pubblicato due documenti: il Secure Software Development Framework (SSDF), PS 800-218e Guida alla sicurezza della catena di fornitura del software. Insieme, si chiamano NIST Guidance e delineano una serie di pratiche che costituiscono la base per la creazione di software sicuro. 
  • L'EO ordina inoltre all'Ufficio di gestione e bilancio di iniziare a richiedere alle agenzie di conformarsi alle linee guida del NIST e a qualsiasi altro aggiornamento. 

L’autocertificazione è un prerequisito, ma è tutto?

I produttori di software sono ora tenuti a fornire alle agenzie un'autocertificazione prima di iniziare a utilizzare il loro software. Esistono in realtà tre categorie che richiedono l'autocertificazione: nuovi acquisti di software, aggiornamenti di versione principali e rinnovi di software. L'obiettivo è dotare le agenzie di prodotti software sicuri e resilienti che le proteggano da minacce come cosa SolarWinds sperimentato, che ha compromesso diverse agenzie. 

Partiamo dalle basi: cos'è esattamente l'autocertificazione? 

L'autocertificazione è un documento che funziona come una dichiarazione di conformità, attestando che il produttore del software rispetta le pratiche delle Linee guida NIST. L'idea è che le agenzie ottengano un'autocertificazione per ogni prodotto o servizio software di terze parti che rientra nei requisiti della nota. Ciò include rinnovi del software e aggiornamenti importanti della versione.

Un altro punto importante della nota è che le agenzie incoraggino le società di software a includere i prodotti. Ciò consentirebbe loro di fornire la stessa attestazione a tutte le agenzie acquirenti.

L'agenzia può conservare il documento di autocertificazione a meno che la società di software non lo pubblichi pubblicamente e offra un collegamento alla pubblicazione all'interno della sua proposta. 

Nota: mentre tutti gli altri promemoria o linee guida fino ad oggi affermano che l'autocertificazione è sufficiente per cominciare, questo stabilisce la fiducia e la trasparenza come obiettivi chiave. Si concentra specificamente sulla catena di fornitura del software, non solo sulla sicurezza informatica o sulla SSDF (anche se ne fanno parte).

Cosa succede se la società di software non è in grado di fornire l'autocertificazione nel formato standard?

Un produttore di software potrebbe non essere in grado di attestare una o più pratiche della Guida NIST identificate nel modulo di autocertificazione standard. In questo caso l’ente richiedente il software richiederà all’azienda di:

  • Identificare quelle pratiche che non possono attestare 
  • Documentare tutte le pratiche in uso per mitigare tali rischi 
  • Sviluppare un piano d'azione e obiettivi intermedi (POA&M) 

Naturalmente l'agenzia deve assicurarsi che la documentazione non venga pubblicata pubblicamente (né dal venditore né dall'agenzia stessa).

Supponiamo che il venditore fornisca tutta la documentazione e che sia soddisfacente per l'agenzia. In tal caso, quest'ultimo potrà utilizzare i prodotti o servizi software nonostante la mancanza di un'autocertificazione completa da parte del produttore.

Cosa deve includere un’autocertificazione accettabile?

Un documento di autocertificazione deve includere i seguenti requisiti minimi: 

  • Il nome della società di software
  • Una descrizione dei prodotti software a cui si riferisce la dichiarazione (idealmente, questo punto descrive l'azienda di software o il livello della linea di prodotti, compresi tutti i prodotti non classificati offerti alle agenzie)
  • Una dichiarazione che confermi che il fornitore opera in linea con pratiche e attività di sviluppo sicure (evidenziate nel modulo di autocertificazione)

Questo tipo di autocertificazione rappresenta il livello minimo richiesto. Tuttavia, se le agenzie desiderano acquistare software senza di esso, ad esempio a causa della sua criticità, possono effettuare determinazioni basate sul rischio con l'aiuto di una valutazione di terze parti (definita in M-21-30). 

Tuttavia, la direttiva incoraggia le agenzie a utilizzare un modulo standard di autocertificazione. Il Federal Acquisition Regulatory (FAR) Council proporrà una regolamentazione sull’uso di tale modulo di autocertificazione standard e uniforme. 

Autocertificazione per software open source

Supponiamo che l'agenzia desideri acquisire software open source o un prodotto software che includa componenti open source. In tal caso, può rivolgersi a una valutazione di terze parti fornita da un'organizzazione di valutazione di terze parti FedRAMP (3PAO) certificata o approvata dall'agenzia stessa.

Tale valutazione è accettabile al posto dell'autocertificazione del fornitore purché il 3PAO utilizzi la guida NIST come base di riferimento. 

Le SBOM stanno diventando uno standard di settore. Sei pronto per questo?

Un'immagine di standard

Sebbene l'autocertificazione sia il livello minimo richiesto, le agenzie potrebbero non averne bisogno se il prodotto o il servizio che stanno cercando è fondamentale e non possono fornire l'autocertificazione in un modulo standard.

Ciò che è importante è che il promemoria incoraggia le agenzie a ottenere dai fornitori elementi che dimostrino la loro conformità alle pratiche di sviluppo software sicure. Una di queste pratiche include avere una SBOM. 

Che cos'è una SBOM e come funziona?

SBOM si riferisce a una distinta base del software, un inventario di tutti i componenti e le dipendenze che fanno parte dello sviluppo e della consegna di un prodotto software.

Un'agenzia può richiedere un SBO come parte dei requisiti di sollecitazione, a seconda della criticità del software per l'agenzia. 

La nota include le seguenti linee guida per l'approvvigionamento e l'utilizzo di SBOM da parte delle agenzie:

  • L'agenzia può conservare la SBOM a meno che il produttore del software non la pubblichi e condivida un collegamento ad essa con l'agenzia. 
  • Le SBOM devono essere generate utilizzando uno dei formati dati definiti nel file Rapporto NTIA "Gli elementi minimi per una distinta base del software (SBOM)" o la guida successiva pubblicata da Cybersecurity and Infrastructure Security Agency
  • Quando si considerano le SBOM, le agenzie devono tenere in considerazione la reciprocità della SBOM e di altri artefatti dei produttori di software gestiti da altre agenzie. Ciò si basa sull'applicabilità diretta degli artefatti e sulla valuta. 
  • Se necessario, l'agenzia può richiedere elementi diversi da SBOM, ad esempio quelli relativi a strumenti e processi automatizzati per convalidare l'integrità del codice sorgente o eseguire controlli delle vulnerabilità.
  • L'agenzia può anche richiedere alla società di software di dimostrare la partecipazione a a Programma di divulgazione delle vulnerabilità.

La nota suggerisce inoltre che le agenzie informino i fornitori di questi requisiti il ​​prima possibile nel processo di acquisizione. Per conformarsi all'Ordine e alle linee guida del NIST, le agenzie devono pianificare in modo appropriato e includere tutti i requisiti nel processo di valutazione del software. Tieni presente che questo dovrebbe anche essere in linea con la sequenza temporale specificata nel promemoria (questo sarà trattato nella sezione successiva).

Le agenzie devono specificare i requisiti nella richiesta di proposta (RFP) o in altri documenti di sollecitazione. L'idea qui è che l'agenzia garantisca che il fornitore implementi e utilizzi pratiche di sviluppo software sicure in linea con le linee guida NIST durante l'intero ciclo di vita dello sviluppo del software.

La SBOM è chiaramente una best practice del settore sulla strada verso un ampio utilizzo, in particolare per la mitigazione rischi della catena di fornitura del software

Per aiutare le aziende a creare fiducia nei propri prodotti software, abbiamo recentemente lanciato una piattaforma facile da usare che aiuta a generare SBOM e a condividerle all'interno e tra le organizzazioni. Fate una prova gratuitamente per vedere quanto può essere facile generare, gestire e condividere SBOM.

Non è più solo una raccomandazione; ora c'è una sequenza temporale obbligata da seguire

Le agenzie devono rispettare i requisiti della nota in linea con questa tempistica:

  • Le agenzie hanno 90 giorni per inventariare tutto il software di terze parti, incluso un inventario separato per il "software critico". 
  • Nel quadro di 120 giorni, devono creare "un processo coerente per comunicare ai fornitori i requisiti rilevanti contenuti in questo memorandum e garantire che le lettere di attestazione non pubblicate pubblicamente dai fornitori di software siano raccolte in un unico sistema di agenzia centrale". 
  • Loro hanno anche 270 giorni per raccogliere lettere di attestazione che non sono state pubblicate pubblicamente per "software critico". Entro un anno le agenzie avrebbero dovuto raccogliere le lettere per tutti i software di terze parti.
  • Infine, dentro 180 giorni dalla data della nota (14 settembre 2022), i CIO dell'agenzia devono aver valutato eventuali esigenze di formazione e sviluppare piani di formazione per la revisione e la convalida dei documenti e degli artefatti di attestazione. 

Le agenzie possono chiedere una proroga almeno 30 giorni prima della scadenza rilevante indicata nella nota, insieme a un piano per soddisfare i requisiti pendenti. È anche possibile richiedere una deroga, ma solo in circostanze eccezionali e per un periodo di tempo limitato.

Sommario

L'OMB condividerà istruzioni specifiche per presentare richieste di deroghe o proroghe entro 90 giorni dalla data della nota (fino a metà dicembre 2022). Inoltre, in consultazione con la CISA e l’Amministrazione dei Servizi Generali, determinerà i requisiti per un “archivio centralizzato per attestazioni e artefatti software” con i giusti meccanismi di protezione e condivisione tra le agenzie. 

Un luogo così centrale potrebbe un giorno diventare un luogo centrale per una serie di prove e attestazioni di sicurezza oltre al modulo di autocertificazione o SBOM. Collocare tutte le prove in un unico luogo condivisibile aiuta le organizzazioni ad affrontare problemi condivisi, come nuovi exploit emergenti o CVE. 

Questo è esattamente ciò di cui parla Scribe. Dare un'occhiata a questa pagina per saperne di più sulla nostra piattaforma completa per la generazione, la gestione e la condivisione di SBOM all'interno e tra le organizzazioni. 

Banner

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ù.