🥇Monitoraggio della sicurezza nei cloud

Il trasferimento di dati e applicazioni verso le nuvole rappresenta una nuova sfida per i SOC aziendali, che non sempre sono pronti a monitorare le infrastrutture altrui. Secondo Netoskope, un'impresa media (probabilmente negli Stati Uniti) utilizza 1246 diversi servizi cloud, il che è del 22% in più rispetto all'anno scorso. 1246 servizi cloud!!! 175 di essi riguardano i servizi HR, 170 sono legati al marketing, 110 nel settore delle comunicazioni e 76 nella finanza e CRM. In Cisco si utilizzano “solo” 700 servizi cloud esterni. Pertanto, questi numeri mi confondono un po'. Ma in ogni caso, il problema non risiede in loro, ma nel fatto che le nuvole iniziano ad essere utilizzate sempre più attivamente da un numero crescente di aziende, che desidererebbero avere le stesse capacità di monitoraggio dell'infrastruttura cloud, come nella propria rete. E questa tendenza è in aumento - secondo i dati della Corte dei conti americana nel 2023 negli Stati Uniti si prevede di chiudere 1200 data center (6250 sono già stati chiusi). Ma il passaggio al cloud non è semplicemente “oh, trasferiamo i nostri server a un fornitore esterno”. Una nuova architettura IT, nuovo software, nuovi processi, nuove restrizioni... Tutto ciò apporta cambiamenti significativi nel funzionamento non solo dell'IT, ma anche della sicurezza informatica. E se i fornitori hanno imparato a gestire in qualche modo la sicurezza del cloud (per fortuna ci sono molte raccomandazioni disponibili), il monitoraggio della sicurezza informatica, specialmente sulle piattaforme SaaS, presenta notevoli difficoltà, di cui parleremo.

Supponiamo che la vostra azienda abbia trasferito parte della sua infrastruttura nel cloud... Stop. Non così. Se l'infrastruttura è stata trasferita e ora vi state solo chiedendo come monitorarla, allora avete già perso. Se non si tratta di Amazon, Google o Microsoft (e anche in questo caso con riserve), probabilmente non avrete molte opzioni per monitorare i vostri dati e le vostre applicazioni. È positivo se vi danno la possibilità di lavorare con i log. A volte i dati sugli eventi di sicurezza sono disponibili, ma non avrete accesso a essi. Ad esempio, Office 365. Se avete la licenza più economica E1, allora gli eventi di sicurezza non sono affatto disponibili. Con la licenza E3, i dati sono conservati solo per 90 giorni e solo con E5 la durata dei log è disponibile per un anno (anche se qui ci sono delle sfide legate alla necessità di richiedere separatamente alcune funzionalità sui log al supporto Microsoft). A proposito, la licenza E3 ha molte meno funzionalità di monitoraggio rispetto a un Exchange aziendale. Per ottenere lo stesso livello, avrete bisogno della licenza E5 o di una licenza aggiuntiva Advanced Compliance, che potrebbero richiedere ulteriori fondi non previsti nel vostro modello finanziario di transizione verso l'infrastruttura cloud. E questo è solo un esempio dei problemi di sottovalutazione legati al monitoraggio della sicurezza nel cloud. In questo articolo, senza pretendere di essere esaustivo, voglio evidenziare alcune peculiarità da considerare nella scelta di un fornitore cloud in termini di sicurezza. Alla fine dell'articolo verrà fornita una checklist da seguire prima di considerare il problema del monitoraggio della sicurezza cloud risolto.

Si possono identificare diversi problemi tipici che possono portare a incidenti negli ambienti cloud, a cui i servizi di sicurezza non riescono a reagire o che non vedono affatto:

I log di sicurezza non esistono. Questa è una situazione abbastanza comune, soprattutto tra i nuovi attori nel mercato delle soluzioni cloud. Ma non bisogna subito abbandonare l'idea. I piccoli operatori, soprattutto quelli nazionali, sono più sensibili alle esigenze dei clienti e possono implementare rapidamente alcune funzionalità richieste, modificando la roadmap dei loro prodotti. Sì, non sarà un'analoga di GuardDuty di Amazon o del modulo "Protezione Proattiva" di Bitrix, ma è comunque qualcosa.
La sicurezza informatica non sa dove siano memorizzati i log o se ci sia accesso ad essi. Qui è necessario avviare negoziati con il fornitore di servizi cloud: potrebbe fornire tali informazioni se lo considera un cliente significativo. In generale, però, non è molto positivo quando l'accesso ai log viene fornito "solo dietro decisione speciale."
Capita anche che il fornitore cloud disponga di log, ma essi forniscano un monitoraggio e una registrazione degli eventi limitati, insufficienti per rilevare tutti gli incidenti. Ad esempio, potrebbero fornirvi solo i log delle modifiche sul sito o i log dei tentativi di autenticazione degli utenti, mentre altri eventi, come quelli sul traffico di rete, potrebbero non essere forniti, nascondendovi così una serie di eventi che caratterizzano i tentativi di attacco alla vostra infrastruttura cloud.
I log esistono, ma l'accesso ad essi è difficile da automatizzare, il che costringe a monitorarli non continuamente, ma secondo un programma. E se non è possibile caricare i log in modo automatico, l'esportazione dei log, ad esempio, in formato Excel (come avviene con alcuni fornitori nazionali di soluzioni cloud), potrebbe portare all'assenza di interesse da parte dei servizi IT aziendali per gestirli.
Nessun monitoraggio dei log. Questa è, probabilmente, la ragione più incomprensibile per la nascita di incidenti di sicurezza informatica negli ambienti cloud. Sembrano esserci log, e l'accesso ad essi si potrebbe automatizzare, ma nessuno lo fa. Perché?

Concetto di sicurezza condivisa del cloud

Il passaggio al cloud è sempre una ricerca di equilibrio tra il desiderio di mantenere il controllo sull'infrastruttura e la delega a mani più professionali di un fornitore di servizi cloud, specializzato nella sua gestione. E anche nel campo della sicurezza degli ambienti cloud, questo equilibrio deve essere cercato. Tanto più che, a seconda del modello di erogazione dei servizi cloud utilizzato (IaaS, PaaS, SaaS), questo equilibrio sarà continuamente diverso. In ogni caso, è importante ricordare che tutti i fornitori di cloud oggi seguono il cosiddetto modello di responsabilità condivisa e di sicurezza informatica condivisa. Il cloud è responsabile per alcune cose, mentre il cliente, che ha posizionato i propri dati, applicazioni, macchine virtuali e altre risorse nel cloud, è responsabile per altre. Sarebbe imprudente aspettarsi che, migrando al cloud, trasferiamo completamente la responsabilità al fornitore. Ma non è nemmeno saggio costruire tutta la sicurezza autonomamente durante il passaggio al cloud. È necessario un equilibrio, che dipenderà da numerosi fattori: — strategie di gestione del rischio, modelli di minaccia, meccanismi di protezione disponibili presso il fornitore di cloud, legislazione, ecc.

