🥇Monitorování bezpečnosti cloudů

Přenos dat a aplikací do cloudů představuje novou výzvu pro podnikové SOCy, které nejsou vždy připraveny monitorovat cizí infrastrukturu. Podle údajů Netoskpu průměrná firma (pravděpodobně v USA) používá 1246 různých cloudových služeb, což je o 22 % více než před rokem. 1246 cloudových služeb!!! 175 z nich se týká HR služeb, 170 je spojených s marketingem, 110 v oblasti komunikací a 76 ve financích a CRM. V Cisco se používá „pouze“ 700 externích cloudových služeb. Proto mě tyto čísla poněkud znepokojují. Ale v každém případě problém není v nich, ale v tom, že cloudové služby se stále častěji začínají používat stále větším počtem firem, které by chtěly mít stejné možnosti monitorování cloudové infrastruktury jako u vlastní sítě. A tento trend roste — podle údajů amerického úřadu pro kontrolu do roku 2023 v USA plánují uzavřít 1200 datových center (6250 už bylo uzavřeno). Ale přechod na cloud není jen o tom „přejděme k našemu serveru k externímu poskytovateli“. Nová IT architektura, nový software, nové procesy, nová omezení… To vše zásadně mění fungování nejen IT, ale i bezpečnostní architektury. A i když poskytovatelé se naučili jakžtakž zajistit bezpečnost samotného cloudu (naštěstí je dost doporučení), tak s cloudovým monitorováním bezpečnosti, zejména na SaaS platformách, se potýkají s významnými obtížemi, o kterých budeme hovořit.

Představme si, že vaše společnost přesunula část své infrastruktury do cloudu… Stop. Ne tak. Pokud byla infrastruktura přesunuta a vy teprve nyní uvažujete o tom, jak ji budete monitorovat, už jste prohráli. Pokud to není Amazon, Google nebo Microsoft (a to ještě s výhradami), pravděpodobně nebudete mít mnoho možností pro monitorování vašich dat a aplikací. Dobré je, když vám umožní pracovat s protokoly. Někdy budou dostupná data o bezpečnostních událostech, ale nebudete mít k nim přístup. Například Office 365. Pokud máte nejlevnější licenci E1, nemáte přístup k bezpečnostním událostem vůbec. Při licenci E3 jsou data uchovávána pouze po dobu 90 dnů a pouze při licenci E5 je doba uchovávání protokolů dostupná po dobu jednoho roku (pravda, také zde existují specifické nuance vyžadující samostatnou žádost o řadu funkcí souvisejících s protokoly na podpoře Microsoft). Mimochodem, licence E3 má mnohem slabší funkce monitorování než firemní Exchange. Abychom dosáhli stejné úrovně, potřebujete licenci E5 nebo dodatečnou licenci Advanced Compliance, které mohou vyžadovat dodatečné náklady, které nebyly zahrnuty do vaší finanční modelu přechodu na cloudovou infrastrukturu. A to je pouze jeden příklad podcenění otázek souvisejících s monitorováním bezpečnosti v cloudech. V tomto článku, aniž bych měl ambice na úplnost, chci upozornit na některé nuance, které je třeba zvážit při výběru poskytovatele cloudu z hlediska bezpečnosti. Na konci článku bude uveden kontrolní seznam, který byste měli splnit, než uznáte, že otázka monitorování bezpečnosti cloudu je vyřešena.

Můžeme identifikovat několik typických problémů, které vedou k incidentům v cloudových prostředích, na které bezpečnostní služby nedokážou reagovat nebo je vůbec nevidí:

Bezpečnostní protokoly neexistují. To je poměrně běžná situace, zvláště u začínajících hráčů na trhu cloudových řešení. Ale okamžitě na ně také není potřeba rezignovat. Malí hráči, zejména domácí, jsou citlivější na požadavky zákazníků a mohou rychle implementovat nějaké žádané funkce, když změní schválený plán vývoje pro své produkty. Ano, nebude to ekvivalent GuardDuty od Amazonu nebo modulu „Proaktivní ochrany“ od Bitrixu, ale alespoň něco.
IB neví, kde se uchovávají logy nebo k nim nemá přístup. Je nutné vyjednávat s poskytovatelem cloudových služeb — možná vám poskytne tyto informace, pokud vás považuje za významného klienta. Obecně vzato, není dobré, když je přístup k logům poskytován „na zvláštní žádost“.
Někdy se může stát, že logy má cloudový poskytovatel, ale poskytují omezené monitorování a zaznamenávání událostí, které jsou nedostatečné pro odhalení všech incidentů. Například vám mohou poskytnout pouze logy změn na webu nebo logy pokusů o autentizaci uživatelů, ale jiné události, například síťový provoz, nezveřejňují, což skryje před vámi celou řadu událostí, charakterizujících pokusy o prolomení vaší cloudové infrastruktury.
Logy existují, ale přístup k nim je těžké automatizovat, což způsobuje, že je nesledujeme nepřetržitě, ale podle plánu. A pokud navíc není možné logy stahovat automaticky, může export logů, například ve formátu Excel (jak to dělá řada domácích poskytovatelů cloudových řešení), vést k tomu, že se jimi korporátní informační bezpečnostní služba nebude chtít zabývat.
Není monitorování logů. To je pravděpodobně nejméně pochopitelný důvod vzniku incidentů informační bezpečnosti v cloudových prostředích. Logy sice existují a přístup k nim lze automatizovat, ale nikdo to nedělá. Proč?

Koncept sdílené bezpečnosti cloudu

Přechod do cloudu je vždy hledáním rovnováhy mezi touhou udržet kontrolu nad infrastrukturou a jejím předáním do profesionálnějších rukou poskytovatele cloudu, který se specializuje na její údržbu. A v oblasti bezpečnosti cloudových prostředí je také třeba tuto rovnováhu hledat. O to více, že v závislosti na použitém modelu poskytování cloudových služeb (IaaS, PaaS, SaaS) se tato rovnováha neustále mění. V každém případě je třeba mít na paměti, že všichni poskytovatelé cloudu dnes dodržují takzvaný model sdílené odpovědnosti a sdílené informační bezpečnosti. Na něčem odpovídá cloud, na něčem odpovídá klient, který umístil do cloudu svá data, své aplikace, své virtuální stroje a další zdroje. Bylo by nezodpovědné myslet si, že přechodem do cloudu přeneseme veškerou odpovědnost na poskytovatele. Ale také není rozumné budovat veškerou bezpečnost samostatně při přechodu do cloudu. Je třeba najít rovnováhu, která bude záviset na celé řadě faktorů: — strategií řízení rizik, modelech hrozeb, dostupných ochranných mechanismech poskytovatele cloudu, legislativě a dalších.

