Bedreigingsreacties automatiseren in Microsoft Sentinel met automatiseringsregels
In dit artikel wordt uitgelegd wat automatiseringsregels van Microsoft Sentinel zijn en hoe u deze kunt gebruiken om uw SOAR-bewerkingen (Security Orchestration, Automation and Response) te implementeren, de effectiviteit van uw SOC te vergroten en tijd en resources te besparen.
Belangrijk
Microsoft Sentinel is beschikbaar als onderdeel van de openbare preview voor het geïntegreerde platform voor beveiligingsbewerkingen in de Microsoft Defender-portal. 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 waarschuwingdie 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 bepalen welk type incident gebeurtenis ervoor zorgt dat de regel wordt uitgevoerd, afhankelijk van...
- Voorwaarden waarmee wordt bepaald onder welke omstandigheden de regel wordt uitgevoerd en uitgevoerd...
- Acties om het incident op een of andere manier te wijzigen of een playbook aan te roepen.
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, waarvan er verschillende typen zijn, zoals wordt uitgelegd in Bedreigingen detecteren met ingebouwde analyseregels 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 | Geïntegreerd platform voor beveiligingsbewerkingen in Microsoft Defender: Microsoft Sentinel is niet ge onboarded naar een geïntegreerd platform: |
| Wanneer incident wordt bijgewerkt | |
| Wanneer een waarschuwing wordt gemaakt |
Automatisering op basis van incidenten of waarschuwingen?
Nu zowel incidentautomatisering als waarschuwingsautomatisering centraal worden afgehandeld door automatiseringsregels en playbooks, hoe moet u kiezen wanneer u deze wilt gebruiken?
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 het geïntegreerde beveiligingsbewerkingsplatform, omdat het maken van incidenten in Microsoft Defender XDR plaatsvindt, 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 met waarschuwingen te gebruiken als u andere externe logica wilt gebruiken om te bepalen of en hoe incidenten worden gemaakt op basis van waarschuwingen, en of en hoe waarschuwingen worden gegroepeerd in incidenten. Voorbeeld:
Een playbook kan worden geactiveerd door een waarschuwing die geen bijgehorend incident heeft, 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 kan worden geactiveerd door een waarschuwing en in plaats van een incident te maken, zoekt u naar een geschikt bestaand incident om de waarschuwing toe te voegen. Meer informatie over incidentuitbreiding.
Een playbook kan worden geactiveerd door een waarschuwing en SOC-personeel op de hoogte stellen van de waarschuwing, zodat het team kan beslissen of er een incident moet worden gemaakt.
Een playbook kan worden geactiveerd door een waarschuwing en de waarschuwing verzenden naar een extern ticketsysteem voor het maken en beheren van incidenten en het maken van een nieuw ticket voor elke waarschuwing.
Notitie
Automatisering die door waarschuwingen wordt geactiveerd, is alleen beschikbaar voor waarschuwingen die zijn gemaakt door geplande, NRT- en Microsoft-beveiligingsanalyseregels.
Automatisering die door waarschuwingen wordt geactiveerd voor waarschuwingen die zijn gemaakt door Microsoft Defender XDR, is niet beschikbaar in het geïntegreerde platform voor beveiligingsbewerkingen. Zie Automation met het geïntegreerde platform voor beveiligingsbewerkingen voor meer informatie.
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:
De waarde van een incidenteigenschap
- 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.
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 het geïntegreerde platform voor beveiligingsbewerkingen:
- 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.
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 wordt na die datum uitgeschakeld. 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 op basis van de status ervan nadat ze zijn uitgevoerd door eerdere automatiseringsregels.
Als 'First Automation Rule' bijvoorbeeld de ernst van een incident heeft gewijzigd van gemiddeld 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 worden weergegeven in een bepaald incident.
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 ingevuld met het nummer na 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 type trigger voor incidentupdates (afhankelijk van hun ordernummers).
- Regels worden altijd opeenvolgend uitgevoerd, nooit parallel.
Notitie
Nadat de onboarding naar het geïntegreerde platform voor beveiligingsbewerkingen is uitgevoerd, wordt er één update naar Microsoft Sentinel verzonden als er binnen vijf tot tien minuten meerdere wijzigingen in hetzelfde incident worden aangebracht, 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 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.
Playbookacties binnen een automatiseringsregel kunnen onder bepaalde omstandigheden anders worden behandeld, volgens de volgende criteria:
| Runtime van playbook | Automatiseringsregel gaat verder met de volgende actie... |
|---|---|
| Minder dan een 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. Elke automatiseringsregel kan dan elk playbook in die resourcegroep uitvoeren.
Wanneer u een automatiseringsregel configureert en een runplaybookactie toevoegt, 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 voor deze resourcegroepen nodig. 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), ziet u de resourcegroepen 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:
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 het geïntegreerde platform voor beveiligingsbewerkingen, afhankelijk van uw specifieke behoeften 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, ziet u dat in het deelvenster Nieuwe automatiseringsregel maken de voorwaarde van de analyseregel niet beschikbaar is, 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.
U ziet dat wanneer u hier een automatiseringsregel maakt, in het deelvenster Nieuwe automatiseringsregel maken alle velden met waarden van het incident zijn ingevuld. 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.
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.
- Automatiseringsregels voor Microsoft Sentinel maken en gebruiken om incidenten te beheren.
- Gebruik automatiseringsregels om lijsten met taken voor analisten te maken.
- Zie Bedreigingsreacties automatiseren met playbooks in Microsoft Sentinel voor meer informatie over geavanceerde automatiseringsopties.
- Zie Zelfstudie: Playbooks gebruiken om reacties op bedreigingen in Microsoft Sentinel te automatiseren voor hulp bij het implementeren van playbooks.