Multi-Tenant Detection Operations for MSSP and MDR Providers

Brandi Moore Chief Revenue Officer

Multi-tenant detection operations is the practice of managing one source of vendor-agnostic detection logic, translated and tuned per tenant, so a book of customers running different SIEM platforms stays consistent, tunable, and reportable from a single governed source.

An MSSP running detection for dozens of tenants faces one structural question: does each customer get its own fork of every detection rule, or does a single governed source translate and tune per tenant? The answer determines operating cost, coverage reporting accuracy, and whether a change to the shared logic propagates at once or sits in a backlog of manual patches.

This page covers the detection-content layer of that model: one source of vendor-agnostic detection logic, managed centrally, translated and tuned per tenant. Hunters operates at the analytics-and-operations layer, a SOC and SIEM-alternative platform for MSSPs and MDR providers. ContraForce operates at the case-management and delivery-workflow layer, oriented to the Microsoft security stack (Microsoft Sentinel and Defender XDR). The detection-content source described here sits upstream, supplying the vendor-agnostic detection logic that execution, investigation, and reporting layers consume.

Scope: SIEM platforms (Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike). EDR as a deployment target is out of scope until per-platform support is verified.

An MSSP is also a regulated entity in its own right. Commission Implementing Regulation (EU) 2024/2690, in force since 7 November 2024, sets monitoring and logging requirements (Annex section 3.2) for managed security service providers under NIS2. The MSSP’s own evidence obligation, not only its tenants’, drives how detection content is governed and reported.

How can a multi-tenant SOC keep detection logic consistent across customer environments running different SIEM platforms?

Write detection logic once in a vendor-agnostic format (Sigma). Translate it per tenant’s SIEM. Manage the source centrally.

The shared base artifact

The base is a single detection-logic artifact. Its logic condition is evaluated against a common, normalized schema rather than against any tenant’s raw log fields. This is what makes the same rule portable across Splunk, Microsoft Sentinel, Google SecOps, Elastic, and CrowdStrike without rewriting the detection logic itself.

Normalization maps source-specific fields to that shared schema while preserving their semantics. A rule written against the normalized field auth.result means the same thing regardless of which identity provider produced the event: auth.result resolves to {success, failure, challenge} per a named semantic contract, not per whatever the customer’s IdP calls the field.

The per-tenant overlay

Each tenant gets an overlay. The overlay carries the field mapping that translates that tenant’s raw source fields into the shared normalized schema, and the tuning parameters (thresholds, time windows, noise exclusions) fitted to that tenant’s environment. Base and overlay are versioned separately.

A logic update to the base propagates to every tenant whose overlay maps the required fields. A tuning change to one tenant’s overlay touches only that tenant.

Shared versus tenant-specific

What stays shared: the detection-logic condition, the semantic contract definitions the logic depends on, the MITRE ATT&CK technique tag, and the version and change history.

What is tenant-specific: the raw-to-normalized field mapping, contract validation status at runtime (pass or fail evaluated per tenant’s actual event stream, not a static property of the rule), platform-target translation, and tuning parameters.

How do you manage detection content across dozens of customer environments without forking it per customer?

One governed artifact per detection, not a fork per customer.

Forking the rule file per customer means maintaining independent copies of what should be one governed artifact. A logic fix or a new evasion-technique update must be manually reapplied to every fork. Forks drift, and the single versioned change history disappears.

When an auditor or a customer asks who changed this rule, when, and why, the answer needs to trace to one timeline. Divergent copies that may or may not reflect the same fix leave that question unanswerable. That is a governance and change-control failure, and it directly undermines the evidence trail that auditors depend on.

The base-plus-overlay model keeps one artifact governed:

Layer	Contains	Scope
Base (shared)	Detection-logic condition, semantic/temporal/correlation contract definitions, MITRE ATT&CK technique tag, version and change history	All tenants
Overlay (per tenant)	Raw-to-normalized field mapping, platform-target translation, thresholds, time windows, noise exclusions	One tenant

One change to the base logic propagates by construction. Only the mapping and tuning stay local. This is Detection-as-Code discipline applied to multi-tenant operations: rule changes are versioned, reviewed, and tracked as code artifacts. Deployment automation carries the updated base to every tenant whose overlay supports it.

Contract versioning governs the base. Changes must be versioned, and breaking changes require a new contract ID, so every tenant gets a reconcilable upgrade path rather than a silent break.

