Microsoft Azure Sentinel – Security As A Service s využitím umělé inteligence (část první)

24.září 2019 v 9:00 tichomořského času byla spuštěna dlouho očekávaná služba Azure Sentinel. Azure Sentinel přináší zákazníkům platformy Microsoft Azure (a nejen jim) možnost využívání cloud-only SIEMu (Security Information & Event Management) s využitím Artificial Intelligence (umělé inteligence). Tato nová generace SIEM řešení je mimo jiné součástí služby ATOM (Advanced Threat and Organization Monitoring), kterou poskytuje společnost KPCS CZ, a je použitelná nejen pro zdroje v prostředí Microsoft, ale také jako globální SIEM organizace. Azure Sentinel poskytuje službu automatické škálovatelnosti, která se přizpůsobuje prostředí každého ze zákazníků, a byla sestavena na základě definic, které jsou očekávány od platformy typu SIEM. Díky využití cloudu a integrace s komponentami, které jsou dostupné nejen v prostředí Microsoft Azure, přináší nové možnosti kontroly prostředí a identifikace, či prošetřování moderních i tradičních hrozeb. Automatické škálování a přizpůsobování prostředí Azure Sentinel zajistí, že limity tohoto řešení jsou postaveny daleko za horizont potřeb běžných zákazníků. Proto již není nutné řešit dimenzování hardwarových prostředků, či počítání událostí za sekundu, které platforma zpracuje.

Co je služba Azure Sentinel a v čem vám pomůže

Prostřednictvím Azure Sentinel lze, s využitím konceptu SOAR (Security, Orchestration, Automation and Response), redukovat čas aktivit SecOps (bezpečnostně operačního týmu) týmu. Koncept SOAR na základě detekce hrozby totiž zajistí, aby systém autonomně provedl konkrétní reakci, například změnu konfigurace aktivního prvku, nastavení black nebo white listu, případně spuštění dalšího prošetřování bezpečnostní události. Azure Sentinel umožní SecOps týmu zaměřit se na významné události, které nebylo možné dříve odbavit nebo byly přehlédnuty v závislosti na množství rutinních činností.

Tyto aktivity, dle nedávného měření, dosahují zhruba 80 % aktivit SecOps týmu. Tedy díky možnostem využití SOAR lze tyto operace automatizovat a zaměnit tak, aby se běžné operativní činnosti SecOps týmu změnily v činnosti související s hloubkovým šetřením a kontinuálním tréninkem. Podle dalších statistik jsou SecOps týmy zaplaveny množstvím událostí k prošetření bezpečnostních událostí a u 44 % událostí vůbec nedojde k jejich včasnému řešení. Tento fakt je částečně problémem komplexity, ale také problémem nedostatku lidí, které by bylo možné do SecOps týmů obsadit. V souvislosti s tímto aspektem vzrostla a dlouhodobě vzrůstá doba, za kterou dokáže společnost bezpečnostní událost odhalit, a to na 197 dní, a doba, než je útočník v prostředí zachycen, stoupla na 69 dní.

Služba Azure Sentinel je sestavena na základě zkušeností, které společnost Microsoft získala ze svých analýz a z prošetřování útoků, které jsou každým dnem vedeny proti službám, jež poskytuje (například Azure, Office365, XBOX atd…). Bohužel však počet komplexních a hůře odhalitelných útoků stále vzrůstá a je nyní potřeba čelit novým výzvám, kdy hrozby zasahují nejen oblast tradičního IT, ale přechází do cloudových služeb a zneužívají platformy IoT, Windows, MacOS, či Linux. I tak se ale stále nejčastější obětí stává uživatel, který po nějaké době vždy podlehne lákadlům útočníka.

Je nutné si také uvědomit, že vektor celého útoku může být značně široký a může využívat šedých zón prostředí, které nemusí být IT správci dostatečně ošetřeny. Tradiční SIEMové nástroje v této oblasti dosahují svých limitů, a to nejen proto, že jejich primární kontrolovanou oblastí je, do jisté míry, lokální prostředí zákazníků, a koncept, se kterým byly vytvořeny, byl vázán výhradně na lokální IT prostředí. Microsoft do služby poskytl celosvětově více jak 3500+ bezpečnostních expertů, kteří se starají o identifikace a rozpoznávání vektorů útoků. Investice, kterou společnost Microsoft provede každým rokem do oblasti Cyber Security, činí 1 bilion USD.

