Squeeze More Data Out of Your Analytic Rules
Enrich investigations with the new Alert Enrichment.
The Microsoft Sentinel team has just recently come out with “Alert Enrichment” which is a replacement for the old “Extend” system. This is good news for analysts because they can now customize the nodes in their Microsoft Sentinel investigation graphs without having to write KQL statements that sometimes did not work predictibly.
The list of supported entities that can be displayed in the investigation graph has jumped from 5 to 18 as of the latest count, which allows for theoretically up to 18 nodes in the investigation graph. All the supported entities in Microsoft Sentinel are represented aside from “Domain” and “IoT Device” which will likely be added later.
In this blog, we show how an analyst can use the new Alert Enrichment system in Microsoft Sentinel analytic rules to maximize the amount of useful data that they can put into their analytic rules.
Picture How Analysts Would Use the Data
It is the job of the analytic rule writer to create an investigation experience for analysts that allows them to finish their investigations as quickly and effectively as possible. By picturing how an analyst would go through an investigation, an analytic rule writer can create an analytic rule that would be the most useful to the analyst.
The analyst writing the analytic rule in this scenario started off by going through the CyberMSI Incident Management Process and using the parts of that process to decide how they would potentially use the Alert Enrichments.
Alert Enrichment Uses Table Data
When the analyst was creating the query for their analytic rule, they determined that they would be using the “SecurityEvent” table to look for data. The analyst kept a tab open with the table displaying all the columns. This way the analyst can go through the column names to see if they can be mapped to entities recognized by Microsoft Sentinel.
Mapping “Who” Information
When investigating who is involved with an incident, some important details about the user would be their account name and any information they can find about that account.
The “Account” column can be mapped to the “Account” entity to get account information. The “HomeDirectory” column can also be mapped to the “Security Group” entity since a domain can be used as a rough equivalent to a security group in the context of the query.
Mapping “Where” Information
When investigating where an incident happened, some important details include which device the incident happened on and where that device was on the network at the time of the incident.
The “Computer” column can be mapped to the “Host” entity to get information about the device. The “IpAddress” column can be mapped to the “IP” entity to get more information about where the device was on the network at the time of the incident.
Mapping “What Happened” Information
When investigating what happened during an incident, it is up to the judgment of the analytic rule writer to decide which of the many columns is the most relevant to what happened during an incident.
In this scenario the analyst used one of the new features that Alert Enrichment has, which is loading multiple columns into the same mapped entity. They mapped “EventId”, “Activity”, and “EventData” to the “Processes” entity so that analysts could get the most possible data about what was happening during the incident.
Creativity is Rewarded
Keen observers would notice that in the last example image “ElevatedToken” was used as the name paired with “EventData”. That pairing makes no sense, but it is necessary if the analytic rule writer is going to fit all the vital information into the investigation graph node.
After doing a sizable amount of testing with Alert Enrichment, analysts at CyberMSI have determined that it has the same lack of input checking that its predecessor had. This means that creative analysts can express whatever kind of information that they want from the table with mapped entities because Microsoft Sentinel does not have very strict checks on the data output.
We will continue to share best practices and lessons learned in future posts on using Microsoft Sentinel analytic rules in customer environments. The Microsoft Sentinel team is constantly adding new features like Alert Enrichment and we plan to stay on top of upcoming changes.
In closing, consider these three questions when using Microsoft Sentinel analytic rules in your organization:
- How can we use analytic rules to facilitate quicker resolution of cybersecurity incidents in the cloud?
- Which new entity mappings should we add to our existing analytic rules to make our investigations more effective?
- When should we bypass input validation rules built in Microsoft Sentinel so that we can get more information out of our analytic rules if needed?