Our SIEM's detection rule repository has become an administrative and performance liability. We currently maintain over 1,200 rules, but a recent audit suggests at least 40% are functionally obsolete—they either fire exclusively on legacy systems no longer in our environment, generate alerts for deprecated protocols, or were authored for threat actors and TTPs irrelevant to our current tech stack. The noise from these rules is degrading signal quality for the SOC and incurring unnecessary log processing and storage costs. However, the process of decommissioning them is fraught with institutional hesitation; no one wants to be responsible for retiring a rule that might, theoretically, be useful someday.
I am seeking a structured, governance-focused framework for rule retirement that moves beyond ad-hoc reviews. Our current process lacks formal criteria and leaves too much to individual analyst judgment. I am particularly interested in how others balance risk tolerance with operational hygiene.
My proposed framework includes the following stages, but I welcome critique and additions:
* **Rule Inventory & Categorization:** Beyond basic metadata, we tag each rule with attributes like: Supporting Data Source Lifecycle (e.g., "legacy perimeter firewall, decommissioned Q4 2023"), MITRE ATT&CK Tactic/Technique, and Original Author/Use Case.
* **Quantitative Analysis Phase:** A six-month review period analyzing:
* Alert volume and true/false positive rate.
* Downstream impact: How many tickets were generated? How many were closed as "informational" or "no action"?
* Cost attribution: Estimated log ingestion and storage costs triggered specifically by the rule's filters.
* **Qualitative Analysis Phase:** A quarterly review by a detection engineering committee to assess:
* Environmental Relevance: Does the rule's logic apply to our current architecture?
* Threat Intelligence Relevance: Is the rule mapped to current threat actor campaigns targeting our industry?
* Coverage Redundancy: Is the same detection coverage provided by a higher-fidelity or more performant rule?
* **Disposition Workflow:** For rules flagged for retirement, we are considering a phased approach:
1. **Disable & Monitor:** The rule is disabled but remains in the SIEM for one full business cycle (e.g., one quarter).
2. **Stakeholder Notification:** Automated notifications are sent to original authors and relevant team leads (e.g., network security, endpoint security) announcing the disablement and providing a 30-day window for objection with justification.
3. **Archive & Document:** If no objection is sustained, the rule is exported to a read-only, version-controlled archive (e.g., a git repository) with all its metadata and analysis history, then deleted from the active SIEM.
The primary point of contention internally is the "Disable & Monitor" phase. Some argue it provides a safety net, while others see it as creating a phantom inventory that undermines the cleanup effort. How have you structured this decommissioning pipeline, and what metrics do you use to justify the program's value to management beyond simply reducing alert volume? Specifically, how do you quantify the reduction in analyst cognitive load and the improvement in mean time to respond (MTTR) for legitimate incidents?