Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
What’s New: Cross-workspace Analytics Rules
Published Sep 14 2020 07:14 AM 14.8K Views
Microsoft

(Updated Feb 9th 2021)

 

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:

 

cross-ws architecture.png

 

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! :smile:

 

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:

 

Picture2.png

 

This can also be used in a multi-tenant setup (using Azure Lighthouse) like shown here:

 

Picture3.png

 

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 20 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>').SecurityEvent

 

 

 

 

 

 

After 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.

 

Picture4.png

 

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!

16 Comments
Copper Contributor

Hello @Javier Soriano,

That's what we need as a MSSP Provider. Sentinel is growing so fast, congratulations to all community.

Copper Contributor

Thanks good article, and a long awaited feature.  In one place it says "You can include a maximum of 10 workspaces in each detection."    And in another section it says "(remember the limit is 15)".   Which is it?    And is that a temporary limit that is likely to be increased soon?  A typical MSSP wouldn't want to be capped at 10-15 customers..

 

Thanks!

Microsoft

Good catch @Mark-Resnik . The limit is 10 right now. Remember that you don't want to create a rule that is spanning more than 1 customer. That would make management very complex. 

 

Regards

Thank you @Javier Soriano  for delivering this important feature!
Is there any new features that will be annonced suring Microsoft Ignite next week?

Microsoft

Of course! Stay tuned next week for announcements :smile:

Copper Contributor

Hello.

In an MSSP environment with many customers on-boarded to a central MSSP Tenant (using Lighthouse), instead of having different rules for every customer (your picture under MSSP considerations) in the central Tenant, maybe it would be better we have a single cross-workspace analytic rule for all the on-boarded customers in the central Tenant and in some point have the ability to "aggregate" the name of the customer or the customer's workspace name in the produced alert? As far i have seen and despite the fact that the query is cross-workspace, the produced alert includes only the workspace name where the analytic rule was created.

 

I am thinking about a scenario where a SOC has already developed 50 use cases (analytic rules) in a central MSSP Tenant for one customer and in the near future 10 additional customers will be on-boarded to that Tenant through Lighthouse. So the SOC will need 50X10=500 different analytic rules in order to query all the customers' workspaces through a single Tenant

 

Regards,

Microsoft

HI @gregoval , having multiple customers in a single analytics rule can be tricky. For example, there could be several events coming from different customers that are grouped into a single alert, and a single incident. That would raise a single incident with entities from different customers mixed. 

 

Having many rules shouldn't be a concern if you manage them through automation via CI/CD or automation via API/Powershell.

 

Regards

Copper Contributor

Thanks Javier.   I get the complexity added by doing a single rule that spans multiple customers.  Though even with DevOps can be complex managing the same rule across multiple customers.  Either you have a copy for every customer which can mean editing a copy per customer for a one minor edit to one KQL query; or you write some pretty complex DevOps code to push a single rule multiple ways based on the details of that customer/workspace.  Something to consider..

 

But what about rules other than the "Scheduled" rules, like the Fusion rule, ML rules, or the Microsoft Security rules such as the one that promotes ASC alerts to Sentinel incidents.  How would I generate Sentinel incidents for these in my Sentinel that my SOC monitors, based on these types of rules?  I don't want to rely on these rules being in the customer Sentinel as I have no control over that Sentinel and the customer may or may not be poking around in their Sentinel with rules and incidents of their own.

 

Thanks, Mark

Microsoft

Hi @Mark-Resnik , keep in mind the two use cases that I put in the article on when to use cross-workspace analytics rules (when you need to consider data from multiple workspaces together or to protect intellectual property). In the case of Microsoft, ML or Fusion rules, are Microsoft's IP and it doesn't make much sense to do this aggregating data multiple customers, right? At the end, each customer will have their own Microsoft 365 Defender products and the alerts related to them. I can't see a case where a Fusion or ML Behavior Analytics rule would need to be applied to multiple customers, but let me know if you see a use case there...

 

Thanks

Copper Contributor

Javier,  multiple workspace doesn't always mean multiple "customers".  Can mean different business units or different countries/regions within the bigger organization.  So yeah, I think correlation and fusion/ML across all data is still interesting for a global SOC.  As are things like alerts from ASC getting into the Sentinel mix.  Also, its about monitoring.  If a customer/BU/country wants us to do the first level security monitoring we'd ideally have all the relevant rules and incidents in our Sentinel, not just the ones from scheduled rules.  In some cases the customer/BU/country may have fully outsourced security monitoring and have no rules/incidents in their own Sentinel, or in some cases they may have some local rules/incidents that they manage/monitor different from what the MSSP/global SOC provides.

 

Thanks

Microsoft

Thanks @Mark-Resnik . If you are in the context of a single tenant, then yes, I would enable 1st party connectors in the central SOC workspace and define the Microsoft rules there. These wouldn't benefit from cross-workspace correlation as you ingest the logs for the whole tenant in a single workspace.

 

As for Fusion/ML Behavior Analytics rules, not sure if there would be benefits to correlating data from different workspaces. For example, Fusion uses mostly MCAS and Identity Protection sources for now, so it would only make sense to enable that rule in the tenant where those logs are being sent, and this should be a single workspace. It is true that it also supports PaloAlto/MDATP logs for a couple of detections, and it that case I agree that correlation would be beneficial. For ML Behavior Analytics, it is based on syslog from individual machines, so I don't think correlation across workspaces would be needed and the recommendation would be to enable on every workspace where syslog is being collected as instructed here: https://docs.microsoft.com/en-us/azure/sentinel/connect-syslog?WT.mc_id=Portal-fx#configure-the-sysl...

 

Adding @Koby Koren and @Sharon Xia for visibility

Copper Contributor

Hi Javier, 

 

thank you for the article,

in regards to multi-workspace implementation, if we wanted to automate threat hunting searches in multiple tables, across 20-30 workspaces using Logic Apps, is it doable? 
or has anyone implemented different solution ? 

thank you

Microsoft

Hi @jasonkasih , why would you want to use logic apps for that? You can use our hunting experience within Sentinel that also supports cross-workspace queries. 

 

I think that Logic App connector would also support multi-workspace, but haven't tried it.

 

Regards

Copper Contributor

Do you actually need a “sentinel” workspace at the customer’s tenant, or is running analytics workspace enough?

Customers won’t have cases or anything running from their tenant, everything like analytics, playbooks and workspaces will be living within the master tenant 

Microsoft

Yes, you need the Azure Sentinel solution installed in both source and target workspaces in order to use cross-workspace analytics rules.

 

Remember that only rules that require intellectual property protection should be created in the central tenant, for the rest use the customer workspace. For more information about MSSP scenarios like this you can visit http://aka.ms/azsentinelmssp 

 

Regards

Copper Contributor

Earlier in the article you mention 20 workspace limit, then further down the limit is 10

Co-Authors
Version history
Last update:
‎Feb 09 2021 07:02 AM
Updated by: