Perché il DevSecOps dovrebbe sforzarsi di adottare misure di applicazione efficaci

This post is also available in: Inglese Francese Tedesco Portoghese, Brasile Spagnolo Russo

Parlare con i potenziali clienti è più utile che leggere le ricerche di mercato. I recenti customer engagement (purtroppo ancora virtuali) lo dicono forte e chiaro: le aziende hanno bisogno di una sicurezza efficace.

1. Definire la sicurezza efficace

Non è necessario ripartire ogni volta da zero. Lo sviluppo delle moderne applicazioni, le architetture di delivery e il framework consentono la massima flessibilità ai team R&S. Inoltre, servizi, moduli e funzioni off-the-shelf consentono una semplice integrazione. Tuttavia, c’è un problema che complica tutto: la necessità di garantire la disponibilità dell’applicazione e l’integrità e la riservatezza dei suoi dati.

Acquistare soluzioni di sicurezza è semplice: basta acquistare qualsiasi tecnologia che affronti la minaccia (le minacce). Più complicato è gestirla. Innanzitutto, i vantaggi ripristinano l’equilibrio sulla bilancia della sicurezza e della produttività per i team Dev. Tenendo conto di ciò, le imprese possono disporre di cicli di rilascio e di un time to market delle nuove capacità più rapidi e a un costo ridotto, rendendo il personale Application Development and Delivery (AD&D) più influente sulle decisioni correlate alla sicurezza. La sicurezza efficace deve entrare a far parte del tuo playbook. In altre parole, non rompere niente e non introdurre interruzioni e rallentamenti.

[Ti potrebbe interessare anche: Perché DevSecOps dovrebbe sforzarsi di adottare misure di applicazione efficaci]

2. La sicurezza “efficace” deve rilevare

Ci sono diversi approcci all’integrazione delle tecnologie di protezione delle applicazioni nella pipeline CI/CD. Ciascuno di essi cerca di superare il bisogno di velocità e minimizzare l’impatto sull’ambiente – che si tratti di latenza, impronta delle risorse o costi del carico di lavoro. Nella maggior parte dei casi, negli approcci “dev friendly” c’è almeno una delle due seguenti carenze:

i.           La soluzione non copre l’intera superficie di attacco

ii.           La soluzione non applica attivamente il security enforcement

         i. Oggi le minacce alle applicazioni vanno oltre lo sfruttamento delle vulnerabilità di codice e logiche – che sono già più che sufficienti da analizzare e gestire. Tener traccia delle vulnerabilità note, degli ultimi protocolli di autenticazione e autorizzazione e dei diversi modi per violarli rappresenta già un compito sufficientemente gravoso.

Oggi le applicazioni – specialmente nei moderni ambienti di sviluppo – usano ampiamente le API per condividere e consumare dati sensibili, che sono altrettanto vulnerabili e richiedono una tecnologia chirurgica dedicata per assicurarsi che non ci sia un abuso di token, un attacco massivo o un furto di dati mediante injections.

A parte la questione della sicurezza delle API, molti servizi si appoggiano o si integrano con dei bot, e devono distinguere quelli buoni da quelli con intenti malevoli. Ad esempio, per essere accettati da AD&D, il RASP (Runtime Application Self Protection) è vulnerabile ad alcune forme di DoS (denial of service).

ii. Dal punto di vista DevOps, applicare la security enforcement è rischioso. Può infatti incidere negativamente sulla user experience o persino interrompere il flusso, portando a errori di runtime. Il ciclo di vita di sviluppo software (SDLC) presenta molti punti ciechi nella sicurezza, soprattutto nelle architetture multicloud ibride di oggi. Per questo motivo, molte tecnologie forniscono fortunatamente avvisi.

[Ti potrebbe interessare anche: Perché DevSecOps dovrebbe sforzarsi di adottare misure di applicazione efficaci]

3. La sicurezza “efficace” deve proteggere

Ci sono alcune lacune negli strumenti che forniscono solo visibilità. Test di sicurezza automatici, scanner per la vulnerabilità dei web server, sistemi operativi e perfino le immagini dei containers non sono all’altezza di una protezione efficace, costringendo pertanto lo sviluppatore a rivedere il proprio lavoro e applicare spesso delle patch. Quando questi allarmi arrivano in massa, è molto più difficile assegnare priorità e affrontarli tutti.

Una versione rilasciata è acqua passata per i team di sviluppo fino al momento in cui un membro dello staff sicurezza viene a dirti di applicare una patch a questa vulnerabilità. Se puoi rilevarla, bloccala. Ricorda soltanto di rilevare l’intero spettro di minacce. Nessuno vuole troppe soluzioni puntuali, in quanto questo non comporta necessariamente una security posture più solida.

4. La sicurezza “efficace” deve restare tale

La natura dinamica di un SDLC agile con cambiamenti e aggiornamenti frequenti alla app rende le policy di sicurezza meno accurate. Questo processo non è scalabile e richiede un FTE per lavorare sugli aggiornamenti delle regole, sulla whitelisting e sulla gestione delle eccezioni.

Per maggiori informazioni su Radware’s Dev Friendly Security e Automatic Policy Generation and Optimization Engine.