Di Marco Rottigni, Chief Technical Security Officer EMEA, Qualys
Lo sviluppo agile del software esiste da circa un ventennio, da quando è stato pubblicato il Manifesto originale di questa metodologia. Chi sviluppa software ha sempre puntato a realizzare applicazioni migliori, che soddisfino in modo più puntuale le esigenze degli utenti e i principi dello sviluppo agile sono sempre stati in linea con questi obiettivi. Nonostante ciò, ci sono ancora molti problemi che riguardano i processi e le politiche di sviluppo.
Le metodologie DevOps possono essere d’aiuto, grazie alla collaborazione tra i team di sviluppatori per realizzare software in modo più rapido ed efficiente. Ma per chi si occupa di sicurezza l’incremento delle tecniche DevOps ha portato non pochi problemi legati alla protezione e ai rischi informatici.
Mi vengono in mente gli Stealers Wheel nel brano Stuck in the Middle With You, dove il cantante è al centro, circondato da “Clowns alla mia sinistra/Jokers alla mia destra”. Come possono i team DevOps e di sicurezza evitare di restare “bloccati nel mezzo” e concentrarsi sui processi più opportuni per gli sviluppi futuri?
Progettare processi migliori tra i team
Uno dei temi caldi per i responsabili di sicurezza IT è l’essere coinvolti fin da subito nel processo di sviluppo, poiché spesso la sicurezza viene presa in considerazione solo quando le applicazioni sono state realizzate e sono in fase di produzione. Questo è certamente un approccio vecchio stile, che veniva utilizzato quando si utilizzava lo sviluppo a cascata e le applicazioni erano protette da forti difese perimetrali.
Oggi, la maggior parte dei software includono elementi di cloud, integrazione con API o codice di terze parti. È diventato più facile mixare componenti software per creare nuovi servizi anziché sviluppare da zero. Qualsiasi team che tenti di implementare in casa la propria crittografia o la sicurezza piuttosto che utilizzare prodotti pronti all’uso, finirà per complicarsi l’esistenza nel lungo termine. La combinazione di servizi best-in-class, componenti open source e codice sviluppato internamente può fornire risultati migliori più rapidamente.
Il primo problema in questo approccio riguarda la visibilità – con così tante componenti coinvolte in ogni applicazione, mantenere il tutto aggiornato e sicuro è una fatica di Sisifo che non ha mai fine. Per coloro che utilizzano container per far girare applicazioni basate su microservizi, questo può essere ancora più difficile: i container – ad esempio – possono essere progettati per essere attivi per tutto il tempo in cui è presente la richiesta del servizio per poi essere disattivati e “distrutti” una volta che i livelli di domanda diminuiscono. Mentre l’istanza dell’applicazione è in esecuzione, i componenti saranno operativi. Ed è proprio in questa fase che saranno vulnerabili.
I container vengono prelevati da repository in cui vengono memorizzate le immagini (software) fino a quando non sono necessarie. Le immagini possono essere sviluppate internamente o prese da librerie pubbliche ma, in entrambi i casi, vanno aggiornate e mantenute attuali. Se questo aggiornamento non viene eseguito con regolarità, un container teoricamente “nuovo” potrebbe essere creato già con degli errori.
Per qualsiasi applicazione basata su cloud, è necessario che tutte le informazioni su ciò che viene eseguito in ogni momento siano precise e dettagliate. Per i team di sicurezza IT, questi dati devono fornire loro elementi mirati sui rischi reali dei singoli servizi, mentre gli sviluppatori possono utilizzare queste stesse informazioni per ottenere una gestione reale delle istanze dell’applicazione e per esaminare le prestazioni.
Il secondo ambito in cui queste informazioni si rivelano essenziali riguarda l’analisi della responsabilità di tali risorse nel tempo. In caso di esecuzione in cloud le applicazioni si troveranno in infrastrutture terze, usufruendo di tutte le risorse necessarie per eseguire il servizio o consentire agli sviluppatori di configurare ed eseguire le proprie istanze sull’infrastruttura cloud di base.
Quando la sicurezza viene trattata dai team DevOps tramite collaborazioni ad hoc o processi DevSecOps più formali, è essenziale che questa non interferisca con il flusso di sviluppo del software. Al contrario, deve essere incorporata in modo nativo nel processo di compilazione del codice esistente tramite plug-in diretti e integrazione negli strumenti che gli sviluppatori utilizzano ogni giorno. Ciò consente loro di vedere la sicurezza come un modo per rendere il codice più efficiente, piuttosto che un elemento di disturbo.
Allo stesso tempo, adottare un modello di responsabilità condivisa cloud significa che i team di sviluppatori e di sicurezza devono collaborare su chi manterrà aggiornate le risorse. Non è importante chi lo fa – ciò che è importante è che lo faccia.
Pianificare in anticipo la collaborazione
Guardando al futuro del DevOps, gli sviluppatori continueranno ad assumersi maggiori responsabilità per l’intero processo di creazione ed esecuzione di software nel tempo.
Per i team di sicurezza, essere coinvolti nelle prime fasi del processo dovrebbe aiutare a integrare strumenti di sicurezza come la scansione delle vulnerabilità software o la gestione dei container. Questo non significa dire ai team software esattamente cosa fare, bensì aiutare i team di sviluppo a dare priorità al loro lavoro consapevoli dei problemi prima che colpiscano le istanze di produzione.
Fornire una visibilità tempestiva sui potenziali problemi di sicurezza può includere la scansione di errori comuni e software obsoleto nelle immagini fino all’applicazione delle best practice sulle applicazioni Web.
Offrendo indicazioni sui problemi nelle prime fasi del processo di sviluppo, questi possono essere risolti prima di entrare in fasi di test successive o in una distribuzione più ampia. Questo rende il processo di correzione più collaborativo e definito nelle priorità, piuttosto che un confronto tra team diversi con obiettivi diversi.
Per i team di sicurezza che cercano un coinvolgimento più stretto con DevOps, concentrarsi sulla sicurezza fine a sé stessa può essere controproducente.
Fornire agli sviluppatori maggiori informazioni sulle loro applicazioni garantirebbe invece che tutti lavorino per gli stessi obiettivi.
Concentrarsi sulla visibilità dei componenti dell’applicazione può aiutare tutti a vedere dove è necessario un intervento, mentre incrociare le informazioni sulle responsabilità e le priorità permette di destinare le risorse nelle posizioni giuste al momento giusto. Questo consiglio su ciò che conta di più – che è diverso per ogni azienda, in base alla propria storia IT e alle proprie scelte tecnologiche, piuttosto che essere lo stesso per tutti – significa che operando in concerto è possibile permettere a tutti di trovare la giusta strada, piuttosto che rimanere bloccati nei progetti sbagliati.
