| 1. Intake |
The backlog entry has a number for each of the six scoring inputs, a one-line note saying where each number came from, and a score computed from them. |
Requests arrive as nothing more than an alert name, with no note about the threat behind it, so the team builds them in the order they showed up. |
| 2. Hypothesis |
The ADS document has a one-sentence hypothesis in the form 'When an attacker does X, log source Y records Z', names the data source, and names one thing the rule cannot see. |
The hypothesis describes one tool's fingerprint. When that tool changes, the rule goes quiet. |
| 3. Research |
The behavior has been reproduced once in a test environment and the resulting log events saved as test fixtures, and the number of times it shows up during normal business has been counted over 7 days of production data. |
The 7-day count is skipped, so the first week in production is spent tuning out noise the count would have shown in advance. |
| 4. Build |
The rule file passes the lint checks, converts cleanly into every query language listed in the repository's target registry, and has at least one test event it must match and one it must ignore. |
The rule is written straight in the SIEM's own query language. It then runs on one product only, its changes cannot be compared against an approved version, and it cannot move when the SIEM changes. |
| 5. Validate |
The test events run through a real instance of every engine that has one, and each returns exactly the expected results; every converted query is identical to the approved copy, or the difference has been explained and accepted; and a second engineer has approved the change. |
Whenever the conversion output changes, someone overwrites the approved copy to match it. The comparison then never fails, and never catches anything. |
| 6. Deploy |
The rule is live with its alert action off; running it over the last 7 days returned no more alerts than the threshold recorded in score.yml; and the alert action has then been switched on. |
Alerting is switched on before the 7-day check, and the SOC pays for the noise in triage time. |
| 7. Tune |
Over the last 30 days, the share of the rule's alerts that were true positives is at or above its floor, and every tuning change went through a pull request and the validate gate. |
Tuning is done by adding exclusions in the SIEM's own interface, so the rule in the repo no longer matches the rule running in production. |
| 8. Retire |
The rule's status is set to deprecated, it is switched off in production, a retirement note records why, and any replacement has been entered at intake with a link to that note. |
Nothing is ever retired, so analysts keep triaging alerts from rules that no one owns or understands anymore. |