Dela via

Schemalagda analysregler i Microsoft Sentinel

  • Artikel
  • Gäller för:
    Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

Den överlägset vanligaste typen av analysregel är schemalagda regler baserade på Kusto-frågor som är konfigurerade för att köras med jämna mellanrum och undersöka rådata från en definierad "lookback"-period. Frågor kan utföra komplexa statistiska åtgärder på sina måldata, vilket avslöjar baslinjer och extremvärden i grupper av händelser. Om antalet resultat som samlas in av frågan överskrider tröskelvärdet som konfigurerats i regeln skapar regeln en avisering.

Den här artikeln hjälper dig att förstå hur schemalagda analysregler skapas och introducerar dig för alla konfigurationsalternativ och deras betydelser. Informationen i den här artikeln är användbar i två scenarier:

  • Skapa en analysregel från en mall: Använd frågelogik och schemaläggnings- och återblicksinställningarna enligt mallen eller anpassa dem för att skapa nya regler.

  • Skapa en analysregel från grunden: skapa en egen fråga och regel från grunden. För att göra detta effektivt bör du ha en grundlig grund i datavetenskap och Kusto-frågespråk.

Viktigt!

Microsoft Sentinel är nu allmänt tillgängligt på Microsofts plattform för enhetliga säkerhetsåtgärder i Microsoft Defender-portalen. Mer information finns i Microsoft Sentinel i Microsoft Defender-portalen.

Analysregelmallar

Frågorna i schemalagda regelmallar skrevs av säkerhets- och datavetenskapsexperter , antingen från Microsoft eller från leverantören av lösningen som tillhandahåller mallen.

Använd en mall för analysregler genom att välja ett mallnamn i listan med mallar och skapa en regel baserat på den.

Varje mall har en lista över nödvändiga datakällor. När du öppnar mallen kontrolleras datakällorna automatiskt för tillgänglighet. Tillgänglighet innebär att datakällan är ansluten och att data matas in regelbundet via den. Om någon av de nödvändiga datakällorna inte är tillgängliga får du inte skapa regeln, och du kan också se ett felmeddelande om detta.

När du skapar en regel från en mall öppnas guiden skapa regel baserat på den valda mallen. All information fylls i automatiskt och du kan anpassa logiken och andra regelinställningar så att de passar dina specifika behov bättre. Du kan upprepa den här processen för att skapa fler regler baserat på mallen. När du når slutet av guiden för att skapa regeln verifieras dina anpassningar och regeln skapas. De nya reglerna visas på fliken Aktiva regler på sidan Analys . På fliken Regelmallar visas nu mallen som du skapade regeln från med taggen In use .

Analysregelmallar underhålls ständigt av författarna, antingen för att åtgärda buggar eller för att förfina frågan. När en mall tar emot en uppdatering visas alla regler som baseras på mallen med taggen Update och du har möjlighet att ändra dessa regler så att de inkluderar de ändringar som gjorts i mallen. Du kan också återställa alla ändringar som du har gjort i en regel tillbaka till den ursprungliga mallbaserade versionen. Mer information finns i Hantera mallversioner för dina schemalagda analysregler i Microsoft Sentinel.

När du har bekantat dig med konfigurationsalternativen i den här artikeln kan du läsa Skapa schemalagda analysregler från mallar.

I resten av den här artikeln förklaras alla möjligheter att anpassa konfigurationen av dina regler.

Konfiguration av analysregel

I det här avsnittet beskrivs de viktigaste överväganden som du måste ta hänsyn till innan du börjar konfigurera dina regler.

Namn och information om analysregel

Den första sidan i guiden analysregel innehåller regelns grundläggande information.

Namn: Namnet på regeln så som den visas i listan över regler och i alla regelbaserade filter. Namnet måste vara unikt för din arbetsyta.

Beskrivning: En beskrivning av syftet med regeln i fritext.

ID: GUID för regeln som en Azure-resurs, som bland annat används i API-begäranden och svar. Detta GUID tilldelas endast när regeln skapas, så det visas bara när du redigerar en befintlig regel. Eftersom det är ett skrivskyddat fält visas det som nedtonat och kan inte ändras. Den finns inte ännu när du skapar en ny regel, antingen från en mall eller från grunden.

Allvarlighetsgrad: Ett omdöme som ger aviseringarna som skapas av den här regeln. Allvarlighetsgraden för en aktivitet är en beräkning av den potentiella negativa effekten av aktivitetens förekomst.