SOC Prime works with MDRs to design detection engineering operations from SIEM detections to reducing SIEM volume with Prime Detect.

Contact Sales

How do you tune per customer without breaking the shared rule?

Tune at the overlay. The base rule stays fixed.

The overlay carries the tenant-specific configuration in two parts.

Field mapping. Each tenant’s source products name the same fact differently in the raw log, so the overlay translates those raw fields into the shared normalized schema. The mapping must independently satisfy the same semantic contract every other tenant shares.

A concrete failure shows why this matters. A tenant’s overlay maps its identity provider’s “MFA pending” outcome to the normalized value “failure” instead of “challenge.” The shared MFA-bypass detection logic, which looks for a successful login with no preceding challenge event, never sees a “challenge” value for that tenant. Every successful login flags as a bypass: a mass false positive for that one tenant, while the identical rule is correct for every other tenant whose overlay maps the enum correctly.

The rule never changed. The failure is entirely in the overlay, an overlay error masquerading as a rule bug.

Tuning parameters. Correlation time tolerances for linking related events, session-timeout and grace-period windows for authentication sequences, and noise exclusions. A tolerance set too tight misses real correlations. Set too loose, it joins unrelated events. These windows may need per-tenant adjustment for that tenant’s clock sync and latency characteristics.

The base rule’s detection-logic condition, evaluated against normalized fields, never changes for a single tenant. Contract validation status must be evaluated per tenant at runtime, not assumed from the rule or the source type.

How do I report MITRE ATT&CK detection coverage to each customer when every customer sends us different log sources?

Compute coverage per tenant against that tenant’s own prioritized technique set. Never report one library number across tenants. The full measurement method is described in the companion page on measuring MITRE ATT&CK detection coverage.

Coverage template:

Coverage (tenant) = techniques where [telemetry valid AND rule deployed AND rule proven to fire] divided by that tenant’s prioritized technique count.

When a technique counts as covered

A technique counts as covered only when all of these hold together:

Telemetry valid for this tenant. The required data source is collected, actively ingesting, passing the semantic, temporal, and correlation contracts, and meeting quality SLOs (null-rate, freshness). All of these are evaluated against this tenant’s actual event stream, not a source-type default.

Rule deployed and mapped to the technique. A Detection-as-Code inventory fact: which rule exists, which MITRE ATT&CK tag it carries, its version.

Rule has proof of firing. Fire-rate baselining, canary events, or atomic-test validation showing the rule produces alerts on real or emulated activity. A technique tag without a firing record is a label, not proof.

The denominator is that tenant’s own named, prioritized subset of ATT&CK techniques. Never the full ATT&CK matrix. Never the vendor’s rule-library size.

Reporting gap states

Report gap states distinctly, never as one collapsed number:

State	Meaning	Remediation
VALID	All gates pass, rule deployed, fired proof on file	Covered as of report date
INVALID	Required source not collected or not ingesting	Source enablement or ingestion repair
DEGRADED	Source collected but contract or quality SLO failing	Mapping, parser, or schema fix
Content gap	Telemetry valid, no rule mapped to technique	Content development

Do not collapse INVALID and DEGRADED into one “gap” number. Different failure modes require different remediations and produce different customer conversations.

Report with a date. Coverage is point-in-time.

What does content reuse do to margin and analyst training load?

Content reuse across tenants converts per-customer detection-engineering cost into a shared, amortized cost. When base detection logic is authored once and translated per tenant, the engineering cost spreads across the customer book.

Margin. Every tenant running the shared base avoids incremental detection-engineering hours. The margin improvement is structural. SOC Prime’s MDR partner program puts the saving at 4K hours per year on threat research and detection content coding.

Training load. One Detection-as-Code methodology. One normalized schema. One set of contract semantics. Analysts onboard against the shared model rather than against per-customer rule libraries with divergent naming, structure, and intent. When an analyst moves from one tenant’s queue to another, the detection logic, the schema, and the contracts are already familiar.

The honest objection. Shared detection content does not erase MSSP differentiation. Differentiation moves to tuning, response, and reporting. Tenant-specific overlays, response runbooks, and customer-facing reporting are where the MSSP’s value shows. A prospect who hears “shared content” and thinks “commodity” needs to see exactly where the custom work lives.

Regulatory driver. The MSSP’s own evidence obligation under NIS2, via Commission Implementing Regulation (EU) 2024/2690, requires monitoring and logging evidence from the MSSP itself, not only from its tenants. The shared model amortizes that evidence production.

