Microsoft Azure Sentinel 101: Dynamically update and change Alert/Incident Severity — based on query results with automation or logic apps for all alerts
Depending on how you run your SOC, you may wish to drop Severity to help prevent going over SLAs, especially when an alert is not a threat. At the same time, you may wish to quickly change an alert severity if it does something specific.
This concept is nice so you don’t have to create multiple alerts to cover different concepts. With this guide, we will create 4 automation rules that will automatically be used by all rules so all we have to do is “tag” our rule and it will quickly be updated to the right severity.
There are a few different ways you can do this.
But first, we need to go over some KQL.
| extend AlertSeverty = iif(User contains "root","Low","Medium")What the following does, it is looks for a value, and if its true, set a value, if not, set another string.
The syntax is as follows:
iff(if, then, else)You can find another example over at https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/iff-function
This allows us to do checks in our alert logic and depending on what we see and find in logs, we can adjust the severity so it makes more sense. So based on correlations, for example, we can determine how sever the threat is based on addition findings and adjust as needed.
Change Severity By Analytics Rules
This is the easiest way, but if at any given time you want to change, disable, ect… you will have to edit every analytic rule.
If we go to the Analytic rule, we can find the hidden secretive text, click on it, and then assign the dynamic value
And there we go. It is a low over normally a Medium.
Change Severity By Automation Rules
This way is nice if you want to have more control and quickly cover all rules for example and have an easy on and off switch.
First lets assign values to the rule. We don’t really need the custom details field, but it also does not help and can future proof the alert for other user-cases and have a field that can be seen and referenced as needed.
Depending on how many dynamic meta values you have, this may not work as you are limited to 3 in the description zone. In this case, we created a tag called “AS:Severity” so we will look for that specific string.
From there we will create 4 automation rules for each severity type.
Take note to where we look for our custom string in the description to know to take action.
From there we let it run and there we go:
Change Severity By Playbooks/Logic Apps
This is another way you can do this. While more complex and time requirements, it allows you more flexibility to cover all the rules, while at the same time not having to worry about the meta limits in the description.
You can see an example of this concept being done here:
—
☕ Like what you read? Did it help you?
Send some coffee and love https://buymeacoffee.com/truvis :)
Your support helps pay for licenses, research & development, and other costs that allow me to bring you new guides and content!
❗If you are new to my content, be sure to follow/connect with me on all my other socials for new ideas and solutions to complicated real world problems and jump start your career! New content drops daily/weekly along with tips and tricks :)
👉 W: https://truv.is
👉 T: https://twitter.com/thattechkitten
👉 Y: https://www.youtube.com/@TRUValueInformationSecurity
👉 G: https://github.com/truvis
👉 L: https://www.linkedin.com/in/truvisthornton
👉 M: https://medium.com/@truvis.thornton
