🥇Monitoraggio della sicurezza nel cloud

Lo spostamento di dati e applicazioni nel cloud rappresenta una nuova sfida per i SOC aziendali, che non sempre sono pronti a monitorare l'infrastruttura di altri. Secondo Netoskope, l’impresa media (apparentemente negli Stati Uniti) utilizza 1246 diversi servizi cloud, ovvero il 22% in più rispetto a un anno fa. 1246 servizi cloud!!! Di questi, 175 riguardano servizi HR, 170 riguardano il marketing, 110 riguardano il campo della comunicazione e 76 riguardano la finanza e il CRM. Cisco utilizza “solo” 700 servizi cloud esterni. Quindi sono un po' confuso da questi numeri. Ma in ogni caso il problema non è loro, ma il fatto che il cloud comincia ad essere utilizzato in modo piuttosto attivo da un numero crescente di aziende che vorrebbero avere le stesse capacità di monitoraggio dell'infrastruttura cloud della propria rete. E questa tendenza è in crescita, secondo secondo la Camera dei conti americana Entro il 2023, negli Stati Uniti verranno chiusi 1200 data center (6250 sono già stati chiusi). Ma il passaggio al cloud non significa semplicemente “spostare i nostri server verso un provider esterno”. Nuova architettura IT, nuovo software, nuovi processi, nuove restrizioni... Tutto ciò comporta cambiamenti significativi nel lavoro non solo dell'IT, ma anche della sicurezza delle informazioni. E se i fornitori hanno imparato a far fronte in qualche modo alla garanzia della sicurezza del cloud stesso (per fortuna ci sono molte raccomandazioni), allora con il monitoraggio della sicurezza delle informazioni sul cloud, soprattutto sulle piattaforme SaaS, ci sono difficoltà significative, di cui parleremo.

Supponiamo che la tua azienda abbia spostato parte della sua infrastruttura nel cloud... Stop. Non in questo modo. Se l'infrastruttura è stata trasferita e solo ora stai pensando a come monitorarla, hai già perso. A meno che non si tratti di Amazon, Google o Microsoft (e quindi con riserva), probabilmente non avrai molta capacità di monitorare i tuoi dati e le tue applicazioni. Va bene se ti viene data l'opportunità di lavorare con i log. A volte i dati sugli eventi di sicurezza saranno disponibili, ma non potrai accedervi. Ad esempio, Office 365. Se disponi della licenza E1 più economica, gli eventi di sicurezza non saranno affatto disponibili. Se disponi di una licenza E3, i tuoi dati vengono archiviati solo per 90 giorni e solo se disponi di una licenza E5, la durata dei registri è disponibile per un anno (tuttavia, questo ha anche le sue sfumature legate alla necessità di richiedere una serie di funzioni per lavorare con i log al supporto Microsoft). A proposito, la licenza E3 è molto più debole in termini di funzioni di monitoraggio rispetto a Exchange aziendale. Per raggiungere lo stesso livello, è necessaria una licenza E5 o una licenza Advanced Compliance aggiuntiva, che potrebbe richiedere denaro aggiuntivo che non è stato preso in considerazione nel tuo modello finanziario per il passaggio all'infrastruttura cloud. E questo è solo un esempio di sottovalutazione delle problematiche legate al monitoraggio della sicurezza delle informazioni nel cloud. In questo articolo, senza la pretesa di essere esaustivo, voglio attirare l'attenzione su alcune sfumature di cui è opportuno tenere conto quando si sceglie un fornitore di servizi cloud dal punto di vista della sicurezza. E alla fine dell'articolo verrà fornita una checklist che vale la pena completare prima di considerare che la questione del monitoraggio della sicurezza delle informazioni nel cloud è stata risolta.

Esistono diversi problemi tipici che portano a incidenti negli ambienti cloud, ai quali i servizi di sicurezza delle informazioni non hanno il tempo di rispondere o non li vedono affatto:

I registri di sicurezza non esistono. Questa è una situazione abbastanza comune, soprattutto tra i giocatori alle prime armi nel mercato delle soluzioni cloud. Ma non dovresti rinunciarvi subito. I piccoli operatori, soprattutto quelli domestici, sono più sensibili alle esigenze dei clienti e possono implementare rapidamente alcune funzioni richieste modificando la roadmap approvata per i loro prodotti. Sì, questo non sarà un analogo di GuardDuty di Amazon o del modulo "Proactive Protection" di Bitrix, ma almeno qualcosa.
La sicurezza delle informazioni non sa dove sono archiviati i registri o non è possibile accedervi. Qui è necessario avviare trattative con il fornitore di servizi cloud: forse fornirà tali informazioni se ritiene che il cliente sia importante per lui. Ma in generale, non è molto positivo quando l’accesso ai log viene fornito “per decisione speciale”.
Succede anche che il fornitore di servizi cloud disponga di registri, ma forniscano un monitoraggio limitato e una registrazione degli eventi, che non sono sufficienti per rilevare tutti gli incidenti. Ad esempio, potresti ricevere solo i registri delle modifiche su un sito Web o i registri dei tentativi di autenticazione dell'utente, ma non altri eventi, come il traffico di rete, che ti nasconderanno un intero livello di eventi che caratterizzano i tentativi di hackeraggio della tua infrastruttura cloud.
Esistono registri, ma l'accesso ad essi è difficile da automatizzare, il che costringe a monitorarli non continuamente, ma secondo una pianificazione. E se non è possibile scaricare i registri automaticamente, il download dei registri, ad esempio, in formato Excel (come nel caso di numerosi fornitori di soluzioni cloud nazionali), potrebbe persino portare ad una riluttanza da parte del servizio di sicurezza informatica aziendale ad armeggiare con essi.
Nessun monitoraggio dei registri. Questa è forse la ragione meno chiara per il verificarsi di incidenti legati alla sicurezza delle informazioni negli ambienti cloud. Sembra che ci siano dei log ed è possibile automatizzare l'accesso ad essi, ma nessuno lo fa. Perché?

Concetto di sicurezza cloud condiviso

La transizione al cloud è sempre una ricerca di un equilibrio tra il desiderio di mantenere il controllo sull'infrastruttura e il suo trasferimento nelle mani più professionali di un fornitore di servizi cloud specializzato nella sua manutenzione. E anche nel campo della sicurezza nel cloud occorre ricercare questo equilibrio. Inoltre, a seconda del modello di fornitura del servizio cloud utilizzato (IaaS, PaaS, SaaS), questo equilibrio sarà sempre diverso. In ogni caso, dobbiamo ricordare che tutti i fornitori di cloud oggi seguono il cosiddetto modello di responsabilità condivisa e sicurezza delle informazioni condivise. Di alcune cose è responsabile il cloud, di altre è responsabile il cliente, che colloca i suoi dati, le sue applicazioni, le sue macchine virtuali e altre risorse nel cloud. Sarebbe sconsiderato aspettarsi che passando al cloud si trasferisca tutta la responsabilità al fornitore. Ma non è nemmeno saggio creare da soli tutta la sicurezza quando si passa al cloud. È necessario un equilibrio, che dipenderà da molti fattori: - strategia di gestione del rischio, modello di minaccia, meccanismi di sicurezza a disposizione del fornitore di servizi cloud, legislazione, ecc.

