Ben Todd, Senior Director Security, Emea, Dynatrace, spiega per quale motivo è importante investire sull’automazione per mettere in sicurezza le applicazioni nella nuova era cloud-native.
Nell’ultimo anno, abbiamo assistito a un’impennata della trasformazione digitale che riflette l’accelerazione nel rilascio di tecnologiche pluriennali da parte di molte aziende.
Automazione per applicazioni
Secondo McKinsey abbiamo superato un punto di svolta che potrebbe aver modificato per sempre le operazioni aziendali. L’uso di ambienti multicloud e architetture cloud-native basate su microservizi, container e Kubernetes è al centro di questa trasformazione.
Sebbene questi approcci aiutino indubbiamente i team DevOps a promuovere l’agilità digitale e un time-to-market più rapido, introducono anche nuove sfide alla sicurezza delle applicazioni che rappresentano un serio rischio.
Automazione per applicazioni
Una visione cloud
Le piattaforme cloud rappresentano il livello fondamentale su cui le organizzazioni avviano iniziative di trasformazione digitale basate su DevOps. Questi ambienti favoriscono l’efficienza dei costi e una maggiore flessibilità IT, oltre a permettere alle aziende di orientarsi rapidamente in risposta alle mutevoli esigenze del mercato.
Poiché la domanda di un’innovazione più rapida cresce in ogni settore, le società stanno investendo di più nelle architetture cloud-native.
Gartner prevede che entro il 2022 il 75% delle multinazionali eseguiranno applicazioni containerizzate in produzione, rispetto a meno del 30% nel 2020.
I container e i microservizi suddividono le funzionalità delle applicazioni in parti più gestibili che possono essere rapidamente costruite, testate e distribuite, il che aiuta i team ad accelerare l’innovazione.
Le architetture cloud-native offrono inoltre la flessibilità di spostare i workflow tra piattaforme diverse per garantire che il loro ambiente sia sempre la soluzione migliore per le loro esigenze, in qualsiasi momento. Tuttavia, questa cloud-native era è accompagnata da nuove sfide.
Automazione per applicazioni
I teams DevOps potrebbero non disporre degli strumenti o delle risorse necessarie per gestire il livello aggiuntivo di complessità e identificare le vulnerabilità nel codice prima che vengano esposti.
Questa è una sfida particolare considerato l’uso diffuso di librerie open-source. Queste librerie aiutano ad accelerare il time-to-market eliminando la necessità di scrivere ogni riga di codice da zero. Tuttavia, contengono anche innumerevoli vulnerabilità che devono essere continuamente identificate ed eliminate. Non è facile in un ambiente cloud-native dinamico, in cui il cambiamento è l’unica costante.
Gli strumenti legacy creano punti ciechi
La nostra ricerca ha evidenziato ulteriori preoccupazioni.
Ad esempio, l’89% dei Ciso globali ha ammesso che microservizi, container, Kubernetes e ambienti multicloud hanno creato punti ciechi, poiché i loro attuali prodotti di sicurezza non sono in grado di vederli.
Questi strumenti legacy sono stati progettati per un’era diversa, caratterizzata da un’infrastruttura statica e applicazioni monolitiche. In quegli ambienti, una singola scansione mensile era sufficiente per identificare la maggior parte delle vulnerabilità.
Oggi, la vita dei container viene misurata in ore e giorni. Quei tools semplicemente non possono tenere il passo con l’attuale ritmo di cambiamento.
Inoltre, di solito non possono vedere all’interno delle applicazioni containerizzate e non sono in grado di individuare i difetti all’interno del loro codice. Di conseguenza, anche le vulnerabilità più ben documentate, come il difetto della libreria Apache Struts che ha causato la violazione di Equifax del 2017, possono eludere il rilevamento per mesi o addirittura anni.
Responsabilità e sicurezza
Allo stesso tempo, l’85% degli esperti di sicurezza intervistati desidera che i team DevOps e applicativi si assumano una responsabilità più diretta per la gestione delle vulnerabilità.
Non c’è niente di sbagliato in questo: infatti, molti considerano DevSecOps e lo “shift-left” , come il modo migliore e più conveniente per mitigare il rischio. Tuttavia, gli strumenti e i processi esistenti stanno deludendo questi team.
Automazione per applicazioni
I professionisti non hanno tempo per eseguire scansioni manuali, spesso non hanno le competenze necessarie per assumersi la responsabilità della sicurezza e non hanno la capacità di rilevare le vulnerabilità critiche abbastanza rapidamente. Alcuni DevOps team addirittura ignorano del tutto i controlli di sicurezza, mentre altri si rifiutano di collaborare con i team di sicurezza perché preoccupati che questi passaggi rallentino il time-to-market.
Di conseguenza, più vulnerabilità si stanno insinuando attraverso le reti di sicurezza e negli ambienti di produzione. Uno scioccante 71% dei Ciso di questa ricerca ha affermato di non essere completamente sicuro che il codice sia privo di vulnerabilità prima del suo rilascio in esercizio.
Non adatto allo scopo
Questi risultati sottolineano che i tradizionali approcci alla sicurezza e le valutazioni d’impatto manuali non sono più adatti allo scopo in ambienti cloud-native dinamici.
Le informazioni in tempo reale sono fondamentali quando i container si avviano e si disattivano in pochi secondi e le dipendenze tra i microservizi sono in continuo mutamento mentre attraversano i confini tra le piattaforme cloud.
I Legacy vulnerability scanners offrono solo una vista statica point-in-time e spesso non sono in grado di distinguere tra un rischio potenziale e un’esposizione effettiva. Questo può portare i team di application security e DevOps ad essere sommersi da migliaia di avvisi di vulnerabilità ogni mese, molti dei quali sono falsi positivi.
Più automazione per le applicazioni nell’era cloud-native
Non sorprende che tre quarti (74%) dei Ciso ritenga che tali strumenti di scansione delle vulnerabilità siano inefficaci. Questi strumenti legacy non solo non riescono a tenere il passo con il rapido ritmo del cambiamento negli ambienti containerizzati, ma sono anche colpevoli di rallentare la transizione verso DevSecOps concentrandosi su una sola fase del ciclo di vita del software.
La mancanza di contesto rende difficile per i team reperire e applicare le patch giuste e i team non riescono a trovare le vulnerabilità abbastanza rapidamente da ridurre al minimo il rischio una volta distribuito il codice.
Mettete insieme il volume dei falsi positivi e degli avvisi con la mancanza di contesto offerta dagli strumenti legacy e avrete una ricetta per innumerevoli ore sprecate e un aumento del rischio di sicurezza delle applicazioni.
L’automazione è il futuro
Per superare queste sfide ed eliminare il carico manuale sui propri team, le organizzazioni hanno bisogno della capacità di identificare automaticamente le esposizioni delle applicazioni.
Questo è possibile se hanno la capacità di automatizzare i test durante il runtime. Senza la necessità di configurazione o ulteriori sforzi da parte dei team DevOps.
Combinando i dati sulle vulnerabilità con la conoscenza dell’ambiente di runtime, ad esempio se il codice in questione è esposto a Internet, i team DevSecOps possono ottenere tutto il contesto di cui hanno bisogno per comprendere la causa, la natura e l’impatto del problema in tempo reale.
In tal modo, i team possono ridurre in modo efficiente i rischi e accelerare l’innovazione alla velocità del business.
In effetti, oltre tre quarti (77%) dei Ciso afferma che l’unico modo per la sicurezza di stare al passo con i moderni ambienti cloud-native è sostituire l’implementazione, la configurazione e la gestione manuali con un approccio più automatizzato. Ciò non sarà solo fondamentale per salvaguardare le organizzazioni dalle minacce che devono affrontare nel mondo nativo del cloud di oggi, ma consentirà loro anche di alimentare la crescita guidata dall’innovazione nella nuova era post-pandemia.