Například klasifikace dat umístěných v cloudu je vždy odpovědností zákazníka. Poskytovatel cloudu nebo externí dodavatel mu může pouze pomoci s nástroji, které mu budou pomáhat označovat data v cloudu, odhalovat porušování, odstraňovat data porušující legislativu nebo je maskovat různými metodami. Na druhou stranu fyzická bezpečnost je vždy odpovědností poskytovatele cloudu, kterou nemůže sdílet se zákazníky. Vše, co se nachází mezi daty a fyzickou infrastrukturu, je právě tématem této článku. Například dostupnost cloudu je odpovědností poskytovatele, zatímco nastavení pravidel MSE nebo aktivace šifrování je již odpovědností klienta. V tomto článku se pokusíme podívat, jaké mechanismy monitorování bezpečnosti dnes nabízejí různí populární poskytovatelé cloudu v Rusku, jaké jsou zvláštnosti jejich použití a kdy stojí za to podívat se na externí monitorovací řešení (například Cisco E-mail Security), které rozšiřují možnosti vašeho cloudu v oblasti kybernetické bezpečnosti. V mnoha případech, zejména při sledování strategie multi-cloud, nebudete mít jinou možnost než použít externí řešení pro monitorování bezpečnosti ve více cloudových prostředích (například Cisco CloudLock nebo Cisco Stealthwatch Cloud). A v některých případech zjistíte, že vybraný (nebo vnucený) poskytovatel cloudu vůbec nenabízí žádné možnosti monitorování bezpečnosti. To je nepříjemné, ale také to je důležité, protože to umožňuje adekvátně posoudit úroveň rizika spojeného s prací s tímto cloudem.

Životní cyklus monitorování bezpečnosti cloudu

Abyste mohli monitorovat bezpečnost používaných cloudů, máte k dispozici jen tři možnosti:

spoléhat se na nástroje poskytované vaším poskytovatelem cloudu,
využít řešení třetích stran, která budou monitorovat vaše IaaS, PaaS nebo SaaS platformy,
vytvořit vlastní monitoring cloudových prostředí (pouze pro IaaS/PaaS platformy).

Pojďme se podívat na vlastnosti každé z těchto možností. Nejprve je však nezbytné pochopit obecný model, který bude použit při monitorování cloudových platforem. Zde bych vyzdvihl 6 hlavních komponent procesu monitorování informační bezpečnosti v cloudu:

Příprava infrastruktury. Určení potřebných aplikací a infrastruktury pro sběr událostí důležitých pro informační bezpečnost ve skladu.
Sběr. V této fázi jsou bezpečnostní události agregovány z různých zdrojů pro jejich následný přenos k zpracování, ukládání a analýze.
Zpracování. V této fázi jsou data transformována a obohacena pro usnadnění jejich následné analýzy.
Uložení. Tato komponenta zodpovídá za krátkodobé a dlouhodobé ukládání shromážděných zpracovaných a "surových" dat.
Analýza. V této fázi máte možnost odhalit incidenty a reagovat na ně automaticky či manuálně.
Reportování. Tento krok pomáhá vytvářet pro zainteresované strany (vedení, auditory, cloudového poskytovatele, klienty atd.) klíčové ukazatele, které nám pomáhají přijímat různá rozhodnutí, například změna poskytovatele nebo posílení informační bezpečnosti.

Porozumění těmto komponentům vám umožní rychle určit, co můžete přenést na svého poskytovatele a co si budete muset řešit sami nebo s pomocí externích poradců.

Vestavěné možnosti cloudových služeb.

Už jsem zmínil, že mnoho cloudových služeb dnes nenabízí žádné možnosti pro monitorování informační bezpečnosti. Vůbec se tématu informační bezpečnosti nevěnují příliš velkou pozornost. Například jeden z populárních ruských servisů pro zasílání zpráv státním orgánům přes Internet (nebudu zmiňovat jeho jméno). Celá část o zabezpečení této služby se soustředí na používání certifikovaných kryptografických prostředků. Část o informační bezpečnosti jiného domácího cloudového servisu pro elektronický oběh dokumentů je oproti tomu mnohem obsáhlejší. Zmiňuje certifikáty veřejných klíčů, certifikovanou kryptografii, odstranění webových zranitelností, ochranu proti DDoS útokům, použití bezpečnostních informačních systémů, zálohování a dokonce pravidelný audit informační bezpečnosti. Ale o monitorování ani slovo, stejně jako o možnosti získání přístupu k událostem informační bezpečnosti, které mohou být pro zákazníky této služby zajímavé.

Obecně lze podle toho, jak cloudový poskytovatel na svých stránkách a v dokumentaci popisuje otázky informační bezpečnosti, pochopit, jak vážně tento problém bere. Například pokud si přečtete příručky k produktům "Můj kancelář", nenajdete tam vůbec žádné slovo o bezpečnosti, a v dokumentaci k samostatnému produktu "Můj kancelář. KS3", určenému k ochraně před neoprávněným přístupem, je to běžné výčty bodů 17. nařízení FSTEK, které "Můj kancelář.KS3" splňuje, ale není popsáno, jak to plní a, co je nejdůležitější, jak integrovat tyto mechanismy s korporátní informační bezpečností. Možná taková dokumentace existuje, ale v veřejném přístupu na stránkách "Můj kancelář" jsem ji nenašel. I když možná prostě nemám přístup k těmto tajným informacím?

Situace u Bitrixu je mnohem lepší. V dokumentaci jsou popsány formáty protokolů událostí a, co je zajímavé, také protokol narušení, který obsahuje události spojené s potenciálními hrozbami pro cloudovou platformu. Odtud můžete získat IP, jméno uživatele nebo hosta, zdroj události, čas, User Agent, typ události atd. Pravda, práce s těmito událostmi je možná buď z řídicího panelu samotného cloudu, nebo můžete exportovat data ve formátu MS Excel. Automatizovat práci s protokoly Bitrix je nyní obtížné a část práce budete muset vykonat ručně (export zprávy a její nahrání do vašeho SIEM). Ale pokud si vzpomenete, že ještě relativně nedávno taková možnost neexistovala, je to velký pokrok. Chci také upozornit na to, že i mnozí zahraniční cloudoví poskytovatelé nabízejí podobné funkce „pro začátečníky“ – buď se podívejte do protokolů očima přes řídicí panel, nebo si exportujte data k sobě (pravda, většina exportuje data ve formátu .csv, nikoli Excel).

