La transizione dal modello di sviluppo software Waterfall ad Agile, per giungere infine al DevOps, rende necessario cambiare in profondità le modalità con le quali l’organizzazione può/deve esercitare la gestione operativa della sicurezza nell’ambito di uno dei processi più delicati, ovvero quello del ciclo di vita.
In logica Waterfall, un modello lineare in cui le attività del progetto sono suddivise in diverse fasi sequenziali, anche i requisiti di sicurezza sono implementati nelle fasi finali del ciclo di vita, talvolta al termine di gran parte dello sviluppo (più frequentemente con rilasci successivi alle prime release), mentre ancora troppo raramente gli stessi test comprendono verifiche specifiche in grado di prevenire la presenza di vulnerabilità nel codice e/o nelle configurazioni che saranno portate in esercizio.
L’evoluzione Agile vede la sua principale innovazione nell’approccio iterativo allo sviluppo, consentendo modifiche in qualsiasi momento ai requisiti del prodotto.
Il DevOps porta ad un ulteriore passo avanti, riunendo sviluppo e operations in un unico un ciclo di vita in favore di una maggiore efficienza e automazione dei suddetti processi.
Come risultato di queste modifiche, il tempo necessario alla realizzazione dei progetti (scuseranno i lettori per l’uso della terminologia “tradizionale” in favore di una maggiore comprensione) è diminuito in modo significativo, da un rilascio ogni sei mesi, a un rilascio ogni settimana o due, fino a un rilascio ogni pochi giorni.
Questo soprattutto perché DevOps scardina il concetto tradizionale di progetto o di servizio, adeguandolo alla velocità di cambiamento del business, in cui pochissimi processi e servizi sono visti e mantenuti come entità statiche, per competere in un mercato in cui la capacità di adattarsi velocemente ad esigenze sempre nuove costituisce un fattore differenziante, talvolta abilitante al perseguimento degli obiettivi.
In questa vertiginosa sequenza temporale, i team di sviluppo software si sono resi conto di non poter più indirizzare le tematiche di sicurezza solo alla fine del ciclo, inopportuno ma tollerabile nel modello Waterfall: le implementazioni e le correttive di sicurezza affrontate solo prima del rilascio del software diventano troppo onerose, troppo costose e impediscono nel concreto di attuare pienamente il nuovo modello.
Indice degli argomenti
DevSecOps e SecDevOps: la differenza principale
DevSecOps e SecDevOps nascono come risposta al problema della sicurezza promettendo di colmare il divario tra i cicli di rilascio continui e le esigenze di sicurezza affrontando la sicurezza in ogni fase dell’SDLC (Software Development Life-Cycle).
Questi approcci spostano la sicurezza a sinistra del flusso (“shift left”), sostenendo l’implementazione delle pratiche di sicurezza già nelle fasi di pianificazione, analisi e progettazione oltre alle tradizionali fasi di implementazione e test: gli sviluppatori si assumono la responsabilità principale della sicurezza durante la scrittura del codice e i test di sicurezza vengono eseguiti durante tutto il processo di sviluppo.
I termini DevSecOps e SecDevOps sono spesso usati in modo intercambiabile, ma c’è un’importante differenza di fondo: mentre DevSecOps sostiene che la sicurezza debba essere incorporata in ogni fase del ciclo di vita dello sviluppo del software, SecDevOps ritiene che la sicurezza debba essere la priorità principale in ogni fase dell’SDLC.
Secondo SecDevOps, tutti i professionisti DevOps devono essere anche professionisti della sicurezza. In questo modo il maggior numero possibile di attività di sicurezza può essere eseguito all’interno della routine quotidiana del team DevOps, affiancato da un minimo team specialistico che si concentra sulla definizione di policy, supervisiona la distribuzione continua ed eseguono attività complesse come i penetration test.
Sviluppo sicuro del software, tra automatismo e shift left dei controlli: linee guida
SecDevOps: come e da dove iniziare
Il primo passo per introdurre il SecDevOps in azienda è individuare un progetto “pilota” su cui iniziare a implementare le logiche previste e tramite il quale è possibile testare la mutua influenza dei membri del team.
Una volta che tale progetto è a pieno regime e gli automatismi che si celano dietro al rilascio del software sono testati con successo e formalizzati, si predispone un modello di riferimento (comprensivo dei tool a supporto) che potrà successivamente essere adottato per altri progetti in portfolio, divenendo via via l’approccio standard dell’Organizzazione.
La spinta educativa della componente Security è un ingrediente fondamentale, considerando peraltro che il classico rapporto fra le risorse di Security e quelle di sviluppo è drammaticamente sbilanciato a livello numerico verso i secondi.
Security dovrà quindi farsi carico della responsabilità di impostare ed erogare l’opportuna attività formativa al resto del team: ciò può avvenire in diversi modi, dai più classici quali webinar o istruzione in classe a quelli più innovativi e coinvolgenti quali la gamification.
Le tematiche trattate vanno mantenute disponibili in apposita knowledge base aggiornata e resa disponibile a tutti i membri del team.
Testare le conoscenze permette inoltre di individuare dei membri particolarmente sensibili alle tematiche, i cosiddetti security champion, che possono fare da traino ai colleghi e diventare figure centrali dell’intero processo (ad esempio supportando i colleghi nella peer review degli output dei test di vulnerabilità o venendo coinvolti nelle attività di threat modelling).
La complessità è elevata e ogni scelta funzionale relativa agli strumenti da utilizzare va valutata in funzione di quali sono i benefici e quale impegno richiede.
In questo senso, il team SecDevOps potrebbe avviare una fase di sperimentazione che coinvolga tutto il team per facilitare la conoscenza e la capacità di utilizzo da parte di ciascun membro, confrontandosi poi sull’efficacia ed efficienza dello strumento stesso.
Ciò si svolge in un contesto in cui la spinta verso il concetto di privacy by design (e by default) è sempre più stringente, e assicurare tale obbligo passa anche da un livello di maturità e consapevolezza da parte di tutto il team particolarmente elevato circa concetti un tempo appannaggio della sola funzione di sicurezza informatica, quali ad esempio:
- “pulizia” del codice, ovvero utilizzo di codice opportunamente formattato secondo una naming convention ben definita, non esposizione della struttura del database, controllo della comunicazione con il codice di terze parti (ad esempio librerie open source…), validazione dell’input inserito dall’utente, gestione dell’errore;
- threat modelling: conoscenza dei potenziali attacchi a cui la propria applicazione può essere esposta;
- utilizzo delle liste di vulnerabilità note e dei framework di riferimento per lo sviluppo sicuro (Owasp top ten list, Owasp security knowledge framework, Mitre top 25).
I tool a supporto del metodo SecDevOps
Non bisogna dimenticare tuttavia che l’introduzione della sicurezza nell’ambito del ciclo di vita è un obiettivo che arriva dal passato, ma che ha ottenuto scarsa fortuna anche nell’ambito di modelli operativi più tradizionali.
Come potrebbe quindi un’organizzazione riuscire a ottenere questo risultato mettendo in atto contestualmente un cambiamento così significativo nel modello di funzionamento della propria ICT, quale l’adozione del DevOps?
Il nuovo modello infatti è sostenuto da obiettivi e aspettative di velocità ed efficienza che, almeno apparentemente, sono in contrasto con quelli di sicurezza e qualità del software.
D’altro canto, uno degli aspetti di maggiore successo nell’introduzione del DevOps è la forte automazione che sostiene questo tipo di modello operativo. Automazione che è essenziale nel garantire la cooperazione nell’ambito delle squad ed i cicli serrati di release&deploy.
Va in tale direzione anche la componente di security, grazie innanzitutto alla possibilità di integrazione di specifici strumenti o funzionalità di sicurezza negli stessi strumenti di gestione delle attività di development e deployment che costituiscono il “motore” operativo del DevOps.
Strumenti quali i SAST (Static Application Security Testing) che permettono di analizzare il codice sorgente di una applicazione, o come i DAST (Dynamic Application Security Testing) che al contrario si concentrano sull’individuazione di falle simulando un possibile attacco, offrono oggi una capacità di intervento molto maggiore che in passato.
Non si tralascino, inoltre, ulteriori tool la cui nascita è ancora più recente come i cosidetti IAST (Interactive Application Security Testing) ed i RASP (Runtime Application Self Protection) che offrono una prospettiva differente e più legata alla “difesa” dell’applicazione in produzione.
È opportuno ricordare come alla sicurezza concorrano anche quelle funzionalità degli strumenti non direttamente riconducibili all’individuazione di vulnerabilità, le quali tuttavia portano ad una riduzione significativa dei tipici di errori di programmazione e “cattive pratiche”, contribuendo di fatto a diminuire l’esposizione a futuri attacchi.
A questo proposito, si pensi ad esempio alla possibilità di fare il cosiddetto “forking” del codice offerta da repository quali Github, clonando un progetto e modificandolo con le opportune patch di sicurezza e modifiche funzionali piuttosto che al controllo di versione, attraverso il quale in caso di attacco o compromissione è possibile ripristinare velocemente l’applicazione ad una versione precedente non compromessa.
La vera sfida non è tanto legata alla selezione di una singola soluzione che soddisfi da sola la componente Security di SecDevOps, quanto alla capacità di comprensione che un uso corretto e ragionato di ogni mezzo a disposizione contribuisce in maniera decisiva allo scopo di far diventare la Security una condizione sempre presente e a cui non è possibile rinunciare.
Conclusioni
Indubbiamente l’inclusione della sicurezza all’interno del modello DevOps comporta una serie di benefici non trascurabili per l’organizzazione che riesca in questo compito non facile, a prescindere da quanto essa sia centrale rispetto ai mondi del Dev e dell’Ops.
In primo luogo, consente all’Organizzazione che segua questo approccio di poter misurare in qualsiasi momento il proprio “stato di salute”, garantendo visibilità sulle proprie vulnerabilità e di conseguenza possibilità di sapere dove e come intervenire.
Poter avere il “controllo” del proprio codice e poterne tracciare i cambiamenti nel dettaglio è un beneficio il cui valore è facilmente comprensibile e può realmente essere la chiave per la vita o la morte di un progetto.
Come accennato in precedenza, è inoltre fondamentale in ottica di privacy e security by design perché diventa un elemento nativo e non più “rincorso” alla fine del processo di sviluppo, peraltro potendo garantire – se correttamente implementata – il rispetto degli standard di settore e delle best practice in tema di sicurezza.
Una conseguenza positiva è sicuramente anche l’utilizzo di strumenti tecnologici moderni in grado di apportare valore, il cui utilizzo libera i collaboratori da quei task a scarso o nullo valore aggiunto automatizzando un gran numero di operazioni manuali e permettendo alle persone di dedicare il proprio tempo a ciò che richiede più impegno.
Riuscire a fare SecDevOps piuttosto che DevSecOps aggiunge a tutto ciò una maggiore rapidità nella gestione delle vulnerabilità (“switch left”) che si traduce in un beneficio anche economico in quanto prima viene intercettato e risolto il problema e minore è l’esborso.
Tale rapidità significa anche flessibilità massima nel saper rispondere al cambiamento delle esigenze funzionali: se riusciamo a fare di Sec il nostro pilota automatico quando affronteremo una curva particolarmente impegnativa non ci sarà bisogno di fermarsi a cercare l’assetto corretto e poi ripartire ma saremo in grado di curvare rallentando il giusto per poi riprendere a pieno ritmo immediatamente dopo.
L’ultimo e più grande beneficio è tuttavia puramente umano, e consiste nell’aumento di consapevolezza e responsabilità da parte dei collaboratori, non più “costretti” ad includere la sicurezza nel ciclo di vita ma attori primari e decisivi affinché essa sia il principio fondante di ogni attività che viene svolta.
Fare SecDevOps significa soprattutto questo, ovvero radicare un concetto tanto banale quanto decisivo ed imprescindibile nella testa di tutti.
L’Organizzazione che riesce a perseguire questo fine è un’organizzazione che si crea un patrimonio inestimabile e riesce ad attuare nel concreto un cambio culturale fondamentale non solo per il successo, ma per la sopravvivenza stessa.
