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

Pubblicato il 24 novembre 2021

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



Contenuti correlati

  • Riccardo Rossi, Consulting Manager di HiSolution
    Digital Supply Chain: risolvere la crisi (anche) con la digitalizzazione

    Di Riccardo Rossi, Consulting Manager di HiSolution La pandemia ha sferrato un duro colpo all’economia globale e il conflitto in Ucraina ha peggiorato la situazione generando in più momenti gravi interruzioni della Supply e della Digital Supply...

  • Pilz festeggia un anno record e guarda con fiducia al 2022

    Che il tema della sicurezza sia questione di DNA in Pilz lo si capisce subito, così come si percepisce quello spirito di famiglia, di comunità, che da sempre la contraddistingue nonostante una presenza ormai globale. Ancora azienda a...

  • Indagine del Women for Security Lab sulla cyber security al femminile in Italia

    Laureata e con una formazione specifica, tra i 26 e i 55 anni; a lei è affidata prevalentemente una mansione “tecnica” nella cybersecurity: è questo l’identikit delle professioniste della sicurezza informatica in Italia ricostruito da Women for...

  • Direttiva NIS2: prendono forma le nuove norme europee sulla sicurezza informatica e delle reti

    Il Consiglio Europeo e il Parlamento europeo hanno recentemente raggiunto un’intesa politica sulle nuove misure per un livello comune elevato di cibersicurezza in tutta l’Unione, al fine di  migliorare ulteriormente la resilienza e le capacità di risposta agli incidenti del settore...

  • Mettere in sicurezza il perimetro aziendale: Bardiani Valvole ha scelto Sophos

    Bardiani Valvole, realtà italiana che opera nel settore della metalmeccanica alimentare, ha scelto Sophos come partner strategico per la cybersecurity. Ha messo così in sicurezza il proprio perimetro aziendale h 24, 7 giorni su 7, attraverso il...

  • Clusit propone un Secure Authentication Day

    Il 5 maggio si è celebrato in tutto il mondo il “World Password Day”. Creata da Intel nel 2013, la giornata mondiale della password ha certamente contribuito alla consapevolezza della sicurezza digitale negli anni passati, ma secondo...

  • Minacce informatiche e rischi della supply chain

    Le aziende sanno che i criminali informatici sono sempre in agguato. Ma oltre ai rischi diretti ai propri sistemi, ci sono quelli legati ai soggetti terzi che operano nella filiera. Più la catena di approvvigionamento è estesa,...

  • Una norma per la convergenza IT-OT

    Si offre qui una panoramica della struttura della norma IEC62443 che regolamenta la convergenza IT-OT, illustrando i ruoli coinvolti nella security e gli accorgimenti da implementare in relazione al livello di sicurezza che si vuole raggiungere Leggi...

  • Cyber-IIoT: reti OT a rischio!

    Parliamo di cybersecurity per le reti industriali. Perché l’era dell’industrial IoT necessita di un nuovo paradigma per la sicurezza di reti e dati? Leggi l’articolo

  • Industroyer2 malware
    Attacco del malware Industroyer2 alla rete elettrica dell’Ucraina

    Alla luce del tentativo di attacco di Sandworm alla rete elettrica Ucraina utilizzando una nuova versione del malware Industroyer, “Industroyer2”, Chris Grove, Director, Cybersecurity Strategy, Nozomi Networks commenta: “Tutti coloro che operano nel settore delle infrastrutture critiche...

Scopri le novità scelte per te x