Sdílet prostřednictvím

Řešení potíží s analytickými pravidly v Microsoft Sentinelu

  • Článek

Tento článek vysvětluje, jak řešit určité problémy, ke kterým může dojít při provádění plánovaných analytických pravidel v Microsoft Sentinelu.

Problém: Ve výsledcích dotazu se nezobrazují žádné události

Když je seskupení událostí nastavené tak, aby aktivovalo upozornění pro každou událost, může se zobrazit, že výsledky dotazu zobrazené později chybí nebo se liší od očekávání. Výsledky dotazu můžete například zobrazit později při vyšetřování souvisejícího incidentu a v rámci tohoto šetření se rozhodnete vrátit zpět k dřívějším výsledkům tohoto dotazu.

Výsledky se automaticky ukládají s upozorněními. Pokud jsou ale výsledky příliš velké, neuloží se žádné výsledky a při opětovném zobrazení výsledků dotazu se nezobrazí žádná data.

V případech, kdy dochází ke zpoždění příjmu dat nebo dotaz není deterministický kvůli agregaci, může se výsledek výstrahy lišit od výsledku zobrazeného ručním spuštěním dotazu.

Pokud má pravidlo toto nastavení seskupení událostí, Microsoft Sentinel tento problém vyřeší tím, že do výsledků dotazu přidá pole OriginalQuery . Tady je porovnání stávajícího pole Dotazu a nového pole:

Název pole Contains Spuštění dotazu v tomto poli
výsledky v...
Dotaz Komprimovaný záznam události, která vygenerovala tuto instanci výstrahy. Událost, která vygenerovala tuto instanci výstrahy;
omezeno na 10 kilobajtů.
OriginalQuery Původní dotaz napsaný v analytickém pravidle. Poslední událost v časovém rámci, ve kterém se dotaz spouští, odpovídá parametrům definovaným dotazem.

Jinými slovy, pole OriginalQuery se chová stejně jako pole Dotazu se chová pod výchozím nastavením seskupení událostí.

Problém: Naplánované pravidlo se nepodařilo spustit nebo je k jeho názvu přidaný text AUTO DISABLED.

Jedná se o vzácný výskyt, kdy se naplánované pravidlo dotazu nepodaří spustit, ale může k němu dojít. Microsoft Sentinel klasifikuje chyby předem jako přechodné nebo trvalé na základě konkrétního typu selhání a okolností, které k němu vedly.

Přechodné selhání

K přechodnému selhání dochází kvůli okolnostem, která je dočasná a brzy se vrátí do normálu, v tomto okamžiku se spuštění pravidla úspěšně provede. Mezi příklady selhání, která Microsoft Sentinel klasifikuje jako přechodné, patří:

  • Spuštění dotazu pravidla trvá příliš dlouho a vyprší časový limit.
  • Problémy s připojením mezi zdroji dat a Log Analytics nebo mezi Log Analytics a Microsoft Sentinelem
  • Jakékoli jiné nové a neznámé selhání se považuje za přechodné.

V případě přechodného selhání se Microsoft Sentinel po předem určených a stále rostoucích intervalech až do bodu pokouší znovu spustit pravidlo. Poté se pravidlo spustí znovu pouze při příštím naplánovaném čase. Pravidlo se nikdy automaticky nerozpozná kvůli přechodnému selhání.

Trvalé selhání – automatické nastavení pravidla

K trvalému selhání dochází kvůli změně podmínek, které umožňují pravidlo spustit, což bez zásahu člověka nemůže vrátit k dřívějšímu stavu. Tady je několik příkladů selhání, která jsou klasifikovaná jako trvalá:

  • Cílový pracovní prostor (na kterém byl dotaz pravidla provozován) byl odstraněn.
  • Cílová tabulka (na které byl dotaz pravidla provozován) byla odstraněna.
  • Služba Microsoft Sentinel byla odebrána z cílového pracovního prostoru.
  • Funkce používaná dotazem pravidla již není platná; byl změněn nebo odebrán.
  • Oprávnění k jednomu ze zdrojů dat dotazu pravidla se změnila (viz příklad).
  • Jeden ze zdrojů dat dotazu pravidla byl odstraněn.

