🥇 Monitorování zabezpečení cloudu

Přesun dat a aplikací do cloudu představuje novou výzvu pro podnikové SOC, které nejsou vždy připraveny monitorovat infrastrukturu jiných lidí. Podle Netoskope využívá průměrný podnik (zřejmě v USA) 1246 22 různých cloudových služeb, což je o 1246 % více než před rokem. 175 cloudových služeb!!! 170 z nich se týká HR služeb, 110 marketingu, 76 oblasti komunikace a 700 financí a CRM. Cisco využívá „pouze“ XNUMX externích cloudových služeb. Tak jsem z těchto čísel trochu zmatený. Ale každopádně problém není v nich, ale v tom, že cloud začíná poměrně aktivně využívat stále větší počet firem, které by chtěly mít stejné možnosti pro monitorování cloudové infrastruktury jako ve vlastní síti. A tento trend roste – podle podle Americké účetní komory Do roku 2023 bude ve Spojených státech uzavřeno 1200 6250 datových center (XNUMX XNUMX již uzavřeno). Ale přechod na cloud není jen „přesuňme naše servery k externímu poskytovateli“. Nová IT architektura, nový software, nové procesy, nová omezení... To vše přináší výrazné změny do práce nejen IT, ale i informační bezpečnosti. A pokud se poskytovatelé naučili nějak vypořádat se zajištěním bezpečnosti cloudu samotného (doporučení je naštěstí spousta), pak s monitorováním bezpečnosti informací v cloudu, zejména na platformách SaaS, jsou značné potíže, o kterých si budeme povídat.

Řekněme, že vaše společnost přesunula část své infrastruktury do cloudu... Stop. Ne tímto způsobem. Pokud byla infrastruktura převedena a vy teprve teď přemýšlíte, jak ji budete sledovat, pak jste již prohráli. Pokud to není Amazon, Google nebo Microsoft (a pak s výhradami), pravděpodobně nebudete mít moc možností sledovat svá data a aplikace. Je dobré, když máte příležitost pracovat s protokoly. Někdy budou k dispozici data událostí zabezpečení, ale nebudete k nim mít přístup. Například Office 365. Pokud máte nejlevnější licenci E1, pak pro vás bezpečnostní akce nejsou vůbec dostupné. Pokud máte licenci E3, jsou vaše data uložena pouze 90 dní a pouze pokud máte licenci E5, je doba trvání protokolů k dispozici po dobu jednoho roku (to má však také své vlastní nuance související s nutností odděleně vyžádejte si od podpory Microsoftu řadu funkcí pro práci s protokoly). Mimochodem, licence E3 je z hlediska monitorovacích funkcí mnohem slabší než firemní Exchange. K dosažení stejné úrovně potřebujete licenci E5 nebo další licenci Advanced Compliance, což může vyžadovat další peníze, které nebyly započítány do vašeho finančního modelu pro přechod na cloudovou infrastrukturu. A to je jen jeden příklad podcenění problémů souvisejících s monitorováním bezpečnosti informací v cloudu. V tomto článku, aniž bych předstíral úplnost, chci upozornit na některé nuance, které je třeba vzít v úvahu při výběru poskytovatele cloudu z hlediska bezpečnosti. A na konci článku bude uveden kontrolní seznam, který stojí za to vyplnit, než uvážíme, že problém monitorování bezpečnosti cloudových informací je vyřešen.

Existuje několik typických problémů, které vedou k incidentům v cloudových prostředích, na které služby informační bezpečnosti nemají čas reagovat nebo je vůbec nevidí:

Protokoly zabezpečení neexistují. To je poměrně běžná situace, zejména mezi začínajícími hráči na trhu cloudových řešení. Ale neměli byste se jich hned vzdávat. Malí hráči, zejména domácí, jsou citlivější na požadavky zákazníků a mohou rychle implementovat některé požadované funkce změnou schválené roadmapy pro své produkty. Ano, nebude to obdoba GuardDuty od Amazonu nebo modulu „Proaktivní ochrana“ od Bitrixu, ale alespoň něco.
Informační bezpečnost neví, kde jsou protokoly uloženy, nebo k nim není přístup. Zde je nutné vstoupit do jednání s poskytovatelem cloudových služeb – třeba takové informace poskytne, pokud považuje klienta za důležitého. Ale obecně není příliš dobré, když je přístup k protokolům poskytován „na základě zvláštního rozhodnutí“.
Stává se také, že poskytovatel cloudu má protokoly, ale poskytují omezené monitorování a záznam událostí, které nestačí k detekci všech incidentů. Můžete například dostávat pouze protokoly změn na webu nebo protokoly pokusů o ověření uživatele, nikoli však jiné události, jako je síťový provoz, což před vámi skryje celou vrstvu událostí, které charakterizují pokusy o hacknutí vaší cloudové infrastruktury.
Existují protokoly, ale přístup k nim je obtížné automatizovat, což nutí je sledovat nikoli nepřetržitě, ale podle plánu. A pokud nemůžete protokoly stahovat automaticky, pak stahování protokolů například ve formátu Excel (jako u řady tuzemských poskytovatelů cloudových řešení) může dokonce vést k neochotě podnikové služby informační bezpečnosti se s nimi šťourat.
Žádné sledování protokolu. To je možná nejnejasnější důvod výskytu incidentů informační bezpečnosti v cloudových prostředích. Zdá se, že existují protokoly a je možné k nim automatizovat přístup, ale nikdo to nedělá. Proč?

Sdílený cloudový bezpečnostní koncept

Přechod na cloud je vždy hledáním rovnováhy mezi touhou udržet kontrolu nad infrastrukturou a jejím převedením do povolanějších rukou poskytovatele cloudu, který se na její údržbu specializuje. A v oblasti cloudové bezpečnosti je třeba hledat i tuto rovnováhu. Navíc v závislosti na použitém modelu poskytování cloudových služeb (IaaS, PaaS, SaaS) se tento zůstatek bude neustále lišit. V každém případě musíme připomenout, že všichni poskytovatelé cloudu dnes dodržují tzv. sdílenou odpovědnost a sdílený model zabezpečení informací. Za některé věci je zodpovědný cloud a za jiné je zodpovědný klient, který umístí svá data, své aplikace, své virtuální stroje a další zdroje do cloudu. Bylo by neuvážené očekávat, že přechodem do cloudu přesuneme veškerou odpovědnost na poskytovatele. Při přechodu do cloudu je ale také nerozumné budovat veškeré zabezpečení sami. Je vyžadována rovnováha, která bude záviset na mnoha faktorech: - strategie řízení rizik, model hrozeb, bezpečnostní mechanismy dostupné poskytovateli cloudu, legislativa atd.

