Delen via


Bedreigingsreacties automatiseren in Microsoft Sentinel met automatiseringsregels

In dit artikel wordt uitgelegd wat automatiseringsregels voor Microsoft Sentinel zijn en hoe u deze kunt gebruiken om uw SOAR-bewerkingen (Security Orchestration, Automation and Response) te implementeren. Automatiseringsregels verhogen de effectiviteit van uw SOC en besparen u tijd en resources.

Belangrijk

Microsoft Sentinel is algemeen beschikbaar binnen het geïntegreerde beveiligingsbewerkingsplatform van Microsoft in de Microsoft Defender-portal. Voor preview is Microsoft Sentinel beschikbaar in de Defender-portal zonder Microsoft Defender XDR of een E5-licentie. Zie Microsoft Sentinel in de Microsoft Defender-portal voor meer informatie.

Wat zijn automatiseringsregels?

Automatiseringsregels zijn een manier om automatisering centraal te beheren in Microsoft Sentinel, doordat u een kleine set regels kunt definiëren en coördineren die in verschillende scenario's kunnen worden toegepast.

Automatiseringsregels zijn van toepassing op de volgende gebruikscategorieën:

  • Voer eenvoudige automatiseringstaken uit voor incidentafhandeling zonder playbooks te gebruiken. Voorbeeld:

    • Voeg incidenttaken toe die analisten moeten volgen.
    • Onderdrukt ruisincidenten.
    • Nieuwe incidenten sorteren door de status van Nieuw in Actief te wijzigen en een eigenaar toe te wijzen.
    • Tag incidenten om ze te classificeren.
    • Escaleer een incident door een nieuwe eigenaar toe te wijzen.
    • Sluit opgeloste incidenten, geef een reden op en voeg opmerkingen toe.
  • Automatiseer reacties voor meerdere analyseregels tegelijk.

  • Bepaal de volgorde van acties die worden uitgevoerd.

  • Inspecteer de inhoud van een incident (waarschuwingen, entiteiten en andere eigenschappen) en voer verdere actie uit door een playbook aan te roepen.

  • Automatiseringsregels kunnen ook het mechanisme zijn waarmee u een playbook uitvoert als reactie op een waarschuwing die niet is gekoppeld aan een incident.

Kortom, automatiseringsregels stroomlijnen het gebruik van automatisering in Microsoft Sentinel, zodat u complexe werkstromen voor uw indelingsprocessen voor bedreigingen kunt vereenvoudigen.

Onderdelen

Automatiseringsregels bestaan uit verschillende onderdelen:

  • Triggers die definiëren welk type incident gebeurtenis ervoor zorgt dat de regel wordt uitgevoerd, afhankelijk van voorwaarden.
  • Voorwaarden die bepalen onder welke omstandigheden de regel wordt uitgevoerd en acties worden uitgevoerd.
  • Acties om het incident op een of andere manier te wijzigen of een playbook aan te roepen, waarmee complexere acties worden uitgevoerd en andere services worden gebruikt.

Triggers

Automatiseringsregels worden geactiveerd wanneer een incident wordt gemaakt of bijgewerkt of wanneer een waarschuwing wordt gemaakt. Denk eraan dat incidenten waarschuwingen bevatten en dat zowel waarschuwingen als incidenten kunnen worden gemaakt door analyseregels, zoals wordt uitgelegd in detectie van bedreigingen in Microsoft Sentinel.

In de volgende tabel ziet u de verschillende mogelijke scenario's die ertoe leiden dat een automatiseringsregel wordt uitgevoerd.

