Introduction

 

Let’s consider a scenario in which a parent holding company – Contoso Group – owns two different companies – Contoso Beverages and Contoso Food – and uses a single, shared, multi-domain Entra ID tenant for all the Contoso Group companies. Contoso Group is licensing Entra ID P2 and Microsoft Defender XDR, but each company runs its own Security Operations Center, with its own SIEM (Microsoft Sentinel). While it is trivial to segregate resource logs that are specific to each company (e.g., virtual machine security events via Azure Monitor Agent, firewall logs via Diagnostic Settings, etc.), it is not that obvious how to segregate logs that come from a single, shared data source such as Entra ID or Defender XDR. For example, how to make sure Entra ID sign-in logs or Defender device events from john@contosofood.com are streamed only to the Contoso Food Sentinel workspace? If we connect all the company-specific Sentinel workspaces to the same tenant, they will all get the same data, seeing each other’s sensitive data and multiplying ingestion costs across all companies.

The following sections describe a simple, yet effective solution for this problem, leveraging Log Analytics workspace transformations and some simple KQL query statements.

 

Log Analytics workspace transformations

 

Log Analytics supports multiple options for filtering data at ingestion time, called transformations, such as data source-level Data Collection Rule transformations (for example, DCRs associated to the Azure Monitor Agent) or workspace-level transformations (applied to all the data ingested into a specific table). Transformations generally do not incur costs, except with Auxiliary Logs or with transformations that filter more than 50% of the ingestion. However, in Microsoft Sentinel workspaces, there is no limit for data that is filtered.

 

With workspace transformations, we are filtering ingestion across the entire table for that workspace, no matter what the ingesting data source is. This feature is exactly what we need to filter single, shared tenant data down to a specific company, provided the target table supports workspace transformations, which is generally the case for Entra ID audit logs and Defender XDR events (see tables that support transformations). For example, in the Contoso Food Sentinel workspace, we will ingest only sign-in logs for contosofood.com UPNs, while in the other two companies (Contoso Group and Contoso Beverages) the same strategy will be followed for their respective Sentinel workspaces.

 

 

Making it real

 

Now that we have a solution to split shared tenant logs between different companies, let’s make it real, by using some workspace transformation examples for some of the most relevant Entra ID and Defender XDR tables. Workspace transformations must be configured in the Sentinel workspace of each individual company, using as transformation filter any user or domain properties with company-specific values (for example, the company domain name).

 

Splitting sign-in logs

 

Workspace transformations are very easy to configure, as you can confirm by following the steps below for the SigninLogs table. For the other table examples in the remainder of the article, we are just providing the KQL query used for each transformation.  

 

1. Just open the Tables menu from the Log Analytics workspace tied to your Sentinel instance and type the table name you want to create a transformation for.

 

 

 

2. On the SigninLogs table row end, click on the ellipsis and on the “Create transformation” option

 

 

 

3. Workspace transformations require a workspace-wide Data Collection Rule (DCR) to be created, where all table transformations are going to be defined. Give the DCR a suggestive name and proceed to the next step.

 

 

 

4. Click on the “Transformation Editor” button and paste a query such as the below, to filter sign-in logs based on the company domain. Run the query to confirm it is filtering in records that are specific to that company. Click on “Apply” and proceed to the final step.

 

source
| where UserPrincipalName endswith "c-org01.contoso.pt" or
        SignInIdentifier endswith "c-org01.contoso.pt" or
        AlternateSignInName endswith "c-org01.contoso.pt"

 

 

 

5. After reviewing the provided data, click on the “Create” button to start filtering sign-in logs for that company.

 

Splitting other tables

 

We provide you with some transformation query examples for additional tables. For each of them, you just need to repeat the steps you followed for the SigninLogs table (reusing the same DCR).

 

AuditLogs

 

source
| where TargetResources has "c-org01.contoso.pt"

 

DeviceEvents

 

source
| where DeviceName endswith "corg1.local" or AdditionalFields.DistinguishedName contains "DC=corg1"

 

IdentityInfo

 

source
| where AccountDomain == 'corg1.local' or AccountUPN endswith "c-org01.contoso.pt"

 

For every other table you want to filter data from, you will need to first identify the properties and value conditions to be used as filters, by exploring them in the Log Analytics workspace “Logs” query pane. Once you are sure the filters are effective, you can go on to create the respective transformation.

 

Workspace transformations DCR

 

After creating all the transformations, you can confirm their configuration by opening the workspace transformations DCR JSON View from the resource overview pane in the Azure Portal, such as the example below.

 

 

 

Conclusion

 

In conclusion, Sentinel workspace data collection rules can indeed segregate logs per Sentinel instance by leveraging specific attributes from the relevant tables. This capability ensures that each organization receives only data associated with its own assets, enabling clear separation of workloads and responsibilities. As a result, every organization can confidently collect, investigate, and remediate security events within its own environment, using accurately scoped information.

 

Despite the security events segregation solution we presented in this article, it is important to highlight that not all Sentinel tables support transformations (see full list) and implementing a central security events repository for the entire tenant (covering events from all companies) is the most optimal security architecture solution, as it allows for correlating events coming from any company in scenarios in which the attacker is using an identity that does not belong to the company being impacted.