La trasformazione digitale fino ad oggi ha causato una crescita pervasiva di applicazioni multidispositivo, di servizi digitali e di app. Le risorse in termini di competenze e pratiche di security, però, non hanno avuto un aumento altrettanto esteso e diffuso, con la conseguenza di un debito di sicurezza a crescita esponenziale.
Contemporaneamente, i criminali digitali non si sono fermati a guardare, ma continuano oggi a cercare computer e reti da violare. A questo scopo identificano i difetti nel software per determinare dove colpire. Infatti, sono proprio i bug nei programmi e nel software che creano un’apertura per potenziali aggressori e per i malintenzionati che vogliono causare danni o arricchirsi a spese delle vittime (singoli o organizzazioni).
Anche se le aziende praticano i Vulnerability Assessment (VA) lo fanno solo a valle degli sviluppi automatizzati del codice e questo mina l’efficacia dei test di security necessari a prevenire e contrastare le minacce digitali. In effetti, se l’esecuzione dei VA avviene ancora solo per motivi di compliance o per far contenti i clienti o i sistemi certificativi, non si raggiunge una vera efficacia per prevenire i problemi del codice. L’approccio denominato “shift left” si rende dunque necessario per sfruttare l’automazione dei test di sicurezza il più a monte possibile nel ciclo di sviluppo.
Attuare lo “shift left” sulla postazione del programmatore è solo il primo passo, a cui far seguire la scansione di tutto quello che viene compilato e depositato nei server di sviluppo. Si attua così la metodologia DevSecOps (Development Security Operations): un approccio alla cultura, all’automazione e alla progettazione delle piattaforme che integra la sicurezza come responsabilità condivisa lungo l’intero ciclo di vita IT.
Oltre ai test si dovrebbero formare le persone, insegnando prassi di programmazione sicura e capacità di remediation sul codice rivelatosi vulnerabile. Dunque, la sola prassi dei VA non basta, mentre la DevSecOps si rende necessaria per sviluppare e testare in ottica agile la catena di quality e di security assurance, perché il codice sia contemporaneamente rispondente ai requisiti, performante, robusto e sicuro.
Indice degli argomenti
Vulnerability assessment: l’efficacia nello sviluppo del codice
Il Vulnerability assessment (VA) è una metodologia per determinare la vulnerabilità di un asset mediante test. In ambito digitale la declinazione di VA si applica al codice software dell’infrastruttura IT aziendale, di tutti i sistemi informatici, hardware e software e al codice delle applicazioni web. Ogni codice digitale, infatti, rischia di essere danneggiato, distrutto o manipolato per carpire dati e informazioni digitali.
Il VA, come prassi di security, è usato come mezzo di prevenzione dalle minacce perché se si identifica per tempo la/le vulnerabilità del codice (ovvero prima che un criminale sfrutti la debolezza del codice per lanciare un attacco n.d.r.) è possibile introdurre correttivi (patch del codice n.d.r.) al fine di chiudere la/le criticità. Ogni rapporto di valutazione dei VA normalmente include l’identificazione delle vulnerabilità, il loro conteggio, la priorità/gravità e le raccomandazioni per intervenire.
La maggior criticità dei test di VA non è solo legata al tipo di prodotti di mercato usato o alle modalità di esecuzione distinte fra test statici di sicurezza delle applicazioni (SAST), test dinamici di sicurezza delle applicazioni (DAST), (esistono anche il test interattivo della sicurezza delle applicazion (IAST) e il codice di protezione a runtime (RASP) n.d.r.) bensì è il fattore tempo che incide (la durata) e soprattutto il momento temporale in cui una organizzazione effettua i test sul codice rispetto alla adozione del codice stesso.
A questo proposito, Edoardo Montrasi, IT & OT Security Consultant per CryptoNet Labs, spiega che, nei casi di sviluppo di codice proprietario, “eseguire i VA nelle fasi di collaudo e preproduzione è ormai tardi, perché l’urgenza di andare in produzione e live con il nuovo codice, male si coniuga con i necessari tempi e piani di remediation del codice. Inoltre, se si rimanda l’applicazione dei test di sicurezza al termine degli sviluppi, è possibile che alcune vulnerabilità non possano essere trovate a causa di aspetti di complementarità del codice che richiedono prassi diverse (ovvero i penetration test per capire come sfruttare una vulneraiblità n.d.r.). In ogni caso, il costo delle prassi di remediation aumenta quando le vulnerabilità sono trovate in fase di deployment, collaudo o preproduzione piuttosto che nelle prime fasi dello sviluppo. Infine, l’eventuale mancanza di piani di remediation del codice sorgente, rende necessario un supporto consulenziale esterno in questa fase del ciclo di vita della programmazione per ricostituire il codice in una forma esente da debolezze, bug e difetti, con un conseguente e correlato aumento dei costi”.
A riprova che solo il VA non basta per produrre codice sicuro ed esente da vulnerabilità, si riportano i dati dell’ultimo State of Software Security v12 emesso da Veracode, che per il dodicesimo anno consecutivo ha tracciato un’analisi sulla sicurezza del codice da loro analizzato, scoprendo un numero di app testate per trimestre più che triplicato e un numero di difetti del codice in decrescita ma ancora significativo (fonte: infografica SoSS).
La Security Shift Left nello sviluppo del software
Nonostante i benefici dei test di VA, bisogna usare due accorgimenti per trarre il massimo vantaggio dal loro utilizzo: il primo accorgimento riguarda la completezza del test ed in particolare, oltre a trovare le vulnerabilità, è necessario capire come un attaccante possa sfruttarle. Per questo motivo i VA dovrebbero essere completati dai penetration test (PT) che rappresentano una simulazione reale di attacco informatico, eseguito da un professionista ethical hacker per far emergere come potrebbe verificarsi un accesso indesiderato al sistema e per la misura dell’impatto sul codice e, quindi, sull’infrastruttura IT che lo esegue.
Il secondo accorgimento riguarda l’introduzione delle prassi di VA fin dall’inizio del ciclo di vita del software (Software Development Life Cicle – SDLC). Spostare la sicurezza a sinistra (Security Shift Left) significa introdurre controlli di sicurezza e lavorare durante le prime fasi dello sviluppo del codice. L’obiettivo è garantire che la base di codice sia progettata per essere sicura da subito, anziché verificare la presenza di problemi di sicurezza alla fine del processo. Ciò richiede spesso l’automazione di alcuni aspetti del processo di analisi delle vulnerabilità.
Per prevenire i difetti e le vulnerabilità di una qualsiasi applicazione è necessario introdurre pratiche di “secure code review”, analisi statica del codice, sin dall’inizio del processo di sviluppo, per ogni porzione della totalità del codice e progressivamente completare queste valutazioni anche con test dinamici che possano valutare non solo la funzionalità e velocità e correttezza dei componenti applicativi che sono eseguiti insieme, ma anche il grado di sicurezza complessiva del codice visto come un unicum.
Per completare la Security Shift Left, tutti i problemi di sicurezza evidenziati nelle diverse fasi dovrebbero essere resi visibili a tutti i membri del team durante tutte le fasi dell’SDLC, con sistemi di monitoraggio e avvisi continui per tutte le applicazioni. Favorendo, in questo modo, il riconoscimento delle porzioni di codice da parte dei rispettivi sviluppatori, sia per la correzione del codice singolo, sia per la verifica delle interazioni fra componenti e per il mantenimento della stabilità e non regressione del codice.
Questa visibilità end-to-end è l’incarnazione della sicurezza “Shift Left” e garantisce che i problemi siano corretti prima che il codice sia distribuito.
Paolo Restagno, VP, EU Region per Veracode, sottolinea in aggiunta, che: “un ulteriore livello di attenzione dovrebbe essere riservato alle librerie open source spesso adottate e incluse nel codice sorgente senza effettuare appropriati test di VA statici e/o dinamici con conseguenze rovinose, come nel caso della vulnerabillità Log4j che nell’ultimo mese ha destabilizzato e impattato buona parte delle applicazioni del Web”.
Ripensare il ciclo di sviluppo del software con la DevSecOps
Un ulteriore passo nella direzione della sicurezza del codice è la sistematizzazione e integrazione di tutte le prassi di security durante tutto il ciclo di vita del codice sorgente: ovvero, oltre alla Security Shift Left, è necessario introdurre formazione mirata per gli sviluppatori sulle prassi di security e richiedere l’adozione di queste prassi nel codice. Alcuni esempi di linee guida per il codice sicuro sono:
- la PA-DSS, standard di sicurezza che si applica allo sviluppo di software applicativi di pagamento;
- le linee guida DISA STIG (Security Technical Implementation Guides- STIGs) in ambito militare o lo standard CERT;
- le indicazioni della Open Web Application Security Project® (OWASP) come anche la OWASP SAMM (un Framework che consente di impostare un «programma» di sicurezza applicativa, lavorando con diverse funzioni di business e in diverse fasi del SDLC).
In aggiunta alle tecniche di scrittura di codice sicuro, l’uso di piattaforme di supporto alla sicurezza del codice mediante gestione delle vulnerabilità come un processo continuo di controllo e di monitoraggio e avvisi efficaci, permette di realizzare un’efficace condivisione fra i dipartimenti di ingegneria e IT di tutti i processi, le metriche, i registri e le dashboard per tenersi informati su ciò che sta accadendo in tutti gli ambienti: sviluppo, test e produzione. Il mix di buone prassi di programmazione, formazione, test, monitoraggio e avvisi continui, con review e remediation dei problemi di sicurezza è alla base di una impostazione di DevSecOps. Termine che significa “sviluppo, sicurezza e operazioni, è un approccio alla cultura, all’automazione e alla progettazione delle piattaforme che integra la sicurezza come responsabilità condivisa lungo l’intero ciclo di vita IT” (Fonte: RedHat).
Un ambiente di sviluppo sicuro può essere adottato mediante plug in che estendono delle funzionalità dello sviluppo nell’ottica di fortificare il codice, evitando le falle. Questo tipo di supporti alla programmazione sicura può includere buone prassi per ambienti specifici come il Web o il Mobile, per citare due esempi, ma anche includere la API security e favorire la Software composition Analysis che si occupa di analizzare anche le librerie open source incluse nel codice realizzando la sicurezza della supply chain security a livello di codice.
Le piattaforme di supporto alla security infine permettono verifica e misura sia delle pratiche di awareness ed education e nel tempo evidenziano il miglioramento raggiunto nella riduzione di vulnerabilità del codice prodotto dimostrando che il confronto sano e guidato fra i team di sviluppo li porta a sviluppare competenze sempre più orientate alla sicurezza del codice sorgente. Stefano Taino, CEO & Founder di CryptoNet Labs Srl, sottolinea infine che “la DevSecOps non solo è necessaria negli ambienti di sviluppo on premise, ma con l’adozione del Cloud, che rappresenta un importante acceleratore di business, queste prassi sono ancora più importanti, tanto che le piattaforme di supporto allo sviluppo di codice sicuro possono includere strati di analisi sui container e sull’Infrastructure-as-Code (IaaC), ai fini della configurazione e segregazione delle componenti per evitare e inibire le fasi di movimento laterali negli attaacchi su Cloud”
Contributo editoriale sviluppato in collaborazione con Veracode Cryptonet
