Project 2 · DetectFlow
Detection at scale, without the operational debt
Most detection programs cap out at hundreds of rules, not because the threats stopped multiplying, but because the operational debt of maintaining the rules ate the team alive. DetectFlow is the discipline that lets a SOC carry thousands. Detection-as-code, CI/CD pipelines for detection content, telemetry feedback loops, automated regression testing. Each rule is a versioned, tested, deployable artifact whose performance and false-positive rate are continuously measured.
The debt problem
The detection backlog grows; the team doesn't.
Every SOC of meaningful size hits the same wall. Year one of the program, 50 detections, freshly tuned, owned by an engineer who knows each one's quirks. Year three, 350 detections, half of them somebody-else-wrote-it, false-positive rates drifting because telemetry shapes shifted but the suppressions didn't follow. Year five, a backlog of 800 detections in the queue, and analysts spending more time tuning existing rules than hunting for what the existing rules don't catch. Detection engineering velocity has collapsed; the team is in maintenance mode permanently.
The mechanism is structural. Detection content is treated as artisanal. Each rule is a craft item with an implicit owner, an implicit test (somebody ran it once and it caught the simulated attack), and an implicit suppression list (the suppressions that accumulate over time as false positives surface in production). When the implicit test breaks because the underlying telemetry changed, nobody notices for weeks. When the implicit owner leaves, the rule becomes nobody's responsibility. The maintenance cost compounds with rule count, but the team headcount doesn't.
The fix isn't more rule writers. It's treating detection content as software: versioned, tested, deployed through CI/CD, monitored with telemetry feedback loops, owned by a system rather than an individual. That's DetectFlow.
Detection-as-code
Each rule is a versioned, tested, deployable artifact.
Versioning.
Detection content lives in source control alongside the rest of the security engineering codebase. Each rule is a file with a defined schema (query language, MITRE ATT&CK technique mapping, suppression logic, expected false-positive rate, owner, last review date). Pull requests carry tests; merges deploy automatically. Rollbacks are git-revert. The concepts are mundane in any other discipline; the absence in detection engineering is the surprise.
Testing.
Every rule ships with two test types. Positive tests are synthetic events or replayed historical telemetry that the rule should fire on, asserted on every commit. Negative tests are events known to be benign that the rule should not fire on, asserted on every commit. Both run in CI before merge; failures block. The discipline catches regressions early. When the underlying telemetry shape shifts and a rule stops matching, the negative-test suite or the positive-test suite breaks loudly, before the rule silently degrades in production.
Deployment.
Approved rules deploy through a CI/CD pipeline. Canary stage runs the rule against production telemetry with alerting suppressed for 24–48 hours, surfacing the actual false-positive rate before any analyst sees the alerts. Promotion to active stage requires the canary metrics to satisfy the rule's defined false-positive threshold. Demotion is automatic if the false-positive rate exceeds threshold for 72 hours consecutively. The rule lifecycle is governed by metrics, not by tribal memory.
Telemetry feedback.
Every rule's production performance is measured continuously. Alert volume, true-positive rate (validated via incident retros), false-positive rate (analyst-marked dispositions), suppression-pattern drift, coverage overlap with other rules. The data shows up in dashboards with trend lines per rule, and feeds back into the rule metadata as input to the next review cycle. Rules that have drifted from their committed false-positive thresholds get flagged for re-tuning automatically; rules that haven't fired in months get flagged for coverage review. The detection program runs on metrics, not on the analyst-team's collective memory of what each rule was supposed to do. The honest ceiling on all of this automation is worth stating plainly, because it calibrates the pitch: even a mature program tops out around 30 to 40 percent of investigations handled end to end, which is the figure one MDR provider reports for its own operation (vendor-reported, Tier C, walked through in the agentic SOC essay), not the near-total automation vendor decks imply, and measuring what your detections actually cover is how you find out where your program sits on that curve.
Coverage
MITRE ATT&CK and D3FEND, mapped explicitly.
Detection content gets organized by MITRE ATT&CK technique, with D3FEND defensive-technique mapping layered on top. The two frameworks together produce the coverage heatmap. Which techniques the program actually detects, which it nominally covers but with weak rules, which it doesn't cover at all. The heatmap drives the prioritization conversation in incident retros and detection roadmap reviews; it replaces the more common "we have 350 detections" headline that treats every detection as equivalent in value.
The coverage view also exposes overlap. Five rules detecting the same technique with subtly different logic isn't five-times-coverage; it's a maintenance multiplier with marginal extra detection. The framework's coverage analysis exposes these overlaps and forces the consolidation conversation. What's actually still in use, what's deprecated, what's the rationalized rule that replaces three. Without that analysis, the rule count grows without the coverage growing.
The heatmap also has to be checked against what actually fires, because a mapped technique is not a detected one. When I planted eight ATT&CK techniques into synthetic telemetry projected to OCSF and ran Sigma rules over it, three were detected cleanly, and the RDP lateral-movement rule caught its planted event inside 2,960 matches, a precision of 0.0003, while the four techniques the bench had no scored rule for missed by construction, all of them still marked covered on the D3FEND Wall (Where mapped and fired disagree, Tier B, synthetic).
Platform-agnostic
Detection content that survives the platform decision.
Single-event detection content written as Sigma rules ports across backends, because one rule compiles through the pySigma backends to SPL, KQL or the SQL of the engines documented on the components page. Detections written natively in SPL (Splunk's query language) or KQL (Microsoft Sentinel's) don't port; they're vendor-specific, and content written in them is content the next migration has to rewrite, and Chronicle's YARA-L is its own dialect with similar problems. Correlation and stateful detections are the bounded part, written either in engine SQL or as Sigma correlation rules whose backend support is still uneven, so they get budgeted as engine-specific work. The choice of detection-content language is a multi-year commitment, and Sigma for the atomic layer is the part that travels.
The DetectFlow method works with content in SPL, KQL, YARA-L, Trino SQL, and Dremio SQL, whichever the existing platform uses. The migration path from SPL or KQL to Sigma and engine SQL is part of the work when the underlying platform is moving (typically alongside a MOAR migration). For shops staying on Splunk or Sentinel, the method shapes the existing platform's content rather than forcing a rewrite. The discipline applies regardless of language.
The harder migration question is the SPL-specific patterns that don't have direct SQL analogs. Transactional event-grouping logic, certain `eval` and `streamstats` patterns, vendor-specific data model assumptions. The method quantifies the rewrite cost up front; some content survives the migration cleanly, some requires redesign, some should stay on the source platform with federated query as the bridge. The portability claim has conditions, and naming them up front is part of the method.
When to pick it
Three patterns that signal DetectFlow is the next investment.
Three signals point to DetectFlow as the next investment:
- The detection backlog grows faster than the team can maintain. The classic shape: new threats land in the threat-intelligence feed, the team writes detections for them, the existing detections drift in maintenance mode, and the velocity drops every quarter even though the headcount is stable.
- Analyst time is consumed by tuning rather than hunting. When the senior analysts spend their week chasing false positives in existing rules instead of investigating novel patterns, the program has flipped from offense to defense at the wrong layer.
- Incident retros surface detections that should have fired and didn't. The rule existed; the rule didn't catch the incident. Either the underlying telemetry shifted and the rule silently broke, or the rule's logic missed a variant that an attacker found. Both are failure modes DetectFlow's testing and telemetry feedback specifically catch.
DetectFlow doesn't replace detection engineers; it makes detection engineering scalable. The work is structurally complementary to the MOAR work. The data platform that supports detection-content portability is the same data platform that supports the testing and telemetry-feedback infrastructure DetectFlow runs on. The two often ship together when the migration scope warrants it.
The engagement shape
Detection Engineering Modernization, as it was offered.
Detection Engineering Modernization (4–8 weeks). The full DetectFlow engagement as it was scoped before the pause, kept here as a record and as a checklist a team can run on its own program. The deliverables:
- Maturity assessment. Defined → Managed → Optimized framework, mapped against the existing program. Not aspirational; based on the artifacts the program produces today.
- 100–200 use cases organized by MITRE ATT&CK technique. The starting catalog; production environments add to it from there.
- D3FEND defensive-technique mapping. Layered on top of the ATT&CK coverage to produce the dual-framework heatmap.
- Platform-agnostic detection content. Authored in the existing platform's language; portability framework documented for future migrations.
- Coverage gap heatmap. What the program detects, what it nominally covers but with weak rules, what it doesn't cover at all. Drives the prioritization conversation for the next quarter.
- Tuning playbook for false-positive reduction. The patterns that recur across SOCs, encoded as repeatable steps the team can apply without consulting calls.
Strong synergy with MOAR. It was designed as a follow-on once the architecture decision has settled; the data platform gets built, then the detection program runs on it. For shops staying on Splunk or Sentinel, the DetectFlow work runs against the existing platform without requiring a platform migration first.
Detection content treated as software, not as craft.
MOAR is the data platform. MLOps-hunting is the next layer. DetectFlow is the discipline that makes both operationally tractable.