Why Every Tenant Needs Its Own Normal

Ask an MSSP analyst which alert they trust least and you will often hear the same answer: the one that fired for every customer at once. A detection tuned for a 50-person accounting firm fires constantly at a 3,000-person manufacturer. A threshold quiet enough for the manufacturer misses the accounting firm's one bad night. Multiply that across a few dozen tenants and you arrive at the defining problem of multi-tenant security operations: there is no such thing as a global normal.

That is the idea behind the Sphere of Normalcy, the per-tenant baseline at the core of SiemCore. This post explains what it is, and why the two common alternatives, shared rules and a single global model, break down once you run security for more than one organization.

Why shared rules fail

Shared rule packs are how most multi-tenant SOCs start. Write a detection once, deploy it everywhere, tune as needed. The tuning is where it falls apart.

• One customer's incident is another customer's Tuesday. Remote PowerShell from an admin workstation is routine at a company whose IT team scripts everything, and alarming at one whose IT is a single outsourced contractor.
• Exceptions pile up. Every suppression added to quiet a rule for tenant A is either applied globally, blinding tenant B, or forked into a per-tenant copy. Soon you maintain hundreds of near-identical rules.
• Thresholds drift toward the loudest tenant. Teams tune to stop the pager, so rules end up calibrated to whichever customer generates the most noise.
• Rules describe the bad, not the normal. A rule knows what to look for. It does not know what this environment usually looks like, so it cannot tell a new-but-harmless event from a new-and-dangerous one.

Why a single global model fails too

The obvious next step is to replace rules with a model: learn normal from all the data, flag what is unusual. In a multi-tenant SOC, one model trained across every tenant has three problems.

It averages. What is normal across fifty organizations is normal for none of them in particular. Rare but legitimate behavior in one tenant, like a quarterly batch job or a sales team that signs in from three continents, looks anomalous against the global average. Behavior that is unusual for one tenant but common elsewhere looks fine.

It leaks. If tenant A's behavior shapes what the model treats as normal for tenant B, then one customer's data is influencing decisions about another. For an MSSP that is a contractual and compliance problem, not just a modeling one. Tenant isolation has to cover what the system learns, not only where the data is stored.

It cannot explain itself to a customer. When a global model calls an event unusual, the obvious follow-up, "unusual compared to what?", has no answer the customer can check.

What the Sphere of Normalcy is

The Sphere of Normalcy is a baseline built separately for each tenant, from that tenant's own data. It has four parts:

• Entities: users, devices, service accounts, applications, and network segments, and the relationships between them.
• Behaviors: how those entities normally act, including sign-in locations and times, processes and their parents, data volumes, admin activity, and peer-group patterns.
• Policies: what the organization has declared, whatever the data shows. No admin sign-ins from outside the country. No mail forwarding to external domains. Policies are explicit, and they take precedence over learned behavior.
• Escalation rules: who gets told, how fast, and through which channel, for which kinds of findings.

With that in place, SiemCore turns the usual detection question around. Instead of searching every event for signs of an attack, it asks whether the event fits this tenant's normal, and if it does, removes it. We don't look for the needle. We remove the hay. Around 99% of events match an established normal and never become work. What is left is genuinely unusual for that tenant, which is a far smaller and far more interesting set.

One event, two tenants

An illustrative example. The same event arrives for two tenants on the same morning: a service account authenticates to a file server from a subnet it has never used, at 06:00.

At the first tenant, a logistics company, the subnet belongs to a warehouse that came online last week, the service account runs the backup job, and nothing in the tenant's policies objects. The event is consistent with the tenant's recent, documented change, and it drops out as normal. At the second tenant, a law firm with one office and a network that has not changed in years, that subnet has never existed and the account has never authenticated outside its maintenance window. The same event becomes a finding.

Two different answers, both correct. Any single shared rule would have been wrong about one of them.

Learned normal is not the same as safe

The fair objection to any baseline: what if an attacker is already inside when learning starts? Their activity could become part of normal. This is why policies are declared rather than learned. A foothold that breaks a policy surfaces however long it has been there. And matching normal removes an event from the noise; it does not override a policy violation or a known-bad indicator. Normal reduces noise. It does not grant immunity.

Baselines also move with the business. A new office, an acquisition, a migration to a new SaaS tool: each changes what normal looks like. A per-tenant baseline absorbs that change for the tenant it affects, without retuning detections for everyone else.

What it means for onboarding

Per-tenant baselines sound expensive to build. In practice they are the reason onboarding is fast. A new tenant does not need its own rule pack written and tuned over weeks. It needs its data sources connected. Monitoring starts in under a day, and the baseline keeps sharpening as it sees more of the tenant's ordinary weeks. Expect the first days to surface more "new to us" findings than later ones, which is one reason every verdict carries its reasoning: analysts can see whether something is new to the baseline or genuinely out of character.

What it means for MSSPs

For a provider, the per-tenant model is what makes scale possible. Each new customer gets its own normal, its own policies, and its own escalation rules, and none of them interfere with anyone else's. Analysts stop maintaining a forest of per-customer exceptions. Customers get findings that make sense for their environment, explained against their own history. And isolation stays clean: one tenant's data never informs another tenant's verdicts.

Every organization is different, and a SOC that treats them all the same will be wrong about most of them. If you run security for multiple customers, see how per-tenant baselines fit into MSSP SOC automation.