My wishlist for automation with Microsoft Defender XDR

During Ignite 2023, we were bombarded with announcements concerning AI. In the Security Space, the main announcement was Microsoft Security Copilot. This Copilot is meant to aid security analysts during an investigation.

Another major announcement is ‘Microsoft Defender XDR’, besides a name change (again 😒), Microsoft is implementing a ‘Unified SecOps platform’, merging Microsoft Sentinel into M365 Defender. In a first phase, this means you will be able to use Microsoft Sentinel and Microsoft 365 Defender from the same GUI. Besides a change in GUI, Microsoft stated the following in their announcement blog.

We are unifying capabilities including single data model, advanced hunting and incident management. 

https://techcommunity.microsoft.com/t5/microsoft-sentinel-blog/introducing-a-unified-security-operations-platform-with/ba-p/3983341

There is little knowledge available about what they mean exactly. How will they merge the data and advanced hunting capabilities? Both products (Microsoft Sentinel and Defender XDR) have a totally different architecture so this raises a lot of questions.

Reading this, got my hopes up and got me to start dreaming… Imagine if Microsoft is merging the two products, I would hope we can use the best of both worlds. Within this article, I want to go over my wishlist for what kind of automation capabilities I would want to see in a Unified SecOps platform.

API Support

When we are looking into API support between Microsoft Sentinel and Defender, the differences are night and day. As Microsoft Sentinel is built on top of Azure Resource Manager, API support has been there since day one. (Almost) Everything that you do using the Sentinel UI, creates API calls using the public Azure Management Rest API. This means it’s possible to automate almost everything.

This is in stark contrast with Microsoft 365 Defender, as we are severely lacking API capabilities. We are missing some core capabilities such as:

• Configuring MDE’s advanced features
• Managing Custom Detection Rules
• Acting on MDO’s action center

These features desperately need API support as it is now not possible to configure those settings programmatically, which is required for MSSP’s such as mine. Without an API, configuring some of those settings is manual labor and a setting can be changed behind your back without you knowing.

With the upcoming conversion of the two products, I am unsure what route Microsoft will go. We are in desperate need for additional API’s within Microsoft Defender XDR and I hope these will be released sooner rather than later.

Most of the ‘backend’ management tasks are now done through the GUI, but there is no way to configure a four-eyes principles – to require approval for a change as we can do when we manage Microsoft Sentinel as CI/CD. Because these settings have such a high impact, this is really necessairy.

Built-in actions vs customization

Automation within Microsoft Sentinel is done using Azure Logic Apps (called Playbooks when used in Sentinel context). Azure Logic Apps are a low-code way to add simple automations without much effort.

Microsoft Defender XDR does not have the same support, but offers built-in actions that can be added when a hit is found on a custom detection rule. This makes it extremely easy to take actions on certain high-confidence rules. By using these actions, you can easily isolate a device or disable a user. In Microsoft Sentinel, you always need to add a new Playbook, which adds complexity. The concept of built-in actions is something I would like to see within Microsoft Sentinel. Some actions are universal and are used really often. Think about: revoking user’s sessions, resetting a password or isolating a device.

This does not mean there is no use case for Logic Apps anymore. I, for one, need additional customization for those actions. Within our The Collective SOC, we allow a customer to customize the automation flow. What devices can be isolated, is there an approval flow or should a notification be sent? Those things cannot be configured with the built-in actions and require a custom Playbook. The advantage of having custom Playbooks ensures advanced users can tweak some of the actions to their liking. Keeping Logic Apps available within Microsoft Sentinel is of paramount importance.

I would like to see Logic Apps have more native integrations into the Defender suite and allow for an easier way to handle data. While there is a connector available for MDE, there is no support for Microsoft Defender XDR in general. Actions into products such as MDI and MDO are missing. In an ideal world, we should have actions to interact with emails and take preemptive actions. A lot can be improved to create a tight automation experience between XDR and SIEM.

Summarizing my thoughts above, I would love for Microsoft to make it easier to build simple automations (more built-actions throughout the products), while still allowing advanced users to have some complexity in their automation (additional support for Logic Apps).

Side Note: Microsoft Defender natively integrates with Power Automate and I am personally not a fan. In the past, I have voiced my opinions on Power Automate for certain ‘infrastructure tasks’ and I hope Defender will embrace Logic Apps just as Sentinel did.

Limitations of low-code

While I regularly praise Logic Apps for their easy of use, you can run into limitations while building some workflows. A great example is looping over array’s of data and using the data to create further actions.

Once you have multiple nested array’s and a few set of objects, things are getting really complex. At this point, you have multiple levels of loops within your Logic App and it’s hard to keep track. That’s why I prefer to create extensive KQL queries that do most of the heavy lifting, removing the need for data handling within Logic Apps itself.

Some of this complexity stems from the fact that you will hit some of the Logic Apps’ limitations, stuff that can easily be coded in Powershell/Python or .NET but cannot be done easily in Logic Apps.. More often than not, it’s just easier to create a quick Powershell function instead of creating complex flows in Logic Apps.

At this time, there isn’t a native integration between Azure Functions and Microsoft Sentinel. While we can trigger an Azure Function from a Logic App, I am missing a native integration. This would allow for easier workflow, without the additional step of having a Logic App that purely receives input from Sentinel and forwards it to an Azure Function.

Entity correlation

If you have used Sentinel Playbooks in the past, you might have worked with entities. An entity in Microsoft Sentinel can have different properties. If we take an account entity as an example, it can have a name, UPN, object ID and much more.

Depending on the type of Playbook trigger (entity, alert or incident) we use, the data for the entity we get will be different. If I would trigger an alert-based Playbooks, I might only have the AzureObjectID. While an incident trigger for the same entity will contain the UPN, name and job title as well.

During previous engagements with Microsoft, they have confirmed this is expected as some triggers ‘enrich’ their entities before sending the data to a Playbook. Having this kind of difference is different to work with, as we are never sure what kind of properties we are able to use.

The same is applicable for different entities, using the same trigger. When using an entity-based trigger, we have seen cases where the object ID is present, while others only have a UPN.

I hope that Microsoft Defender XDR can do better in terms of entity support and provide a uniform way of providing data. This allows us to create simpler automations.

Hoping for the best

With this blog, I wanted to share some of my current frustrations while automating Microsoft Cloud Security. I hope that with the release of Microsoft Defender XDR some of the existing issues will be fixed and that there will be a focus on more integration and standardization across XDR & SIEM.

Featured image was created using Bing AI.