I CIO ei loro reparti IT devono affrontare una notevole pressione aziendale per modernizzare le applicazioni, migliorare l’esperienza dei clienti, migrare le applicazioni nel cloud e automatizzare i flussi di lavoro. Sviluppo agile e devops comprendono le culture, le pratiche, gli strumenti e le automazioni che consentono ai team di sviluppo software di raggiungere questi obiettivi e fornire valore aziendale con maggiore qualità e in cicli di rilascio più rapidi.

I team di sviluppo più avanzati dispongono di pipeline di integrazione e distribuzione continua (CI/CD) completamente automatizzate, collegano i flussi di lavoro di gestione delle modifiche e degli incidenti con strumenti di sviluppo agili e utilizzano le piattaforme AIops per trovare più rapidamente le cause alla radice dei problemi di produzione.

Tuttavia, i problemi di sicurezza nello sviluppo del software persistono. Nella ricerca ESG sulla sicurezza per lo sviluppo di applicazioni moderne, solo il 36% degli intervistati valuta il proprio programma di sicurezza delle applicazioni con un punteggio di 9 o un 10, mentre il 66% ha affermato che gli strumenti di sicurezza delle applicazioni proteggono meno del 75% della propria base di codice e il 48% ha ammesso di inserire regolarmente codice vulnerabile nella produzione.

Queste carenze di sicurezza non sono dovute alla mancanza di tecnologia, consulenza o fornitori di servizi di sicurezza. Il Cybersecurity Almanac 2020 identifica più di 3.500 potenziali partner per la sicurezza. In definitiva, la chiave per fornire valore aziendale riducendo al minimo i rischi per la sicurezza nello sviluppo del software è definire chiaramente i principi di sicurezza e comunicarli ai team di sviluppo software. Ecco sei rischi su cui i CIO ei leader IT dovrebbero concentrarsi e i modi per affrontarli.

Rischio n. 1: non trattare la sicurezza come un cittadino devops di prima classe

È facile dire che l’organizzazione mette la sicurezza al primo posto e molte organizzazioni seguono le migliori pratiche di sicurezza in ambito agile e devops. Ma con infosec spesso a corto di personale rispetto al numero di team di sviluppo, è facile vedere come altre priorità di debito tecnico e aziendale dominano gli arretrati di team agili e perché le pratiche di sicurezza non vengono adottate in modo uniforme in tutta l’organizzazione.

La ricerca ESG supporta questa conclusione. Mentre il 78% degli intervistati afferma che i propri analisti della sicurezza coinvolgono direttamente gli sviluppatori, solo il 31% esamina le singole funzionalità e il codice. Si tratta di un divario considerevole ed è improbabile che la maggior parte delle organizzazioni possa assumere un numero sufficiente di esperti di sicurezza per assegnarli permanentemente a team di sviluppo agili. Ma ecco cosa possono fare molte organizzazioni:

  • Richiedere formazione continua sulla sicurezza per l’intero team di sviluppo software
  • Chiedere a infosec di documentare gli standard dei criteri di accettazione della sicurezza in strumenti come Atlassian Confluence o Microsoft Teams e richiedere ai team agili di farvi riferimento
  • Formalizzare la collaborazione sulla pianificazione agile e sulla gestione dei rilasci in modo che infosec possa contrassegnare le funzionalità a rischio più elevato nelle prime fasi del processo di sviluppo
  • Registrare e pubblicare le revisioni degli sprint in modo che infosec possa segnalare le implementazioni rischiose

Definire i principi, garantire la collaborazione tra i team, migliorare la cultura e promuovere la felicità del team possono essere i modi più importanti in cui i CIO possono contribuire a migliorare la sicurezza del software. Nel sondaggio della community DevSecOps 2020, sviluppatori soddisfatti hanno dimostrato di essere 3,6 volte più propensi a prestare attenzione alla sicurezza.

DevOps

Rischio n. 2: sviluppo di implementazioni tecniche proprietarie

