Use a Microsoft Sentinel playbook to stop potentially compromised users

This article describes a sample scenario of how you can use a playbook and automation rule to automate incident response and remediate security threats. Automation rules help you triage incidents in Microsoft Sentinel, and are also used to run playbooks in response to incidents or alerts. For more information, see Automation in Microsoft Sentinel: Security orchestration, automation, and response (SOAR).

The sample scenario described in this article describes how to use an automation rule and playbook to stop a potentially compromised user when an incident is created.

Prerequisites

The following roles are required to use Azure Logic Apps to create and run playbooks in Microsoft Sentinel.

The Active playbooks tab on the Automation page displays all active playbooks available across any selected subscriptions. By default, a playbook can be used only within the subscription to which it belongs, unless you specifically grant Microsoft Sentinel permissions to the playbook's resource group.

Extra permissions required to run playbooks on incidents

Microsoft Sentinel uses a service account to run playbooks on incidents, to add security and enable the automation rules API to support CI/CD use cases. This service account is used for incident-triggered playbooks, or when you run a playbook manually on a specific incident.

In addition to your own roles and permissions, this Microsoft Sentinel service account must have its own set of permissions on the resource group where the playbook resides, in the form of the Microsoft Sentinel Automation Contributor role. Once Microsoft Sentinel has this role, it can run any playbook in the relevant resource group, manually or from an automation rule.

To grant Microsoft Sentinel with the required permissions, you must have an Owner or User access administrator role. To run the playbooks, you'll also need the Logic App Contributor role on the resource group that contains the playbooks you want to run.

Stop potentially compromised users

SOC teams want to make sure that potentially compromised users can't move around their network and steal information. We recommend that you create an automated, multifaceted response to incidents generated by rules that detect compromised users to handle such scenarios.

Configure your automation rule and playbook to use the following flow:

1. An incident is created for a potentially compromised user and an automation rule is triggered to call your playbook.

2. The playbook opens a ticket in your IT ticketing system, such as ServiceNow.

3. The playbook also sends a message to your security operations channel in Microsoft Teams or Slack to make sure your security analysts are aware of the incident.

4. The playbook also sends all the information in the incident in an email message to your senior network admin and security admin. The email message includes Block and Ignore user option buttons.

5. The playbook waits until a response is received from the admins, then continues with its next steps.

   • If the admins choose Block, the playbook sends a command to Microsoft Entra ID to disable the user, and one to the firewall to block the IP address.

   • If the admins choose Ignore, the playbook closes the incident in Microsoft Sentinel, and the ticket in ServiceNow.

The following screenshot shows the actions and conditions you would add in creating this sample playbook:

Related content

• Automate threat response with playbooks in Microsoft Sentinel
• Create and manage Microsoft Sentinel playbooks
• Use a Microsoft Sentinel playbook to stop potentially compromised users