Manage a Security Operations Environment · Topic 3 of 8
Sentinel Automation Rules and Playbooks
SC-200 Sentinel automation: automation rules with triggers and actions, Logic App playbooks, managed identities and the roles needed to run them.
- 6 min
- Includes a diagram
- Automation rules have triggers (incident created, incident updated, alert created), conditions and actions, run in order, and can expire.
- Playbooks are Logic Apps with incident, alert or entity triggers, and can run automatically or manually.
- Running a playbook from an automation rule needs the Sentinel service principal to have Microsoft Sentinel Automation Contributor on the playbook's resource group.
What it is
Microsoft Sentinel is also a SOAR, so it can respond automatically. There are two building blocks. Automation rules are simple, fast rules that run when an incident or alert is created or changed, and they handle routine tasks such as tagging, assigning and closing. Playbooks are workflows built on Azure Logic Apps for anything more involved, such as blocking a user, posting to a chat channel or enriching an alert with threat intelligence.
How it works
Automation rules
An automation rule has three parts.
| Part | Examples |
|---|---|
| Trigger | When an incident is created, when an incident is updated, or when an alert is created |
| Conditions | The analytics rule name, severity, status, tactics, an entity such as an account or IP address, a tag, or a custom detail |
| Actions | Change the status or severity, assign an owner, add a tag, add a task, or run a playbook |
Rules run in an order that you set, and one rule's actions can feed the next. You can also give a rule an expiration date, for example to suppress incidents during a maintenance window. Typical uses are:
- Close known benign incidents automatically with a classification.
- Assign incidents of a given type to a team.
- Add a standard set of incident tasks for the analyst to follow.
- Tag incidents from a particular rule.
- Run a playbook when a high severity incident is created.
Because automation rules run directly inside Sentinel, they are quick and need no extra cost. They can run one or more playbooks as an action, which is how a rule triggers a playbook for an incident.
Playbooks
A playbook is a collection of steps built as a Logic App, using a Microsoft Sentinel trigger. There are three trigger types.
| Playbook trigger | Runs on |
|---|---|
| Incident trigger | An incident, so the playbook receives the whole incident and its entities |
| Alert trigger | A single alert |
| Entity trigger | An entity such as an account or IP address, run manually from the incident or hunt |
Inside the Logic App, you add actions with connectors. Common actions are posting a message to a team channel, sending an email, creating a ticket, adding a comment to the incident, looking up an IP address in a threat intelligence service, and calling Microsoft Graph or Defender APIs to block a user or isolate a device. If an analyst needs to see the result, a playbook can add a comment to the incident, which places the verdict on the incident page.
Playbooks can run in two ways: automatically, from an automation rule, or manually, started by an analyst for a chosen incident, alert or entity.
Permissions
Playbooks and rules need the right permissions, or they fail.
| Need | What to assign |
|---|---|
| Run a playbook from an automation rule | The Microsoft Sentinel service principal needs the Microsoft Sentinel Automation Contributor role on the resource group that holds the playbook |
| Let an analyst run a playbook manually | The Microsoft Sentinel Playbook Operator role |
| Create or edit automation rules | Microsoft Sentinel Contributor |
| Let the Logic App act on Microsoft Graph or Azure | A managed identity for the Logic App with the right permission |
| Edit the playbook | Logic App Contributor on that resource |
The managed identity of a Logic App is a common source of errors. If a playbook calls Microsoft Graph to revoke a user's sessions with the identity of the Logic App and returns 403 even though the identity is Owner on the resource group, the fix is not an Azure role. Microsoft Graph uses application permissions, so the managed identity needs the right Graph application permission, such as User.RevokeSessions.All, with admin consent.
Where automation runs
In the unified Defender portal, Sentinel automation rules and playbooks are managed together with Defender XDR. Defender XDR has its own automated investigation, and Sentinel automation rules apply to the incidents that come to Sentinel. Playbooks that act on Microsoft Defender XDR incidents can use the Defender XDR connector.
Design tips
- Keep each playbook small and focused, and call one from another when you need reuse.
- Use automation rules for simple tasks and playbooks only when you need connectors.
- Test with a sample incident before enabling on all incidents.
- Always add a comment or tag, so analysts can see that automation acted.
- Avoid loops, such as a rule that updates an incident and then triggers itself again.
Choosing the tool
| The need | Tool |
|---|---|
| Assign every incident from one analytics rule to the network team | An automation rule |
| Close known false positives automatically | An automation rule with a close action |
| Look up an IP in VirusTotal and add the result to the incident | A playbook that adds a comment |
| Disable a user in Entra ID when an incident is created | A playbook called by an automation rule |
| An analyst wants to run a response on one suspicious account | A playbook with an entity trigger, run manually |
A worked scenario
A SOC receives many incidents from a rule that detects sign ins from unfamiliar locations. An automation rule triggers when an incident is created from that rule, tags it, assigns it to the identity team and adds a task list. A second rule runs a playbook for high severity incidents. The playbook checks the IP address in a threat intelligence service, adds the verdict as a comment, and posts a message to the team's chat channel. It first failed because the Sentinel service principal lacked the Automation Contributor role on the resource group with the playbook, which was then granted.
What to remember for the exam
- Automation rules have triggers (incident created, incident updated, alert created), conditions and actions, run in order, and can expire.
- Playbooks are Logic Apps with incident, alert or entity triggers, and can run automatically or manually.
- Running a playbook from an automation rule needs the Sentinel service principal to have Microsoft Sentinel Automation Contributor on the playbook's resource group.
- Playbook Operator lets an analyst run playbooks manually.
- Graph calls from a Logic App managed identity need Graph application permissions.
Use an automation rule for simple, fast tasks and a playbook when you need connectors to other systems.
How the exam asks about this
- "Which action records a playbook's verdict on the incident page?" Add a comment to the incident.
- "A playbook calling Graph returns 403 although the identity is Owner." Grant the managed identity the Graph application permission and consent to it.
- "Which role lets the automation rule run a playbook?" Microsoft Sentinel Automation Contributor, for the Sentinel service principal.
- "Run a response on a single suspicious account." A playbook with an entity trigger.
Common mistakes
Using Azure roles for Graph permissions. Graph needs application permissions.
Forgetting the Automation Contributor role. The rule cannot run the playbook without it.
Building a playbook for a simple tag or assignment. An automation rule is enough.
Not testing. A faulty rule can close real incidents.
Check yourself
What three parts does an automation rule have?
A trigger, conditions and actions.
Which role must the Microsoft Sentinel service principal hold to run playbooks from automation rules?
Microsoft Sentinel Automation Contributor on the resource group of the playbooks.
What are the three playbook trigger types?
Incident, alert and entity.
Topic 3 of 8 in Manage a Security Operations Environment
Test yourself on Manage a Security Operations Environment
The full Microsoft SC-200 question bank has 650 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Microsoft. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.