Například klasifikace dat hostovaných v cloudu je vždy odpovědností zákazníka. Poskytovatel cloudu nebo externí poskytovatel služeb mu může pomoci pouze s nástroji, které pomohou označit data v cloudu, identifikovat porušení, odstranit data porušující zákon nebo je zamaskovat tím či oním způsobem. Na druhou stranu za fyzické zabezpečení je vždy odpovědný poskytovatel cloudu, který nemůže sdílet s klienty. Ale vše, co je mezi daty a fyzickou infrastrukturou, je právě předmětem diskuse v tomto článku. Například dostupnost cloudu je v kompetenci poskytovatele a nastavení pravidel firewallu nebo povolení šifrování je v kompetenci klienta. V tomto článku se pokusíme podívat na to, jaké mechanismy monitorování bezpečnosti informací dnes poskytují různí populární poskytovatelé cloudu v Rusku, jaké jsou vlastnosti jejich použití a kdy se vyplatí poohlédnout se po externích překryvných řešeních (například Cisco E- mail Security), které rozšiřují možnosti vašeho cloudu z hlediska kybernetické bezpečnosti. V některých případech, zejména pokud se řídíte multicloudovou strategií, vám nezbude nic jiného, než použít externí řešení pro monitorování bezpečnosti informací v několika cloudových prostředích najednou (například Cisco CloudLock nebo Cisco Stealthwatch Cloud). V některých případech si uvědomíte, že poskytovatel cloudu, kterého jste si vybrali (nebo vám byl uložen), nenabízí vůbec žádné možnosti monitorování bezpečnosti informací. To je nepříjemné, ale také ne málo, protože vám to umožňuje adekvátně posoudit úroveň rizika spojeného s prací s tímto cloudem.

Životní cyklus monitorování zabezpečení cloudu

Chcete-li sledovat zabezpečení cloudů, které používáte, máte pouze tři možnosti:

spoléhat na nástroje poskytované vaším poskytovatelem cloudu,
používat řešení od třetích stran, která budou monitorovat platformy IaaS, PaaS nebo SaaS, které používáte,
vybudovat si vlastní cloudovou monitorovací infrastrukturu (pouze pro platformy IaaS/PaaS).

Podívejme se, jaké funkce má každá z těchto možností. Nejprve však musíme porozumět obecnému rámci, který bude použit při monitorování cloudových platforem. Zdůraznil bych 6 hlavních součástí procesu monitorování bezpečnosti informací v cloudu:

Příprava infrastruktury. Určení potřebných aplikací a infrastruktury pro sběr událostí důležitých pro bezpečnost informací do úložiště.
Sbírka. V této fázi jsou bezpečnostní události agregovány z různých zdrojů pro následný přenos za účelem zpracování, uložení a analýzy.
Léčba. V této fázi jsou data transformována a obohacena pro usnadnění následné analýzy.
Úložný prostor. Tato komponenta je zodpovědná za krátkodobé a dlouhodobé uchovávání shromážděných zpracovaných a nezpracovaných dat.
Analýza. V této fázi máte možnost detekovat incidenty a reagovat na ně automaticky nebo ručně.
Hlášení. Tato fáze pomáhá formulovat klíčové ukazatele pro zainteresované strany (management, auditory, poskytovatele cloudu, klienty atd.), které nám pomáhají činit určitá rozhodnutí, například změnit poskytovatele nebo posílit informační bezpečnost.

Pochopení těchto komponent vám umožní v budoucnu rychle se rozhodnout, co si můžete od svého poskytovatele vzít a co budete muset udělat sami nebo se zapojením externích konzultantů.

Vestavěné cloudové služby

Již jsem psal výše, že mnoho cloudových služeb dnes neposkytuje žádné možnosti monitorování bezpečnosti informací. Obecně se tématu informační bezpečnosti příliš nevěnují. Například jedna z oblíbených ruských služeb pro zasílání hlášení státním úřadům přes internet (její název konkrétně uvádět nebudu). Celá sekce o zabezpečení této služby se točí kolem použití certifikovaného CIPF. Nejinak je tomu u sekce informační bezpečnosti další tuzemské cloudové služby pro správu elektronických dokumentů. Hovoří o certifikátech veřejného klíče, certifikované kryptografii, odstraňování zranitelností webu, ochraně před DDoS útoky, používání firewallů, zálohování a dokonce i pravidelných auditech bezpečnosti informací. Ale není tam ani slovo o monitorování, ani o možnosti získat přístup k událostem zabezpečení informací, které mohou být pro klienty tohoto poskytovatele služeb zajímavé.

Obecně lze říci, že podle toho, jak poskytovatel cloudu popisuje problémy zabezpečení informací na svých webových stránkách a ve své dokumentaci, můžete pochopit, jak vážně tento problém bere. Pokud si například přečtete manuály k produktům „My Office“, o bezpečnosti není ani slovo, ale v dokumentaci k samostatnému produktu „My Office. KS3“, určený k ochraně před neoprávněným přístupem, je zde obvyklý výpis bodů 17. řádu FSTEC, který „My Office.KS3“ implementuje, ale není popsáno, jak to implementuje a hlavně jak integrovat tyto mechanismy s podnikovou informační bezpečností. Možná taková dokumentace existuje, ale nenašel jsem ji ve veřejné doméně na webu „My Office“. I když možná jen nemám přístup k těmto tajným informacím?...

U Bitrixu je situace mnohem lepší. Dokumentace popisuje formáty protokolů událostí a zajímavé je také protokol narušení, který obsahuje události související s potenciálními hrozbami pro cloudovou platformu. Odtud můžete vytáhnout IP, jméno uživatele nebo hosta, zdroj události, čas, User Agent, typ události atd. Pravda, s těmito událostmi můžete pracovat buď z ovládacího panelu samotného cloudu, nebo nahrát data ve formátu MS Excel. Nyní je obtížné automatizovat práci s protokoly Bitrix a část práce budete muset dělat ručně (nahrát zprávu a načíst ji do vašeho SIEM). Ale když si připomeneme, že ještě relativně nedávno taková možnost neexistovala, tak je to velký pokrok. Zároveň bych rád poznamenal, že mnoho zahraničních poskytovatelů cloudu nabízí podobnou funkcionalitu „pro začátečníky“ – buď se na protokoly podíváte očima přes ovládací panel, nebo si data nahrajete sami (většina však nahrává data ve formátu . csv, ne Excel).