Pokud nebudeme zvažovat možnost absence logů, obvykle poskytovatelé cloudových služeb nabízejí tři možnosti pro monitorování bezpečnostních událostí — dashboardy, export dat a přístup k nim prostřednictvím rozhraní API. První varianta zdánlivě vyřeší mnoho problémů za vás, ale není to tak docela pravda; při vícero logách se musíte přepínat mezi obrazovkami, které je zobrazují, a ztrácíte celkový přehled. Kromě toho vám pravděpodobně cloudový poskytovatel neposkytne možnost korelace bezpečnostních událostí a jejich analýzy z hlediska bezpečnosti (obvykle se zabýváte syrovými daty, se kterými se musíte vypořádat sami). Jsou však výjimky a o těch budeme hovořit dále. Nakonec by stálo za to zjistit, jaké události zaznamenává váš cloudový poskytovatel, v jakém formátu a jak dobře odpovídají vašemu procesu monitorování informační bezpečnosti. Například identifikace a autentifikace uživatelů a hostů. Ten samý Bitrix vám umožňuje na základě těchto událostí zaznamenat datum a čas dané události, jméno uživatele nebo hosta (pokud je k dispozici modul „Webová analytika“), objekt, ke kterému byl přístup, a další typické prvky webové stránky. Ale korporátní služby informační bezpečnosti mohou potřebovat informace o tom, zda se uživatel přihlásil do cloudu z důvěryhodného zařízení (například v firemní síti tuto úlohu realizuje Cisco ISE). A taková jednoduchá úloha, jako je funkce geo-IP, která pomůže zjistit, zda nebyl účet uživatele cloudové služby odcizen? A i kdyby vám to cloudový poskytovatel poskytl, je to nedostatečné. Ten samý Cisco CloudLock nejen analyzuje geolokaci, ale také k tomu využívá strojové učení a analyzuje historická data pro každého uživatele a sleduje různé anomálie v pokusech o identifikaci a autentifikaci. Podobnou funkcionalitu má pouze MS Azure (při vhodném předplatném).

Existuje ještě jedna komplikace – protože monitorování bezpečnosti informací (IB) je pro mnoho cloudových providerů nová téma, se kterým teprve začínají, neustále mění svá řešení. Dnes mají jednu verzi API, zítra jinou, pozítří třetí. Na to se také musíte připravit. Totéž platí pro funkčnost, která se může měnit, což je třeba zohlednit ve vašem monitorovacím systému IB. Například, u Amazonu byly nejprve samostatné služby pro monitorování událostí v cloudu – AWS CloudTrail a AWS CloudWatch. Pak se objevila samostatná služba pro monitorování událostí specificky pro IB – AWS GuardDuty. Po nějaké době Amazon spustil nový systém správy Amazon Security Hub, který zahrnuje analýzu dat získaných od GuardDuty, Amazon Inspector, Amazon Macie a dalších. Další příklad – nástroj pro integraci logů Azure se SIEM – AzLog. Aktivně ho používalo mnoho dodavatelů SIEM, dokud v roce 2018 Microsoft neoznámil ukončení jeho vývoje a podpory, což postavilo mnoho klientů, kteří tento nástroj používali, před problém (jak se to vyřešilo, budeme hovořit dále).

Proto pečlivě sledujte všechny funkce monitorování, které vám nabízí váš cloudový poskytovatel. Nebo se svěřte externím dodavatelům řešení, kteří budou sloužit jako zprostředkovatelé mezi vaším SOC a cloudem, který chcete monitorovat. Ano, bude to dražší (i když ne vždy), ale tak přenesete veškerou odpovědnost na cizí ramena. Nebo ne úplně? Připomeňme si koncept sdílené bezpečnosti a uvědomíme si, že nic nemůžeme úplně delegovat – budeme se muset sami vyznat v tom, jak různí cloudoví poskytovatelé zajišťují monitorování IB vašich dat, aplikací, virtuálních strojů a dalších zdrojů umístěných v cloudu. A začneme tím, co nabízí Amazon v této oblasti.

Příklad: Monitorování IB v IaaS na bázi AWS

Ano, rozumím, že Amazon není tím nejlepším příkladem, protože je to americká služba a může být blokována v rámci boje proti extremismu a šíření zakázaných informací na území Ruska. Ale v této publikaci bych chtěl ukázat, jak se různé cloudové platformy liší v možnostech monitorování kybernetické bezpečnosti a na co si dát pozor při přenosu svých klíčových procesů do cloudu z hlediska bezpečnosti. A pokud někteří z ruských vývojářů cloudových řešení objeví něco užitečného, bude to skvělé.

Nejprve je třeba říci, že Amazon není nedobytná pevnost. Jeho klienti pravidelně čelí různým incidentům. Například Deep Root Analytics ukradli jména, adresy, data narození a telefonní čísla 198 milionů voličů. Izraelské společnosti Nice Systems ukradli 14 milionů záznamů o abonentech Verizon. Přitom vestavěné možnosti AWS umožňují detekci širokého spektra incidentů. Například:

útoky na infrastrukturu (DDoS)
kompromitace uzlu (vkládání příkazů)
kompromitace účtu a neoprávněný přístup
špatná konfigurace a zranitelnosti
nechráněné rozhraní a API.

Toto nesoulad je způsoben tím, že za bezpečnost dat zákazníka, jak jsme zjistili výše, odpovídá sám zákazník. A pokud se nepostaral o aktivaci ochranných mechanismů a nepoužil monitorovací nástroje, o incidentu se dozví pouze z médií nebo od svých klientů.

K identifikaci incidentů lze použít široké spektrum různých monitorovacích služeb, které vyvinula společnost Amazon (ačkoliv jsou často doplněny externími nástroji, jako je osquery). V AWS se sledují všechny akce uživatelů, bez ohledu na to, jak jsou prováděny — prostřednictvím ovládacího panelu, příkazového řádku, SDK nebo jiných služeb AWS. Všechny záznamy o akcích každého účtu AWS (včetně uživatelského jména, akce, služby, parametrů aktivity a jejích výsledků) a používání API jsou k dispozici prostřednictvím služby AWS CloudTrail. Můžete si prohlížet tyto události (například přihlášení do ovládacího panelu AWS IAM) z ovládacího panelu CloudTrail, analyzovat je pomocí Amazon Athena nebo je

předat" externím řešením, jako je Splunk, AlienVault, atd. Samotné protokoly AWS CloudTrail jsou umístěny ve vašem úložišti AWS S3.

