Attacchi alla software supply chain: chi è responsabile del rischio? Come si può affrontare al meglio?
![](https://automazione-plus.it/wp-content/uploads/sites/3/2021/11/Schermata-2021-11-23-alle-10.17.07-300x153.png)
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
-
Logistica, boom del mercato italiano che nel 2030 varrà 140 miliardi di dollari (+24%): I 7 trend che rivoluzioneranno il settore
Il mercato della logistica italiana può sorridere grazie a una crescita costante che non sembra intenzionata a frenare nemmeno nei prossimi anni. Secondo gli ultimi dati riportati da Mordor Intelligence il valore del trasporto merci e della...
-
InnoTrans 2024: Moxa presenta le soluzioni di comunicazione ed elaborazione dati con protezione
Moxa, fornitore di soluzioni di comunicazione basate su IP, si presenterà a InnoTrans 2024 nello stand 550 del padiglione 4.1 ispirandosi al tema “Forging Mobility Ahead” (definire lo sviluppo futuro della mobilità). L’azienda presenterà il primo router...
-
Giochi olimpici di Parigi 2024: il fattore sicurezza
Dopo la conclusione dei campionati europei di calcio ‘Euro 2024’, l’attenzione degli appassionati di sport è ora rivolta ai Giochi Olimpici di Parigi di quest’estate, uno dei più grandi palcoscenici del mondo che proprio per questo è...
-
Security Summit sbarca a Cagliari
L’innovazione digitale è certamente motore di sviluppo per il settore turistico alberghiero, così come può avere enormi potenzialità per le piccole e medie imprese del Made in Italy; imprescindibile è, tuttavia, la consapevolezza dei rischi cyber che...
-
Formazione multi-brand con Sacchi in automazione industriale
Sacchi Elettroforniture, azienda di riferimento nella distribuzione di materiale elettrico e rinnovabili del Nord Italia, prosegue nel suo programma di formazione dedicato a tutti i professionisti del settore elettrico, con l’obiettivo di formare i prossimi esperti e...
-
Quali sono i rischi informatici nell’industria manifatturiera?
Il rapporto Clusit del primo semestre del 2023 ha evidenziato in Italia un aumento del 40% degli attacchi informatici e preoccupa il fatto che il settore manifatturiero sia quello maggiormente colpito L’industria manifatturiera è uno degli obiettivi...
-
Un gemello digitale per una supply chain smart
Secondo reichelt elektronik l’integrazione di un gemello digitale nella catena di fornitura intelligente offre numerosi vantaggi Un gemello digitale è una rappresentazione virtuale di un oggetto fisico, di un processo o di un sistema di processo. Si...
-
La salvezza che viene dagli standard
Il ‘Main Event 2024’ di Consorzio PI Italia ha costituito un momento di confronto su due tematiche molto sentite dall’industria, robotica e cybersecurity, nonché un’occasione per ‘fare il punto’ sulla diffusione ed evoluzione delle tecnologie di comunicazione...
-
onsemi investe in produzione di carburo di silicio in Repubblica Ceca
onsemi annuncia il proprio piano di stabilire un impianto di produzione di carburo di silicio (SiC) all’avanguardia e integrato verticalmente in Repubblica Ceca. Il sito produrrà i semiconduttori di potenza intelligenti dell’azienda, essenziali per migliorare l’efficienza energetica...
-
Cybersecurity nella PA e nella sanità, l’andamento nei rapporti Clusit
Gli attacchi condotti dalla criminalità organizzata verso l’Italia sono in aumento più che nel resto del mondo, con una percentuale del 65% tra il 2022 e il 2023 (verso una crescita del 12% a livello globale). A...