Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Vigtigt!
Brugerdefinerede registreringer er nu den bedste måde at oprette nye regler på tværs af Microsoft Sentinel SIEM-Microsoft Defender XDR. Med brugerdefinerede registreringer kan du reducere omkostningerne til indtagelse, få ubegrænsede registreringer i realtid og drage fordel af problemfri integration med Defender XDR data, funktioner og afhjælpningshandlinger med automatisk enhedstilknytning. Du kan få flere oplysninger ved at læse denne blog.
I denne artikel forklares det, hvordan du håndterer visse problemer, der kan opstå i forbindelse med udførelse af planlagte analyseregler i Microsoft Sentinel.
Problem: Der vises ingen hændelser i forespørgselsresultater
Når hændelsesgruppering er indstillet til at udløse en besked for hver hændelse, kan forespørgselsresultater, der vises på et senere tidspunkt, se ud til at mangle eller være anderledes end forventet. Du kan f.eks. få vist resultaterne af en forespørgsel på et senere tidspunkt, når du undersøger en relateret hændelse, og som en del af undersøgelsen beslutter du at vende tilbage til forespørgslens tidligere resultater.
Resultaterne gemmes automatisk sammen med beskederne. Men hvis resultaterne er for store, gemmes der ingen resultater, og der vises ingen data, når forespørgselsresultaterne vises igen.
I tilfælde, hvor der er forsinkelse i indtagelse, eller forespørgslen ikke er deterministisk pga. sammenlægning, kan beskedens resultat være anderledes end det resultat, der vises ved at køre forespørgslen manuelt.
Hvis du vil løse dette problem, når en regel har denne indstilling for hændelsesgruppering, føjer Microsoft Sentinel feltet OriginalQuery til resultaterne af forespørgslen. Her er en sammenligning af det eksisterende forespørgselsfelt og det nye felt:
| Feltnavn | Indeholder | Kørsel af forespørgslen i dette felt resulterer i... |
|---|---|---|
| Forespørgsel | Den komprimerede post for den hændelse, der genererede denne forekomst af beskeden. | Hændelsen, der genererede denne forekomst af beskeden. begrænset til 10 kilobyte. |
| OriginalQuery | Den oprindelige forespørgsel, som skrevet i analysereglen. | Den seneste hændelse i den tidsramme, som forespørgslen kører i, og som passer til de parametre, der er defineret af forespørgslen. |
Med andre ord fungerer feltet OriginalQuery , som om feltet Forespørgsel fungerer under standardindstillingen for hændelsesgruppering.
Problem: En planlagt regel blev ikke udført, eller den vises, hvor AUTO DISABLED er føjet til navnet
Det er en sjælden forekomst, at en planlagt forespørgselsregel ikke kan køre, men det kan ske. Microsoft Sentinel klassificerer fejl på forhånd som enten midlertidige eller permanente, baseret på den specifikke type fejl og de omstændigheder, der førte til den.
Midlertidig fejl
Der opstår en midlertidig fejl på grund af en situation, der er midlertidig og snart vender tilbage til normal, hvorefter udførelsen af reglen lykkes. Eksempler på fejl, der Microsoft Sentinel klassificeres som midlertidige, er:
- Det tager for lang tid at køre en regelforespørgsel, og der er timeout.
- Forbindelsesproblemer mellem datakilder og Log Analytics eller mellem Log Analytics og Microsoft Sentinel.
- Alle andre nye og ukendte fejl betragtes som midlertidige.
I tilfælde af en forbigående fejl fortsætter Microsoft Sentinel med at udføre reglen igen efter forudbestemte og stadig stigende intervaller op til et punkt. Derefter køres reglen først igen på det næste planlagte tidspunkt. En regel kan aldrig automatisk distribueres på grund af en forbigående fejl.
Permanent fejl – reglen kan automatisk distribueres
Der opstår en permanent fejl på grund af en ændring i de betingelser, der tillader, at reglen kører, som uden menneskelig indgriben ikke kan vende tilbage til deres tidligere status. Følgende er nogle eksempler på fejl, der er klassificeret som permanente:
- Destinationsarbejdsområdet (som regelforespørgslen kørte på) blev slettet.
- Destinationstabellen (som regelforespørgslen kørte på) blev slettet.
- Microsoft Sentinel blev fjernet fra målarbejdsområdet.
- En funktion, der bruges af regelforespørgslen, er ikke længere gyldig. Den blev enten ændret eller fjernet.
- Tilladelserne til en af datakilderne i regelforespørgslen blev ændret (se eksempel).
- En af datakilderne for regelforespørgslen blev slettet.
I tilfælde af et forudbestemt antal permanente fejl i træk af samme type og på samme regel stopper Microsoft Sentinel forsøget på at udføre reglen og udfører også følgende trin:
- Deaktiverer reglen.
- Tilføjer ordene "AUTO DISABLED" i starten af reglens navn.
- Føjer årsagen til fejlen (og deaktivering) til beskrivelsen af reglen.
Du kan nemt bestemme tilstedeværelsen af autodisabled regler ved at sortere regellisten efter navn. De automatisk disaktiverede regler er øverst på listen eller tæt på listen.
SOC-ledere skal sørge for at kontrollere regellisten regelmæssigt for tilstedeværelsen af autodisabled regler.
Permanent fejl på grund af ressourceafløb
En anden form for permanent fejl opstår på grund af en forkert bygget forespørgsel , der medfører, at reglen forbruger overdrevne beregningsressourcer , og der er risiko for, at dine systemer drænes for ydeevnen. Når Microsoft Sentinel identificerer en sådan regel, tager den de samme tre trin, der er nævnt for de andre typer permanente fejl– deaktiverer reglen, forpenser "AUTO DISABLED" til regelnavnet og tilføjer årsagen til fejlen i beskrivelsen.
Hvis du vil aktivere reglen igen, skal du løse de problemer i forespørgslen, der medfører, at den bruger for mange ressourcer. Du kan finde flere oplysninger under:
- Forespørg om bedste praksis – Kusto-dokumentation
- Optimer logforespørgsler i Azure skærm
- Kusto-undervisningsressourcer til forespørgselssprog
Permanent fejl på grund af mistet adgang på tværs af abonnementer/lejere
Et bestemt eksempel på, hvornår der kan opstå en permanent fejl på grund af en ændring af tilladelser i en datakilde (se listen), vedrører en MICROSOFT-sikkerhedsløsningsudbyder (MSSP) eller et andet scenarie, hvor analyseregler forespørger på tværs af abonnementer eller lejere.
Når du opretter en analyseregel, anvendes der et adgangstilladelserstoken på reglen og gemmes sammen med den. Dette token sikrer, at reglen kan få adgang til det arbejdsområde, der indeholder de tabeller, som reglens forespørgsel refererer til, og at denne adgang bevares, selvom reglens opretter mister adgangen til det pågældende arbejdsområde.
Der er dog én undtagelse: Når der oprettes en regel for at få adgang til arbejdsområder i andre abonnementer eller lejere, f.eks. hvad der sker i tilfælde af en MSSP, tager Microsoft Sentinel ekstra sikkerhedsforanstaltninger for at forhindre uautoriseret adgang til kundedata. Disse typer regler har legitimationsoplysningerne for den bruger, der oprettede reglen, anvendt på dem i stedet for et uafhængigt adgangstoken. Når brugeren ikke længere har adgang til den anden lejer, holder reglen op med at fungere.
Hvis du arbejder Microsoft Sentinel i et scenarie på tværs af abonnementer eller på tværs af lejere, og hvis en af dine analytikere eller teknikere mister adgang til et bestemt arbejdsområde, holder de regler, der er oprettet af den pågældende bruger, op med at fungere. Du får vist en tilstandsovervågningsmeddelelse om "utilstrækkelig adgang til ressource", og reglen vil automatisk blive deaktiveret i henhold til den procedure, der er beskrevet tidligere.
Næste trin
Du kan finde flere oplysninger under:
- Selvstudium: Undersøg hændelser med Microsoft Sentinel
- Naviger til og undersøg hændelser i Microsoft Sentinel – prøveversion
- Klassificer og analysér data ved hjælp af objekter i Microsoft Sentinel
- Selvstudium: Brug playbooks med automatiseringsregler i Microsoft Sentinel
Få også mere at vide om et eksempel på brug af brugerdefinerede analyseregler, når du overvåger Zoom med en brugerdefineret connector.