Attacchi alla software supply chain: chi è responsabile del rischio? Come si può affrontare al meglio?

• 
• Tweet
• Pin It
• Condividi per email

di John Walsh, senior product marketing manager, DevOps security, CyberArk e Tim Johnson, director, product marketing, CloudBees

Nel momento in cui circola la notizia di un attacco alla software supply chain, è probabile che quest’ultimo sia già diventato un problema enorme anche a livello di comunicazione. In realtà, queste violazioni non iniziano così: quasi sempre partono da un piccolo errore, come una credenziale Git esposta o uno strumento CI/CD mal configurato, nel ciclo della supply chain: proprio quello che fa al caso dei cybercriminali.

Più di 18.000 clienti SolarWinds sono stati infettati da un codice pericoloso iniettato in un aggiornamento software altrimenti legittimo; la violazione di Codecov dell’aprile 2021 è stata ricondotta a un errore di processo che ha permesso a malintenzionati di estrarre le credenziali e modificare gli script; nel massiccio attacco ransomware di Kaseya, alcuni software noti e fidati sono stati compromessi per raggiungere la customer base globale dell’azienda. Sono solo alcuni esempi, e si prevede che le cose possano solo peggiorare: secondo Gartner, “entro il 2025, il 45% delle organizzazioni di tutto il mondo avrà subito attacchi alle loro software supply chain, con un valore triplo rispetto al 2021.” [1]

Questi recenti attacchi hanno provocato significativi danni finanziari e di reputazione, spingendo molte organizzazioni a riesaminare i propri ambienti di sviluppo e le pratiche di delivery per identificarne le vulnerabilità. E stanno arrivando al cuore del problema: secret (credenziali, password SQL/LDAP, chiavi SSH e token API) non protetti che forniscono accesso privilegiato ai dati e alle risorse più preziose dell’organizzazione. Un singolo punto di accesso non protetto è tutto ciò che serve a un attaccante per violare un intero ambiente IT e muoversi poi a valle verso clienti e partner.

Il “segreto” della software delivery automation

Prendiamo ad esempio Jenkins. Questo – insieme a tutti gli altri strumenti, piattaforme e contenitori utilizzati dagli sviluppatori per automatizzare l’erogazione del software – deve essere in grado di interagire con numerosi sistemi e applicazioni in tutto l’ambiente DevOps per svolgere il suo ruolo di “maggiordomo”, Per farlo, richiede accesso ai potenti secret utilizzati per identificare il controllo e implementare gli artefatti.

Se non configurati correttamente e protetti in modo adeguato, questi secret diventano facili – e preziosi – obiettivi per gli attaccanti. La pipeline CI/CD e altri strumenti DevOps sono beni “Tier Zero”: entrandoci si ottiene l’accesso a credenziali ancora più privilegiate. Utilizzandole, gli aggressori possono prelevare dati riservati, iniettare malware nella codebase, apportare modifiche significative alla funzionalità di un’applicazione o rubare codice e IP di valore dai repository.

Sul tema, Gartner ha un’idea chiara: “Raccomandiamo strumenti di Privileged Access Management (PAM) per monitorare e proteggere gli account privilegiati che eseguono attività di compilazione e automazione. Nell’attacco SolarWinds, gli attaccanti hanno modificato i domini trusted e abusato di ruoli privilegiati, a conferma di quanto gli account privilegiati siano un obiettivo primario. Per mitigare questo rischio spesso è necessaria una soluzione PAM”[2].

È dunque chiaro che proteggere l’accesso privilegiato rappresentato da secret e credenziali attraverso la pipeline DevOps è la chiave per salvaguardare l’integrità del software e rendere sicura la supply chain. Ma in definitiva chi si deve assumere questa responsabilità?

Chi è responsabile del rischio nella software supply chain?

Il passaggio all’infrastruttura moderna e a DevOps ha creato complessità e differenze nel modo in cui vengono soddisfatte le esigenze di sicurezza. I regolamenti e gli standard di settore come il Sarbanes-Oxley (SOX) richiedono infatti alle organizzazioni di prendersi le responsabilità del rischio della supply chain, implementare controlli di sicurezza DevOps specifici e fornire una maggiore trasparenza per ridurre al minimo i rischi. Allo stesso tempo, le richieste dei clienti in termini di protezione stanno aumentando rapidamente, insieme alla domanda di moderne esperienze digitali.