Allvarlighetsgrad beskrivning
Informativt Ingen inverkan på systemet, men informationen kan tyda på framtida steg som planeras av en hotskådespelare.
Låg Den omedelbara effekten skulle vara minimal. En hotskådespelare skulle sannolikt behöva utföra flera steg innan en miljö påverkas.
Medel Hotskådespelaren kan ha viss inverkan på miljön med den här aktiviteten, men den skulle vara begränsad i omfånget eller kräva ytterligare aktivitet.
Hög Den identifierade aktiviteten ger hotaktören omfattande åtkomst till att utföra åtgärder i miljön eller utlöses av påverkan på miljön.

Standardvärden för allvarlighetsgrad är inte en garanti för aktuell eller miljömässig påverkansnivå. Anpassa aviseringsinformation för att anpassa allvarlighetsgrad, taktik och andra egenskaper för en viss instans av en avisering med värdena för relevanta fält från en frågas utdata.

Allvarlighetsgradsdefinitioner för Microsoft Sentinel-analysregelmallar är endast relevanta för aviseringar som skapats av analysregler. För aviseringar som matas in från andra tjänster definieras allvarlighetsgraden av källsäkerhetstjänsten.

MITRE ATT&CK: En specifikation av attacktaktik och -tekniker som representeras av de aktiviteter som fångas upp av den här regeln. Dessa baseras på taktiken och teknikerna i MITRE ATT&CK-ramverket®.

MITRE ATT&CK-taktikerna och teknikerna som definieras här i regeln gäller för alla aviseringar som genereras av regeln. De gäller även för incidenter som skapats från dessa aviseringar.

Mer information om hur du maximerar din täckning av MITRE ATT&CK-hotlandskapet finns i Förstå säkerhetstäckningen i MITRE ATT&CK-ramverket®.

Status: När du skapar regeln är statusen Aktiverad som standard, vilket innebär att den körs direkt när du har skapat den. Om du inte vill att den ska köras omedelbart har du två alternativ:

  • Välj Inaktiverad och regeln skapas utan att köras. När du vill att regeln ska köras hittar du den på fliken Aktiva regler och aktiverar den därifrån.
  • Schemalägg regeln så att den först körs vid ett visst datum och en viss tidpunkt. Den här metoden är för närvarande i FÖRHANDSVERSION. Se Frågeschemaläggning senare i den här artikeln.

Regelfråga

Det här är kärnan i regeln: du bestämmer vilken information som finns i aviseringarna som skapas av den här regeln och hur informationen organiseras. Den här konfigurationen har följdeffekter på hur de resulterande incidenterna ser ut och hur enkla eller svåra de är att undersöka, åtgärda och lösa. Det är viktigt att göra aviseringarna så omfattande som möjligt och att göra informationen lättillgänglig.

Visa eller ange Kusto-frågan som analyserar rådata. Om du skapar en regel från grunden är det en bra idé att planera och utforma frågan innan du öppnar den här guiden. Du kan skapa och testa frågor på sidan Loggar .

Allt du skriver in i regelfrågefönstret verifieras omedelbart, så du får reda på det direkt om du gör några misstag.

Metodtips för analysregelfrågor

  • Vi rekommenderar att du använder en ASIM-parser (Advanced Security Information Model) som frågekälla i stället för att använda en intern tabell. Detta säkerställer att frågan stöder alla aktuella eller framtida relevanta datakällor eller datakällor i stället för att förlita sig på en enda datakälla.

  • Frågelängden ska vara mellan 1 och 10 000 tecken och får inte innehålla "search *" eller "union *". Du kan använda användardefinierade funktioner för att övervinna frågelängdsbegränsningen, eftersom en enskild funktion kan ersätta dussintals kodrader.

  • Det går inte att använda ADX-funktioner för att skapa Azure Data Explorer-frågor i Log Analytics-frågefönstret.

  • När du använder bag_unpack funktionen i en fråga misslyckas frågan om du projicerar kolumnerna som fält med "project field1" och kolumnen inte finns. För att skydda dig mot detta måste du projicera kolumnen på följande sätt:

    project field1 = column_ifexists("field1","")

Mer hjälp med att skapa Kusto-frågor finns i Kusto Query Language i Microsoft Sentinel och Metodtips för Kusto Query Language-frågor.

Aviseringsförbättring

Om du vill att dina aviseringar ska visa sina resultat så att de omedelbart kan visas i incidenter och spåras och undersökas på lämpligt sätt använder du konfigurationen för aviseringsförbättring för att visa all viktig information i aviseringarna.

Den här aviseringsförbättringen har den extra fördelen med att presentera resultaten på ett lätt synligt och tillgängligt sätt.

Det finns tre typer av aviseringsförbättringar som du kan konfigurera:

  • Entitetsmappning
  • Anpassad information
  • Aviseringsinformation (kallas även dynamiskt innehåll)

