🥇Monitoraggio della sicurezza nel cloud

La migrazione di dati e applicazioni verso il cloud rappresenta una nuova sfida per i SOC aziendali, che non sono sempre pronti a monitorare infrastrutture esterne. Secondo dati di Netskope, un'azienda media (probabilmente negli Stati Uniti) utilizza 1.246 diversi servizi cloud, il 22% in più rispetto all'anno scorso. 1.246 servizi cloud!!! 175 di essi riguardano servizi HR, 170 sono legati al marketing, 110 nel settore delle comunicazioni e 76 nelle finanze e CRM. In Cisco si utilizzano "solo" 700 servizi cloud esterni. Pertanto, questi numeri mi lasciano un po' perplesso. Ma in ogni caso, il problema non sono tanto quelli, quanto piuttosto il fatto che il cloud sta iniziando ad essere adottato attivamente da un numero sempre maggiore di aziende, che desiderano avere le stesse capacità di monitoraggio dell'infrastruttura cloud che hanno nella propria rete. E questa tendenza è in crescita — secondo dati della Corte dei Conti americana Entro il 2023 negli Stati Uniti si prevede la chiusura di 1200 data center (6250 sono già stati chiusi). Tuttavia, passare al cloud non è semplicemente ‘trasferiamo i nostri server a un provider esterno’. Si tratta di una nuova architettura IT, nuovo software, nuovi processi e nuove restrizioni... Tutto questo comporta cambiamenti significativi non solo nel settore IT, ma anche nella sicurezza informatica. E se i provider sono riusciti a gestire in qualche modo la sicurezza del cloud stesso (fortunatamente ci sono molte raccomandazioni), ci sono notevoli complessità per quanto riguarda il monitoraggio della sicurezza nel cloud, specialmente nelle piattaforme SaaS, di cui parleremo.

Supponiamo che la tua azienda abbia trasferito parte della sua infrastruttura nel cloud... Aspetta. Non è così. Se l'infrastruttura è già stata trasferita e stai solo ora pensando a come monitorarla, hai già perso. Se non è Amazon, Google o Microsoft (anche se con delle riserve), probabilmente non avrai molte opzioni per monitorare i tuoi dati e le tue applicazioni. Va bene se ti consentono di lavorare con i log. A volte, i dati sugli eventi di sicurezza saranno disponibili, ma non avrai accesso a essi. Per esempio, in Office 365. Se hai la licenza più economica E1, gli eventi di sicurezza non sono accessibili. Con la licenza E3, i dati vengono conservati solo per 90 giorni e solo con la E5 la durata dei log è disponibile per un anno (anche qui ci sono delle peculiarità legate alla necessità di richiedere separatamente certe funzioni riguardanti i log al supporto Microsoft). A proposito, la licenza E3 è molto più limitata in termini di funzioni di monitoraggio rispetto a un Exchange aziendale. Per ottenere lo stesso livello, hai bisogno della licenza E5 o di un'ulteriore licenza Advanced Compliance, che potrebbero richiedere costi aggiuntivi non considerati nel tuo modello finanziario di transizione all'infrastruttura cloud. E questo è solo un esempio di come vengono sottovalutate le questioni relative al monitoraggio della sicurezza nel cloud. In questo articolo, senza pretendere di essere esaustivo, voglio attirare l'attenzione su alcune sfumature da considerare nella scelta del fornitore di servizi cloud dal punto di vista della sicurezza. Alla fine dell'articolo, sarà fornita una checklist da seguire prima di ritenere che il problema del monitoraggio della sicurezza nel cloud sia risolto.

È possibile identificare diversi problemi tipici che portano a incidenti negli ambienti cloud, ai quali i servizi di sicurezza informatica non riescono a reagire o non riescono nemmeno a vedere:

I log di sicurezza non esistono. Questa è una situazione abbastanza comune, soprattutto tra i nuovi entranti nel mercato delle soluzioni cloud. Ma non dobbiamo scartarli completamente. I piccoli fornitori, soprattutto quelli locali, sono più sensibili ai requisiti dei clienti e possono rapidamente implementare alcune funzionalità richieste, modificando la roadmap approvata per i loro prodotti. Sì, non sarà un equivalente di GuardDuty di Amazon o del modulo “Protezione Proattiva” di Bitrix, ma è pur sempre qualcosa.
La sicurezza informatica non sa dove si trovano i log o non ha accesso a essi. Qui è necessario avviare negoziati con il fornitore di servizi cloud: è possibile che fornisca tale informazione se considera il cliente significativo per sé. Ma in generale, non è molto positivo quando l'accesso ai log è fornito "su decisione speciale".
Può capitare che il fornitore di servizi cloud disponga di log, ma che essi offrano un monitoraggio e una registrazione degli eventi limitati, insufficienti per rilevare tutti gli incidenti. Ad esempio, potrebbero fornirti solo i log delle modifiche sul sito o i log dei tentativi di autenticazione degli utenti, escludendo altri eventi come quelli sul traffico di rete, il che nasconderebbe un'intera gamma di eventi che caratterizzano i tentativi di accesso non autorizzato alla tua infrastruttura cloud.
I log esistono, ma l'accesso a essi è difficile da automatizzare, costringendo a un monitoraggio non continuo ma programmato. E se non è possibile caricare i log in modo automatico, l'esportazione dei log, ad esempio, in formato Excel (come offerta da alcuni fornitori di soluzioni cloud nazionali), potrebbe rendere poco desiderabile gestirli da parte del reparto sicurezza informatica dell'azienda.
Manca il monitoraggio dei log. Questa è, probabilmente, la ragione più oscura per l'emergere di incidenti di sicurezza informatica negli ambienti cloud. Sembra che ci siano log e che l'accesso possa essere automatizzato, ma nessuno lo fa. Perché?

Concetto di sicurezza condivisa nel cloud

