Per mantenere il vantaggio competitivo e capitalizzare sulle nuove tecnologie, i team DevOps di molte organizzazioni si avvalgono di svariati strumenti IT, di sicurezza e componenti infrastrutturali. Tuttavia, la presenza di un maggior numero di soluzioni in azienda offre il fianco agli hacker che dispongono di più punti di accesso da cui colpire.
Gli attacchi alla catena di approvvigionamento del software – che utilizzano software di terze parti o librerie upstream liberamente disponibili e componenti che gli sviluppatori possono facilmente scaricare da Internet – sono diventati sempre più frequenti, con gli aggressori che sfruttano queste possibilità per violare contemporaneamente migliaia di aziende e organizzazioni.
Uno dei principali esempi di attacco alla supply chain del software è stato registrato nel 2020, quando il codice maligno scritto in un aggiornamento di SolarWinds si è diffuso attraverso i dipartimenti del governo federale degli Stati Uniti, prima di diventare globale e infettare circa 18.000 organizzazioni. Più recentemente, nel marzo di quest’anno, più di 20.000 organizzazioni sono state compromesse tramite una vulnerabilità in Microsoft Exchange Server.
Tuttavia, è altrettanto vero che la presenza di software complesso spesso è una necessità inevitabile per le imprese. Quindi, come affrontare questa minaccia alla sicurezza? La chiave sta nell’abbracciare le stesse idee, processi e strumenti che hanno permesso a DevOps di avere successo, e di integrare la sicurezza nelle persone, nei processi e nelle tecnologie. Così facendo, la sicurezza diventa una componente fondamentale e continua dei cicli di vita di applicazioni e infrastrutture, consentendo in pratica la creazione di una cultura “DevSecOps”.
Da DevOps a una cultura “DevSecOps”
Il passaggio a DevOps è stato rivoluzionario. Automatizzando i processi che esistevano tra i team di sviluppo e quelli operativi, gli sviluppatori hanno potuto creare software di alta qualità, permettendo ai team operativi di assicurare una delivery continua abbinata a una qualità di servizio costante.
Questo approccio può essere applicato anche alla sicurezza, da qui il concetto di DevSecOps. Ma cosa significa in pratica? Per dare un senso a DevSecOps, è necessario dare un senso a tre tecniche chiave che lo facilitano: automazione, standard aperti e architettura zero trust.
Tecnica 1: Automazione
Proprio come per DevOps, alla base di DevSecOps c’è l’automazione che permette processi coerenti e ripetibili che semplificano le interazioni tra sviluppo, infrastruttura IT e team di sicurezza. Il motivo che rende DevSecOps interessante è proprio la sua capacità di automatizzare i flussi di lavoro: che si tratti di assegnazioni di progetti, di gestire compiti semplici e ripetitivi per conto dei team, o di orchestrare e integrare gli strumenti IT.
Inoltre, l’automazione permette di automatizzare la sicurezza nell’intero ciclo di vita dell’applicazione. Creando pipeline di applicazioni comuni e automatizzate che portano gli strumenti e i controlli di sicurezza nei processi di applicazione e distribuzione, è possibile eseguire controlli di sicurezza approvati in ogni fase, assicurando che sicurezza e coerenza siano integrate nelle applicazioni fin dall’inizio.
Tecnica 2: Standard aperti
Come in ogni ecosistema specializzato, i professionisti della sicurezza hanno sviluppato le loro piattaforme e linguaggi per eseguire e descrivere processi e tecniche. Per realizzare pienamente DevSecOps, però, è importante che le esigenze e i requisiti dei team di sicurezza e DevOps siano facilmente traducibili tra loro.
È qui che entrano in gioco gli standard aperti e gli strumenti open source. Al contrario del software proprietario, il software e le applicazioni open source possono aiutare a standardizzare le piattaforme e i linguaggi utilizzati. In questo modo, sia i team DevOps che quelli di sicurezza possono fare il loro lavoro usando piattaforme compatibili in un modo che sia coerente e comprensibile per entrambi, risparmiando tempo e riducendo il rischio di errori nella traduzione dei flussi di lavoro tra i team.
Tecnica 3: Architettura zero trust
La chiave per affrontare un attacco alla supply chain è garantire che lo stack tecnologico di un’azienda non possa essere compromesso. Anche se un attore malintenzionato può ottenere le credenziali di accesso, le posizioni dei database o gli indirizzi IP – e negli attacchi più gravi, spesso lo fa – non dovrebbe poi essere in grado di accedere al resto del sistema o della rete.
Ecco perché le organizzazioni dovrebbero adottare un approccio di sicurezza “zero trust” partendo dalla considerazione che i tradizionali perimetri di rete e i modelli di fiducia impliciti non proteggono adeguatamente i dati, le risorse o i carichi di lavoro. La ‘fiducia zero’ sfrutta la capacità dei team di segmentare automaticamente le reti per evitare che qualsiasi violazione di una rete venga sfruttata. Invece di dare per scontata l’affidabilità di cose e persone che si trovano all’interno della rete IT, l’approccio zero trust presuppone il contrario e costruisce un ambiente di sicurezza intorno ai concetti di de-perimetrazione e minimo privilegio.
In questo modo i permessi sono iper-granulari, motivo per cui ogni violazione in una posizione della rete resterà confinata lì. Allo stesso tempo, però, l’automazione zero trust assicura anche che i flussi di lavoro regolari non vengano interrotti, dando rapidamente agli utenti legittimi un accesso sufficiente per fare il loro lavoro.
Nell’insieme, la cultura DevSecOps che si crea mescolando automazione, standard aperti e zero trust vede la sicurezza integrata nei cicli di vita delle applicazioni e delle infrastrutture fin dall’inizio, garantendo la robustezza dei processi, delle applicazioni e delle loro catene di fornitura associate e consentendo ai team di fornire applicazioni e servizi innovativi e affidabili.
