V první části jsme se zabývali základními informacemi o Microsoft Azure Sentinel. Jak funguje, s čím vám může pomoci, jaké má možnosti integrace a propojení, detekčními pravidly a identifikací potenciálních hrozeb. Nyní se přesuneme k oblasti Investigace a následně k interpretaci zjištěných informací.
Jak probíhá Investigace
Pokud se přesuneme k části Investigate, tedy prošetřování dané bezpečnostní události, a to jak na základě připraveného detekčního pravidla (Case) nebo za pomoci vytvořeného Bookmarku, můžeme provádět interaktivní šetření. Když zvolíme tlačítko Investigate, zobrazí se nám vždy část služby Azure Sentinel, která slouží k možnosti provedení tzv. Root Cause analýzy a interaktivní cestou nás celá služba vede k dalším a dalším informacím, a to bez nutnosti psaní složitých a někdy i nepřehledných detekčních dotazů. Jelikož útoky mohou být značně komplexní, tak je nutné každé detekční pravidlo řádně testovat a kontrolovat jeho funkčnost s ohledem na změny, které útočníci implementují do svých postupů útoků.
Zdroj: https://attack.mitre.org/
Společnost Microsoft, stejně jako je tomu u detekčních pravidel, připravuje podobná pravidla do části Analytics. Tato pravidla slouží pro generování alertů, které jsou následně odeslány na případné řešitele. Tyto alerty odesílají e-maily a vytvářejí položky v části Incidents za předpokladu, že je splněna podmínka v nich definovaná. V základním nastavení jsou tyto Analytics pravidla jen připravena ve formě šablon a každý zákazník má možnost volby, zda provede jejich aktivaci, či nikoliv.
Definice těchto analytických pravidel může a nemusí využívat dříve zmiňované umělé inteligence, tedy FUSION. O využívání FUSION jste informováni v rámci popisu daného detekčního pravidla. To v zásadě znamená, že pokud dojde k vzniku události a k ní navazující události, dojde k jejich sloučení a vytvoří se komplexní detekce. Následně se vytvoří Incident, který je možné dále prošetřovat. Stejně jako je tomu u Bookmarků, je možné Incidenty přiřadit na konkrétního řešitele, sepsat si poznámky, či nastavit Tagy daného incidentu. U těchto Incidentů lze provést i jejich reklasifikaci a určit jinou hodnotu rizika, než byla stanovena na základě detekčního pravidla.
Do Incidentů jsou nejen propsány detekce z Azure Sentinel, ale automaticky se do tohoto místa propisují i Incidenty detekované přímo společností Microsoft, a to skrze integraci například s Azure Security Center.
Prošetřování je možné provádět i na základě připravených Notebooků, tedy na základě komponenty, která se nazývá Azure Notebooks a která je postavena nad platformou Jupyter Notebook. Tyto Notebooky jsou postaveny jako interaktivní a analytický sešit a s využitím bloků, ze kterých se tento Notebook skládá – máte možnost načítat dynamický, či statický obsah z různě dostupných veřejných API, a to za pomoci hned několika analytických jazyků (Python 2, Python 3, Python 3.6, R, F#). Do těchto operací je možné začlenit analytické výhody strojového učení, kterými knihovny uvedených jazyků disponují.
Díky této možnosti analýzy je mnohem snadnější určit, zda se jedná o falešné hlášení nebo o skutečný bezpečnostní incident. Týmy L1 – L3 v SecOps mohou provádět mnohem komplexnější Root Cause analýzy celého prostředí a obohacovat informace například o různé typy slovníků a informací z reputačních databází nebo například načítat informace ze STIX a TAXII slovníků, pokud nevyužívají nástroj Threat Intelligence (například MISP).
Interpretace informací
Pro bezpečnostního manažera musí být však interpretace informací jednoduchá, snadno pochopitelná a lehce rozpoznatelná, aby mohl učinit adekvátní rozhodnutí ve věci přijmutí náležitého opatření ke snížení rizika, či k eliminaci případného dalšího výskytu incidentu. Pro snadnou interpretaci výsledků z detekcí a pro případný prvotní náhled na stav prostředí jsou připraveny Azure Workbooky (neplést s Azure Notebooky), které jsou do Azure Sentinel integrovány na místo dříve používaných Azure Dashboards. Azure Workbooky zastávají v rámci služby Azure Sentinel funkcionalitu reportů. Tyto reporty mají vzájemně vázané prvky (dotazy, sestavy, filtry, podmínky atd.), s možností napojení na různé typy služeb a s možností vzájemné korelace informací. Interpretovaná data jsou vždy online a mohou reflektovat trendy, či forecasty, postavené na základě historických informací. Opět tyto Azure Workbooky můžeme rozdělit na partnerské
a na přímo vytvořené společností Microsoft, a to i když nejsou striktně vázány na jejich produkty, ale jsou v zásadě partnerským řešením.
Sada Workbooků je pravidelně aktualizována a verze každého z nich je uvedena přímo v Azure Resource Manager Template, kterou lze získat na github.com. Automatický mechanizmus, který je zabudován ve službě Azure Sentinel, se stará o kontrolu těchto repositářů. Pokud identifikuje změnu verze daného Workbooku, dá uživateli možnost, aby provedl upgrade. Azure Workbooky je možné do github repositáře nasadit i jinou společnostní, čímž se z celé této části stává částečně komunitní záležitost.
Azure Sentinel má sadu výchozích Azure Workbooků, které si může každý zákazník nasadit sám pouhým stisknutím tlačítka. Výhodou může být také to, že pokud aktuální sestava nevyhovuje, lze ji jednoduše upravit za pomoci modifikace definovaných dotazů. Další výhodou je fakt, že celé Azure Workbooks jsou k dispozici na github.com a existuje zde možnost, jak poskytnout zákazníkem vytvořené Azure Workbooky pro Azure Sentinel dalším uživatelům služby.
Nevýhodou těchto Azure Workbooků, ale taktéž Azure Dashboardů, může být absence autorefresh grafů a query, kterou má k dispozici například Grafana. Pokud však zákazníkovi vyhovuje pro interpretaci více právě Grafana nebo PowerBI, pak lze i této možnosti využít a data a výsledky z daných dotazů může vizualizovat právě v těchto nástrojích.
Jelikož je Azure Sentinel klasifikován nejen jako SIEM, ale také jako SOAR (Security, Orchestration, Automation and Response) nástroj, tak služba Azure Sentinel dává možnost vytvořit automatická pravidla definovaná pomocí workflow. Tato workflow jsou velmi podobná například s Office365 Flow, ale ve skutečnosti se jedná o Logic Apps, která bere jako vstupní signály právě výsledky Incidentů, tedy alertů a na ně vytváří potřebné reakce. Dobrou demonstrací může být například scénář, kdy dochází k automatickému umístění identifikované Malicious IP, ze které bylo odesláno více než 10 neúspěšných požadavků na autentizaci skrze protokol SSH nebo RDP. Systém sám na základě definovaného pravidla vezme identifikovanou IP adresu, tu prostřednictvím API Firewallu nastaví do Black Listu a informuje správce pomocí krátké zprávy odeslané do týmu v rámci Microsoft Teams nebo založí ticket do Service desku, který i automaticky uzavře. Tímto způsobem jsou operativní aktivity snižovány až na naprosté minimum, přičemž kontrola definic, přizpůsobování a stavba nových detekčních pravidel je i nadále aktivitou správce Azure Sentinel.
Pokud vás tento článek, zaměřený na hlavní části nové služby Azure Sentinel jako nové generace SIEMového řešení zaujal a máte o službu zájem či potřebujete zodpovědět dotazy, neváhejte nás kontaktovat.
