Correlating Microsoft Defender for Cloud alerts in Sentinel

Your cyber security team is faced with numerous alerts every single day. Alert grouping techniques aim to bring together alerts that are similar in nature or require similar steps in order to be solved.
We will take the MDC (Microsoft Defender for Cloud) as an example.
Defender for Cloud generates alerts for resources deployed on your Azure, on-premises, and hybrid cloud environments.
In order to get these alerts into the environment you are required to enable the MDC data connector.

Connect MDC:
Go into the Data connectors section in Microsoft Sentinel and select ‘Microsoft Defender for Cloud.’

This will open the connector page for MDC in which you can select which subscriptions you would like to connect into your Microsoft Sentinel workspace.

 Up until now, in order to create incidents from MDC alerts, you would have enabled an incident creation rule that creates an incident from each alert received from MDC.

This rule can also be found in a template that looks like this:

 

This incident creation rule provides only basic filtering abilities and no grouping configuration.
Usually this isn’t a problem since these alerts are quite reliable but, in our example, we would like to get maximal control over our incident queue.

 

Scheduled alert rules to the rescue:
We will leverage the capabilities of multiple scheduled alert rules to achieve the desired outcome:
Group alerts with similar entities into one incident

 

Create schedule analytics rule:
Select "Analytics” in Microsoft Sentinel to open the Analytics section.

Here we will create a new scheduled query analytics rule.

General configuration:
In the General tab of the configuration we will set some properties of the rule itself.

Note that we would not want these configurations to be applied to the alerts. We would like to maintain the name, description, tactics, and severity of the original alerts but we will get to that in a minute.

 

Rule logic:
In the rule logic we will start by defining the query.
The query will analyze the Security Alert table, where we will find our MDC alerts.
Since we are using KQL, we can define any KQL filtering we would like.
In our example we would like to analyze alerts with the product name ‘Azure Security Center’ (MDC) and to filter out all alerts that contain our testing IP address (1.2.3.4).

The next step would until recently have been parsing the entities from the MDC alerts.
Those of you who have tried this before know very well how difficult that task can be but don’t worry, we’ve got you covered.

The new, recently published entity mapping feature is what we will use to solve this problem.

This mapping allows us to parse the entities found on the alert automatically if the selected column is in Sentinel entities format.

The next thing we would like to do is preserve the data from the original alert.
By default, the rule details will populate the alert (and incident) properties. By using the alert details, we will fetch the original data from the Microsoft Defender for Cloud alerts.

 

We will define the new alert name using the one found on the alert. he same will apply to the description, tactics, and severity.

I added a small prefix to the name to make it noticeable that these incidents (and alerts) were created from the MDC rule.
Saving the rule as is will create a problem, since now all alerts received from MDC over the rule’s lookback period will just be grouped into a new alert.
In order to solve that we will use the event grouping configuration.

This configuration will create an alert for each result of our query, in our case for each MDC alert we will have a new alert and incident.
Now the only missing part left is the grouping which is very straightforward:

Selecting the ‘Grouping alerts into a single incident if all the entities match (recommended)’ option means that each MDC alert that has all the entities matching will be grouped together.
After saving the rule we can see the incidents that were created by this rule.

The incident has a number of alerts grouped together since they have the same entity so instead of getting 135 incidents.

We got only 23 incidents around 83% decrease in incident load.

Summary
In this blog we have seen how by using this additional entity mapping technique we gained the ability to control the load in your SOC.
I would recommend reading an additional blog post demonstrating another example on how to better protect your organization and maintain a healthy SOC.