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), vilket ökar SOC:s effektivitet och sparar tid och resurser.
Viktigt!
Microsoft Sentinel är tillgängligt som en del av den offentliga förhandsversionen av den enhetliga säkerhetsåtgärdsplattformen i Microsoft Defender-portalen. 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 aviseringsom 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, med förbehåll för...
- Villkor som avgör de exakta omständigheter under vilka regeln ska köras och utföras...
- Åtgärder för att ändra incidenten på något sätt eller anropa en spelbok.
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, av vilka det finns flera typer, enligt beskrivningen i Identifiera hot med inbyggda analysregler 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 gör att regeln körs |
|---|---|
| När incidenten skapas | Enhetlig säkerhetsåtgärdsplattform i Microsoft Defender: Microsoft Sentinel har inte registrerats för enhetlig plattform: |
| När incidenten uppdateras | |
| När aviseringen skapas |
Incidentbaserad eller aviseringsbaserad automatisering?
Nu när både incidentautomatisering och aviseringsautomatisering hanteras centralt av automatiseringsregler och spelböcker, hur ska du välja när du ska använda vilken?
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 har inaktiveratspå fliken Incidentinställningar i guiden analysregel).
Den här orsaken är särskilt relevant när din Microsoft Sentinel-arbetsyta registreras på den enhetliga säkerhetsåtgärdsplattformen, eftersom alla incidenter skapas i Microsoft Defender XDR, 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 hur incidenter skapas från aviseringar, samt om och hur aviseringar grupperas i incidenter. Till exempel:
En spelbok kan utlösas av en avisering som inte har en associerad incident, berika aviseringen med information från andra källor och baserat på viss extern logik avgör om en incident ska skapas eller inte.
En spelbok kan utlösas av en avisering och i stället för att skapa en incident letar du efter en lämplig befintlig incident att lägga till aviseringen i. Läs mer om incidentexpansion.
En spelbok kan utlösas av en avisering och meddela SOC-personalen om aviseringen, så att teamet kan avgöra om en incident ska skapas eller inte.
En spelbok kan utlösas av en avisering och skicka aviseringen till ett externt biljettsystem för skapande och hantering av incidenter, vilket 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 på plattformen för enhetliga säkerhetsåtgärder. Mer information finns i Automation med den enhetliga säkerhetsåtgärdsplattformen.
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:
Värdet för en incidentegenskap
- ä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.
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 med något av följande värden, beroende på om du har registrerat din arbetsyta på den enhetliga säkerhetsåtgärdsplattformen:
- 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 av 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" |
SANT | Sant |
| Samling med alla taggar innehåller inte "2024" |
FALSKA | 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 blir resultatet detsamma, oavsett vilken typ av villkor som definieras.
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 automationsregeln ska köras 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 körs i den ordning de anges i regeln.
Spelböcker som använder någon av versionerna av Azure Logic Apps (standard eller förbrukning) kommer att vara tillgängliga för körning från automatiseringsregler.
Förfallodatum
Du kan definiera ett förfallodatum för en automatiseringsregel. Regeln inaktiveras efter det datumet. 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 ska köras. Senare kommer automatiseringsregler att utvärdera 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 uppgifterna ska 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 skapats i Azure-portalen 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 hindrar flera regler från att ha 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 ska köras 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 för den enhetliga säkerhetsåtgärdsplattformen skickas en enda uppdatering till Microsoft Sentinel om flera ändringar görs i samma incident under en fem till tio minuter lång period, 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 kommer inte att missa 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 for 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 har använt 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 biljetterna.
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 under vissa omständigheter, enligt följande kriterier:
| Körningstid för spelbok | Automationsregeln går vidare till nästa åtgärd... |
|---|---|
| Mindre än en sekund | Omedelbart efter att spelboken har slutförts |
| 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 den 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 till visas 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 ) ser du de resursgrupper som tillhör klientorganisationen för tjänsteleverantören 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 den enhetliga säkerhetsåtgärdsplattformen, 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.
Du kommer att märka att när du skapar en automatiseringsregel härifrån visar panelen Skapa ny automatiseringsregel villkoret för analysregeln som otillgängligt, 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.
Du kommer att märka att när du skapar en automatiseringsregel härifrån har panelen Skapa ny automatiseringsregel fyllt 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.
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.