Automating incident response queries is one of the quick wins you can implement in Microsoft Sentinel. This allows you to automate incident enrichment and further investigations. The first blog of the Sentinel Automation Series will explain how you can quickly implement this in your environment. This is done based on automation rules and Playbooks (Logic Apps).

Results

To show the value of automatically enriching incidents two examples are discussed in this section; Device Enrichment and the listing of inbound connections. These enrichment flows can provide analysts with additional details and context about the incident, without the need to go to another portal/tool/tab to find the results.

Both Playbooks mentioned in this section are available on GitHub and can be deployed to your tenant! Link: Sentinel Automation GitHub

The term Playbook and Logic App refer both to the usage of a Logic App. Microsoft likes to name it Playbooks in the Sentinel documentation, for this blog the naming convention will also be applicable (until the name is changed, which never happens with Microsoft products right?).

Device Information

This Playbook collects the DeviceName, OSPlatform, OSVersionInfo, PublicIP, DeviceType, JoinType and ExposureLevel for each device mentioned in the incident entities. This is done based on the data available in the DeviceInfo table. This helps analysts to get efficient insight into the device they are investigating.

KQL Query:

let HostName= "HostNameVariable";
DeviceInfo
| where DeviceName startswith HostName
| summarize arg_max(TimeGenerated, *) by DeviceId
| project DeviceName, OSPlatform, OSVersionInfo, PublicIP, DeviceType, JoinType, ExposureLevel

Inbound Connections

This automation flow collects the last 10 inbound connections to a device that is mentioned in the incident entities. These results are added as comments in the Sentinel incident. In this case, a strange pattern can be identified, since there are multiple inbound RDP connections within a short timeframe from different locations.

KQL Query:

// Add the device you are investigating in the CompromisedDevice variable
let HostName= "HostNameVariable";
let SearchWindow = 10d; //Customizable h = hours, d = days
DeviceNetworkEvents
| where TimeGenerated > ago(SearchWindow)
| where DeviceName startswith HostName
// Only list accepted inbound connections
| where ActionType == "InboundConnectionAccepted"
| where RemoteIPType == "Public"
| extend GeoIPInfo = geo_info_from_ip_address(RemoteIP)
| extend country = tostring(parse_json(GeoIPInfo).country), state = tostring(parse_json(GeoIPInfo).state), city = tostring(parse_json(GeoIPInfo).city), latitude = tostring(parse_json(GeoIPInfo).latitude), longitude = tostring(parse_json(GeoIPInfo).longitude)
| project TimeGenerated, DeviceName, RemoteIP, LocalIP, LocalPort, country, state
| top 10 by TimeGenerated

Overview

There are two triggers to enrich Sentinel incidents; manual and automatic. If a Playbook is executed manually, the analyst investigates the incident and determines that more context/information is needed. This information can now be collected by clicking a button, whereas previously the analyst had to build (or copy) and run the query each time more information was needed.

This process can be further automated with automation rules, these are centrally managed automation flows in Sentinel. One of the actions automation rules can do is to execute a Playbook, this can be the same Playbook as mentioned in the manual steps. With this automatic trigger, the analysts are served with all the information when they open the Sentinel incident.

Playbook

When enriching incidents with KQL queries the Playbook will look similar to the one seen below.

This flow consists of four steps:

1. A Playbook Trigger which starts the Playbook Flow. This can be a Sentinel Incident, Entity or Alert (DOCS).
2. Extracting the Entities, these are needed in the KQL query to filter on the devices, users, files, etc. that are mentioned in the trigger.
3. For each entity run a KQL query, this is done using the Azure Monitor API. You can achieve the same results with the Microsoft Defender API, this allows you to query the data directly from Advanced Hunting.
4. Add the query results as a comment to the Sentinel incident.

For more automation ideas have a look at my presentation slides from the Dutch Security Meetup.

Trigger Playbook

As already briefly discussed in the previous part there are different options to trigger the Playbook execution. For automation, you have one option, to use the Automation Rule as a trigger. The manual locations are shared below. While it makes sense, it is good to mention that you cannot execute a Playbook that has an alert trigger via the manual incident trigger option, only the manual alert trigger option can execute this playbook.

Entities The effectiveness of the Logic App relies on the Entities that are set when configuring Analytics/Custom Detection Rules. The more entities you configure, the more effective automation will be!

Manual Incident Trigger

Manual Alert Trigger

Manual Entity Trigger

Create Automation Rule

Creating an automation rule in Sentinel is very easy.

1. Navigate to the Automation section in the Sentinel menu.
2. Create an Automation Rule. This includes defining which incidents the automation rule should trigger.
3. Select the Playbook you want the automation rule to execute.

Next Blogs

This blog has introduced the Sentinel Automation topic. The next parts of this series will provide more information, examples and templates to further optimize your Sentinel experience.

Questions? Feel free to reach out to me on any of my socials.