Microsoft has announced a new Sentinel feature: Summary Rules. Those rules are aimed at aggregating large sets of data in the background for a smoother security operations experience across all log tiers (Documentation). This blog describes multiple use cases to get started with this new feature.

I just want to have the queries! GitHub Sentinel Summary Rules.

Use Cases

You might question the use cases related to summary rules. First, it is good to know that summary rules are closely related to the summarize operator. This opertator is used to gather statistics and aggregate results and push those results to a custom table. One can now query this custom table, without the need to execute resource intensive queries.

Knowing this use cases for summary rules are:

• Reporting on larger datasets.
• Query data that is stored in Analytics, Auxiliary or Basic logs.
• Summarize suspicious activities for detections.

In this blog three example use cases are shared:

• AzureHound Detection
• Discovery log activities
• Entra ID Role and Group Reporting

Microsoft has also shared multiple Summary Rule scenarios including the KQL queries to replicate them, these are available in the Summary Rule Documentation.

Create Summary Rule

The summary rules can be created from the Sentinel Configuration section, from there select Summary rules (Preview). From here you can add another rule, give it a name and a description. You can forward the result to a new table or select an existing table you want to forward the results to. In the case below a new table Actions_CL is created.

The next step is to select input a summary query and set the schedule. In this case, the aim is to retrieve all unique events and how often they appeared on the last day.

let StartDate = startofday(ago(1d));
let EndDate = startofday(now());
union * 
| where TimeGenerated between (StartDate .. EndDate)
| extend Action = coalesce(Operation, OperationName, OperationNameValue, ActionType) 
| where isnotempty(Action) 
| summarize TotalEvents = count() by Type, Action
| extend RetrievalDate = StartDate
| sort by Type

The configuration of Summary Rules is important, this decides how often your rule puts data in the new table. The more often you run the rule, the more data is written thus the higher the cost are. In this case, I only run it once every 24 hours. The delay is important, most of the ingested data to Sentinel has a delay of several (in some cases a lot more) minutes. The rule performs a lookup from yesterday, so the delay is set to 60 minutes to include as many logs as possible. Lastly, the rules can be scheduled at a specific timeframe. This is especially important if you summarize in combination with bin() operators.

Diagnostics

It is recommended to enable the diagnostic settings for the summary rules, since they deal with bigger datasets they may return failures.

If the data is forwarded to a Log Analytics Workspace the data can be queried with KQL. The query below can be used to list all failures related to Summary Logs.

AzureActivity
| where OperationNameValue startswith @"MICROSOFT.OPERATIONALINSIGHTS/WORKSPACES/SUMMARYLOGS"
| where ActivityStatusValue != "Success"

When you delete a summary rule the custom table is not removed. The custom table can be deleted by going to the log analytics workspace in which the table was created and deleting it from there.

AzureHound

In a previous blog, the value of the Microsoft Graph Logs is explained - Investigating Microsoft Graph Activity Logs. The MicrosoftGraphActivityLogs can detect AzureHound and other cloud reconnaissance tools (KQL Query for Detection), but is expensive to ingest. Because of the amount of ingested data summary rules are well tailored for detection purposes. Instead of an Analytics Rule that runs every hour and summarizes all MicrosoftGraphActivityLogs in search of AzureHound patterns, one can now run an analytics rule and alert based on new entries in the custom log table.

Once an AzureHound pattern is found the result is forwarded to the AzureHound_CL table. The last step is to create a Sentinel Incident based on this an NRT detection that triggers when new entries in the table arrive is sufficient to get the security team in motion.

Once AzureHound is executed the data flows into the custom table created by the summary rule, as configured in this case AzureHound_CL. In this table, only the results of the summary rule are saved, with the ingested data a Sentinel Incident is triggered for the security team to investigate.

Unique Actions

In the section Create Summary Rule the KQL query for the Unique Actions (Operation, OperationName, OperationNameValue or ActionType) use case is already shared. This summary rule runs once a day and saves all unique actions and how often they appear in your environment to the Actions_CL table.

This allows for easy retrieval of statistics on how many unique actions are found in the environment each day.

Actions_CL
| summarize UniqueEvents = dcount(Action) by bin(RetrievalDate, 1d)
| render columnchart 

This data can be further analyzed to get trends for individual actions, such as below where we see a downward trend for the action MailItemsAccessed. This insight can be used to get insights into trends. Big changes could mean that logs are not collected anymore or might indicate anomalous behaviour.

Query:

Actions_CL
| where _OriginalType == "OfficeActivity"
| where Action == "MailItemsAccessed"
| project RetrievalDate, TotalEvents
| render columnchart

Entra ID Role and Group Reporting

The last use case shared in this blog investigates the reporting potential for Entra Groups and Roles.

Group

This summary rule focusses on the group memberships of users. The results are saved in the EntraGroupMembership_CL table. An example of the results is shared in the image below. The results of the summary rule can again be used to get insights into specific users, to for example see if their memberships increase or decrease overtime.

Summary Rule Query:

let StartDate = startofday(ago(1d));
let EndDate = startofday(now());
IdentityInfo
| summarize arg_max(TimeGenerated, *) by AccountObjectId
| mv-expand GroupMembership
| summarize TotalMemberships = dcount(tostring(GroupMembership)), MemberOf = make_set(tostring(GroupMembership), 1000) by AccountObjectId, AccountDisplayName, AccountUPN
| extend ReportDate = now()

Roles

The query below creates a summary rule to report on the amount and which roles users have assigned.

Summary Rule Query:

let StartDate = startofday(ago(1d));
let EndDate = startofday(now());
IdentityInfo
| summarize arg_max(TimeGenerated, *) by AccountObjectId
| mv-expand AssignedRoles
| where isnotempty(AssignedRoles)
| summarize TotalRoles = dcount(tostring(AssignedRoles)), Roles = make_set(tostring(AssignedRoles), 100) by AccountObjectId, AccountDisplayName, AccountUPN
| extend ReportDate = now()

A reporting use case that is recommended is to monitor the top 10 users with the most roles. They most likely do not need all those roles, which is not in line with the least privilege principle.

To get the top 10 users, use the query below (EntraRoleAssignments_CL = table in which the summary rule results are saved):

EntraRoleAssignments_CL
| summarize arg_max(TimeGenerated, *) by AccountObjectId
| top 10 by TotalRoles

Yes, it is possible to get the results for the Unique Actions and Entra reporting without summary rules. However, the queries consume heavy resources which you want to avoid.

Tips

Some tips to get you started with using summary rules:

• The results of summary rules are mostly aggregated data, which uses less space. It is recommended to summarize important data via summary rules and save it with a longer retention.
• Run resource intensive queries with summary rules. By doing so the results are saved in a custom table, with this you only query the results instead of collecting all the events over and over again.
• Summary Rules can serve as input for Analytics Rules, and use NRT analytics rules to directly inform the security team when new data is added to the custom table.
• Use summary rules accross all tiers. For example use the summary rule to get the important events from Auxiliary and Basic tables. The results can be forwarded to a Analytics table again where you can use all the KQL capabilities again for analytics rules.
• For high-volume tables (such as MicrosoftGraphActivityLogs) summarize the data by entities and forward that to the custom summary table. The original data can then have a low retention period, while the aggregated results (that take less space) can be saved for a longer period.

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