Welcome to the third entry of our blog series on automating Microsoft Sentinel.

In this series, we’re showing you how to automate various aspects of Microsoft Sentinel, from simple automation of Sentinel Alerts and Incidents to more complicated response scenarios with multiple moving parts.  So far, we’ve covered Part 1: Introduction to Automating Microsoft Sentinel where we talked about why you would want to automate as well as an overview of the different types of automation you can do in Sentinel and Part 2: Automation Rules where we talked about automating the mundane away.

In this post, we’re going to start talking about Playbooks which can be used for automating just about anything.

Here is a preview of what you can expect in the upcoming posts [we’ll be updating this post with links to new posts as they happen]:

• Part 1: Introduction to Automating Microsoft Sentinel


• Part 2: Automation Rules – Automate the mundane away


• Part 3: Playbooks 1 Part I – Fundamentals [You are here]


• Part 4: Playbooks 2 Part II – Diving Deeper


• Part 5: Azure Functions / Custom Code


• Part 6: Capstone Project (Art of the Possible) – Putting it all together

Part 3: Playbooks – Fundamentals

Pre-Built Playbooks in Content Hub

Before we dive any deeper into Playbooks, I want to first point out that there are many pre-built playbooks available in the Content Hub. As of this writing, there are 484 playbooks available from 195 providers covering all manner of use cases like threat intelligence ingestion, incident response, operations integrations, and more in both first party Microsoft and third-party security tools.  Before we dive into the internals of Playbooks and start creating our own, you really should do yourself a favor and take a look at the Content Hub and see if there isn’t already a Playbook doing what you want.  You can also review the list of solutions at the Microsoft Sentinel GitHub page at Azure-Sentinel/Solutions at master · Azure/Azure-Sentinel

Basic Structure of a Playbook

Microsoft Sentinel Playbooks are built on Azure Logic Apps which is a low to no-code workflow automation platform.  We’ll be diving into the details of how to create a Logic App from start to finish in the next installment of this series, but for now just know that there are two key “custom” features that Sentinel exposes for use in Playbooks: Triggers and Entities.

Triggers

The events or actions that can start a Playbook running are Triggers.  These can be Incident, Alert, or Entity based.

Incident Triggers

Incident triggers are when an incident is either created or updated in Sentinel. Incident triggers can be tied to Automation Rules (which were covered in part 2 of this series) and can also be manually triggered by an analyst. Playbooks launched with Incident triggers receive all the incident objects, including any entities it contains as well as the alerts it is comprised of.

Alert Triggers

Alert triggers are similar to Incident triggers; except they trigger when an Alert is fired due to an Analytic Rule having a result.  This is especially useful when you have an Alert that is not configured to create an Incident.  Alert triggers can also be tied to Automation Rules

Entity Triggers

Entity triggers are different from Incident and Alert triggers as they cannot be tied to Automation Rules.  Instead, they are triggered manually by an analyst.  For example, let’s say that there is a user account that is part of an Incident and during the investigation the analyst decided they wanted to disable that user account in Entra.  They could use an Entity Trigger to launch the Playbook, passing the Account Entity to the playbook for the account to be disabled.

Entities

We can’t really talk about Entity Triggers without talking about Entities themselves.  So, what is an Entity in Sentinel?  Entities are data elements that identify components in an alert or incident.  There are many different types of entities within Sentinel, but for Playbooks we only need to focus on five key ones:

• IP


• Host


• Account


• URL


• FileHash

(for more information on Entities in general, please see: https://learn.microsoft.com/azure/sentinel/entities )

How do you use Entity Triggers?

When you are building an Analytic rule, you can identify the different Entities that it contains.  These are then carried along as part of the Alert and exposed for further actions.  This means that all you need to do is map the results of the Analytic Rule to the different Entity types using values returned from your query.  For example, let’s say we are creating an Analytic Rule to alert on a new CloudShell user being created in Azure with the following query:

let match_window = 3m;

AzureActivity

| where ResourceGroup has “cloud-shell”

| where (OperationNameValue =~ “Microsoft.Storage/storageAccounts/listKeys/action”)

| where ActivityStatusValue =~ “Success”

| extend TimeKey = bin(TimeGenerated, match_window), AzureIP = CallerIpAddress

| join kind = inner

(AzureActivity

| where ResourceGroup has “cloud-shell”

| where (OperationNameValue =~ “Microsoft.Storage/storageAccounts/write”)

| extend TimeKey = bin(TimeGenerated, match_window), UserIP = CallerIpAddress

) on Caller, TimeKey

| summarize count() by TimeKey, Caller, ResourceGroup, SubscriptionId, TenantId, AzureIP, UserIP, HTTPRequest, Type, Properties, CategoryValue, OperationList = strcat(OperationNameValue, ‘ , ‘, OperationNameValue1)

| extend Name = tostring(split(Caller,’@’,0)[0]), UPNSuffix = tostring(split(Caller,’@’,1)[0])

When we use this query as the basis for an Alert, we can then use Entity Mapping under Alert Enhancement to take the relevant fields returned and map them to Entity objects:

This example maps the values “Caller”, “Name”, and “UPNSuffix” returned by the query to the “FullName”, “Name”, and “UPNSuffix” fields of an Account Entity. It also maps the UserIP result to the “Address” field of an IP Entity. When the Alert fires, it will include a collection of Account and IP Entities with the necessary values in its Entities field.  Now if we wanted to, we could use a Playbook based on Entity Triggers to act on the Account or IP entities.

What is a “strong” identifier versus a “weak” identifier and why is it important?

Entities have fields that identify individual instances. Strong identifiers uniquely identify an entity, while weak identifiers may not. Often, combining weak identifiers can create a strong identifier.

For example, Account entities can be identified by a strong identifier like a Microsoft Entra ID (GUID) or User Principal Name (UPN). Alternatively, a combination of weak identifiers like Name and NTDomain can be used. Different data sources might identify the same user differently. When Microsoft Sentinel recognizes two entities as the same based on their identifiers, it merges them into one for consistent handling.

We’ll be covering more details on using Entities and Triggers in the next article when we start building Playbooks from scratch.

Conclusion

In this article we talked about the fundamentals of Playbooks in Sentinel , the Content Hub which is the home of pre-built Playbooks, as well as the different types of Triggers that can be used to launch a Playbook.  In the next article we’ll be covering how to build a playbook from scratch and put these concepts to work.

Additional Resources

• Supported triggers and actions in Microsoft Sentinel playbooks


• Entities in Microsoft Sentinel