Intro
I recently stumbled over a LogicApp (Microsoft Sentinel Playbook) I’ve created a long time ago where I needed to fix some stuff. The use case of the LogicApp is to handle the phone alerting process for customers with specific alerting requirements (no 24/7, only dedicated times during the day).
In this blog post, I want to share the implementation approach. Have you approached the challenge differently or see a pitfall? Let me know in the comments!
The challenge
Our SOC handles security incidents raised in Microsoft Sentinel. Depending on the customer use case, alerting is only required during a specific time period. Additionally there might also be a limitation on the security products covered by the SOC service.
Long story short for this blog post: Security Incidents created must only be alerted during the agreed monitoring time.
Approach
Our approach was to
- Trigger a LogicApp where all the information from the security incident ticket is available
- Compare the information from the security incident with a watchlist – the watchlist has the customer specific details:
- Alerting time start
- Alerting time end
- Included Alert providers (security products)
- If there is a match -> alerting process is initialized
We have all the required information items available in the security incident entity.
Step 1 - Variables initialization
The first section of the LogicApp initializes a bunch of variables. Please note that due to debugging I have more variables initialized than actually required.
Actually this is the key part of the LogicApp;
- The IncidentCreatedTime is first translated to local time (CET)
- Then the values for hours, minutes and seconds are extracted from the local time as this information is key
- As a last step, the colons are removed from the hh:mm:ss value and then transformed to an integer (varLocalTimeHHmmss). Now we have the incident time created as an integer available.
int(replace(variables('IncidentTimeLocalTimeHHmmss'),':',''))
- The variables for the watchlist values varSocSmartAlarmingFrom and varSocSmartAlarmingTo are only initialized as these are empty and filled with data at a later time
Step 2 - Watchlist information
A query on the watchlist looking for the customer workspace ID (which is unique) returns the results we need to cover this use case; SocSmartAlarmingFrom and SocSmartAlarmingto.
I know that I could have stored these values as integers within the watchlist in a first place. Due to the latest updates in the LogicApp’s workflow logic, these values have not been migrated yet.
Final step - compare the information
The following steps are straight forward.
- Convert the watchlist values to integers as well (screenshot 1)
- Check if specific watchlist values were returned from the watchlist query for the customer (screenshot 2, condition – CheckCustomerAlarmingtimeValues)
- Check if the values from the incident (time created) are within the values from the watchlist (screenshot 2, condition 2 – CheckIncidentCreatedTimeAgainstAlarmingtimeValues)
- Optionally (that’s what we do for other use cases) you could also check if the security incident Alert Product is returned in the watchlist results. (second screenshot)
Voilà, based on the result from the last condition, the further steps to perform the alarming (or what your use case includes) can be conducted.
I decided to only update a variable (AlarmTrigger). Based on the variable’s value, the whole alarming logic is triggered later on.
Screenshot 1 – watchlist values conversion
Screenshot 2 – Values comparison
Closing thoughts
I personally like to remove the logic from required parameters. Therefore the logic app calls a watchlist whose results can be compared to the security incidents information entities.
As of today we have not had any struggles or issues with this approach. Let me know if you need any more details or have questions/feedback.
- Sentinel Automation use case – custom Alerting with LogicApps - March 6, 2023
- Microsoft Sentinel Security Incident statistics with Workbooks - February 20, 2023
- Sentinel Incident Automation – Playbook dependencies - January 16, 2023
0 Comments