Nel settembre 2022, l'Ufficio di gestione e bilancio (OMB) degli Stati Uniti ha emesso un promemoria di riferimento per quanto riguarda le misure necessarie per proteggere la catena di fornitura del software a un livello accettabile dal governo federale degli Stati Uniti. Qualsiasi azienda che desideri fare affari con il governo e qualsiasi agenzia federale che produce software deve rispettare i requisiti e le tempistiche stabilite nel Promemoria M-22-18.
M-22-18 si è concentrato sulla sicurezza e sull'integrità della catena di fornitura del software, prestando particolare attenzione al ruolo dell' SBOM. Comprendeva un elenco di requisiti e una tempistica per l'implementazione dei passaggi necessari per la conformità.
La nota stabiliva due documenti principali prodotti dal NIST: il Secure Software Development Framework (SSDF), PS 800-218e Guida alla sicurezza della catena di fornitura del software come guida del NIST sullo sviluppo di software sicuro. La nota sottolinea inoltre la responsabilità dei produttori di software di autocertificare la propria conformità alle linee guida del NIST prima che le agenzie federali siano libere di utilizzare i loro prodotti. Tale autocertificazione dovrà assumere la forma di una “forma comune” di autocertificazione firmata. Tre categorie di software richiedono questo modulo di autocertificazione: nuovi acquisti di software, aggiornamenti di versione principali e rinnovi di software.
M-22-18 richiedeva alla CISA di stabilire questo "modulo comune" di autocertificazione standard entro 120 giorni dalla data di tale memorandum (14 settembre 2022). Quei 120 giorni sono trascorsi nel gennaio 2023 ma la forma è ancora in vigore bozza di modulo anche se il periodo per i commenti si è concluso il 26 giugno 2023. Questo è più o meno il periodo in cui la nota OMB aveva originariamente ordinato alle agenzie di iniziare a raccogliere attestazioni per il software critico.
Sulla base di alcuni dei commenti ricevuti per quel modulo di attestazione comune, l'OMB ha ritenuto opportuno rilasciare un emendamento a M-22-18 il 9 giugno 2023. Questo emendamento è intitolato M-23-16. Il nuovo memorandum estende la tempistica pubblicata su M-22-18 affinché le agenzie raccolgano attestati dai produttori di software. Le agenzie sono ora tenute a raccogliere i autocertificazione “forma comune” dai produttori di software per software “critico” entro tre mesi dall’approvazione da parte dell’OMB del modulo comune di autocertificazione CISA. Tutti gli altri produttori di software hanno sei mesi di tempo dall'approvazione del modulo di autocertificazione da parte dell'OMB.
Da questo Il modulo standard di autocertificazione sembra essere al centro dell'attenzione, esaminiamo un po' più nel dettaglio cosa contiene. Vedremo anche chi esattamente dovrebbe firmarlo e cosa significherebbe una tale firma.
Modulo comune di autocertificazione del software sicuro
Seguendo la catena normativa che va dall'EO 14028 ai documenti guida del NIST fino alle note dell'OMB, è chiaro che il governo mira a proteggere tutti, sia le agenzie federali che le aziende del settore privato, da vulnerabilità della catena di fornitura del software e intrusioni. Dal momento che il settore privato non ha fatto abbastanza al riguardo (secondo il governo), il governo ha deciso di creare nuove normative che tutti (chi vende al governo federale) devono seguire.
Naturalmente, anche se non vendi (ancora) al governo federale, è nel tuo interesse seguire queste regole e autocertificare di essere "sicuro", poiché tali società diventeranno un partner commerciale più attraente. Chi vorrebbe fare affari con un'azienda che non può confermare che sta facendo tutto il possibile per proteggere il proprio prodotto e i propri utenti?
Poiché abbiamo già stabilito che le linee guida del NIST costituiscono la base per la nuova regolamentazione e le migliori pratiche, non sorprende che gli stessi suggerimenti che compaiono, ad esempio, nella SSDF figurare anche nel modulo di autocertificazione.
Ecco un breve esempio tratto dalla bozza del documento:
Tratto dalla bozza del modulo comune di autocertificazione del software sicuro
Possiamo vedere il requisito a sinistra seguito dalla relativa sezione EO e poi dalle pratiche e dai compiti SSDF. Si tratta di un elenco piuttosto completo di requisiti (una pagina e mezza) che non sarebbe necessariamente del tutto chiaro se il lettore non si occupasse di sicurezza informatica e/o DevOps o DevSecOps.
Il documento richiede al firmatario dell'azienda di attestare PERSONALMENTE che tutti i requisiti delineati nel modulo sono costantemente mantenuti e che l'azienda notificherà alle agenzie interessate se qualsiasi elemento dell'elenco non è più valido.
Il documento non specifica chi all'interno dell'azienda dovrebbe firmarlo, ma poiché questo modulo è un requisito affinché l'azienda possa fare affari con il governo federale e le sue agenzie, è ovvio che l'amministratore delegato è la persona che dovrebbe assumersi la responsabilità Qui. Il CEO probabilmente non lo firmerà ciecamente chiedendo al CTO e al CISO di verificare (possibilmente per iscritto) che l'azienda segua tutte queste linee guida e requisiti.
Poiché non esiste un prodotto o una modalità operativa consolidata per raccogliere e attestare tutti questi requisiti, in un certo senso ogni azienda firmataria deve "reinventare la ruota" per se stessa e sperare che non succeda nulla di brutto.
Se succede qualcosa di brutto, il governo federale inseguirà il firmatario per dimostrare e dimostrare di poter sostenere tutti i requisiti dei moduli.
Cosa succede se non firmo?
Innanzitutto, tutta questa questione dell'attestazione è attualmente rilevante solo se il tuo software viene utilizzato da un'agenzia federale, se intendi vendere il tuo software al governo federale o, se il tuo software viene utilizzato da un fornitore il cui software è in uso o è destinato a essere venduto al governo federale.
Si noti che ho detto "attualmente" poiché vi sono tutte le indicazioni che la conformità SSDF, sia come autocertificazione che in qualche altra forma verificabile, diventerà una nuova "migliore pratica" nel campo della produzione di software.
Quindi, supponendo che la vostra azienda rientri nel gruppo sopra menzionato e non riusciate a trovare il modo di firmare questo documento con la coscienza pulita, non tutto è ancora perduto. A patto che tu possa spiegare dove si trova la carenza di attestazione e offrire un risultato soddisfacente Piano d'azione e tappe fondamentali (POA&M) l'agenzia federale in questione può comunque acquistare/utilizzare il tuo prodotto e richiedere un'estensione per il tuo software per tuo conto da OMB.
La cattiva notizia è che con o senza un piano POA&M alla fine dovrai fornire un modulo di attestazione completo, il che significa che devi essere in grado di verificare presso un tribunale federale che tutti i passaggi richiesti dal modulo siano stati seguiti dalla tua azienda e che il tuo il processo di sviluppo del software è sicuro almeno quanto i requisiti del modulo.
L'unico software attualmente esente da questa forma di attestazione è il software sviluppato da agenzie federali e il software disponibile gratuitamente, ovvero il software open source. Naturalmente, la maggior parte sicurezza della catena di fornitura del software i buchi possono essere rintracciati in qualche modo in qualche pacchetto open source nel codice, ma esiste un vero problema nel cercare di costringere sviluppatori e manutentori open source, che lavorano gratuitamente, a fornire una garanzia legalmente vincolante per il loro software. Dovrebbe spettare a chiunque utilizzi un software open source verificarne la sicurezza sia in generale che per quanto riguarda il software in cui è incorporato in particolare.
Scenario peggiore
L'intera coscienziosità della sicurezza della catena di fornitura del software è iniziata dopo il famoso SolarWinds incidere. Senza entrare troppo nei dettagli, al momento dell’attacco sono stati colpiti più di 18,000 clienti dell’azienda, comprese 9 agenzie federali.
È solo ora, a distanza di anni, che stiamo iniziando a vedere alcuni dei risultati legali di questo incidente. La SEC, Commissione statunitense per i titoli e gli scambi, sta inseguendo l'azienda nel suo insieme e dopo diversi dirigenti di livello C. Questo può essere visto come un esempio delle intenzioni del governo nel caso in cui un incidente del genere o simile dovesse accadere a un produttore di software che ha attestato le proprie pratiche di sviluppo sicure e tuttavia è rimasto vittima di un hacking.
Nel caso di SolarWinds, la società sostiene pienamente qualsiasi dipendente che venga preso di mira da tale azione legale. Conoscendo il sistema legale statunitense, è probabile che casi del genere richiedano anni e costino un sacco di soldi. Le multe non sono escluse e potrebbero raggiungere somme milionarie in base a una stima del danni subiti.
Si può immaginare che non tutte le aziende, in particolare quelle piccole e medie, siano così fermamente protettive nei confronti dei propri dipendenti come lo è SolarWinds. Il problema è che se la parte accusata è l'amministratore delegato dell'azienda, c'è una reale possibilità che la fiducia del mercato nell'azienda e nel suo prodotto venga gravemente compromessa. Affrontare la SEC senza il sostegno di una grande azienda con tasche profonde potrebbe rovinare un ignaro CEO e la sua azienda. Naturalmente, l’intento è quello di indurre le persone ad assumersi seriamente le proprie responsabilità per garantire lo sviluppo, ma la paura potrebbe indurre le persone a peccare per eccesso di autoconservazione. Ciò significa che le persone preferiscono nascondere gli incidenti di sicurezza informatica se pensano di non poter vincere un potenziale caso SEC o temono che il costo e la cattiva pubblicità di un caso del genere sarebbero così gravi che è meglio nasconderli indipendentemente dall'esito del caso giudiziario.
Come posso firmare?
La guida SSDF del NIST è ricca di suggerimenti e migliori pratiche ma scarsa sugli aspetti pratici. Poiché ogni azienda è unica, è piuttosto difficile realizzare un prodotto o un sistema che funzioni per tutti. In questo caso, il settore privato interviene per colmare il vuoto, creando un ecosistema per aiutare a soddisfare i requisiti.
Per esempio, Scribe ha costruito una piattaforma basato sul concetto di creare attestati, firmarli e offrire la possibilità di verificarli. Presto pubblicheremo un documento su misura per il Modulo di autocertificazione CISA, dimostrando come la soluzione Scribe può aiutarti in ogni sezione dei requisiti. Rimani sintonizzato.
Provare La piattaforma di Scribe è gratuita. Ti incoraggio a provarla e vedere come adattare la piattaforma alle tue esigenze e allo stesso tempo firmare il modulo di autocertificazione CISA con la coscienza pulita.
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