Where this does not hold

The base-plus-overlay model assumes the base rule is written against a normalized schema that every tenant’s source product can satisfy. The model breaks under the following conditions.

Source products that do not emit required data. Different source products, or different versions of the same product, may not emit a required data component at all. No overlay fixes a structurally absent field. This is an INVALID gap, remediated by source enablement or upgrade.

Source availability. A tenant has not onboarded a required log source, or its ingestion has gone dark. The rule, mapping, and tuning may all be correct, and the affected techniques still go uncovered until the source flows again.

Correlation-tolerance mismatch. The shared default time tolerance may miss real correlations for a tenant with unusual clock sync or latency. Per-tenant tuning of correlation windows is required, not optional.

Unique threat models or data-residency constraints. A tenant with a genuinely unique threat profile may need custom detection logic the shared base does not contain. A constraint that prohibits sharing detection-logic artifacts across organizational boundaries has the same effect.

Tenant isolation is non-negotiable. The model shares detection LOGIC across tenants (rule text, contract definitions). It never shares tenant data, enrichment cache, alert state, or validation results across a tenant boundary. Any architecture where one tenant’s enrichment lookups or alert queue leaks into another’s is a priority-one incident by design. Logic sharing and data sharing are different claims.

Multi-tenant operating model checklist

Author and govern the base rule

Detection logic authored in a vendor-agnostic format (Sigma) against a normalized, contract-defined schema
Base rule separated from tenant overlay: detection logic, contract definitions, MITRE ATT&CK tag, and version history stay shared
Overlay per tenant carries field mapping, platform translation, and tuning parameters only, versioned separately from the base
Base rule changes propagate to every tenant by construction
Change history traces to one governed timeline per base rule, with overlay changes tracked per tenant
Contract versioning enforced: breaking changes carry a new contract ID

Validate mapping and platform translation

Field mappings satisfy the same semantic contract per tenant, with contract validation run at runtime against each tenant’s actual event stream
Platform translation validated per target SIEM (Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike)

Compute coverage per tenant

Coverage computed per tenant against that tenant’s prioritized ATT&CK technique set
Coverage numerator requires telemetry valid, rule deployed, and rule proven to fire, all true together
Gap states distinguished: VALID, INVALID (source missing), DEGRADED (source present, validation failing), and Content gap (telemetry valid, no rule mapped)

Tune, isolate, and report

Correlation time tolerances reviewed per tenant for clock sync and latency fit
Tuning adjusted in the overlay, never by forking the base rule
Tenant isolation enforced: no shared data, enrichment cache, alert state, or validation results across tenant boundaries
Coverage reported with a date, per tenant, never as one library number across the book
MSSP’s own regulatory evidence obligation (NIS2 Implementing Regulation 2024/2690) addressed alongside tenant obligations
Analyst training aligned to the shared Detection-as-Code methodology, normalized schema, and contract semantics

FAQ

How can a multi-tenant SOC keep detection logic consistent across customer environments running different SIEM platforms?

Write detection logic once in Sigma, a vendor-agnostic format, and translate it per tenant’s SIEM. A base-plus-overlay model keeps the shared detection logic and MITRE ATT&CK technique mapping in one governed artifact, while each tenant’s overlay carries the field mapping, platform translation, and tuning parameters for that environment. This scopes to SIEM platforms (Splunk, Microsoft Sentinel, Google SecOps, Elastic, CrowdStrike). EDR as a deployment target is out of scope until per-platform support is verified.

How do I report MITRE ATT&CK detection coverage to each customer when every customer sends us different log sources?

Compute coverage per tenant against that tenant’s own prioritized ATT&CK technique set, never as one library number across the book. A technique counts as covered only when telemetry is valid for that tenant, a rule is deployed and mapped to the technique, and the rule has proof of firing. Report four distinct gap states: VALID, INVALID (source missing), DEGRADED (source collected but validation failing), and Content gap (telemetry valid, no rule mapped). Every coverage report carries a date.

Does shared detection content erase an MSSP’s differentiation?

Shared detection content shifts where differentiation lives. The MSSP’s distinct value moves to tenant-specific tuning, response runbooks, and customer-facing coverage reporting. Tenant overlays, response playbooks, and per-tenant coverage analysis are where the MSSP’s expertise shows to each customer.

Contact Sales