Entitetsmappning

Entiteter är spelarna på båda sidor av någon attackhistoria. Det är viktigt att identifiera alla entiteter i en avisering för att identifiera och undersöka hot. För att säkerställa att Microsoft Sentinel identifierar entiteterna i dina rådata måste du mappa de entitetstyper som identifieras av Microsoft Sentinel till fält i frågeresultatet. Den här mappningen integrerar identifierade entiteter i fältet Entiteter i ditt aviseringsschema.

Mer information om entitetsmappning och fullständiga instruktioner finns i Mappa datafält till entiteter i Microsoft Sentinel.

Anpassad information

Som standard visas endast aviseringsentiteter och metadata i incidenter utan att öka detaljnivån i råhändelserna i frågeresultatet. Om du vill ge andra fält från frågeresultatet omedelbar synlighet i dina aviseringar och incidenter definierar du dem som anpassad information. Microsoft Sentinel integrerar den här anpassade informationen i fältet ExtendedProperties i dina aviseringar, vilket gör att de visas i förväg i dina aviseringar och i eventuella incidenter som skapats från dessa aviseringar.

Mer information om hur du visar anpassad information och om du vill få fullständiga instruktioner finns information om anpassade surface-händelser i aviseringar i Microsoft Sentinel.

Aviseringsinformation

Med den här inställningen kan du anpassa annars standardaviseringsegenskaper enligt innehållet i olika fält i varje enskild avisering. De här anpassningarna är integrerade i fältet ExtendedProperties i dina aviseringar. Du kan till exempel anpassa aviseringsnamnet eller beskrivningen så att det innehåller ett användarnamn eller en IP-adress i aviseringen.

Mer information om hur du anpassar aviseringsinformation och fullständiga instruktioner finns i Anpassa aviseringsinformation i Microsoft Sentinel.

Kommentar

I den enhetliga säkerhetsåtgärdsplattformen ansvarar Defender XDR-korrelationsmotorn enbart för namngivning av incidenter, så eventuella aviseringsnamn som du har anpassat kan åsidosättas när incidenter skapas från dessa aviseringar.

Frågeschemaläggning

Följande parametrar avgör hur ofta den schemalagda regeln ska köras och vilken tidsperiod den ska undersöka varje gång den körs.

Inställning Funktionssätt
Kör alla frågor Styr frågeintervallet: hur ofta frågan körs.
Uppslagsdata från den senaste Avgör återställningsperioden: den tidsperiod som omfattas av frågan.

  • Det tillåtna intervallet för båda dessa parametrar är från 5 minuter till 14 dagar.

  • Frågeintervallet måste vara kortare än eller lika med återställningsperioden. Om den är kortare överlappar frågeperioderna och detta kan orsaka viss duplicering av resultat. Med regelverifieringen kan du dock inte ange ett intervall längre än återställningsperioden, eftersom det skulle leda till luckor i din täckning.

Med inställningen Börja köra , nu i FÖRHANDSVERSION, kan du skapa en regel med statusen Aktiverad, men fördröja den första körningen till ett fördefinierat datum och tid. Den här inställningen är användbar om du vill tajmat körningen av dina regler enligt när data förväntas matas in från källan eller när soc-analytikerna börjar sin arbetsdag.

Inställning Funktionssätt
Automatiskt Regeln körs för första gången omedelbart när den skapas, och därefter vid det intervall som anges i inställningen Kör fråga varje inställning.
Vid en viss tidpunkt (förhandsversion) Ange ett datum och en tid då regeln ska köras först, varefter den körs med det intervall som anges i varje inställning för Kör fråga.

  • Startkörningstiden måste vara mellan 10 minuter och 30 dagar efter att regeln har skapats (eller aktiverats).

  • Textraden under inställningen Börja köra (med informationsikonen till vänster) sammanfattar de aktuella frågeschemaläggnings- och återblicksinställningarna.

    Skärmbild av växlingsknappen och inställningarna för avancerad schemaläggning.

Kommentar

Inmatningsfördröjning

För att ta hänsyn till svarstider som kan uppstå mellan en händelses generering vid källan och dess inmatning till Microsoft Sentinel, och för att säkerställa fullständig täckning utan dataduplicering, kör Microsoft Sentinel schemalagda analysregler på fem minuters fördröjning från den schemalagda tiden.

Mer information finns i Hantera inmatningsfördröjning i schemalagda analysregler.

Aviseringströskelvärde

