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
- 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.
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
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