Ad esempio, la classificazione dei dati ospitati nel cloud è sempre a carico del cliente. Un fornitore di servizi cloud o un fornitore di servizi esterno può aiutarlo solo con strumenti che aiuteranno a contrassegnare i dati nel cloud, identificare le violazioni, eliminare i dati che violano la legge o mascherarli utilizzando un metodo o un altro. D’altro canto, la sicurezza fisica è sempre responsabilità del fornitore di servizi cloud, che non può condividerla con i clienti. Ma tutto ciò che si trova tra dati e infrastruttura fisica è proprio oggetto di discussione in questo articolo. Ad esempio, la disponibilità del cloud è responsabilità del fornitore, mentre l'impostazione delle regole del firewall o l'attivazione della crittografia è responsabilità del cliente. In questo articolo proveremo a vedere quali meccanismi di monitoraggio della sicurezza delle informazioni sono forniti oggi da vari famosi provider cloud in Russia, quali sono le caratteristiche del loro utilizzo e quando vale la pena guardare a soluzioni di overlay esterne (ad esempio, Cisco E- mail Security) che espandono le capacità del tuo cloud in termini di sicurezza informatica. In alcuni casi, soprattutto se stai seguendo una strategia multi-cloud, non avrai altra scelta che utilizzare soluzioni esterne di monitoraggio della sicurezza delle informazioni in più ambienti cloud contemporaneamente (ad esempio Cisco CloudLock o Cisco Stealthwatch Cloud). Ebbene, in alcuni casi ti renderai conto che il fornitore cloud che hai scelto (o che ti è stato imposto) non offre alcuna funzionalità di monitoraggio della sicurezza delle informazioni. Questo è spiacevole, ma anche non da poco, poiché consente di valutare adeguatamente il livello di rischio associato al lavoro con questo cloud.

Ciclo di vita del monitoraggio della sicurezza nel cloud

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

affidarsi agli strumenti forniti dal proprio fornitore di servizi cloud,
utilizzare soluzioni di terze parti che monitoreranno le piattaforme IaaS, PaaS o SaaS che utilizzi,
costruisci la tua infrastruttura di monitoraggio cloud (solo per piattaforme IaaS/PaaS).

Vediamo quali caratteristiche ha ciascuna di queste opzioni. Ma prima dobbiamo comprendere il quadro generale che verrà utilizzato durante il monitoraggio delle piattaforme cloud. Vorrei evidenziare 6 componenti principali del processo di monitoraggio della sicurezza delle informazioni nel cloud:

Preparazione delle infrastrutture. Determinazione delle applicazioni e dell'infrastruttura necessarie per la raccolta di eventi importanti per la sicurezza delle informazioni nell'archiviazione.
Collezione. In questa fase, gli eventi di sicurezza vengono aggregati da varie fonti per la successiva trasmissione per l'elaborazione, l'archiviazione e l'analisi.
Trattamento. In questa fase, i dati vengono trasformati e arricchiti per facilitare la successiva analisi.
Magazzinaggio. Questo componente è responsabile dell'archiviazione a breve e lungo termine dei dati elaborati e grezzi raccolti.
Analisi. In questa fase, hai la possibilità di rilevare gli incidenti e rispondere automaticamente o manualmente.
Segnalazione. Questa fase aiuta a formulare indicatori chiave per le parti interessate (management, revisori, fornitore di servizi cloud, clienti, ecc.) che ci aiutano a prendere determinate decisioni, ad esempio cambiare un fornitore o rafforzare la sicurezza delle informazioni.

Comprendere questi componenti ti consentirà di decidere rapidamente in futuro cosa puoi prendere dal tuo fornitore e cosa dovrai fare da solo o con il coinvolgimento di consulenti esterni.

Servizi cloud integrati

Ho già scritto sopra che molti servizi cloud oggi non forniscono alcuna funzionalità di monitoraggio della sicurezza delle informazioni. In generale, non prestano molta attenzione al tema della sicurezza delle informazioni. Ad esempio, uno dei popolari servizi russi per l'invio di rapporti alle agenzie governative tramite Internet (non ne menzionerò specificamente il nome). Tutta la sezione relativa alla sicurezza di questo servizio ruota attorno all'utilizzo del CIPF certificato. La sezione dedicata alla sicurezza informatica di un altro servizio cloud domestico per la gestione dei documenti elettronici non è diversa. Si parla di certificati a chiave pubblica, crittografia certificata, eliminazione delle vulnerabilità web, protezione contro gli attacchi DDoS, utilizzo di firewall, backup e persino controlli regolari sulla sicurezza delle informazioni. Ma non c'è una parola sul monitoraggio, né sulla possibilità di avere accesso a eventi di sicurezza informatica che potrebbero interessare ai clienti di questo fornitore di servizi.

In generale, dal modo in cui il fornitore di servizi cloud descrive i problemi di sicurezza delle informazioni sul suo sito Web e nella sua documentazione, puoi capire quanto seriamente prenda questo problema. Ad esempio, se leggi i manuali dei prodotti “My Office”, non c'è alcuna parola sulla sicurezza, ma nella documentazione del prodotto separato “My Office. KS3", progettato per proteggere dall'accesso non autorizzato, c'è un consueto elenco di punti del 17° ordine del FSTEC, che "My Office.KS3" implementa, ma non viene descritto come lo implementa e, soprattutto, come farlo integrare questi meccanismi con la sicurezza informatica aziendale. Forse tale documentazione esiste, ma non l'ho trovata di pubblico dominio, sul sito “My Office”. Anche se forse semplicemente non ho accesso a queste informazioni segrete?...

Per Bitrix la situazione è molto migliore. La documentazione descrive i formati dei registri eventi e, cosa interessante, il registro delle intrusioni, che contiene eventi relativi a potenziali minacce alla piattaforma cloud. Da lì puoi estrarre l'IP, il nome utente o ospite, l'origine dell'evento, l'ora, l'agente utente, il tipo di evento, ecc. È vero, puoi lavorare con questi eventi dal pannello di controllo del cloud stesso o caricare i dati in formato MS Excel. Ora è difficile automatizzare il lavoro con i log Bitrix e dovrai svolgere parte del lavoro manualmente (caricando il report e caricandolo nel tuo SIEM). Ma se ricordiamo che fino a tempi relativamente recenti non esisteva tale opportunità, allora si tratta di un grande progresso. Allo stesso tempo, vorrei sottolineare che molti fornitori di servizi cloud stranieri offrono funzionalità simili "per principianti": guarda i registri con i tuoi occhi attraverso il pannello di controllo o carica i dati su te stesso (tuttavia, la maggior parte carica i dati in formato . formato CSV, non Excel).

