When a cyberattack occurs, the SOC acts as the digital front line, responding forcefully to the security incident while also minimizing the impact on business operations.
Since SOC resources are limited, we need to maintain a delicate balance on our analysts making sure we are not overloading them with incidents.
In Sentinel we are constantly thinking of ways to improve SOC performance, reduce false positives, and drive down MTTR as low as possible.
In our example, our SOC has several low-severity rules as a part of the mix.
Each of the low-severity rules can create alerts and incidents that we want to make sure are not overloading the SOC.
For that we will construct the following architecture:
Setting the low-severity rules:
We want to make sure incidents are not created from low-severity rules, only alerts.
This way we are not creating any incidents thus not changing the load on the SOC regardless of how many alerts are created.
To do so, we apply the following configuration on the rules:
Incident load balancer:
Now we can see that we are getting alerts into the workspace from our low severity rules but no incidents to investigate.
We will create an additional rule that will process all the alerts created by low severity rules.
This rule will be responsible for creating incident from multiple low severity alerts.
Let’s discuss the configuration:
Name, description, severity, and tactics: since this rule is going to process multiple alerts from multiple rules the name and description should describe the load balancer rule. The severity and tactics don’t matter since we are going to take them dynamically from the alerts.
Rule logic: The rule logic is where the magic is going to happen.
Assuming in our example that we wouldn’t like to get incidents from rules that generate more than 100 incidents.
Usually, to do so it will require us to create such a logic in KQL which is not that complicated but to maintain the original alert data we are forced to re-map the entities.
Sentinel has multiple entity types to select from, this means that parsing is going to be a real challenge and cannot be done in a generic way that will fit all rules.
Sentinel entities solves just that, instead of starting to parse the ‘Sentinel entities’ from Sentinel security alert you can map it directly.
Regardless of how many different entity types are in there, Sentinel will do the heavy lifting for you.
This setting means that if the content of the column ‘SecurityAlertEntities’ is a valid Sentinel entity structure it will be parsed automatically by Sentinel.
It also means that we can add additional entities or any information to the new alert.
Dynamic alert details to the help: new if we will just save the rule as is we will be missing the original name/description/tactics/severity.
This will be set to the values of the rule (and not the alert) to solve that we can use the dynamic alert details (blog).
By using the dynamic alert details, we can set the name/description/tactics/severity according to the values we see on the alert itself.
Event grouping configuration: now we need to keep in mind that each result that we are getting from the query is an actual alert so we would like to have an incident for each of the result.
We will be using the “Trigger an alert for each event” option that will allow us to create up to 150 incidents from the result of the query.
The incident: the incident we are getting is populated with all the correct information.
We can see that the name and description is populated from the alert and that the entities have been parsed automatically by Sentinel.
Rules that are exceeding the limitation: as for rules exceeding the limitation, we would create an additional rule that will open a ticket to the detection engineer to take a look at the rule and tune it.
What we saw: in this blog we covered the ability of parsing Sentinel Entities from the security alert table.
We took a simple use case of SOC load, but this can be used for many more use cases cross rule correlation, advanced filtering, cross workspace correlation - are just a few of them.