Za druhé, služba VPC Flow Logs umožňuje analyzovat síťový provoz, který je odesílán nebo přijímán vašimi servery AWS (zvenčí nebo zevnitř), stejně jako mezi mikroservisy. Když některý z vašich zdrojů AWS VPC komunikuje se sítí, služba VPC Flow Logs zaznamenává informace o síťovém provozu, včetně síťového rozhraní zdroje a cíle, jakož i IP adresy, porty, protokol, počet bajtů a počet paketů, které jste viděli. Ti, kteří mají zkušenosti s lokální síťovou bezpečností, uznávají, že to je analogní proudům, NetFlow, které mohou být vytvářeny switchemi, směrovači a podnikovými firewally. Tyto protokoly jsou důležité pro sledování kybernetické bezpečnosti, protože na rozdíl od událostí týkajících se činnosti uživatelů a aplikací umožňují sledovat také síťovou interakci ve virtuálním privátním cloudovém prostředí AWS.

Tyto tři služby AWS — AWS CloudTrail, Amazon CloudWatch a VPC Flow Logs — tedy dohromady poskytují dostatečně efektivní přehled o používání vašeho účtu, chování uživatelů, správě infrastruktury, aktivitě aplikací a služeb, a také o síťové aktivitě. Například pomocí nich lze detekovat následující anomálie:

Pokusy o skenování webu, hledání zadních dveří, vyhledávání zranitelností prostřednictvím skoků "404 chyb."
Útoky typu injection (například SQL injection) prostřednictvím skoků "500 chyb."
Známé nástroje pro útoky jako sqlmap, nikto, w3af, nmap a další prostřednictvím analýzy pole User Agent.

Amazon Web Services pro účely kybernetické bezpečnosti vyvinul také další služby, které umožňují řešení mnoha dalších úkolů. Například v AWS je integrovaná služba pro audit politik a konfigurací — AWS Config. Tato služba zajišťuje nepřetržitý audit vašich prostředků AWS a jejich konfigurací. Uvažujme o jednoduchém příkladu: předpokládejme, že chcete zajistit, že uživatelská hesla jsou deaktivována na všech vašich serverech a přístup je možný pouze na základě certifikátů. AWS Config umožňuje snadno to ověřit pro všechny vaše servery. Existují i další politiky, které mohou být aplikovány na vaše cloudové servery: „Žádný server nesmí používat port 22“, „Pouze administrátoři mohou měnit pravidla firewallu“ 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í nastavených politik. AWS Config Rules jsou v podstatě nepřetržité dotazy konfigurace služeb Amazon, které generují události v případě porušení příslušných politik. Například namísto toho, abyste pravidelně prováděli dotazy pomocí AWS Config na kontrolu, že všechny disky virtuálního serveru jsou šifrované, AWS Config Rules mohou být použity k trvalé kontrole disků serverů na splnění této podmínky. A co je nejdůležitější, v kontextu tohoto příspěvku, jakékoli porušení generuje události, které mohou být analyzovány vaší službou IT bezpečnosti.

V AWS existují i vlastní ekvivalenty tradičním podnikových řešením pro IT bezpečnost, které také generují bezpečnostní události, které můžete a měli byste analyzovat:

detekce vniknutí — AWS GuardDuty
kontrola úniků informací — AWS Macie
EDR (i když mluvit o koncových zařízeních v cloudu je trochu zvláštní) — AWS Cloudwatch + open source řešení osquery nebo GRR
analýza Netflow — AWS Cloudwatch + AWS VPC Flow
analýza DNS — AWS Cloudwatch + AWS Route53
AD — AWS Directory Service
řízení účtů — AWS IAM
SSO — AWS SSO
analýza zabezpečení — AWS Inspector
řízení konfigurací — AWS Config
WAF — AWS WAF.

Nebudu podrobně popisovat všechny služby Amazon, které mohou být užitečné v kontextu informační bezpečnosti. Hlavní je pochopit, že všechny mohou generovat události, které můžeme a musíme analyzovat v kontextu IS, přičemž využijeme jak zabudované možnosti samotného Amazonu, tak externí řešení, například SIEM, které mohou přebírat bezpečnostní události do vašeho monitorovacího centra a analyzovat je tam vedle událostí z jiných cloudových služeb nebo z vnitřní infrastruktury, perimetru či mobilních zařízení.

V každém případě to začíná u zdrojů dat, které vám poskytují události IS. Mezi takové zdroje lze mimo jiné zařadit:

CloudTrail — využívání API a akce uživatelů
Trusted Advisor — kontrola bezpečnosti dle nejlepších praktik
Config — inventarizace a konfigurace účtů a nastavení služeb
VPC Flow Logs — spojení s virtuálními rozhraními
IAM — služba identifikace a autentizace
ELB Access Logs — protokoly z vyvažovačů zatížení
Inspector — zranitelnosti v aplikacích
S3 — úložné služby
CloudWatch — aktivita aplikací
SNS — služba upozornění.

Amazon, nabízející takové spektrum zdrojů událostí a nástrojů na jejich generování, je přitom výrazně omezen v možnostech analýzy shromážděných dat v kontextu IS. Budete muset самостоятельно prozkoumávat existující protokoly, abyste v nich našli odpovídající indikátory kompromitace. AWS Security Hub, který nedávno uvedl Amazon, má tento problém řešit, a stává se tak modelem cloudového SIEM pro AWS. Ale zatím je teprve na začátku své cesty a je omezen jak počtem zdrojů, se kterými pracuje, tak jinými omezeními danými architekturou a předplatným samotného Amazonu.

Příklad: Monitorování IS v IaaS na bázi Azure

Nechci se pouštět do dlouhé polemiky, který z trojice cloudových poskytovatelů (Amazon, Microsoft či Google) je nejlepší (tím spíše, že každý z nich má své specifické rysy a je vhodný pro různá řešení); soustřeďme se na možnosti monitorování bezpečnosti, které tito hráči nabízejí. Je třeba uznat, že Amazon AWS byl jedním z prvních v tomto segmentu a proto pokročil nejvzdáleněji ve svých funkcích bezpečnosti (i když mnozí uznávají, že je obtížné je používat). Ale to neznamená, že ignorujeme možnosti, které nám nabízí Microsoft s Googlem.

Produkty Microsoftu se vždy vyznačovaly svou "otevřeností" a v Azure je situace podobná. Například, pokud AWS a GCP vždy vycházejí z konceptu "vše, co není povoleno, je zakázáno", pak Azure má úplně 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řeny a povoleny. Proto budete 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 přísnější požadavky v oblasti monitorování aktivity v cloudu Azure.

