Felsöka analysregler i Microsoft Sentinel

  • Artikel

Den här artikeln beskriver hur du hanterar vissa problem som kan uppstå vid körning av schemalagda analysregler i Microsoft Sentinel.

Problem: Inga händelser visas i frågeresultat

När händelsegruppering är inställt på att utlösa en avisering för varje händelse kan frågeresultat som visas vid ett senare tillfälle verka saknas eller vara annorlunda än förväntat. Du kan till exempel visa en frågas resultat vid ett senare tillfälle när du undersöker en relaterad incident, och som en del av den undersökningen bestämmer du dig för att pivotera tillbaka till den här frågans tidigare resultat.

Resultaten sparas automatiskt med aviseringarna. Men om resultatet är för stort sparas inga resultat och inga data visas när du visar frågeresultatet igen.

Om det uppstår inmatningsfördröjning eller om frågan inte är deterministisk på grund av aggregering kan aviseringens resultat skilja sig från det resultat som visas genom att köra frågan manuellt.

För att lösa det här problemet lägger Microsoft Sentinel till fältet OriginalQuery i resultatet av frågan när en regel har den här inställningen för händelsegruppering. Här är en jämförelse av det befintliga frågefältet och det nya fältet:

Fältnamn Innehåller Köra frågan i det här fältet
resulterar i...
Fråga Den komprimerade posten för händelsen som genererade den här instansen av aviseringen. Händelsen som genererade den här instansen av aviseringen.
10 kilobyte.
OriginalQuery Den ursprungliga frågan som skrivits i analysregeln. Den senaste händelsen i tidsramen där frågan körs, som passar de parametrar som definierats av frågan.

Med andra ord fungerar fältet OriginalQuery som om fältet Fråga beter sig under standardinställningen för händelsegruppering.

Problem: En schemalagd regel kunde inte köras eller visas med AUTO DISABLED tillagt i namnet

Det är ovanligt att en schemalagd frågeregel inte kan köras, men det kan inträffa. Microsoft Sentinel klassificerar fel i förväg som antingen tillfälliga eller permanenta, baserat på den specifika typen av fel och de omständigheter som ledde till det.

Tillfälligt fel

Ett tillfälligt fel inträffar på grund av en situation som är tillfällig och snart återgår till det normala, då regelkörningen lyckas. Några exempel på fel som Microsoft Sentinel klassificerar som tillfälliga är:

  • En regelfråga tar för lång tid att köra och tidsgränsen överskrids.
  • Anslut ivitetsproblem mellan datakällor och Log Analytics, eller mellan Log Analytics och Microsoft Sentinel.
  • Andra nya och okända fel anses vara tillfälliga.

I händelse av ett tillfälligt fel fortsätter Microsoft Sentinel att försöka köra regeln igen efter förutbestämda och ständigt ökande intervall, upp till en punkt. Därefter körs regeln endast igen vid nästa schemalagda tidpunkt. En regel kan aldrig identifieras automatiskt på grund av ett tillfälligt fel.

Permanent fel – regeln kan identifieras automatiskt

Ett permanent fel inträffar på grund av en ändring i villkoren som tillåter att regeln körs, vilket utan mänsklig inblandning inte kan återgå till sin tidigare status. Följande är några exempel på fel som klassificeras som permanenta:

  • Målarbetsytan (där regelfrågan kördes) togs bort.
  • Måltabellen (där regelfrågan kördes) togs bort.
  • Microsoft Sentinel har tagits bort från målarbetsytan.
  • En funktion som används av regelfrågan är inte längre giltig. Den har antingen ändrats eller tagits bort.
  • Behörigheter till en av datakällorna i regelfrågan ändrades (se exempel).
  • En av datakällorna i regelfrågan har tagits bort.

I händelse av ett förutbestämt antal på varandra följande permanenta fel, av samma typ och på samma regel, slutar Microsoft Sentinel att försöka köra regeln och utför även följande steg:

  1. Inaktiverar regeln.
  2. Lägger till orden "AUTO DISABLED" i början av regelns namn.
  3. Lägger till orsaken till felet (och inaktivering) i regelns beskrivning.

Du kan enkelt fastställa förekomsten av regler som kan identifieras automatiskt genom att sortera regellistan efter namn. Reglerna för automatisk upptäckt finns högst upp i listan.

SOC-chefer bör se till att kontrollera regellistan regelbundet för förekomsten av regler för automatisk upptäckt.

Permanent fel på grund av resursavlopp

En annan typ av permanent fel uppstår på grund av en felaktigt skapad fråga som gör att regeln förbrukar överdrivna databehandlingsresurser och riskerar att bli ett prestandadränage på dina system. När Microsoft Sentinel identifierar en sådan regel tar den samma tre steg som nämns för de andra typerna av permanenta fel– inaktiverar regeln, förbereder "AUTO DISABLED" till regelnamnet och lägger till orsaken till att beskrivningen misslyckas.

Om du vill återaktivera regeln måste du åtgärda problemen i frågan som gör att den använder för många resurser. I följande artiklar finns metodtips för att optimera dina Kusto-frågor:

Mer information finns i Användbara resurser för att arbeta med Kusto-frågespråk i Microsoft Sentinel.

Permanent fel på grund av förlorad åtkomst mellan prenumerationer/klientorganisationer

Ett särskilt exempel på när ett permanent fel kan inträffa på grund av en behörighetsändring på en datakälla (se listan) gäller fallet med en Microsoft Security Solution Provider (MSSP)– eller något annat scenario där analysregler frågar mellan prenumerationer eller klienter.

När du skapar en analysregel tillämpas en åtkomstbehörighetstoken på regeln och sparas tillsammans med den. Den här token säkerställer att regeln kan komma åt arbetsytan som innehåller tabellerna som refereras till av regelns fråga och att den här åtkomsten upprätthålls även om regelns skapare förlorar åtkomsten till den arbetsytan.

Det finns dock ett undantag: När en regel skapas för åtkomst till arbetsytor i andra prenumerationer eller klientorganisationer, till exempel vad som händer vid en MSSP, vidtar Microsoft Sentinel extra säkerhetsåtgärder för att förhindra obehörig åtkomst till kunddata. Den här typen av regler har autentiseringsuppgifterna för den användare som skapade regeln som tillämpades på dem, i stället för en oberoende åtkomsttoken. När användaren inte längre har åtkomst till den andra klientorganisationen slutar regeln att fungera.

Om du använder Microsoft Sentinel i ett scenario mellan prenumerationer eller flera innehavare, och om någon av dina analytiker eller tekniker förlorar åtkomst till en viss arbetsyta, slutar alla regler som skapats av användaren att fungera. Du får ett hälsoövervakningsmeddelande om "otillräcklig åtkomst till resursen" och regeln kan identifieras automatiskt enligt den procedur som beskrevs tidigare.

Nästa steg

Mer information finns i:

Lär dig också från ett exempel på hur du använder anpassade analysregler när du övervakar Zoom med en anpassad anslutningsapp.