Negli ultimi anni stiamo assistendo ad un cambiamento epocale dell’approccio al rilascio di software e creazione di nuove applicazioni in generale. I nuovi processi di DevOps prevedono infatti un forte cambiamento culturale che porta i team di sviluppo e operation ad una maggiore collaborazione per far fronte ad una pressione imposta dal business che non si era mai vista.
Il Time To Market richiesto per rilasciare al mercato nuovi servizi è estremamente sfidante e ha portato le strutture a supporto del business a dover rilasciare nuove funzionalità e soluzioni in tempi molto ridotti.
A queste velocità è facile immaginare come chi si occupi di sviluppo abbia la necessità di focalizzarsi il più possibile sul coding lasciando la definizione degli ambienti di sviluppo alle operation che a loro volta, per far fronte alla agilità richiesta, hanno trovato nel Cloud, la velocità e automazione necessarie per raggiungere gli obiettivi di rilascio richiesti dal business.
Le nuove practice e soluzioni hanno permesso agli sviluppatori di passare allo sviluppo agile spostando la strategia da applicazioni monolitiche a soluzioni a microservizi garantendo cicli di sviluppo molto più veloce, e cambiando così il modello operativo.
IDC ha previsto che entro 5 anni verranno realizzate fino a 500 milioni nuove applicazioni, che corrispondono al numero di applicazioni create negli ultimi 40 anni (IDC FutureScape: Worldwide IT Industry 2019 Predictions).
E questi cambiamenti hanno portato anche nuove sfide per i CISO che si trovano a definire la strategia di sicurezza in ambienti Cloud e Multi Cloud in modo completamente diverso rispetto all’ on premise. In passato, infatti, la Security era responsabilità di team dedicati che intervenivano a posteriori, ma le nuove metodologie DevOps, i nuovi cicli di sviluppo cloud-native, piu veloci e frequenti, hanno portato la Security ad essere sempre più continua e integrata in tutte le fasi dei processi di sviluppo, spostando l’attenzione all’inizio della pipeline CI/CD e automatizzando le attività di controllo, con l’obiettivo di non rallentare il ciclo di sviluppo.
Ma con la nuova metodologia DevSecOps, anche gli sviluppatori sono chiamati a ripensare la creazione del codice e a condividere con molta più frequenza feedback e informazioni sulle vulnerabilità note ai team di sicurezza. Questo nuovo approccio “Security By Design”, porta ad un cambiamento culturale mai visto in precedenza e non secondario.
Diverse ricerche di mercato ci fanno notare come negli ultimi anni, più del 70 % delle vulnerabilità, arrivano dalle applicazioni e Forrester (Forrester’s State of Application Security, 2021 Report) conferma come il passaggio al lavoro remoto abbia infatti spinto le aziende a fare ancora più affidamento sulle applicazioni, e questo spiega perché le applicazioni web sono oggi la forma più comune di attacco, seguita da vulnerabilità del software.
Secondo il NIST (National Institute of Standards and Technologies), il costo di fix delle vulnerabilità, una volta che il codice è in produzione, può essere 60 volte più oneroso rispetto che nelle fasi di sviluppo. Se pensiamo ad esempio come i processi di Infrastructure as Code (IaC), aiutino a scalare e ridurre i tempi di sviluppo, ci rendiamo subito conto come vulnerabilità o mis-configurations non identificate all’inizio del processo, possano essere esponenzialmente replicate alle velocità del cloud.
In scenari come questi, così fluidi ed eterogenei, un errore che rileviamo è quello di utilizzare ancora soluzioni specifiche per il singolo processo (single-point solutions) e non un approccio a piattaforma, coprendo così solo una parte del problema e creando competenze verticali che non garantiscono un passaggio trasversale di competenze nei team, e portando l’azienda a dover gestire numerosi contratti a condizioni diversi tra numerosi fornitori.
Una piattaforma di sicurezza nativamente integrata nei processi di sviluppo aiuta le best practices DevSecOps ad aumentare la visibilità ed a gestire in modo olistico e ZeroTrust tutta una serie di problematiche quali vulnerability assessment, runtime security, la micro segmentazione a livello Multi Cloud, la governance degli access ecc.
Grazie ad Azure Security Center e le funzionalità di Azure Policies e Azure Compliance Manager, i team di sicurezza possono iniziare ad avere un primo controllo del rischio, della postura e compliance delle risorse a livello Cloud e Multi Cloud (CSPM). Le best practice suggerite da Microsoft basano il loro valore nella protezione che Azure Security Center può offrire per la gestione degli accessi e nelle fasi iniziali di sviluppo, spostando sempre più a sinistra la protezione dei workload, per esempio identificando vulnerabilità nelle immagini dei container (Azure Container Registry), proteggendo le istanze del servizio Azure Kubernetes oppure sfruttando Azure Arc per proteggere workload fuori Azure (CWPP).
L’adozione di Github è chiaramente un primo passo per migliorare la postura in termini di sicurezza del mondo DevOps. Ma è solo l’inizio.
Molte sono le strategie atte a modificare il codice sorgente tramite il quale è possibile veicolare un attacco informatico. Il caso di Solarwinds è solo l’ultimo. La risposta di Microsoft per cercare di mitigare queste vulnerabilità prende il nome di DevSecOps.
DevSecOps, si basa sui principi di DevOps , ma aggiunge una maggiore attenzione alla sicurezza. Con DevSecOps, la sicurezza diventa una parte centrale dell’intero ciclo di vita dell’applicazione e riesce anche a forzare una standard di lavoro per un gruppo anche distribuito. Questo concetto è “Shift-Left Security”: spostamento della sicurezza permette di intercettare criticità dalle prime fasi di sviluppo includendo anche la gestione di vulnerabilità dei framework utilizzati per lo sviluppo.
Microsoft e GitHub offrono soluzioni che permettono di eseguire codice certificato in ambienti di produzione, esaminando anche la relativa tracciabilità soprattutto per i componenti di terze parti in uso.
Questa unione ha permesso di gestire in modo strategico la sicurezza in tutte le fasi di gestione delle applicazioni.
I quattro componenti in Azure che garantiscono questa sicurezza end-to-end in Ambienti DevSecOps sono:
GitHub, la piattaforma per sviluppatori più diffusa al mondo, offre funzionalità avanzate che contribuiscono alla protezione del codice e delle dipendenze delle applicazioni con:
- GitHub Advanced Security sfrutta CodeQL, il motore di analisi semantica del codice per identificare vulnerabilità nel codice.
Identifica e correggi i problemi di sicurezza nelle dipendenze usando gli avvisi di sicurezza e gli aggiornamenti automatici della sicurezza (Dependabot).
Grazie all’uso di Azure Pipelines per l’integrazione continua, il codice viene compilato e inserito in pacchetti in un contenitore Docker cifrati e formati, specialmente su repositories di tipo privato.
Le immagini applicative di produzione vengono archiviate in Azure Container Registry, dove vengono analizzate automaticamente per rilevare vulnerabilità grazie all’integrazione con il Centro sicurezza di Azure.
Tramite il Centro di Sicurezza (Aure Defender) è possibile governare l’intera supply chain del software. Tutte le nuove applicazioni create sfruttano codice scritto da terze parti, inclusi componenti open source. Benché questo approccio offra vantaggi chiari, incrementando la produttività e migliorando la collaborazione, crea anche difficoltà correlate al controllo e alla protezione della supply chain per il software.
Spesso ci si trova a capire come integrare controlli di questo tipo su ambienti collaudati ed in esercizio.
Spesso per i CISO questo tipo di approccio richiede uno studio più o meno complesso e spesso tende a far percepire una situazione di rallentamento delle attività. È utile in questi casi utilizzare una strategia tecnica di implementazione secondo questi 3 pillars:
Questa strategia permette di accelerare l’adozione dei servizi di sicurezza di DevSecOps in modo strutturato.
Microsoft si trova in una posizione privilegiata perché conosce molto bene le sfide in ambito DevOps, ed è anche molto attenta a garantire competenze verticali e consulenti in grado di seguire end-to-end i processi DevSecOps.
Vi invitiamo a seguire la nostra Security Community (Sign In) per webinar, video e aggiornamenti e contattarci direttamente o attraverso i nostri partners per ricevere maggiori informazioni.
Autori: Alessandro Nava, Sr. Enterprise Security Executive – Matteo Creati, Cloud Solution Architect
