Feilsøk analyseregler i Microsoft Sentinel

Viktig

Egendefinerte gjenkjenninger er nå den beste måten å opprette nye regler på tvers av Microsoft Sentinel SIEM-Microsoft Defender XDR. Med egendefinerte oppdagelser kan du redusere inntakskostnader, få ubegrensede sanntidsgjenkjenninger og dra nytte av sømløs integrering med Defender XDR data, funksjoner og utbedringshandlinger med automatisk enhetstilordning. Hvis du vil ha mer informasjon, kan du lese denne bloggen.

Denne artikkelen forklarer hvordan du håndterer visse problemer som kan oppstå med kjøring av planlagte analyseregler i Microsoft Sentinel.

Problem: Ingen hendelser vises i spørringsresultater

Når hendelsesgruppering er satt til å utløse et varsel for hver hendelse, kan det hende at spørringsresultatene som vises på et senere tidspunkt, mangler eller er forskjellig fra forventet. Du kan for eksempel vise resultatene for en spørring på et senere tidspunkt når du undersøker en relatert hendelse, og som en del av undersøkelsen bestemmer du deg for å gå tilbake til spørringens tidligere resultater.

Resultatene lagres automatisk med varslene. Hvis resultatene imidlertid er for store, lagres ingen resultater, og ingen data vises når du viser spørringsresultatene på nytt.

I tilfeller der det er inntaksforsinkelse, eller spørringen ikke er deterministisk på grunn av aggregasjon, kan resultatet av varselet være forskjellig fra resultatet som vises ved å kjøre spørringen manuelt.

Hvis du vil løse dette problemet, legger Microsoft Sentinel til OriginalQuery-feltet i resultatene av spørringen når en regel har denne innstillingen for hendelsesgruppering. Her er en sammenligning av det eksisterende spørringsfeltet og det nye feltet:

Feltnavn Inneholder Kjører spørringen i dette feltet
resulterer i...
Spørring Den komprimerte posten for hendelsen som genererte denne forekomsten av varselet. Hendelsen som genererte denne forekomsten av varselet.
begrenset til 10 kilobyte.
OriginalQuery Den opprinnelige spørringen som er skrevet i analyseregelen. Den nyeste hendelsen i tidsrammen der spørringen kjøres, som passer til parameterne som er definert av spørringen.

OriginalQuery-feltet fungerer med andre ord som om spørringsfeltet fungerer under standardinnstillingen for hendelsesgruppering.

Problem: En planlagt regel kan ikke kjøres, eller vises med AUTO DISABLED lagt til i navnet

Det er en sjelden forekomst at en planlagt spørringsregel ikke kan kjøres, men det kan skje. Microsoft Sentinel klassifiserer feil på forhånd som enten midlertidige eller permanente, basert på den spesifikke typen av feilen og omstendighetene som førte til den.

Midlertidig feil

En midlertidig feil oppstår på grunn av en situasjon som er midlertidig og snart går tilbake til normal, og da lykkes regelkjøringen. Noen eksempler på feil som Microsoft Sentinel klassifiseres som forbigående, er:

  • En regelspørring tar for lang tid å kjøre og blir tidsavbrutt.
  • Tilkoblingsproblemer mellom datakilder og log analytics, eller mellom Log Analytics og Microsoft Sentinel.
  • Alle andre nye og ukjente feil anses som midlertidige.

Hvis det oppstår en midlertidig feil, fortsetter Microsoft Sentinel å prøve å kjøre regelen på nytt etter forhåndsbestemte og stadig økende intervaller, opptil et punkt. Etter dette kjøres regelen på nytt bare ved neste planlagte tidspunkt. En regel blir aldri autodisablert på grunn av en midlertidig feil.

Permanent feil – autodisabler regel

