MON-008 Detection Content Lifecycle
Description
Detection rules are held as a managed set in which each rule records the behaviour it detects, the entry in the threat model or the recognised technique catalogue it comes from, its owner and the date it was last reviewed. Coverage of the set against that threat model is measured. Behaviours with no rule are tracked as gaps with a named owner. Rules are tuned on a defined cycle using the true-positive and false-positive outcomes of the alerts they raised. A rule that is disabled, suppressed or retired carries a recorded reason and a date on which the decision is revisited.
Rationale
Detection content decays. The threat model moves on, a noisy rule is suppressed one evening and never re-enabled, then the alert queue stays quiet for reasons nobody can name. Measuring coverage against the threat model and forcing an expiry date onto every suppression keep a quiet queue meaningful. MON-005 holds the alerting and triage that runs on this content, MON-004 the platform it runs in and APP-002 the threat model it is measured against. Issued in S4 from G-MON-1 in docs/review-canonical-quality.md section 7.3.
Applicability (9 profiles)
Framework Mappings (5)
| LOG-05 | Audit Logs Monitoring and Response | informative |
| LOG-05 | Audit Logs Monitoring and Response | informative |
| 8.16 | Monitoring activities | informative |
| AU-6 | Audit Record Review, Analysis, and Reporting | partial |
| SI-4 | System Monitoring | partial |
Evidence (3)
Detection coverage assessment mapping the rule set to the threat model or technique catalogue, naming the behaviours covered, the behaviours with no rule and the owner of each gap.
Example: Detection coverage assessment for the second half of 2026, dated 2026-08-15, mapping 214 rules to the technique catalogue and listing 19 uncovered behaviours with owners and target dates
Test: Read the coverage assessment. Verify: (1) the threat model or catalogue it measures against is named and current, (2) coverage is stated per behaviour rather than as a single percentage, (3) every uncovered behaviour has an owner and a date, (4) gaps carried over from the previous assessment either closed or carry a recorded reason, (5) the rule count in the assessment reconciles with the rule set in the platform.
Rule inventory export from the detection platform giving, per rule, the behaviour detected, its threat model or catalogue reference, its owner, its last review date and its enabled, suppressed or retired state with any expiry.
Example: Detection rule inventory export of 2026-08-18 listing rule identifier, technique reference, owner, state, last review date and suppression expiry for every rule in the production workspace
Test: Export the rule inventory. Verify: (1) every enabled rule carries a threat model or catalogue reference and a named owner, (2) every rule was reviewed within the defined cycle, (3) every suppressed or disabled rule carries a reason and a date on which the decision is revisited, (4) no suppression is past that date, (5) rules present in the platform but absent from the coverage assessment are identified.
Tuning review record for the last cycle showing the alert outcomes considered, the rules changed and the effect the change was expected to have.
Example: Detection tuning review minutes of 2026-08-04 covering the July alert outcomes, with the true-positive and false-positive counts per rule and the eleven rule changes agreed
Test: Take the tuning review record for the last cycle. Verify: (1) it uses the true-positive and false-positive outcomes of alerts actually raised rather than opinion, (2) the rules it changed match the changes visible in the rule inventory, (3) rules with a false-positive rate above the documented threshold were changed, suppressed with an expiry or accepted with a recorded reason, (4) the review happened within the defined cycle.
Questions (3)
Is the detection rule set mapped to a threat model or a recognised technique catalogue?
Mapped means each rule points at the behaviour it is there to catch and the coverage of the model can be read off the mapping. A rule set built from vendor defaults with no reference back to a threat model does not meet this.
Which of the following does the detection rule set record for each rule?
The suppression fields are the ones that decay fastest, because a rule silenced during an incident is rarely re-examined. Answer against what the platform holds, not against what the runbook says should be held.
How often are detection rules tuned using the outcomes of the alerts they raised?
Options run from strongest to weakest. Tuning means changing the rule on evidence from the queue. Disabling a noisy rule without a revisit date is suppression, which the previous question covers.