Mise SecOps týmu, který bdí nad bezpečností organizace, se jeví jako stále obtížnější, jelikož dochází ke ztrátě hranic mezi lokálním prostředím a cloudem (budování hybridních cloudů), nebo také díky rozšíření konceptů BYOD. SecOps týmy musí kontinuálně čelit výzvám, kterými mohou být:

• ​ komplexnější útoky
• ​ velký objem událostí k prošetření
• ​ nutnost provádění aktualizací a správy svých detekčních či prevenčních nástrojů
• ​ investice za inovaci, či za pořízení nových bezpečnostních, či dohledových nástrojů
• ​ ztráta kontroly, díky přerušení hranice tradičního IT
• ​ nedostupnost automatizace a orchestrace rutinních činností
• ​ nedostatek informací v důsledku absence připojených datových zdrojů, které jsou způsobeny limity produktů, či licenčními limity stávajících řešení

Jak pracuje Azure Sentinel

Azure Sentinel je vystavěn nad základnou produktů, které byly již v prostředí Microsoft Azure dříve k dispozici, ale díky možnostem využívání enginu FUSION (umělé inteligence) pomáhá s rozpoznáním celé škály nových a komplexních útoků. Primárním prvkem pro Azure Sentinel je Log Analytics Workspace, Microsoft Threat Protection (ochranný prvek služeb Microsoft 365), nebo také Microsoft Security Graph, či produkty třetích stran.

Azure Sentinel však není vázán jen na cloudové služby společnosti Microsoft, ale právě díky tomu, že je integrován nad Log Analytics, je možné využívat propojení na jakékoliv služby a sbírat jakákoliv data. Sběr dat lze provést buď pomocí Common Event Format logů (CEF), pomocí syslogových zpráv nebo je možné data odesílat na otevřená HTTP DATA API (REST API) a následně tato data korelovat v rámci detekčních pravidel. Azure Sentinel je však velmi úzce propojen, díky připraveným konektorům služby anebo pomocí konektorů Log Analytics, na další služby, které chrání lokální či cloudové prostředí nebo uživatele.

Pokud se rozhodnete provést napojení Azure Sentinel nad své prostředí, tedy konkrétně nad službu Log Analytics, měli byste si být jisti, že je služba v dobré zdravotní kondici, a hlavně poskytuje ta správná data a informace z vašeho prostředí, se kterými může dále Azure Sentinel pracovat. Správné nastavení celého řešení, a ještě mnohem více, vám nabídne i služba ATOM, která byla vystavěna primárně nad službou Log Analytics a s vydáním služby Azure Sentinel jej adoptovala. Služba ATOM tak nabízí kompletní a ucelené řešení, které pokryje potřeby i těch nejnáročnějších organizací.

Nejen napojení a konfigurace je důležitá pro celé fungování služby Azure Sentinel, ale také vyšetřovací tým musí zaměřit svou pozornost na prošetření nálezů a bezpečnostních událostí. S ohledem na vyšetřovací tým zde máte několik možností, a to

- využít vlastní interní kapacity bezpečnostního týmu; a/nebo

- využít konzultantů KPCS CZ, kteří pomáhají zákazníkům s šetřením bezpečnostních událostí v rámci poskytování služby ATOM; a/nebo

- využít týmu Microsoft Threat Experts.

Jakým způsobem by měly být rozloženy role, bude jen na vás. Můžete převzít roli a pozici vyšetřovatele, tedy úroveň L2, a rutinní události nechat prošetřit týmem ATOM, který z pozice L1 analytiků provede základní ohledání a prošetření bezpečnostní události. Pokud si však s danou bezpečnostní událostí nevíte rady, pak lze využívat i služeb vyšetřovacích týmů společnosti Microsoft, a to právě v rámci čerpání kapacit Microsoft Threat Experts, případně v rámci Premier Supportu. Tito experti poté zastanou pozici L3 úrovně bezpečnostního týmu.

Možné integrace a propojení

Jelikož je Azure Sentinel postaven na základech běžného SIEMu, je zde připravena i integrace řešení třetích stran, která rozšiřují existující datovou základu, a tedy i detekční dotazy tak, aby bylo možné identifikovat více komplexních scénářů útoku.

Ze strany společnosti Microsoft jsou poskytovány konektory, které umožňují, do jisté míry, extrakci dat, či bezpečnostních událostí z platforem, které již nyní zákazníci využívají. Nicméně další možnosti integrace přináší služba Log Analytics, Azure Security Center, či Windows Defender ATP.

