Automatisera hotsvar i Microsoft Sentinel med automatiseringsregler
Den här artikeln förklarar vad Microsoft Sentinel-automatiseringsregler är och hur du använder dem för att implementera dina soar-åtgärder (Security Orchestration, Automation and Response). Automatiseringsregler ökar soc-effektiviteten och sparar tid och resurser.
Viktigt!
Microsoft Sentinel är allmänt tillgängligt på Microsofts plattform för enhetliga säkerhetsåtgärder i Microsoft Defender-portalen. För förhandsversion är Microsoft Sentinel tillgängligt i Defender-portalen utan Microsoft Defender XDR eller en E5-licens. Mer information finns i Microsoft Sentinel i Microsoft Defender-portalen.
Vad är automatiseringsregler?
Automationsregler är ett sätt att centralt hantera automatisering i Microsoft Sentinel genom att låta dig definiera och samordna en liten uppsättning regler som kan tillämpas i olika scenarier.
Automationsregler gäller för följande kategorier av användningsfall:
Utför grundläggande automatiseringsuppgifter för incidenthantering utan att använda spelböcker. Till exempel:
- Lägg till incidentuppgifter som analytiker kan följa.
- Undertryck brusande incidenter.
- Sortera nya incidenter genom att ändra deras status från Ny till Aktiv och tilldela en ägare.
- Tagga incidenter för att klassificera dem.
- Eskalera en incident genom att tilldela en ny ägare.
- Stäng lösta incidenter, ange en orsak och lägg till kommentarer.
Automatisera svar för flera analysregler samtidigt.
Kontrollera ordningen på de åtgärder som körs.
Granska innehållet i en incident (aviseringar, entiteter och andra egenskaper) och vidta ytterligare åtgärder genom att anropa en spelbok.
Automatiseringsregler kan också vara den mekanism som du kör en spelbok med som svar på en avisering som inte är associerad med en incident.
Kort och kort, automatiseringsregler effektiviserar användningen av automatisering i Microsoft Sentinel, så att du kan förenkla komplexa arbetsflöden för orkestreringsprocesser för hotsvar.
Komponenter
Automationsregler består av flera komponenter:
- Utlösare som definierar vilken typ av incidenthändelse som gör att regeln körs, beroende på villkor.
- Villkor som avgör de exakta omständigheter under vilka regeln körs och utför åtgärder.
- Åtgärder för att ändra incidenten på något sätt eller anropa en spelbok, som utför mer komplexa åtgärder och interagerar med andra tjänster.
Utlösare
Automatiseringsregler utlöses när en incident skapas eller uppdateras eller när en avisering skapas. Kom ihåg att incidenter inkluderar aviseringar och att både aviseringar och incidenter kan skapas av analysregler, enligt beskrivningen i Hotidentifiering i Microsoft Sentinel.
I följande tabell visas de olika möjliga scenarier som gör att en automatiseringsregel körs.
| Utlösartyp | Händelser som utlöser regeln |
|---|---|
| När incidenten skapas | Microsoft Defender-portalen: Microsoft Sentinel har inte registrerats på Defender-portalen: |
| När incidenten uppdateras | |
| När aviseringen skapas |
Incidentbaserad eller aviseringsbaserad automatisering?
Hur ska du välja vilka som ska automatiseras och under vilka omständigheter när automatiseringsregler hanterar svar på både incidenter och aviseringar centralt?
För de flesta användningsfall är incidentutlöst automatisering den bästa metoden. I Microsoft Sentinel är en incident en "ärendefil" – en sammanställning av alla relevanta bevis för en specifik undersökning. Det är en container för aviseringar, entiteter, kommentarer, samarbete och andra artefakter. Till skillnad från aviseringar som är enkla bevis kan incidenter ändras, ha den mest uppdaterade statusen och kan berikas med kommentarer, taggar och bokmärken. Med incidenten kan du spåra attackberättelsen som fortsätter att utvecklas med tillägg av nya aviseringar.
Av dessa skäl är det mer meningsfullt att skapa din automatisering kring incidenter. Det lämpligaste sättet att skapa spelböcker är därför att basera dem på Microsoft Sentinel-incidentutlösaren i Azure Logic Apps.
Den främsta anledningen till att använda aviseringsutlöst automatisering är för att svara på aviseringar som genereras av analysregler som inte skapar incidenter (det vill: där incidentskapande är inaktiverat på fliken Incidentinställningar i analysregelguiden).
Den här orsaken är särskilt relevant när din Microsoft Sentinel-arbetsyta registreras på Defender-portalen. I det här scenariot sker alla incidentskapanden i Defender-portalen och därför måste reglerna för incidentskapande i Microsoft Sentinel inaktiveras.
Även om du inte har registrerats på den enhetliga portalen kan du ändå välja att använda aviseringsutlöst automatisering om du vill använda annan extern logik för att avgöra om och när incidenter ska skapas från aviseringar och hur aviseringar grupperas tillsammans. Till exempel:
En spelbok, som utlöses av en avisering som inte har en associerad incident, kan utöka aviseringen med information från andra källor och baserat på viss extern logik avgöra om en incident ska skapas eller inte.
En spelbok som utlöses av en avisering kan, i stället för att skapa en incident, leta efter en lämplig befintlig incident att lägga till aviseringen i. Läs mer om incidentexpansion.
En spelbok som utlöses av en avisering kan meddela SOC-personalen om aviseringen så att teamet kan avgöra om en incident ska skapas eller inte.
En spelbok som utlöses av en avisering kan skicka aviseringen till ett externt biljettsystem för incidentskapande och hantering, och det systemet skapar en ny biljett för varje avisering.
Kommentar
Aviseringsutlöst automatisering är endast tillgängligt för aviseringar som skapats av regler för schemalagd, NRT och Microsofts säkerhetsanalys.
Aviseringsutlöst automatisering för aviseringar som skapats av Microsoft Defender XDR är inte tillgänglig i Defender-portalen. Mer information finns i Automation i Defender-portalen.
Villkor
Komplexa uppsättningar med villkor kan definieras för att styra när åtgärder (se nedan) ska köras. Dessa villkor omfattar den händelse som utlöser regeln (incidenten har skapats eller uppdaterats eller aviseringen har skapats), tillstånden eller värdena för incidentens egenskaper och entitetsegenskaper (endast för incidentutlösare) och även analysregeln eller reglerna som genererade incidenten eller aviseringen.
När en automatiseringsregel utlöses kontrollerar den utlösande incidenten eller aviseringen mot de villkor som definierats i regeln. För incidenter utvärderas de egenskapsbaserade villkoren enligt egenskapens aktuella tillstånd när utvärderingen sker, eller enligt ändringar i egenskapens tillstånd (se nedan för mer information). Eftersom en enskild incidentskapande eller uppdateringshändelse kan utlösa flera automatiseringsregler, gör den ordning i vilken de körs (se nedan) en skillnad när det gäller att fastställa resultatet av villkorsutvärderingen. De åtgärder som definieras i regeln körs endast om alla villkor är uppfyllda.
Utlösare för incidentskapande
För regler som definieras med utlösaren När en incident skapas kan du definiera villkor som kontrollerar det aktuella tillståndet för värdena i en viss lista över incidentegenskaper med hjälp av en eller flera av följande operatorer:
- är lika med eller är inte lika med det värde som definierats i villkoret.
- innehåller eller innehåller inte det värde som definierats i villkoret.
- börjar med eller börjar inte med det värde som definierats i villkoret.
- slutar med eller slutar inte med det värde som definierats i villkoret.
Om du till exempel definierar analysregelnamn som Contains == Brute force attack mot en molndator, uppfyller inte en analysregel med Brute force-attacken mot Azure Portal villkoret. Men om du definierar Analysregelnamn som Innehåller inte == Användarautentiseringsuppgifter, uppfyller både Brute force-attacken mot en molndator och Brute force mot Azure Portal analysregler villkoret.
Kommentar
Det aktuella tillståndet i den här kontexten refererar till det ögonblick då villkoret utvärderas, det vill säga det ögonblick då automatiseringsregeln körs. Om mer än en automatiseringsregel har definierats för att köras som svar på skapandet av den här incidenten anses ändringar som gjorts i incidenten av en tidigare körningsautomatiseringsregel vara det aktuella tillståndet för regler som körs senare.
Utlösare för incidentuppdatering
De villkor som utvärderas i regler som definierats med utlösaren När en incident uppdateras innehåller alla de som anges för utlösaren för incidentskapande. Men uppdateringsutlösaren innehåller fler egenskaper som kan utvärderas.
En av dessa egenskaper uppdateras av. Med den här egenskapen kan du spåra typen av källa som gjorde ändringen i incidenten. Du kan skapa ett villkor som utvärderar om incidenten uppdaterades av något av följande värden, beroende på om du registrerade din arbetsyta på Defender-portalen:
- Ett program, inklusive program i både Azure- och Defender-portalerna.
- En användare, inklusive ändringar som gjorts av användare i både Azure- och Defender-portalerna.
- AIR, för uppdateringar efter automatiserad undersökning och svar i Microsoft Defender för Office 365
- En aviseringsgruppering (som lade till aviseringar till incidenten), inklusive aviseringsgrupperingar som utfördes både av analysregler och inbyggd Microsoft Defender XDR-korrelationslogik
- En spelbok
- En automatiseringsregel
- Annat, om inget av ovanstående värden gäller
Med det här villkoret kan du till exempel instruera den här automatiseringsregeln att köra alla ändringar som görs i en incident, förutom om den har gjorts av en annan automatiseringsregel.
Mer till saken använder uppdateringsutlösaren även andra operatorer som kontrollerar tillståndsändringar i värdena för incidentegenskaper samt deras aktuella tillstånd. Ett tillståndsändringsvillkor skulle uppfyllas om:
Värdet för en incidentegenskap
- ändrats (oavsett det faktiska värdet före eller efter).
- ändrats från det värde som definierats i villkoret.
- ändrat till det värde som definierats i villkoret.
- läggs till (detta gäller för egenskaper med en lista med värden).
Taggegenskap : enskild jämfört med samling
Incidentegenskapstaggen är en samling enskilda objekt – en enskild incident kan ha flera taggar tillämpade på den. Du kan definiera villkor som kontrollerar varje tagg i samlingen individuellt och villkor som kontrollerar samlingen med taggar som en enhet.
- Alla enskilda taggoperatorer kontrollerar villkoret mot varje tagg i samlingen. Utvärderingen är sann när minst en tagg uppfyller villkoret.
- Samling av alla taggar operatorer kontrollera villkoret mot samlingen av taggar som en enda enhet. Utvärderingen gäller endast om samlingen som helhet uppfyller villkoret.
Den här skillnaden är viktig när ditt villkor är negativt (innehåller inte), och vissa taggar i samlingen uppfyller villkoret och andra inte.
Nu ska vi titta på ett exempel där ditt villkor är, taggen innehåller inte "2024" och du har två incidenter, var och en med två taggar:
| \Incidenter ▶ Villkoret ▼ \ |
Incident 1 Tagg 1: 2024 Tagg 2: 2023 |
Incident 2 Tagg 1: 2023 Tagg 2: 2022 |
|---|---|---|
| Alla enskilda taggar innehåller inte "2024" |
SANN | Sant |
| Samling med alla taggar innehåller inte "2024" |
FALSK | SANT |
I det här exemplet i Incident 1:
- Om villkoret kontrollerar varje tagg individuellt är det övergripande villkoret sant eftersom det finns minst en tagg som uppfyller villkoret (som inte innehåller "2024".
- Om villkoret kontrollerar alla taggar i incidenten som en enda enhet är det övergripande villkoret falskt eftersom det finns minst en tagg som inte uppfyller villkoret (som innehåller "2024".
I Incident 2 är resultatet detsamma, oavsett vilken typ av villkor som definieras.
Entitetsegenskaper som stöds
En lista över entitetsegenskaper som stöds som villkor för automatiseringsregler finns i Referens för Microsoft Sentinel-automatiseringsregler.
Utlösare för aviseringsskapande
För närvarande är det enda villkor som kan konfigureras för utlösaren för att skapa aviseringar den uppsättning analysregler som automatiseringsregeln körs för.
Åtgärder
Åtgärder kan definieras att köras när villkoren (se ovan) uppfylls. Du kan definiera många åtgärder i en regel och du kan välja i vilken ordning de ska köras (se nedan). Följande åtgärder kan definieras med hjälp av automatiseringsregler, utan att du behöver de avancerade funktionerna i en spelbok:
Lägga till en uppgift i en incident – du kan skapa en checklista med uppgifter som analytiker kan följa under processerna för sortering, undersökning och reparation av incidenten för att säkerställa att inga kritiska steg missas.
Ändra status för en incident och hålla arbetsflödet uppdaterat.
- När du ändrar till "stängd" anger du stängningsorsaken och lägger till en kommentar. Detta hjälper dig att hålla reda på din prestanda och effektivitet och finjustera för att minska falska positiva identifieringar.
Ändra allvarlighetsgraden för en incident – du kan omvärdera och omprioritera baserat på närvaro, frånvaro, värden eller attribut för entiteter som är inblandade i incidenten.
Tilldela en incident till en ägare – detta hjälper dig att dirigera typer av incidenter till den personal som passar bäst för att hantera dem, eller till den mest tillgängliga personalen.
Lägga till en tagg i en incident – detta är användbart för att klassificera incidenter efter ämne, av angripare eller av någon annan gemensam nämnare.
Du kan också definiera en åtgärd för att köra en spelbok för att vidta mer komplexa svarsåtgärder, inklusive alla som omfattar externa system. Vilka spelböcker som är tillgängliga för användning i en automatiseringsregel beror på den utlösare som spelböckerna och automatiseringsregeln baseras på: Endast spelböcker för incidentutlösare kan köras från automatiseringsregler för incidentutlösare och endast spelböcker för aviseringsutlösare kan köras från regler för automatisering av aviseringsutlösare. Du kan definiera flera åtgärder som anropar spelböcker eller kombinationer av spelböcker och andra åtgärder. Åtgärder utförs i den ordning de anges i regeln.
Spelböcker med antingen version av Azure Logic Apps (standard eller förbrukning) är tillgängliga för körning från automatiseringsregler.
Förfallodatum
Du kan definiera ett förfallodatum för en automatiseringsregel. Regeln är inaktiverad efter att det datumet har passerat. Detta är användbart för hantering av (dvs. stänga) "brus"-incidenter som orsakas av planerade, tidsbegränsade aktiviteter, till exempel intrångstestning.
Order
Du kan definiera i vilken ordning automationsregler körs. Senare utvärderar automatiseringsregler villkoren för incidenten enligt dess tillstånd efter att ha följts av tidigare automatiseringsregler.
Om till exempel "First Automation Rule" ändrade en incidents allvarlighetsgrad från Medel till Låg, och "Second Automation Rule" definieras för att endast köras på incidenter med medelhög eller högre allvarlighetsgrad, körs den inte på den incidenten.
Ordningen på automatiseringsregler som lägger till incidentaktiviteter avgör i vilken ordning aktiviteterna visas i en viss incident.
Regler som baseras på uppdateringsutlösaren har en egen separat orderkö. Om sådana regler utlöses för att köras på en incident som just har skapats (genom en ändring som gjorts av en annan automatiseringsregel) körs de först när alla tillämpliga regler som baseras på skapa-utlösaren har körts.
Anteckningar om körningsordning och prioritet
- Om du anger ordernumret i automatiseringsregler avgörs deras körningsordning.
- Varje utlösartyp har en egen kö.
- För regler som skapas i Azure Portal fylls orderfältet automatiskt i med talet som följer det högsta antalet som används av befintliga regler av samma utlösartyp.
- För regler som skapats på andra sätt (kommandorad, API osv.) måste ordernumret dock tilldelas manuellt.
- Det finns ingen valideringsmekanism som förhindrar att flera regler har samma ordernummer, även inom samma utlösartyp.
- Du kan tillåta att två eller flera regler av samma utlösartyp har samma ordernummer, om du inte bryr dig om vilken ordning de körs i.
- För regler av samma utlösartyp med samma ordernummer väljer körningsmotorn slumpmässigt vilka regler som körs i vilken ordning.
- För regler för olika typer av incidentutlösare körs alla tillämpliga regler med utlösartypen för incidentskapande först (enligt deras ordernummer) och först därefter reglerna med typ av incidentuppdateringsutlösare (enligt deras ordernummer).
- Regler körs alltid sekventiellt, aldrig parallellt.
Kommentar
När du har registrerat dig på Defender-portalen skickas en enda uppdatering till Microsoft Sentinel om flera ändringar görs i samma incident under en period på fem till tio minuter, med endast den senaste ändringen.
Vanliga användningsfall och scenarier
Incidentuppgifter
Med automatiseringsregler kan du standardisera och formalisera de steg som krävs för sortering, undersökning och reparation av incidenter genom att skapa uppgifter som kan tillämpas på en enskild incident, mellan grupper av incidenter eller för alla incidenter, enligt de villkor som du anger i automatiseringsregeln och logiken för hotidentifiering i de underliggande analysreglerna. Uppgifter som tillämpas på en incident visas på incidentens sida, så dina analytiker har hela listan över åtgärder som de behöver vidta, precis framför dem, och missa inte några kritiska steg.
Incident- och aviseringsutlöst automatisering
Automatiseringsregler kan utlösas genom att incidenter skapas eller uppdateras och även genom att aviseringar skapas. Dessa förekomster kan utlösa automatiserade svarskedjor, som kan innehålla spelböcker (särskilda behörigheter krävs).
Utlösa spelböcker för Microsoft-leverantörer
Automatiseringsregler är ett sätt att automatisera hanteringen av Microsofts säkerhetsaviseringar genom att tillämpa dessa regler på incidenter som skapats från aviseringarna. Automatiseringsreglerna kan anropa spelböcker (särskilda behörigheter krävs) och skicka incidenterna till dem med all information, inklusive aviseringar och entiteter. I allmänhet dikterar Microsoft Sentinel-metodtips att incidentkön används som fokuspunkt för säkerhetsåtgärder.
Microsofts säkerhetsaviseringar innehåller följande:
- Microsoft Entra ID Protection
- Microsoft Defender for Cloud
- Microsoft Defender för Cloud Apps
- Microsoft Defender för Office 365
- Microsoft Defender för slutpunkter
- Microsoft Defender for Identity
- Microsoft Defender for IoT
Flera sekvenserade spelböcker/åtgärder i en enda regel
Nu kan du ha nästan fullständig kontroll över ordningen för körning av åtgärder och spelböcker i en enda automatiseringsregel. Du kan också styra körningsordningen för själva automatiseringsreglerna. På så sätt kan du förenkla dina spelböcker avsevärt, minska dem till en enda uppgift eller en liten, enkel sekvens med uppgifter och kombinera dessa små spelböcker i olika kombinationer i olika automatiseringsregler.
Tilldela en spelbok till flera analysregler samtidigt
Om du har en uppgift som du vill automatisera på alla dina analysregler – t.ex. skapandet av en supportbegäran i ett externt biljettsystem – kan du tillämpa en enda spelbok på alla dina analysregler – inklusive eventuella framtida regler – på ett enda skott. Detta gör enkla men repetitiva underhålls- och hushållningsuppgifter mycket mindre av en syssla.
Automatisk tilldelning av incidenter
Du kan tilldela incidenter till rätt ägare automatiskt. Om din SOC har en analytiker som specialiserar sig på en viss plattform kan eventuella incidenter som rör den plattformen automatiskt tilldelas den analytikern.
Incidentundertryckning
Du kan använda regler för att automatiskt lösa incidenter som är kända falska/godartade positiva identifieringar utan användning av spelböcker. När du till exempel kör intrångstester, utför schemalagt underhåll eller uppgraderingar eller testar automatiseringsprocedurer kan många falska positiva incidenter skapas som SOC vill ignorera. En tidsbegränsad automatiseringsregel kan automatiskt stänga dessa incidenter när de skapas, samtidigt som de märks med en beskrivning av orsaken till deras generation.
Tidsbegränsad automatisering
Du kan lägga till förfallodatum för dina automatiseringsregler. Det kan finnas andra fall än incidentundertryckning som garanterar tidsbegränsad automatisering. Du kanske vill tilldela en viss typ av incident till en viss användare (till exempel en praktikant eller en konsult) för en viss tidsram. Om tidsramen är känd i förväg kan du effektivt göra så att regeln inaktiveras i slutet av dess relevans, utan att du behöver komma ihåg att göra det.
Tagga incidenter automatiskt
Du kan automatiskt lägga till fritexttaggar till incidenter för att gruppera eller klassificera dem enligt valfria kriterier.
Användningsfall som lagts till av uppdateringsutlösaren
Nu när ändringar som görs i incidenter kan utlösa automatiseringsregler är fler scenarier öppna för automatisering.
Utöka automatiseringen när incidenten utvecklas
Du kan använda uppdateringsutlösaren för att tillämpa många av ovanstående användningsfall på incidenter när undersökningen fortskrider och analytiker lägger till aviseringar, kommentarer och taggar. Kontrollera aviseringsgruppering i incidenter.
Uppdatera orkestrering och meddelande
Meddela dina olika team och annan personal när ändringar görs i incidenter, så att de inte missar några kritiska uppdateringar. Eskalera incidenter genom att tilldela dem till nya ägare och informera de nya ägarna om deras tilldelningar. Kontrollera när och hur incidenter öppnas igen.
Underhålla synkronisering med externa system
Om du använde spelböcker för att skapa biljetter i externa system när incidenter skapas kan du använda en automatiseringsregel för uppdateringsutlösare för att anropa en spelbok som uppdaterar dessa biljetter.
Körning av automationsregler
Automationsregler körs sekventiellt, enligt den ordning du bestämmer. Varje automatiseringsregel körs när den föregående har slutfört sin körning. I en automatiseringsregel körs alla åtgärder sekventiellt i den ordning de definieras.
Spelboksåtgärder inom en automatiseringsregel kan behandlas på olika sätt i vissa situationer enligt följande kriterier:
| Spelbokens körningstid | Automatiseringsregeln går vidare till nästa åtgärd … |
|---|---|
| Mindre än en sekund | Omedelbart efter att spelboken har avslutats |
| Mindre än två minuter | Upp till två minuter efter att spelboken började köras, men högst 10 sekunder efter att spelboken har slutförts |
| Mer än två minuter | Två minuter efter att spelboken började köras, oavsett om den har slutförts eller inte |
Behörigheter för automatiseringsregler för att köra spelböcker
När en Microsoft Sentinel-automatiseringsregel kör en spelbok använder den ett särskilt Microsoft Sentinel-tjänstkonto som är specifikt auktoriserat för den här åtgärden. Användningen av det här kontot (i motsats till ditt användarkonto) ökar säkerhetsnivån för tjänsten.
För att en automatiseringsregel ska kunna köra en spelbok måste det här kontot beviljas uttryckliga behörigheter till den resursgrupp där spelboken finns. Då kan alla automatiseringsregler köra valfri spelbok i resursgruppen.
När du konfigurerar en automatiseringsregel och lägger till en run playbook-åtgärd visas en listruta med spelböcker. Spelböcker som Microsoft Sentinel inte har behörighet att visa som otillgängliga ("nedtonade"). Du kan ge Microsoft Sentinel behörighet till spelböckernas resursgrupper på plats genom att välja länken Hantera spelboksbehörigheter . Om du vill bevilja dessa behörigheter behöver du ägarbehörigheter för dessa resursgrupper. Se de fullständiga behörighetskraven.
Behörigheter i en arkitektur med flera klientorganisationer
Automation-regler stöder helt distributioner mellan arbetsytor och flera klientorganisationer (när det gäller flera klientorganisationer med hjälp av Azure Lighthouse).
Om din Microsoft Sentinel-distribution använder en arkitektur med flera klienter kan du därför ha en automatiseringsregel i en klientorganisation som kör en spelbok som finns i en annan klientorganisation, men behörigheter för Sentinel att köra spelböckerna måste definieras i klientorganisationen där spelböckerna finns, inte i klientorganisationen där automatiseringsreglerna definieras.
I det specifika fallet med en hanterad säkerhetstjänstleverantör (MSSP), där en tjänstleverantörsklient hanterar en Microsoft Sentinel-arbetsyta i en kundklientorganisation, finns det två specifika scenarier som motiverar din uppmärksamhet:
En automatiseringsregel som skapats i kundklientorganisationen har konfigurerats för att köra en spelbok som finns i tjänstleverantörens klientorganisation.
Den här metoden används normalt för att skydda immateriella rättigheter i spelboken. Inget särskilt krävs för att det här scenariot ska fungera. När du definierar en spelboksåtgärd i automatiseringsregeln och du kommer till den fas där du beviljar Microsoft Sentinel-behörigheter för den relevanta resursgruppen där spelboken finns (med hjälp av panelen Hantera spelboksbehörigheter ) kan du se de resursgrupper som tillhör tjänstleverantörens klientorganisation bland de du kan välja mellan. Se hela processen som beskrivs här.
En automatiseringsregel som skapats på kundens arbetsyta (när den är inloggad i tjänstleverantörens klientorganisation) har konfigurerats för att köra en spelbok som finns i kundklientorganisationen.
Den här konfigurationen används när det inte finns något behov av att skydda immateriella rättigheter. För att det här scenariot ska fungera måste behörigheter för att köra spelboken beviljas till Microsoft Sentinel i båda klientorganisationer. I kundklientorganisationen beviljar du dem i panelen Hantera spelboksbehörigheter , precis som i scenariot ovan. Om du vill bevilja relevanta behörigheter i tjänstleverantörens klientorganisation måste du lägga till ytterligare en Azure Lighthouse-delegering som ger åtkomstbehörighet till Azure Security Insights-appen , med rollen Microsoft Sentinel Automation-deltagare , i resursgruppen där spelboken finns.
Scenariot ser ut så här:
Se våra instruktioner för att konfigurera detta.
Skapa och hantera automatiseringsregler
Du kan skapa och hantera automatiseringsregler från olika områden i Microsoft Sentinel eller Defender-portalen, beroende på ditt specifika behov och användningsfall.
Sidan Automation
Automationsregler kan hanteras centralt på sidan Automation under fliken Automation-regler . Därifrån kan du skapa nya automatiseringsregler och redigera de befintliga. Du kan också dra automatiseringsregler för att ändra körningsordningen och aktivera eller inaktivera dem.
På sidan Automation ser du alla regler som har definierats på arbetsytan, tillsammans med deras status (aktiverad/inaktiverad) och vilka analysregler de tillämpas på.
När du behöver en automatiseringsregel som gäller för incidenter från Microsoft Defender XDR, eller från många analysregler i Microsoft Sentinel, skapar du den direkt på sidan Automation .
Guiden Analysregel
På fliken Automatiserat svar i guiden Microsoft Sentinel-analysregel kan du under Automation-regler visa, redigera och skapa automatiseringsregler som gäller för den specifika analysregel som skapas eller redigeras i guiden.
När du skapar en automatiseringsregel härifrån visar panelen Skapa ny automatiseringsregel villkoret för analysregeln som otillgänglig, eftersom den här regeln redan är inställd på att endast gälla för den analysregel som du redigerar i guiden. Alla andra konfigurationsalternativ är fortfarande tillgängliga för dig.
Sidan Incidenter
Du kan också skapa en automatiseringsregel från sidan Incidenter för att kunna svara på en enda återkommande incident. Detta är användbart när du skapar en undertryckningsregel för att automatiskt stänga "bullriga" incidenter.
När du skapar en automatiseringsregel härifrån fyller panelen Skapa ny automatiseringsregel alla fält med värden från incidenten. Den namnger regeln med samma namn som incidenten, tillämpar den på analysregeln som genererade incidenten och använder alla tillgängliga entiteter i incidenten som villkor för regeln. Det föreslår också en undertryckningsåtgärd (stängning) som standard och föreslår ett förfallodatum för regeln. Du kan lägga till eller ta bort villkor och åtgärder och ändra förfallodatumet som du vill.
Export- och importautomatiseringsregler
Exportera dina automatiseringsregler till ARM-mallfiler (Azure Resource Manager) och importera regler från dessa filer som en del av hanteringen och kontrollen av dina Microsoft Sentinel-distributioner som kod. Exportåtgärden skapar en JSON-fil på webbläsarens nedladdningsplats, som du sedan kan byta namn på, flytta och på annat sätt hantera som alla andra filer.
Den exporterade JSON-filen är arbetsyteoberoende, så den kan importeras till andra arbetsytor och till och med andra klienter. Som kod kan den också vara versionskontrollerad, uppdaterad och distribuerad i ett hanterat CI/CD-ramverk.
Filen innehåller alla parametrar som definierats i automatiseringsregeln. Regler av valfri utlösartyp kan exporteras till en JSON-fil.
Anvisningar om hur du exporterar och importerar automatiseringsregler finns i Exportera och importera Microsoft Sentinel-automatiseringsregler.
Nästa steg
I det här dokumentet har du lärt dig hur automatiseringsregler kan hjälpa dig att centralt hantera svarsautomation för Microsoft Sentinel-incidenter och aviseringar.
- Skapa och använda Microsoft Sentinel-automatiseringsregler för att hantera incidenter.
- Använd automatiseringsregler för att skapa listor över uppgifter för analytiker.
- Mer information om avancerade automatiseringsalternativ finns i Automatisera hotsvar med spelböcker i Microsoft Sentinel.
- Hjälp med att implementera spelböcker finns i Självstudie: Använda spelböcker för att automatisera hotsvar i Microsoft Sentinel.