The Validation Loop

What is it?

The validation loop turns a rule from written to trusted: hypothesize the behaviour, identify the telemetry, write the rule, run it against test events (true positives AND known-benign), review the matches, tune, and document what it does not cover.

Why it matters

An untested rule is a guess. Running it against both the attack and the benign lookalike is the only way to know it catches the first without flooding on the second.

Where you see it

A test set of normalized events: the malicious Office→-enc case (should match) and a benign signed admin -enc case (should NOT, after the filter). Iterate until both hold.

What normal looks like

A rule that matches every crafted true positive and none of the crafted benign cases, with its coverage gaps written down honestly.

What suspicious looks like

Shipping a rule that was never run against test events, or one that matches the benign case too — both mean it will misbehave in production.

How analysts investigate

Assemble a small event set with both positives and benign lookalikes, run the rule, and tune the selection/filter until it matches exactly the positives — then document the residual gaps.

Common beginner mistakes

Validating only against the attack, never against the benign lookalike.
Calling a rule 'done' the moment it is written, before any test.

Written is not done

  loop: hypothesis → telemetry → rule → TEST → tune → document
  test set:
    event A (Office → -enc)      expect: MATCH
    event B (svc-deploy → -enc)  expect: NO MATCH (filtered)
  iterate the selection/filter until both expectations hold

Validate a rule against both true positives and benign lookalikes, tuning until it matches exactly the positives.

Quick check

When is a Sigma detection actually 'done'?

A quick self-check — it doesn't affect your XP or progress.