Sicurezza e DevOps: cosa vuol dire "shift left" ?

Nel documento DBIR (Data Breach Investigations Report) 2021 rilasciato in Maggio da Verizon si analizzano le investigazioni su incidenti e data breach informatici del difficile anno appena trascorso.

Tra le diverse evidenze identificate nelle cause di incidenti e di perdite dati, una colpisce sia per la ricorrenza in entrambe le categorie che per la posizione in classifica – al secondo posto per importanza: gli attacchi alle applicazioni web.

La combinazione tra trasformazione digitale delle aziende e l’emergenza pandemica hanno caratterizzato importanti cambiamenti, che recentemente hanno enormemente amplificato l’utilizzo di applicazioni web per larga parte della produttività personale e professionale.

Figura 1 - Classifica delle cause di incidenti e compromissioni

- Fonte: Verizon DBIR 2021

Da un lato il tanto deprecato "lavoro da casa" si è in realtà rivelato un'eccellente soluzione, che ha contribuito a mitigare la devastazione che diversamente avrebbe colpito l'operatività delle aziende in modo importante.

Aziende che sia nei dirigenti che nei dipendenti hanno mostrato una creatività notevole nonostante note problematiche infrastrutturali ed operative.

Dall’altro si è assistito ad un aumento esponenziale della superficie di attacco esposta e dei conseguenti rischi di compromissione.

Il consorzio Open Web Application Security Project (OWASP) manutiene una lista di 10 categorie di vulnerabilità gravi sulle web application, in modo da permettere ai team di security di intervenire nel loro controllo.

Il problema rimane nella scarsa attenzione ad un’igiene digitale preventiva e a controlli applicati solo quando l’applicazione è pubblicata in Internet, quindi raggiungibile sia da utenti legittimi che – purtroppo – da cybercriminali.

Altra causa di debolezza degli applicativi web sta negli intervalli molto ampi – a volte anche di semestri o più – con cui sono eseguite verifiche per la presenza di vulnerabilità.

È necessario aumentare il livello di maturità di aziende e organizzazioni nei confronti di questa igiene digitale mancante, con un’azione spesso definita come shift left security.

Per capire meglio l’idea va analizzato il processo con cui sono sviluppate, verificate ed infine pubblicate le applicazioni web, secondo i dettami della metodologia agile che prevede Continous Integration, Continuous Delivery/Deployment (CI/CD).

Spesso rappresentato come un ciclo che ricorda la forma dell’infinito matematico, il flusso operativo di integrazione ed implementazione continua viene frequentemente sintetizzato con il termine DevOps – ad indicare la stretta collaborazione tra il team di sviluppo (Dev) ed il team di gestione operativa (Ops).

Figura 2 - Illustrazione del Ciclo DevOps

La domanda importante a questo punto diventa: dove inserire i controlli di sicurezza, per evitare che le vulnerabilità – quindi i potenziali vettori di attacco – siano scoperti quando l’applicazione è visibile e raggiungibile da chiunque?

Ecco l’idea alla base di “Shift Left Security”.

Quando un’organizzazione implementa il paradigma DevOps, spesso il processo prevede l’adozione di piattaforme software che agevolino la transizione tra le varie fasi del ciclo.

Esempi di queste piattaforme sono Jenkins, Bamboo, TeamCity, etc.

Figura 3 - Esempio di istruzioni nella fase Build

La logica utilizzata prevede di gestire i vari momenti, quali recupero del codice dal repository centralizzato (es. GitHub), eseguire le istruzioni per compilare l’applicazione (fase di build), eseguire azioni prima o dopo la fase di build (es. trasferire il semilavorato in un altro ambiente o eseguire il compilato).

La maggior parte di queste piattaforme sono strutturate in modo aperto, supportando plug-in software che permettano di espandere le funzioni di base previste dalla piattaforma.

Proprio grazie a questi plug-in è possibile integrare controlli di sicurezza automatici, in modo che intervengano nei passaggi tra una fase e la successiva.

A seconda dei plug-in utilizzati è addirittura possibile impostare dei criteri di sicurezza, in base ai quali la fase di build possa concludersi con successo o con errore.

Figura 4 - Esempio di definizione criteri di sicurezza con plugin

Ad esempio, definire che in presenza di vulnerabilità software oltre una certa soglia numerica o di criticità il progresso lungo la pipeline non debba essere possibile.Altre opzioni di configurazione dei plug-in permettono di esporre gli errori e le problematiche di security direttamente nella schermata visibile agli sviluppatori, in modo da renderli autonomi nella risoluzione del problema.

In questo modo i controlli di sicurezza si spostano sempre più verso l’origine, garantendo una miglior resilienza dell’applicazione quando finalmente verrà promossa in produzione e mitigando il rischio di attacchi informatici.

La tecnica dello “shift left” non riguarda soltanto le pipeline di produzione delle applicazioni web, ma viene spesso adottata per implementare lo stesso livello di agilità in ambiti quali container applicativi, formazione risorse cloud, immagini di server e client, infrastruttura.

Si tratta, in sostanza, di una crescita nella maturità del programma di sicurezza di un’organizzazione che riesce a combinare in modo efficiente agilità, velocità operativa ed efficacia nei controlli di sicurezza.

Marco Rottigni