Intro
Automation is a key element to improve SOC efficiency. Many different use cases exist where automation can be applied
- Tagging of Security incidents
- Severity level adoptions
- Auto-Closure
- Security incident information enrichment
- …and many more
Most of the automation is based on pre-defined conditions. To auto-close a security incident one needs to define specific conditions (host X + user Y + IP address Z).
To summarize the situation, we need entities mapped and available in the security incident to apply most of the automation use cases.
The challenge
No entities are available after the security incident has been generated.
There might be two major reasons;
- Entity mapping in the corresponding scheduled analytic rule is faulty and not set up properly. Stop reading and setup the entities in the analytic rule correctly to address this challenge
- Entities are not mapped or mapped with a huge delay (5-10 minutes) for security incidents generated by external platforms (e.g. M365 Defender). Continue reading.
Playbook automation - solution approach
Assuming that Playbooks (Azure LogicApps) are used for automation, the challenge can be addressed with this approach.
- First bracket – Add a tag (in my scenario, I’ll tag security incidents which are automated)
- Second bracket – Add a loop action to the LogicApp. The loop action runs until a result from the KQL query search (check if entities are mapped for the security incident) is returned (also add a general timeout)
- Query the security incident’s entities with KQL. The security incident number can be gathered from the trigger action (Microsoft Sentinel incident)
- Results parsing
- (optionally) add a delay to limit the number of search queries and throttle their execution
- Third bracket – (optional) At any point in your LogicApp where the workflow is terminated; remove the automation tag from the security incident
Additional benefits
Given the situation that multiple Playbooks are triggered via automation rules, the additional benefit of this approach is that dependencies can be created between the involved Playbooks. Simply add the loop step to any other Playbook workflow and query if the automation tag is assigned to the security incident.
If the tag got removed -> the security incident is not automated. If the tag is available -> the security incident is automated. Pay close attention of the loops duration limits though 😉
I’ll follow-up on this benefit in another blog post.
- 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
6 Comments
CyberHunter · February 15, 2023 at 15:02
Can we get the raw source code of the logic app please (code view)?
Christoph Düggeli · February 16, 2023 at 20:09
Hi CyberHunter, in this particular post I share the idea which should be sufficient to rebuild everything in another environment.
CyberHunter · February 20, 2023 at 19:59
I want to see how youre fetching the KQL to run I see the Analytical rule in the connector but not the actual KQL nor a connector I can use to pull the KQL for the Analytical rule
In Logic App Designer – select code view
CyberHunter · February 20, 2023 at 20:16
ah from raw payload?
Christoph Düggeli · February 20, 2023 at 23:52
You’ll get the result from the KQL query by using the Azure Monitoring Logs connector (run & list results) in the logic app.
Sentinel Incident Automation - Playbook dependencies - Workplace Ninja's · January 16, 2023 at 22:48
[…] Here’s the link in case you missed the blog post: Sentinel Incident Automation – handle entity mapping delay in Playbooks – Workplace Ninj… […]