Tyto konektory mají různé metody integrace a liší se i úroveň datové základny (poskytovaná data z jednotlivých služeb). Proto je vhodné ověřit, jaké informace a jaká data budou z daných systémů sbírána a korelována v rámci incidentů. Ne vždy se jedná o plnou podobu logů, které jsou v integrované službě dostupné. Pokud dochází k předání logů ze zařízení, kterými může být například Cisco ASA, pak jde o plný přenos informací. Tyto informace jsou díky vnitřním korelačním a normalizačním službám rozděleny na jednotlivé hodnoty a z nestrukturované syslogové zprávy nebo datové věty se stane objekt, tedy řádek v tabulce, který má jasné a zařaditelné hodnoty. Na tyto hodnoty je možné následně definovat dotazy, které pomohou s vyhledáním potencionálních hrozeb.

Příprava dotazů a testování detekčních scénářů

K přípravě dotazů a testování detekčních scénářů hrozeb může velmi dobře posloužit možnost náhledu na čistá data. V rámci části Logs je zákazník přesměrován do Log Analytics Workspace, kde tato data může dále zpracovávat a upravovat dle své znalosti či představivosti. Hlavní výhodou je možnost úpravy již existujících dotazů, tedy úprava na přesné a konkrétní požadavky každého ze zákazníků. Pokud jsou zjištěny nějaké nedostatky v detekčním dotazu, může být tento detekční dotaz upraven na konkrétní potřeby, případně můžeme v rámci daného detekčního dotazu upravit hodnoty (například vyloučením určitých IP adres, uživatelských jmen atd.). Pro vyhledávání je použit jazyk s názvem KUSTO Query Language, který se nese mnohými službami v platformě Microsoft Azure. Postupně se stává standardizovaným dotazovacím jazykem - je podobný SQL, konkrétně tedy T-SQL, nebo jazyku, který se využívá u nástroje s názvem Splunk.

Pokud má zákazník připravené a odladěné detekční dotazy, má možnost tyto dotazy na zkoušku nasadit do části služby Azure Sentinel, kde jsou, pokud tomu zákazník chce, spouštěny vždy po vynucení aktualizace v aplikaci. Dotazy jsou spuštěny a každý dotaz zobrazuje celkový počet nálezů, nicméně není odeslán alert, jedná se pouze o detekční mechanismus. Tato část se taktéž používá jako nástroj pro identifikaci hrozeb napříč prostředím v definovaném časovém intervalu, jelikož jsou všechny detekční dotazy spouštěny společně a každý z nich zobrazí svůj výsledek, tedy počet nálezů, které splňují podmínky specifikované v detekčním dotazu.

Každý detekční dotaz by měl být správně kategorizován, aby bylo možné určit, jaké části vektoru se daný nález týká. Z tohoto důvodu jsou využívány kategorizační fáze popsané v rámci MITRE ATT&CK. Kategorizace může být provedena do fází:

• ​ Initial Access
• ​ Execution
• ​ Persistence
• ​ Privilege Escalation
• ​ Defense Evasion
• ​ Credential Access
• ​ Discovery
• ​ Lateral Movement
• ​ Collection
• ​ Exfiltration
• ​ Command and Control
• ​ Impact

Detekční pravidla a identifikace potenciální hrozby

Společnost Microsoft na základě zjištění pravidelně rozšiřuje dostupná detekční pravidla, kterých je aktuálně celkem 119, ale některá padají do více kategorií, proto nelze hovořit o 119 unikátních pravidlech detekce bezpečnostních událostí. Další pravidla lze také získat, pokud zákazník provozuje integraci s Azure Security Center, některá se však mohou krýt mezi sebou.

Pokud dojde k identifikaci potencionální hrozby, pak je možné u každého detekčního dotazu zobrazit kompletní přehled čisté podoby logů nebo případně dotaz modifikovat tak, aby poskytoval úplný přehled o bezpečnostní události. Jelikož prvotní ověření provádí většinou tým L0 ze SecOps týmu, je nutné občas některé logy předávat k dalšímu prověření, a z tohoto důvodu je možné události označit a nastavit nad nimi Bookmark. Přehled těchto Bookmarků se poté zobrazí ve stejné části, kde je možné spustit všechny dotazy napříč prostředím, nicméně jejich přiřazení se provádí přes náhledy logů ve své surové podobě. Bookmarky mají také jednu z velkých výhod, a to je možnost přiřazení konkrétního Bookmarku na konkrétního řešitele a taktéž možnost komentování či tagování daného Bookmarku. Proto bychom se měli zamýšlet i nad stanovením jednoznačných pravidel kategorizace každého takového přiřazení.

Nenechte si ujít pokračování, ve druhé části tohoto článku se přesuneme do oblasti prošetřování bezpečnostních událostí a interpretaci zjištěných informací.