Triggertype Gebeurtenissen die ervoor zorgen dat de regel wordt uitgevoerd
Wanneer een incident wordt gemaakt Microsoft Defender-portal:
  • Er wordt een nieuw incident gemaakt in de Microsoft Defender-portal.

    Microsoft Sentinel is niet ge onboarded naar de Defender-portal:
  • Er wordt een nieuw incident gemaakt door een analyseregel.
  • Een incident wordt opgenomen vanuit Microsoft Defender XDR.
  • Er wordt handmatig een nieuw incident gemaakt.
  • Wanneer incident wordt bijgewerkt
  • De status van een incident wordt gewijzigd (gesloten/opnieuw geopend/gesorteerd).
  • De eigenaar van een incident wordt toegewezen of gewijzigd.
  • De ernst van een incident wordt verhoogd of verlaagd.
  • Waarschuwingen worden toegevoegd aan een incident.
  • Opmerkingen, tags of tactieken worden toegevoegd aan een incident.
  • Wanneer een waarschuwing wordt gemaakt
  • Er wordt een waarschuwing gemaakt door een door Microsoft Sentinel geplande of NRT-analyseregel .
  • Automatisering op basis van incidenten of waarschuwingen?

    Hoe moet u met automatiseringsregels de reactie op incidenten en waarschuwingen centraal afhandelen, hoe moet u kiezen welke te automatiseren en in welke omstandigheden?

    Voor de meeste gebruiksscenario's is automatisering die wordt geactiveerd door incidenten de voorkeur. In Microsoft Sentinel is een incident een 'case-bestand': een aggregatie van alle relevante bewijzen voor een specifiek onderzoek. Het is een container voor waarschuwingen, entiteiten, opmerkingen, samenwerking en andere artefacten. In tegenstelling tot waarschuwingen die één stukje bewijs zijn, kunnen incidenten worden gewijzigd, de meest bijgewerkte status hebben en kunnen worden verrijkt met opmerkingen, tags en bladwijzers. Met het incident kunt u het aanvalsverhaal bijhouden dat zich blijft ontwikkelen met de toevoeging van nieuwe waarschuwingen.

    Om deze redenen is het logischer om uw automatisering rond incidenten te bouwen. De meest geschikte manier om playbooks te maken, is door ze te baseren op de Microsoft Sentinel-incidenttrigger in Azure Logic Apps.

    De belangrijkste reden voor het gebruik van door waarschuwingen geactiveerde automatisering is het reageren op waarschuwingen die worden gegenereerd door analyseregels die geen incidenten maken (dat wil gezegd, waarbij het maken van incidenten is uitgeschakeld op het tabblad Incidentinstellingen van de wizard Analyseregels).

    Deze reden is vooral relevant wanneer uw Microsoft Sentinel-werkruimte wordt toegevoegd aan de Defender-portal. In dit scenario gebeurt het maken van incidenten in de Defender-portal en daarom moeten de regels voor het maken van incidenten in Microsoft Sentinel worden uitgeschakeld.

    Zelfs zonder onboarding naar de geïntegreerde portal te worden uitgevoerd, kunt u toch besluiten om automatisering door waarschuwingen te gebruiken als u andere externe logica wilt gebruiken om te bepalen of en wanneer incidenten moeten worden gemaakt op basis van waarschuwingen en hoe waarschuwingen worden gegroepeerd. Voorbeeld:

    • Een playbook, geactiveerd door een waarschuwing die geen bijgehorend incident heeft, kan de waarschuwing verrijken met informatie uit andere bronnen en op basis van een externe logica bepalen of een incident moet worden gemaakt of niet.

    • Een playbook, geactiveerd door een waarschuwing, kan, in plaats van een incident te maken, zoeken naar een geschikt bestaand incident waaraan de waarschuwing moet worden toegevoegd. Meer informatie over incidentuitbreiding.

    • Een playbook, geactiveerd door een waarschuwing, kan SOC-personeel op de hoogte stellen van de waarschuwing, zodat het team kan beslissen of er een incident moet worden gemaakt.

    • Een playbook, geactiveerd door een waarschuwing, kan de waarschuwing verzenden naar een extern ticketsysteem voor het maken en beheren van incidenten en dat systeem maakt een nieuw ticket voor elke waarschuwing.

    Notitie

    Voorwaarden

    Complexe sets voorwaarden kunnen worden gedefinieerd om te bepalen wanneer acties (zie hieronder) moeten worden uitgevoerd. Deze voorwaarden omvatten de gebeurtenis die de regel activeert (incident gemaakt of bijgewerkt of waarschuwing gemaakt), de statussen of waarden van de eigenschappen en entiteitseigenschappen van het incident (alleen voor incidenttrigger) en ook de analyseregel of regels die het incident of de waarschuwing hebben gegenereerd.

    Wanneer een automatiseringsregel wordt geactiveerd, wordt het activerende incident of de waarschuwing gecontroleerd op de voorwaarden die in de regel zijn gedefinieerd. Voor incidenten worden de op eigenschappen gebaseerde voorwaarden geëvalueerd op basis van de huidige status van de eigenschap op het moment dat de evaluatie plaatsvindt, of volgens wijzigingen in de status van de eigenschap (zie hieronder voor meer informatie). Aangezien één incident maken of bijwerken meerdere automatiseringsregels kan activeren, maakt de volgorde waarin ze worden uitgevoerd (zie hieronder) een verschil in het bepalen van het resultaat van de evaluatie van de voorwaarden. De acties die in de regel zijn gedefinieerd, worden alleen uitgevoerd als aan alle voorwaarden wordt voldaan.

    Trigger voor het maken van incidenten

    Voor regels die zijn gedefinieerd met behulp van de trigger Wanneer een incident wordt gemaakt, kunt u voorwaarden definiëren die de huidige status van de waarden van een bepaalde lijst met incidenteigenschappen controleren met behulp van een of meer van de volgende operators:

    • is gelijk aan of is niet gelijk aan de waarde die is gedefinieerd in de voorwaarde.
    • bevat of bevat niet de waarde die in de voorwaarde is gedefinieerd.
    • begint met of begint niet met de waarde die in de voorwaarde is gedefinieerd.
    • eindigt met of eindigt niet met de waarde die is gedefinieerd in de voorwaarde.

    Als u bijvoorbeeld de naam van de analyseregel definieert als Contains == Brute force-aanval op een cloud-pc, voldoet een analytische regel met de Brute force-aanval tegen Azure Portal niet aan de voorwaarde. Als u echter de naam van de analyseregel definieert zoals Geen == Gebruikersreferenties bevat, voldoen zowel de Brute Force-aanval tegen een Cloud-pc als Brute Force tegen analyseregels van Azure Portal aan de voorwaarde.

    Notitie

    De huidige status in deze context verwijst naar het moment waarop de voorwaarde wordt geëvalueerd. Dat wil gezegd, het moment waarop de automatiseringsregel wordt uitgevoerd. Als er meer dan één automatiseringsregel is gedefinieerd om te worden uitgevoerd als reactie op het maken van dit incident, worden wijzigingen in het incident door een eerdere automatiseringsregel beschouwd als de huidige status voor regels voor latere uitvoeringen.

    Trigger voor incidentupdate

    De voorwaarden die worden geëvalueerd in regels die zijn gedefinieerd met behulp van de trigger Wanneer een incident wordt bijgewerkt , bevatten alle voorwaarden die worden vermeld voor de trigger voor het maken van incidenten. De updatetrigger bevat echter meer eigenschappen die kunnen worden geëvalueerd.

    Een van deze eigenschappen is bijgewerkt door. Met deze eigenschap kunt u het type bron bijhouden dat de wijziging in het incident heeft aangebracht. U kunt een voorwaarde maken die evalueert of het incident is bijgewerkt met een van de volgende waarden, afhankelijk van of u uw werkruimte hebt toegevoegd aan de Defender-portal:

    • Een toepassing, inclusief toepassingen in de Azure- en Defender-portals.
    • Een gebruiker, inclusief wijzigingen die zijn aangebracht door gebruikers in zowel de Azure- als de Defender-portal.
    • AIR, voor updates door geautomatiseerd onderzoek en reactie in Microsoft Defender voor Office 365
    • Een waarschuwingsgroepering (die waarschuwingen aan het incident heeft toegevoegd), inclusief waarschuwingsgroepen die zijn uitgevoerd door analyseregels en ingebouwde Correlatielogica van Microsoft Defender XDR
    • Een playbook
    • Een automatiseringsregel
    • Als geen van de bovenstaande waarden van toepassing is

    Met deze voorwaarde kunt u bijvoorbeeld deze automatiseringsregel instrueren om uit te voeren op elke wijziging die is aangebracht in een incident, behalve als deze is gemaakt door een andere automatiseringsregel.

    Meer nog, de updatetrigger maakt ook gebruik van andere operators die statuswijzigingen controleren in de waarden van incidenteigenschappen en hun huidige status. Aan een statuswijzigingsvoorwaarde wordt voldaan als:

    De waarde van een incidenteigenschap was

    • gewijzigd (ongeacht de werkelijke waarde vóór of na).
    • gewijzigd van de waarde die in de voorwaarde is gedefinieerd.
    • gewijzigd in de waarde die is gedefinieerd in de voorwaarde.
    • toegevoegd aan (dit geldt voor eigenschappen met een lijst met waarden).

    Tageigenschap : afzonderlijke versus verzameling

    De incidenteigenschapstag is een verzameling afzonderlijke items. Op één incident kunnen meerdere tags worden toegepast. U kunt voorwaarden definiëren waarmee elke tag afzonderlijk in de verzameling wordt gecontroleerd en voorwaarden waarmee de verzameling tags als eenheid wordt gecontroleerd.

    • Elke afzonderlijke tagoperator controleert de voorwaarde voor elke tag in de verzameling. De evaluatie is waar wanneer ten minste één tag voldoet aan de voorwaarde.
    • Verzameling van alle tagsoperators controleert de voorwaarde voor de verzameling tags als één eenheid. De evaluatie geldt alleen als de verzameling als geheel voldoet aan de voorwaarde.

    Dit onderscheid is van belang wanneer uw voorwaarde een negatief is (niet bevat) en sommige tags in de verzameling voldoen aan de voorwaarde en andere niet.

    Laten we eens kijken naar een voorbeeld waarin uw voorwaarde is, Tag bevat geen '2024', en u hebt twee incidenten, elk met twee tags:

    \Incidenten ▶
    Voorwaarde ^ \
    Incident 1
    Tag 1: 2024
    Tag 2: 2023
    Incident 2
    Tag 1: 2023
    Tag 2: 2022
    Elke afzonderlijke tag
    bevat geen "2024"
    WAAR TRUE
    Verzameling van alle tags
    bevat geen "2024"
    ONWAAR TRUE

    In dit voorbeeld in Incident 1:

    • Als de voorwaarde elke tag afzonderlijk controleert, is de algehele voorwaarde waar omdat er ten minste één tag aan de voorwaarde voldoet (die niet '2024' bevat).
    • Als de voorwaarde alle tags in het incident als één eenheid controleert, is de algehele voorwaarde onwaar omdat er ten minste één tag is die niet voldoet aan de voorwaarde (die wel '2024' bevat).

    In Incident 2 is het resultaat hetzelfde, ongeacht welk type voorwaarde is gedefinieerd.

    Ondersteunde entiteitseigenschappen

    Zie de naslaginformatie over automatiseringsregels voor de lijst met entiteitseigenschappen die worden ondersteund als voorwaarden voor automatiseringsregels.

    Trigger voor het maken van waarschuwingen

    Momenteel is de enige voorwaarde die kan worden geconfigureerd voor de trigger voor het maken van waarschuwingen de set analyseregels waarvoor de automatiseringsregel wordt uitgevoerd.

    Acties

    Acties kunnen worden gedefinieerd om uit te voeren wanneer aan de voorwaarden (zie hierboven) wordt voldaan. U kunt veel acties definiëren in een regel en u kunt de volgorde kiezen waarin ze worden uitgevoerd (zie hieronder). De volgende acties kunnen worden gedefinieerd met behulp van automatiseringsregels, zonder dat u de geavanceerde functionaliteit van een playbook nodig hebt:

    • Een taak toevoegen aan een incident: u kunt een controlelijst maken voor taken die analisten moeten volgen tijdens de processen van het triage, onderzoek en herstel van het incident, om ervoor te zorgen dat er geen kritieke stappen worden gemist.

    • De status van een incident wijzigen, zodat uw werkstroom up-to-date blijft.

      • Wanneer u overschakelen naar 'gesloten', geeft u de reden voor sluiten op en voegt u een opmerking toe. Zo kunt u uw prestaties en effectiviteit bijhouden en afstemmen om fout-positieven te verminderen.
    • De ernst van een incident wijzigen: u kunt de ernst van een incident opnieuw evalueren en herpriritiseren op basis van de aanwezigheid, afwezigheid, waarden of kenmerken van entiteiten die betrokken zijn bij het incident.

    • Het toewijzen van een incident aan een eigenaar: dit helpt u bij het doorsturen van typen incidenten naar het personeel dat het meest geschikt is om ermee om te gaan, of aan het meest beschikbare personeel.

    • Een tag toevoegen aan een incident: dit is handig voor het classificeren van incidenten per onderwerp, door aanvaller of door een andere veelgebruikte noemer.

    U kunt ook een actie definiëren om een playbook uit te voeren om complexere antwoordacties uit te voeren, inclusief acties die betrekking hebben op externe systemen. De playbooks die beschikbaar zijn voor gebruik in een automatiseringsregel, zijn afhankelijk van de trigger waarop de playbooks en de automatiseringsregel zijn gebaseerd: Alleen playbooks voor incidenttriggers kunnen worden uitgevoerd op basis van automatiseringsregels voor incidenttriggers en alleen playbooks voor waarschuwingstriggers kunnen worden uitgevoerd vanuit automatiseringsregels voor waarschuwingentriggers. U kunt meerdere acties definiëren die playbooks aanroepen of combinaties van playbooks en andere acties. Acties worden uitgevoerd in de volgorde waarin ze worden vermeld in de regel.

    Playbooks die gebruikmaken van een van beide versies van Azure Logic Apps (Standard of Consumption) zijn beschikbaar om te worden uitgevoerd vanuit automatiseringsregels.

    Vervaldatum

    U kunt een vervaldatum definiëren voor een automatiseringsregel. De regel is uitgeschakeld nadat deze datum is verstreken. Dit is handig voor het verwerken (dat wil gezegd, afsluiten) 'ruis'-incidenten die worden veroorzaakt door geplande, tijdgebonden activiteiten zoals penetratietests.

    Order

    U kunt de volgorde definiëren waarin automatiseringsregels worden uitgevoerd. Latere automatiseringsregels evalueren de voorwaarden van het incident volgens de status ervan nadat ze zijn uitgevoerd door eerdere automatiseringsregels.

    Als 'First Automation Rule' bijvoorbeeld de ernst van een incident heeft gewijzigd van normaal naar laag en tweede automatiseringsregel is gedefinieerd om alleen te worden uitgevoerd op incidenten met gemiddelde of hogere ernst, wordt deze niet uitgevoerd op dat incident.

    De volgorde van automatiseringsregels waarmee incidenttaken worden toegevoegd, bepaalt de volgorde waarin de taken in een bepaald incident worden weergegeven.

    Regels op basis van de updatetrigger hebben hun eigen afzonderlijke orderwachtrij. Als dergelijke regels worden geactiveerd om te worden uitgevoerd op een zojuist gemaakt incident (door een wijziging die is aangebracht door een andere automatiseringsregel), worden ze pas uitgevoerd nadat alle toepasselijke regels op basis van de create-trigger zijn uitgevoerd.

    Opmerkingen over uitvoeringsvolgorde en prioriteit

    • Het instellen van het ordernummer in automatiseringsregels bepaalt de volgorde van uitvoering.
    • Elk triggertype onderhoudt een eigen wachtrij.
    • Voor regels die zijn gemaakt in Azure Portal, wordt het orderveld automatisch gevuld met het nummer dat volgt op het hoogste aantal dat wordt gebruikt door bestaande regels van hetzelfde triggertype.
    • Voor regels die op andere manieren zijn gemaakt (opdrachtregel, API, enzovoort), moet het ordernummer echter handmatig worden toegewezen.
    • Er is geen validatiemechanisme dat voorkomt dat meerdere regels hetzelfde ordernummer hebben, zelfs binnen hetzelfde triggertype.
    • U kunt toestaan dat twee of meer regels van hetzelfde triggertype hetzelfde ordernummer hebben, als het u niet uitmaakt in welke volgorde ze worden uitgevoerd.
    • Voor regels van hetzelfde triggertype met hetzelfde ordernummer selecteert de uitvoeringsengine willekeurig welke regels worden uitgevoerd in welke volgorde.
    • Voor regels van verschillende typen incidenttriggers worden alle toepasselijke regels met het triggertype voor het maken van incidenten eerst uitgevoerd (op basis van hun ordernummers) en alleen de regels met het triggertype incidentupdate (volgens hun ordernummers).
    • Regels worden altijd opeenvolgend uitgevoerd, nooit parallel.

    Notitie

    Als na onboarding naar de Defender-portal meerdere wijzigingen worden aangebracht in hetzelfde incident in een periode van vijf tot tien minuten, wordt er één update verzonden naar Microsoft Sentinel, met alleen de meest recente wijziging.

    Veelvoorkomende gebruikstoepassingen en scenario's

    Incidenttaken

    Met automatiseringsregels kunt u de stappen die nodig zijn voor het trireren, onderzoeken en herstellen van incidenten standaardiseren en formaliseren door taken te maken die kunnen worden toegepast op één incident, in groepen incidenten of op alle incidenten, volgens de voorwaarden die u hebt ingesteld in de automatiseringsregel en de logica voor bedreigingsdetectie in de onderliggende analyseregels. Taken die zijn toegepast op een incident worden weergegeven op de pagina van het incident, zodat uw analisten de volledige lijst met acties hebben die ze moeten uitvoeren, direct voor hen en geen kritieke stappen missen.

    Automatisering door incidenten en waarschuwingen geactiveerd

    Automatiseringsregels kunnen worden geactiveerd door het maken of bijwerken van incidenten en ook door het maken van waarschuwingen. Deze exemplaren kunnen alle geautomatiseerde reactieketens activeren, waaronder playbooks (speciale machtigingen zijn vereist).

    Playbooks activeren voor Microsoft-providers

    Automatiseringsregels bieden een manier om de verwerking van Beveiligingswaarschuwingen van Microsoft te automatiseren door deze regels toe te passen op incidenten die zijn gemaakt op basis van de waarschuwingen. De automatiseringsregels kunnen playbooks aanroepen (speciale machtigingen zijn vereist) en de incidenten doorgeven met al hun details, inclusief waarschuwingen en entiteiten. Over het algemeen bepalen de best practices van Microsoft Sentinel het gebruik van de incidentenwachtrij als het middelpunt van beveiligingsbewerkingen.

    Microsoft-beveiligingswaarschuwingen omvatten het volgende:

    • Microsoft Entra ID-beveiliging
    • Microsoft Defender for Cloud
    • Microsoft Defender for Cloud Apps
    • Microsoft Defender for Office 365
    • Microsoft Defender voor Eindpunten
    • Microsoft Defender for Identity
    • Microsoft Defender for IoT

    Meerdere gesequentieerde playbooks/acties in één regel

    U kunt nu bijna volledige controle hebben over de volgorde van de uitvoering van acties en playbooks in één automatiseringsregel. U bepaalt ook de volgorde van de uitvoering van de automatiseringsregels zelf. Hierdoor kunt u uw playbooks aanzienlijk vereenvoudigen, ze verminderen tot één taak of een kleine, eenvoudige reeks taken en deze kleine playbooks combineren in verschillende combinaties in verschillende automatiseringsregels.

    Eén playbook toewijzen aan meerdere analyseregels tegelijk

    Als u een taak hebt die u wilt automatiseren op al uw analyseregels, bijvoorbeeld het maken van een ondersteuningsticket in een extern ticketsysteem, kunt u in één shot één playbook toepassen op een of al uw analyseregels, inclusief toekomstige regels. Dit maakt eenvoudige maar terugkerende onderhouds- en huishoudtaken veel minder van een klus.

    Automatische toewijzing van incidenten

    U kunt incidenten automatisch toewijzen aan de juiste eigenaar. Als uw SOC een analist heeft die gespecialiseerd is in een bepaald platform, kunnen incidenten met betrekking tot dat platform automatisch worden toegewezen aan die analist.

    Incidentonderdrukking

    U kunt regels gebruiken om incidenten die bekende fout-/goedaardige positieven zijn automatisch op te lossen zonder gebruik te maken van playbooks. Wanneer u bijvoorbeeld penetratietests uitvoert, gepland onderhoud of upgrades uitvoert of automatiseringsprocedures test, kunnen er veel fout-positieve incidenten worden gemaakt die de SOC wil negeren. Een automatiseringsregel met beperkte tijd kan deze incidenten automatisch sluiten wanneer ze worden gemaakt, terwijl ze worden gelabeld met een beschrijving van de oorzaak van hun generatie.

    Tijdsgebonden automatisering

    U kunt vervaldatums toevoegen voor uw automatiseringsregels. Er kunnen andere gevallen zijn dan incidentonderdrukking die tijdsbeperkingen rechtvaardigen. U kunt een bepaald type incident toewijzen aan een bepaalde gebruiker (bijvoorbeeld een intern of consultant) voor een bepaald tijdsbestek. Als het tijdsbestek van tevoren bekend is, kunt u ervoor zorgen dat de regel effectief wordt uitgeschakeld aan het einde van de relevantie, zonder dat u dit hoeft te doen.

    Incidenten automatisch taggen

    U kunt automatisch vrije-teksttags toevoegen aan incidenten om ze te groeperen of classificeren op basis van de criteria van uw keuze.

    Use cases toegevoegd door updatetrigger

    Nu wijzigingen in incidenten automatiseringsregels kunnen activeren, zijn er meer scenario's open voor automatisering.

    Automatisering uitbreiden wanneer incident zich ontwikkelt

    U kunt de updatetrigger gebruiken om veel van de bovenstaande use cases toe te passen op incidenten wanneer hun onderzoek vordert en analisten waarschuwingen, opmerkingen en tags toevoegen. Het groeperen van waarschuwingen in incidenten beheren.

    Indeling en melding bijwerken

    Informeer uw verschillende teams en andere medewerkers wanneer er wijzigingen worden aangebracht in incidenten, zodat ze geen essentiële updates missen. Escaleer incidenten door ze toe te wijzen aan nieuwe eigenaren en de nieuwe eigenaren van hun toewijzingen te informeren. Bepalen wanneer en hoe incidenten opnieuw worden geopend.

    Synchronisatie met externe systemen onderhouden

    Als u playbooks hebt gebruikt om tickets te maken in externe systemen wanneer er incidenten worden gemaakt, kunt u een automatiseringsregel voor updatetriggers gebruiken om een playbook aan te roepen waarmee deze tickets worden bijgewerkt.

    Uitvoering van Automatiseringsregels

    Automatiseringsregels worden opeenvolgend uitgevoerd volgens de volgorde die u bepaalt. Elke automatiseringsregel wordt uitgevoerd nadat de vorige regel is uitgevoerd. Binnen een automatiseringsregel worden alle acties opeenvolgend uitgevoerd in de volgorde waarin ze zijn gedefinieerd.

    Playbook-acties binnen een automatiseringsregel kunnen onder bepaalde omstandigheden anders worden behandeld, volgens de volgende criteria:

    Runtime van playbook Automatiseringsregel gaat verder met de volgende actie...
    Korter dan 1 seconde Onmiddellijk nadat het playbook is voltooid
    Minder dan twee minuten Maximaal twee minuten nadat het playbook begon te draaien,
    maar niet meer dan 10 seconden nadat het playbook is voltooid
    Meer dan twee minuten Twee minuten nadat het playbook begon te draaien,
    ongeacht of het al dan niet is voltooid

    Machtigingen voor automatiseringsregels voor het uitvoeren van playbooks

    Wanneer een Automatiseringsregel van Microsoft Sentinel een playbook uitvoert, wordt een speciaal Microsoft Sentinel-serviceaccount gebruikt dat specifiek is geautoriseerd voor deze actie. Het gebruik van dit account (in tegenstelling tot uw gebruikersaccount) verhoogt het beveiligingsniveau van de service.

    Als u een automatiseringsregel wilt gebruiken om een playbook uit te voeren, moet u aan dit account expliciete machtigingen verlenen voor de resourcegroep waarin het playbook zich bevindt. Op dat moment kan elke automatiseringsregel elk playbook in die resourcegroep uitvoeren.

    Wanneer u een automatiseringsregel configureert en een playbookactie uitvoert, wordt er een vervolgkeuzelijst met playbooks weergegeven. Playbooks waarvoor Microsoft Sentinel geen machtigingen heeft, worden weergegeven als niet beschikbaar (grijs weergegeven). U kunt Microsoft Sentinel toestemming verlenen aan de resourcegroepen van de playbooks ter plaatse door de koppeling Playbookmachtigingen beheren te selecteren. Als u deze machtigingen wilt verlenen, hebt u eigenaarsmachtigingen nodig voor deze resourcegroepen. Zie de volledige machtigingsvereisten.

    Machtigingen in een architectuur met meerdere tenants

    Automatiseringsregels bieden volledige ondersteuning voor implementaties tussen werkruimten en meerdere tenants (in het geval van multitenant, met behulp van Azure Lighthouse).

    Als uw Microsoft Sentinel-implementatie gebruikmaakt van een architectuur met meerdere tenants, kunt u dus een automatiseringsregel in één tenant uitvoeren met een playbook dat zich in een andere tenant bevindt, maar machtigingen voor Sentinel om de playbooks uit te voeren, moeten worden gedefinieerd in de tenant waarin de playbooks zich bevinden, niet in de tenant waarin de automatiseringsregels zijn gedefinieerd.

    In het specifieke geval van een Managed Security Service Provider (MSSP), waarbij een serviceprovidertenant een Microsoft Sentinel-werkruimte beheert in een klanttenant, zijn er twee specifieke scenario's die uw aandacht rechtvaardigen:

    • Een automatiseringsregel die is gemaakt in de tenant van de klant, is geconfigureerd voor het uitvoeren van een playbook in de tenant van de serviceprovider.

      Deze benadering wordt normaal gesproken gebruikt om intellectueel eigendom in het playbook te beschermen. Er is niets speciaals vereist om dit scenario te laten werken. Wanneer u een playbookactie definieert in uw automatiseringsregel en u toegang krijgt tot de fase waarin u Microsoft Sentinel-machtigingen verleent voor de relevante resourcegroep waar het playbook zich bevindt (met behulp van het deelvenster Playbookmachtigingen beheren), kunt u de resourcegroepen zien die behoren tot de tenant van de serviceprovider waaruit u kunt kiezen. Bekijk het hele proces dat hier wordt beschreven.

    • Een automatiseringsregel die is gemaakt in de werkruimte van de klant (terwijl u bent aangemeld bij de tenant van de serviceprovider) is geconfigureerd voor het uitvoeren van een playbook in de tenant van de klant.

      Deze configuratie wordt gebruikt wanneer het intellectueel eigendom niet hoeft te worden beschermd. Voordat dit scenario werkt, moeten machtigingen voor het uitvoeren van het playbook worden verleend aan Microsoft Sentinel in beide tenants. In de tenant van de klant verleent u deze in het deelvenster Playbookmachtigingen beheren, net zoals in het bovenstaande scenario. Als u de relevante machtigingen wilt verlenen in de tenant van de serviceprovider, moet u een extra Azure Lighthouse-delegatie toevoegen die toegangsrechten verleent aan de Azure Security Insights-app , met de rol Microsoft Sentinel Automation-inzender , in de resourcegroep waarin het playbook zich bevindt.

      Het scenario ziet er als volgt uit:

      Architectuur voor automatiseringsregel voor meerdere tenants

      Zie onze instructies voor het instellen hiervan.

    Automatiseringsregels maken en beheren

    U kunt automatiseringsregels maken en beheren op basis van verschillende gebieden in Microsoft Sentinel of de Defender-portal, afhankelijk van uw specifieke behoefte en use-case.

    • Automation-pagina

      Automatiseringsregels kunnen centraal worden beheerd op de pagina Automation , op het tabblad Automatiseringsregels . Hier kunt u nieuwe automatiseringsregels maken en de bestaande regels bewerken. U kunt automatiseringsregels ook slepen om de uitvoeringsvolgorde te wijzigen en deze in of uit te schakelen.

      Op de pagina Automation ziet u alle regels die zijn gedefinieerd in de werkruimte, samen met de status (ingeschakeld/uitgeschakeld) en op welke analyseregels ze worden toegepast.

      Wanneer u een automatiseringsregel nodig hebt die van toepassing is op incidenten van Microsoft Defender XDR of van veel analyseregels in Microsoft Sentinel, maakt u deze rechtstreeks op de automation-pagina .

    • Wizard Analyseregel

      Op het tabblad Automatisch antwoord van de wizard Microsoft Sentinel-analyseregels kunt u onder Automatiseringsregels automatiseringsregels bekijken, bewerken en maken die van toepassing zijn op de specifieke analyseregel die in de wizard wordt gemaakt of bewerkt.

      Wanneer u hier een automatiseringsregel maakt, wordt in het deelvenster Nieuwe automatiseringsregel maken de voorwaarde van de analyseregel weergegeven als niet beschikbaar, omdat deze regel al is ingesteld om alleen van toepassing te zijn op de analyseregel die u in de wizard bewerkt. Alle andere configuratieopties zijn nog steeds beschikbaar voor u.

    • Pagina Incidenten

      U kunt ook een automatiseringsregel maken op de pagina Incidenten om te reageren op één terugkerend incident. Dit is handig bij het maken van een onderdrukkingsregel voor het automatisch sluiten van 'luidruchtige' incidenten.

      Wanneer u hier een automatiseringsregel maakt, vult het deelvenster Nieuwe automatiseringsregel maken alle velden met waarden van het incident. Deze noemt de regel dezelfde naam als het incident, past deze toe op de analyseregel die het incident heeft gegenereerd en gebruikt alle beschikbare entiteiten in het incident als voorwaarden van de regel. Er wordt ook standaard een onderdrukkingsactie (afsluiten) voorgesteld en wordt een vervaldatum voor de regel voorgesteld. U kunt voorwaarden en acties toevoegen of verwijderen en de vervaldatum desgewenst wijzigen.

    Automatiseringsregels exporteren en importeren

    Exporteer uw automatiseringsregels naar ARM-sjabloonbestanden (Azure Resource Manager) en importeer regels uit deze bestanden als onderdeel van het beheren en beheren van uw Microsoft Sentinel-implementaties als code. Met de exportactie maakt u een JSON-bestand op de downloadlocatie van uw browser, die u vervolgens kunt hernoemen, verplaatsen en anderszins kunt verwerken zoals elk ander bestand.

    Het geëxporteerde JSON-bestand is werkruimte-onafhankelijk, zodat het kan worden geïmporteerd in andere werkruimten en zelfs andere tenants. Als code kan het ook versiebeheerd, bijgewerkt en geïmplementeerd worden in een beheerd CI/CD-framework.

    Het bestand bevat alle parameters die zijn gedefinieerd in de automatiseringsregel. Regels van elk triggertype kunnen worden geëxporteerd naar een JSON-bestand.

    Zie Automatiseringsregels van Microsoft Sentinel exporteren en importeren voor instructies voor het exporteren en importeren van automatiseringsregels.

    Volgende stappen

    In dit document hebt u geleerd hoe automatiseringsregels u kunnen helpen bij het centraal beheren van reactieautomatisering voor Microsoft Sentinel-incidenten en -waarschuwingen.