I team di sicurezza vengono quindi incaricati di rendere sicure le catene di valore digitali che proteggono i dati dei clienti, a partire da chi, o cosa, è autorizzato ad accedere a quali elementi all’interno della pipeline CI/CD e degli ambienti di produzione, fino a quando e per quanto tempo. Il tutto con una sfida: trovare un modo per raggiungere questo obiettivo senza rallentare gli sviluppatori.

Questi ultimi sono alle prese con il loro personale dilemma di sicurezza: con l’obiettivo di portare velocemente le innovazioni sul mercato, la cultura DevOps enfatizza alta velocità, condivisione intensiva del codice, strumenti ad hoc e automazione totale. Ma proprio qui spesso emergono scorciatoie a bassa sicurezza, come ad esempio l’inserimento di secret non protetti in JenkinsFiles per risparmiare tempo o riutilizzare codice open-source da Internet senza sufficiente controllo. Infatti, l’ultima cosa che desiderano gli sviluppatori è che qualcun altro impedisca loro di portare a termine il loro lavoro; tantomeno vogliono assumersi la responsabilità della sicurezza, né essere ritenuti gli eventuali responsabili di una costosa interruzione dovuta alla violazione.

Come conseguenza, alcune forme di sicurezza, come vulnerabilità e code scanning, vengono man mano integrate nei processi DevOps, ma in molte organizzazioni la gestione dei secret rimane una funzionalità di base frammentata nei singoli strumenti DevOps, rendendoli difficili da gestire e proteggere per gli sviluppatori (che non hanno tempo di diventare esperti di sicurezza). In più, quando vengono scoperti problemi di sicurezza – a volte subito prima che il codice sia programmato per andare in produzione – gli sviluppatori affrontano lo stress legato alle modifiche al codice dell’ultimo minuto e al rilascio ritardato.

Il panorama in continua evoluzione dello sviluppo richiede che operi insieme alla sicurezza per proteggere i secret in tutto l’ambiente CI/CD, ridurre il rischio e minimizzare i danni dell’eventuale prossima minaccia alla supply chain. Un approccio centralizzato alla gestione dei secret rende più facile per gli sviluppatori mantenere i loro flussi di lavoro esistenti e continuare a operare velocemente.

Tre passaggi per proteggere la pipeline

La maggior parte delle organizzazioni ha già stabilito i requisiti per proteggere le credenziali tramite l’adozione di un secret management nei sistemi IT tradizionali, come la rotazione automatica, l’archiviazione centralizzata e il monitoraggio continuo di credenziali e segreti. Tuttavia, per proteggere la propria software supply chain e rendere sicura la pipeline CI/CD, è anche necessario implementare queste best practice in tutta la pipeline Jenkins, all’interno degli strumenti DevOps e delle console di amministrazione, sulle workstation degli sviluppatori, nelle applicazioni e negli script. La strategia più efficace segue questi passi:
• Applicare il “principio del minimo privilegio” per limitare l’esposizione dei secret; e impiegare il controllo di role-based access control (RBAC) in modo che sviluppatore, strumento, applicazione, container, script o il processo di automazione abbiano accesso solo alle credenziali di cui hanno bisogno. Questo, ad esempio, aiuterà a prevenire che identità non fidate configurino i job e ad assicurare che le credenziali di valore, come i token di implementazione, siano protette da restrizioni di accesso appropriate o vengano implementate da un secondo server Jenkins sicuro.
• Rimuovere tutti i secret hard-coded dal codice negli strumenti DevOps, nei file di configurazione e negli script. È anche importante non usare mai password predefinite. Ad esempio, alcuni tool definiscono un utente sviluppatore di default per creare progetti e altre console possono essere accedute usando http o tramite la password di default.
• Richiedere autenticazione per l’accesso ai secret. Questo livello extra di protezione richiede agli attaccanti di fare passi in più oltre a rubare un singolo elemento noto come “secret zero”.

Una piattaforma centralizzata di secret management renderà queste best practice molto più facili da implementare e gestire, dando all’organizzazione un quadro completo e continuo di chi ha accesso a cosa.

[1] Gartner, “How Software Engineering Leaders Can Mitigate Software Supply Chain Security Risks,” 15 luglio 2021. Manjunath Bhat, Dale Gardner, Mark Horvath
[2] Gartner, “How Software Engineering Leaders Can Mitigate Software Supply Chain Security Risks,” 15 luglio 2021. Manjunath Bhat, Dale Gardner, Mark Horvath

• 
• Tweet
• Pin It
• Condividi per email