FireEye analizza ed elenca le criticità del cloud pubblico

FireEye analizza ed elenca le criticità del cloud pubblico

Per quello che riguarda la sicurezza minacce e intrusioni sono in agguato anche in un cloud pubblico, malgrado sia più sicuro di un data center tradizionale. Le tendenze del settore mostrano un’enorme migrazione dei carichi di lavoro verso il cloud. Per rispondere a questo incremento di utilizzo, FireEye sta crescendo insieme ai clienti per garantire che le tecnologie emergenti non siano un campo da gioco per gli attaccanti.

Daniele Nicita, Consulting Systems Engineer di FireEye
L’utilizzo di varie tecniche esterne per ottenere le credenziali è, dalle nostre analisi, la modalità di attacco più diffusa subita negli ambienti cloud. Questa modalità di attacco si divide in tre fasi: l’ottenimento delle credenziali come prima, il movimento laterale nel cloud come seconda, per terminare con l’esfiltrazione dei dati.

L’ambiente cloud è esposto principalmente a tre tipologie di attacco: hacking di applicazioni web vulnerabili, sfruttamento di autorizzazioni improprie e utilizzo di strumenti esterni per ottenere credenziali. Ci sono diversi modi in cui gli attaccanti possono acquisire le credenziali cloud, quali ad esempio il phishing, l’utilizzo di Trojan o le pubblicazioni accidentali.

-Il phishing è quella attività in cui delle email vengono utilizzate per indurre gli utenti a fornire le loro password.
-Trojan, keylogger e altre tipologie simili di malware rappresentano ancora oggi una grave minaccia per le aziende. Un nuovo utilizzo dei Trojan è quello di rubare credenziali per console e applicazioni cloud.
-Sviluppatori e amministratori, accidentalmente, possono talvolta pubblicare credenziali su internet e su l’intranet aziendale, dando la possibilità ai malintenzionati di individuarle utilizzando le ricerche intelligenti. Questo è il metodo detto di pubblicazione accidentale.

Daniele Nicita, Consulting Systems Engineer di FireEye
Tutte e tre le fasi di questa attività d’attacco sono difficili da individuare. È fondamentale che questo avvenga in tempi rapidi con il minor danno possibile per i dati aziendali, ed è per questo che noi di FireEye lavoriamo ogni giorno per offrire i migliori prodotti, la migliore intelligence e la nostra esperienza sul campo, sempre attenti ai cambiamenti e alla evoluzione delle minacce presenti.

Una volta che un attaccante è riuscito ad autenticarsi con successo nell’infrastruttura cloud aziendale, deve determinare di quale accesso dispone e mappare l’ambiente. Nel cloud questi due compiti sono incredibilmente facili. Il tutto può essere completato, ad esempio, in Amazon Web Services (AWS) utilizzando alcuni semplici comandi come ad esempio “describe snapshots”. La forza di questo comando è notevole. Tramite esso è possibile richiedere l’elenco di tutti gli snapshot delle macchine virtuali esistenti, il che può essere una modalità di accesso ai dati anche qualora siano state previste protezioni accettabili. Un attaccante che possiede le credenziali per la creazione o il mounting di un determinato snapshot, può utilizzarle anche per setacciare gli snapshot ed estrarne i dati. Utilizzando questo meccanismo l’attaccante può aggirare l’autenticazione basata su password così come la segmentazione di rete.

Una volta che un attaccante ha avuto accesso ai dati, vi sono molte modalità differenti per rubarli. Inizia così la cosiddetta fase di esfiltrazione. In alcuni casi, un attaccante si potrà limitare ad avviare un trasferimento tradizionale di file con destinazione prevista su un sito di archiviazione cloud, un server FTP o qualche altro strumento di archiviazione.

Un attaccante più avanzato, invece, potrà utilizzare cloud nativi per copiare i dati (come la replica bucket-to-bucket). Questo metodo assicura che ogni qual volta vengano aggiornati i dati, questi aggiornamenti siano visibili anche all’attaccante e ai suoi complici.
Il rilevamento dell’esfiltrazione dei dati può essere possibile utilizzando un alert statistico riferito ai byte trasferiti. Per combattere la replica non autorizzata del bucket, devono essere necessariamente monitorate specifiche chiamate API.