AWS má zvláštnost, že když monitorujete své virtuální zdroje, pokud se nacházejí v různých regionech, vznikají problémy s kombinováním všech událostí a jejich jednotnou analýzou, pro jejichž odstranění musíte používat různá úskalí, například vytvářením vlastního kódu pro AWS Lambda, který bude přenášet události mezi regiony. V Azure tento problém není — jeho mechanismus Activity Log sleduje veškerou aktivitu napříč celou organizací bez omezení. Totéž platí pro AWS Security Hub, který byl nedávno vyvinut Amazonem pro konsolidaci mnoha funkčností bezpečnosti do jednoho bezpečnostního centra, ale pouze v rámci svého regionu, což pro Rusko není relevantní. V Azure existuje vlastní Security Center, které není spojeno s regionálními omezeními a poskytuje přístup ke všem funkcím bezpečnosti cloudové platformy. Co je více, pro různé místní týmy může poskytnout vlastní sadu obranných schopností, včetně událostí bezpečnosti, které spravují. AWS Security Hub se teprve snaží přiblížit Azure Security Center. Ale je třeba dodat i špetku hořkosti — můžete využít z Azure velmi mnoho z toho, co bylo dříve popsáno pro AWS, ale nejpohodlněji to funguje pouze pro Azure AD, Azure Monitor a Azure Security Center. Všechny ostatní obranné mechanismy Azure, včetně analýzy událostí bezpečnosti, jsou zatím řízeny ne úplně komfortně. Částečně problém řeší API, které proniká do všech služeb Microsoft Azure, ale to vyžaduje další úsilí s integrací vašeho cloudu s vaším SOC a mít kvalifikované specialisty (stejně jako u jakéhokoli jiného SIEM, který pracuje s cloudovými API). Některé SIEM, o kterých se bude dále hovořit, již podporují Azure a mohou automatizovat úkol jeho monitorování, ale i s nimi jsou určité komplikace — ne všechny mohou vyžadovat všechny protokoly, které Azure má.

Shromažďování událostí a jejich monitorování 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 — repozitáře Git, kontejnerech, virtuálních strojích, aplikacích atd. Všechna data shromážděná pomocí Azure Monitor jsou rozdělena do dvou kategorií — metriky shromažďované v reálném čase, které popisují klíčové výkonnostní ukazatele cloudu Azure, a protokoly, které obsahují data organizovaná v záznamech, charakterizující různé aspekty činnosti prostředků a služeb Azure. Kromě toho může služba Azure Monitor pomocí Data Collector API shromažďovat data z jakéhokoli REST zdroje pro vytváření vlastních scénářů monitorování.

Zde je několik zdrojů událostí zabezpečení, které vám Azure nabízí a k nimž můžete přistupovat prostřednictvím Azure Portalu, CLI, PowerShell nebo REST API (některé pouze prostřednictvím Azure Monitor / Insight API):

Aktivní protokoly — tento protokol odpovídá na klasické otázky “kdo”, “co” a “kdy” v souvislosti s jakoukoli operací zápisu (PUT, POST, DELETE) nad cloudovými prostředky. Události související s přístupem pro čtení (GET) do tohoto protokolu nepatří, stejně jako řada dalších.
Diagnostické protokoly — obsahují data o operacích s jednotlivými prostředky, které patří do vaší předplatné.
Azure AD reportování — obsahuje informace o uživatelské aktivitě, stejně jako systémové aktivity spojené s řízením skupin a uživatelů.
Windows Event Log a Linux Syslog — obsahují události z virtuálních strojů umístěných v cloudu.
Metriky — obsahují telemetrii o stavu výkonnosti a „zdraví“ vašich cloudových služeb a prostředků. Měří se každou minutu a uchovávají se po dobu 30 dnů.
Protokoly Flow skupiny zabezpečení sítě — obsahují data o síťových událostech zabezpečení, shromažďovaná pomocí služby Network Watcher a monitorování prostředků na úrovni sítě.
Protokoly úložiště — obsahují události spojené s přístupem k úložištím.

Pro monitoring můžete použít externí SIEM nebo integrovaný Azure Monitor a jeho rozšíření. O systémech správy bezpečnostních událostí si ještě pohovoříme, ale nyní se podívejme, co nám samotný Azure nabízí pro analýzu dat v kontextu bezpečnosti. Hlavním panelem pro všechno, co souvisí se zabezpečením v Azure Monitor, je Dashboard pro bezpečnost a audit Log Analytics (zdarma verze podporuje uchovávání omezeného množství událostí pouze na jednu týden). Tento panel je rozdělen na 5 hlavních oblastí, které vizualizují souhrnné statistiky o tom, co se děje ve vaší cloudové infrastruktuře:

Bezpečnostní domény — klíčové kvantitativní ukazatele související s bezpečností — počet incidentů, počet kompromitovaných uzlů, neopravené uzly, události síťové bezpečnosti atd.
Významné problémy — zobrazuje počet a důležitost aktivních bezpečnostních problémů
Detekce — zobrazuje vzory, které byly použity proti vám v útocích
Inteligence hrozeb — zobrazuje geografické informace o externích uzlech, které vás napadají
Běžné bezpečnostní dotazy — typické dotazy, které vám pomohou lépe monitorovat vaši bezpečnost.

Mezi rozšíření Azure Monitor lze zařadit Azure Key Vault (ochrana kryptografických klíčů v cloudu), Malware Assessment (analýza ochrany proti malwaru na virtuálních strojích), Azure Application Gateway Analytics (analýza, mimo jiné, logů cloudového firewallu) atd. Tyto nástroje, obohacené o určité pravidla zpracování událostí, umožňují vizualizovat různé aspekty činnosti cloudových služeb, včetně bezpečnosti, a odhalovat určitá odchylky v provozu. Ale jak to často bývá, každá další funkčnost vyžaduje odpovídající placené předplatné, což od vás vyžaduje příslušné finanční investice, které je třeba plánovat předem.

Azure má řadu vestavěných funkcí pro monitorování hrozeb, které jsou integrovány do Azure AD, Azure Monitor a Azure Security Center. Mezi nimi například detekce interakce virtuálních strojů s známými škodlivými IP (díky integraci se službami Threat Intelligence od Microsoftu), detekce škodlivých programů v cloudové infrastruktuře na základě signálů alarmů z virtuálních strojů umístěných v cloudu, útoky typu „hrubou silou“ na virtuální stroje, zranitelnosti v konfiguraci systému identifikace uživatelů, přihlášení z anonymizátorů nebo infikovaných uzlů, úniky účtů, přihlášení z neobvyklých míst a podobně. Dnes je Azure jedním z mála poskytovatelů cloudových služeb, kteří vám nabízejí vestavěné možnosti Threat Intelligence pro obohacení shromážděných událostí kybernetické bezpečnosti.