Il passaggio al cloud rappresenta sempre una ricerca di equilibrio tra il desiderio di mantenere il controllo sull'infrastruttura e la sua affidamento a mani più professionali di un fornitore di cloud, specializzato nel suo supporto. Anche nel campo della sicurezza degli ambienti cloud, questo equilibrio deve essere ricercato. Inoltre, a seconda del modello di servizi cloud utilizzato (IaaS, PaaS, SaaS), questo equilibrio cambierà continuamente. In ogni caso, è importante ricordare che tutti i fornitori di cloud seguono oggi il cosiddetto modello di responsabilità condivisa e sicurezza condivisa. Alcuni aspetti sono di competenza del cloud, mentre altri spettano al cliente che ha ospitato nel cloud i propri dati, le proprie applicazioni, le proprie macchine virtuali e altre risorse. Sarebbe imprudente pensare che, trasferendosi nel cloud, trasferiremo tutta la responsabilità al fornitore. Tuttavia, non sarebbe saggio neanche costruire tutta la sicurezza da soli nel passaggio verso il cloud. È necessario trovare un equilibrio che dipenda da numerosi fattori: strategie di gestione dei rischi, modelli di minaccia, meccanismi di protezione disponibili presso il fornitore di cloud, legislazione, e così via.

Ad esempio, la classificazione dei dati archiviati nel cloud è sempre responsabilità del cliente. Il fornitore di servizi cloud o un fornitore esterno può solo supportarlo con strumenti che aiutino a contrassegnare i dati nel cloud, rilevare le violazioni, rimuovere i dati che violano la legge o mascherarli utilizzando vari metodi. D'altra parte, la sicurezza fisica è sempre responsabilità del fornitore cloud, che non può condividerla con i clienti. Tuttavia, tutto ciò che si trova tra i dati e l'infrastruttura fisica è esattamente l'oggetto di discussione di questo articolo. Ad esempio, la disponibilità del cloud è responsabilità del fornitore, mentre la configurazione delle regole di MSCE o l'abilitazione della crittografia sono responsabilità del cliente. In questo articolo, tenteremo di esplorare quali meccanismi di monitoraggio della sicurezza informatica offrono oggi diversi fornitori cloud popolari in Russia, quali sono le peculiarità del loro utilizzo e quando è opportuno considerare soluzioni esterne (come Cisco E-mail Security) che ampliano le capacità del vostro cloud in termini di cybersecurity. In alcuni casi, soprattutto seguendo una strategia multi-cloud, non avrete altra scelta che utilizzare soluzioni di monitoraggio della sicurezza informatica in diverse ambienti cloud (come Cisco CloudLock o Cisco Stealthwatch Cloud). In altri casi, scoprirete che il fornitore di cloud scelto (o imposto) non offre alcuna possibilità di monitoraggio della sicurezza informatica. Sebbene ciò possa essere sgradevole, è comunque utile, poiché consente di valutare adeguatamente il livello di rischio associato all'uso di quel cloud.

Ciclo di monitoraggio della sicurezza cloud

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

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

Esaminiamo quali caratteristiche ha 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 informatica nel cloud:

Preparazione dell'infrastruttura. Identificazione delle applicazioni necessarie e dell'infrastruttura per la raccolta di eventi rilevanti per la sicurezza informatica nello storage.
Raccolta. In questa fase, gli eventi di sicurezza vengono aggregati da diverse fonti per essere successivamente inviati per elaborazione, archiviazione e analisi.
Elaborazione. In questa fase, i dati vengono trasformati e arricchiti per facilitare la loro analisi successiva.
Archiviazione. Questo componente si occupa dello stoccaggio a breve e lungo termine dei dati elaborati e 'grezzi' raccolti.
Analisi. In questa fase è possibile rilevare incidenti e reagire ad essi in modo automatico o manuale.
Reportistica. Questo passaggio aiuta a fornire ai soggetti interessati (direzione, auditor, fornitore di cloud, clienti, ecc.) indicatori chiave che ci consentono di prendere decisioni, ad esempio, il cambio di fornitore o un miglioramento della sicurezza informatica.

Comprendere questi componenti ti permetterà di decidere prontamente cosa puoi ottenere dal tuo fornitore e cosa dovrai gestire da solo o con l'assistenza di consulenti esterni.

Funzionalità integrate nei servizi cloud

Come ho già accennato, molti servizi cloud oggi non offrono alcuna possibilità di monitoraggio della sicurezza informatica. In generale, prestano poca attenzione a questo tema. Ad esempio, uno dei servizi russi più popolari per l'invio di report alle autorità statali tramite Internet (non menzionerò il suo nome). Tutta la sezione sulla sicurezza di questo servizio ruota attorno all'uso di sistemi di crittografia certificati. La sezione sulla sicurezza informatica di un altro servizio cloud nazionale per la gestione elettronica dei documenti è significativamente più ampia. Parla di certificati a chiave pubblica, crittografia certificata, eliminazione delle vulnerabilità web, protezione contro gli attacchi DDoS, implementazione di misure di sicurezza elettronica, backup e persino conduzione regolare di audit sulla sicurezza informatica. Ma non si menziona nulla sul monitoraggio, così come sull'accesso agli eventi di sicurezza informatica che potrebbero interessare i clienti di questo fornitore di servizi.

In generale, dall'approccio di un fornitore di cloud rispetto alla sicurezza informatica, come descritto sul proprio sito e nella documentazione, si può capire quanto realmente prenda sul serio questo tema. Ad esempio, se si leggono i manuali sui prodotti "Il mio ufficio", non si trova nemmeno una parola sulla sicurezza. Tuttavia, nella documentazione del prodotto specifico "Il mio ufficio. KS3", progettato per la protezione contro l'accesso non autorizzato, c'è solo un elenco dei requisiti dell'ordine 17 dell'FSTEK. Questa documentazione non spiega come vengano implementati questi requisiti e, soprattutto, come integrare questi meccanismi nella sicurezza informatica aziendale. È possibile che esista una tale documentazione, ma non riesco a trovarla nel pubblico dominio; sul sito "Il mio ufficio" non l'ho vista. Forse non ho accesso a queste informazioni riservate?

