Postures, Overrides, and Disabled Rules

Three nested controls govern how much signal vs noise Burrow produces: the detection posture (one setting that adjusts everything), per-rule overrides (single-rule custom thresholds), and the disabled rules list (heavy-hammer kill switches). This article walks each lever, when to reach for which, and how they interact.

For one-user noise problems, see Entity exceptions — that's a fourth lever, scoped to specific users rather than entire rules.

The three levers, in order of blast radius

Lever 1 — Detection posture (whole-system)

The detection posture is a single dropdown on the Rules page that sets the noise-vs-sensitivity baseline for every rule at once. Five postures ship, from least to most sensitive:

Posture	Profile	Typical use
Permissive	Catches only the obvious — large bytes, mass operations. Roughly 50% lower volume than Balanced.	Trial deployments, very small SOC team.
Relaxed	One step below Balanced. Roughly 25% lower volume.	Established tenants where Balanced was too noisy after exceptions.
Balanced (default)	Tuned for typical mid-size tenants.	Default starting point.
Strict	One step above Balanced. Roughly 50% higher volume.	Mature SOC teams that want more signal coverage.
Paranoid	Catches small movements early. Roughly 3x volume vs Balanced.	High-risk tenants, post-incident hardening.

How to change it: Rules page → Detection posture dropdown → pick → Save. Every rule's posture-default thresholds shift on the next detection pass.

Blast radius: every rule affected simultaneously. Per-rule overrides still win over the new posture.

Lever 2 — Per-rule override (rule-wide)

When a single rule is consistently too noisy or too quiet for your environment but the rest are fine, override that one rule's threshold without changing the posture.

How to do it: Rules page → expand the rule's accordion → set a custom value → Save. The override wins over the posture preset for that rule on every user.

Blast radius: the rule applies the new threshold to every user. If the override is misconfigured, that rule produces no alerts (or far too many) until you reset.

Reverting: Rules page → reset to posture default, or remove the value from the override.

Lever 3 — Disabled rules (kill switch)

The Disabled rules list on the Rules page globally turns rules off. No alerts are generated for any user in that category.

Use sparingly. Disabling a rule blinds you to a class of attack across your entire tenant. The two cases where it is legitimate:

• The rule does not apply. Example: you have no MIP labelling rollout, so the rules that gate on labelled-file activity will never produce useful signal.
• A category is fundamentally too noisy in your environment even after posture and override tuning, and the cost of running it outweighs the value.

For one-user noise — even a chronically-noisy service account — use an entity exception instead. The exception is scoped; the disable is global.

How the three levers interact

Burrow evaluates the lever chain in this order:

1. Is the rule disabled? No alert generated, ever.
2. Is there a per-rule override for the threshold? Use the override value.
3. Otherwise use the threshold defined by the current detection posture.

Per-user-and-category suppression via entity exceptions happens later in the pipeline — after the alert is generated, before the email step decides what to send.

When to use which

Symptom	Reach for
One user / service account is noisy in one or many categories	Entity exception
One specific rule is noisy across many users	Per-rule override (raise threshold)
Many rules are too noisy across the board	Posture change (Strict to Balanced, or Balanced to Relaxed)
A rule fundamentally does not apply to your tenant	Disabled rules

A typical tuning workflow

1. Start at Balanced. Run for 2 weeks.
2. Review the Suggestions panel at the top of the Rules page. Apply suggestions that match your environment.
3. For repeated noise from specific users, add entity exceptions.
4. For repeated noise from a specific rule category, add a per-rule override.
5. If overall volume is still too high, shift to Relaxed. If too low, shift to Strict.
6. Use Rule replay before committing a posture or threshold change to preview the effect over the last 24 hours of activity.

What NOT to do

• Do not disable a rule to silence a single user. Use an exception. Disabling blinds the whole tenant to that class of attack.
• Do not raise a threshold past the next posture's default. If you are routinely setting Balanced thresholds to Permissive levels, just change the posture.
• Do not tune away the UEBA family. The baseline-deviation rules catch things deterministic rules miss. If they are noisy, raise the minimum baseline-maturity gate rather than disabling.
• Do not make changes without a reason text on exceptions. Future-you, looking at the History page, will thank present-you.

Every change you make through the Rules page is logged on the History page with timestamp, your operator identity, and a before / after diff — so undoing a change is a one-click affair from the History entry.

See also

• Tuning a noisy rule — with the Suggestions panel.
• Entity exceptions — per-user noise control.
• Rule replay — preview a tuning change.
• Rule catalog — the full per-rule reference.

---

Need help? support@smikar.com.