Jak již bylo uvedeno výše, ochranné funkce a tedy i události bezpečnosti, které generují, nejsou dostupné všem uživatelům stejně a vyžadují určité předplatné zahrnující požadované funkce, které generují příslušné události pro monitorování kybernetické bezpečnosti. Například část funkcí popsaných v předchozím odstavci pro monitorování anomálií v účtech je dostupná pouze v prémiové licenci P2 pro službu Azure AD. Bez ní, stejně jako v případě AWS, budete muset analyzovat shromážděné události bezpečnosti „ručně“. A také, v závislosti na typu licence na Azure AD, nebudou vám dostupné všechny události k analýze.

Na portálu Azure můžete spravovat jak dotazy na zajímavé záznamy, tak nastavovat panely pro vizualizaci klíčových ukazatelů kybernetické bezpečnosti. Kromě toho si tam můžete vybrat rozšíření Azure Monitor, která vám umožňují rozšířit funkčnost protokolů Azure Monitor a získat hlubší analýzu událostí z hlediska bezpečnosti.

Pokud potřebujete nejen možnost práce s logy, ale komplexní centrum bezpečnosti vaší cloudové platformy Azure, včetně správy politik kybernetické bezpečnosti, pak je na místě hovořit o nutnosti využití Azure Security Center, jehož většina užitečných funkcí je dostupná za poplatek, například detekce hrozeb, monitorování mimo Azure, hodnocení souladu atd. (v bezplatné verzi máte k dispozici pouze hodnocení bezpečnosti a doporučení k odstranění identifikovaných problémů). Centralizuje všechny otázky bezpečnosti na jednom místě. V podstatě lze říci, že poskytuje vyšší úroveň kybernetické bezpečnosti, než vám nabízí Azure Monitor, protože v tomto případě jsou shromážděná data z celé vaší cloudové infrastruktury obohacena řadou zdrojů, jako jsou 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é se uplatňují různá sofistikovaná strojová učení a behaviorální analytiky, což by mělo zvýšit účinnost detekce hrozeb a reakce na ně.

Azure má také svůj vlastní SIEM, který byl představen na začátku roku 2019. Je to Azure Sentinel, který se opírá o data z Azure Monitor a může se také integrovat s externími bezpečnostními řešeními (například NGFW nebo WAF), jejichž seznam se neustále rozšiřuje. Kromě toho vám integrace Microsoft Graph Security API umožňuje připojit k Sentinelu vlastní feedy Threat Intelligence, což obohacuje možnosti analýzy incidentů ve vašem cloudovém prostředí Azure. Lze říci, že Azure Sentinel je prvním "nativním" SIEMem, který se objevuje u cloudových poskytovatelů (kdežto Splunk nebo ELK, které lze umístit do cloudu, například na AWS, jsou vyvinuty ne poskytovateli tradičních cloudových služeb). Azure Sentinel a Security Center by bylo možné považovat za SOC pro cloud Azure a bylo by možné se jimi v podstatě omezit (s určitými výhradami), pokud byste neměli žádnou jinou infrastrukturu a všechny své výpočetní zdroje přenesli do cloudu a tímto cloudu by byl Microsoft Azure.

Ale protože vestavěné možnosti Azure (i při aktivní předplatné na Sentinel) často nestačí pro účely monitorování kybernetické bezpečnosti a integraci tohoto procesu s dalšími zdroji bezpečnostních událostí (jak cloudovými, tak interními), vzniká potřeba exportovat shromážděná data do externích systémů, mezi které může patřit i SIEM. To se provádí jak pomocí API, tak pomocí speciálních rozšíření, která jsou momentálně oficiálně k dispozici pouze pro následující SIEM — Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight a ELK. Ještě nedávno bylo těchto SIEM více, ale od 1. června 2019 Microsoft přestal podporovat nástroj Azure Log Integration Tool (AzLog), který na počátku existence Azure a při absenci normální standardizace práce s logy (Azure Monitor ještě ani neexistoval) umožňoval snadno integrovat externí SIEM s cloudem Microsoft. Situace se nyní změnila a Microsoft doporučuje platformu Azure Event Hub jako hlavní nástroj pro integraci s ostatními SIEM. Mnozí již tuto integraci provedli, ale buďte opatrní — mohou zachytávat jen některé logy Azure, nikoli všechny (viz dokumentaci k vašemu SIEM).

Na závěr krátkého exkurzu do Azure bych chtěl doporučit jednu obecnou radu ohledně této cloudové služby: než něco potvrdíte ohledně funkcí monitorování IT bezpečnosti v Azure, ujistěte se, že je nastavíte velmi pečlivě a otestujete, aby fungovaly tak, jak je uvedeno v dokumentaci a jak vám řekli konzultanti Microsoft (a ti mohou mít různé názory na funkčnost Azure). Při dostatečných finančních prostředcích lze z Azure vytěžit velmi mnoho užitečného pro monitorování IT bezpečnosti. Pokud jsou však vaše prostředky omezené, budete se muset stejně jako v případě AWS spoléhat pouze na vlastní síly a syrová data, která vám poskytuje Azure Monitor. A pamatujte, že mnohé funkce monitorování stojí peníze, a je dobré se s cenovou politikou seznámit předem. Například zdarma můžete uchovávat data za 31 dní s objemem maximálně 5 GB na klienta — překročení těchto hodnot vás přinutí vynaložit další peníze (přibližně 2+ dolary za uchovávání každého dalšího GB na klienta a 0,1 dolaru za uchovávání 1 GB každý další měsíc). Práce s telemetrií aplikací a metrikami může také vyžadovat další finanční prostředky, stejně jako práce s alarmy a notifikacemi (zdarma je k dispozici určitý limit, který nemusí stačit pro vaše potřeby).

Příklad: Monitorování IT bezpečnosti v IaaS na bázi Google Cloud Platform

Google Cloud Platform v porovnání s AWS a Azure vypadá jako naprostý nováček, ale z části je to dobré. Na rozdíl od AWS, který postupně zvyšoval své schopnosti, včetně těch bezpečnostních, s problémy v centralizaci, GCP, podobně jako Azure, je mnohem lépe spravováno centrálně, což snižuje počet chyb a dobu zavádění na podniku. Z hlediska bezpečnosti se GCP nachází, jak to divně zní, mezi AWS a Azure. Má také jednotné registrování událostí pro celou organizaci, ale není ú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 zralější platformou z pohledu monitorování IT bezpečnosti.

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