Ad esempio, la classificazione dei dati archiviati nel cloud è sempre responsabilità del cliente. Il fornitore del cloud o il fornitore di servizi esterni possono solo aiutare con gli strumenti che aiuteranno a contrassegnare i dati nel cloud, a identificare le violazioni, a rimuovere i dati che violano la normativa o a mascherarli con uno o un altro metodo. D'altra parte, la sicurezza fisica è sempre responsabilità del fornitore del cloud, che non può condividerla con i clienti. Tutto ciò che si trova tra i dati e l'infrastruttura fisica è il tema di discussione di questo articolo. Ad esempio, la disponibilità del cloud è responsabilità del fornitore, mentre le impostazioni delle regole MSE o l'abilitazione della crittografia sono responsabilità del cliente. In questo articolo cercheremo di esaminare quali meccanismi di monitoraggio della sicurezza informatica offrono oggi diversi fornitori di cloud popolari in Russia, quali sono le peculiarità del loro utilizzo e quando è opportuno considerare soluzioni esterne integrate (ad esempio, Cisco E-mail Security) che ampliano le capacità del tuo cloud in materia di cybersecurity. In alcuni casi, soprattutto seguendo una strategia multicloud, non avrai altra scelta se non quella di utilizzare soluzioni esterne per il monitoraggio della sicurezza informatica in più ambienti cloud (ad esempio, Cisco CloudLock o Cisco Stealthwatch Cloud). In altri casi, ti renderai conto che il fornitore di cloud scelto (o imposto) non offre affatto capacità di monitoraggio della sicurezza informatica. Questo è sgradevole, ma è rilevante, poiché consente di valutare adeguatamente il livello di rischio associato al lavoro con questo cloud.

Ciclo di vita del monitoraggio della sicurezza del cloud

Per monitorare la sicurezza dei cloud che utilizzi, hai solo tre opzioni:

fare affidamento sugli strumenti forniti dal tuo fornitore di cloud,
utilizzare soluzioni di terze parti che monitoreranno le piattaforme IaaS, PaaS o SaaS che utilizzi,
costruire la propria infrastruttura di monitoraggio degli ambienti cloud (solo per piattaforme IaaS/PaaS).

Vediamo quali sono le caratteristiche di ciascuna di queste opzioni. Ma prima dobbiamo comprendere lo schema generale che verrà utilizzato per il monitoraggio delle piattaforme cloud. Identificherei 6 componenti principali del processo di monitoraggio della sicurezza nel cloud:

Preparazione dell'infrastruttura. Identificazione delle applicazioni e dell'infrastruttura necessarie per raccogliere eventi rilevanti per la sicurezza in un archivio.
Raccolta. In questa fase, gli eventi di sicurezza vengono aggregati da diverse fonti per essere successivamente trasmessi per l'elaborazione, il deposito e l'analisi.
Elaborazione. In questa fase, i dati vengono trasformati e arricchiti per facilitare le analisi successive.
Archiviazione. Questo componente è responsabile dello stoccaggio a breve e lungo termine dei dati raccolti, trattati e 'grezzi'.
Analisi. In questa fase hai la possibilità di rilevare incidenti e reagire ad essi in modalità automatica o manuale.
Reportistica. Questa fase aiuta a fornire ai soggetti interessati (dirigenza, revisori, fornitore di servizi cloud, clienti, ecc.) indicatori chiave che ci aiutano a prendere decisioni sulla base di ciò, come cambiare fornitore o rafforzare la sicurezza.

Comprendere questi componenti ti permetterà in seguito di determinare rapidamente cosa puoi richiedere al tuo fornitore e cosa dovrai fare tu stesso o con l'aiuto di consulenti esterni.

Funzionalità integrate dei servizi cloud

Ho già scritto sopra che molti servizi cloud oggi non offrono alcuna possibilità di monitoraggio della sicurezza informatica. In generale, dedicano poca attenzione al tema della sicurezza. Per esempio, uno dei popolari servizi russi per l'invio di report agli enti statali tramite Internet (non citerò il nome appositamente). L'intera sezione sulla sicurezza di questo servizio ruota attorno all'uso di sistemi di criptografia certificati. La sezione sulla sicurezza informatica di un altro servizio cloud nazionale per la gestione dei documenti elettronici è ben più ampia. Qui si parla di certificati a chiave pubblica, crittografia certificata, rimozione delle vulnerabilità web, protezione contro gli attacchi DDoS, utilizzo di sistemi di Monitoraggio della Sicurezza Elettronica, backup e persino audit regolari della sicurezza informatica. Ma non c'è parola sul monitoraggio, né sulla possibilità di accedere agli eventi di sicurezza, che possono essere di interesse per i clienti di questo fornitore di servizi.

In generale, da come il fornitore cloud descrive sul proprio sito e nella documentazione le questioni relative alla sicurezza informatica, si può capire quanto seriamente affronti questo argomento. Per esempio, se si leggono le guide sui prodotti "Mio Ufficio", non c'è nemmeno una parola sulla sicurezza, e nella documentazione su un prodotto separato "Mio Ufficio. KS3", destinato a proteggere contro l'accesso non autorizzato, c'è solo un elenco dei punti del 17° ordine del FSTEK che "Mio Ufficio. KS3" adempie, ma non viene descritto come e, cosa più importante, come integrare questi meccanismi con la sicurezza informatica aziendale. È possibile che tale documentazione esista, ma nel pubblico dominio, sul sito di "Mio Ufficio" non l'ho trovata. Forse non ho semplicemente accesso a queste informazioni riservate?...

La situazione per lo stesso Bitrix è di gran lunga migliore. Nella documentazione sono descritti i formati dei log degli eventi e, cosa interessante, il log delle intrusioni, che contiene eventi legati a potenziali minacce per la piattaforma cloud. Da lì puoi estrarre l'IP, il nome utente o dell'ospite, la sorgente dell'evento, l'ora, l'User Agent, il tipo di evento, ecc. In effetti, lavorare con questi eventi è attualmente complicato e dovrai eseguire parte del lavoro manualmente (estraendo il report e caricandolo nel tuo SIEM). Ma se consideriamo che non molto tempo fa nemmeno questa possibilità esisteva, si tratta di un grande progresso. Vorrei anche sottolineare che molti fornitori cloud stranieri offrono funzionalità simili “per principianti”: puoi semplicemente controllare i log manualmente attraverso il pannello di controllo o scaricare i dati (anche se la maggior parte li esporta in formato .csv, e non Excel).

