Who's Who
Technology HowTo
“I team di DevOps hanno sempre considerato la security come un ‘problema secondario’ dando priorità ad elementi come la rapidità di sviluppo e il rilascio dei servizi, tralasciando spesso di eseguire i test di sicurezza”. L’impietoso quadro è tratto da un’analisi di Milan Hanson, senior analyst Infrastructure & Operations di Forrester, che nel suo ultimo report decide di spiegare l’errore di tali approcci attraverso i numeri di alcuni studi: “Un’analisi di Verizon (2016 Data Breach Investigations Report) su 100mila incidenti di sicurezza, conferma che oltre 3mila riguardano la violazione di dati; da un’indagine Ibm (commissionata a Ponemon – 2016 Ponemon Cost of Data Breach Study) emerge che il costo medio di una violazione è di 4 milioni di dollari, con un tempo medio di identificazione delle minacce di 201 giorni; infine, il report di Symantec (2016 Internet Security Threat Report) mostra che in media il 35% degli attacchi è contro le imprese (il 22% contro aziende medio-grandi ed il 43% contro le imprese piccole, quest’ultime divenute un bersaglio sempre più crescente)”, si legge nel report di Hanson.
La sicurezza delle applicazioni assume, di fronte a questi numeri, un significato ancora più critico nella visione di Forrester che, come spesso propone, ha steso una sorta di guida per spiegare alle imprese ed ai professionisti coinvolti nei processi DevOps come riuscire a migliorarla. Tre le mosse suggerite per lavorare su altrettante direttrici: persone, processi, tecnologia.
1) Persone: portare i professionisti della sicurezza all’interno dei team DevOps
Forrester suggerisce di creare team multidisciplinari dove gli esperti di sicurezza possano interagire con sviluppatori e operation fin dalle prime fasi del ciclo di application development per ‘influenzare’ il percorso da una prospettiva di protezione dei dati e sicurezza dell’applicazione stessa. Questi i passaggi chiave per rendere concreto questo primo step:
- creare team ‘misti’: non lasciare che gli esperti di sicurezza intervengano solo per eseguire test o per verificare la compliance ma fare in modo che possano interagire con i membri del DevOps in tutte le fasi;
- enfatizzare il ‘linguaggio’ della sicurezza: le aziende si aspettano dai propri esperti di sicurezza una riduzione dei rischi ed una più efficace protezione dei dati aziendali e dei clienti; un’applicazione diventa un canale di accesso ai dati e quindi la sicurezza diventa un elemento da ‘stressare’. Analisi delle vulnerabilità, delle intrusioni e delle minacce, così come l’interruzione di servizio o la qualità del software diventano tutti elementi che incidono sulla customer experience;
- focalizzarsi sulle vulnerabilità: come accennato, se l’applicazione diventa un canale di accesso ai dati aziendali, l’analisi delle sue vulnerabilità e di quelle che determina per l’azienda diventa un fattore critico non solo per la qualità del servizio ma anche per il business aziendale che viene sottoposto a un rischio.
2) Processi: ragionare sull’integrazione
I due differenti team, Sicurezza e DevOps, devono comprendere i processi gli uni degli altri per identificare le più efficace modalità di integrazione. Questi i suggerimenti di Forrester:
- allineare i processi: abbandonare l’idea di lasciare i test di sicurezza alla fine del processo di sviluppo, prima del rilascio, ma inserirli lungo tutto il ciclo (rende più semplici e rapidi gli interventi in caso di necessità ed aiuta lo sviluppo di un reale team multidisciplinare di DevSecOps);
- considerare caratteristiche e minacce allo stesso modo: anziché concentrarsi solo sulle caratteristiche funzionali della soluzione, iniziare a valutare le minacce di sicurezza come un ‘difetto’ della soluzione sul quale intervenire in fase di sviluppo (in questo modo si creano processi più consistenti);
- costruire relazioni solide per reagire velocemente: mettere tutto in sicurezza e garantire una protezione totale è praticamente impossibile, ma se esiste un team consolidato di DevSecOps i processi di intervento in caso di attacco o vulnerabilità diventano più rapidi (per esempio nel rilascio di patch affidabili per la messa in sicurezza di un servizio);
- adottare un approccio Agile: applicare le metodologie Agile con sviluppi e rilasci incrementali dei servizi anche per la sicurezza.
3) Tecnologia: unire le soluzioni di sicurezza nei tool di DevOps
Si ragiona ancora sul fronte dell’integrazione quando si scende al livello della tecnologia. “Lasciare i test di sicurezza all’ultima fase è rischioso e non si adatta alle pratiche Agile di sviluppo e rilascio incrementale – scrive l’analista di Forrester. È necessario che i tool di sviluppo integrino quelle di sicurezza sia per garantire che lo sviluppo stesso avvenga secondo logiche di security, sia per inserire i processi di testing in tutte le fasi”. Hanson suggerisce di integrare le tecnologie seguendo questi principi:
- governare i processi con audit automatici attraverso tool che automatizzino i test di sicurezza;
- aggiungere la sicurezza nel percorso di qualità del software, sfruttando gli output dei sistemi di sviluppo come dati ed informazioni per i sistemi di sicurezza (e viceversa);
- eseguire prove di sicurezza ‘come gioco’, ossia sfruttare tecnologie per la simulazione di attacchi e penetrazioni per valutare non solo la qualità e la sicurezza di un’applicazione ma anche la capacità di reazione del team DevSecOps.
