Narrow a noisy rule instead of deleting it, and prove the coverage held

short · 55 min · Objective 4.1

Task

Take a rule producing noise, exclude the specific observed cause, and then demonstrate that the narrowed rule still fires on the behaviour it was written for.

Steps

  1. Identify the noisy rule and record why it fires in lab/noise.md -- the specific process, parent, account, host and window. The investigation is the work; the exclusion is the easy part.
  2. Write the NARROWEST exclusion that removes the observed noise: this process from this parent on these hosts under this account. Record it in lab/exclusions.csv as rule,exclusion,reason,author,added,review_date.
  3. Re-run over historical data and record the new alert count.
  4. Now VALIDATE: trigger the behaviour the rule was written to catch, in a form the exclusion should not cover, and capture the alert in lab/rule-still-fires.txt.
  5. Deliberately write a BROAD exclusion instead -- by process name alone -- re-run the validation, and capture the rule failing to fire in lab/broad-exclusion-blind.txt. Then revert to the narrow one.

Verify

awk -F, 'NR>1 {n++} END {print n" exclusion(s)"}' lab/exclusions.csv
awk -F, 'NR>1 && $6=="" {n++} END {print n+0" with no review date"}' lab/exclusions.csv
test -s lab/rule-still-fires.txt && echo "narrow exclusion preserved coverage"
test -s lab/broad-exclusion-blind.txt && echo "broad exclusion demonstrated blind"

The narrow exclusion still firing on the target behaviour AND the broad one demonstrated blind to it. Every exclusion needs a review date -- zero without one. A broad exclusion by process name is an instruction for how to evade the rule.

This is an independent study companion for CompTIA SecurityX CAS-005 and is not produced by or endorsed by CompTIA.