How should teams balance static rules and enrichment baselines?

Static rules handle the obvious, baselines handle the contextual

static rules are the right choice when the behaviour is clearly unacceptable on its face: a policy violation, an impossible action, or a known bad pattern that should always trigger. Baselines are better when the same action may be legitimate in one context and suspicious in another, because the signal depends on history, identity, role, workload, or environment.

The practical test is whether the detection logic should be stable across every subject, or whether it should learn what normal looks like for each subject and look for meaningful deviation. Static logic gives certainty and consistency; baselines give sensitivity to drift, rare abuse, and low-and-slow behaviour that rule sets often miss.

A strong programme usually treats static and baseline detections as different layers of control rather than competing options. The static layer catches universal violations quickly, while the baseline layer adds context where rigid rules would create too much noise or miss subtle misuse.

Where each approach is strongest

Static detections work best when the event itself is sufficiently informative. Examples include disallowed protocols, known forbidden destinations, policy-breaching privilege use, or activity that should never happen in any normal operating mode. Because the condition is explicit, the rule can be tested, audited, and explained with little ambiguity.

Baselines work best when the important question is not “did this happen?” but “does this look normal for this identity or system over time?” That matters for access patterns, authentication behaviour, request volume, data access timing, or operational usage that varies by team, role, geography, or seasonality. A useful baseline is usually narrow enough to be meaningful, but broad enough to avoid flagging every routine fluctuation.

CIS Benchmarks are a good example of where static expectations help most, because they define hardening baselines that can be checked deterministically against known configuration requirements. That makes them strong for compliance-style validation and weak only where behaviour must be interpreted in context.

How to tune the mix without losing signal

Use static rules for the controls that must remain invariant, then reserve baselines for behaviours that are legitimate but variable. If a rule produces repeated exceptions for normal work, it probably belongs in the baseline layer. If a baseline keeps missing events that are always unacceptable, promote those events into static detection.

Teams should also be careful not to overfit baselines to a short observation window. A baseline built on incomplete history can normalise rare abuse, recent compromise activity, or one-off operational changes. The more critical the asset or identity, the more important it is to validate whether the baseline reflects real normal behaviour or only recent noise.

Static and baseline logic should feed different response paths. Static violations often justify immediate blocking, while baseline anomalies often justify triage, corroboration, and correlation with other signals before action. That division helps avoid alert fatigue without delaying response to clear-cut policy breaks.

Practitioner Guidance

What to prioritise: Put your unambiguous policy breaks, forbidden configurations, and known-bad event patterns into static detections first, then use baselines where context is essential to distinguish ordinary variation from abuse. If a detection depends on comparing one actor against its own history, it usually belongs in the baseline layer.

What to verify: Check that every baseline has a clear scope, a defined review cadence, and an explicit plan for model drift or business change. If the baseline cannot be explained to an operator in plain language, it will be hard to trust when it matters.

Common mistake: Teams often try to force one method to do both jobs. Static rules become noisy when they are asked to understand context, and baselines become unreliable when they are asked to encode absolute policy.

Practitioner takeaway: The best balance is not equal use of both methods, it is assigning each to the kind of truth it can express most reliably, absolute violation for static rules, and contextual abnormality for baselines.

Related resources from NHI Mgmt Group

• How should teams use static analysis rules to balance code quality with development speed?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?