Modular playbook architectures
Sometimes we end up building problems for ourselves when creating automations in Microsoft Sentinel. One way to work around some of these problems is to modularise the automation architecture.
Sometimes we end up building problems for ourselves when creating automations in Microsoft Sentinel… We can end up with playbooks that are complicated, difficult to maintain, hard to change.
Or we may end up with too many Automation Rules, too many sources for Comments in our incidents, too many unnecessary events in our incident Activity log, etc.
Sometimes a good fix for these situations is to modularise the automation architecture.
My usual example for this is Incident Enrichment, parsing through entities in our incidents that we want to enrich with external data. Threat indicators, asset management attributes, geolocation data, etc.
Consider the following workflow:
With this approach, we only need one Automation Rule for all kinds of entity scenarios and we only need to call one playbook from Sentinel.
The main playbook can identify what entities we are dealing with and run nested playbooks, which handle the actual lookups and enrichment to Sentinel (or pass the last task back to the main playbook, if that suits your scenario better).
This way our individual playbooks stay simple and easy to maintain. Of course you could take the middle road here, and combine some or all of the nested playbooks into one.. May ways to go about this.
How to handle nested Logic Apps? There are plenty of resources describing that:
This is an idea I’ve implemented for multiple clients and I’m happy to discuss this further with you if needed.
For now I’ll just publish this as a quick post to get the year 2025 started properly here on SecOpsLab.