Admin Activity — obsahuje všechny události spojené s administrativním přístupem, například vytváření virtuálního stroje, změnu přístupových práv atd. Tento protokol se zapisuje vždy, bez ohledu na váš přání, a uchovává svá data po dobu 400 dní.
Data Access — obsahuje všechny události spojené s prací s daty cloudovými uživateli (vytváření, změna, čtení atd.). Tento protokol se ve výchozím nastavení nezapisuje, protože jeho objem velmi rychle narůstá. Z tohoto důvodu je doba jeho uchovávání pouhých 30 dní. Dále se do tohoto protokolu nezapisuje vše. Například události spojené s veřejně dostupnými zdroji pro všechny uživatele nebo události, které jsou dostupné bez přihlášení do GCP, se sem nezapisují.
System Event — obsahuje systémové události, nesouvisející s uživateli, nebo akce administrátora, který mění konfiguraci cloudových zdrojů. Zapisuje se vždy a uchovává se po dobu 400 dní.
Access Transparency — je unikátní příklad registračního protokolu, který zaznamenává všechny akce zaměstnanců Google (ale zatím ne pro všechny služby GCP), kteří mají přístup k vaší infrastruktuře v rámci vykonávání svých pracovních povinností. Tento protokol se uchovává 400 dní a není dostupný každému klientovi GCP, ale pouze za splnění řady podmínek (buď Gold nebo Platinum úroveň podpory, nebo mít čtyři role určitých typů v rámci korporátní podpory). Podobná funkce existuje také například v Office 365 — Lockbox.

Příklad protokolu: Access Transparency

