Automatizace reakcí na hrozby v Microsoft Sentinelu pomocí pravidel automatizace
Tento článek vysvětluje, co jsou pravidla automatizace služby Microsoft Sentinel a jak je používat k implementaci operací orchestrace zabezpečení, automatizace a reakce (SOAR), což zvyšuje efektivitu SOC a šetří čas a prostředky.
Důležité
Microsoft Sentinel je k dispozici jako součást veřejné verze Preview pro jednotnou platformu operací zabezpečení na portálu Microsoft Defender. Další informace najdete v tématu Microsoft Sentinel na portálu Microsoft Defender.
Co jsou pravidla automatizace?
Pravidla automatizace představují způsob, jak centrálně spravovat automatizaci v Microsoft Sentinelu tím, že vám umožní definovat a koordinovat malou sadu pravidel, která se dají použít v různých scénářích.
Pravidla automatizace se vztahují na následující kategorie případů použití:
Provádění základních úloh automatizace pro zpracování incidentů bez použití playbooků Příklad:
- Přidejte úkoly incidentů pro analytiky, které mají sledovat.
- Potlačit hlučné incidenty.
- Třídění nových incidentů změnou stavu Nové na Aktivní a přiřazením vlastníka
- Označte incidenty a klasifikujte je.
- Eskalujte incident přiřazením nového vlastníka.
- Zavření vyřešených incidentů, zadání důvodu a přidání komentářů
Automatizujte odpovědi pro více analytických pravidel najednou.
Řídí pořadí spuštěných akcí.
Zkontrolujte obsah incidentu (výstrahy, entity a další vlastnosti) a proveďte další akce voláním playbooku.
Pravidla automatizace můžou být také mechanismem, kterým spouštíte playbook v reakci na výstrahu, která není přidružená k incidentu.
Stručně řečeno, pravidla automatizace zjednodušují používání automatizace v Microsoft Sentinelu, což vám umožní zjednodušit složité pracovní postupy pro procesy orchestrace reakcí na hrozby.
Komponenty
Pravidla automatizace se skládají z několika komponent:
- Triggery , které definují, jaký druh události incidentu způsobí, že se pravidlo spustí, v souladu s...
- Podmínky , které určují přesné okolnosti, za kterých se pravidlo spustí a provede...
- Akce pro změnu incidentu nějakým způsobem nebo volání playbooku
Aktivační události
Pravidla automatizace se aktivují při vytvoření nebo aktualizaci incidentu nebo při vytvoření výstrahy. Vzpomeňte si, že incidenty zahrnují výstrahy a že výstrahy i incidenty je možné vytvořit pomocí analytických pravidel, z nichž existuje několik typů, jak je vysvětleno v tématu Detekce hrozeb pomocí integrovaných analytických pravidel v Microsoft Sentinelu.
Následující tabulka ukazuje různé možné scénáře, které způsobí spuštění pravidla automatizace.
| Typ aktivační události | Události, které způsobují spuštění pravidla |
|---|---|
| Při vytvoření incidentu | Unified security operations platform in Microsoft Defender: Microsoft Sentinel není onboardovaný na sjednocenou platformu: |
| Při aktualizaci incidentu | |
| Při vytvoření výstrahy |
Automatizace založená na incidentech nebo výstrahách?
Teď, když se automatizace incidentů i automatizace výstrah zpracují centrálně pomocí pravidel automatizace i playbooků, jak byste měli zvolit, kdy se má použít?
Pro většinu případů použití je vhodnější použít automatizaci aktivovanou incidenty. V Microsoft Sentinelu je incident "případový soubor" – agregace všech relevantních důkazů pro konkrétní šetření. Jedná se o kontejner pro výstrahy, entity, komentáře, spolupráci a další artefakty. Na rozdíl od výstrah , které jsou jedinými důkazy, jsou incidenty upravitelné, mají nejaktuálnější stav a dají se rozšířit o komentáře, značky a záložky. Incident umožňuje sledovat scénář útoku, který se neustále vyvíjí s přidáním nových upozornění.
Z těchto důvodů je vhodnější vytvořit automatizaci v případě incidentů. Nejvhodnější způsob, jak vytvořit playbooky, je tedy založit je na triggeru incidentu Microsoft Sentinelu v Azure Logic Apps.
Hlavním důvodem použití automatizace aktivované výstrahami je reakce na výstrahy generované analytickými pravidly, která nevytvářejí incidenty (to znamená, že vytváření incidentů bylo zakázáno na kartě Nastavení incidentu v průvodci analytickým pravidlem).
Tento důvod je zvlášť relevantní, pokud je váš pracovní prostor Microsoft Sentinelu nasazený na sjednocené platformě operací zabezpečení, protože veškeré vytváření incidentů probíhá v XDR v programu Microsoft Defender, a proto musí být pravidla vytváření incidentů v Microsoft Sentinelu zakázaná.
I bez onboardingu na sjednocený portál byste se přesto mohli rozhodnout použít automatizaci aktivovanou výstrahou, pokud chcete použít jinou externí logiku k určení, jestli a jak se incidenty vytvářejí z výstrah, a také jestli a jak se výstrahy seskupují do incidentů. Příklad:
Playbook může aktivovat výstraha, která nemá přidružený incident, rozšířit výstrahu o informace z jiných zdrojů a na základě nějaké externí logiky rozhodnout, jestli se má incident vytvořit, nebo ne.
Playbook může aktivovat výstraha a místo vytvoření incidentu vyhledejte odpovídající existující incident, do něhož se má výstraha přidat. Přečtěte si další informace o rozšíření incidentů.
Playbook může aktivovat výstraha a upozornit pracovníky SOC na výstrahu, aby se tým mohl rozhodnout, jestli má incident vytvořit nebo ne.
Playbook může aktivovat výstraha a odeslat ji externímu systému lístků pro vytvoření a správu incidentů a vytvořit nový lístek pro každou výstrahu.
Poznámka:
Automatizace aktivovaná výstrahami je dostupná jenom pro výstrahy vytvořené podle pravidel naplánovaných analýz zabezpečení, pravidel NRT a Microsoftu.
Automatizace aktivovaná výstrahami pro výstrahy vytvořené XDR v programu Microsoft Defender není dostupná na sjednocené platformě operací zabezpečení. Další informace najdete v tématu Automatizace s jednotnou platformou operací zabezpečení.
Podmínky
Komplexní sady podmínek je možné definovat tak, aby se řídily, kdy se mají spustit akce (viz níže). Mezi tyto podmínky patří událost, která aktivuje pravidlo (vytvoření nebo aktualizace incidentu nebo vytvoření výstrahy), stavy nebo hodnoty vlastností incidentu a vlastností entity (pouze pro trigger incidentu) a také analytické pravidlo nebo pravidla, která vygenerovala incident nebo výstrahu.
Když se aktivuje pravidlo automatizace, zkontroluje aktivační incident nebo výstrahu s podmínkami definovanými v pravidle. U incidentů se podmínky na základě vlastností vyhodnocují v závislosti na aktuálním stavu vlastnosti v okamžiku, kdy dojde k vyhodnocení, nebo podle změn ve stavu vlastnosti (podrobnosti najdete níže). Vzhledem k tomu, že jedna událost vytvoření nebo aktualizace incidentu může aktivovat několik pravidel automatizace, pořadí , ve kterém se spouští (viz níže), je rozdíl při určování výsledku vyhodnocení podmínek. Akce definované v pravidle se spustí jenom v případě, že jsou splněny všechny podmínky.
Trigger vytvoření incidentu
Pro pravidla definovaná pomocí triggeru Při vytvoření incidentu můžete definovat podmínky, které kontrolují aktuální stav hodnot daného seznamu vlastností incidentu pomocí jednoho nebo několika následujících operátorů:
Hodnota vlastnosti incidentu
- rovná se nebo se nerovná hodnotě definované v podmínce.
- obsahuje nebo neobsahuje hodnotu definovanou v podmínce.
- začíná nebo nezačíná hodnotou definovanou v podmínce.
- končí nebo nekončí hodnotou definovanou v podmínce.
Aktuální stav v tomto kontextu odkazuje na okamžik vyhodnocení podmínky – to znamená okamžik, kdy se pravidlo automatizace spustí. Pokud je definováno více než jedno pravidlo automatizace, které se má spustit v reakci na vytvoření tohoto incidentu, považují se změny incidentu dříve spuštěným pravidlem automatizace za aktuální stav pravidel pozdějšího spuštění.
Trigger aktualizace incidentu
Podmínky vyhodnocené v pravidlech definovaných pomocí triggeru Při aktualizaci incidentu zahrnují všechny podmínky uvedené pro trigger vytvoření incidentu. Aktivační událost aktualizace ale obsahuje více vlastností, které je možné vyhodnotit.
Jedna z těchto vlastností je aktualizována. Tato vlastnost umožňuje sledovat typ zdroje, který provedl změnu v incidentu. Můžete vytvořit podmínku, která vyhodnotí, jestli se incident aktualizoval některou z následujících hodnot v závislosti na tom, jestli jste pracovní prostor onboardovali na sjednocenou platformu operací zabezpečení:
- Aplikace, včetně aplikací na portálech Azure i Defender.
- Uživatel, včetně změn provedených uživateli na portálech Azure i Defender.
- AIR pro aktualizace prostřednictvím automatizovaného vyšetřování a reakce v Microsoft Defender pro Office 365
- Seskupení výstrah (které do incidentu přidalo výstrahy), včetně seskupení výstrah provedených analytickými pravidly a integrovanou logikou korelace XDR v programu Microsoft Defender
- Playbook
- Pravidlo automatizace
- Jiné, pokud se žádná z výše uvedených hodnot nepoužije
Pomocí této podmínky můžete například dát tomuto pravidlu automatizace pokyn, aby se spustilo při jakékoli změně incidentu, s výjimkou případu, kdy ho provedl jiný pravidlo automatizace.
Aktivační událost aktualizace navíc používá další operátory, které kontrolují změny stavu v hodnotách vlastností incidentu a jejich aktuální stav. Podmínka změny stavu by byla splněna v následujících případech:
Hodnota vlastnosti incidentu byla
- změněno (bez ohledu na skutečnou hodnotu před nebo po).
- změna z hodnoty definované v podmínce.
- změna na hodnotu definovanou v podmínce.
- přidáno do (to platí pro vlastnosti se seznamem hodnot).
Vlastnost značky : jednotlivá vs. kolekce
Značka vlastnosti incidentu je kolekce jednotlivých položek – u jednoho incidentu může být použito více značek. Můžete definovat podmínky, které kontrolují jednotlivé značky v kolekci jednotlivě, a podmínky, které kontrolují kolekci značek jako jednotku.
- Všechny operátory jednotlivých značek kontrolují podmínku pro každou značku v kolekci. Vyhodnocení platí, pokud podmínka splňuje alespoň jednu značku.
- Kolekce všech operátorů značek kontroluje podmínku pro kolekci značek jako jednu jednotku. Vyhodnocení platí pouze v případě, že kolekce jako celek splňuje podmínku.
Toto rozlišení záleží, když je vaše podmínka negativní (neobsahuje) a některé značky v kolekci splňují podmínku a jiné ne.
Podívejme se na příklad, kde je vaše podmínka, značka neobsahuje "2024" a máte dva incidenty, z nichž každá má dvě značky:
| \Incidenty ▶ Podmínka ▼ \ |
Incident 1 Značka 1: 2024 Značka 2: 2023 |
Incident 2 Značka 1: 2023 Značka 2: 2022 |
|---|---|---|
| Libovolná jednotlivá značka neobsahuje "2024" |
PRAVDA | TRUE |
| Kolekce všech značek neobsahuje "2024" |
FALSE | TRUE |
V tomto příkladu v incidentu 1:
- Pokud podmínka zkontroluje každou značku jednotlivě, znamená to, že existuje alespoň jedna značka, která splňuje podmínku (která neobsahuje "2024"), je celková podmínka pravdivá.
- Pokud podmínka zkontroluje všechny značky v incidentu jako jednu jednotku, znamená to, že existuje alespoň jedna značka, která nesplňuje podmínku (která obsahuje "2024"), je celková podmínka nepravda.
V incidentu 2 bude výsledek stejný bez ohledu na to, jaký typ podmínky je definován.
Trigger pro vytvoření výstrahy
Jedinou podmínkou, kterou je možné nakonfigurovat pro trigger vytvoření upozornění, je sada analytických pravidel, pro která se pravidlo automatizace spustí.
Akce
Akce je možné definovat, aby se spustily, když jsou splněny podmínky (viz výše). V pravidlu můžete definovat mnoho akcí a můžete zvolit pořadí, ve kterém se budou spouštět (viz níže). Následující akce je možné definovat pomocí pravidel automatizace, aniž by bylo nutné provádět pokročilé funkce playbooku:
Přidání úkolu k incidentu – můžete vytvořit kontrolní seznam úkolů pro analytiky, které budou sledovat v rámci procesů třídění, vyšetřování a nápravy incidentu, abyste zajistili, že nedojde k chybě žádných kritických kroků.
Změna stavu incidentu a udržování pracovního postupu v aktualizovaném stavu
- Při změně na "uzavřeno" zadejte důvod uzavření a přidání komentáře. To vám pomůže sledovat výkon a efektivitu a doladit, abyste snížili falešně pozitivní výsledky.
Změna závažnosti incidentu – můžete znovu vyhodnotit a přepsat na základě přítomnosti, nepřítomnosti, hodnot nebo atributů entit zapojených do incidentu.
Přiřazení incidentu vlastníkovi – to vám pomůže směrovat typy incidentů na pracovníky, kteří jsou nejvhodnější pro jejich řešení nebo pro ty nejpřístupnější pracovníky.
Přidání značky k incidentu – to je užitečné pro klasifikaci incidentů podle předmětu, podle útočníka nebo jakéhokoli jiného společného jmenovatele.
Můžete také definovat akci pro spuštění playbooku, aby bylo možné provádět složitější akce reakce, včetně všech externích systémů. Playbooky, které je možné použít v pravidle automatizace, závisí na triggeru, na kterém jsou založené playbooky a pravidlo automatizace: Pouze playbooky triggeru incidentu je možné spouštět z pravidel automatizace triggeru incidentů a z pravidel automatizace triggeru výstrah je možné spouštět pouze playbooky triggeru upozornění. Můžete definovat více akcí, které volají playbooky, nebo kombinace playbooků a dalších akcí. Akce se spustí v pořadí, v jakém jsou uvedené v pravidle.
Playbooky využívající buď verzi Azure Logic Apps (Standard, nebo Consumption), budou k dispozici ke spuštění z pravidel automatizace.
Datum vypršení platnosti
Datum vypršení platnosti můžete definovat u pravidla automatizace. Pravidlo bude po tomto datu zakázané. To je užitečné pro zpracování (tj. uzavření) incidentů "šumu" způsobených plánovanými, časově omezenými aktivitami, jako je penetrační testování.
Objednávka
Můžete definovat pořadí, ve kterém se budou pravidla automatizace spouštět. Později pravidla automatizace vyhodnotí podmínky incidentu podle jeho stavu po provedení předchozích pravidel automatizace.
Pokud například "První pravidlo automatizace" změnilo závažnost incidentu ze střední na nízké a druhé pravidlo automatizace se definuje tak, aby se spustilo jenom u incidentů se střední nebo vyšší závažností, nespustí se u tohoto incidentu.
Pořadí pravidel automatizace, která přidávají úkoly incidentu, určuje pořadí, ve kterém se úkoly zobrazí v daném incidentu.
Pravidla založená na triggeru aktualizace mají vlastní samostatnou frontu objednávek. Pokud se taková pravidla aktivují tak, aby běžela na právě vytvořeném incidentu (změnou provedenou jiným pravidlem automatizace), spustí se až po spuštění všech příslušných pravidel založených na triggeru vytvoření.
Poznámky k pořadí provádění a prioritě
- Nastavení čísla objednávky v pravidlech automatizace určuje jejich pořadí provádění.
- Každý typ triggeru udržuje svou vlastní frontu.
- U pravidel vytvořených na webu Azure Portal se pole objednávky automaticky vyplní číslem, které následuje za nejvyšším číslem používaným stávajícími pravidly stejného typu triggeru.
- Pro pravidla vytvořená jinými způsoby (příkazový řádek, rozhraní API atd.) je však nutné číslo objednávky přiřadit ručně.
- Neexistuje žádný ověřovací mechanismus, který brání více pravidlům mít stejné číslo objednávky, a to i ve stejném typu triggeru.
- Dvě nebo více pravidel stejného typu triggeru můžete povolit, aby měla stejné číslo objednávky, pokud vám nezáleží na tom, ve kterém pořadí se spouští.
- U pravidel stejného typu triggeru se stejným číslem objednávky modul spouštění náhodně vybere, která pravidla se budou spouštět v jakém pořadí.
- Pro pravidla různých typů triggerů incidentu se spustí všechna příslušná pravidla s typem triggeru vytvoření incidentu jako první (podle jejich čísel objednávek) a teprve potom pravidla s typem triggeru aktualizace incidentu (podle jejich čísel objednávek).
- Pravidla se vždy spouštějí postupně, nikdy paralelně.
Poznámka:
Po připojení k jednotné platformě operací zabezpečení se v případě, že během pěti až desetiminutového období provede několik změn stejného incidentu, odešle se do Microsoft Sentinelu jedna aktualizace s pouze nejnovější změnou.
Běžné scénáře a případy použití
Úkoly incidentu
Pravidla automatizace umožňují standardizovat a formalizovat kroky potřebné pro třídění, vyšetřování a nápravu incidentů vytvořením úloh , které se dají použít na jeden incident, napříč skupinami incidentů nebo pro všechny incidenty podle podmínek, které jste nastavili v pravidle automatizace, a logiky detekce hrozeb v podkladových analytických pravidlech. Úkoly použité na incident se zobrazí na stránce incidentu, takže vaši analytici mají celý seznam akcí, které musí provést, přímo před nimi a nezmešká žádné kritické kroky.
Automatizace aktivovaná incidenty a výstrahy
Pravidla automatizace se dají aktivovat vytvořením nebo aktualizací incidentů a také vytvořením výstrah. Všechny tyto výskyty můžou aktivovat automatizované řetězy odpovědí, které můžou zahrnovat playbooky (vyžadují se speciální oprávnění).
Aktivace playbooků pro poskytovatele Microsoftu
Pravidla automatizace poskytují způsob, jak automatizovat zpracování výstrah zabezpečení Microsoftu použitím těchto pravidel na incidenty vytvořené z výstrah. Pravidla automatizace můžou volat playbooky (vyžadují se zvláštní oprávnění) a předat jim incidenty se všemi podrobnostmi, včetně výstrah a entit. Obecně platí, že osvědčené postupy Microsoft Sentinelu určují použití fronty incidentů jako ústředního bodu operací zabezpečení.
Výstrahy zabezpečení Společnosti Microsoft zahrnují následující:
- Ochrana Microsoft Entra ID
- Microsoft Defender for Cloud
- Microsoft Defender for Cloud Apps
- Microsoft Defender for Office 365
- Microsoft Defender for Endpoint
- Microsoft Defender for Identity
- Microsoft Defender for IoT
Více sekvencovaných playbooků a akcí v jednom pravidlu
Teď můžete mít téměř úplnou kontrolu nad pořadím provádění akcí a playbooků v jediném pravidlu automatizace. Řídíte také pořadí provádění samotných pravidel automatizace. To vám umožní výrazně zjednodušit playbooky, omezit je na jeden úkol nebo na malou, jednoduchou posloupnost úkolů a kombinovat tyto malé playbooky v různých kombinacích v různých pravidlech automatizace.
Přiřazení jednoho playbooku k více analytickým pravidlům najednou
Pokud máte úkol, který chcete automatizovat ve všech analytických pravidlech – například vytvoření lístku podpory v externím systému lístků – můžete použít jeden playbook na libovolná nebo všechna analytická pravidla – včetně jakýchkoli budoucích pravidel – na jednom snímku. Díky tomu je jednoduchá, ale opakující se údržba a úklid úkolů mnohem méně práce.
Automatické přiřazení incidentů
Incidenty můžete automaticky přiřadit správnému vlastníkovi. Pokud má váš SOC analytika, který se specializuje na konkrétní platformu, všechny incidenty související s danou platformou se dají danému analytikovi automaticky přiřadit.
Potlačení incidentů
Pravidla můžete použít k automatickému řešení incidentů, které jsou známé jako falešně/neškodné pozitivní výsledky bez použití playbooků. Například při spouštění penetračních testů, provádění plánované údržby nebo upgradů nebo testovacích automatizačních procedur může být vytvořeno mnoho falešně pozitivních incidentů, které soC chce ignorovat. Pravidlo automatizace s časovým limitem může tyto incidenty automaticky zavřít při jejich vytváření a zároveň je označit popisovačem příčiny jejich generování.
Časově omezená automatizace
Pro pravidla automatizace můžete přidat data vypršení platnosti. Mohou existovat jiné případy než potlačení incidentů, které zaručují časově omezenou automatizaci. Konkrétní typ incidentu můžete konkrétnímu uživateli (například internovi nebo konzultantovi) přiřadit pro určitý časový rámec. Pokud je časový rámec známý předem, můžete účinně způsobit, že pravidlo bude zakázané na konci jeho levnosti, aniž byste si to museli pamatovat.
Automatické označování incidentů
Do incidentů můžete automaticky přidávat značky volného textu, abyste je seskupili nebo klasifikovali podle libovolných kritérií podle vašeho výběru.
Případy použití přidané triggerem aktualizace
Teď, když změny provedené v incidentech můžou aktivovat pravidla automatizace, jsou pro automatizaci otevřené další scénáře.
Rozšíření automatizace při vývoji incidentu
Trigger aktualizace můžete použít k použití mnoha výše uvedených případů použití incidentů v průběhu vyšetřování a analytici přidávají výstrahy, komentáře a značky. Řízení seskupení výstrah v incidentech
Aktualizace orchestrace a oznámení
Upozorněte různé týmy a další pracovníky, když dojde k nějakým změnám incidentů, aby nezmeškali žádné důležité aktualizace. Eskalujte incidenty tím, že je přiřadíte novým vlastníkům a informujete nové vlastníky o svých přiřazeních. Řízení, kdy a jak se incidenty znovu otevřou.
Údržba synchronizace s externími systémy
Pokud jste při vytváření incidentů vytvořili lístky v externích systémech pomocí playbooků, můžete pomocí pravidla automatizace triggeru aktualizace volat playbook, který tyto lístky aktualizuje.
Spouštění pravidel automatizace
Pravidla automatizace se spouští postupně podle pořadí, které určíte. Každé pravidlo automatizace se spustí poté, co předchozí pravidlo dokončí jeho spuštění. V rámci pravidla automatizace se všechny akce spouštějí postupně v pořadí, v jakém jsou definovány.
Akce playbooku v rámci pravidla automatizace se můžou za určitých okolností zacházet odlišně podle následujících kritérií:
| Čas běhu playbooku | Pravidlo automatizace přejde na další akci... |
|---|---|
| Méně než sekunda | Ihned po dokončení playbooku |
| Méně než dvě minuty | Až dvě minuty po spuštění playbooku, ale po dokončení playbooku maximálně 10 sekund |
| Více než dvě minuty | Dvě minuty po spuštění playbooku, bez ohledu na to, zda byl dokončen nebo nebyl dokončen |
Oprávnění pro pravidla automatizace ke spouštění playbooků
Když pravidlo automatizace Microsoft Sentinelu spustí playbook, použije pro tuto akci speciální účet služby Microsoft Sentinel, který je speciálně autorizovaný. Použití tohoto účtu (na rozdíl od vašeho uživatelského účtu) zvyšuje úroveň zabezpečení služby.
Aby mohlo pravidlo automatizace spustit playbook, tento účet musí mít udělená explicitní oprávnění ke skupině prostředků, ve které se playbook nachází. Pak bude moct jakékoli pravidlo automatizace spustit jakýkoli playbook v dané skupině prostředků.
Když konfigurujete pravidlo automatizace a přidáte akci run playbooku, zobrazí se rozevírací seznam playbooků. Playbooky, ke kterým Microsoft Sentinel nemá oprávnění, se zobrazí jako nedostupné (šedě). Microsoft Sentinel můžete udělit oprávnění ke skupinám prostředků playbooků na místě výběrem odkazu Spravovat oprávnění playbooku. K udělení těchto oprávnění budete potřebovat oprávnění vlastníka těchto skupin prostředků. Podívejte se na úplné požadavky na oprávnění.
Oprávnění ve víceklientové architektuře
Pravidla automatizace plně podporují nasazení mezi pracovními prostory a více tenanty (v případě víceklientů pomocí Azure Lighthouse).
Proto pokud vaše nasazení Microsoft Sentinelu používá víceklientské architektury, můžete mít v jednom tenantovi pravidlo automatizace, které běží v jiném tenantovi, ale oprávnění pro Sentinel ke spouštění playbooků musí být definována v tenantovi, kde se nacházejí playbooky, ne v tenantovi, ve kterém jsou definovaná pravidla automatizace.
V konkrétním případě poskytovatele spravované služby zabezpečení (MSSP), kde tenant poskytovatele služeb spravuje pracovní prostor Služby Microsoft Sentinel v tenantovi zákazníka, existují dva konkrétní scénáře, které vyžadují vaši pozornost:
Pravidlo automatizace vytvořené v tenantovi zákazníka je nakonfigurováno pro spuštění playbooku umístěného v tenantovi poskytovatele služeb.
Tento přístup se obvykle používá k ochraně duševního vlastnictví v playbooku. Pro tento scénář není potřeba nic zvláštního. Při definování akce playbooku v pravidlu automatizace a dostanete se do fáze, ve které udělíte microsoft Sentinel oprávnění k příslušné skupině prostředků, ve které se playbook nachází (pomocí panelu Spravovat oprávnění playbooku), uvidíte skupiny prostředků patřící do tenanta poskytovatele služeb mezi těmi, ze kterých si můžete vybrat. Podívejte se na celý proces, který je zde popsaný.
Pravidlo automatizace vytvořené v pracovním prostoru zákazníka (při přihlášení k tenantovi poskytovatele služeb) je nakonfigurované pro spuštění playbooku umístěného v tenantovi zákazníka.
Tato konfigurace se používá, když není potřeba chránit duševní vlastnictví. Aby tento scénář fungoval, musí být oprávnění ke spuštění playbooku udělena službě Microsoft Sentinel v obou tenantech. V tenantovi zákazníka je udělíte na panelu Spravovat oprávnění playbooku stejně jako ve výše uvedeném scénáři. Pokud chcete udělit příslušná oprávnění v tenantovi poskytovatele služeb, musíte přidat další delegování Azure Lighthouse, které uděluje přístupová práva k aplikaci Azure Security Přehledy s rolí Přispěvatel služby Microsoft Sentinel Automation ve skupině prostředků, ve které se nachází playbook.
Scénář vypadá takto:
Vytváření a správa pravidel automatizace
V závislosti na konkrétní potřebě a použití můžete vytvářet a spravovat pravidla automatizace z různých oblastí v Microsoft Sentinelu nebo na jednotné platformě operací zabezpečení.
Stránka Automation
Pravidla automatizace je možné centrálně spravovat na stránce Automation na kartě Pravidla automatizace. Odtud můžete vytvořit nová pravidla automatizace a upravit stávající pravidla. Pravidla automatizace můžete také přetáhnout, aby se změnilo pořadí provádění, a můžete je povolit nebo zakázat.
Na stránce Automation uvidíte všechna pravidla definovaná v pracovním prostoru spolu se stavem (Povoleno/Zakázáno) a na která analytická pravidla se použijí.
Pokud potřebujete pravidlo automatizace, které bude platit pro incidenty z XDR v programu Microsoft Defender nebo z mnoha analytických pravidel v Microsoft Sentinelu, vytvořte ho přímo na stránce Automation .
Průvodce analytickým pravidlem
Na kartě Automatizovaná odpověď v průvodci analytickým pravidlem Služby Microsoft Sentinel můžete v části Pravidla automatizace zobrazit, upravit a vytvořit pravidla automatizace, která se vztahují na konkrétní analytické pravidlo, které se v průvodci vytváří nebo upravuje.
Všimněte si, že když tady vytvoříte pravidlo automatizace, zobrazí se na panelu Vytvořit nové pravidlo automatizace podmínka analytického pravidla jako nedostupná, protože toto pravidlo je už nastavené tak, aby platilo jenom pro analytické pravidlo, které upravujete v průvodci. Všechny ostatní možnosti konfigurace jsou pro vás stále dostupné.
Stránka Incidenty
Můžete také vytvořit pravidlo automatizace ze stránky Incidenty , aby bylo možné reagovat na jeden opakovaný incident. To je užitečné při vytváření pravidla potlačení pro automatické zavření "hlučných" incidentů.
Všimněte si, že když tady vytvoříte pravidlo automatizace, panel Vytvořit nové pravidlo automatizace naplní všechna pole hodnotami z incidentu. Pojmenuje pravidlo stejným názvem jako incident, použije ho na analytické pravidlo, které incident vygenerovalo, a jako podmínky pravidla použije všechny dostupné entity v incidentu. Ve výchozím nastavení navrhuje také akci potlačení (uzavření) a navrhne datum vypršení platnosti pravidla. Můžete přidat nebo odebrat podmínky a akce a změnit datum vypršení platnosti podle potřeby.
Další kroky
V tomto dokumentu jste se dozvěděli, jak vám pravidla automatizace můžou pomoct centrálně spravovat automatizaci odpovědí pro incidenty a výstrahy Microsoft Sentinelu.
- Vytvářejte a používejte pravidla automatizace Microsoft Sentinelu ke správě incidentů.
- Pomocí pravidel automatizace můžete vytvářet seznamy úkolů pro analytiky.
- Další informace o pokročilých možnostech automatizace najdete v tématu Automatizace reakcí na hrozby pomocí playbooků v Microsoft Sentinelu.
- Nápovědu k implementaci playbooků najdete v tématu Kurz: Použití playbooků k automatizaci reakcí na hrozby v Microsoft Sentinelu.