Dipping your toes in Microsoft Sentinel Automation

Microsoft Sentinel is both a SIEM and SOAR product. SIEM (Security Information and Event Management) covers log ingestion and analysis, while SOAR (Security Orchestration, Automation, and Response) focuses on automation and the response to those incidents. Automation is a big part of Sentinel, as it helps security administrators fight the spew of alerts generated by the different security solutions. Previous articles cover Microsoft Sentinel in detail and how you can benefit from Sentinel functionality. In this article, we dive into some common use cases for automation and how to utilize Playbooks within Microsoft Sentinel.

Automation Use Cases

I divide automation use cases into three categories:

1. Notifications
2. Enrichment
3. Automated actions

Notifications are the simplest use case and are used across many organizations. A SOC analyst does not want to continuously refresh the Sentinel UI to know when new information about incidents is available. To solve the problem, you create a notification when an incident is created or updated. A notification can come in different forms and depends on the current business flow of an organization. The simplest form of notification is through Teams or email. You can also set up text-based notifications or even have a fully bi-directional synchronization with your ITSM tool.

Enrichment removes some of the manual processing a SOC analyst must do for every incident. Certain steps need to be executed like:

• Assessing the reputation of the IP.
• History of the user.
  • Has the user been involved in previous security incidents?
• Information about the device.
  • Is this a server or an endpoint? Are there any open vulnerabilities?

By automating the enrichment aspect of the incident, a SOC analyst can quickly grasp the context and focus on the task at hand.

The last scenario is Automated actions. These actions range from closing an incident to resetting a user’s password. Automated actions are the last thing to focus on, as they can impact your environment most when something goes wrong.

Automating Microsoft Sentinel

Azure Logic Apps are the foundation for Sentinel automation. Logic Apps are a low-code solution running on Azure that allows a Security engineer without deep development knowledge to create automation. Azure Logic Apps can be compared with Power Automate, as the UI and features are almost identical. While Power Automate Flows are built by an end-user and licensed through a Microsoft 365 license, Logic Apps are saved on the Azure platform and are billed by their consumption. Logic Apps are called ‘Playbooks’ when used within the context of Sentinel. By default, Playbooks are triggered manually.

Besides Playbooks, Automation Rules play a significant role in automation. Automation rules have a couple of distinct functions:

• They allow administrators to trigger Playbooks automatically based on a set of predefined conditions.
• They can update incidents (the assignment, status, and severity) using a set of conditions.

Automation Rules

Automation Rules are the glue and orchestrator for Sentinel automation. Automation Rules can be created using the Sentinel GUI and don’t require much knowledge before using them. Within an automation rule, you can define the actions to run based on a set of conditions.

Within our SOC, we use Automation Rules extensively to suppress certain known false positives. Figure 1 is an example of an automation rule if my user account accesses a highly privileged password from a known IP range. Some users/devices are bound to trigger certain security controls which will generate incidents in the SIEM. This could be because of scripts or service accounts running scheduled actions, which triggers a security rule regularly. Automation Rules can quickly close these incidents, meaning your SOC doesn’t need to spend much effort on them.

While Automation Rules are straightforward, consider using a naming convention and order for these rules. Each automation rule has a specific order, and Sentinel executes the rule with the lowest order first. This means you need to consider the order in which your automation rules occur to ensure they don’t conflict with each other. By having a naming convention, we can tell which automation rule is responsible for which action. At my company, we have about 30 different automation rules.

Building Playbooks

While Automation Rules provide the ability to run basic actions on incidents, more complex actions require Playbooks. Getting started with playbooks can be difficult as there are so many options to choose from. To help you with this issue, here are some tips:

• Use the community
  • Many prebuilt Playbooks are available. While a Playbook gallery is built into Microsoft Sentinel with a ton of sample Playbooks, I recommend checking out the Sentinel GitHub repository as well. It contains playbooks created by both Microsoft and the community.  These two sources inspire you to create your own use cases.
• Choosing the correct trigger
  • A trigger in a Logic App defines when it will run. There are currently three different triggers supported by Sentinel:
    • Entity-based: These triggers only support manual action, meaning they are always triggered by a SOC analyst manually running the Playbook. It will enable you to scope your automation to a single IP, device, or account. This is a big difference compared to alerts and incidents, as they can contain multiple IPs and devices.Alert-based: Alert-based Playbooks run every time an alert is created in Microsoft Sentinel, independent of an incident being created. They are my preferred method to add enrichment as it is able to add information to an alert without needing an incident.  Based on the alert and enrichment, you can then decide through KQL whether you want to create an incident or not.
    • Incident-based: These are great for notifications and automated actions. They will run each time Sentinel creates or updates an incident.
• Documentation
  • Documentation is as vital in a low-code environment as it is for regular coding. If you build big Playbooks, they can become complicated fast. Within a Playbook, you can add a comment for each step to explain what the step does and the expected outcome.

The Bigger Picture

Every Playbook should have a predefined use case. This is important to keep the Playbook within the automation architecture. If you are not careful, you will end up with dozens of Playbooks and no clear overview of how they are connected. While it’s often said you don’t need to be a developer to create Logic Apps, keeping the bigger picture in mind is essential. Your organization needs a general architecture on how Playbooks are connected, how to avoid code reuse, and failures. This means you should be careful if multiple people create separate Playbooks, and ensure that someone is responsible for the maintenance and upgrade of the playbooks.

Manual Playbooks

I have heard customers saying they want to automate everything and don’t see a need for manual execution. Nevertheless, there is an extensive use case for manual playbooks. These playbooks have some advantages:

• Permissions
  • Some permissions cannot be set granularly within the Microsoft 365 ecosystem. Let’s take the example of updating a named location called ‘Blocked IPs.’ You would want your SOC analysts to add new IPs, but you might not want them to have access to Conditional Access or other named locations. If you are in this scenario, you have two choices: not assigning the role at all or having an overprivileged user (using the Conditional Access Administrator). Having a Playbook allows you to scope the action so they are only able to update one specific named location. This way, the user does not need any additional (overprivileged) administrator role, and they can just run the Playbook.
• Predefined flow
  • Some actions require a predefined flow when they run. The most common example is when several people must be informed when a device is isolated. The set might include the helpdesk, the users’ manager, and the user themself. By configuring these notifications in a Playbook, you can ensure the correct stakeholders are informed without depending on a manual email from a SOC analyst.

Start Developing Playbooks

A pretty good Microsoft Learning path is available for Playbooks. The biggest tip I can provide you with is to start playing around with different types of Playbooks. Get a trial tenant going and deploy some Playbooks from the gallery. See how they are built and what kind of actions they perform. After that, you can start tweaking the built-in ones (which you can find through the gallery or on GitHub) to your needs. There is no reason to start from scratch when there are so many great resources available.