This installment is part of a broader series to keep you up to date with the latest features in Azure Sentinel. The installments will be bite-sized to enable you to easily digest the new content.
Today we are announcing a new feature in Azure Sentinel that enhances our multi-workspace and multi-tenant capabilities.
As you might know, there are certain occasions where your Azure Sentinel environment is spread across multiple workspaces. There are various reasons for this, like data ownership requirements or multi-tenant/multi-geography setups. For a full explanation of use cases and alternatives, refer to Extend Sentinel across workspaces/tenants.
In these cases, there’s normally the need to have a central place where we can oversee the whole environment. This can be for example a global SOC or in the case of an MSSP, a multi-customer console. This central place can be also used to replicate configuration (analytics rules, workbooks, playbooks,…) and manage all your workspace from a single point, ideally using DevOps processes and tooling. The following diagram describes this setup:
Up to now, customers and partners were able to do many things across workspaces, like hunting, workbooks and incident management.
Today we are happy to present the ability to create Analytics Rules that inspect data stored across multiple workspaces! 
With this new feature you can now create in your Central SOC, an analytics rule that spans across other workspaces, like shown in this picture:
This can also be used in a multi-tenant setup (using Azure Lighthouse) like shown here:
There are some things you need to consider when using this feature:
- Both the source and target workspaces need to have the Sentinel solution installed on them.
- You can include a maximum of 10 workspaces in each detection.
- Incidents and alerts raised by a cross-workspace analytics rule, will only be created in the workspace where the rule was defined (they will not show up in the “remote” workspaces)
Handling Entities
One of the great things about this feature, is that alerts and incidents created as part of a cross-workspace analytics rule, will also contain all the related entities, even if those entities are not from the workspace where the rule and incident where triggered.
This, for example, will allow analysts to analyze data from all workspaces related to an alert/incident.
Some other features are still not fully functional in the cross-workspace scenario, like full visual investigation or UEBA. These will come in the future.
When to use cross-workspace Analytics Rules
There are mainly two scenarios where customer and partners can benefit from this new feature:
- When the analytics rule needs to consider data stored in multiple workspaces.
- To protect the Intellectual Property created as part of an analytics rule (MSSP scenario described later in this article)
There are other scenarios where customers and partners should not use cross-workspace rules:
- When the same rule applies to multiple individual workspaces, but data should not be considered together. As explained above, some Sentinel features will not fully function in a cross-workspace scenario and in addition it would make it more difficult to discern which workspace is the alert coming from.
Creating a cross-workspace Analytic Rule
Creating a cross-workspace rule is very easy…the only thing that changes compared to a regular rule is the query itself. In order to span multiple workspaces, you need to include the workspace and union KQL statements, adding tables from other workspaces as needed (remember the limit is 10). For example, a query to find EventID 4625 in two workspaces, would look like this:
workspace('<workspace-A>').SecurityEvent
| union workspace('<workspace-B>').SecurityEvent
| where EventID == '4625'Remember that you can also leverage KQL functions to create aliases, that make it easier for you to use multiple workspaces. For example, you could create a function named wsAB_SecurityEvent that contains:
workspace('<workspace-A>').SecurityEvent
| union workspace('<workspace-B>').SecurityEventAfter defining this function, you can just use it in your analytics rules like this:
wsAB_SecurityEvent
| where EventID == '4625'MSSP considerations
This new feature has special relevance for MSSPs as they normally manage multiple Sentinel environments spread across multiple organizations and tenants.
One of the reasons to use this feature is for example when the MSSP needs to hide the contents of the query from the end customer. In that case, the MSSP can create the query in its own tenant and Sentinel workspace but point at the customer workspace. See more information about protecting MSSPs intellectual property in this blog post.
The recommended approach for this scenario is to create analytics rules that only contain workspaces from a single customer (see diagram below). Mixing customer workspaces into a single analytics rule can lead to confusion and poor manageability.
The analytics rules in this case would contain a KQL query that doesn’t need the union statement, they would be as simple as this:
workspace('customerA_workspace').SecurityEvent
| where EventID == '4625'Get started today!
We encourage you to leverage this new feature that enhances our cross-workspace capabilities and offers more flexibility in the way you organize your SOC.
Try it out, and let us know what you think!