En permanent feil oppstår på grunn av en endring i betingelsene som tillater regelen å kjøre, som uten menneskelig inngripen ikke kan gå tilbake til sin tidligere status. Nedenfor finner du noen eksempler på feil som klassifiseres som permanente:

  • Målarbeidsområdet (der regelspørringen ble slettet).
  • Måltabellen (som regelspørringen ble slettet på).
  • Microsoft Sentinel ble fjernet fra målarbeidsområdet.
  • En funksjon som brukes av regelspørringen, er ikke lenger gyldig. den ble enten endret eller fjernet.
  • Tillatelser til én av datakildene i regelspørringen ble endret (se eksempel).
  • En av datakildene for regelspørringen ble slettet.

Hvis det oppstår et forhåndsbestemt antall påfølgende permanente feil, av samme type og på samme regel, Microsoft Sentinel slutter å prøve å kjøre regelen, og gjør også følgende:

  1. Deaktiverer regelen.
  2. Legger til ordene «AUTO DISABLED» i begynnelsen av regelens navn.
  3. Legger til årsaken til feilen (og deaktiveringen) i regelens beskrivelse.

Du kan enkelt bestemme om det finnes autodisabled-regler, ved å sortere regellisten etter navn. Reglene for autodisabled er på eller nær toppen av listen.

SOC-ansvarlige bør kontrollere regellisten regelmessig for tilstedeværelse av autodisabled-regler.

Permanent feil på grunn av ressursavløp

En annen type permanent feil oppstår på grunn av en feilbygd spørring som fører til at regelen forbruker overflødige databehandlingsressurser og risikerer å bli et ytelsesavløp på systemene dine. Når Microsoft Sentinel identifiserer en slik regel, utfører den de samme tre trinnene som er nevnt for de andre typene permanente feil – deaktiverer regelen, klargjør «AUTO DISABLED» til regelnavnet, og legger til årsaken til feilen i beskrivelsen.

Hvis du vil aktivere regelen på nytt, må du løse problemene i spørringen som fører til at den bruker for mange ressurser. Hvis du vil ha mer informasjon, kan du se:

Permanent feil på grunn av tapt tilgang på tvers av abonnementer/leiere

Et bestemt eksempel på når en permanent feil kan oppstå på grunn av en endring av tillatelser på en datakilde (se listen), gjelder saken om en Microsoft Security Solution Provider (MSSP)– eller et annet scenario der analyseregler spør på tvers av abonnementer eller leiere.

Når du oppretter en analyseregel, brukes et tilgangstillatelsestoken på regelen og lagres sammen med den. Dette tokenet sikrer at regelen får tilgang til arbeidsområdet som inneholder tabellene som det refereres til i regelens spørring, og at denne tilgangen opprettholdes selv om regelens oppretter mister tilgangen til dette arbeidsområdet.

Det finnes imidlertid ett unntak: Når en regel opprettes for å få tilgang til arbeidsområder i andre abonnementer eller leiere, for eksempel hva som skjer når det gjelder en MSSP, tar Microsoft Sentinel ekstra sikkerhetstiltak for å forhindre uautorisert tilgang til kundedata. Disse reglene har legitimasjonen til brukeren som opprettet regelen, i stedet for et uavhengig tilgangstoken. Når brukeren ikke lenger har tilgang til den andre leieren, slutter regelen å fungere.

Hvis du opererer Microsoft Sentinel i et scenario på tvers av abonnementer eller på tvers av leiere, og hvis en av analytikerne eller teknikerne dine mister tilgang til et bestemt arbeidsområde, slutter alle regler som opprettes av denne brukeren å fungere. Du får en melding om tilstandsovervåking angående «utilstrekkelig tilgang til ressurs», og regelen vil bli automatisk diskutert i henhold til prosedyren som er beskrevet tidligere.

Neste trinn

Hvis du vil ha mer informasjon, kan du se:

Lær også fra et eksempel på bruk av egendefinerte analyseregler når du overvåker Zoom med en egendefinert kobling.