V případě předem určeného počtu po sobě jdoucích trvalých selhání stejného typu a stejného pravidla se Microsoft Sentinel přestane pokoušet pravidlo spustit a provede také následující kroky:

  1. Zakáže pravidlo.
  2. Přidá slova "AUTO DISABLED" na začátek názvu pravidla.
  3. Přidá do popisu pravidla důvod selhání (a zakázání).

Přítomnost všech automatickydisabled pravidel můžete snadno určit seřazením seznamu pravidel podle názvu. Automaticky konfigurovatelná pravidla jsou v horní části seznamu nebo v horní části seznamu.

Správci SOC by měli mít jistotu, že seznam pravidel pravidelně kontroluje přítomnost automatickydisabled pravidel.

Trvalé selhání kvůli vyprázdnění prostředků

K dalšímu druhu trvalého selhání dochází kvůli nesprávně sestaveným dotazům , které způsobí, že pravidlo spotřebuje nadměrné výpočetní prostředky a riskuje vyčerpání výkonu ve vašich systémech. Když Microsoft Sentinel takové pravidlo identifikuje, použije stejné tři kroky uvedené pro ostatní typy trvalých selhání – zakáže pravidlo, předpne "AUTO DISABLED" k názvu pravidla a přidá do popisu důvod selhání.

Pokud chcete pravidlo znovu povolit, musíte vyřešit problémy v dotazu, které způsobují, že používá příliš mnoho prostředků. Osvědčené postupy optimalizace dotazů Kusto najdete v následujících článcích:

Další pomoc najdete také v užitečných zdrojích informací pro práci s dotazovací jazyk Kusto v Microsoft Sentinelu.

Trvalé selhání kvůli ztrátě přístupu mezi předplatnými nebo tenanty

Jeden konkrétní příklad, kdy může dojít k trvalému selhání kvůli změně oprávnění u zdroje dat (viz seznam), se týká případu poskytovatele řešení zabezpečení Microsoftu (MSSP) nebo jakéhokoli jiného scénáře, ve kterém se pravidla analýzy dotazují napříč předplatnými nebo tenanty.

Při vytváření analytického pravidla se na pravidlo použije token přístupových oprávnění a uloží se spolu s ním. Tento token zajistí, že pravidlo bude mít přístup k pracovnímu prostoru, který obsahuje tabulky odkazované dotazem pravidla, a že tento přístup se zachová i v případě, že tvůrce pravidla ztratí přístup k tomuto pracovnímu prostoru.

Existuje však jedna výjimka: Když se pravidlo vytvoří pro přístup k pracovním prostorům v jiných předplatných nebo tenantech, například co se stane v případě mssp, Microsoft Sentinel přijímá další bezpečnostní opatření, která brání neoprávněnému přístupu k zákaznickým datům. Tyto typy pravidel mají přihlašovací údaje uživatele, který na ně vytvořil pravidlo použité místo nezávislého přístupového tokenu. Pokud už uživatel nemá přístup k jinému tenantovi, pravidlo přestane fungovat.

Pokud provozujete Microsoft Sentinel ve scénáři mezi předplatnými nebo mezi tenanty a pokud některý z analytiků nebo techniků ztratí přístup ke konkrétnímu pracovnímu prostoru, přestanou fungovat všechna pravidla vytvořená tímto uživatelem. Zobrazí se zpráva monitorování stavu týkající se nedostatečného přístupu k prostředku a pravidlo se automaticky rozpozná podle výše popsaného postupu.

Další kroky

Další informace naleznete v tématu:

Také se naučíte z příkladu použití vlastních analytických pravidel při monitorování zoomu pomocí vlastního konektoru.