Bez ohledu na možnost no-logs vám poskytovatelé cloudu obvykle nabízejí tři možnosti monitorování bezpečnostních událostí – dashboardy, nahrávání dat a přístup k API. Zdá se, že první za vás vyřeší mnoho problémů, ale není to tak úplně pravda – pokud máte několik časopisů, musíte přepínat mezi obrazovkami, které je zobrazují, a ztrácíte tak celkový obraz. Kromě toho je nepravděpodobné, že vám poskytovatel cloudu poskytne možnost korelovat bezpečnostní události a obecně je analyzovat z hlediska zabezpečení (obvykle máte co do činění s nezpracovanými daty, kterým musíte sami rozumět). Existují výjimky a o nich si povíme dále. Nakonec stojí za to se zeptat, jaké události zaznamenává váš poskytovatel cloudu, v jakém formátu a jak odpovídají vašemu procesu monitorování zabezpečení informací? Například identifikace a autentizace uživatelů a hostů. Stejný Bitrix umožňuje na základě těchto událostí zaznamenat datum a čas události, jméno uživatele nebo hosta (pokud máte modul „Web Analytics“), objekt, ke kterému se přistupuje a další prvky typické pro webovou stránku. . Firemní služby zabezpečení informací však mohou potřebovat informace o tom, zda uživatel přistupoval ke cloudu z důvěryhodného zařízení (například v podnikové síti tento úkol implementuje Cisco ISE). A co takový jednoduchý úkol, jako je funkce geo-IP, která pomůže určit, zda byl uživatelský účet cloudové služby odcizen? A i když vám to poskytovatel cloudu poskytne, nestačí to. Stejný Cisco CloudLock neanalyzuje pouze geolokaci, ale využívá k tomu strojové učení a analyzuje historická data pro každého uživatele a sleduje různé anomálie v pokusech o identifikaci a autentizaci. Podobnou funkcionalitu má pouze MS Azure (pokud máte příslušné předplatné).

Je tu další úskalí – jelikož je pro mnohé cloudové poskytovatele monitoring bezpečnosti informací novým tématem, kterým se teprve začínají zabývat, neustále ve svých řešeních něco mění. Dnes mají jednu verzi API, zítra druhou, pozítří třetí. I na to je potřeba být připraven. Totéž platí pro funkcionalitu, která se může změnit, což je nutné vzít v úvahu ve vašem systému monitorování bezpečnosti informací. Například Amazon zpočátku měl samostatné služby monitorování cloudových událostí – AWS CloudTrail a AWS CloudWatch. Poté se objevila samostatná služba pro sledování událostí zabezpečení informací - AWS GuardDuty. Po nějaké době Amazon spustil nový systém správy, Amazon Security Hub, který zahrnuje analýzu dat přijatých od GuardDuty, Amazon Inspector, Amazon Macie a několika dalších. Dalším příkladem je nástroj pro integraci protokolů Azure se SIEM – AzLog. Aktivně jej využívalo mnoho prodejců SIEM, až v roce 2018 Microsoft oznámil ukončení jeho vývoje a podpory, což čelilo mnoha klientům, kteří tento nástroj používali, s problémem (o tom, jak byl vyřešen, si povíme později).

Proto pečlivě sledujte všechny monitorovací funkce, které vám váš poskytovatel cloudu nabízí. Nebo se spolehněte na externí poskytovatele řešení, kteří budou fungovat jako prostředníci mezi vaším SOC a cloudem, který chcete monitorovat. Ano, bude to dražší (i když ne vždy), ale veškerou zodpovědnost přesunete na bedra někoho jiného. Nebo ne všechno?... Připomeňme si koncept sdílené bezpečnosti a pochopme, že nemůžeme nic posunout – budeme muset nezávisle pochopit, jak různí poskytovatelé cloudu zajišťují monitorování informační bezpečnosti vašich dat, aplikací, virtuálních strojů a dalších zdrojů hostované v cloudu. A začneme tím, co Amazon v tomto díle nabízí.

Příklad: Monitorování bezpečnosti informací v IaaS založené na AWS

Ano, ano, chápu, že Amazon není tím nejlepším příkladem vzhledem k tomu, že se jedná o americkou službu a lze ji zablokovat v rámci boje proti extremismu a šíření informací v Rusku zakázané. Ale v této publikaci bych jen rád ukázal, jak se různé cloudové platformy liší ve svých možnostech monitorování bezpečnosti informací a na co byste si měli dát pozor při přenosu vašich klíčových procesů do cloudu z bezpečnostního hlediska. No, pokud se někteří z ruských vývojářů cloudových řešení naučí něco užitečného pro sebe, bude to skvělé.

První věc, kterou je třeba říci, je, že Amazon není neproniknutelná pevnost. Jeho klientům se pravidelně stávají různé incidenty. Z Deep Root Analytics byla například ukradena jména, adresy, data narození a telefonní čísla 198 milionů voličů. Izraelská společnost Nice Systems ukradla 14 milionů záznamů předplatitelů Verizonu. Vestavěné možnosti AWS vám však umožňují detekovat širokou škálu incidentů. Například:

dopad na infrastrukturu (DDoS)
kompromitace uzlu (injekce příkazu)
kompromitace účtu a neoprávněný přístup
nesprávná konfigurace a zranitelnosti
nezabezpečená rozhraní a API.

Tento rozpor je způsoben tím, že jak jsme zjistili výše, za bezpečnost zákaznických dat je odpovědný sám zákazník. A pokud se neobtěžoval zapnout ochranné mechanismy a nezapnul monitorovací nástroje, tak se o incidentu dozví až z médií nebo od svých klientů.

K identifikaci incidentů můžete využít širokou škálu různých monitorovacích služeb vyvinutých společností Amazon (ačkoli tyto jsou často doplněny externími nástroji, jako je osquery). Takže v AWS jsou všechny akce uživatele monitorovány bez ohledu na to, jak jsou prováděny - prostřednictvím konzoly pro správu, příkazového řádku, SDK nebo jiných služeb AWS. Všechny záznamy o aktivitě každého účtu AWS (včetně uživatelského jména, akce, služby, parametrů aktivity a výsledku) a využití API jsou dostupné prostřednictvím AWS CloudTrail. Tyto události (například přihlášení do konzole AWS IAM) můžete zobrazit z konzoly CloudTrail, analyzovat je pomocí Amazon Athena nebo je „outsourcovat“ externím řešením, jako je Splunk, AlienVault atd. Samotné protokoly AWS CloudTrail jsou umístěny ve vašem kbelíku AWS S3.

Dvě další služby AWS poskytují řadu dalších důležitých monitorovacích funkcí. Za prvé, Amazon CloudWatch je služba monitorování zdrojů a aplikací AWS, která mimo jiné umožňuje identifikovat různé anomálie ve vašem cloudu. Všechny vestavěné služby AWS, jako je Amazon Elastic Compute Cloud (servery), Amazon Relational Database Service (databáze), Amazon Elastic MapReduce (analýza dat) a 30 dalších služeb Amazonu, používají k ukládání svých protokolů službu Amazon CloudWatch. Vývojáři mohou využít otevřené API od Amazon CloudWatch k přidání funkce monitorování protokolů do vlastních aplikací a služeb, což jim umožní rozšířit rozsah analýzy událostí v kontextu zabezpečení.

