How to Prohibit an Azure Sentinel Analyst from Editing a Playbook

Recently, I wrote about how to Grant Access to Specific Azure Sentinel Playbooks for Specific Analyst. The idea with that is to ensure that an analyst with meager access can still run Playbooks against Incidents. By default, the Sentinel Reader role is limited in what they can do in Azure Sentinel. As a reminder, here’s the current list of applicable roles that can be assigned to an Azure Sentinel analyst:

A customer required recently that in addition to limiting access per Playbook for an analyst, that we could somehow limit the analysts’ abilities even further. The customer wanted the analyst to be able to run a Playbook, but then not have the capability to modify the Playbook logic. My steps outlined previously provided the ability for the Azure Sentinel Reader role to run a Playbook, but they could also modify the Playbook logic.

Working with a colleague from China, Arvin Zhu, the following method was identified and prescribed. I want to thank Arvin for the work on figuring this out and the eagerness for wanting to work together to share with the community.

The following method digs into creating and applying custom Azure roles. In our scenario, the intent is to still give the Azure Sentinel analyst access to run a specific Playbook, but take away (or filter-out) the ability to modify or delete the Playbook.

How to do it

First, use my previous instructions to Grant Access to Specific Azure Sentinel Playbooks for Specific Analyst. Without assign Logic App Contributor access, the analyst will not be able see the specific Playbook in the Playbooks blade.

Next, you need to create a custom role at the Azure Subscription level. In the Azure portal, go to Subscriptions.

In the IAM blade of the Subscriptions area, click the Add option, and then choose Add custom role.

On the metadata page in the wizard for creating a custom role, give the new role an appropriate role name and a good description.

Now, on the Permissions tab in the wizard, look for Microsoft.Logic/workflows and choose Other : Run Workflow. Add it.

Next, locate Microsoft.Logic/workflows/triggers and choose Other : Trigger Run and Other : List Trigger Callback URL. Add those.

Once you’ve added these three specific permissions, your Permissions list should look like the following image.

Finally, we need to assign the new role to the analyst for the specific Playbook. Go to the Playbook and choose to add a role assignment. It may take a few second to a few minutes for the custom role to show up in the list. Sometimes it takes a while to sync across the Subscription. Once it shows up, select the newly minted, custom role from the list.

Now assign the custom role to the specific Azure Sentinel analyst.

By walking through these steps, you have effectively given a lower access analyst the ability to run a specific Playbook and also limited the analyst’s ability to modify the logic of the Playbook. You’ve also (hopefully) gotten a taste of why knowledge of creating custom roles can be so important to your work in Azure.

Best Practice

This method works, but I highly recommend that – if at all possible – you just use the normal methods to use the built-in roles to assign access. Why? Well, continually making modifications to access per instance means management of access can quickly get out of control and make the job more difficult. As a security principle you always want to include periodic access reviews as part of policy and unless you adhere to change management, someone may have access they don’t need. Or there may be conflicting access rules that keeps an individual from having the access they need.

[Want to discuss this further? Hit me up on Twitter or LinkedIn]