{
 insertId: "abcdefg12345"
 jsonPayload: {
 @type: "type.googleapis.com/google.cloud.audit.TransparencyLog"
 location: {
 principalOfficeCountry: "US"
 principalEmployingEntity: "Google LLC"
 principalPhysicalLocationCountry: "CA"
 }
 product: [
 0: "Cloud Storage"
 ]
 reason: [
 detail: "Číslo případu: 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.comaccess_transparency"
 operation: {
 id: "12345xyz"
 }
 receiveTimestamp: "2017-12-18T16:06:37.400577736Z"
 resource: {
 labels: {
 project_id: "1234567890"
 }
 type: "project"
 }
 severity: "NOTICE"
 timestamp: "2017-12-18T16:06:24.660001Z"
}

K uvedeným logům je přístup několika způsoby (podobně jako u dříve probíraných Azure a AWS) — přes rozhraní Log Viewer, API, Google Cloud SDK nebo stránku Aktivity vašeho projektu, k němuž se zajímají události. Stejným způsobem je také možné je exportovat do externích řešení pro další analýzu. To se provádí exportem logů do úložiště BigQuery nebo Cloud Pub/Sub.

Kromě Stackdriver Logging nabízí platforma GCP také funkčnost Stackdriver Monitoring, která umožňuje sledovat klíčové metriky (výkon, dostupnost, celkový stav atd.) cloudových služeb a aplikací. Speciálně zpracovaná a vizualizovaná data mohou usnadnit hledání problémů v infrastruktuře vašeho cloudu, včetně bezpečnostního kontextu. Je však třeba poznamenat, že tato funkčnost nebude příliš bohatá právě v kontextu IB, protože v současnosti GCP nemá ekvivalent AWS GuardDuty a nemůže během všech registrovaných událostí vyčlenit skutečně problematické (Google vyvinul Event Threat Detection, ale zatím je v beta verzi a o jeho užitečnosti je brzy hovořit). Stackdriver Monitoring by mohl být využit jako systém detekce anomálií, které by byly následně vyšetřovány za účelem nalezení příčin jejich vzniku. Avšak vzhledem k nedostatku kvalifikovaných odborníků v oblasti IB na trhu, tato úloha se v současnosti jeví jako složitá.

Také by bylo dobré uvést seznam některých modulů pro IB, které mohou být aplikovány v rámci vašeho 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 úprava (například maskování) dat uložených v cloudu podle více než 90 přednastavených klasifikačních politik.
Cloud Scanner — skener známých zranitelností (XSS, Flash Injection, nepoužité knihovny atd.) v App Engine, Compute Engine a Google Kubernetes.
Cloud IAM — správa přístupu ke všem zdrojům GCP.
Cloud Identity — správa uživatelských účtů, zařízení a aplikací GCP z jediné konzole.
Cloud HSM — ochrana kryptografických klíčů.
Cloud Key Management Service — správa kryptografických klíčů v GCP.
VPC Service Control — vytvoření chráněného perimetru kolem vašich zdrojů GCP pro ochranu proti únikům.
Titan Security Key — ochrana proti phishingu.

Mnoho z těchto modulů generuje bezpečnostní události, které mohou být odeslány do úložiště BigQuery pro analýzu nebo export do jiných systémů, včetně SIEM. Jak již bylo zmíněno, GCP je aktivně rozvíjená platforma a Google v současnosti vyvíjí řadu nových modulů pro kybernetickou bezpečnost pro svou platformu. Mezi nimi Event Threat Detection (aktuálně dostupná v beta verzi), která skenuje protokoly Stackdriver na hledání stop neoprávněné aktivity (analog GuardDuty v AWS) nebo Policy Intelligence (dostupná v alfa verzi), která umožní vypracovat inteligentní politiky přístupu k zdrojům GCP.

Udělil jsem krátký přehled integrovaných možností monitorování v populárních cloudových platformách. Ale máte odborníky, kteří jsou schopní pracovat se "syrovými" protokoly poskytovatele IaaS (ne všichni jsou ochotni kupovat rozšířené možnosti AWS, Azure nebo Google)? Kromě toho je mnohým známo přísloví "důvěřuj, ale prověřuj", které je v oblasti bezpečnosti platnější než kdy předtím. Jak důvěřujete integrovaným možnostem cloudového poskytovatele, které vám poskytují bezpečnostní události? Jak moc se vůbec zaměřují na kybernetickou bezpečnost?

Někdy stojí za to podívat se na řešení pro monitorování cloudové infrastruktury, která mohou doplnit vestavěnou bezpečnost cloudu, a někdy jsou tato řešení jedinou možností, jak získat informace o zabezpečení vašich dat a aplikací umístěných v cloudu. Kromě toho jsou jednodušší, protože se postarají o všechny úkoly spojené s analýzou potřebných logů generovaných různými cloudovými službami od různých poskytovatelů cloudu. Příkladem takového nadstavbového řešení může být Cisco Stealthwatch Cloud, který se zaměřuje na jediný úkol — monitorování anomálií bezpečnosti informací v cloudových prostředích, mezi nimiž jsou 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í platformu pro výpočty, ale tato flexibilita vede k tomu, že firmy snadněji dělají chyby, které vedou k bezpečnostním problémům. A sdílený model bezpečnosti informací tomu pouze napomáhá. Spuštění cloudových aplikací s neznámými zranitelnostmi (pro které lze například bojovat pomocí AWS Inspector nebo GCP Cloud Scanner), slabá hesla, nesprávné konfigurace, insidři atd. A to vše se odráží v chování cloudových zdrojů, které může sledovat Cisco Stealthwatch Cloud, jenž je systémem pro monitorování bezpečnosti informací a detekci útoků v veřejných a soukromých cloudech.

Jednou z klíčových vlastností Cisco Stealthwatch Cloud je možnost modelování entit. Pomocí něj můžete vytvořit softwarový model (tedy simulaci téměř v reálném čase) každého z vašich cloudových zdrojů (ať už je to AWS, Azure, GCP nebo něco jiného). Může se jednat o servery a uživatele, stejně jako o typy zdrojů specifické pro vaše cloudové prostředí, jako jsou bezpečnostní skupiny a skupiny automatického škálování služeb (auto-scale). Tyto modely používají jako vstup strukturované proudy dat poskytované cloudovými službami. Například pro AWS to budou VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda a AWS IAM. Modelování entit automaticky odhaluje roli a chování jakéhokoli z vašich zdrojů (můžeme mluvit o profilování celé cloudové aktivity). Mezi takové role patří mobilní zařízení Android nebo Apple, server Citrix PVS, RDP server, poštovní brána, VoIP klient, terminálový server, doménový řadič a další. Poté neustále sleduje jejich chování, aby zjistil, kdy dochází k riskantnímu nebo bezpečnostně ohrožujícímu chování. Můžete identifikovat pokusy o prolomení hesel, DDoS útoky, úniky dat, nelegální vzdálený přístup, činnost škodlivého kódu, skenování zranitelností a další hrozby. Například takto vypadá detekce pokusu o vzdálený přístup z netypické země pro vaši organizaci (Jižní Korea) k clusteru Kubernetes přes SSH:

A takto vypadá předpokládaný únik informací z databáze Postgres do země, se kterou dříve nebyl žádný kontakt:

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

Nebo si představte, že instance serveru ve VPC by podle politiky nikdy neměla být bodem pro vzdálený přístup. Dále předpokládejme, že na tomto počítači došlo k vzdálenému přihlášení kvůli chybné změně politiky pravidel firewallu. Funkce modelování entit by tuto aktivitu („Neobvyklý vzdálený přístup“) detekovala a hlásila v téměř reálném čase a vyznačila by konkrétní volání API AWS CloudTrail, Azure Monitor nebo GCP Stackdriver Logging (včetně uživatelského jména, data a času, mezi dalšími detaily), které způsobily změnu v pravidle MSEC. A poté mohou být tyto informace předány do SIEM k analýze.

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

Modelování entit je jedinečná forma zabezpečení automatizace, která může odhalit dříve neznámé problémy s vašimi lidmi, procesy nebo technologiemi. Například umožňuje odhalovat mimo jiné následující bezpečnostní problémy:

Bylo zjištěno, že někdo má backdoor v softwaru, který používáme?
Existuje nějaký třetí software nebo zařízení v našem cloudu?
Zneužívá autorizovaný uživatel privilegium?
Došlo k chybě konfigurace, která umožňuje vzdálený přístup nebo jiné neúmyslné využití zdrojů?
Není z našich serverů únik dat?
Snažil se k nám někdo připojit z neobvyklého geografického místa?
Není naše cloudové prostředí infikováno malwarem?

Zjištěná událost v oblasti IT může být předána jako odpovídající tiket do Slacku, Cisco Spark, systému správy incidentů PagerDuty, a také poskytnuta do různých SIEM, mezi nimiž jsou Splunk nebo ELK. Shrnutí je takové, že pokud vaše společnost používá multicloudovou strategii a neomezuje se pouze na jednoho poskytovatele cloudu, možnosti sledování IT, o kterých bylo hovořeno výše, činí Cisco Stealthwatch Cloud dobrou volbou pro získání jednotné sady funkcí pro monitorování předních poskytovatelů cloudových služeb - Amazonu, Microsoftu a Google. Nejzajímavější je, že při porovnání cen Stealthwatch Cloud s pokročilými licencemi pro sledování IT v AWS, Azure nebo GCP se může ukázat, že řešení Cisco je dokonce levnější než vestavěné funkce nabízené společnostmi Amazon, Microsoft a Google. Paradoxně, ale je to tak. A čím více cloudů a jejich funkcí používáte, tím jasnější budou výhody konsolidovaného řešení.

Kromě toho může Stealthwatch Cloud monitorovat i privátní cloudy, které máte nasazené ve vaší organizaci, například na základě kontejnerů Kubernetes nebo prostřednictvím sledování Netflow nebo síťového provozu získávaného pomocí zrcadlení v síťovém vybavení (i domácí výroby), dat AD nebo DNS serverů atd. Všechny tyto údaje budou obohaceny o informace o hrozbách, které shromažďuje oddělení Cisco Talos, největší na světě nevládní skupina výzkumníků v oblasti kybernetických hrozeb.

To vám umožňuje realizovat jednotný systém monitorování jak veřejných, tak hybridních cloudů, které může vaše společnost používat. Shromážděné informace mohou být poté analyzovány pomocí vestavěných funkcí Stealthwatch Cloud nebo odeslány do vašeho SIEM (výchozí podporované jsou Splunk, ELK, SumoLogic a řada dalších).

Tímto zakončíme první část článku, ve které jsem prozkoumal vestavěné a externí nástroje pro monitorování bezpečnosti IaaS/PaaS platforem, které nám umožňují rychle detekovat a reagovat na incidenty v cloudových prostředích, jež si naše firma zvolila. Ve druhé části se budeme věnovat tématu dále a prozkoumáme možnosti monitorování SaaS platforem na příkladu Salesforce a Dropboxu, a také se pokusíme shrnout a spojit vše dohromady, abychom vytvořili jednotný systém monitorování bezpečnosti různých cloudových poskytovatelů.

Zdroj: habr.com