Za druhé, služba VPC Flow Logs vám umožňuje analyzovat síťový provoz odeslaný nebo přijatý vašimi servery AWS (externě nebo interně), stejně jako mezi mikroslužbami. Když kterýkoli z vašich zdrojů AWS VPC interaguje se sítí, protokoly toku VPC zaznamenají podrobnosti o síťovém provozu, včetně rozhraní zdrojové a cílové sítě, a také IP adresy, porty, protokol, počet bajtů a počet paketů. viděl. Ti, kteří mají zkušenosti se zabezpečením místní sítě, to poznají jako analogii vláken Síťový tok, které mohou být vytvořeny pomocí přepínačů, směrovačů a podnikových firewallů. Tyto protokoly jsou důležité pro účely monitorování bezpečnosti informací, protože na rozdíl od událostí o akcích uživatelů a aplikací vám také umožňují nezmeškat síťové interakce v prostředí virtuálního privátního cloudu AWS.

Stručně řečeno, tyto tři služby AWS – AWS CloudTrail, Amazon CloudWatch a VPC Flow Logs – společně poskytují poměrně silný přehled o používání vašeho účtu, chování uživatelů, správě infrastruktury, aktivitě aplikací a služeb a síťové aktivitě. Mohou být například použity k detekci následujících anomálií:

Pokusy o skenování webu, hledání zadních vrátek, hledání zranitelností prostřednictvím shluků „chyb 404“.
Injekční útoky (například SQL injection) prostřednictvím shluků „500 chyb“.
Známé útočné nástroje jsou sqlmap, nikto, w3af, nmap atd. pomocí analýzy pole User Agent.

Amazon Web Services také vyvinul další služby pro účely kybernetické bezpečnosti, které vám umožňují řešit mnoho dalších problémů. Například AWS má vestavěnou službu pro auditování zásad a konfigurací – AWS Config. Tato služba poskytuje nepřetržitý audit vašich prostředků AWS a jejich konfigurací. Vezměme si jednoduchý příklad: Řekněme, že se chcete ujistit, že uživatelská hesla jsou zakázána na všech vašich serverech a že přístup je možný pouze na základě certifikátů. AWS Config usnadňuje kontrolu tohoto pro všechny vaše servery. Existují další zásady, které lze použít na vaše cloudové servery: „Žádný server nemůže používat port 22“, „Pravidla brány firewall mohou měnit pouze správci“ nebo „Pouze uživatel Ivashko může vytvářet nové uživatelské účty a může to dělat pouze v úterý. " V létě 2016 byla služba AWS Config rozšířena o automatizaci detekce porušení vyvinutých zásad. Pravidla konfigurace AWS jsou v podstatě nepřetržité konfigurační požadavky pro služby Amazon, které používáte, které generují události, pokud jsou porušeny odpovídající zásady. Například namísto pravidelného spouštění dotazů AWS Config za účelem ověření, že jsou všechny disky na virtuálním serveru šifrovány, lze pravidla AWS Config použít k průběžné kontrole disků serveru, aby bylo zajištěno, že je tato podmínka splněna. A co je nejdůležitější, v kontextu této publikace jakákoli porušení generují události, které může vaše služba zabezpečení informací analyzovat.

AWS má také svůj ekvivalent k tradičním řešením podnikové informační bezpečnosti, která také generují bezpečnostní události, které můžete a měli byste analyzovat:

Detekce narušení - AWS GuardDuty
Řízení úniku informací - AWS Macie
EDR (i když trochu zvláštně mluví o koncových bodech v cloudu) - AWS Cloudwatch + open source osquery nebo řešení GRR
Analýza Netflow - AWS Cloudwatch + AWS VPC Flow
Analýza DNS - AWS Cloudwatch + AWS Route53
AD - AWS Directory Service
Správa účtu - AWS IAM
SSO - AWS SSO
bezpečnostní analýza - AWS Inspector
správa konfigurace - AWS Config
WAF - AWS WAF.

Nebudu podrobně popisovat všechny služby Amazonu, které mohou být užitečné v rámci informační bezpečnosti. Hlavní věc je pochopit, že všechny mohou generovat události, které můžeme a měli bychom analyzovat v kontextu informační bezpečnosti, a to s využitím jak vestavěných schopností samotného Amazonu, tak externích řešení, například SIEM, která mohou přeneste bezpečnostní události do svého monitorovacího centra a analyzujte je tam spolu s událostmi z jiných cloudových služeb nebo z interní infrastruktury, perimetru nebo mobilních zařízení.

V každém případě vše začíná u zdrojů dat, které vám poskytují události týkající se bezpečnosti informací. Tyto zdroje zahrnují, ale nejsou omezeny na:

CloudTrail – využití API a uživatelské akce
Důvěryhodný poradce – kontrola zabezpečení proti osvědčeným postupům
Config - inventarizace a konfigurace účtů a nastavení služeb
VPC Flow Logs - připojení k virtuálním rozhraním
IAM - služba identifikace a autentizace
ELB Access Logs - Load Balancer
Inspektor - zranitelnosti aplikace
S3 - úložiště souborů
CloudWatch – aktivita aplikací
SNS je oznamovací služba.

Amazon, přestože nabízí takovou škálu zdrojů událostí a nástrojů pro jejich generování, je velmi omezený ve své schopnosti analyzovat shromážděná data v kontextu informační bezpečnosti. Budete muset nezávisle studovat dostupné protokoly a hledat v nich relevantní ukazatele kompromisu. AWS Security Hub, který Amazon nedávno spustil, má za cíl tento problém vyřešit tím, že se stane cloudovým SIEM pro AWS. Zatím je ale pouze na začátku své cesty a je limitován jak počtem zdrojů, se kterými pracuje, tak dalšími omezeními stanovenými architekturou a předplatnými samotného Amazonu.

Příklad: Monitorování zabezpečení informací v IaaS založené na Azure

Nechci se pouštět do dlouhé debaty o tom, který ze tří cloudových poskytovatelů (Amazon, Microsoft nebo Google) je lepší (zejména proto, že každý z nich má stále svá specifická specifika a je vhodný pro řešení vlastních problémů); Zaměřme se na možnosti monitorování bezpečnosti informací, které tito hráči poskytují. Nutno přiznat, že Amazon AWS byl v tomto segmentu jedním z prvních, a proto ve svých funkcích informační bezpečnosti pokročil nejdále (ačkoli mnozí přiznávají, že jsou obtížně použitelné). To ale neznamená, že budeme ignorovat příležitosti, které nám Microsoft a Google poskytují.

