Learn how to use automation tools and techniques to make your security operations awesome right away with Microsoft Sentinel.

Welcome to the fourth entry of our blog series on automating Microsoft Sentinel. My apologies for how long it has taken to get this post completed and published.

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 with an overview of the different types of automation you can do in Sentinel, Part 2: Automation Rules where we talked about automating the mundane away, and Part 3: Playbook Fundamentals where we talked about the basics of Playbooks, Triggers, and Entities.

In this post, we’re continuing our discussion about Playbooks and going to jump in to creating a Playbook from scratch.

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 – Playbooks Part I – Fundamentals
• Part 4: Playbooks 2 – Playbooks Part II – Diving Deeper [You are here]
• Part 5: Azure Functions / Custom Code
• Part 6: Capstone Project (Art of the Possible) – Putting it all together

 

 

Part 4: Playbooks Part II – Diving Deeper

Creating a new Playbook from scratch

In Part 3 of this series, we talked about leveraging the Content Hub in Sentinel to take pre-built playbooks for many different use cases. But what if there isn’t a pre-built Playbook? No problem! We can build our own. We start by going to the Automation blade and selecting “Create”

 

We’re presented with options to create a Playbook with either an incident, alert, or entity trigger or to create a blank workbook. We talked about Triggers in Part 3, and we discussed how these triggers work, and the ways in which you might want to use them. For a quick review:

• Incident Triggers - Fire whenever a new Incident is created.
• Alert Triggers - Fire when the Alert is generated
• Entity Triggers - Each of these options is available as a template for starting a new Playbook

Playbook Basics

When you create a new Playbook, irrespective of which type of Trigger you choose, the basic process is the same: Define where the Playbook will live and give it a name. Then define the identity that the Playbook will execute as. You have two options here:

1.  Run as a managed identity [recommended]
2.  Run as the current user

Running as a managed identity is the recommended route for a couple of reasons including the concepts of least privilege and scope. Another easy way I like to think of it is also what happens when a Playbook that is running as a user and the user leaves the organization? For example, if a Playbook is running as jane@contoso.com and Jane wins the Lottery and retires, then her user account is going to be disabled and removed. All the Playbooks running as Jane are going to start failing because they can’t authenticate as Jane. So, running as a managed identity is more secure, robust, and reliable.

After choosing our identity, we then proceed to the Review and Create tab where we are presented with a summary of our new Playbook. One thing of note is that if we chose a managed identity, there is a note section on screen:

This is because the managed identity doesn’t have the proper permissions to access Sentinel nor necessarily the other things that it might want or need to do. We’re going to cover those permissions in a little bit, but for now just know that we’re going to have to do it. There are some other potential issues around running as a managed identity that we will have to consider as well. For example, what happens if the Playbook is using a service or connector that requires a license? 

 

Now that we have completed all the steps to create our Playbook we simply click Create Playbook and we’re done! Right? Well, sort of. We do have a new Playbook, but it’s still blank and won’t do anything

 

 

The only thing we can see on the designer pane is the Trigger that we chose, and while technically this is a valid Playbook, it’s obviously not very useful. The trigger however is our starting point and has our initial packet of data about the incident, entity, or alert that triggered it. We then use its output in subsequent steps. Let’s add a step and see what that means. If we click the “+” symbol under the trigger, we’re presented with a menu option to either “Add an action” or “Add an agent”. We’re only going to cover Actions in this blog post, and will talk about Agents later.

 

 

Selecting “Add an action” brings up a fly-in menu showing us a plethora of connectors and actions we can take

 

Built-In 1^st and 3^rd Party Connections (ServiceNow, etc.)

The actions are grouped in a couple of different ways to make it easier to find them (at the time of writing this post there are 1575 connectors, with more being added all the time). Not all of these are going to be relevant to your SOC operations, but in my opinion it’s always better to have more options than less. For this post we’re only going to look at the “Built-In Tools” as well as a couple of specific connectors, but I encourage you to explore as you never know what you might be able to make use of.

 

Built-in Tools

Think of this as the DIY toolbox. It has the logical scaffolding and manipulation tools that you will reuse most often and it breaks them into four areas: Control, Date Time, Data Operations, and HTTP. We’re going to look at the HTTP section a little later, but for now just know that it’s there. 
For our discussion today, we’re going to be taking a look at one section and one item, specifically the “Control” section and the “Condition” item.
Control is where flow control statements live. When we select it, we see a number of sub-items that are all about how our Playbooks flow. For example, “Condition” is where you can put an evaluation statement and based on the output of it, take branching logic in your Playbook. Let’s say we want to have different responses for the severity of an incident where if that value is “High” we take one action, if it’s anything else we do something different. When we choose the Condition action, it gets added to the diagram attached to our Trigger event and we’re presented with a Parameters panel to configure the Action.

 

If we click into the field labeled “choose a value” we see two little icons pop up

 

The top one represents data from a preceding step in the Playbook and the bottom one is for entering an Expression (think of it as more logic and code that you can run on data fields). For this example, we’re going to choose the top icon and we’re presented with a pop-up window showing data from our Microsoft Sentinel incident

These represent all of the data fields that are presented as part of the Incident trigger. One thing to note is that the initial pop-up box does not show all of the fields. To show all of them you can click the “See more” button in the upper right corner of the pop-up box. In this case, there are 154 additional fields of data that you can work with. Since we’re making our Control logic based on Severity, we’re simply going to use the Search field to find the Incident Severity field and select that. 

Having done that we’re redirected back to the fly-in panel to finish configuring our Condition only now the Choose a Value field shows a token object representing our Incident Severity and we can start to choose or fill in other fields as well as the evaluator we want to use (contains, not contains, equals, etc.) and then finally the value we want to evaluate against (in this case “High”).

Having configured the parameters of the Action, we could then continue on construction of our Playbook logic by clicking the “+” sign in the True section or the False section and continuing to add our different actions that we want to take. This is the basic workflow that we repeat throughout the Playbook: Choose the action, configure the action. This is true for all actions, even 3^rd party ones. Each Action or connector will need to be configured with an identity or connection information and then be passed data to work with. Creating a Playbook incorporating those services is just a matter of passing them the data you want and processing the results.

HTTP / REST APIs (everything else)

But, what about services or systems that don’t have a pre-built connector or action? So long as they can be communicated with over HTTP / REST, we can still connect to them. One of the built-in Actions is HTTP, which contains options for calling HTTP / REST endpoints as either direct calls (using the HTTP action) or via Webhooks or HTTP + Swagger. As long as there is a way for us to talk to it, a Playbook can work with it.

Conclusion

In this entry, we explored how to create a Playbook from scratch in Microsoft Sentinel, emphasizing the importance of choosing the right trigger and identity and why running Playbooks as managed identities is more secure and reliable than using user accounts. We also discovered how to leverage built-in tools and connectors, and how to integrate with external services using HTTP/REST APIs. These insights equip us to automate security operations more effectively and confidently within Sentinel and sets the stage for the next post where we’ll be talking about custom code and Azure functions. 

Stay tuned for more updates and tips on automating Microsoft Sentinel!