La situazione è notevolmente migliore con Bitrix. La documentazione descrive i formati dei registri degli eventi e, cosa interessante, il registro delle intrusioni, che contiene eventi collegati a potenziali minacce per la piattaforma cloud. Da lì è possibile estrarre l'IP, il nome dell'utente o dell'ospite, la fonte dell'evento, l'orario, l'User Agent, il tipo di evento, ecc. Tuttavia, per lavorare con questi eventi, è possibile farlo solo tramite il pannello di controllo del cloud stesso o esportare i dati in formato MS Excel. Automatizzare la gestione dei log di Bitrix è attualmente difficile, e sarà necessario svolgere parte del lavoro manualmente (esportando il rapporto e caricandolo nel proprio SIEM). Ma se si considera che non molto tempo fa non c'era neanche questa possibilità, allora si tratta di un grande progresso. Voglio sottolineare che anche molti fornitori di cloud stranieri offrono funzionalità simili 'per principianti' — o si guardano i log manualmente tramite il pannello di controllo, oppure si esportano i dati (anche se la maggior parte li esporta in formato .csv, piuttosto che Excel).

Se non si considera l'opzione senza log, i fornitori di cloud di solito offrono tre modalità per monitorare gli eventi di sicurezza: dashboard, esportazione dei dati e accesso tramite API. La prima sembra risolvere molti problemi per voi, ma non è così semplice: con più log bisogna passare tra vari schermi, perdendo la visione d'insieme. Inoltre, è improbabile che il fornitore di cloud vi offra la possibilità di correlare gli eventi di sicurezza e analizzarli dal punto di vista della sicurezza (di solito si tratta di dati grezzi che dovete interpretare da soli). Ci sono alcune eccezioni, di cui parleremo più avanti. Infine, è importante sapere quali eventi registra il vostro fornitore di cloud, in quale formato e quanto questi siano allineati al vostro processo di monitoraggio della sicurezza informatica. Ad esempio, l'identificazione e l'autenticazione degli utenti e degli ospiti. Lo stesso Bitrix consente di registrare, per questi eventi, la data e l'ora dell'evento, il nome dell'utente o dell'ospite (se il modulo “Web Analytics” è attivo), l'oggetto a cui è stato effettuato l'accesso e altri elementi tipici di un sito web. Tuttavia, i servizi di sicurezza aziendale potrebbero necessitare di informazioni su se l'utente accede al cloud da un dispositivo di fiducia (ad esempio, nella rete aziendale, questa funzione è garantita da Cisco ISE). E una semplice funzione come il geo-IP, che aiuta a determinare se l'account dell'utente del servizio cloud è stato rubato, è fondamentale. Anche se il fornitore di cloud ve la fornisce, non è sufficiente. Cisco CloudLock non solo analizza la geolocalizzazione, ma utilizza anche machine learning e analizza i dati storici di ciascun utente, monitorando varie anomalie nei tentativi di identificazione e autenticazione. Funzionalità simili sono disponibili solo su MS Azure (con il piano appropriato).

C'è un'ulteriore difficoltà: poiché per molti fornitori di servizi cloud il monitoraggio della sicurezza informatica è una novità su cui stanno appena iniziando a lavorare, continuano a modificare le loro soluzioni. Oggi hanno una versione dell'API, domani un'altra, dopodomani un'altra ancora. Bisogna essere pronti anche a questo. Lo stesso vale per le funzionalità, che possono variare e che devono essere considerate nel proprio sistema di monitoraggio della sicurezza informatica. Ad esempio, Amazon aveva inizialmente servizi separati per il monitoraggio degli eventi nel cloud: AWS CloudTrail e AWS CloudWatch. Poi è stato introdotto un servizio specifico per il monitoraggio degli eventi di sicurezza: AWS GuardDuty. Dopo un certo periodo, Amazon ha lanciato un nuovo sistema di gestione chiamato Amazon Security Hub, che integra 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 i SIEM: AzLog. Questo strumento era ampiamente utilizzato da molti fornitori di SIEM finché nel 2018 Microsoft non ha annunciato la cessazione dello sviluppo e del supporto, lasciando molti clienti che utilizzavano questo strumento di fronte a un problema (come è stata risolta questa situazione, ne parleremo più avanti).

Pertanto, tenete d'occhio tutte le funzionalità di monitoraggio offerte dal vostro fornitore di cloud. Oppure affidatevi a fornitori esterni di soluzioni che fungano da intermediari tra il vostro SOC e il cloud che desiderate monitorare. Sì, sarà più costoso (anche se non sempre), ma in questo modo trasferirete tutta la responsabilità sulle spalle di qualcun altro. Oppure no?.. Ricordiamo il concetto di sicurezza condivisa e comprendiamo che non possiamo trasferire nulla - dovremo capirci da soli su come i diversi fornitori di cloud garantiscono il monitoraggio della sicurezza delle vostre informazioni, applicazioni, macchine virtuali e altre risorse ospitate nel cloud. E iniziamo con ciò che offre Amazon in questo ambito.

Esempio: Monitoraggio della sicurezza in IaaS su AWS

Sì, capisco che Amazon non sia il miglior esempio, considerando che si tratta di un servizio americano e che potrebbe essere bloccato nella lotta contro l'estremismo e la diffusione di informazioni vietate in Russia. Tuttavia, in questa pubblicazione vorrei semplicemente dimostrare quanto differiscano le varie piattaforme cloud in termini di monitoraggio della sicurezza delle informazioni e su cosa prestare attenzione quando si trasferiscono i propri processi chiave nel cloud, dal punto di vista della sicurezza. E se alcuni dei fornitori di soluzioni cloud russi riusciranno a trarne qualcosa di utile, sarebbe fantastico.

Innanzitutto, va detto 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 stati rubati 14 milioni di registrazioni sui clienti di Verizon. Tuttavia, le funzionalità integrate di AWS vi consentono di rilevare un ampio spettro di incidenti. Ad esempio:

impatto sull'infrastruttura (DDoS)
compromissione di un nodo (iniezione di comandi)
compromissione dell'account e accesso non autorizzato
configurazione errata e vulnerabilità
interfacce e API non protetti.

Questa non conformità è legata al fatto che la sicurezza dei dati del cliente, come abbiamo appurato sopra, è responsabilità del cliente stesso. Se non si è preoccupato di attivare meccanismi di protezione e di implementare strumenti di monitoraggio, verrà a conoscenza dell'incidente solo dai media o dai propri clienti.