Produkty Microsoftu se vždy vyznačovaly svou „otevřeností“ a v Azure je situace podobná. Pokud například AWS a GCP vždy vycházejí z konceptu „co není povoleno, je zakázáno“, pak Azure má přesně opačný přístup. Například při vytváření virtuální sítě v cloudu a virtuálního stroje v ní jsou všechny porty a protokoly ve výchozím nastavení otevřené a povolené. Budete tedy muset vynaložit trochu více úsilí na prvotní nastavení systému řízení přístupu v cloudu od Microsoftu. A to na vás klade také přísnější požadavky, pokud jde o sledování aktivity v cloudu Azure.

AWS má zvláštnost spojenou s tím, že když monitorujete své virtuální zdroje, pokud se nacházejí v různých regionech, pak máte potíže s kombinováním všech událostí a jejich jednotnou analýzou, k jejichž odstranění je třeba se uchýlit k různým trikům, jako je např. Vytvořte si vlastní kód pro AWS Lambda, který bude přenášet události mezi regiony. Azure tento problém nemá – jeho mechanismus Activity Log sleduje veškerou aktivitu v celé organizaci bez omezení. Totéž platí pro AWS Security Hub, který nedávno vyvinul Amazon za účelem konsolidace mnoha bezpečnostních funkcí v rámci jednoho bezpečnostního centra, ale pouze v rámci svého regionu, který však pro Rusko není relevantní. Azure má vlastní Centrum zabezpečení, které není vázáno regionálními omezeními a poskytuje přístup ke všem funkcím zabezpečení cloudové platformy. Navíc pro různé místní týmy může poskytnout vlastní sadu ochranných schopností, včetně jimi spravovaných bezpečnostních událostí. AWS Security Hub je stále na cestě stát se podobným Azure Security Center. Ale stojí za to přidat mouchu - z Azure můžete vymáčknout spoustu toho, co bylo dříve popsáno v AWS, ale nejpohodlněji to lze provést pouze pro Azure AD, Azure Monitor a Azure Security Center. Všechny ostatní bezpečnostní mechanismy Azure, včetně analýzy událostí zabezpečení, zatím nejsou spravovány tím nejpohodlnějším způsobem. Problém částečně řeší API, které prostupuje všemi službami Microsoft Azure, ale to od vás bude vyžadovat další úsilí k integraci vašeho cloudu s vaším SOC a přítomnost kvalifikovaných specialistů (ve skutečnosti stejně jako u jakéhokoli jiného SIEM, který pracuje s cloudová API). Některé SIEM, o kterých bude řeč později, již Azure podporují a dokážou zautomatizovat úlohu jeho monitorování, ale má to i svá úskalí – ne všechny dokážou sbírat všechny protokoly, které Azure má.

Sběr a monitorování událostí v Azure je zajištěno pomocí služby Azure Monitor, která je hlavním nástrojem pro shromažďování, ukládání a analýzu dat v cloudu Microsoftu a jeho prostředcích – úložištích Git, kontejnerech, virtuálních počítačích, aplikacích atd. Všechna data shromážděná Azure Monitorem jsou rozdělena do dvou kategorií – metriky, shromažďované v reálném čase a popisující klíčové ukazatele výkonu cloudu Azure, a protokoly, obsahující data uspořádaná do záznamů charakterizujících určité aspekty aktivity prostředků a služeb Azure. Kromě toho může služba Azure Monitor pomocí rozhraní Data Collector API shromažďovat data z libovolného zdroje REST a vytvářet své vlastní scénáře monitorování.

Zde je několik zdrojů událostí zabezpečení, které vám Azure nabízí a ke kterým máte přístup prostřednictvím Azure Portal, CLI, PowerShell nebo REST API (a některé pouze přes Azure Monitor/Insight API):

Protokoly aktivit – tento protokol odpovídá na klasické otázky „kdo“, „co“ a „kdy“ týkající se jakékoli operace zápisu (PUT, POST, DELETE) do cloudových zdrojů. Události související s přístupem ke čtení (GET) nejsou v tomto protokolu zahrnuty, stejně jako řada dalších.
Diagnostické protokoly – obsahuje údaje o operacích s konkrétním zdrojem zahrnutým ve vašem předplatném.
Reportování Azure AD – obsahuje jak aktivitu uživatele, tak aktivitu systému související se správou skupin a uživatelů.
Windows Event Log a Linux Syslog – obsahuje události z virtuálních strojů hostovaných v cloudu.
Metriky – obsahuje telemetrii o výkonu a stavu vašich cloudových služeb a prostředků. Měřeno každou minutu a uloženo. do 30 dnů.
Network Security Group Flow Logs – obsahuje data o událostech zabezpečení sítě shromážděná pomocí služby Network Watcher a monitorování zdrojů na úrovni sítě.
Záznamy úložiště – obsahuje události související s přístupem k úložišti.

Pro monitorování můžete použít externí SIEM nebo vestavěný Azure Monitor a jeho rozšíření. O systémech správy událostí zabezpečení informací si povíme později, ale nyní se podívejme, co nám samotný Azure nabízí pro analýzu dat v kontextu zabezpečení. Hlavní obrazovkou pro vše, co souvisí se zabezpečením v Azure Monitor, je Log Analytics Security and Audit Dashboard (bezplatná verze podporuje omezené množství úložiště událostí jen na jeden týden). Tento řídicí panel je rozdělen do 5 hlavních oblastí, které vizualizují souhrnné statistiky toho, co se děje v cloudovém prostředí, které používáte:

Bezpečnostní domény – klíčové kvantitativní ukazatele související s informační bezpečností – počet incidentů, počet kompromitovaných uzlů, neopravených uzlů, události zabezpečení sítě atd.
Pozoruhodné problémy – zobrazuje počet a důležitost aktivních problémů se zabezpečením informací
Detekce – zobrazuje vzory útoků použitých proti vám
Threat Intelligence – zobrazuje geografické informace o externích uzlech, které na vás útočí
Běžné bezpečnostní dotazy – typické dotazy, které vám pomohou lépe sledovat zabezpečení informací.

Mezi rozšíření Azure Monitor patří Azure Key Vault (ochrana kryptografických klíčů v cloudu), Malware Assessment (analýza ochrany před škodlivým kódem na virtuálních počítačích), Azure Application Gateway Analytics (analýza mimo jiné protokolů cloudového firewallu) atd. . Tyto nástroje, obohacené o určitá pravidla pro zpracování událostí, umožňují vizualizovat různé aspekty činnosti cloudových služeb včetně zabezpečení a identifikovat určité odchylky od provozu. Jak se však často stává, jakákoli další funkce vyžaduje odpovídající placené předplatné, které od vás bude vyžadovat odpovídající finanční investice, které musíte naplánovat předem.

