Azure Sentinel RBAC Review - Azure Cloud & AI Domain Blog

I was recently asked by a customer to help prepare a matrix covering role-based access for Sentinel users and administrators. In this article I describe a custom Sentinel Advanced Responder role and several interesting points around Sentinel access management.

Sentinel Access Matrix Example

I recommend setting up user groups to define access for each category of Sentinel user. Assign built-in and custom roles to these groups as needed. The groups can be documented in a matrix for reference and tracking. Consider designating the scope (SUB,RG,WS) and highlighting custom roles. You may also want to designate persistent assignments, temporary elevated access, and hybrid access requirements.

Temporary Access Requirements

Sentinel administrators will need elevated access for certain activities. These credentials can and should only be granted on a temporary basis.

Activating and modifying connectors involving Azure services often requires Global Admin or Security Admin.
Setting up Notebooks may require activation of Machine Learning services.
Activating and developing API-based connectors may require the creation and management of App Registrations in Azure AD.
You may need to store and retrieve keys from a Key Vault and Azure AD.
Developers may need Sentinel Contributor access to test and deploy new solutions.
Sentinel Administrators and Responders may need temporary access to highly secured resources for deeper analysis.

Persistent Access Requirements

Your Sentinel Administrator should be approving and periodically reviewing Sentinel access (possibly assigning access).
Sentinel Administrators and developers will need access to create analytic rules, hunter queries, workbooks, and playbooks.
Sentinel Administrators and developers may need access to Azure Monitor, Azure Automation, Azure Functions, and other related services.
Sentinel Administrators and developers may need persistent access to specific blob storage or file shares.
Sentinel Administrators and developers may require persistent Application Administrator access when many API connections are maintained.
Sentinel Administrators and Responders will likely need access to related security solutions like Defender, Office ATP, and MCAS.
Sentinel Administrators and Responders will need access to most source systems and logs for deeper analysis.
Sentinel Administrators and Responders will often need access to operational (non-Sentinel) workspaces for deeper analysis.
Internal stakeholders may need access to view workbooks and other Sentinel data.
External support providers may need persistent access to provide managed services (guest accounts, company managed accounts, or Lighthouse).

Note: Guest users cannot assign incident records unless they are granted Directory Reader permissions in Azure AD. This is assigned per user. Guest users are prevented from reading the directory by default.

Hybrid Access Requirements

Sentinel Administrators and Responders will often need more traditional credentials, especially in a hybrid support model.

Persistent or periodic RDP and SSH access to servers.
Remote access to event logs and monitoring agent configurations.
Access to appliances and network devices like firewalls and Internet proxies.
Access to management consoles for related Microsoft solutions like SCOM, SCCM, Intune, and Orchestrator.
Access to related 3^rd party solutions like ITSM, SolarWinds, AV and EDR, SEIMs, and VMWare.

Taking a Closer Look:

There are three Sentinel RBAC Roles including the Sentinel Contributor, Responder, and Reader roles. There are similar roles for the Log Analytics Workspace, Logic Apps, and other services that you should also consider.

Sentinel uses a Log Analytics workspace that resides within a resource group.

Role based access cannot be set directly on Sentinel. Rather, access is inherited from the workspace, resource group, and subscription.

You need at least read access (in some form) to the resource group. Sentinel access cannot be granted on the workspace directly (using Sentinel Contributor, Sentinel Responder, or Sentinel Reader).

All Sentinel users should have read access to the Resource Group at a minimum.

What is a role in Azure?

A role is a set of allowed and not-allowed resource provider activities. A resource provider is a service and each provider has a defined set of activities (permissions).

Roles allow or deny (not-allow) activities from one or more resource provider. For example, Sentinel, Log analytics, and Key Vault.
Role definitions can use wildcards to include an entire provider set or common value. For example, “*/read/” for all read activities.
There are built-in and custom roles.
Roles are cumulative.

Azure includes many built-in roles representing a recommended set of permissions (provider activities). You have the option to create custom roles, choosing your own provider activities. There are many providers and activities to choose from. Creating roles requires a certain amount of testing and the documentation on specific activities is limited. Here are a few tips for creating custom roles:

Test your custom roles carefully before making production assignments.
Refer to the Built-In Roles documentation to identify target activities.
Create a test user and group to represent the target audience. Always assign roles to groups.
Log off and log back in with your test account to verify changes.
In most cases you will need to use the traditional method for custom roles.
There is a new Custom Role Creator though it is limited to specific providers and activities.
Do not forget that roles can allow and not-allow.

Having a basic understanding of how these roles are defined will change how you look at roles in the future.

What is Reader access?

Reader is one of the core built-in roles (it gives the user every child activity that ends in “read”). Reader will allow users to view all child resources (except for secrets). This also excludes all activities not defined as ‘read’. There are some activities that are read-only but are not listed specifically as “read” activities. As a Reader you can view most of the data and configuration. Readers cannot see all settings and blades (because many activities do not have “read” in the name).

There are many service-specific roles (including reader roles). For example, Sentinel Reader and Log Analytics Reader. Despite having similar names, they can vary significantly in definition.

Log Analytics Reader is equivalent to the standard Reader (*/read) plus the ability to run searches and view monitoring settings.

Sentinel Reader is not based on “*/read” like Log Analytics Reader. Rather this role grants read access to a list of specific resource providers including SecurityInsights (aka Sentinel), OperationalInsights (Azure Monitor), and a few other related providers.

Why are we talking about Reader?

You need read access to the resource group where your Sentinel workplace resides. Granting access directly to the child workspace is ineffective. Assuming you are using the built-in groups, you need one of the reader roles listed above at the RG level at a minimum (Reader, Log Analytics Reader, or Sentinel Reader). Higher-level roles obviously count as well like Responder or Contributor.

What about Sentinel Responder?

Sentinel Responders can view the Sentinel configuration, query the logs, and assign and close incident records. Responders have some interesting limitations:

Sentinel Responder cannot modify configuration (create new rules, change workbooks, etc.)
Sentinel Responder cannot create bookmarks.
Sentinel Responder cannot use the investigation blade.
Sentinel Responder cannot manage watchlists (preview).
Sentinel Responder cannot use the behavioral analytics profiles.
Sentinel Responder can use the hunting blade but cannot set hunter query favorites.
Sentinel Responder cannot delete incident records.

This is a great example of where custom roles become important. Your organization and users will have unique role requirements. Start by evaluating the built-in role and provider activities to grant additional access or restrict access as needed. This will require some trial and error to identify the desired activity. For example, you likely want your SOC responders to create bookmarks, perform investigations, and block the deletion of incident records.

Sentinel Contributor is the Sentinel Administrator role. You do not want to assign Sentinel Contributor simply because your Responder role is too limiting. Though this may be your only option if you rely on built-in roles alone.

Sentinel Advanced Contributor Example

Here is a list of actions and not-actions to create an Advanced Sentinel Responder role. These can be used in a variety of custom role creation templates.

“actions”: [
“*/read”,
“Microsoft.SecurityInsights/dataConnectorsCheckRequirements/action”,
“Microsoft.SecurityInsights/cases/*”,
“Microsoft.SecurityInsights/incidents/*“,
“Microsoft.SecurityInsights/Bookmarks/*”,
“Microsoft.SecurityInsights/Watchlists/*“,
“Microsoft.SecurityInsights/threatIntelligence/*”,
“Microsoft.OperationalInsights/workspaces/analytics/query/action”,
“Microsoft.OperationalInsights/workspaces/savedSearches/*“,
“Microsoft.Insights/alertRules/*”,
“Microsoft.Resources/deployments/*“,
“Microsoft.Support/“
],
“notActions”: [
“Microsoft.SecurityInsights/cases//Delete”,
“Microsoft.SecurityInsights/incidents//Delete”
}

Tips for Role customization

It is best to avoid granting unwanted access in the first place. There are several methods to consider:

Start with built-in roles whenever possible.
Assign users to groups and roles to groups at the RG or resource level.
Assign groups to roles as close to the target resource as possible (or as close as you can support).
You can create custom roles to allow and not-allow where the built-in roles do not meet your requirements.
Maintain separation of data with separate resource groups. For example, use separate resource groups and workspaces to isolate data (rather than using role-based restrictions).
If necessary, consider deny assignments using Azure Blueprints.

Reference:

Andrew Blumhardt