Add Azure tags from evidence to your Sentinel incidents

…and make the life of your security analysts, yet again, a little bit better

Introduction

When investigating security incidents in Microsoft Sentinel there will probably be a few entities related and attached as evidence. It can be very helpful to have additional information about each entity for your follow-up triage steps. These details might help you asses the impact or help you to get in touch with the right owner(s). Think of details like in which environment the resource is running (i.e. production or test), which department is using it and maybe even some contact details.

Especially in larger organizations, where resources can span tens or even hundreds of Azure subscriptions, this can be very helpful. These organizations are probably already making use of tags for all of their Azure resources and subscriptions. And now these will be also beneficial for your SOC.

In this article I want to share how you can retrieve Azure tags from an Azure Logic App and use this for automation to add these to your Microsoft Sentinel incidents.

Authentication

Via Azure Resource Manager APIs we’re able to retrieve tags from subscriptions and resources:

https://management.azure.com/ <subscriptionId>
/providers/Microsoft.Resources/tags/default?api-version=2021-04-01
https://management.azure.com/ <resourceId>
/providers/Microsoft.Resources/tags/default?api-version=2021-04-01

But we need to authenticate first. One way to do this is by using an Azure application / SPN with a secret which acts as a password. But this means you also have to keep managing the SPN, its secret(s) and preferably an automatic key rotation mechanism.

To skip all this you can use a system-assigned managed identity instead and because of this, it has become my favorite way of handling authentication in Azure Logic Apps and other Azure resources.

If you still want to use an SPN, and you’re interested in building an automatic key rotation mechanism using Azure DevOps pipelines, please read this article I’ve posted in the past.

Don’t forget to enable the managed identity within your Logic App

In the “HTTP” step you need to enable authentication via managed identity

Most Logic App Connection support authentication via managed identities by now. But there are some exceptions unfortunately, like for example the Log Analytics / Azure Monitor connection. Stay on the lookout for my next article where I’ll explain how to work around these limitations!

Permissions

Your Logic App’s managed identity also needs some permissions. Unfortunately there’s no built-in Azure role which would only allow reading tags. Sure, you could use the reader role, but this would mean the Logic App can also retrieve all kinds of other information about resources and subscriptions. Obviously we want to practice principle of least-privilege here, so we need to create a custom role.

The managed identity can then be assigned this newly create role on your (root) management group which means it inherits these permissions across all of your subscriptions.

Example of a custom “Tag Reader” role

The Logic App would not be able to retrieve resource groups. Nor would it be able to retrieve other resource-specific details. It can only read tag information once it knows a specific subscriptionId and/or resourceId.

Yes, there is a ‘tag’-specific role called Tag Contributor but assigning this role would also mean that the Logic App can alter and add tags, and this is not required for this particular use case.

The workflow

Here’s a general overview of what the Logic App workflow looks like:

• One or more entities are coming in from Sentinel. These can be all sorts of items like hosts, users, IP addresses, storage accounts, databases etc. The workflow will loop thru all entities with a for each step.
• Because every Azure subscription contains a Defender for Cloud instance (and because larger organization nowadays tend to separate applications/solutions on a per-subscription-basis) I see my customers sometimes struggling with handling Defender for Cloud alerts. That’s why I’ve added a step which determines if the incident is coming from this source because it contains an alertId with a subscriptionId. The subscription tags can help the security analyst to track down the team responsible for configuring Defender for Cloud policies for example.
• Next, the workflow will check te entity kind to determine if it is an Azure resource or not. If not, that particular entity can be skipped.
• If it’s an Azure resource we also have a resourceId and we can retrieve its tags via the API.

Overview over de processes inside the Logic App workflow

Result

To get the most out of this Logic App, I’d advise to create a Sentinel automation rule which triggers the playbook for every incident that is raised.

There might be incidents where there’s either no subscriptionId involved nor a resource residing in Azure, like with Microsoft 365 Defender alerts. But that’s fine, the Logic App won’t return any results and the incident won’t be tagged.

The example below shows an incident coming in from Defender for Cloud in which other Azure resources were attached as evidence. Now the security analyst has an instant overview of details of both the Azure subscription as wel as resource-specific details added as tags:

Both Defender for Cloud subscription tags and resource tags were added to the incident

Try out this Logic App yourself without having to re-build it. Click on the button below for a one-click-deploy it into your Azure environment:

You can also manually download the ARM template here

Conclusion

I hope you’ve find this informative and clearly explained. Hopefully this solution is useful for you as well! Or it might have inspired you to build a variantion of it.

If you have additional questions, never hesitate to reach out to me!