Definire la sicurezza delle applicazioni a partire da quello che non è

Le previsioni F5 per un 2021 all’insegna del cambiamento e della capacità di adattarsi

A cura di Maurizio Desiderio, Country Manager per l’Italia e Malta di F5 Networks

In uno scenario che vede aumentare esponenzialmente il volume e la frequenza con le quali le nuove app vengono sviluppate e distribuite, definire il concetto stesso di sicurezza applicativa è molto complesso. Per farlo è forse più facile soffersi su quello che la sicurezza delle applicazioni sicuramente non è:

TI PIACE QUESTO ARTICOLO?

Iscriviti alla nostra newsletter per essere sempre aggiornato.

  1. Non una priorità (ma dovrebbe diventarlo!)

In una ricerca sulla sicurezza dei dispositivi IoT e delle applicazioni mobile promossa da Arxan e IBM, il 44% degli intervistati ha dichiarato che in questo momento non sta facendo nulla per prevenire gli attacchi alle applicazioni. Supponiamo che questo dato, per quanto allarmante, sia in realtà così elevato solo perché collegato a un piccolo sottoinsieme del portafoglio applicativo, ed esploriamo il concetto in modo più esteso. L’analisi promossa su base semestrale da WhiteHat Security e relativa alle statistiche sulla sicurezza web rivela che “circa un terzo delle applicazioni in ambito assicurativo, il 40% delle applicazioni legate ai servizi finanziari e bancari, la metà delle applicazioni del settore sanitario e retail, e più della metà delle applicazioni del Manufacturing, Food & Beverage e IT sono sempre vulnerabili”. “Sempre vulnerabili” nella definizione di WhiteHat Security significa “vulnerabile in ogni singolo momento di tutto l’anno”.

La stessa analisi rivela che “il tempo medio per rimediare alla vulnerabilità varia a seconda del settore da circa 100 a 245 giorni”. Per il retail e la sanità è di circa 200 giorni mentre i settori tecnologici e IT ritardano ulteriormente la media impegnando circa 250 giorni per risolvere una vulnerabilità.

Questo approccio un po’ lassista alla sicurezza rende sempre più urgente affrontare il problema, perché se la protezione delle applicazioni non viene inclusa nell’elenco delle priorità sarà sempre maggiore la percentuale delle applicazioni (o delle API che forniscono i dati alle applicazioni) esposta a vulnerabilità.

  1. Non ha a che fare solo con le app

Sussiste un malinteso di fondo, che la sicurezza applicativa riguardi solo l’applicazione. Se un’applicazione fosse un’entità isolata forse sarebbe vero, ma le applicazioni sono distribuite su piattaforme, si basano su script e API di terze parti e si integrano con sistemi responsabili della gestione dei dati. Ciò significa che la sicurezza dell’app è uno stack che richiede un’attenzione costante rispetto a tutte le componenti, non solo all’applicazione stessa. La top ten elaborata dal Open Web Application Security (OWASP) è un buon punto di partenza per la sicurezza delle applicazioni, anche se non devono essere ignorate nemmeno le vulnerabilità delle piattaforme a livello di protocollo (TCP, HTTP e TLS), che sono state una fonte significativa di preoccupazione negli ultimi dieci anni.

Leggi anche:  La Società assicurativa Employers Mutual Limited copre la gestione del rischio grazie a SentinelOne

Infine, non bisogna trascurare il rapporto tra gli attacchi alla rete di tipo volumetrico e gli attacchi più insidiosi del sistema al livello applicativo. Come fa notare Dark Reading in un recente articolo, quasi la metà delle organizzazioni che subiscono un attacco dichiarano che il DDoS ha coinciso con una qualche forma di violazione o attività criminale sulla propria rete, come il furto di dati e l’attività ransomware. Il 47%, ad esempio, riferisce di avere scoperto un virus sulla rete dopo un attacco DDoS, il 43% cita un malware che è stato attivato e il 32% denuncia il furto di dati dei clienti.

La protezione dell’applicazione richiede quindi di porre attenzione all’architettura applicativa complessiva, che include la rete, i dati e i servizi che scalano e proteggono l’applicazione.

  1. Non è “il problema di qualcun altro”

Nella nostra analisi State of Application Delivery abbiamo scoperto che un’organizzazione su cinque dichiara di voler ospitare oltre il 50% delle proprie applicazioni su cloud: tutto questo renderà la protezione delle applicazioni sempre più impegnativa.

Spostare un’applicazione in “cloud” può significare ridistribuire alcune responsabilità di sicurezza, in particolare quelle legate ad alcune compenti a livello di rete e di sistemi, ma l’app e le sue piattaforme e gli script esterni e le risorse su cui essa si basa continuano ad essere responsabilità dell’azienda. Garantire lo stesso livello di sicurezza in cloud può rivelarsi estremamente difficile, in particolare quando si mescolano e si associano servizi cloud nativi che non sono compatibili a livello di policy con quelli on-premise. Si tratta però di una sfida che deve e può essere affrontata, assicurando la coerenza nell’applicazione delle policy ai servizi in cloud e on-premise o spostando la gestione della sicurezza di un’applicazione verso un’offerta service-based che può offrire consistenza su diversi ambienti contemporaneamente, o elaborare policy equivalenti manualmente per i servizi nativi in cloud. Qualunque strada si scelga di seguire la responsabilità rimarrà nelle vostre mani.

Leggi anche:  L’area EMEA è la più colpita a livello globale dagli attacchi alle API che prendono di mira il settore del commercio

L’impatto delle violazioni in termini di reputazione del brand, fiducia dei consumatori e potenziale di sfruttamento futuro (nel caso di credenziali rubate) rende la sicurezza delle applicazioni più importante che mai. Metterla all’ultimo posto supponendo che qualcun altro se ne prenderà cura è la ricetta perfetta per un disastro! Riconoscere la sua importanza e attribuirle la priorità nelle fasi di testing e remediation, sfruttando le opzioni offerte delle architetture cloud e i servizi supportati dal cloud stesso, significa imboccare il cammino corretto verso la riduzione del rischio. Perché la sicurezza delle app non può mai essere un optional!