Se non si considera l'opzione dell'assenza di log, i provider cloud di solito offrono tre opzioni per il monitoraggio degli eventi di sicurezza: dashboard, esportazione dei dati e accesso tramite API. La prima sembra risolvere molti problemi per te, ma non è del tutto così: quando ci sono più registri, ci si deve spostare tra gli schermi che li visualizzano, perdendo la visione d'insieme. Inoltre, è difficile che un provider cloud ti offra la possibilità di correlare gli eventi di sicurezza e di analizzarli da un punto di vista di sicurezza (di solito si ha a che fare con dati grezzi che devi elaborare da solo). Ci sono eccezioni e ne parleremo più avanti. Infine, vale la pena chiedersi quali eventi registra il tuo provider cloud, in quale formato e quanto corrispondano al tuo processo di monitoraggio della sicurezza delle informazioni? Ad esempio, identificazione e autenticazione degli utenti e degli ospiti. Lo stesso Bitrix ti consente, sulla base di questi eventi, di registrare la data e l'ora dell'evento, il nome dell'utente o dell'ospite (se è disponibile il modulo "Web Analytics"), l'oggetto a cui si è avuto accesso e altri elementi tipici di un sito web. Ma i servizi di sicurezza delle informazioni aziendali potrebbero aver bisogno di informazioni su se l'utente stava accedendo al cloud da un dispositivo fidato (ad esempio, nella rete aziendale, questa funzione è fornita da Cisco ISE). E che dire di un compito così semplice come la funzione geo-IP, che aiuta a determinare se l'account dell'utente del servizio cloud è stato rubato? E anche se il provider cloud te la fornisce, non è sufficiente. Lo stesso Cisco CloudLock non analizza semplicemente la geolocalizzazione, ma utilizza l'apprendimento automatico e analizza i dati storici per ogni utente, monitorando varie anomalie nei tentativi di identificazione e autenticazione. Una funzionalità simile è presente solo su MS Azure (con un abbonamento appropriato).

C'è un'altra difficoltà: poiché per molti fornitori di servizi cloud il monitoraggio della sicurezza è un argomento nuovo con cui stanno appena iniziando a confrontarsi, cambiano costantemente le loro soluzioni. Oggi hanno una versione API, domani un'altra e dopodomani una terza. Bisogna essere pronti anche a questo. Lo stesso vale per la funzionalità, che può variare e deve essere presa in considerazione nel proprio sistema di monitoraggio della sicurezza. Ad esempio, inizialmente Amazon aveva servizi di monitoraggio degli eventi nel cloud separati: AWS CloudTrail e AWS CloudWatch. Poi è stato introdotto un servizio separato per il monitoraggio degli eventi di sicurezza: AWS GuardDuty. Dopo un po', Amazon ha lanciato un nuovo sistema di gestione, Amazon Security Hub, che include l'analisi dei dati provenienti da GuardDuty, Amazon Inspector, Amazon Macie e altri. Un altro esempio è lo strumento di integrazione dei log di Azure con SIEM: AzLog. Questo è stato utilizzato attivamente da molti fornitori di SIEM fino a quando Microsoft non ha annunciato nel 2018 la cessazione dello sviluppo e del supporto, mettendo molti clienti che utilizzavano questo strumento di fronte a un problema (come è stato risolto ne parleremo più avanti).

Pertanto, segui attentamente tutte le funzionalità di monitoraggio offerte dal tuo fornitore di servizi cloud. Oppure affidati a fornitori esterni di soluzioni, che agiranno come intermediari tra il tuo SOC e il cloud che desideri monitorare. Sì, questo sarà più costoso (anche se non sempre), ma così ti libererai di gran parte della responsabilità. O forse non tutta? Ricordiamo il concetto di sicurezza condivisa e comprendiamo che non potremo delegare completamente: dovremo capire come i diversi fornitori cloud garantiscono il monitoraggio della sicurezza dei tuoi dati, applicazioni, macchine virtuali e altre risorse collocate nel cloud. Iniziamo con ciò che offre Amazon in questo ambito.

Esempio: Monitoraggio della sicurezza in IaaS basato su AWS

Sì, capisco che Amazon non sia il miglior esempio dato che è un servizio americano e potrebbe essere bloccato nella lotta contro l'estremismo e la diffusione di informazioni vietate in Russia. Tuttavia, in questa pubblicazione vorrei semplicemente mostrare quanto diversi siano le varie piattaforme cloud in termini di capacità di monitoraggio della sicurezza informatica e su cosa prestare attenzione quando si trasferiscono i propri processi chiave nel cloud sotto il profilo della sicurezza. E se alcuni degli sviluppatori russi di soluzioni cloud riusciranno a trarre qualche utile insegnamento, sarà fantastico.

Per prima cosa, bisogna dire che Amazon non è una fortezza inespugnabile. I suoi clienti si trovano regolarmente ad affrontare vari incidenti. Ad esempio, a Deep Root Analytics sono stati rubati nomi, indirizzi, date di nascita e numeri di telefono di 198 milioni di elettori. A una società israeliana, Nice Systems, sono state rubate 14 milioni di registrazioni di abbonati Verizon. Allo stesso tempo, le capacità integrate di AWS permettono di rilevare un ampio spettro di incidenti. Ad esempio:

attacco all'infrastruttura (DDoS)
compromissione del nodo (iniezione di comandi)
compromissione dell'account e accesso non autorizzato
configurazioni errate e vulnerabilità
interfacce e API non protette.

Questa disaccordo è dovuto al fatto che la responsabilità della sicurezza dei dati del cliente, come abbiamo chiarito sopra, è del cliente stesso. E se non si è preoccupato di attivare i meccanismi di protezione e non ha attivato gli strumenti di monitoraggio, scoprirà l'incidente solo dai media o dai propri clienti.

