In this blog post we will explore the new “Alert enrichment” in Azure Sentinel Analytics and do a deep dive into the “Alert details” dynamic content ability.
The “Alert enrichment” abilities are constructed of 3 parts:
1. Entity mapping: Entity mapping is an integral part of the scheduled query analytics rules configuration. It enriches the rules’ output (alerts and incidents) with essential information that serves as the building blocks for any investigation processes and remediation actions that would follow.
2. Custom details: Using the custom details feature in the analytics rule wizard, you can surface event data in the alerts that are constructed from those events, making the event data part of the alert properties. In effect, this gives you immediate event content visibility in your incidents, enabling you to triage, investigate, draw conclusions, and respond with much greater speed and efficiency.
Accessing custom details:
i. Alert: you can access the custom details from the alert by reviewing the extended properties.
ii. Incident: on the incident timeline you can see all the alerts related to this incident. Each alert has its own custom details which are visible when we open the alert in the entity timeline view.
3. Alert details: With the alert details feature, you can customize the alert’s appearance and content. Here you can select parameters in your alert that can be represented in the name or description of each instance of the alert, or that can contain the tactics and severity assigned to that instance of the alert. If the selected parameter has no value (or an invalid value in the case of tactics and severity), the alert details will revert to the defaults specified in the first page of the wizard.
As you can probably tell for yourself, we are going to take a deep dive into the “Alert details” dynamic content.
Why “Alert details” dynamic content?
Generally, the purpose of “alert enrichment” is to allow customization of the Alert created from the detection.
The main goal is to reduce the time it takes to the analyst to triage and handle the incident. The same applies for “Alert details” dynamic content.
In Azure Sentinel when you create a detection (an analytics rule), the rule name (and the description, MITRE tactics and severity) will populate the alerts created from that rule.
Now let’s try and examine the following case study to see how we can leverage the “Alert details” dynamic content for better investigation and incident handling.
Case study – “Multiple Teams deleted by a single user”.
Let’s take a look at the following detection.
This is a out-of-the-box content provided by Azure Sentinel.
In this detection we are trying to spot a single user who deleted multiple groups within an hour.
As you can see the severity of such a detection is set to “low” which makes sense as this action by itself is not highly important.
Now assuming that the user who performed these actions is an Admin in the organization, we might want to raise the severity since this might indicate that the account has been compromised.
What are we going to do?
We’ll create a watchlist in which we will store all these high-profile/risk accounts.
This list will be accessed later on by the rule.
Note: we can also use the watchlist templates, each built-in watchlist template has its own set of data listed in the CSV file attached to the template.
Now we can create our rule from the template:
When creating the rule, we are going to customizing the query in order to create incidents with different values according to the user who performed the action.
What we are used to do with multiple rules we are going to do with just one.
Each event will have a column called “Severity”, which will be set according to the user who performed the action.
Now we can make the magic happen!
By using “Alert details” dynamic content, we can set the alert severity (and the corresponding incident) to dynamically change according to the value of the column.
This means when a user from the watchlist will delete 3 or more groups a high severity alert and incident will be created.
But we want more!
After having these 2 types of incidents created from this rule, we can improve the incidents even more.
The first thing that an analyst will do with a high-severity incident received from this rule is to ask himself – “Which user from the list performed this action?”
To get a quick answer we can take 2 approaches:
#1 – the custom details approach:
Using the custom details feature in the Analytics Rule wizard, you can surface event data in the alerts that are constructed from those events, making the event data part of the alert properties. In effect, this gives you immediate event content visibility in your incidents, enabling you to triage, investigate, draw conclusions, and respond faster and more efficient.
The only downside to this approach is that an analyst must enter the incident to understand which user performed this action.
#2 – dynamic name approach:
In the Alert Name Format field, enter the text you want to appear as the name of the alert (the alert text), and include, in double curly brackets, any parameters you want to be part of the alert text.
This setting means that the display name of the alert (and incident) will change according to the user who caused this alert trigger.
An analyst reviewing the incident could instantly tell which user is involved and eventually improve the MTTR.
We also changed the description to be dynamically set according to the actual content of events.
As you can see the alert enrichment really opens a variety of new abilities:
• Changing the severity according to the number of results (or based on historical data)
• Leverage the HTML & markdown support on the incident to create richer and more accurate description for the incident
• Change the title according to the user who performed the action
And much more!
The goal here is to immediately improve your detections, reduce the number of rules, and result in shorter MTTR.