Azure má řadu integrovaných funkcí monitorování hrozeb, které jsou integrované do Azure AD, Azure Monitor a Azure Security Center. Mezi nimi například detekce interakce virtuálních strojů se známými škodlivými IP (vzhledem k přítomnosti integrace se službami Threat Intelligence od společnosti Microsoft), detekce malwaru v cloudové infrastruktuře přijímáním alarmů z virtuálních strojů hostovaných v cloudu, heslo hádání útoků “ na virtuální stroje, zranitelnosti v konfiguraci systému identifikace uživatelů, přihlašování do systému z anonymizátorů nebo infikovaných uzlů, úniky účtů, přihlašování do systému z neobvyklých míst atd. Azure je dnes jedním z mála poskytovatelů cloudu, který vám nabízí vestavěné funkce Threat Intelligence pro obohacení shromážděných událostí zabezpečení informací.

Jak bylo uvedeno výše, bezpečnostní funkce a v důsledku toho jím generované bezpečnostní události nejsou dostupné všem uživatelům stejně, ale vyžadují určité předplatné, které zahrnuje funkcionalitu, kterou potřebujete, které generuje příslušné události pro monitorování bezpečnosti informací. Například některé funkce popsané v předchozím odstavci pro sledování anomálií v účtech jsou dostupné pouze v prémiové licenci P2 pro službu Azure AD. Bez něj budete, stejně jako v případě AWS, muset analyzovat shromážděné bezpečnostní události „ručně“. A také v závislosti na typu licence Azure AD nebudou všechny události dostupné pro analýzu.

Na Azure Portal můžete spravovat jak vyhledávací dotazy pro protokoly, které vás zajímají, tak nastavit řídicí panely pro vizualizaci klíčových indikátorů zabezpečení informací. Kromě toho si zde můžete vybrat rozšíření Azure Monitor, která vám umožní rozšířit funkčnost protokolů Azure Monitor a získat hlubší analýzu událostí z hlediska zabezpečení.

Pokud potřebujete nejen možnost práce s protokoly, ale komplexní bezpečnostní centrum pro vaši cloudovou platformu Azure včetně správy zásad zabezpečení informací, pak můžete mluvit o nutnosti pracovat s Azure Security Center, jehož většina užitečných funkcí jsou k dispozici za nějaké peníze, například detekce hrozeb, monitorování mimo Azure, hodnocení souladu atd. (v bezplatné verzi máte přístup pouze k bezpečnostnímu hodnocení a doporučením pro odstranění zjištěných problémů). Konsoliduje všechny bezpečnostní problémy na jednom místě. Ve skutečnosti můžeme mluvit o vyšší úrovni zabezpečení informací, než vám poskytuje Azure Monitor, protože v tomto případě jsou data shromážděná v celé vaší cloudové továrně obohacena o mnoho zdrojů, jako je Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX. , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) a Microsoft Security Response Center (MSRC), na kterých jsou umístěny různé sofistikované algoritmy strojového učení a behaviorální analýzy, což by mělo v konečném důsledku zlepšit efektivitu detekce a reakce na hrozby. .

Azure má také svůj vlastní SIEM - objevil se na začátku roku 2019. To je Azure Sentinel, který se spoléhá na data z Azure Monitor a umí se také integrovat. externí bezpečnostní řešení (například NGFW nebo WAF), jejichž seznam se neustále rozrůstá. Navíc díky integraci rozhraní Microsoft Graph Security API máte možnost připojit své vlastní zdroje Threat Intelligence k Sentinelu, což obohacuje možnosti analýzy incidentů ve vašem cloudu Azure. Lze namítnout, že Azure Sentinel je první „nativní“ SIEM, který se objevil od poskytovatelů cloudu (stejné Splunk nebo ELK, které mohou být hostovány v cloudu, například AWS, stále nejsou vyvinuty tradičními poskytovateli cloudových služeb). Azure Sentinel a Security Center by se mohly nazývat SOC pro cloud Azure a mohly by se na ně omezit (s určitými výhradami), pokud byste již neměli žádnou infrastrukturu a přenesli jste všechny své výpočetní prostředky do cloudu a byl by to cloud Azure od společnosti Microsoft.

Ale protože vestavěné možnosti Azure (i když máte předplatné Sentinelu) často nestačí pro účely monitorování zabezpečení informací a integrace tohoto procesu s jinými zdroji bezpečnostních událostí (jak cloudových, tak interních), existuje potřeba exportovat shromážděná data do externích systémů, do kterých může být SIEM. A to jak pomocí API, tak pomocí speciálních rozšíření, která jsou zatím oficiálně dostupná pouze pro následující SIEM - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight a ELK. Donedávna bylo takových SIEM více, ale od 1. června 2019 přestal Microsoft podporovat Azure Log Integration Tool (AzLog), který na úsvitu existence Azure a při absenci běžné standardizace práce s logy (Azure Monitor ještě ani neexistoval) usnadnil integraci externího SIEM s cloudem Microsoftu. Nyní se situace změnila a Microsoft doporučuje platformu Azure Event Hub jako hlavní integrační nástroj pro ostatní SIEM. Mnozí již takovou integraci implementovali, ale pozor – nemusí zachytit všechny protokoly Azure, ale jen některé (podívejte se do dokumentace k vašemu SIEM).

Na závěr krátké exkurze do Azure bych rád dal obecné doporučení ohledně této cloudové služby – než něco řeknete o funkcích monitorování zabezpečení informací v Azure, měli byste je velmi pečlivě nakonfigurovat a otestovat, že fungují tak, jak je napsáno v dokumentaci a jak vám konzultanti řekli Microsoft (a mohou mít různé názory na funkčnost funkcí Azure). Pokud máte finanční prostředky, můžete z Azure vymáčknout spoustu užitečných informací, pokud jde o monitorování zabezpečení informací. Pokud jsou vaše zdroje omezené, pak se stejně jako v případě AWS budete muset spoléhat pouze na vlastní síly a nezpracovaná data, která vám Azure Monitor poskytuje. A nezapomeňte, že mnoho monitorovacích funkcí stojí peníze a je lepší se předem seznámit s cenovou politikou. Zdarma můžete například ukládat 31 dní dat až do maximálního objemu 5 GB na zákazníka – překročení těchto hodnot bude vyžadovat vyplacení dalších peněz (přibližně 2 USD+ za uložení každého dalšího GB od zákazníka a 0,1 USD za uložení 1 GB každý další měsíc). Práce s aplikační telemetrií a metrikami může také vyžadovat další finanční prostředky, stejně jako práce s upozorněními a upozorněními (určitý limit je k dispozici zdarma, což nemusí vašim potřebám stačit).

Příklad: Monitorování zabezpečení informací v IaaS založené na Google Cloud Platform

Google Cloud Platform vypadá ve srovnání s AWS a Azure jako mladík, ale je to částečně dobré. Na rozdíl od AWS, které své schopnosti, včetně bezpečnostních, zvyšovalo postupně, s problémy s centralizací; GCP, stejně jako Azure, je mnohem lépe spravován centrálně, což snižuje chyby a dobu implementace v celém podniku. Z bezpečnostního hlediska je GCP kupodivu mezi AWS a Azure. Má také jedinou registraci na akci pro celou organizaci, ale ta je neúplná. Některé funkce jsou stále v beta režimu, ale postupně by měl být tento nedostatek odstraněn a GCP se stane vyzrálejší platformou z hlediska monitorování bezpečnosti informací.

