MSSP Multi-Tenant Handling with Lighthouse and Defender XDR

1. Multi-Tenant Management in Defender XDR (The Lighthouse Evolution)

Your Question: In the case of moving to Defender XDR, how would this be possible in a multi-tenant MSSP scenario?

The Answer: You are correct that Azure Lighthouse is the foundational technology for providing delegated access. However, simply using Lighthouse to jump between different customer portals is inefficient for an MSSP.

Microsoft's solution is Microsoft Defender for MSSPs. This is a dedicated, multi-tenant management portal built on top of the Defender XDR platform.

• How it Works: An MSSP onboards their customers into this portal using Azure Lighthouse for the underlying permissions. Once onboarded, the MSSP's analysts can log into a single pane of glass (security.microsoft.com/mssp) and see a unified view of incidents, alerts, and vulnerabilities across all their customers.
• The Key Feature: It provides a multi-tenant incident queue. Analysts can see incidents from Customer A, Customer B, and Customer C all in one list. They can filter, sort, and assign incidents based on the customer tenant. This avoids the need to constantly switch contexts between different browser tabs or portals.

2. Preventing Cross-Tenant Incident Merging

Your Questions:

• Even with Lighthouse, how does Defender XDR avoid merging incidents/alerts across different customers when the same entities are involved?
• How does Defender XDR differentiate identical IOCs (same IP, hash, etc.) that appear in multiple customers?
• In Defender XDR, would these two alerts risk being merged into a single incident because the same entity is detected across tenants?

The Answer: This is the most critical point. Defender XDR's correlation engine is strictly bound by the tenant boundary.

• Tenant as a Hard Wall: Think of each customer's tenant as a completely separate, walled-off database. When the Defender XDR correlation engine runs, it operates only on the data within a single tenant.
• Your Example:
  • Customer Test 1 has a port scan from 10.10.10.10. This generates Alert A1 and contributes to Incident I1 within Customer Test 1's tenant.
  • Customer Test 2 has a port scan from the same IP 10.10.10.10. This generates Alert A2 and contributes to Incident I2 within Customer Test 2's tenant.
• No Cross-Tenant Merging: Defender XDR will never merge Incident I1 and Incident I2. The correlation logic is not aware of other tenants. The fact that the attacking IP is the same is irrelevant to the incident creation process. The TenantId is the primary key for all data, and the correlation engine respects this boundary implicitly.

In the MSSP portal, your analysts would see two separate incidents in their queue, one tagged for "Customer Test 1" and the other for "Customer Test 2." They can then choose to investigate them separately or recognize the pattern and handle them in a coordinated fashion, but the platform itself keeps them distinct.

3. Customizing Correlation Logic

Your Question: Can MSSPs customize correlation logic to prevent false cross-tenant merges?

The Answer: Since cross-tenant merges do not happen by design, there is no need to customize logic to prevent them.

However, MSSPs can and should deploy their own custom detection rules via the Advanced Hunting engine.

• How it Works: Using Lighthouse, an MSSP can deploy a custom analytic rule (a KQL query) to multiple customer tenants simultaneously.
• Tenant-Specific Execution: When that rule runs, it executes independently within each customer's tenant, against that customer's data. If the rule detects something in Customer A and Customer B, it will generate two separate alerts, one in each tenant, which will then lead to two separate incidents.

4. Content Ownership & Protecting Intellectual Property

Your Question: How is Defender XDR approaching this requirement to ensure MSSPs can operate without exposing their intellectual property (custom rules, playbooks, etc.)?

The Answer: This is a huge area of focus for Microsoft, and the solution lies in how the content is deployed and managed.

1. Deployment via Lighthouse and APIs:
   • An MSSP does not typically log into a customer's portal and manually create a custom detection rule. Instead, they use automation (like ARM templates, Terraform, or direct API calls) to deploy their proprietary content.
   • The deployment is done using the MSSP's own service principal, which has been granted delegated permissions via Lighthouse.
   • The Key: The underlying definition of the analytic rule (the KQL query, the scheduling, etc.) is stored and managed within the MSSP's own source control (e.g., a private GitHub repo). The customer does not have direct access to this source code.
2. Limited Customer Visibility:
   • While a customer with sufficient permissions could potentially view the KQL of a custom detection rule running in their environment, this access can be controlled.
   • MSSPs can use least-privilege RBAC within the customer's tenant. They can ensure that the customer's day-to-day users do not have the "Security Administrator" or "Security Reader" roles that would allow them to inspect the advanced hunting and custom detection rules.
   • The rule is deployed and managed by the MSSP's identity, not the customer's.
3. Playbooks (Logic Apps):
   • This is even more secure. An MSSP's automation playbooks (built in Logic Apps) are typically hosted in the MSSP's own Azure subscription, not the customer's.
   • The playbook is triggered by an alert from the customer's tenant, but the logic itself (the IP lookups, the enrichment, the ticketing) runs entirely within the MSSP's environment. The customer has zero visibility into the playbook's internal workings. They only see the outcome (e.g., a ticket is created, an account is disabled).

In summary: The combination of the tenant-bound correlation engine and the dedicated MSSP portal solves the data segregation and management challenges. The protection of intellectual property is achieved through automated, API-driven deployment and by hosting critical logic (like playbooks) within the MSSP's own subscription, ensuring customers cannot see the "secret sauce."

This is an opinion of mine after working 10-15 years in the Security Operation side of EDR, XDR and IR.  There is not a single scenario where you as a MSSP or partner will be looked upon with positive view if you want to call analytic rules, custom detections or similar logic as "IP's" and hide them from your customer. Specially not in the Microsoft echosystem. The value is not your custom detection, there are TONS of communities out there sharing those. Its understanding them and presenting that to the partner. You are both in it for the security. 

With that said, you have some solid questions, but analytic rules need to have custom lookups (you have to make them all custom to look in specific workspaces). the alerts/incident will only be listed under that workspace with that filter.