L’Application Security nell’era dei microservizi

Via via che le società scompongono le loro applicazioni in microservizi, sfruttando i container come architettura ideale a tal fine, anche la responsabilità di rendere sicuri questi ambienti si sposta, esponendo le società a una più ampia gamma di rischi alla sicurezza e lacune nella protezione. 

In effetti, ci troviamo culturalmente a un punto di inflessione tra il ruolo dei DevOps e del CISO. Mentre i CISO hanno la responsabilità di tenere al sicuro la loro società a tutti i costi, per i team DevOp la prontezza rappresenta l’elemento critico nelle operazioni aziendali e, pertanto, tendono ad avere un approccio alla sicurezza del tipo “va bene così” (e a volte del tipo “no, accidenti!”). 

Cosa comporta questo per le aziende e la cybersecurity?

Abbiamo focalizzato la nostra ricerca sul mercato 2019 sulla comunità DevOps e DevSecOps per verificare cosa sono diventati i DevOps comuni e quanto sia grande la loro influenza sui processi decisionali in materia di sicurezza informatica. A tal fine, abbiamo intervistato quasi 300 professionisti di aziende di ogni dimensione da tutto il mondo.  Riportiamo qui di seguito un quadro riassuntivo di quanto rilevato. 

Le aziende abbracciano le tecnologie e i concept emergenti

Le aziende sembrano assolutamente consapevoli che, come parte della loro trasformazione digitale, l’introduzione di nuovi framework richiede una mente (e un portafoglio) aperti quando si tratta di nuove soluzioni. E stanno testando e/o acquistando misure di sicurezza aggiuntive.

[Ti potrebbe interessare anche: 4 Emerging Challenges in Securing Modern Applications]]

Per esempio, il 67% delle aziende intervistate eseguire microservizi/container, il 53% delle quali già utilizza un qualche tipo di tecnologia di sicurezza dei container. Il 43% utilizza una soluzione dedicata per garantire funzioni serverless durante il runtime, così da non avere interruzioni e fughe di dati. 

Per quanto questo possa apparire promettente, sembra che le società stiano adottando un approccio del tipo “lancia gli spaghetti sul muro”, accumulando diverse tecnologie ma non necessariamente ottimizzandone l’interoperabilità.  Esse sperano piuttosto che sia sufficiente mettere in campo diverse soluzioni. 

Dal momento che microservizi e container management sono considerati ancora tecnologie emergenti, è fondamentale che le aziende siano ancora in una fase di apprendimento su come abbinare le soluzioni e le pratiche giuste alle nuove infrastrutture e flussi dati.  Prevale tuttavia una falsa fiducia nei modelli di sicurezza esistenti – lasciando lacune di sicurezza impreviste che si traducono in violazioni di dati.

Le aziende seguono le prassi di sicurezza richieste

Non soltanto le aziende sono pronte ad abbracciare le tecnologie di sicurezza emergenti, ma seguono anche ampiamente il libro sacro delle prassi di information security. Esempi: 

• il 70% dispone di controlli di sicurezza sul traffico est-ovest. 
• Più della metà effettua la code review in aggiunta al security testing e alle soluzioni WAF che utilizzano.
• Il 52% ritiene che il criterio principale per la scelta della tecnologia di application security sia la qualità della sicurezza.

Quest’idea è dimostrata perfettamente dalle prassi di sicurezza API. Il grafico seguente mostra che le aziende sono consapevoli dei rischi alla sicurezza attraverso le API e si muovono attivamente per affrontarli; una mossa intelligente, in quanto le API sono oggi il collante tra tool, app, sistemi e ambienti.  

[Ti potrebbe interessare anche: How to Prevent Real-Time API Abuse]]

Seguire le prassi di sicurezza basilari e adottare funzioni come il DevSecOps (più del 90% delle aziende dispone già di team DevOps o DevSecOps e il 58% ha un rapporto compreso tra 1:6 e 1:10 tra personale DevSecOps e personale addetto allo sviluppo) in combinazione con l’accumulo di tecnologie di application security aiuta a sviluppare un grande senso di fiducia. 

Le applicazioni vengono ancora hackerate

Ciononostante, gli hacker hanno ancora la meglio, in quanto gli attacchi alle applicazioni restano una minaccia costante. L’88% delle aziende contattate ha riportato attacchi nel corso dell’anno e il 90% ha subito violazioni di dati. Gli attacchi subiti quotidianamente dagli intervistati comprendono violazioni d’accesso, session/cookie poisoning, SQL injection, denial of service, protocol attack, cross-site scripting, cross site request forgery e API manipulation. 

[Ti potrebbe interessare anche: Threats on APIs and Mobile Applications]]

Il 56% ha riportato un fraintendimento dei confini della responsabilità sulla sicurezza tra l’azienda stessa e il suo public cloud service provider. Molte delle aziende intervistate si ritrovano ancora a combattere settimanalmente contro diversi tipi di attacco alle loro applicazioni. 

I gateway API, in ogni caso, non sembrano sufficienti. Essi vengono usati prevalentemente per l’autenticazione (37%) e l’IP filtering (30%), oltre che per un qualche load-balancing di base (28%), ma ovviamente non possono bloccare tutti i tipi di manipolazione e abuso API.

In generale, le soluzioni basate su regole statiche e una rigida euristica non possono garantire un livello adeguato di application security, dati i costanti cambiamenti nel tempo. Metà degli intervistati dichiara che le loro app cambiano costantemente, anche svariate volte al giorno – e tenerle sotto controllo è un compito impossibile per un essere umano.  Farlo significherebbe rilevare il cambiamento, adattare la policy, convalidarla e applicarla. Nessuno può farlo. È necessaria l’automazione.

La rapidità dei cambiamenti cede qualche potere al nuovo acquirente, che è responsabile dello sviluppo agile e della delivery di applicazioni e microservizi e progetta l’ambiente SLDC e sceglie gli strumenti. Il ruolo emergente di DevOps e DevSecOps sta avendo una maggiore influenza sulle decisioni e le prassi di sicurezza. Se ricordate, era questa l’ipotesi che volevamo verificare. 

[Ti potrebbe interessare anche: Are Your DevOps Your Biggest Security Risks?]

Chi prende le decisioni?

Certamente non lo staff addetto alla sicurezza. L’IT è ancora l’influencer n. 1 per la scelta degli strumenti, la definizione della policy e l’implementazione delle soluzioni di application security (l’IT controlla il budget ma è allarmante che il 70% dei CISO non abbia l’ultima parola).  

La trasformazione digitale è più che digitale

La conclusione della nostra ricerca è che gli attacchi hanno ancora successo perché le aziende non considerano pienamente l’impatto della trasformazione digitale sulla loro attività.  

Nella trasformazione digitale, la tecnologia è in testa al cambiamento. E mentre nuove tecnologie e framework vengono acquistati e adottati (ed è questa la parte più semplice!), la tecnologia in sé non può mantenere la promessa. Nonostante la disponibilità delle aziende a seguire prassi di sicurezza adeguate, gli attacchi continuano con successo. Perché?  Perché le aziende non compiono il secondo passo della trasformazione digitale – quello non digitale, ovvero acquisire nuove competenze, adeguare i processi aziendali e ridefinire ruoli e responsabilità.

È qui che fallisce l’application security. Se ai professionisti della sicurezza fosse consentito di fare il loro lavoro e rendere la sicurezza un business enabler, potremmo finalmente vedere la sicurezza procedere alla stessa velocità aziendale.