Hlavním nástrojem pro protokolování událostí v GCP je Stackdriver Logging (obdoba Azure Monitor), který umožňuje shromažďovat události napříč celou vaší cloudovou infrastrukturou (a také z AWS). Z hlediska zabezpečení v GCP má každá organizace, projekt nebo složka čtyři protokoly:

Admin Activity – obsahuje všechny události související s administrativním přístupem, například vytvoření virtuálního stroje, změna přístupových práv atd. Tento protokol je vždy zapsán bez ohledu na vaše přání a uchovává jeho data po dobu 400 dní.
Data Access - obsahuje všechny události související s prací s daty uživateli cloudu (vytváření, úpravy, čtení atd.). Ve výchozím nastavení se tento protokol nezapisuje, protože jeho objem se velmi rychle zvětšuje. Z tohoto důvodu je jeho trvanlivost pouze 30 dní. Navíc v tomto časopise není napsáno vše. Nezapisují se do něj například události související se zdroji, které jsou veřejně přístupné všem uživatelům nebo které jsou přístupné bez přihlášení do GCP.
Systémová událost – obsahuje systémové události nesouvisející s uživateli nebo akce administrátora, který mění konfiguraci cloudových prostředků. Je vždy zapsán a uložen po dobu 400 dnů.
Access Transparency je jedinečný příklad protokolu, který zachycuje všechny akce zaměstnanců Google (ale zatím ne pro všechny služby GCP), kteří přistupují k vaší infrastruktuře v rámci svých pracovních povinností. Tento protokol je uchováván po dobu 400 dní a není dostupný každému klientovi GCP, ale pouze při splnění řady podmínek (buď podpora na úrovni Gold nebo Platinum, nebo přítomnost 4 rolí určitého typu v rámci firemní podpory). Podobná funkce je dostupná také například v Office 365 - Lockbox.

Příklad protokolu: Průhlednost přístupu

{
 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"
}

Přístup k těmto protokolům je možný několika způsoby (v podstatě stejným způsobem jako dříve probrané Azure a AWS) – prostřednictvím rozhraní Log Viewer, prostřednictvím API, Google Cloud SDK nebo prostřednictvím stránky Aktivita vašeho projektu, pro který zajímají se o události. Stejným způsobem je lze exportovat do externích řešení pro další analýzu. To se provádí exportem protokolů do úložiště BigQuery nebo Cloud Pub/Sub.

Kromě Stackdriver Logging nabízí platforma GCP také funkcionalitu Stackdriver Monitoring, která umožňuje sledovat klíčové metriky (výkon, MTBF, celkový stav atd.) cloudových služeb a aplikací. Zpracovaná a vizualizovaná data mohou usnadnit vyhledávání problémů ve vaší cloudové infrastruktuře, a to i v kontextu zabezpečení. Je však třeba poznamenat, že tato funkce nebude v kontextu informační bezpečnosti příliš bohatá, protože dnes GCP nemá analog stejného AWS GuardDuty a nemůže identifikovat špatné mezi všemi registrovanými událostmi (Google vyvinul Event Threat Detection, ale stále se vyvíjí ve verzi beta a je příliš brzy na to mluvit o jeho užitečnosti). Stackdriver Monitoring by mohl být použit jako systém pro odhalování anomálií, které by byly následně zkoumány za účelem nalezení příčin jejich vzniku. Ale vzhledem k nedostatku kvalifikovaného personálu v oblasti informační bezpečnosti GCP na trhu se tento úkol v současnosti zdá obtížný.

Rovněž stojí za to uvést seznam některých modulů zabezpečení informací, které lze použít ve vašem cloudu GCP a které jsou podobné tomu, co nabízí AWS:

Cloud Security Command Center je analogem AWS Security Hub a Azure Security Center.
Cloud DLP – Automatické zjišťování a úpravy (např. maskování) dat hostovaných v cloudu pomocí více než 90 předdefinovaných zásad klasifikace.
Cloud Scanner je skener známých zranitelností (XSS, Flash Injection, neopravené knihovny atd.) v App Engine, Compute Engine a Google Kubernetes.
Cloud IAM – Řízení přístupu ke všem zdrojům GCP.
Cloud Identity – Spravujte účty uživatelů, zařízení a aplikací GCP z jediné konzoly.
Cloud HSM - ochrana kryptografických klíčů.
Cloud Key Management Service – správa kryptografických klíčů v GCP.
Kontrola služeb VPC – Vytvořte zabezpečený obvod kolem svých zdrojů GCP, abyste je chránili před úniky.
Titan Security Key - ochrana proti phishingu.

Mnohé z těchto modulů generují bezpečnostní události, které lze odeslat do úložiště BigQuery za účelem analýzy nebo exportu do jiných systémů, včetně SIEM. Jak již bylo zmíněno výše, GCP je aktivně se rozvíjející platforma a Google nyní pro svou platformu vyvíjí řadu nových modulů zabezpečení informací. Mezi ně patří Event Threat Detection (nyní dostupná v beta verzi), která skenuje protokoly Stackdriver a hledá stopy neautorizované aktivity (obdoba GuardDuty v AWS), nebo Policy Intelligence (dostupná v alpha), která vám umožní vyvíjet inteligentní zásady pro přístup ke zdrojům GCP.

Udělal jsem krátký přehled vestavěných možností monitorování v populárních cloudových platformách. Máte ale specialisty, kteří jsou schopni pracovat s „surovými“ protokoly poskytovatelů IaaS (ne každý je připraven koupit pokročilé možnosti AWS nebo Azure nebo Google)? Mnozí navíc znají přísloví „důvěřuj, ale prověřuj“, které je v oblasti bezpečnosti pravdivější než kdy jindy. Jak moc důvěřujete vestavěným schopnostem poskytovatele cloudu, který vám zasílá události zabezpečení informací? Jak moc se vůbec zaměřují na informační bezpečnost?

Někdy se vyplatí podívat se na překryvná řešení pro monitorování cloudové infrastruktury, která mohou doplnit vestavěné cloudové zabezpečení, a někdy jsou taková řešení jedinou možností, jak získat přehled o zabezpečení vašich dat a aplikací hostovaných v cloudu. Kromě toho jsou jednoduše pohodlnější, protože přebírají všechny úkoly analýzy nezbytných protokolů generovaných různými cloudovými službami od různých poskytovatelů cloudu. Příkladem takového překryvného řešení je Cisco Stealthwatch Cloud, který je zaměřen na jediný úkol – sledování anomálií zabezpečení informací v cloudových prostředích, mezi které patří nejen Amazon AWS, Microsoft Azure a Google Cloud Platform, ale také privátní cloudy.