Många typer av säkerhetshändelser är normala eller till och med förväntade i små antal, men är ett tecken på ett hot i större antal. Olika skalor av stora antal kan innebära olika typer av hot. Till exempel är två eller tre misslyckade inloggningsförsök inom loppet av en minut ett tecken på att en användare inte kommer ihåg ett lösenord, men femtio på en minut kan vara ett tecken på en mänsklig attack, och tusen är förmodligen en automatiserad attack.

Beroende på vilken typ av aktivitet regeln försöker identifiera kan du ange ett minsta antal händelser (frågeresultat) som krävs för att utlösa en avisering. Tröskelvärdet gäller separat för varje gång regeln körs, inte kollektivt.

Tröskelvärdet kan också anges till ett maximalt antal resultat eller ett exakt antal.

Händelsegruppering

Det finns två sätt att hantera gruppering av händelser i aviseringar:

  • Gruppera alla händelser i en enda avisering: Detta är standardvärdet. Regeln genererar en enskild avisering varje gång den körs, så länge frågan returnerar fler resultat än det angivna tröskelvärdet för aviseringar som beskrivs i föregående avsnitt. Den här enskilda aviseringen sammanfattar alla händelser som returneras i frågeresultatet.

  • Utlös en avisering för varje händelse: Regeln genererar en unik avisering för varje händelse (resultat) som returneras av frågan. Det här läget är användbart om du vill att händelser ska visas individuellt eller om du vill gruppera dem efter vissa parametrar – efter användare, värdnamn eller något annat. Du kan definiera dessa parametrar i frågan. |

Analysregler kan generera upp till 150 aviseringar. Om händelsegruppering är inställt på Utlösa en avisering för varje händelse och regelns fråga returnerar fler än 150 händelser, genererar de första 149 händelserna var och en unik avisering (för 149 aviseringar) och den 150:e aviseringen sammanfattar hela uppsättningen returnerade händelser. Med andra ord är den 150:e aviseringen vad som skulle ha genererats om händelsegruppering hade angetts till Gruppera alla händelser i en enda avisering.

Utlösa en avisering för varje händelseinställning kan orsaka ett problem där frågeresultaten verkar saknas eller skiljer sig från förväntat. Mer information om det här scenariot finns i Felsöka analysregler i Microsoft Sentinel | Problem: Inga händelser visas i frågeresultat.

Undertryckning

Om du vill att den här regeln ska sluta fungera under en viss tid efter att den har genererat en avisering aktiverar du inställningen Sluta köra frågan när aviseringen har genererats. Sedan måste du ange Sluta köra frågan till den tid som frågan ska sluta köras, upp till 24 timmar.

Resultatsimulering

Med guiden för analysregler kan du testa dess effekt genom att köra den på den aktuella datauppsättningen. När du kör testet visar fönstret Resultatsimulering ett diagram över de resultat som frågan skulle ha genererat under de senaste 50 gångerna som den skulle ha körts, enligt det aktuella definierade schemat. Om du ändrar frågan kan du köra testet igen för att uppdatera diagrammet. Diagrammet visar antalet resultat under den definierade tidsperioden, vilket bestäms av det frågeschema som du definierade.

Så här kan resultatsimuleringen se ut för frågan i skärmbilden ovan. Den vänstra sidan är standardvyn och den högra sidan är det du ser när du hovra över en tidpunkt i diagrammet.

Skärmbilder av resultatsimuleringar.

Om du ser att frågan utlöser för många eller för frekventa aviseringar kan du experimentera med schemaläggnings- och tröskelvärdesinställningarna och köra simuleringen igen.

Incidentinställningar

Välj om Microsoft Sentinel omvandlar aviseringar till åtgärdsbara incidenter.

Incidentskapande är aktiverat som standard. Microsoft Sentinel skapar en enskild, separat incident från varje avisering som genereras av regeln.

Om du inte vill att den här regeln ska leda till att incidenter skapas (till exempel om den här regeln bara är att samla in information för efterföljande analys) anger du detta till Inaktiverad.

Viktigt!

Om du registrerade Microsoft Sentinel på den enhetliga säkerhetsåtgärdsplattformen ansvarar Microsoft Defender XDR för att skapa incidenter. Men om du vill att Defender XDR ska skapa incidenter för den här aviseringen måste du lämna den här inställningen Aktiverad. Defender XDR använder instruktionen som definieras här.

Detta ska inte förväxlas med Microsofts säkerhetstyp av analysregel som skapar incidenter för aviseringar som genereras i Microsoft Defender-tjänster. Dessa regler inaktiveras automatiskt när du registrerar Microsoft Sentinel på den enhetliga säkerhetsåtgärdsplattformen.

Om du vill att en enskild incident ska skapas från en grupp av aviseringar går du till nästa avsnitt i stället för en för varje avisering.

