I rischi della catena di approvvigionamento ti hanno abbattuto? Mantieni la calma e diventa strategico!

Il settore della sicurezza perde collettivamente la testa quando vengono scoperte nuove vulnerabilità nel software. OpenSSL non fa eccezione e due nuove vulnerabilità hanno travolto i feed di notizie alla fine di ottobre e all'inizio di novembre 2022. La scoperta e la divulgazione sono solo l'inizio di questo ciclo di vulnerabilità senza fine. Le organizzazioni interessate si trovano di fronte a misure correttive, che sono particolarmente dolorose per coloro che sono in prima linea nell'IT. I leader della sicurezza devono mantenere un'efficace strategia di sicurezza informatica per aiutare a filtrare parte del rumore sulle nuove vulnerabilità, riconoscere gli impatti sulle catene di approvvigionamento e proteggere le proprie risorse di conseguenza.

Gli attacchi alla catena di approvvigionamento non stanno scomparendo

In circa un anno, abbiamo sofferto di gravi vulnerabilità nei componenti inclusi log4j, Quadro di primaverae OpenSSL. Inoltre, lo sfruttamento delle vulnerabilità meno recenti non cessa mai a causa di implementazioni configurate in modo errato o che utilizzano dipendenze vulnerabili note. Nel novembre 2022, il pubblico ha appreso di un campagna di attacco contro il ramo esecutivo civile federale (FCEB), attribuibile a una minaccia iraniana sponsorizzata dallo stato. Questa entità federale statunitense utilizzava l'infrastruttura VMware Horizon che conteneva la vulnerabilità Log4Shell, che fungeva da vettore di attacco iniziale. FCEB è stata colpita da una complessa catena di attacchi che includeva movimenti laterali, compromissione delle credenziali, compromissione del sistema, persistenza della rete, bypass della protezione degli endpoint e cryptojacking.

Le organizzazioni potrebbero chiedersi "perché consumare OSS?" dopo incidenti di sicurezza da pacchetti vulnerabili come OpenSSL o Log4j. Gli attacchi alla catena di approvvigionamento continuano a crescere perché il riutilizzo dei componenti ha un "buon senso commerciale" per partner e fornitori. Progettiamo i sistemi riproponendo il codice esistente piuttosto che costruendolo da zero. Questo per ridurre lo sforzo di ingegneria, scalare operativamente e consegnare rapidamente. Il software open source (OSS) è generalmente considerato affidabile in virtù del controllo pubblico che riceve. Tuttavia, il software è in continua evoluzione e i problemi sorgono a causa di errori di codifica o dipendenze collegate. Nuovi problemi vengono scoperti anche attraverso l'evoluzione delle tecniche di test e sfruttamento.

Affrontare le vulnerabilità della catena di approvvigionamento

Le organizzazioni hanno bisogno di strumenti e processi adeguati per proteggere i progetti moderni. Gli approcci tradizionali come la gestione delle vulnerabilità o le valutazioni point-in-time da soli non possono tenere il passo. I regolamenti possono ancora consentire questi approcci, il che perpetua il divario tra "sicuro" e "conforme". La maggior parte delle organizzazioni aspira a ottenere un certo livello di maturità DevOps. "Continuo" e "automatizzato" sono tratti comuni delle pratiche DevOps. I processi di sicurezza non dovrebbero differire. I leader della sicurezza devono mantenere l'attenzione durante le fasi di build, consegna e runtime come parte della loro strategia di sicurezza:

• Scansione continua in CI/CD: Cerca di proteggere le pipeline di compilazione (ad es. Maiusc-sinistra) ma riconosci che non sarai in grado di scansionare tutto il codice e il codice annidato. Il successo con gli approcci shift-left è limitato dall'efficacia dello scanner, dalla correlazione dell'output dello scanner, dall'automazione delle decisioni di rilascio e dal completamento dello scanner entro le finestre di rilascio. Gli strumenti dovrebbero aiutare a dare la priorità al rischio di risultati. Non tutti i risultati sono utilizzabili e le vulnerabilità potrebbero non essere sfruttabili nella tua architettura.

• Scansione continua durante la consegna: La compromissione dei componenti e la deriva dell'ambiente si verificano. Le applicazioni, l'infrastruttura e i carichi di lavoro devono essere scansionati durante la consegna nel caso in cui qualcosa sia stato compromesso nella catena di fornitura digitale durante l'estrazione da registri o repository e il bootstrapping.

• Scansione continua in runtime: La sicurezza del runtime è il punto di partenza di molti programmi di sicurezza e il monitoraggio della sicurezza è alla base della maggior parte degli sforzi di sicurezza informatica. Tuttavia, sono necessari meccanismi in grado di raccogliere e correlare i dati di telemetria in tutti i tipi di ambienti, inclusi gli ambienti cloud, container e Kubernetes. Le informazioni raccolte in fase di esecuzione dovrebbero fornire un feed back alle fasi precedenti di compilazione e consegna. Identità e interazioni di servizio

• Dai la priorità alle vulnerabilità esposte in fase di esecuzione: Tutte le organizzazioni faticano ad avere abbastanza tempo e risorse per scansionare e sistemare tutto. L'assegnazione delle priorità in base al rischio è fondamentale per il lavoro del programma di sicurezza. L'esposizione a Internet è solo uno dei fattori. Un altro è la gravità della vulnerabilità e le organizzazioni spesso si concentrano su problemi di gravità elevata e critica poiché si ritiene che abbiano il maggiore impatto. Questo approccio può ancora sprecare cicli di ingegneri e team di sicurezza perché potrebbero inseguire vulnerabilità che non vengono mai caricate in fase di esecuzione e che non sono sfruttabili. Utilizza l'intelligence di runtime per verificare quali pacchetti vengono effettivamente caricati nelle applicazioni e nell'infrastruttura in esecuzione per conoscere l'effettivo rischio per la sicurezza della tua organizzazione.

Abbiamo creato guida specifica del prodotto per guidare i clienti attraverso la recente follia di OpenSSL.

L'ultima vulnerabilità OpenSSL e Log4Shell ci ricordano la necessità di una preparazione alla sicurezza informatica e di un'efficace strategia di sicurezza. Dobbiamo ricordare che i CVE-ID sono solo quei problemi noti nel software o nell'hardware pubblico. Molte vulnerabilità non vengono segnalate, in particolare debolezze nel codice sviluppato internamente o configurazioni errate ambientali. La tua strategia di sicurezza informatica deve tenere conto della tecnologia distribuita e diversificata dei design moderni. Hai bisogno di un programma di gestione delle vulnerabilità modernizzato che utilizzi informazioni di runtime per dare priorità al lavoro di riparazione per i team di ingegneri. Sono inoltre necessarie funzionalità di rilevamento e risposta alle minacce che correlino i segnali tra gli ambienti per evitare sorprese.

L'autore

Michael Isbitski, direttore della strategia di sicurezza informatica di Sysdig, svolge ricerche e fornisce consulenza sulla sicurezza informatica da oltre cinque anni. È esperto di sicurezza cloud, sicurezza dei container, sicurezza Kubernetes, sicurezza API, test di sicurezza, sicurezza mobile, protezione delle applicazioni e consegna continua sicura. Ha guidato innumerevoli organizzazioni a livello globale nelle loro iniziative di sicurezza e nel supporto delle loro attività.

Prima della sua esperienza di ricerca e consulenza, Mike ha imparato molte dure lezioni in prima linea nell'IT con oltre 20 anni di esperienza professionale e di leadership incentrata sulla sicurezza delle applicazioni, la gestione delle vulnerabilità, l'architettura aziendale e l'ingegneria dei sistemi.