Příklad: Monitorování bezpečnosti informací pomocí Stealthwatch Cloud

AWS poskytuje flexibilní výpočetní platformu, ale tato flexibilita usnadňuje společnostem dělat chyby, které vedou k bezpečnostním problémům. A model sdílené informační bezpečnosti k tomu jen přispívá. Spuštěný software v cloudu s neznámými zranitelnostmi (se známými dokáže bojovat např. AWS Inspector nebo GCP Cloud Scanner), slabými hesly, nesprávnými konfiguracemi, zasvěcenci atd. A to vše se odráží v chování cloudových zdrojů, které může monitorovat Cisco Stealthwatch Cloud, což je systém pro monitorování bezpečnosti informací a detekci útoků. veřejné a soukromé cloudy.

Jednou z klíčových funkcí Cisco Stealthwatch Cloud je schopnost modelovat entity. S ním můžete vytvořit softwarový model (tedy simulaci téměř v reálném čase) každého z vašich cloudových zdrojů (nezáleží na tom, zda jde o AWS, Azure, GCP nebo něco jiného). Mohou zahrnovat servery a uživatele a také typy prostředků specifické pro vaše cloudové prostředí, jako jsou skupiny zabezpečení a skupiny s automatickým škálováním. Tyto modely využívají jako vstup strukturované datové toky poskytované cloudovými službami. Například pro AWS by to byly protokoly VPC Flow, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda a AWS IAM. Modelování entit automaticky zjišťuje roli a chování kteréhokoli z vašich zdrojů (můžete mluvit o profilování veškeré cloudové aktivity). Tyto role zahrnují mobilní zařízení Android nebo Apple, server Citrix PVS, server RDP, poštovní bránu, klienta VoIP, terminálový server, řadič domény atd. Průběžně pak sleduje jejich chování, aby zjistil, kdy dochází k rizikovému nebo bezpečnost ohrožujícímu chování. Můžete identifikovat hádání hesel, DDoS útoky, úniky dat, nelegální vzdálený přístup, aktivitu škodlivého kódu, skenování zranitelnosti a další hrozby. Takto například vypadá detekce pokusu o vzdálený přístup ze země netypické pro vaši organizaci (Jižní Korea) do clusteru Kubernetes přes SSH:

A takto vypadá údajný únik informací z databáze Postgress do země, se kterou jsme se dosud nesetkali s interakcí:

Konečně takto vypadá příliš mnoho neúspěšných pokusů o SSH z Číny a Indonésie z externího vzdáleného zařízení:

Nebo předpokládejme, že instance serveru ve VPC podle zásad nikdy nebude cílem vzdáleného přihlášení. Dále předpokládejme, že tento počítač zaznamenal vzdálené přihlášení kvůli chybné změně zásad pravidel brány firewall. Funkce Entity Modeling zjistí a nahlásí tuto aktivitu („Neobvyklý vzdálený přístup“) téměř v reálném čase a ukáže na konkrétní volání AWS CloudTrail, Azure Monitor nebo GCP Stackdriver Logging API (včetně uživatelského jména, data a času a dalších podrobností). ), což vedlo ke změně pravidla ITU. A pak mohou být tyto informace odeslány do SIEM k analýze.

Podobné funkce jsou implementovány pro jakékoli cloudové prostředí podporované Cisco Stealthwatch Cloud:

Modelování entit je jedinečná forma automatizace zabezpečení, která dokáže odhalit dříve neznámý problém s vašimi lidmi, procesy nebo technologií. Umožňuje například odhalit mimo jiné bezpečnostní problémy, jako jsou:

Objevil někdo zadní vrátka v softwaru, který používáme?
Je v našem cloudu nějaký software nebo zařízení třetí strany?
Zneužívá oprávněný uživatel oprávnění?
Došlo k chybě konfigurace, která umožňovala vzdálený přístup nebo jiné nezamýšlené použití zdrojů?
Dochází k úniku dat z našich serverů?
Pokoušel se k nám někdo připojit z atypické geografické polohy?
Je náš cloud napaden škodlivým kódem?

Zjištěná událost zabezpečení informací může být odeslána ve formě odpovídajícího tiketu do Slack, Cisco Spark, systému správy incidentů PagerDuty a také do různých SIEM, včetně Splunk nebo ELK. Abychom to shrnuli, můžeme říci, že pokud vaše společnost používá multi-cloudovou strategii a není omezena na žádného poskytovatele cloudu, možnosti monitorování bezpečnosti informací popsané výše, pak je použití Cisco Stealthwatch Cloud dobrou možností, jak získat jednotnou sadu monitorování. schopnosti pro přední cloudové hráče – Amazon, Microsoft a Google. Nejzajímavější na tom je, že pokud porovnáte ceny za Stealthwatch Cloud s pokročilými licencemi pro monitorování informační bezpečnosti v AWS, Azure nebo GCP, může se ukázat, že řešení Cisco bude ještě levnější než vestavěné možnosti Amazon, Microsoft a řešení Google. Je to paradoxní, ale je to tak. A čím více cloudů a jejich možností využijete, tím zjevnější bude výhoda konsolidovaného řešení.

Kromě toho může Stealthwatch Cloud monitorovat privátní cloudy nasazené ve vaší organizaci, například na základě kontejnerů Kubernetes nebo sledováním toků Netflow nebo síťového provozu přijatého prostřednictvím zrcadlení v síťových zařízeních (i v tuzemsku), dat AD nebo DNS serverů a tak dále. Všechna tato data budou obohacena o informace Threat Intelligence shromážděné společností Cisco Talos, největší světovou nevládní skupinou výzkumníků kybernetických hrozeb.

To vám umožní implementovat jednotný monitorovací systém pro veřejné i hybridní cloudy, které může vaše společnost používat. Shromážděné informace pak mohou být analyzovány pomocí vestavěných funkcí Stealthwatch Cloud nebo odeslány do vašeho SIEM (ve výchozím nastavení jsou podporovány Splunk, ELK, SumoLogic a několik dalších).

Tímto dokončíme první část článku, ve které jsem zhodnotil vestavěné a externí nástroje pro monitorování informační bezpečnosti platforem IaaS/PaaS, které nám umožňují rychle detekovat a reagovat na incidenty vyskytující se v cloudových prostředích, které si náš podnik vybral. Ve druhé části budeme v tématu pokračovat a podíváme se na možnosti monitorování SaaS platforem na příkladu Salesforce a Dropbox a také se pokusíme vše shrnout a dát dohromady vytvořením jednotného systému monitorování bezpečnosti informací pro různé poskytovatele cloudu.

Zdroj: www.habr.com

Cloud Security Monitoring