I team di sviluppo software amano la codifica e lo sviluppo di soluzioni e le organizzazioni hanno bisogno della loro magia, innovazione e abilità tecniche per affrontare le sfide aziendali urgenti. Ma a volte i requisiti portano i team di sviluppo a risolvere difficili sfide tecniche e implementazioni che potenzialmente potrebbero adottare da fonti di terze parti.

Low-code e no-code a volte possono significare soluzioni più sicure. Ci sono almeno due ragioni per questo. In primo luogo, i proprietari di prodotti agili non sempre conoscono le implicazioni per la sicurezza delle loro funzionalità principali. In secondo luogo, molti fanno fatica a formulare requisiti senza dettare elementi della soluzione, il che a volte porta i team a implementare soluzioni ad alta intensità di codice che introducono rischi per la sicurezza.

Rischio n. 3: scarsa governance e gestione delle componenti open source e commerciali

Conoscete la storia di come i team devops sono i più attrezzati per scegliere i propri strumenti? È una convinzione spesso dichiarata dai team devops avanzati. Tuttavia, molti CIO, leader IT e CISO mettono in guardia dal conferire ai team devops l’autorità decisionale carta bianca sulla selezione di strumenti e componenti.

Allo stesso tempo, la maggior parte dei leader riconosce anche che troppe restrizioni e processi di approvazione complessi rallentano l’innovazione e frustrano gli sviluppatori di talento. I CIO, i leader IT e i CISO devono definire regole chiare e facili da seguire e una governance ragionevole in merito a selezioni, aggiornamenti e patch.

In un sondaggio di 1.500 professionisti IT su devsecops e gestione open source, solo il 72% degli intervistati dichiara di avere una politica sull’uso dell’open source e solo il 64% ha dichiarato di avere un consiglio di amministrazione open source. Questa è solo la punta del problema, poiché il 16% degli intervistati ritiene di poter risolvere una vulnerabilità open source critica una volta identificata.

Questi risultati sono preoccupanti dato il numero di violazioni segnalate legate a componenti open source. Nel sondaggio della comunità DevSecOps 2020, il 21% degli intervistati ha riconosciuto violazioni relative ai componenti open source. Non è solo un problema dell’open source, poiché anche qualsiasi sistema commerciale può presentare vulnerabilità di sicurezza API o altre vulnerabilità di componenti software.

Politiche, governance e pratiche di gestione chiaramente definite sull’utilizzo dell’open source, sulla selezione degli strumenti e sulla gestione del ciclo di vita della tecnologia sono necessarie per mitigare i rischi. Ma le organizzazioni differiscono sulle migliori pratiche; alcune propendono per una maggiore apertura mentre altre verso una minore tolleranza al rischio e verso procedure più rigorose. Per stabilire una politica equilibrata tra sicurezza e innovazione, i CIO dovrebbero creare un team multidisciplinare per definire le procedure di governance, gli standard di pratica, gli strumenti e le metriche.

Disporre di strumenti che integrano le capacità degli sviluppatori con le migliori pratiche di sicurezza può alleviare alcune delle sfide legate alla selezione di componenti open source. Jay Jamison, chief product and technology officer di Quick Base, ha condiviso questo suo pensiero sull’approccio di Quick Base all’innovazione tramite l’open source:

“Siamo tra i primi ad adottare GitHub Advanced Security, che rende più facile sradicare le vulnerabilità nei progetti open source gestiti sulla sua piattaforma. Questo è un passo importante per spostare la sicurezza nelle prime fasi del ciclo di vita dello sviluppo del software o, come è noto tra gli sviluppatori, spostarsi a sinistra”.

Rischio n. 4: accesso illimitato a repository di codice sorgente e pipeline CI/CD

La protezione del software interno equivaleva a bloccare i repository di controllo della versione, scansionare il codice per le vulnerabilità, definire i privilegi minimi per facilitare le distribuzioni, crittografare le connessioni ed eseguire test di penetrazione. Il blocco della rete e dell’infrastruttura era un ambito di sicurezza completamente separato che comprendeva strumenti e discipline separati gestiti dalle operazioni IT.