Per identificare gli incidenti, è possibile utilizzare un ampio ventaglio di diversi servizi di monitoraggio sviluppati da Amazon (anche se spesso vengono integrati con strumenti esterni, come osquery). In AWS, vengono monitorate tutte le azioni degli utenti, indipendentemente da come vengono eseguite — tramite la console di gestione, la riga di comando, SDK o altri servizi AWS. Tutte le registrazioni delle azioni di ciascun account AWS (incluso il nome utente, l'azione, il servizio, i parametri di attività e il suo risultato) e l'uso delle API sono disponibili tramite il servizio AWS CloudTrail. È possibile visualizzare questi eventi (ad esempio, l'accesso alla console AWS IAM) dalla console CloudTrail, analizzarli tramite Amazon Athena o

Due altri servizi AWS forniscono ulteriori importanti funzionalità di monitoraggio. Innanzitutto, Amazon CloudWatch è un servizio di monitoraggio delle risorse e delle applicazioni AWS, che consente di rilevare, tra le altre cose, diverse anomalie nel proprio cloud. Tutti i servizi integrati di AWS, come Amazon Elastic Compute Cloud (server), Amazon Relational Database Service (database), Amazon Elastic MapReduce (analisi dei dati) e altri 30 servizi di Amazon, utilizzano Amazon CloudWatch per archiviare i propri log. Gli sviluppatori possono utilizzare l'API aperta di Amazon CloudWatch per integrare la funzionalità di monitoraggio dei log nelle proprie applicazioni e servizi, ampliando così il ventaglio di eventi analizzati nel contesto della sicurezza informatica.

In secondo luogo, il servizio VPC Flow Logs consente di analizzare il traffico di rete inviato o ricevuto dai propri server AWS (dall'esterno o dall'interno), nonché tra i microservizi. Quando una delle proprie risorse AWS VPC interagisce con la rete, il servizio VPC Flow Logs registra informazioni sul traffico di rete, inclusi l'interfaccia di rete di origine e destinazione, nonché indirizzi IP, porte, protocolli, numero di byte e numero di pacchetti ricevuti. Coloro che hanno esperienza nella sicurezza delle reti locali riconosceranno questo come analogo ai flussi NetFlow, che possono essere generati da switch, router e firewall di livello aziendale. Questi log sono importanti per il monitoraggio della sicurezza informatica, poiché, a differenza degli eventi relativi alle azioni degli utenti e delle applicazioni, consentono di non trascurare nemmeno le interazioni di rete in un ambiente privato virtuale cloud AWS.

Pertanto, questi tre servizi AWS - AWS CloudTrail, Amazon CloudWatch e VPC Flow Logs - insieme offrono una rappresentazione abbastanza efficace dell'uso del tuo account, del comportamento degli utenti, della gestione dell'infrastruttura, dell'attività delle applicazioni e dei servizi, nonché dell'attività di rete. Ad esempio, possono essere utilizzati per rilevare le seguenti anomalie:

Tentativi di scansione del sito, ricerca di backdoor, ricerca di vulnerabilità tramite picchi di “errori 404”.
Attacchi di injection (ad esempio, SQL injection) tramite picchi di “errori 500”.
Strumenti noti per attacchi come sqlmap, nikto, w3af, nmap, ecc. tramite analisi del campo User Agent.

Amazon Web Services ha sviluppato anche altri servizi per la sicurezza informatica, in grado di affrontare molte altre problematiche. Ad esempio, AWS offre un servizio integrato per l'audit delle politiche e delle configurazioni: AWS Config. Questo servizio garantisce un audit continuo delle risorse AWS e delle loro configurazioni. Prendiamo un semplice esempio: supponiamo che tu voglia assicurarti che le password degli utenti siano disabilitate su tutti i tuoi server e che l'accesso sia consentito solo su base di certificati. AWS Config consente di verificare facilmente questo per tutti i tuoi server. Esistono anche altre politiche che possono essere applicate ai tuoi server cloud: "Nessun server può utilizzare la porta 22", "Solo gli amministratori possono modificare le regole del firewall" o "Solo l'utente Ivashko può creare nuovi account utente e può farlo solo il martedì". Nell'estate del 2016, il servizio AWS Config è stato potenziato per automatizzare la rilevazione delle violazioni delle politiche sviluppate. AWS Config Rules sono, sostanzialmente, richieste di configurazione continue dei servizi Amazon utilizzati, che generano eventi in caso di violazione delle politiche corrispondenti. Ad esempio, invece di eseguire periodicamente richieste AWS Config per verificare che tutti i dischi di un server virtuale siano crittografati, è possibile utilizzare AWS Config Rules per controllare costantemente i dischi server per la conformità a questa condizione. E, cosa più importante, nel contesto di questa pubblicazione, qualsiasi violazione genera eventi che possono essere analizzati dal tuo team di sicurezza informatica.

In AWS ci sono anche i propri equivalenti delle soluzioni aziendali tradizionali per la sicurezza informatica, che generano anch'essi eventi di sicurezza che puoi e devi analizzare:

rilevamento delle intrusioni — AWS GuardDuty
controllo delle fughe di informazioni — AWS Macie
EDR (anche se parlare di dispositivi finali nel cloud è un po' strano) — AWS Cloudwatch + soluzioni open source osquery o GRR
analisi Netflow — AWS Cloudwatch + AWS VPC Flow
analisi DNS — AWS Cloudwatch + AWS Route53
AD — AWS Directory Service
gestione degli account — AWS IAM
SSO — AWS SSO
analisi della sicurezza — AWS Inspector
gestione delle configurazioni — AWS Config
WAF — AWS WAF.

Non descriverò nel dettaglio tutti i servizi di Amazon che possono essere utili nel contesto della sicurezza informatica. La cosa principale da capire è che tutti possono generare eventi che possiamo e dobbiamo analizzare nel contesto della sicurezza informatica, utilizzando sia le funzionalità incorporate di Amazon stesso sia soluzioni esterne, come i SIEM, che possono prelevare eventi di sicurezza nel vostro centro di monitoraggio e analizzarli lì insieme ad eventi di altri servizi cloud o della vostra infrastruttura interna, perimetro o dispositivi mobili.

In ogni caso, tutto inizia dalle sorgenti di dati che vi forniscono eventi di sicurezza informatica. Tra queste sorgenti si possono annoverare, tra l'altro:

CloudTrail — utilizzo delle API e azioni degli utenti
Trusted Advisor — controllo della sicurezza secondo le migliori pratiche
Config — inventario e configurazione degli account e delle impostazioni dei servizi
VPC Flow Logs — connessioni con interfacce virtuali
IAM — servizio di identificazione e autenticazione
ELB Access Logs — bilanciatori di carico
Inspector — vulnerabilità nelle applicazioni
S3 — archiviazione dei file
CloudWatch — attività delle applicazioni
SNS — servizio di notifiche.

Amazon, offrendo tale gamma di sorgenti di eventi e strumenti per la loro generazione, è fortemente limitato nelle capacità di analisi dei dati raccolti nel contesto della sicurezza informatica. Dovrete esaminare autonomamente i registri disponibili, cercando in essi gli indicatori di compromissione pertinenti. AWS Security Hub, recentemente lanciato da Amazon, è stato concepito per affrontare questo problema, fungendo da una sorta di SIEM cloud per AWS. Ma per ora è solo all'inizio del suo percorso e risulta limitato sia nel numero di sorgenti con cui interagisce che in altre restrizioni imposte dall'architettura e dagli abbonamenti di Amazon stesso.

Esempio: Monitoraggio della sicurezza informatica in IaaS su base Azure

Non voglio entrare in una lunga polemica su quale dei tre provider cloud (Amazon, Microsoft o Google) sia migliore (soprattutto considerando che ognuno di essi ha le sue specifiche e adatte per risolvere determinate esigenze); concentriamoci sulle possibilità di monitoraggio della sicurezza informatica che questi attori offrono. È giusto riconoscere che Amazon AWS è stato uno dei primi in questo segmento e quindi ha fatto più progressi rispetto agli altri in termini di funzioni di sicurezza informatica (anche se molti ammettono che utilizzarle possa essere complicato). Ma questo non significa che ignoreremo le opportunità offerte da Microsoft e Google.

I prodotti Microsoft si sono sempre contraddistinti per la loro "apertura" e la situazione è simile in Azure. Ad esempio, mentre AWS e GCP partono sempre dal concetto che "tutto ciò che non è permesso è vietato", Azure adotta un approccio completamente opposto. Ad esempio, creando una rete virtuale nel cloud e una macchina virtuale in essa, tutte le porte e i protocolli sono aperti e consentiti per impostazione predefinita. Pertanto, dovrete spendere un po' più di tempo per la configurazione iniziale del sistema di gestione degli accessi nel cloud di Microsoft. Questo impone anche requisiti più rigorosi per il monitoraggio delle attività nel cloud Azure.

AWS presenta una peculiarità: quando monitori le tue risorse virtuali, se sono situate in regioni diverse, potresti avere difficoltà a unire tutti gli eventi e analizzarli in modo unificato. Per risolvere questo problema, dovresti ricorrere a vari espedienti, come la creazione di codice personalizzato per AWS Lambda, che trasferisca eventi tra le regioni. In Azure non c'è questo problema: il suo meccanismo Activity Log tiene traccia di tutte le attività all'interno dell'intera organizzazione senza limitazioni. Lo stesso vale per AWS Security Hub, recentemente sviluppato da Amazon per consolidare molte funzioni di sicurezza in un unico centro, ma solo all'interno della propria regione, il che, a dire il vero, non è rilevante per la Russia. Azure ha il suo Security Center, privo di vincoli regionali, che offre accesso a tutte le funzionalità di sicurezza della piattaforma cloud. Inoltre, per diverse squadre locali, può fornire un proprio insieme di funzionalità di protezione, compresi eventi di sicurezza gestiti da loro. AWS Security Hub sta ancora cercando di assomigliare ad Azure Security Center. Tuttavia, vale la pena menzionare una nota negativa: puoi ottenere molto da Azure di ciò che era stato descritto in AWS, ma questo è più comodo solo per Azure AD, Azure Monitor e Azure Security Center. Tutti gli altri meccanismi di protezione di Azure, inclusa l'analisi degli eventi di sicurezza, vengono attualmente gestiti in modo non molto conveniente. In parte, il problema viene risolto da un'API che attraversa tutti i servizi Microsoft Azure, ma ciò richiede sforzi aggiuntivi per integrare il tuo cloud con il tuo SOC e la disponibilità di specialisti qualificati (proprio come con qualsiasi altro SIEM che lavora con API cloud). Alcuni SIEM, di cui si parlerà più avanti, già supportano Azure e possono automatizzare il compito di monitoraggio, ma anche con essi ci sono delle complessità: non tutti possono raccogliere tutti i log disponibili in Azure.

La raccolta e il monitoraggio degli eventi in Azure è fornita dal servizio Azure Monitor, che è lo strumento principale per la raccolta, la conservazione e l'analisi dei dati nel cloud di Microsoft e nelle sue risorse — repository Git, contenitori, macchine virtuali, applicazioni, ecc. Tutti i dati raccolti da Azure Monitor sono divisi in due categorie: metriche, raccolte in tempo reale che descrivono i principali indicatori delle prestazioni del cloud Azure, e log, che contengono dati organizzati in record, caratterizzanti determinati aspetti delle attività delle risorse e dei servizi Azure. Inoltre, tramite il Data Collector API, il servizio Azure Monitor può raccogliere dati da qualsiasi sorgente REST per costruire scenari di monitoraggio personalizzati.

Ecco alcune sorgenti di eventi di sicurezza che Azure offre e a cui puoi accedere tramite Azure Portal, CLI, PowerShell o REST API (alcune solo tramite Azure Monitor / Insight API):

Activity Logs — questo log risponde alle classiche domande 'chi', 'cosa' e 'quando' riguardo a qualsiasi operazione di scrittura (PUT, POST, DELETE) su risorse cloud. Gli eventi relativi all'accesso in lettura (GET) non vengono registrati in questo log, così come altri.
Diagnostic Logs — contiene dati sulle operazioni riguardanti una determinata risorsa inclusa nella tua sottoscrizione.
Azure AD reporting — contiene sia l'attività degli utenti che l'attività di sistema relativa alla gestione dei gruppi e degli utenti.
Windows Event Log e Linux Syslog — contiene eventi provenienti dalle macchine virtuali ospitate nel cloud.
Metrics — contiene telemetria sulle prestazioni e sul 'benessere' dei tuoi servizi e risorse cloud. Viene misurata ogni minuto e conservata per 30 giorni.
Network Security Group Flow Logs — contiene dati relativi agli eventi di sicurezza della rete, raccolti attraverso il servizio Network Watcher e il monitoraggio delle risorse a livello di rete.
Storage Logs — contiene eventi relativi all'accesso agli archivi.

Per il monitoraggio puoi utilizzare SIEM esterni o il monitoraggio integrato di Azure e le sue estensioni. Parleremo dei sistemi di gestione degli eventi di sicurezza informatica in seguito, nel frattempo vediamo cosa ci offre Azure per l'analisi dei dati nel contesto della sicurezza. La schermata principale per tutto ciò che riguarda la sicurezza in Azure Monitor è il Log Analytics Security and Audit Dashboard (la versione gratuita supporta il salvataggio di un numero limitato di eventi per una sola settimana). Questo pannello è suddiviso in 5 aree principali che visualizzano statistiche riepilogative su ciò che sta accadendo nell'ambiente cloud che stai utilizzando:

Sicurezza dei domini — indicatori chiave quantitativi relativi alla sicurezza informatica — numero di incidenti, numero di nodi compromessi, nodi non aggiornati, eventi di sicurezza di rete, ecc.
Problemi notevoli — visualizza il numero e l'importanza dei problemi attivi con la sicurezza informatica
Rilevamenti — mostra i modelli di attacchi utilizzati contro di te
Intelligence sulle minacce — visualizza informazioni geografiche sui nodi esterni che ti attaccano
Query di sicurezza comuni — richieste tipiche che ti aiuteranno a monitorare meglio la tua sicurezza informatica.

Tra le estensioni di Azure Monitor troviamo Azure Key Vault (protezione delle chiavi crittografiche nel cloud), Malware Assessment (analisi della protezione contro il malware sulle macchine virtuali), Azure Application Gateway Analytics (analisi, tra l'altro, dei log del firewall cloud) e così via. Questi strumenti, arricchiti da specifiche regole di gestione degli eventi, consentono di visualizzare vari aspetti delle attività dei servizi cloud, inclusa la sicurezza, e di identificare eventuali anomalie nel funzionamento. Ma, come spesso accade, qualsiasi funzionalità aggiuntiva richiede un abbonamento a pagamento, il che comporterà investimenti finanziari che dovrai pianificare in anticipo.

Azure offre una serie di funzionalità integrate per il monitoraggio delle minacce, integrate in Azure AD, Azure Monitor e Azure Security Center. Tra queste, ad esempio, la rilevazione delle interazioni delle macchine virtuali con indirizzi IP dannosi noti (grazie all'integrazione con i servizi di Threat Intelligence di Microsoft), la rilevazione di malware nell'infrastruttura cloud attraverso segnali di allerta provenienti dalle macchine virtuali ospitate nel cloud, attacchi di tipo 'brute force' contro le macchine virtuali, vulnerabilità nella configurazione del sistema di identità degli utenti, accesso tramite anonymizer o nodi infetti, fuga di credenziali, accesso da posizioni insolite, ecc. Oggi Azure è uno dei pochi fornitori di cloud a offrire funzionalità integrate di Threat Intelligence per arricchire gli eventi di sicurezza raccolti.

Come già detto, le funzionalità di protezione e, di conseguenza, gli eventi di sicurezza che esse generano, non sono accessibili a tutti gli utenti in egual modo, ma richiedono un abbonamento specifico che include le funzionalità necessarie e che genera gli eventi corrispondenti per il monitoraggio della sicurezza. Ad esempio, parte delle funzioni descritte nel paragrafo precedente relative al monitoraggio delle anomalie nelle credenziali è disponibile solo con la licenza premium P2 per il servizio Azure AD. Senza di essa, come nel caso di AWS, dovrai analizzare gli eventi di sicurezza raccolti 'manualmente'. Inoltre, a seconda del tipo di licenza su Azure AD, non tutti gli eventi saranno disponibili per l'analisi.

Nel portale Azure puoi gestire sia le query di ricerca per i log di registrazione che ti interessano, sia configurare cruscotti per visualizzare i principali indicatori di sicurezza. Inoltre, lì puoi anche scegliere le estensioni di Azure Monitor, che ti permettono di espandere le funzionalità dei log di Azure Monitor e ottenere un'analisi più approfondita degli eventi dal punto di vista della sicurezza.

Se hai bisogno non solo della possibilità di lavorare con i log, ma di un centro di sicurezza completo per la tua piattaforma cloud Azure, incluse la gestione delle politiche di sicurezza informatica, allora si può parlare della necessità di utilizzare Azure Security Center, la maggior parte delle funzioni utili delle quali sono a pagamento, ad esempio, la rilevazione delle minacce, il monitoraggio al di fuori di Azure, la valutazione della conformità, ecc. (nella versione gratuita è disponibile solo la valutazione della sicurezza e le raccomandazioni per risolvere i problemi identificati). Consolida tutte le questioni di sicurezza in un unico luogo. In sostanza, si può parlare di un livello di sicurezza informatica più elevato rispetto a quello fornito da Azure Monitor, poiché in questo caso i dati raccolti da tutta la tua fabbrica cloud vengono arricchiti attraverso molteplici fonti, come Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX, outlook.com, MSN.com, Microsoft Digital Crimes Unit (DCU) e Microsoft Security Response Center (MSRC), ai quali si sovrappongono vari sofisticati algoritmi di apprendimento automatico e analisi comportamentale, il che dovrebbe alla fine migliorare l'efficacia nella rilevazione delle minacce e nella risposta ad esse.

Azure ha anche il suo SIEM — è stato lanciato all'inizio del 2019. Si tratta di Azure Sentinel, che si basa sui dati di Azure Monitor e può anche integrarsi con soluzioni di sicurezza esterne (ad esempio, NGFW o WAF), il cui elenco è in continua espansione. Inoltre, grazie all'integrazione con Microsoft Graph Security API, hai la possibilità di collegare a Sentinel i tuoi feed di Threat Intelligence, il che arricchisce le capacità di analisi degli incidenti nel tuo cloud Azure. Si può affermare che Azure Sentinel è il primo SIEM "nativo" che è stato introdotto dai fornitori di cloud (anche se Splunk o ELK, che possono essere implementati nel cloud, ad esempio, AWS, non sono stati sviluppati da fornitori di servizi cloud tradizionali). Azure Sentinel e Security Center potrebbero essere definiti come un SOC per il cloud Azure e potrebbero essere sufficienti (con alcune riserve) se non possiedi alcuna infrastruttura e hai trasferito tutte le tue risorse di calcolo nel cloud, e questo sarebbe il cloud Microsoft Azure.

Tuttavia, poiché le funzionalità integrate di Azure (anche con un abbonamento a Sentinel) spesso non sono sufficienti per le esigenze di monitoraggio della sicurezza delle informazioni e per integrare questo processo con altre fonti di eventi di sicurezza (sia nel cloud che interni), sorge la necessità di esportare i dati raccolti verso sistemi esterni, tra cui può rientrare anche un SIEM. Questo può essere fatto sia tramite API che attraverso estensioni speciali, disponibili ufficialmente al momento solo per i seguenti SIEM: Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight ed ELK. Recentemente, c'erano più SIEM, ma dal 1° giugno 2019 Microsoft ha interrotto il supporto per Azure Log Integration Tool (AzLog), che all'inizio dell'esistenza di Azure e in assenza di una corretta standardizzazione del lavoro con i log (Azure Monitor non esisteva nemmeno) consentiva di integrare facilmente SIEM esterni con il cloud Microsoft. Attualmente la situazione è cambiata e Microsoft raccomanda la piattaforma Azure Event Hub come principale strumento di integrazione per gli altri SIEM. Molti hanno già effettuato tale integrazione, ma fate attenzione: potrebbero non acquisire tutti i log di Azure, ma solo alcuni (consultate la documentazione per il vostro SIEM).

Concludendo una breve panoramica su Azure, voglio dare un consiglio generale su questo servizio cloud: prima di affermare qualcosa relativamente alle funzionalità di monitoraggio della sicurezza in Azure, è importante configurarle molto attentamente e testarle, per assicurarsi che funzionino come previsto nella documentazione e come riferito dai consulenti Microsoft (che possono avere visioni diverse sulla funzionalità delle opzioni di Azure). Se le risorse finanziarie lo consentono, da Azure si possono ottenere molte informazioni utili nel campo del monitoraggio della sicurezza. Tuttavia, se le vostre risorse sono limitate, come nel caso di AWS, dovrete fare affidamento solo sulle vostre capacità e sui dati grezzi forniti da Azure Monitor. E ricordate che molte funzionalità di monitoraggio comportano costi, quindi è meglio familiarizzare in anticipo con la politica dei prezzi. Ad esempio, è possibile archiviare gratuitamente i dati per 31 giorni fino a un massimo di 5 GB per cliente — superare queste soglie richiederà ulteriori spese (circa 2+ dollari per ogni GB extra archiviato e 0,1 dollari per l'archiviazione di 1 GB al mese aggiuntivo). Lavorare con la telemetria delle applicazioni e con le metriche potrebbe anche richiedere ulteriori risorse finanziarie, così come la gestione di avvisi e notifiche (è disponibile un certo limite gratuito, che potrebbe non essere sufficiente per le vostre necessità).

Esempio: Monitoraggio della sicurezza in IaaS su Google Cloud Platform

Google Cloud Platform, in confronto a AWS e Azure, appare piuttosto giovane, ma questo ha anche i suoi aspetti positivi. A differenza di AWS, che ha gradualmente ampliato le sue capacità, incluse quelle di sicurezza, affrontando problemi di centralizzazione; GCP, al pari di Azure, è gestita in modo molto più centrale, il che riduce il numero di errori e i tempi di implementazione nelle aziende. Dal punto di vista della sicurezza, GCP si colloca, stranamente, tra AWS e Azure. Ha infatti una registrazione degli eventi centralizzata per tutta l'organizzazione, ma non è completa. Alcune funzionalità sono ancora in fase beta, ma gradualmente questo difetto dovrebbe essere risolto e GCP diventerà una piattaforma più matura dal punto di vista del monitoraggio della sicurezza.

Lo strumento principale per la registrazione degli eventi in GCP è Stackdriver Logging (equivalente ad Azure Monitor), che consente di raccogliere eventi in tutta la tua infrastruttura cloud (incluso AWS). Dal punto di vista della sicurezza, in GCP ogni organizzazione, progetto o cartella ha quattro registri di log:

Attività amministrativa — contiene tutti gli eventi relativi all'accesso amministrativo, come la creazione di una macchina virtuale, la modifica dei diritti di accesso e così via. Questo registro viene sempre aggiornato, indipendentemente dalle tue preferenze, e conserva i suoi dati per 400 giorni.
Accesso ai dati — contiene tutti gli eventi relativi alle operazioni dei dati degli utenti cloud (creazione, modifica, lettura, ecc.). Per impostazione predefinita, questo registro non viene aggiornato, poiché il suo volume cresce molto rapidamente. Per questo motivo, il periodo di conservazione è di soli 30 giorni. Inoltre, non tutte le azioni vengono registrate. Ad esempio, non vengono annotate le attività che riguardano risorse pubblicamente accessibili a tutti gli utenti o che sono disponibili senza accesso a GCP.
Evento di sistema — contiene eventi di sistema non associati agli utenti o azioni di un amministratore che modifica la configurazione delle risorse cloud. Viene sempre aggiornato e conservato per 400 giorni.
Trasparenza degli accessi — è un esempio unico di registro che registra tutte le azioni dei dipendenti di Google (ma non ancora per tutti i servizi GCP) che accedono alla tua infrastruttura nell'ambito delle loro mansioni. Questo registro viene conservato per 400 giorni ed è accessibile solo a determinati clienti di GCP, a condizione che siano soddisfatti alcuni criteri (supporto di livello Gold o Platinum, oppure possedere 4 ruoli di un certo tipo nel supporto aziendale). Una funzione simile è presente anche, ad esempio, in Office 365 — Lockbox.

Esempio di registro: Trasparenza degli accessi

{
 insertId: "abcdefg12345"
 jsonPayload: {
 @type: "type.googleapis.com/google.cloud.audit.TransparencyLog"
 location: {
 principalOfficeCountry: "US"
 principalEmployingEntity: "Google LLC"
 principalPhysicalLocationCountry: "CA"
 }
 product: [
 0: "Cloud Storage"
 ]
 reason: [
 detail: "Numero di caso: bar123"
 type: "SUPPORTO_INIZIATO_DAL_CLIENTE"
 ]
 accesses: [
 0: {
 methodName: "GoogleInternal.Read"
 resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
 }
 ]
 }
 logName: "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.comaccess_transparency"
 operation: {
 id: "12345xyz"
 }
 receiveTimestamp: "2017-12-18T16:06:37.400577736Z"
 resource: {
 labels: {
 project_id: "1234567890"
 }
 type: "project"
 }
 severity: "NOTICE"
 timestamp: "2017-12-18T16:06:24.660001Z"
}

L'accesso ai log specificati può avvenire in vari modi (simile a quanto visto in precedenza con Azure e AWS) — tramite l'interfaccia Log Viewer, l'API, il Google Cloud SDK o la pagina Attività del tuo progetto che ti interessa. Allo stesso modo possono essere esportati in soluzioni esterne per un'analisi aggiuntiva. Quest'ultima avviene mediante l'esportazione dei log in un archivio BigQuery o Cloud Pub/Sub.

Oltre a Stackdriver Logging, la piattaforma GCP offre anche la funzionalità Stackdriver Monitoring, che consente di monitorare metriche chiave (prestazioni, uptime, stato generale, ecc.) dei servizi e delle applicazioni cloud. Dati elaborati in modo specifico e visualizzati possono semplificare l'individuazione di problemi nella tua infrastruttura cloud, anche nel contesto della sicurezza. Tuttavia, va notato che questa funzionalità non sarà molto ricca proprio nel contesto della sicurezza informatica, poiché al momento GCP non ha un equivalente di AWS GuardDuty e non può distinguere tra tutti gli eventi registrati quelli negativi (Google ha sviluppato Event Threat Detection, ma al momento è ancora in beta e parlare della sua utilità è prematuro). Stackdriver Monitoring potrebbe essere utilizzato come sistema di rilevamento delle anomalie, che saranno poi investigate per scoprire le cause della loro insorgenza. Tuttavia, data la carenza di personale qualificato nel campo della sicurezza informatica sul mercato, questo compito al momento appare piuttosto difficile.

È anche opportuno fornire un elenco di alcuni moduli di sicurezza informatica che possono essere applicati all'interno del tuo cloud GCP e che sono simili a quanto offre AWS:

Cloud Security Command Center è l'equivalente di AWS Security Hub e Azure Security Center.
Cloud DLP — rilevamento e modifica automatica (ad esempio, mascheramento) dei dati archiviati nel cloud, secondo oltre 90 politiche di classificazione preimpostate.
Cloud Scanner — scanner di vulnerabilità note (XSS, Flash Injection, librerie non patchate, ecc.) in App Engine, Compute Engine e Google Kubernetes.
Cloud IAM — gestione degli accessi a tutte le risorse GCP.
Cloud Identity — gestione degli account utente, dei dispositivi e delle applicazioni GCP da un'unica console.
Cloud HSM — protezione delle chiavi crittografiche.
Cloud Key Management Service — gestione delle chiavi crittografiche in GCP.
VPC Service Control — creazione di un perimetro protetto intorno alle vostre risorse GCP per proteggerle da perdite.
Titan Security Key — protezione contro il phishing.

Molti di questi moduli generano eventi di sicurezza che possono essere inviati a BigQuery per analisi o esportati in altri sistemi, incluso SIEM. Come già accennato, GCP è una piattaforma in continua evoluzione e Google sta attualmente sviluppando diversi nuovi moduli di sicurezza per la sua piattaforma. Tra questi Event Threat Detection (disponibile in beta), che analizza i log di Stackdriver alla ricerca di tracce di attività non autorizzata (simile a GuardDuty in AWS), o Policy Intelligence (disponibile in alpha), che consentirà di sviluppare politiche di accesso intelligenti alle risorse GCP.

Ho fatto una piccola panoramica delle funzionalità integrate di monitoraggio nelle popolari piattaforme cloud. Ma avete esperti in grado di lavorare con i "log grezzi" del provider IaaS (non tutti sono disposti a comprare funzionalità avanzate di AWS, Azure o Google)? Inoltre, è risaputo il detto "fidati, ma verifica", che nel campo della sicurezza è più vero che mai. Quanto ti fidi delle funzionalità integrate del provider cloud che ti inviano eventi di sicurezza? Quanto si concentrano effettivamente sulla sicurezza?

A volte è utile considerare soluzioni di monitoraggio delle infrastrutture cloud da applicare, che possono integrare la sicurezza intrinseca del cloud. In alcuni casi, tali soluzioni sono l'unica opzione per ottenere dati sulla sicurezza delle informazioni e delle applicazioni ospitate nel cloud. Inoltre, sono semplicemente più comode, poiché si occupano dell'analisi dei log necessari generati dai vari servizi cloud di diversi provider. Un esempio di tale soluzione è Cisco Stealthwatch Cloud, focalizzato su un'unica missione: monitorare le anomalie della sicurezza informatica negli ambienti cloud, che comprendono non solo Amazon AWS, Microsoft Azure e Google Cloud Platform, ma anche cloud privati.

Esempio: Monitoraggio della sicurezza informatica con Stealthwatch Cloud

AWS offre una piattaforma flessibile per il calcolo, ma questa flessibilità rende più facile per le aziende commettere errori che possono portare a problemi di sicurezza. Inoltre, il modello di sicurezza condiviso contribuisce a questo. L'esecuzione nel cloud di software con vulnerabilità sconosciute (per quelle conosciute, ad esempio, AWS Inspector o GCP Cloud Scanner possono intervenire), password deboli, configurazioni errate, insider, ecc., riflette il comportamento delle risorse cloud, che possono essere monitorate da Cisco Stealthwatch Cloud, un sistema di monitoraggio della sicurezza informatica e rilevamento delle minacce in ambienti pubblici e privati.

Una delle caratteristiche chiave di Cisco Stealthwatch Cloud è la possibilità di modellare le entità. Con questo strumento, è possibile creare un modello software (cioè un'imitazione quasi in tempo reale) di ciascuna delle vostre risorse cloud (indipendentemente dal fatto che si tratti di AWS, Azure, GCP o altro). Queste possono includere server e utenti, così come tipi di risorse specifiche per il vostro ambiente cloud, come gruppi di sicurezza e gruppi di scaling automatico dei servizi (auto-scale). Questi modelli utilizzano come input flussi di dati strutturati forniti dai servizi cloud. Ad esempio, per AWS questi saranno VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda e AWS IAM. La modellazione delle entità scopre automaticamente il ruolo e il comportamento di ciascuna delle vostre risorse (è possibile parlare di profilazione di tutta l'attività cloud). Tra questi ruoli ci sono dispositivi Android o Apple, server Citrix PVS, server RDP, gateway di posta elettronica, client VoIP, server terminale, controller di dominio, ecc. Successivamente, monitora continuamente il loro comportamento per determinare quando si verifica un comportamento rischioso o minaccioso per la sicurezza. Puoi identificare attacchi di brute force, DDoS, perdite di dati, accesso remoto non autorizzato, azioni di malware, scansioni di vulnerabilità e altre minacce. Ad esempio, ecco come appare la rilevazione di un tentativo di accesso remoto da un paese insolito per la tua organizzazione (Corea del Sud) a un cluster Kubernetes tramite SSH:

Ecco come appare una presunta perdita di dati da un database Postgress in un paese con cui non si è mai interagito in precedenza:

Infine, ecco come appare un numero eccessivo di tentativi di accesso falliti via SSH dalla Cina e dall'Indonesia da un dispositivo remoto esterno:

Oppure, supponiamo che un'istanza del server in VPC, secondo la politica, non debba mai essere un punto di destinazione per accessi remoti. Supponiamo ulteriormente che su questo computer si sia verificato un accesso remoto a causa di una modifica errata della politica delle regole del firewall. La funzione di modellazione delle entità rileverà e segnalerà tale attività ("Accesso remoto insolito") quasi in tempo reale e indicherà la specifica chiamata API di AWS CloudTrail, Azure Monitor o GCP Stackdriver Logging (incluso il nome utente, data e ora, tra i vari dettagli) che ha provocato la modifica nella regola MSE. E poi queste informazioni possono essere inviate a SIEM per analisi.

Funzionalità simili vengono implementate per qualsiasi ambiente cloud supportato da Cisco Stealthwatch Cloud:

La modellazione delle entità è una forma unica di automazione della sicurezza che può rilevare problemi precedentemente sconosciuti con le persone, i processi o le tecnologie. Ad esempio, consente di scoprire tra le altre cose problemi di sicurezza come:

Qualcuno ha scoperto un backdoor nel software che utilizziamo?
C'è qualche software o dispositivo di terze parti nel nostro cloud?
Un utente autorizzato sta abusando dei propri privilegi?
C'è stata una configurazione errata che consente accessi remoti o utilizzi non autorizzati delle risorse?
C'è qualche fuga di dati dai nostri server?
Qualcuno ha tentato di connettersi a noi da una località geografica atipica?
Il nostro cloud è infettato da malware?

Un evento di sicurezza informatica rilevato può essere inviato come ticket appropriato su Slack, Cisco Spark, nel sistema di gestione degli incidenti PagerDuty, e anche passato a diversi SIEM, tra cui Splunk o ELK. In sintesi, si può dire che se la tua azienda utilizza una strategia multicloud e non si limita a un solo fornitore di servizi cloud, le possibilità di monitoraggio della sicurezza informatica descritte sopra rendono l'uso di Cisco Stealthwatch Cloud una buona opzione per ottenere un set unificato di possibilità di monitoraggio dei principali attori cloud — Amazon, Microsoft e Google. La cosa interessante è che, confrontando i prezzi di Stealthwatch Cloud con le licenze avanzate per il monitoraggio della sicurezza informatica su AWS, Azure o GCP, potrebbe risultare che la soluzione Cisco sia addirittura più economica delle funzionalità integrate delle soluzioni di Amazon, Microsoft e Google. Paradossale, ma è così. E più cloud e le loro funzionalità utilizzi, più evidente sarà il vantaggio di una soluzione consolidata.

Inoltre, Stealthwatch Cloud può monitorare anche cloud privati, implementati all'interno della tua organizzazione, ad esempio, basati su contenitori Kubernetes o tramite il monitoraggio dei flussi Netflow o del traffico di rete ottenuto tramite il mirroring nell'hardware di rete (anche di produzione nazionale), dati AD o server DNS, ecc. Tutti questi dati saranno arricchiti con informazioni di Threat Intelligence raccolte dal team Cisco Talos, il più grande gruppo di ricercatori di minacce informatiche al mondo.

Questo ti consente di implementare un sistema di monitoraggio unificato per cloud pubblici e ibridi che la tua azienda può utilizzare. Le informazioni raccolte possono quindi essere analizzate utilizzando le funzionalità integrate di Stealthwatch Cloud o inviate al tuo SIEM (supportando per default Splunk, ELK, SumoLogic e altri).

Con questo concludiamo la prima parte dell'articolo, in cui ho esaminato gli strumenti integrati ed esterni per il monitoraggio della sicurezza delle piattaforme IaaS/PaaS, che ci permettono di rilevare e rispondere rapidamente agli incidenti che si verificano negli ambienti cloud scelti dalla nostra azienda. Nella seconda parte continueremo il tema e esamineremo le opzioni di monitoraggio delle piattaforme SaaS, prendendo come esempio Salesforce e Dropbox, oltre a cercare di riassumere e raccogliere tutto insieme, creando un'unica sistema di monitoraggio della sicurezza per diversi fornitori di servizi cloud.

Fonte: habr.com