Detection content as code: reviewing a change the way you review software

The problem with editing rules in a console

Detection rules written directly in a security platform have no review, no history, and no test. A change to a rule that suppresses a noisy alert is made because an analyst was paged at night, and the effect on coverage is discovered months later when the technique it caught appears in an incident.
Treating detection content as code addresses this, not because source control is fashionable but because review, history, and testing are the mechanisms that keep coverage from eroding silently.

What the workflow needs

A repository holding the rule content in a plain format, with the platform loading from it rather than the other way around. Sigma rules compile into several query languages and give a portable intermediate representation, which avoids locking detection logic to one product's syntax.
A review step that asks two questions. Does the rule detect what the description claims, and what does it stop detecting. The second question is the one that is usually skipped, and it is where coverage is lost.
Automated validation before merge. Syntax checks are the minimum. A rule set can also be run against a corpus of recorded events to confirm it fires on known-bad samples and stays quiet on baseline traffic.

Handling suppressions honestly

Suppression is the mechanism that most often erodes coverage, so it needs the strictest treatment. A suppression should name the specific alert, the specific source or account it applies to, the reason, and an expiry date. A suppressions file with an expiry column makes stale entries visible; a console exception list does not.
Where a rule is disabled outright, record the technique it covered and who accepted the resulting gap. That record is what turns an undocumented gap into an accepted risk decision.

Testing with real material

The strongest validation uses events the team already has. Replay a working directory of recorded telemetry against the rule set and compare alerts before and after the change. This catches the rule that no longer fires because a log field was renamed, which syntax validation cannot see.
For rules that should fire, keep a small set of known-bad samples with the expected result. A rule that has never fired in production is untested, and the test corpus is how you find out whether it can fire at all.

Measuring drift

Track rule count, technique coverage, and the number of active suppressions over time. Coverage that shrinks while the environment grows is the signal that detection is losing ground, and it is easier to see in a repository with history than in a console without one.

References

• Sigma, generic signature format for SIEM systems: https://github.com/SigmaHQ/sigma
• MITRE ATT&CK: https://attack.mitre.org/
• NIST SP 800-61 Rev. 2, Incident Handling Guide: https://csrc.nist.gov/pubs/sp/800/61/r2/final