Per identificare gli incidenti, è possibile utilizzare un ampio spettro di diversi servizi di monitoraggio, sviluppati da Amazon (anche se spesso integrati da strumenti esterni come osquery). In AWS, tutte le azioni degli utenti sono tracciate, indipendentemente da come vengono eseguite — tramite la console di gestione, la riga di comando, SDK o altri servizi AWS. Tutti i registri delle azioni di ogni account AWS (incluso il nome utente, l'azione, il servizio, i parametri di attività e il risultato) e l'uso delle API sono disponibili tramite il servizio AWS CloudTrail. Puoi visualizzare questi eventi (per esempio, l'accesso alla console AWS IAM) dalla console CloudTrail, analizzarli con Amazon Athena o “passarli” a soluzioni esterne, come Splunk, AlienVault, ecc. I log di AWS CloudTrail vengono archiviati nel tuo bucket AWS S3.

Altri due servizi AWS offrono ulteriori funzionalità importanti per il monitoraggio. In primo luogo, Amazon CloudWatch è un servizio di monitoraggio delle risorse e delle applicazioni AWS che consente, tra le altre cose, di identificare varie anomalie nel tuo 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 oltre 30 altri servizi Amazon, utilizzano Amazon CloudWatch per archiviare i propri log. Gli sviluppatori possono utilizzare l'API aperta di Amazon CloudWatch per aggiungere funzionalità di monitoraggio dei log alle applicazioni e ai servizi personalizzati, ampliando così la gamma di eventi analizzati in un contesto di sicurezza informatica.

In secondo luogo, il servizio VPC Flow Logs consente di analizzare il traffico di rete inviato o ricevuto dai tuoi server AWS (verso l'esterno o all'interno), così come tra microservizi. Quando uno qualsiasi delle tue risorse AWS VPC interagisce con la rete, il servizio VPC Flow Logs registra informazioni sul traffico di rete, comprese le interfacce di rete di origine e destinazione, così come indirizzi IP, porte, protocolli, numero di byte e numero di pacchetti che hai visto. Chi ha esperienza con la sicurezza delle reti locali riconoscerà questo come l'equivalente dei flussi NetFlow, che possono essere generati da switch, router e firewall di livello aziendale. Questi log sono importanti per scopi di monitoraggio della sicurezza informatica, poiché a differenza degli eventi sulle azioni degli utenti e delle applicazioni, permettono di non trascurare nemmeno le interazioni di rete in un ambiente cloud privato virtuale AWS.

Quindi, questi tre servizi AWS — AWS CloudTrail, Amazon CloudWatch e VPC Flow Logs — forniscono insieme una rappresentazione molto efficace dell'utilizzo 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 aiutare a rilevare le seguenti anomalie:

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

Amazon Web Services ha sviluppato anche altri servizi per scopi di cybersecurity, che permettono di affrontare molte altre questioni. Ad esempio, in AWS è disponibile un servizio integrato per l'audit delle politiche e delle configurazioni: AWS Config. Questo servizio fornisce un audit continuo delle vostre risorse AWS e delle loro configurazioni. Consideriamo un semplice esempio: supponiamo che vogliate assicurarvi che le password degli utenti siano disabilitate su tutti i vostri server e che l'accesso sia possibile solo mediante certificati. AWS Config consente di controllare facilmente questo per tutti i vostri server. Ci sono altre politiche che possono essere applicate ai vostri 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 i martedì". Nell'estate del 2016, il servizio AWS Config è stato ampliato per automatizzare il rilevamento delle violazioni delle politiche definite. AWS Config Rules sono, essenzialmente, richieste di configurazione continue dei servizi Amazon che utilizzate, 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 del server virtuale siano crittografati, è possibile utilizzare AWS Config Rules per controllare continuamente i dischi dei server per verificare il rispetto di questa condizione. E, cosa più importante, nel contesto di questa pubblicazione, qualsiasi violazione genera eventi che possono essere analizzati dal vostro team di sicurezza informatica.

Amazon Web Services offre anche le proprie equivalenti a soluzioni aziendali tradizionali per la sicurezza informatica, in grado di generare eventi di sicurezza che puoi e devi analizzare:

rilevamento delle intrusioni — AWS GuardDuty
controllo delle perdite di dati — AWS Macie
EDR (anche se riferirsi agli endpoint 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 entrerò nei dettagli su tutti i servizi di Amazon che possono essere utili nel contesto della sicurezza delle informazioni. La cosa principale da capire è che tutti possono generare eventi che possiamo e dobbiamo analizzare nel contesto della sicurezza informatica, sfruttando sia le capacità integrate di Amazon che soluzioni esterne, come i SIEM, che possono prelevare eventi di sicurezza nel tuo centro di monitoraggio e analizzarli insieme agli eventi di altri servizi cloud o dalla tua infrastruttura interna, dal perimetro o dai dispositivi mobili.

In ogni caso, tutto inizia dalle fonti di dati che forniscono eventi di sicurezza informatica. Queste fonti includono, tra l'altro:

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

Amazon, offrendo un vasto spettro di fonti di eventi e strumenti per la loro generazione, è comunque molto limitato nelle sue capacità di analisi dei dati raccolti in contesto di sicurezza informatica. Dovrete esaminare i log disponibili, cercando indicatori di compromissione. AWS Security Hub, recentemente lanciato da Amazon, è stato concepito per affrontare questo problema, fungendo da SIEM cloud per AWS. Tuttavia, è ancora all'inizio del suo percorso e presenta limitazioni sia nel numero di fonti con cui interagisce, sia per altre restrizioni imposte dall'architettura e dalle sottoscrizioni di Amazon stesso.

Esempio: Monitoraggio della sicurezza informatica in IaaS basato su Azure

Non voglio entrare in una lunga polemica su quale dei tre fornitori di cloud (Amazon, Microsoft o Google) sia il migliore (anche perché ognuno di essi ha le proprie specificità e si adatta a risolvere determinate esigenze); concentriamoci sulle possibilità di monitoraggio della sicurezza informatica che offrono questi attori. Va detto che Amazon AWS è stato uno dei primi in questo settore e perciò si è sviluppato ulteriormente nelle sue funzionalità di sicurezza (anche se molti riconoscono che utilizzarle possa essere complicato). Tuttavia, ciò non significa che ignoreremo le opportunità che ci offrono Microsoft e Google.

I prodotti Microsoft sono sempre stati caratterizzati dalla loro "apertura", e la situazione è simile anche in Azure. Ad esempio, mentre AWS e GCP seguono sempre il concetto che "tutto ciò che non è esplicitamente consentito è vietato", Azure adotta un approccio completamente opposto. Creando una rete virtuale nel cloud e una macchina virtuale al suo interno, tutti i porti e i protocolli sono aperti e consentiti per impostazione predefinita. Pertanto, dovrai spendere un po' più di tempo per configurare inizialmente il sistema di controllo degli accessi nel cloud di Microsoft. Questo comporta anche requisiti più rigidi in termini di monitoraggio delle attività nel cloud di Azure.

AWS presenta una peculiaridad: quando monitori le tue risorse virtuali in diverse regioni, riscontri difficoltà nel consolidare tutti gli eventi e analizzarli in modo unitario. Per risolvere ciò, è necessario ricorrere a vari stratagemmi, come la creazione di codice personalizzato per AWS Lambda per trasferire eventi tra le diverse regioni. In Azure, questo problema non sussiste: il suo meccanismo di Activity Log monitora tutta l'attività all'interno dell'intera organizzazione senza restrizioni. Lo stesso vale per AWS Security Hub, recentemente sviluppato da Amazon per consolidare molte funzionalità di sicurezza in un unico centro sicurezza, ma solo all'interno della propria regione, cosa che, per la Russia, non è pertinente. Azure ha il proprio Security Center, privo di restrizioni regionali, che fornisce accesso a tutte le funzionalità di sicurezza della piattaforma cloud. Inoltre, offre un set di funzionalità di protezione adatto a diverse squadre locali, incluse le loro attività di sicurezza gestite. AWS Security Hub si sta ancora impegnando per diventare simile all'Azure Security Center. Tuttavia, è necessario aggiungere una nota negativa: puoi ottenere molto da Azure di ciò che è stato descritto in precedenza per AWS, ma ciò è più semplice per Azure AD, Azure Monitor e Azure Security Center. Tutti gli altri meccanismi di protezione di Azure, incluso l'analisi degli eventi di sicurezza, sono gestiti in modo non molto conveniente al momento. Parte del problema è risolto dall'API che attraversa tutti i servizi Microsoft Azure, ma questo richiederà ulteriori sforzi per integrare il tuo cloud con il tuo SOC e la presenza di professionisti qualificati (come per qualsiasi altro SIEM che lavora con API cloud). Alcuni SIEM, di cui si parlerà in seguito, supportano già Azure e possono automatizzare il monitoraggio, ma anche in questo caso ci sono delle complessità: non tutti possono raccogliere tutti i log disponibili su Azure.

La raccolta e il monitoraggio degli eventi in Azure avviene tramite Azure Monitor, che è lo strumento principale per la raccolta, l'archiviazione e l'analisi dei dati nel cloud Microsoft e nelle sue risorse — come repository Git, contenitori, macchine virtuali, applicazioni, ecc. Tutti i dati raccolti da Azure Monitor si suddividono in due categorie: metriche raccolte in tempo reale che descrivono i principali indicatori di prestazione del cloud Azure e i registri, che contengono dati organizzati in voci che caratterizzano vari aspetti delle attività delle risorse e dei servizi Azure. Inoltre, tramite Data Collector API, il servizio Azure Monitor può raccogliere dati da qualsiasi fonte REST per costruire i propri scenari di monitoraggio.

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

Activity Logs — questo registro risponde alle classiche domande “chi”, “cosa” e “quando” in relazione a qualsiasi operazione di registrazione (PUT, POST, DELETE) sui risorse cloud. Gli eventi legati all'accesso in lettura (GET) non vengono registrati, così come alcuni altri.
Diagnostic Logs — contiene dati relativi alle operazioni su uno o più risorse incluse nel tuo abbonamento.
Azure AD reporting — include sia l'attività degli utenti che l'attività di sistema legata alla gestione di gruppi e utenti.
Windows Event Log e Linux Syslog — contiene eventi dalle macchine virtuali ospitate nel cloud.
Metrics — fornisce dati di telemetria sullo stato delle prestazioni e sulla “salute” dei tuoi servizi e risorse cloud. Viene misurato ogni minuto e conservato per 30 giorni.
Network Security Group Flow Logs — raccoglie dati sugli eventi di sicurezza della rete, raccolti tramite il servizio Network Watcher e il monitoraggio delle risorse a livello di rete.
Storage Logs — contiene eventi legati all'accesso agli archivi.

Per il monitoraggio, puoi utilizzare SIEM esterni o il monitoraggio Azure incorporato e le sue estensioni. Parleremo dei sistemi di gestione degli eventi di sicurezza in seguito, ma per ora vediamo cosa offre Azure per l'analisi dei dati nel contesto della sicurezza. Lo schermo principale per tutto ciò che riguarda la sicurezza in Azure Monitor è il Log Analytics Security and Audit Dashboard (la versione gratuita supporta la conservazione di un numero limitato di eventi per una sola settimana). Questa dashboard è suddivisa in 5 aree principali, che visualizzano statistiche aggregate su ciò che accade nell'ambiente cloud che stai utilizzando:

Sicurezza dei domini — indicatori chiave quantitativi relativi alla sicurezza — 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 di sicurezza
Rilevamenti — visualizza 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.

Le estensioni di Azure Monitor comprendono Azure Key Vault (protezione delle chiavi crittografiche nel cloud), Malware Assessment (analisi della protezione contro il codice dannoso su macchine virtuali), Azure Application Gateway Analytics (analisi, tra l'altro, dei log del firewall cloud) e così via. Questi strumenti, arricchiti con determinate regole di elaborazione degli eventi, consentono di visualizzare vari aspetti dell'attività dei servizi cloud, inclusa la sicurezza, e di identificare eventuali deviazioni dal funzionamento. Ma, come spesso accade, ogni funzionalità aggiuntiva richiede un abbonamento a pagamento, il che comporta investimenti finanziari che è necessario pianificare in anticipo.

Azure offre una serie di funzionalità integrate per il monitoraggio delle minacce, che sono integrate in Azure AD, Azure Monitor e Azure Security Center. Tra queste, ad esempio, la rilevazione delle interazioni delle macchine virtuali con indirizzi IP noti per essere malevoli (grazie all'integrazione con i servizi Threat Intelligence di Microsoft), la rilevazione di malware nell'infrastruttura cloud attraverso segnali di allerta provenienti da macchine virtuali ospitate nel cloud, attacchi di tipo "brute force" su macchine virtuali, vulnerabilità nella configurazione del sistema di identificazione degli utenti, accessi tramite anonimizzatori o nodi compromessi, violazioni di credenziali, accessi da ubicazioni insolite, e così via. Oggi Azure è uno dei pochi fornitori di cloud che offre funzionalità integrate di Threat Intelligence per arricchire gli eventi raccolti sulla sicurezza informatica.

Come già accennato in precedenza, le funzionalità di protezione e, di conseguenza, gli eventi di sicurezza generati, non sono disponibili per tutti gli utenti in modo uniforme, ma richiedono un determinato abbonamento che include le funzionalità necessarie, che generano eventi corrispondenti per il monitoraggio della sicurezza informatica. Ad esempio, alcune delle funzioni descritte nel paragrafo precedente per il monitoraggio delle anomalie degli account sono disponibili solo nella licenza premium P2 per il servizio Azure AD. Senza di essa, così come nel caso di AWS, dovrai analizzare manualmente gli eventi di sicurezza raccolti. Inoltre, a seconda del tipo di licenza per Azure AD, non tutti gli eventi saranno disponibili per l'analisi.

Nel portale Azure puoi gestire sia le query di ricerca per i registri di tuo interesse sia configurare dashboard per visualizzare le metriche chiave di sicurezza. Inoltre, qui puoi selezionare le estensioni di Azure Monitor, che ti consentono di ampliare le funzionalità dei registri 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, inclusa la gestione delle politiche di sicurezza, si può parlare della necessità di utilizzare Azure Security Center. La maggior parte delle sue funzionalità utili è disponibile a pagamento, come la rilevazione delle minacce, il monitoraggio al di fuori di Azure, e 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. Si può sostanzialmente affermare che offre un livello di sicurezza superiore rispetto a quanto fornito da Azure Monitor, poiché in questo caso i dati raccolti su tutta la tua infrastruttura cloud vengono arricchiti con numerose 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), su cui vengono applicati algoritmi complessi di machine learning e analisi comportamentale, il che dovrebbe, alla fine, migliorare l'efficacia nella rilevazione e risposta alle minacce.

Azure ha anche il proprio SIEM, introdotto all'inizio del 2019. Si tratta di Azure Sentinel, che si basa sui dati di Azure Monitor e può integrarsi con soluzioni di sicurezza esterne (come NGFW o WAF), il cui elenco è in continua espansione. Inoltre, grazie all'integrazione con Microsoft Graph Security API, è possibile collegare a Sentinel i propri feed di Threat Intelligence, arricchendo le capacità di analisi degli incidenti nel tuo ambiente Azure. Si può affermare che Azure Sentinel rappresenti il primo SIEM 'nativo' tra i fornitori di servizi cloud (a differenza di Splunk o ELK, che possono essere ospitati nel cloud, ad esempio, AWS, ma non sono stati sviluppati dai fornitori di servizi cloud tradizionali). Azure Sentinel e Security Center potrebbero essere considerati come un SOC per Azure, e potrebbero servirti, a determinate condizioni, se non hai ulteriori infrastrutture e hai trasferito tutte le tue risorse computazionali nel cloud, specificamente nel cloud di Microsoft Azure.

Tuttavia, poiché le capacità integrate di Azure (anche con un abbonamento a Sentinel) spesso non sono sufficienti per il monitoraggio della sicurezza e per integrare questo processo con altre fonti di eventi di sicurezza (sia nel cloud che interne), emerge la necessità di esportare i dati raccolti verso sistemi esterni, tra cui potrebbe rientrare un SIEM. Questo viene fatto sia tramite API che attraverso estensioni specifiche, attualmente ufficialmente disponibili 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 normalizzazione adeguata per la gestione dei log (Azure Monitor non esisteva nemmeno), consentiva di integrare facilmente SIEM esterni con il cloud di Microsoft. Ora la situazione è cambiata e Microsoft consiglia la piattaforma Azure Event Hub come strumento principale di integrazione per gli altri SIEM. Molti hanno già effettuato tale integrazione, ma fate attenzione: potrebbero non catturare tutti i log di Azure, ma solo alcuni (consultate la documentazione per il vostro SIEM).

In conclusione di una breve introduzione ad Azure, vorrei dare un consiglio generale su questo servizio cloud: prima di affermare qualcosa riguardo alle funzionalità di monitoraggio della sicurezza in Azure, è fondamentale configurarle con attenzione e testare che funzionino come indicato nella documentazione e come vi hanno spiegato i consulenti Microsoft (i quali possono avere opinioni diverse sulla funzionalità delle caratteristiche di Azure). Se disponete di risorse finanziarie, da Azure è possibile estrapolare molte informazioni utili per il 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. Ricordate che molte funzioni di monitoraggio comportano costi e sarebbe meglio familiarizzare con la politica dei prezzi in anticipo. Ad esempio, è possibile archiviare gratuitamente i dati per 31 giorni con un limite di 5 GB per cliente — superare questi valori richiederà un investimento aggiuntivo (circa 2+ dollari per ogni GB extra di archiviazione e 0,1 dollaro per GB ogni mese aggiuntivo). Lavorare con la telemetria delle applicazioni e le metriche potrebbe anche richiedere risorse finanziarie extra, così come gestire avvisi e notifiche (è disponibile un limite gratuito, che potrebbe non essere sufficiente per le vostre esigenze).

Esempio: Monitoraggio della sicurezza informatica in IaaS basato su Google Cloud Platform

Google Cloud Platform, rispetto ad AWS e Azure, è relativamente nuova, ma questo può essere un vantaggio. A differenza di AWS, che ha ampliato le proprie capacità, compresa la sicurezza, in modo graduale e ha affrontato problemi di centralizzazione, GCP, come Azure, è gestita in modo più centralizzato, riducendo il numero di errori e il tempo di implementazione nelle aziende. In termini di sicurezza, GCP si colloca, sorprendentemente, tra AWS e Azure. Ha anche una registrazione degli eventi unificata per tutta l'organizzazione, ma è incompleta. Alcune funzionalità sono ancora in fase beta, ma col tempo questo difetto dovrebbe essere risolto e GCP diventerà una piattaforma più matura dal punto di vista del monitoraggio della sicurezza informatica.

Il principale strumento per la registrazione degli eventi in GCP è Stackdriver Logging (simile a Azure Monitor), che consente di raccogliere eventi in tutta la vostra infrastruttura cloud (inclusa AWS). In termini di sicurezza, in GCP ogni organizzazione, progetto o cartella dispone di quattro registri.

Attività Admin — include tutti gli eventi legati all'accesso amministrativo, come la creazione di macchine virtuali, la modifica dei diritti di accesso, e così via. Questo registro viene sempre registrato, indipendentemente dalla tua volontà, e conserva i suoi dati per 400 giorni.
Accesso ai Dati — contiene tutti gli eventi legati alle operazioni degli utenti cloud sui dati (creazione, modifica, lettura, ecc.). Di default, questo registro non viene attivato, poiché il suo volume cresce molto rapidamente. Per questo motivo, il periodo di conservazione è di soli 30 giorni. Inoltre, non vengono registrati tutti gli eventi. Ad esempio, non vengono registrati eventi relativi a risorse pubblicamente disponibili per tutti gli utenti o accessibili senza accesso a GCP.
Evento di Sistema — contiene eventi di sistema non legati agli utenti o azioni dell'amministratore che modificano la configurazione delle risorse cloud. Viene sempre registrato e conservato per 400 giorni.
Access Transparency è un esempio unico di registro che tiene traccia di tutte le azioni degli impiegati di Google (anche se attualmente non per tutti i servizi GCP) che accedono alla tua infrastruttura nell'ambito delle loro mansioni. Questo registro è conservato per 400 giorni ed è accessibile solo a determinati clienti GCP, a condizione di soddisfare specifici requisiti (ossia avere un supporto di livello Gold o Platinum, oppure avere 4 ruoli di un certo tipo nel contesto del supporto aziendale). Una funzione simile è disponibile, ad esempio, in Office 365 — Lockbox.

Esempio di registro: Access Transparency

{
 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:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_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 è possibile attraverso diversi metodi (simile a quanto esaminato precedentemente per Azure e AWS) — tramite l'interfaccia Log Viewer, tramite API, attraverso Google Cloud SDK o attraverso la pagina Activity del tuo progetto per cui sei interessato agli eventi. Allo stesso modo, possono essere esportati in soluzioni esterne per un'analisi aggiuntiva. Quest'ultima operazione avviene esportando i log nel bucket BigQuery o in Cloud Pub/Sub.

Oltre a Stackdriver Logging, la piattaforma GCP offre anche le funzionalità di Stackdriver Monitoring, che consentono di monitorare metriche chiave (prestazioni, tempo medio tra guasti, stato generale, ecc.) dei servizi e delle applicazioni cloud. I dati elaborati e visualizzati in modo specifico possono facilitare l'individuazione dei problemi nella tua infrastruttura cloud, anche nel contesto della sicurezza. Tuttavia, è importante notare che queste funzionalità non sono particolarmente ricche in relazione alla Sicurezza Informatica, poiché a oggi 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 attualmente è in beta e sarebbe prematuro parlare della sua utilità). Stackdriver Monitoring potrebbe essere utilizzato come sistema per la rilevazione di anomalie, che verrebbero successivamente investigate per individuare le cause. Tuttavia, data la carenza attuale di personale qualificato nel campo della Sicurezza Informatica sul mercato, questo compito appare attualmente complesso.

È opportuno elencare alcuni moduli relativi alla sicurezza informatica che possono essere applicati nel vostro cloud GCP e che sono simili a quelli offerti da AWS:

Cloud Security Command Center è l'equivalente di AWS Security Hub e Azure Security Center.
Cloud DLP offre rilevamento e modifica automatica (ad esempio, mascheramento) dei dati memorizzati nel cloud, secondo oltre 90 politiche di classificazione preimpostate.
Cloud Scanner è uno scanner di vulnerabilità note (XSS, Flash Injection, librerie non aggiornate, ecc.) per App Engine, Compute Engine e Google Kubernetes.
Cloud IAM consente la gestione degli accessi a tutte le risorse GCP.
Cloud Identity gestisce gli account utenti, i dispositivi e le applicazioni GCP da un'unica console.
Cloud HSM protegge le chiavi crittografiche.
Cloud Key Management Service si occupa della gestione delle chiavi crittografiche in GCP.
VPC Service Control crea un perimetro sicuro attorno alle vostre risorse GCP per proteggerle da perdite.
Titan Security Key offre protezione contro il phishing.

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

Ho fatto una breve panoramica delle funzionalità integrate di monitoraggio nelle popolari piattaforme cloud. Ma avete specialisti in grado di lavorare con i log “grezzi” del fornitore IaaS (non tutti sono disposti a pagare per funzionalità avanzate di AWS, Azure o Google)? Inoltre, è ben nota l'espressione “fidati, ma verifica”, che nel campo della sicurezza è più valida che mai. Quanto vi fidate delle funzionalità integrate del fornitore cloud che vi forniscono eventi di sicurezza? Quanto si concentrano sulla sicurezza informatica?

A volte è utile considerare soluzioni di monitoraggio sovrapposte per le infrastrutture cloud, che possono integrare la sicurezza integrata del cloud, e talvolta queste soluzioni sono l'unica opzione per ottenere dati sulla sicurezza delle vostre informazioni e applicazioni ospitate nel cloud. Inoltre, sono semplicemente più comode, poiché si occupano di tutte le attività di analisi dei log necessari generati da diversi servizi cloud di vari fornitori. Un esempio di tale soluzione sovrapposta è Cisco Stealthwatch Cloud, che si concentra su un'unica attività: il monitoraggio delle anomalie di sicurezza informatica negli ambienti cloud, inclusi Amazon AWS, Microsoft Azure e Google Cloud Platform, oltre ai cloud privati.

Esempio: Monitoraggio della sicurezza informatica con Stealthwatch Cloud

AWS offre una piattaforma di calcolo flessibile, ma questa flessibilità porta le aziende a commettere più facilmente errori che sfociano in problemi di sicurezza. Inoltre, il modello condiviso di sicurezza delle informazioni contribuisce a questa situazione. L'esecuzione nel cloud di software con vulnerabilità sconosciute (per le vulnerabilità note si possono usare strumenti come AWS Inspector o GCP Cloud Scanner), password deboli, configurazioni errate, insider e così via, influiscono su come si comportano le risorse cloud. Questo comportamento può essere monitorato da Cisco Stealthwatch Cloud, un sistema di monitoraggio della sicurezza delle informazioni e di rilevamento delle intrusioni nei cloud pubblici e privati.

Una delle caratteristiche fondamentali di Cisco Stealthwatch Cloud è la possibilità di modellare entità. Grazie a questa funzione, è possibile creare un modello software (ossia una simulazione quasi in tempo reale) di ciascuna delle vostre risorse cloud (che si tratti di AWS, Azure, GCP o altro). Queste risorse possono includere server e utenti, così come tipologie di risorse specifiche per il vostro ambiente cloud, come i gruppi di sicurezza e i gruppi di scalabilità automatica dei servizi (auto-scale). Questi modelli utilizzano come input flussi dati strutturati forniti dai servizi cloud. Ad esempio, per AWS, saranno i VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda e AWS IAM. La modellazione delle entità individua automaticamente il ruolo e il comportamento di ciascuna delle vostre risorse (si può parlare di profiling di tutta l'attività cloud). Tra questi ruoli si possono trovare dispositivi mobili Android o Apple, server Citrix PVS, server RDP, gateway di posta, client VoIP, server terminali, controller di dominio e così via. Successivamente, monitora continuamente il loro comportamento per determinare quando si verifica un comportamento rischioso o minaccioso per la sicurezza. Potete identificare tentativi di forza bruta, attacchi DDoS, perdite di dati, accesso remoto non autorizzato, attività di malware, scansioni di vulnerabilità e altre minacce. Ad esempio, ecco come appare il rilevamento di un tentativo di accesso remoto da un paese atipico per la vostra organizzazione (Corea del Sud) a un cluster Kubernetes via SSH:

Ecco come appare un presunto leak di informazioni dal database Postgres in un paese con cui non si era mai interagito prima:

Infine, ecco come si presenta un numero eccessivamente elevato di tentativi di accesso falliti tramite SSH dalla Cina e dall'Indonesia da un dispositivo remoto esterno:

Oppure, supponiamo che un'istanza di server in un VPC non debba mai essere una destinazione per l'accesso remoto al sistema, secondo la politica. Supponiamo inoltre che si sia verificato un accesso remoto a questo computer a causa di una modifica errata della politica delle regole del firewall. La funzione di modellazione delle entità rileverà e segnalerà questa attività ('Accesso remoto insolito') in quasi tempo reale, indicando la specifica chiamata API di AWS CloudTrail, Azure Monitor o GCP Stackdriver Logging (incluso nome utente, data e ora, tra gli altri dettagli) che ha provocato la modifica della regola del firewall. Quindi, queste informazioni possono essere inviate a SIEM per l'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 legati alle persone, ai processi o alla tecnologia. Ad esempio, consente di identificare, tra l'altro, problematiche di sicurezza come:

Qualcuno ha scoperto una backdoor nel software che utilizziamo?
C'è del software o un dispositivo di terze parti nel nostro cloud?
Un utente autorizzato abusa delle sue autorizzazioni?
È stato commesso un errore di configurazione che consente l'accesso remoto o un altro uso non intenzionale delle risorse?
Ci sono perdite di dati dai nostri server?
Qualcuno ha cercato di connettersi a noi da una posizione geografica insolita?
Il nostro cloud è infettato da malware?

Un evento di sicurezza informatica rilevato può essere notificato come ticket appropriato in Slack, Cisco Spark, nel sistema di gestione incidenti PagerDuty, e anche inviato a vari SIEM, tra cui Splunk o ELK. In sintesi, se la vostra azienda adotta una strategia multi-cloud e non si limita a un solo fornitore di cloud, le capacità di monitoraggio della sicurezza informatica descritte sopra rendono Cisco Stealthwatch Cloud una buona opzione per ottenere un insieme unificato di funzionalità di monitoraggio dai principali attori del settore cloud: Amazon, Microsoft e Google. La cosa interessante è che, confrontando i prezzi di Stealthwatch Cloud con le licenze avanzate per il monitoraggio della sicurezza in AWS, Azure o GCP, può risultare che la soluzione di Cisco sia persino più conveniente delle funzionalità integrate offerte da Amazon, Microsoft e Google. Paradossalmente, è così. E più cloud e capacità utilizzate, più evidente sarà il vantaggio di una soluzione consolidata.

Inoltre, Stealthwatch Cloud può monitorare anche le infrastrutture cloud private implementate nella vostra organizzazione, ad esempio basate su container Kubernetes o attraverso il monitoraggio dei flussi Netflow o del traffico di rete acquisito tramite mirroring nell'hardware di rete (anche di produzione nazionale), dati AD o server DNS, e così via. Tutti questi dati verranno arricchiti con informazioni di Threat Intelligence raccolte dal team di Cisco Talos, che è il più grande gruppo di ricercatori indipendenti nel campo delle minacce alla sicurezza informatica.

Questo vi consente di realizzare un sistema di monitoraggio unificato per i cloud pubblici e ibridi che la vostra azienda può utilizzare. Le informazioni raccolte possono poi essere analizzate attraverso le funzionalità integrate di Stealthwatch Cloud o inviate al vostro SIEM (supporta di default Splunk, ELK, SumoLogic e altri).

Concludiamo qui la prima parte dell'articolo, in cui ho esaminato gli strumenti interni 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 analizzeremo le soluzioni di monitoraggio delle piattaforme SaaS, come Salesforce e Dropbox, e cercheremo di riassumere e collegare tutto insieme, creando un sistema unificato di monitoraggio della sicurezza delle varie piattaforme cloud.

Fonte: habr.com