Note!
This blog post is now part of the official Azure Sentinel documentation, and updated there.
This blog post is obsolete.
In no organization, everyone is allowed to see all information. The same is true for the data collected by your SIEM system. Luckily, Azure Sentinel has the tools needed to limit such access. The primary methods to enable such role-based access to control to data, or data RBAC for short, are either to split your Azure Sentinel implementation into multiple workspaces or to use Resource RBAC. In this blog post, I discuss when you should use each of those methods and describe how to implement the latter. To learn more about using multiple workspaces in Azure Sentinel, you review out Azure Sentinel architecture webinar (YouTube, Slides) or get deeper listening to the forthcoming Azure Sentinel for MSSPs webinar (register here).
For completeness, there are two additional methods for controlling access to data in Azure Sentinel, both serve well some use cases but are less general and which I don't discuss in detail in this post:
Lastly, it is worth mentioning the ability to control access to the different features in Azure Sentinel. Azure Sentinel feature RBAC is typically used to differentiate between roles in the SOC, rather than to control access to data.
When using resource RBAC, users who have access to the Azure Sentinel workspace can typically view all the data. Resource RBAC helps by enabling users, let's call them none SOC users, who do not have access to the workspace to view telemetry collected for resources they have log reader permissions for.
None SOC users can view logs by navigating to a resource they have log read access to, or to a resource group containing it and use the "logs" and "workbooks" options to query the data and visualize it, respectively as demonstrated below:
Alternatively, none SOC users can navigate to Azure Monitor and use the "Logs" or "Workbooks" options. Using Azure Monitor enables the user to select the scope of the query or workbook, spanning multiple resource groups and optionally selecting specific resources.
The resource RBAC description above implies a significant distinction. In essence, for a SOC user to get full Azure Sentinel experience, you need permissions for the workspace, which implies access to all data. Resource RBAC enables external users to get access to their data, but not a full Azure Sentinel experience.
To summarize:
|
SOC team |
None SOC team |
Permissions |
To the workspace |
To specific resources |
Data access |
All the data in the workspace |
Only data for resources the team is authorized to access |
Experience |
Azure Sentinel experience (possibly limited by the functional permissions the user has) |
Query (“Logs”) and Workbooks only |
There are use cases for which resource RBAC does not provide a solution. One such scenario is when a subsidiary has a security operations team which requires a full Azure Sentinel experience. In this case, using a multi-workspace architecture, as described above, is the preferred option.
Another challenge is data RBAC, which is not based on resources, for example, limiting access based on the user an event references. You might encounter this requirement when trying to limit access to Office 365 logs based on the subsidiary of the user.
The full solution for this would be to use custom collection, as described later. A more straightforward solution, even if partial, would be to enrich the relevant log with the subsidiary information, as described in Chris Boehm's blog post. Once enriched, use the information in workbooks, so that each none SOC team gets access to a workbook pre-filtered to display only its data.
The best practice for implementing resource RBAC requires the following steps:
Once you completed those steps, team members have access to their logs through the "logs" and "workbooks" options of their team resource group.
In some cases, especially when collecting from Azure resources, the resource group assignment must follow a different methodology preventing you from grouping resources to the team resource groups described above. In those cases, using the alternatives suggested above for none SOC team use, namely a dedicated workspace or through Azure Monitor, work.
When Azure resources, whether VMs using the Log Analytics agent or PaaS services, send telemetry to Azure Sentinel, the log records are automatically tagged with the resource ID of the originating resource. Ideally, group the resource under the resource group you created. If you cannot do that, make sure that the none SOC team has log reader permission to the resources themselves.
When collecting events using CEF, Syslog, or WEF*, a collector VM is used to collect events from multiple source systems. For example, when a Syslog collector VM listens to different sources sending Syslog and forwards it to Azure Sentinel, the collector VM resource ID is assigned to all events. When using an on-prem or another cloud collector VM, you can ensure it has a resource ID by implementing Azure Arc.
As a result, you need to ensure that separate collector VMs are processing events that belong to different none SOC teams. So that all the Syslog events which belong to team A are collected using collector VM A.
To summarize, to allow a user group access to its data:
* WEF is in private preview at this time.
When collecting using the Log Analytics data collector API, you can assign to events a resource ID using a special HTTP header x-ms-AzureResourceId. As you may expect, the resource ID must be a real resource ID. So which resource ID should you use? While you can use any valid resource ID, the best practice is to use the ID of the resource group you created for the none SOC team, which the events should be accessible by.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.