Oggi ci sono più rischi e più strumenti, ma anche migliori integrazioni. Ho parlato con Josh Mason, vicepresidente dell’ingegneria di Cherwell, dell’approccio della sua azienda alla protezione del codice. “In Cherwell stratifichiamo test di sicurezza con analisi statica automatizzata (SAST), test di sicurezza delle applicazioni dinamiche e test di penetrazione, che all’unisono tendono a migliorare la produttività. L’implementazione di SAST come parte della pipeline CI/CD sposta il processo di discovery ulteriormente a sinistra nel ciclo di vita dello sviluppo del software, determinando risoluzioni più rapide e meno costose”.

Rajesh Raheja, capo dell’ingegneria di Boomi, un’azienda di Dell Technologies, consiglia diverse discipline di sicurezza. “Se il software non è sviluppato correttamente, il rischio per la sicurezza è amplificato su una scala molto maggiore rispetto a una violazione di un singolo sistema. Potete mitigare i rischi proteggendo la pipeline CI/CD, bloccando i sistemi con il principio del privilegio minimo, implementando soluzioni alternative sicure per l’automazione con autenticazione a più fattori, promuovendo la consapevolezza della sicurezza all’interno dei membri del team e sviluppando pratiche di codifica sicure”.

Rischio n. 5: protezione e gestione dei dati sensibili

Sebbene molti team devops siano esperti nelle pratiche di sicurezza per lo sviluppo, il test e la distribuzione di applicazioni, devono anche stratificare le pratiche di sicurezza relative alla gestione dei dati e ai dataops.

Chris Bergh, CEO di DataKitchen, spiega il problema e un approccio per automatizzare una maggiore sicurezza delle operazioni sui dati. “La privacy dei dati e le sfide alla sicurezza impediscono alle aziende di monetizzare i propri dati per un vantaggio competitivo. I processi manuali non possono risolvere il problema: semplicemente ci sono troppi dati che fluiscono troppo rapidamente. Datasecops è una metodologia che automatizza la privacy e la sicurezza dei dati, integrando privacy, sicurezza e governance in flussi di lavoro automatizzati che vengono eseguiti insieme allo sviluppo, all’implementazione e alle operazioni dell’analisi dei dati”.

La principale sfida per i dataops dei CIO e dei leader IT è l’adozione di una governance proattiva dei dati, l’etichettatura dei dati sensibili e la formazione di sviluppatori e data scientist su pratiche di dati accettabili. La centralizzazione della gestione delle identità, la definizione dei diritti basati sui ruoli e il mascheramento dei dati sensibili negli ambienti di sviluppo sono pratiche importanti per la sicurezza e la riservatezza dei dati.

La gestione dei dati sensibili va oltre la sicurezza dei dati. Ad esempio, molte aziende, in particolare quelle nei settori regolamentati, devono acquisire la discendenza dei dati mostrando chi, quando, dove e come i dati cambiano. Queste aziende spesso utilizzano l’integrazione dei dati e le piattaforme di gestione dei dati che hanno funzionalità di derivazione dei dati incorporate.

Rischio n. 6: competenze e soluzioni di sicurezza fai-da-te

Il mio approccio alla gestione del rischio e della sicurezza è sempre stato quello di chiedere consiglio a diversi esperti. Le minacce alla sicurezza stanno crescendo in intensità e complessità ed è improbabile che la maggior parte delle organizzazioni abbia tutte le competenze necessarie. Inoltre, quando sorgono problemi di sicurezza, avere un elenco di persone con cui consultarsi per ridurre i rischi, affrontare i problemi, raccogliere informazioni forensi e puntellare le vulnerabilità è fondamentale per ridurre al minimo gli impatti.

Sebbene gli strumenti e le pratiche aiutino i CIO ad affrontare i problemi odierni, abbiamo bisogno degli esperti che ci aiutino con la prossima serie di sfide alla sicurezza.