Using it at your size
The framework is eight modules that work on their own. A team adopts the ones that fix a problem it actually has, in any order, and leaves the rest. Nothing below needs the reference pipeline or a particular SIEM; the pipeline is one way to enforce the gates, not a requirement for using them.
3.1 The eight modules#
Each row names a problem detection teams recognize, what adopting the module gives back, what has to exist first, and roughly what it costs to put in place.
| Module | What it fixes | What it needs first | Effort |
|---|---|---|---|
| Detection zero, the log source silence alert | A detection cannot fire on telemetry that stopped arriving, and a silent log source looks exactly like a quiet network. | A list of log sources and their normal event rate. | An afternoon for the first source, an hour for each one after. |
| The scored backlog | Detection backlogs are longer than the team's capacity, so order is decided by whoever asked most recently. | Nothing but the candidates. Readiness needs the log source inventory to be honest. | An hour to score ten candidates once the anchors are read. |
| Countable exit gates | Stages that end on judgment ("it looks ready") cannot be reported on, so work stalls quietly between them. | Somewhere to record the count: a ticket field is enough. | One editing session on your ticket template. |
| The detection record | A detection whose intent, data sources, blind spots, and response steps live only in the author's head cannot be triaged, reviewed, or safely changed by anyone else. | A place to keep it next to the rule: a repository, a wiki page, or the rule's own description field. | Thirty minutes per detection, most of it recall. |
| Second-engineer review | A detection approved only by its author reaches production carrying the author's assumptions about the environment. | A pull request, a ticket transition, or a change record. | Twenty minutes per detection for the reviewer. |
| Retirement triggers and the precision floor | Detections leave production far less often than they enter it, so analysts spend their day triaging alerts from rules nobody owns. | Alert outcomes from the SIEM: how many alerts fired and how many were true positives. | A scheduled query per month, plus one review of the results. |
| The metric set | Detection metrics get redefined between reports, so the trend line measures the definition rather than the program. | The stages in use, plus alert outcomes for the live-side numbers. | Half a day to wire the first four; the rest as the data becomes available. |
| Detection as code, with a CI job per gate | Gates enforced by habit are skipped under deadline pressure, and nobody notices until an alert fires on a rule that was never tested. | Version control, a CI runner, and detections stored as files. | A week for the first pipeline, then minutes per detection. |
3.2 The smallest version of each#
Start at the small version and grow it only when it stops answering a question somebody is asking.
| Module | Smallest version that still works |
|---|---|
| Detection zero | One saved search per source that compares the gap since the last event against three times the median gap, with a one-hour floor. |
| The scored backlog | Score the open backlog in the spreadsheet on the downloads page. Keep the evidence line for each input; drop the weights and the presets until someone disputes the order. |
| Countable exit gates | Copy the gate column into the definition-of-done for your detection ticket type. |
| The detection record | Four sections to start: goal, ATT&CK technique, blind spots and assumptions, and response. |
| Second-engineer review | A checklist in the pull request: the fixtures pass, the query matches the approved copy, the blind spots section is filled in. |
| Retirement triggers and the precision floor | Run the floor by hand once a quarter on the ten noisiest rules. |
| The metric set | Four numbers: detections live, percent with tests, precision over 30 days, and minutes per true positive. |
| Detection as code | One job that validates the rule file and the score record on every pull request. |
3.3 Teams and roles#
The stage owners are roles, not headcount. On a one-person team every role is the same person, and the reviewer role is filled by a colleague outside detection engineering, a peer at another organization, or a 24-hour wait before you approve your own pull request.
| Team | Who holds which role | Work in progress limit | Adopt first |
|---|---|---|---|
| One engineer, detection part-time | Every stage owner is you. The reviewer is a colleague outside the team, a peer at another organization, or a 24-hour wait before you approve your own change. | One rule in flight. Two half-built detections is the failure mode at this size. | Detection zero, The scored backlog, Retirement triggers and the precision floor |
| Two to four engineers | One person holds the lead role and owns intake and the backlog order; the others rotate build and review so no rule is approved by its author. | Weekly engineering hours divided by the hours one detection takes from build through validation. Eight hours per rule until you measure your own. | The scored backlog, Countable exit gates, The detection record, Retirement triggers and the precision floor |
| Five or more, or several teams | Stage owners map to real seats. The lead owns intake and prioritization; engineers build; a rotating reviewer approves; the SOC lead co-owns tuning because the triage cost lands on their analysts. | Per engineer, not per team, so one engineer's stalled rule does not consume the team's limit. | Detection as code, The metric set, Countable exit gates, The scored backlog |
3.4 The first month#
- One engineer, detection part-time. Build the log source inventory, ship the silence alert for each source, score the backlog once, and take the top three. Track two numbers by hand: alerts per rule per day and minutes to triage one.
- Two to four engineers. Put the gates in the ticket template, score the open backlog, and run the retirement triggers against the live rule set. Expect the first pass to retire rules nobody has defended in a year.
- Five or more, or several teams. Put the framework in version control, wire one CI job per gate, and publish the metric set so the numbers in a status report are defined the same way each month.