Aviseringsgruppering

Välj om aviseringar ska grupperas tillsammans i incidenter. Som standard skapar Microsoft Sentinel en incident för varje avisering som genereras. Du har möjlighet att gruppera flera aviseringar i en enda incident i stället.

Incidenten skapas först när alla aviseringar har genererats. Alla aviseringar läggs till i incidenten omedelbart när den skapas.

Upp till 150 aviseringar kan grupperas i en enda incident. Om fler än 150 aviseringar genereras av en regel som grupperar dem i en enda incident genereras en ny incident med samma incidentinformation som originalet och de överskjutande aviseringarna grupperas i den nya incidenten.

Om du vill gruppera aviseringar tillsammans anger du inställningen för aviseringsgruppering till Aktiverad.

Det finns några alternativ att tänka på när du grupperar aviseringar:

  • Tidsram: Som standard läggs aviseringar som skapats upp till 5 timmar efter den första aviseringen i en incident till i samma incident. Efter 5 timmar skapas en ny incident. Du kan ändra den här tidsperioden till någonstans mellan 5 minuter och 7 dagar.

  • Grupperingsvillkor: Välj hur du vill avgöra vilka aviseringar som ingår i gruppen. I följande tabell visas de möjliga alternativen:

    Alternativ Description
    Gruppera aviseringar i en enskild incident om alla entiteter matchar Aviseringar grupperas tillsammans om de delar identiska värden för var och en av de mappade entiteter som definierades tidigare. Detta är den rekommenderade inställningen.
    Gruppera alla aviseringar som utlöses av den här regeln i en enda incident Alla aviseringar som genereras av den här regeln grupperas tillsammans även om de inte delar några identiska värden.
    Gruppera aviseringar i en enskild incident om de valda entiteterna och informationen matchar Aviseringar grupperas tillsammans om de delar identiska värden för alla mappade entiteter, aviseringsinformation och anpassad information som du väljer för den här inställningen. Välj entiteter och information i listrutorna som visas när du väljer det här alternativet.

    Du kanske vill använda den här inställningen om du till exempel vill skapa separata incidenter baserat på källans eller målets IP-adresser, eller om du vill gruppera aviseringar som matchar en viss entitet och allvarlighetsgrad.

    Obs! När du väljer det här alternativet måste du ha minst en entitet eller information vald för regeln. Annars misslyckas verifieringen av regeln och regeln skapas inte.

  • Incidenter som öppnas igen: Om en incident har lösts och stängts, och senare en annan avisering genereras som ska tillhöra incidenten, anger du den här inställningen till Aktiverad om du vill att den stängda incidenten ska öppnas igen och lämnar som Inaktiverad om du vill att den nya aviseringen ska skapa en ny incident.

    Alternativet att öppna stängda incidenter igen är inte tillgängligt om du registrerade Microsoft Sentinel på den enhetliga säkerhetsåtgärdsplattformen.

Automatiserat svar

Med Microsoft Sentinel kan du ställa in automatiserade svar när:

  • En avisering genereras av den här analysregeln.
  • En incident skapas från aviseringar som genereras av den här analysregeln.
  • En incident uppdateras med aviseringar som genereras av den här analysregeln.

Information om olika typer av svar som kan skapas och automatiseras finns i Automatisera hotsvar i Microsoft Sentinel med automatiseringsregler.

Under rubriken Automation-regler visar guiden en lista över de automatiseringsregler som redan har definierats på hela arbetsytan, vars villkor gäller för den här analysregeln. Du kan redigera någon av dessa befintliga regler eller skapa en ny automatiseringsregel som endast gäller för den här analysregeln.

Använd automatiseringsregler för att utföra grundläggande sortering, tilldelning, arbetsflöde och stängning av incidenter.

Automatisera mer komplexa uppgifter och anropa svar från fjärrsystem för att åtgärda hot genom att anropa spelböcker från dessa automatiseringsregler. Du kan anropa spelböcker för incidenter och enskilda aviseringar.

Nästa steg

När du använder Microsoft Sentinel-analysregler för att identifiera hot i din miljö måste du aktivera alla regler som är associerade med dina anslutna datakällor för att säkerställa fullständig säkerhetstäckning för din miljö.

För att automatisera regelaktivering skickar du regler till Microsoft Sentinel via API och PowerShell, men det kräver ytterligare arbete. När du använder API eller PowerShell måste du först exportera reglerna till JSON innan du aktiverar reglerna. API eller PowerShell kan vara till hjälp när du aktiverar regler i flera instanser av Microsoft Sentinel med identiska inställningar i varje instans.

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.