Senza considerare l'opzione no-log, i fornitori di servizi cloud solitamente offrono tre opzioni per monitorare gli eventi di sicurezza: dashboard, caricamento dati e accesso API. Il primo sembra risolverti molti problemi, ma non è del tutto vero: se hai più riviste, devi passare da una schermata all'altra per visualizzarle, perdendo il quadro generale. Inoltre, è improbabile che il fornitore di servizi cloud ti offra la possibilità di correlare gli eventi di sicurezza e in generale di analizzarli dal punto di vista della sicurezza (di solito hai a che fare con dati grezzi, che devi comprendere tu stesso). Ci sono delle eccezioni e ne parleremo più avanti. Infine, vale la pena chiedersi quali eventi vengono registrati dal tuo fornitore di servizi cloud, in quale formato e come corrispondono al tuo processo di monitoraggio della sicurezza delle informazioni? Ad esempio, l'identificazione e l'autenticazione di utenti e ospiti. Lo stesso Bitrix permette, in base a questi eventi, di registrare la data e l'ora dell'evento, il nome dell'utente o dell'ospite (se si dispone del modulo “Web Analytics”), l'oggetto visitato e altri elementi tipici di un sito web . Ma i servizi di sicurezza delle informazioni aziendali potrebbero aver bisogno di informazioni sul fatto che l'utente abbia effettuato l'accesso al cloud da un dispositivo affidabile (ad esempio, in una rete aziendale questa attività è implementata da Cisco ISE). Che ne dici di un compito così semplice come la funzione geo-IP, che aiuterà a determinare se l'account utente di un servizio cloud è stato rubato? E anche se te lo fornisce il fornitore di servizi cloud, questo non è sufficiente. Lo stesso Cisco CloudLock non si limita ad analizzare la geolocalizzazione, ma utilizza per questo il machine learning e analizza i dati storici di ciascun utente e monitora diverse anomalie nei tentativi di identificazione e autenticazione. Solo MS Azure ha funzionalità simili (se disponi dell'abbonamento appropriato).

C'è un'altra difficoltà: poiché per molti fornitori di servizi cloud il monitoraggio della sicurezza delle informazioni è un argomento nuovo con cui stanno appena iniziando ad affrontare, qualcosa cambia costantemente nelle loro soluzioni. Oggi hanno una versione dell'API, domani un'altra, dopodomani una terza. Devi essere preparato anche per questo. Lo stesso vale per le funzionalità, che possono cambiare, di cui bisogna tenere conto nel sistema di monitoraggio della sicurezza delle informazioni. Ad esempio, Amazon inizialmente disponeva di servizi di monitoraggio degli eventi cloud separati: AWS CloudTrail e AWS CloudWatch. Quindi è apparso un servizio separato per il monitoraggio degli eventi di sicurezza delle informazioni: AWS GuardDuty. Dopo qualche tempo, Amazon ha lanciato un nuovo sistema di gestione, Amazon Security Hub, che include l'analisi dei dati ricevuti da GuardDuty, Amazon Inspector, Amazon Macie e molti altri. Un altro esempio è lo strumento di integrazione dei log di Azure con SIEM - AzLog. È stato utilizzato attivamente da molti fornitori SIEM, fino a quando nel 2018 Microsoft ha annunciato la cessazione del suo sviluppo e supporto, cosa che ha messo di fronte a un problema molti clienti che utilizzavano questo strumento (di cui parleremo più avanti).

Pertanto, monitora attentamente tutte le funzionalità di monitoraggio che il tuo provider cloud ti offre. Oppure affidati a fornitori di soluzioni esterni che fungeranno da intermediari tra il tuo SOC e il cloud che desideri monitorare. Sì, sarà più costoso (anche se non sempre), ma trasferirai tutta la responsabilità sulle spalle di qualcun altro. O non tutto?.. Ricordiamo il concetto di sicurezza condivisa e comprendiamo che non possiamo spostare nulla: dovremo capire in modo indipendente come i diversi fornitori di servizi cloud forniscono il monitoraggio della sicurezza delle informazioni dei vostri dati, applicazioni, macchine virtuali e altre risorse ospitato nel cloud. E inizieremo con ciò che offre Amazon in questa parte.

Esempio: monitoraggio della sicurezza delle informazioni in IaaS basato su AWS

Sì, sì, capisco che Amazon non è il miglior esempio perché si tratta di un servizio americano e può essere bloccato come parte della lotta contro l'estremismo e la diffusione di informazioni vietate in Russia. Ma in questa pubblicazione vorrei solo mostrare come le diverse piattaforme cloud differiscono nelle loro capacità di monitoraggio della sicurezza delle informazioni e a cosa dovresti prestare attenzione quando trasferisci i tuoi processi chiave sul cloud dal punto di vista della sicurezza. Ebbene, se alcuni sviluppatori russi di soluzioni cloud imparassero qualcosa di utile per se stessi, sarebbe fantastico.

La prima cosa da dire è che Amazon non è una fortezza impenetrabile. Ai suoi clienti accadono regolarmente vari incidenti. Ad esempio, i nomi, gli indirizzi, le date di nascita e i numeri di telefono di 198 milioni di elettori sono stati rubati da Deep Root Analytics. La società israeliana Nice Systems ha rubato 14 milioni di record di abbonati Verizon. Tuttavia, le funzionalità integrate di AWS ti consentono di rilevare un'ampia gamma di incidenti. Per esempio:

impatto sulle infrastrutture (DDoS)
compromissione del nodo (iniezione di comandi)
compromissione dell'account e accesso non autorizzato
configurazione errata e vulnerabilità
interfacce e API non sicure.

Questa discrepanza è dovuta al fatto che, come abbiamo scoperto sopra, il cliente stesso è responsabile della sicurezza dei dati del cliente. E se non si è preoccupato di attivare i meccanismi di protezione e non ha attivato gli strumenti di monitoraggio, verrà a conoscenza dell'incidente solo dai media o dai suoi clienti.

Per identificare gli incidenti, è possibile utilizzare un'ampia gamma di diversi servizi di monitoraggio sviluppati da Amazon (sebbene questi siano spesso integrati da strumenti esterni come osquery). Pertanto, in AWS, tutte le azioni dell'utente vengono monitorate, indipendentemente da come vengono eseguite, tramite la console di gestione, la riga di comando, l'SDK o altri servizi AWS. Tutti i record dell'attività di ciascun account AWS (inclusi nome utente, azione, servizio, parametri di attività e risultato) e l'utilizzo dell'API sono disponibili tramite AWS CloudTrail. Puoi visualizzare questi eventi (come gli accessi alla console AWS IAM) dalla console CloudTrail, analizzarli utilizzando Amazon Athena o "esternalizzarli" a soluzioni esterne come Splunk, AlienVault, ecc. I log AWS CloudTrail stessi vengono inseriti nel bucket AWS S3.

Altri due servizi AWS forniscono una serie di altre importanti funzionalità di monitoraggio. Innanzitutto, Amazon CloudWatch è un servizio di monitoraggio delle risorse e delle applicazioni AWS che, tra le altre cose, ti consente di identificare varie anomalie nel tuo cloud. Tutti i servizi AWS integrati, come Amazon Elastic Compute Cloud (server), Amazon Relational Database Service (database), Amazon Elastic MapReduce (analisi dei dati) e altri 30 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 ad applicazioni e servizi personalizzati, consentendo loro di espandere l'ambito dell'analisi degli eventi in un contesto di sicurezza.

In secondo luogo, il servizio VPC Flow Logs ti consente di analizzare il traffico di rete inviato o ricevuto dai tuoi server AWS (esternamente o internamente), nonché tra microservizi. Quando una qualsiasi delle tue risorse AWS VPC interagisce con la rete, i log di flusso VPC registrano i dettagli sul traffico di rete, inclusa l'interfaccia di rete di origine e destinazione, nonché gli indirizzi IP, le porte, il protocollo, il numero di byte e il numero di pacchetti che hai sega. Coloro che hanno esperienza con la sicurezza della rete locale lo riconosceranno come analogo ai thread Flusso netto, che può essere creato da switch, router e firewall di livello aziendale. Questi log sono importanti ai fini del monitoraggio della sicurezza delle informazioni perché, a differenza degli eventi relativi alle azioni degli utenti e delle applicazioni, consentono anche di non perdere le interazioni di rete nell'ambiente cloud privato virtuale AWS.

In sintesi, questi tre servizi AWS (AWS CloudTrail, Amazon CloudWatch e VPC Flow Logs) forniscono insieme informazioni abbastanza approfondite sull'utilizzo dell'account, sul comportamento degli utenti, sulla gestione dell'infrastruttura, sull'attività delle applicazioni e dei servizi e sull'attività di rete. Ad esempio, possono essere utilizzati per rilevare le seguenti anomalie:

Tentativi di scansionare il sito, cercare backdoor, cercare vulnerabilità attraverso raffiche di “errori 404”.
Attacchi injection (ad esempio SQL injection) attraverso raffiche di “500 errori”.
Gli strumenti di attacco noti sono sqlmap, nikto, w3af, nmap, ecc. attraverso l'analisi del campo User Agent.

Amazon Web Services ha sviluppato anche altri servizi per scopi di sicurezza informatica che permettono di risolvere tanti altri problemi. Ad esempio, AWS dispone di un servizio integrato per il controllo di policy e configurazioni: AWS Config. Questo servizio fornisce un controllo continuo delle risorse AWS e delle relative configurazioni. Facciamo 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 possibile solo in base ai certificati. AWS Config semplifica il controllo di questo per tutti i tuoi server. Esistono altre policy 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 ampliato per automatizzare il rilevamento delle violazioni delle policy sviluppate. Le regole di AWS Config sono essenzialmente richieste di configurazione continue per i servizi Amazon che utilizzi, che generano eventi se le policy corrispondenti vengono violate. Ad esempio, invece di eseguire periodicamente query AWS Config per verificare che tutti i dischi su un server virtuale siano crittografati, è possibile utilizzare le regole AWS Config per controllare continuamente i dischi del server per garantire che questa condizione sia soddisfatta. E, soprattutto, nel contesto di questa pubblicazione, eventuali violazioni generano eventi che possono essere analizzati dal vostro servizio di sicurezza informatica.

AWS dispone anche di soluzioni equivalenti alle tradizionali soluzioni di sicurezza delle informazioni aziendali, che generano anche eventi di sicurezza che puoi e dovresti analizzare:

Rilevamento delle intrusioni - AWS GuardDuty
Controllo della perdita di informazioni - AWS Macie
EDR (anche se parla un po' stranamente di endpoint nel cloud) - AWS Cloudwatch + osquery open source o soluzioni GRR
Analisi del flusso di rete: AWS Cloudwatch + AWS VPC Flow
Analisi DNS - AWS Cloudwatch + AWS Route53
AD: AWS Directory Service
Gestione account - AWS IAM
SSO: AWS SSO
analisi della sicurezza - AWS Inspector
gestione della configurazione - AWS Config
WAF-AWS WAF.

Non descriverò in dettaglio tutti i servizi Amazon che potrebbero essere utili nel contesto della sicurezza informatica. La cosa principale è capire che tutti possono generare eventi che possiamo e dobbiamo analizzare nel contesto della sicurezza delle informazioni, utilizzando a questo scopo sia le capacità integrate di Amazon stessa sia soluzioni esterne, ad esempio SIEM, che possono porta gli eventi di sicurezza nel tuo centro di monitoraggio e analizzali lì insieme agli eventi provenienti da altri servizi cloud o dall'infrastruttura interna, dal perimetro o dai dispositivi mobili.

In ogni caso, tutto inizia con le fonti dati che forniscono eventi di sicurezza delle informazioni. Queste fonti includono, ma non sono limitate a:

CloudTrail: utilizzo dell'API e azioni dell'utente
Trusted Advisor: controllo di sicurezza rispetto alle migliori pratiche
Config: inventario e configurazione di account e impostazioni del servizio
Log di flusso VPC: connessioni alle interfacce virtuali
IAM - servizio di identificazione e autenticazione
Registri di accesso ELB - Bilanciamento del carico
Ispettore: vulnerabilità dell'applicazione
S3: archiviazione di file
CloudWatch - Attività dell'applicazione
SNS è un servizio di notifica.

Amazon, pur offrendo una tale gamma di fonti di eventi e strumenti per la loro generazione, è molto limitata nella sua capacità di analizzare i dati raccolti nel contesto della sicurezza delle informazioni. Dovrai studiare in modo indipendente i registri disponibili, cercando in essi indicatori rilevanti di compromissione. AWS Security Hub, lanciato di recente da Amazon, mira a risolvere questo problema diventando un SIEM cloud per AWS. Ma finora è solo all'inizio del suo viaggio ed è limitato sia dal numero di fonti con cui funziona sia da altre restrizioni stabilite dall'architettura e dagli abbonamenti di Amazon stessa.

Esempio: monitoraggio della sicurezza delle informazioni in IaaS basato su Azure

Non voglio entrare in un lungo dibattito su quale dei tre fornitori di servizi cloud (Amazon, Microsoft o Google) sia migliore (soprattutto perché ognuno di essi ha comunque le sue specificità ed è adatto a risolvere i propri problemi); Concentriamoci sulle capacità di monitoraggio della sicurezza delle informazioni fornite da questi attori. Bisogna ammettere che Amazon AWS è stato uno dei primi in questo segmento e quindi è quello che ha fatto più progressi in termini di funzioni di sicurezza delle informazioni (anche se molti ammettono che sono difficili da usare). Ma questo non significa che ignoreremo le opportunità che Microsoft e Google ci offrono.

I prodotti Microsoft si sono sempre distinti per la loro “apertura” e in Azure la situazione è simile. Ad esempio, se AWS e GCP partono sempre dal concetto “ciò che non è consentito è proibito”, allora Azure ha l’approccio esattamente opposto. Ad esempio, quando si crea una rete virtuale nel cloud e una macchina virtuale al suo interno, tutte le porte e i protocolli sono aperti e consentiti per impostazione predefinita. Pertanto dovrai dedicare un po' più di impegno alla configurazione iniziale del sistema di controllo degli accessi nel cloud di Microsoft. E questo impone anche requisiti più severi in termini di monitoraggio dell'attività nel cloud di Azure.

AWS ha una particolarità legata al fatto che quando monitori le tue risorse virtuali, se si trovano in regioni diverse, hai difficoltà a combinare tutti gli eventi e la loro analisi unificata, per eliminare le quali devi ricorrere a vari trucchi, come Crea il tuo codice per AWS Lambda che trasporterà gli eventi tra regioni. Azure non presenta questo problema: il suo meccanismo di registro attività tiene traccia di tutte le attività dell'intera organizzazione senza restrizioni. Lo stesso vale per AWS Security Hub, recentemente sviluppato da Amazon per riunire molte funzioni di sicurezza in un unico centro di sicurezza, ma solo all’interno della sua regione, cosa che però non è rilevante per la Russia. Azure dispone di un proprio Centro sicurezza, che non è vincolato da restrizioni regionali, fornendo accesso a tutte le funzionalità di sicurezza della piattaforma cloud. Inoltre, per diversi team locali può fornire il proprio set di capacità di protezione, compresi gli eventi di sicurezza da loro gestiti. AWS Security Hub è ancora sulla buona strada per diventare simile ad Azure Security Center. Ma vale la pena aggiungere un unico neo: puoi estrarre da Azure molto di ciò che è stato precedentemente descritto in AWS, ma è più conveniente farlo solo per Azure AD, Monitoraggio di Azure e Centro sicurezza di Azure. Tutti gli altri meccanismi di sicurezza di Azure, inclusa l'analisi degli eventi di sicurezza, non sono ancora gestiti nel modo più conveniente. Il problema è in parte risolto dalle API, che permeano tutti i servizi Microsoft Azure, ma questo richiederà uno sforzo ulteriore da parte tua per integrare il tuo cloud con il tuo SOC e la presenza di specialisti qualificati (infatti, come per qualsiasi altro SIEM che funziona con cloud API). Alcuni SIEM, di cui parleremo più avanti, supportano già Azure e possono automatizzare l'attività di monitoraggio, ma presenta anche le sue difficoltà: non tutti riescono a raccogliere tutti i log di Azure.

La raccolta e il monitoraggio degli eventi in Azure vengono forniti utilizzando il servizio Monitoraggio di Azure, che è lo strumento principale per la raccolta, l'archiviazione e l'analisi dei dati nel cloud Microsoft e nelle sue risorse: repository Git, contenitori, macchine virtuali, applicazioni, ecc. Tutti i dati raccolti da Monitoraggio di Azure sono divisi in due categorie: metriche, raccolte in tempo reale e che descrivono gli indicatori chiave di prestazione del cloud di Azure, e log, contenenti dati organizzati in record che caratterizzano determinati aspetti dell'attività delle risorse e dei servizi di Azure. Inoltre, utilizzando l'API di raccolta dati, il servizio Monitoraggio di Azure può raccogliere dati da qualsiasi origine REST per creare i propri scenari di monitoraggio.

Di seguito sono riportate alcune origini di eventi di sicurezza offerti da Azure e a cui è possibile accedere tramite il portale di Azure, l'interfaccia della riga di comando, PowerShell o l'API REST (e alcune solo tramite l'API Monitoraggio/Insight di Azure):

Registri attività: questo registro risponde alle classiche domande su "chi", "cosa" e "quando" relative a qualsiasi operazione di scrittura (PUT, POST, DELETE) sulle risorse cloud. Gli eventi relativi all'accesso in lettura (GET) non sono inclusi in questo registro, come molti altri.
Log diagnostici: contiene dati sulle operazioni con una particolare risorsa inclusa nell'abbonamento.
Reporting di Azure AD: contiene sia l'attività dell'utente che l'attività del sistema relativa alla gestione di gruppi e utenti.
Registro eventi di Windows e Syslog Linux: contiene eventi provenienti da macchine virtuali ospitate nel cloud.
Metriche: contiene dati di telemetria sulle prestazioni e sullo stato di integrità dei servizi e delle risorse cloud. Misurato ogni minuto e memorizzato. entro 30 giorni.
Registri di flusso del gruppo di sicurezza di rete: contiene dati sugli eventi di sicurezza di rete raccolti utilizzando il servizio Network Watcher e il monitoraggio delle risorse a livello di rete.
Registri di archiviazione: contiene eventi relativi all'accesso alle strutture di archiviazione.

Per il monitoraggio è possibile usare SIEM esterni o il monitoraggio di Azure integrato e le relative estensioni. Parleremo più avanti dei sistemi di gestione degli eventi di sicurezza delle informazioni, ma per ora vediamo cosa ci offre lo stesso Azure per l’analisi dei dati nell’ambito della sicurezza. La schermata principale per tutto ciò che riguarda la sicurezza in Monitoraggio di Azure è il dashboard di sicurezza e controllo di Log Analytics (la versione gratuita supporta una quantità limitata di archiviazione di eventi per una sola settimana). Questa dashboard è divisa in 5 aree principali che visualizzano statistiche riepilogative di ciò che accade nell'ambiente cloud che stai utilizzando:

Domini di sicurezza: indicatori quantitativi chiave relativi alla sicurezza delle informazioni: numero di incidenti, numero di nodi compromessi, nodi senza patch, eventi di sicurezza della rete, ecc.
Problemi notevoli: visualizza il numero e l'importanza dei problemi di sicurezza delle informazioni attivi
Rilevamenti: visualizza i modelli di attacchi utilizzati contro di te
Threat Intelligence: visualizza informazioni geografiche sui nodi esterni che ti stanno attaccando
Query di sicurezza comuni: query tipiche che ti aiuteranno a monitorare meglio la sicurezza delle tue informazioni.

Le estensioni di Monitoraggio di Azure includono Azure Key Vault (protezione delle chiavi crittografiche nel cloud), Malware Assessment (analisi della protezione contro codice dannoso su macchine virtuali), Azure Application Gateway Analytics (analisi, tra le altre cose, dei log del firewall cloud), ecc. . Questi strumenti, arricchiti con alcune regole per l'elaborazione degli eventi, consentono di visualizzare vari aspetti dell'attività dei servizi cloud, inclusa la sicurezza, e identificare alcune deviazioni dal funzionamento. Ma, come spesso accade, qualsiasi funzionalità aggiuntiva richiede un corrispondente abbonamento a pagamento, che richiederà da parte tua corrispondenti investimenti finanziari, che dovrai pianificare in anticipo.

Azure dispone di una serie di funzionalità di monitoraggio delle minacce predefinite integrate in Azure AD, Monitoraggio di Azure e Centro sicurezza di Azure. Tra questi, ad esempio, il rilevamento dell'interazione di macchine virtuali con IP dannosi noti (grazie alla presenza dell'integrazione con i servizi Threat Intelligence di Microsoft), il rilevamento di malware nell'infrastruttura cloud tramite la ricezione di allarmi da macchine virtuali ospitate nel cloud, password attacchi indovinati” su macchine virtuali, vulnerabilità nella configurazione del sistema di identificazione dell'utente, accesso al sistema da anonimizzatori o nodi infetti, perdite di account, accesso al sistema da posizioni insolite, ecc. Azure oggi è uno dei pochi provider cloud che offre funzionalità di Threat Intelligence integrate per arricchire gli eventi di sicurezza delle informazioni raccolte.

Come accennato in precedenza, la funzionalità di sicurezza e, di conseguenza, gli eventi di sicurezza da essa generati non sono disponibili allo stesso modo per tutti gli utenti, ma richiedono un determinato abbonamento che includa la funzionalità necessaria, che generi gli eventi appropriati per il monitoraggio della sicurezza delle informazioni. Ad esempio, alcune delle funzionalità descritte nel paragrafo precedente per il monitoraggio delle anomalie sugli account sono disponibili solo nella licenza P2 premium del servizio Azure AD. Senza di essa, come nel caso di AWS, dovrai analizzare “manualmente” gli eventi di sicurezza raccolti. Inoltre, a seconda del tipo di licenza di Azure AD, non tutti gli eventi saranno disponibili per l'analisi.

Nel portale di Azure puoi gestire sia le query di ricerca per i log di tuo interesse sia impostare dashboard per visualizzare gli indicatori chiave di sicurezza delle informazioni. Inoltre, è possibile selezionare le estensioni di Monitoraggio di Azure, che consentono di espandere le funzionalità dei log di Monitoraggio di Azure e ottenere un'analisi più approfondita degli eventi dal punto di vista della sicurezza.

Se hai bisogno non solo della capacità di lavorare con i log, ma di un centro sicurezza completo per la tua piattaforma cloud di Azure, inclusa la gestione dei criteri di sicurezza delle informazioni, allora puoi parlare della necessità di lavorare con il Centro sicurezza di Azure, la maggior parte delle quali funzioni utili sono disponibili pagando un certo importo, ad esempio rilevamento delle minacce, monitoraggio all'esterno di Azure, valutazione della conformità, ecc. (nella versione gratuita hai accesso solo a una valutazione della sicurezza e a consigli per eliminare i problemi identificati). Consolida tutti i problemi di sicurezza in un unico posto. In effetti, possiamo parlare di un livello di sicurezza delle informazioni più elevato rispetto a quello offerto da Monitoraggio di Azure, poiché in questo caso i dati raccolti nella tua cloud factory vengono arricchiti utilizzando molte 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 sono sovrapposti vari sofisticati algoritmi di machine learning e analisi comportamentale, che dovrebbero in definitiva migliorare l'efficienza nel rilevamento e nella risposta alle minacce .

Anche Azure ha il proprio SIEM, apparso all'inizio del 2019. Si tratta di Azure Sentinel, che si basa sui dati di Monitoraggio di Azure e può anche integrarsi con. soluzioni di sicurezza esterne (ad esempio NGFW o WAF), il cui elenco è in costante crescita. Inoltre, attraverso l'integrazione dell'API Microsoft Graph Security, hai la possibilità di connettere i tuoi feed di Threat Intelligence a Sentinel, il che arricchisce le funzionalità di analisi degli incidenti nel tuo cloud di Azure. Si può sostenere che Azure Sentinel è il primo SIEM "nativo" apparso dai fornitori di servizi cloud (gli stessi Splunk o ELK, che possono essere ospitati nel cloud, ad esempio AWS, non sono ancora sviluppati dai tradizionali fornitori di servizi cloud). Azure Sentinel e Security Center potrebbero chiamarsi SOC per il cloud Azure e potrebbero essere limitati ad essi (con alcune riserve) se non avessi più alcuna infrastruttura e trasferissi tutte le tue risorse informatiche sul cloud e sarebbe il cloud Microsoft Azure.

Ma poiché le funzionalità integrate di Azure (anche se si dispone di un abbonamento a Sentinel) spesso non sono sufficienti ai fini del monitoraggio della sicurezza delle informazioni e dell'integrazione di questo processo con altre fonti di eventi di sicurezza (sia cloud che interni), esiste un necessità di esportare i dati raccolti verso sistemi esterni, ai quali può includere SIEM. Ciò avviene sia utilizzando l'API che utilizzando estensioni speciali, che sono attualmente ufficialmente disponibili solo per i seguenti SIEM: Splunk (Azure Monitor Add-On per Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight ed ELK. Fino a poco tempo fa esistevano più SIEM di questo tipo, ma dal 1 giugno 2019 Microsoft ha smesso di supportare lo strumento di integrazione dei log di Azure (AzLog), che agli albori dell'esistenza di Azure e in assenza di una normale standardizzazione del lavoro con i log (Azure Monitor non esisteva ancora) ha reso semplice l'integrazione del SIEM esterno con il cloud Microsoft. Ora la situazione è cambiata e Microsoft consiglia la piattaforma Azure Event Hub come principale strumento di integrazione per altri SIEM. Molti hanno già implementato tale integrazione, ma fai attenzione: potrebbero non acquisire tutti i log di Azure, ma solo alcuni (consulta la documentazione del tuo SIEM).

Concludendo una breve escursione in Azure, vorrei dare una raccomandazione generale su questo servizio cloud: prima di dire qualsiasi cosa sulle funzioni di monitoraggio della sicurezza delle informazioni in Azure, dovreste configurarle con molta attenzione e testare che funzionino come scritto nella documentazione e come ti hanno detto i consulenti Microsoft (e potrebbero avere opinioni diverse sulla funzionalità delle funzioni di Azure). Se disponi di risorse finanziarie, puoi ottenere molte informazioni utili da Azure in termini di monitoraggio della sicurezza delle informazioni. Se le tue risorse sono limitate, allora, come nel caso di AWS, dovrai fare affidamento solo sulle tue forze e sui dati grezzi che Azure Monitor ti fornisce. E ricorda che molte funzioni di monitoraggio costano denaro ed è meglio familiarizzare in anticipo con la politica dei prezzi. Ad esempio, puoi archiviare gratuitamente 31 giorni di dati fino a un massimo di 5 GB per cliente: superare questi valori richiederà di sborsare denaro aggiuntivo (circa $ 2+ per archiviare ogni GB aggiuntivo dal cliente e $ 0,1 per memorizzando 1 GB ogni mese aggiuntivo). Anche lavorare con la telemetria e le metriche dell'applicazione può richiedere fondi aggiuntivi, così come lavorare con avvisi e notifiche (un certo limite è disponibile gratuitamente, il che potrebbe non essere sufficiente per le tue esigenze).

Esempio: monitoraggio della sicurezza delle informazioni in IaaS basato su Google Cloud Platform

Google Cloud Platform sembra giovane rispetto ad AWS e Azure, ma questo è in parte positivo. A differenza di AWS, che ha aumentato le sue capacità, comprese quelle di sicurezza, gradualmente, avendo problemi con la centralizzazione; GCP, come Azure, è gestito molto meglio a livello centrale, il che riduce gli errori e i tempi di implementazione in tutta l'azienda. Dal punto di vista della sicurezza, GCP si trova, stranamente, tra AWS e Azure. Ha anche una registrazione evento unica per l'intera organizzazione, ma è incompleta. Alcune funzioni sono ancora in modalità beta, ma gradualmente questa carenza dovrebbe essere eliminata e GCP diventerà una piattaforma più matura in termini di monitoraggio della sicurezza delle informazioni.

Lo strumento principale per la registrazione degli eventi in GCP è Stackdriver Logging (simile a Monitoraggio di Azure), che consente di raccogliere eventi nell'intera infrastruttura cloud (oltre che da AWS). Dal punto di vista della sicurezza in GCP, ogni organizzazione, progetto o cartella ha quattro log:

Attività di amministrazione: contiene tutti gli eventi relativi all'accesso amministrativo, ad esempio la creazione di una macchina virtuale, la modifica dei diritti di accesso, ecc. Questo registro viene sempre scritto, indipendentemente dal tuo desiderio, e memorizza i suoi dati per 400 giorni.
Accesso ai dati: contiene tutti gli eventi relativi all'utilizzo dei dati da parte degli utenti del cloud (creazione, modifica, lettura, ecc.). Per impostazione predefinita, questo registro non viene scritto poiché il suo volume aumenta molto rapidamente. Per questo motivo la sua durata è di soli 30 giorni. Inoltre, non tutto è scritto in questa rivista. Ad esempio, gli eventi relativi alle risorse accessibili pubblicamente a tutti gli utenti o accessibili senza accedere a GCP non vengono scritti al suo interno.
Evento di sistema: contiene eventi di sistema non correlati agli utenti o azioni di un amministratore che modifica la configurazione delle risorse cloud. Viene sempre scritto e conservato per 400 giorni.
La trasparenza degli accessi è un esempio unico di log che cattura tutte le azioni dei dipendenti Google (ma non ancora per tutti i servizi GCP) che accedono alla tua infrastruttura come parte delle loro mansioni lavorative. Questo registro viene archiviato per 400 giorni e non è disponibile per tutti i client GCP, ma solo se vengono soddisfatte una serie di condizioni (supporto di livello Gold o Platinum, oppure presenza di 4 ruoli di un certo tipo nell'ambito del supporto aziendale). Una funzione simile è disponibile, ad esempio, anche in Office 365 - Lockbox.

Esempio di registro: trasparenza dell'accesso

{
 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 a questi log è possibile in diversi modi (più o meno allo stesso modo di Azure e AWS discussi in precedenza): tramite l'interfaccia del visualizzatore log, tramite l'API, tramite Google Cloud SDK o tramite la pagina Attività del progetto per il quale si desidera sono interessati agli eventi. Allo stesso modo, possono essere esportati verso soluzioni esterne per ulteriori analisi. Quest'ultima operazione viene eseguita esportando i log nello spazio di archiviazione BigQuery o Cloud Pub/Sub.

Oltre a Stackdriver Logging, la piattaforma GCP offre anche la funzionalità Stackdriver Monitoring, che consente di monitorare i parametri chiave (prestazioni, MTBF, stato generale, ecc.) dei servizi e delle applicazioni cloud. I dati elaborati e visualizzati possono facilitare l'individuazione dei problemi nella vostra infrastruttura cloud, anche nell'ambito della sicurezza. Ma va notato che questa funzionalità non sarà molto ricca nel contesto della sicurezza delle informazioni, poiché oggi GCP non ha un analogo dello stesso AWS GuardDuty e non può identificare quelli dannosi tra tutti gli eventi registrati (Google ha sviluppato Event Threat Detection, ma è ancora in fase di sviluppo in versione beta ed è troppo presto per parlare della sua utilità). Stackdriver Monitoring potrebbe essere utilizzato come sistema per rilevare anomalie, che verrebbero poi indagate per individuare le cause del loro verificarsi. Ma data la mancanza sul mercato di personale qualificato nel campo della sicurezza informatica GCP, questo compito sembra attualmente difficile.

Vale anche la pena fornire un elenco di alcuni moduli di sicurezza delle informazioni che possono essere utilizzati nel cloud GCP e che sono simili a ciò che offre AWS:

Cloud Security Command Center è un analogo di AWS Security Hub e Azure Security Center.
Cloud DLP: rilevamento e modifica automatici (ad esempio mascheramento) dei dati ospitati nel cloud utilizzando più di 90 criteri di classificazione predefiniti.
Cloud Scanner è uno scanner per vulnerabilità note (XSS, Flash Injection, librerie senza patch, ecc.) in App Engine, Compute Engine e Google Kubernetes.
Cloud IAM: controlla l'accesso a tutte le risorse GCP.
Cloud Identity: gestisci gli account utente, dispositivo e applicazione GCP da un'unica console.
Cloud HSM: protezione delle chiavi crittografiche.
Cloud Key Management Service: gestione delle chiavi crittografiche in GCP.
Controllo del servizio VPC: crea un perimetro sicuro attorno alle tue risorse GCP per proteggerle da perdite.
Chiave di sicurezza Titan: protezione dal phishing.

Molti di questi moduli generano eventi di sicurezza che possono essere inviati allo spazio di archiviazione BigQuery per l'analisi o l'esportazione in altri sistemi, incluso SIEM. Come accennato in precedenza, GCP è una piattaforma in continuo sviluppo e Google sta ora sviluppando una serie di nuovi moduli di sicurezza delle informazioni per la sua piattaforma. Tra questi ci sono Event Threat Detection (ora disponibile in versione beta), che scansiona i log di Stackdriver alla ricerca di tracce di attività non autorizzate (analogo a GuardDuty in AWS), o Policy Intelligence (disponibile in versione alpha), che ti consentirà di sviluppare policy intelligenti per accesso alle risorse GCP.

Ho fatto una breve panoramica delle funzionalità di monitoraggio integrate nelle piattaforme cloud più diffuse. Ma avete specialisti in grado di lavorare con i log “grezzi” dei provider IaaS (non tutti sono pronti ad acquistare le funzionalità avanzate di AWS o Azure o Google)? Inoltre, molti conoscono il detto “fiducia, ma verifica”, che è più vero che mai nel campo della sicurezza. Quanto ti fidi delle funzionalità integrate del fornitore di servizi cloud che ti inviano eventi di sicurezza delle informazioni? Quanto si concentrano sulla sicurezza delle informazioni?

A volte vale la pena cercare soluzioni di monitoraggio dell'infrastruttura cloud sovrapposte che possano integrare la sicurezza cloud integrata, e talvolta tali soluzioni sono l'unica opzione per ottenere informazioni dettagliate sulla sicurezza dei dati e delle applicazioni ospitate nel cloud. Inoltre, sono semplicemente più convenienti, poiché si assumono tutte le attività di analisi dei log necessari generati da diversi servizi cloud di diversi fornitori cloud. Un esempio di tale soluzione overlay è Cisco Stealthwatch Cloud, che si concentra su un unico compito: monitorare le anomalie della sicurezza delle informazioni negli ambienti cloud, inclusi non solo Amazon AWS, Microsoft Azure e Google Cloud Platform, ma anche cloud privati.

Esempio: monitoraggio della sicurezza delle informazioni utilizzando Stealthwatch Cloud

AWS fornisce una piattaforma informatica flessibile, ma questa flessibilità rende più facile per le aziende commettere errori che portano a problemi di sicurezza. E il modello condiviso di sicurezza delle informazioni non fa altro che contribuire a questo. Esecuzione di software nel cloud con vulnerabilità sconosciute (quelle note possono essere combattute, ad esempio, da AWS Inspector o GCP Cloud Scanner), password deboli, configurazioni errate, insider, ecc. E tutto ciò si riflette nel comportamento delle risorse cloud, che possono essere monitorate da Cisco Stealthwatch Cloud, che è un sistema di monitoraggio della sicurezza delle informazioni e di rilevamento degli attacchi. cloud pubblici e privati.

Una delle caratteristiche principali di Cisco Stealthwatch Cloud è la capacità di modellare le entità. Con esso, puoi creare un modello software (ovvero una simulazione quasi in tempo reale) di ciascuna delle tue risorse cloud (non importa se si tratta di AWS, Azure, GCP o qualcos'altro). Questi possono includere server e utenti, nonché tipi di risorse specifici per l'ambiente cloud, come gruppi di sicurezza e gruppi di scalabilità automatica. Questi modelli utilizzano come input flussi di dati strutturati forniti dai servizi cloud. Ad esempio, per AWS questi sarebbero VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda e AWS IAM. La modellazione delle entità rileva automaticamente il ruolo e il comportamento di qualsiasi risorsa (puoi parlare di profilazione di tutta l'attività cloud). Questi ruoli includono dispositivo mobile Android o Apple, server Citrix PVS, server RDP, gateway di posta, client VoIP, server terminal, controller di dominio, ecc. Quindi monitora continuamente il loro comportamento per determinare quando si verifica un comportamento rischioso o pericoloso per la sicurezza. Puoi identificare tentativi di password, attacchi DDoS, fughe di dati, accesso remoto illegale, attività di codice dannoso, scansione di vulnerabilità e altre minacce. Ad esempio, ecco come appare il rilevamento di un tentativo di accesso remoto da un paese atipico per la tua organizzazione (Corea del Sud) a un cluster Kubernetes tramite SSH:

Ed ecco come appare la presunta fuga di informazioni dal database Postgress verso un paese con il quale non abbiamo mai avuto interazioni in precedenza:

Infine, ecco come appaiono i troppi tentativi SSH falliti dalla Cina e dall'Indonesia da un dispositivo remoto esterno:

Oppure, supponiamo che l'istanza del server nel VPC, per policy, non sia mai una destinazione di accesso remoto. Supponiamo inoltre che questo computer abbia subito un accesso remoto a causa di una modifica errata nella politica delle regole del firewall. La funzionalità di modellazione di entità rileverà e segnalerà questa attività ("Accesso remoto insolito") quasi in tempo reale e indicherà la chiamata API specifica di AWS CloudTrail, Monitoraggio di Azure o GCP Stackdriver Logging (inclusi nome utente, data e ora, tra gli altri dettagli ), che ha portato alla modifica della regola ITU. E poi queste informazioni possono essere inviate a SIEM per l'analisi.

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

La modellazione delle entità è una forma unica di automazione della sicurezza in grado di scoprire un problema precedentemente sconosciuto relativo a persone, processi o tecnologia. Ad esempio, consente di rilevare, tra le altre cose, problemi di sicurezza come:

Qualcuno ha scoperto una backdoor nel software che utilizziamo?
C'è qualche software o dispositivo di terze parti nel nostro cloud?
L'utente autorizzato sta abusando dei privilegi?
Si è verificato un errore di configurazione che ha consentito l'accesso remoto o un altro utilizzo non intenzionale delle risorse?
C'è una perdita di dati dai nostri server?
Qualcuno stava cercando di connettersi con noi da una posizione geografica atipica?
Il nostro cloud è infetto da codice dannoso?

Un evento di sicurezza delle informazioni rilevato può essere inviato sotto forma di ticket corrispondente a Slack, Cisco Spark, al sistema di gestione degli incidenti PagerDuty e anche inviato a vari SIEM, tra cui Splunk o ELK. Per riassumere, possiamo dire che se la tua azienda utilizza una strategia multi-cloud e non si limita a un solo fornitore di servizi cloud e alle funzionalità di monitoraggio della sicurezza delle informazioni sopra descritte, l'utilizzo di Cisco Stealthwatch Cloud è una buona opzione per ottenere un set unificato di monitoraggio funzionalità per i principali attori del cloud: Amazon, Microsoft e Google. La cosa più interessante è che se si confrontano i prezzi di Stealthwatch Cloud con licenze avanzate per il monitoraggio della sicurezza delle informazioni in AWS, Azure o GCP, potrebbe risultare che la soluzione Cisco sarà ancora più economica delle funzionalità integrate di Amazon, Microsoft e soluzioni Google. È paradossale, ma è vero. E quanto più cloud e le relative funzionalità verranno utilizzati, tanto più evidente sarà il vantaggio di una soluzione consolidata.

Inoltre, Stealthwatch Cloud può monitorare i cloud privati distribuiti nella tua organizzazione, ad esempio, basati su contenitori Kubernetes o monitorando i flussi Netflow o il traffico di rete ricevuto tramite mirroring nelle apparecchiature di rete (anche di produzione nazionale), dati AD o server DNS e così via. Tutti questi dati verranno arricchiti con le informazioni di Threat Intelligence raccolte da Cisco Talos, il più grande gruppo non governativo al mondo di ricercatori sulle minacce alla sicurezza informatica.

Ciò ti consente di implementare un sistema di monitoraggio unificato per i cloud pubblici e ibridi che la tua azienda potrebbe utilizzare. Le informazioni raccolte possono quindi essere analizzate utilizzando le funzionalità integrate di Stealthwatch Cloud o inviate al tuo SIEM (Splunk, ELK, SumoLogic e molti altri sono supportati per impostazione predefinita).

Con questo completeremo la prima parte dell'articolo, in cui ho esaminato gli strumenti integrati ed esterni per il monitoraggio della sicurezza delle informazioni delle piattaforme IaaS/PaaS, che ci consentono di rilevare e rispondere rapidamente agli incidenti che si verificano negli ambienti cloud che la nostra azienda ha scelto. Nella seconda parte continueremo l'argomento ed esamineremo le opzioni per monitorare le piattaforme SaaS utilizzando l'esempio di Salesforce e Dropbox, e proveremo anche a riassumere e mettere tutto insieme creando un sistema unificato di monitoraggio della sicurezza delle informazioni per diversi fornitori di servizi cloud.

Fonte: habr.com

Monitoraggio della sicurezza nel cloud