Building a Detection Engineering Practice

Most security operations centers still run on a triage model built for a world of static signatures and quiet log volumes — a world that no longer exists. The fix is not another dashboard or a bigger analyst roster; it is a disciplined detection engineering practice that treats detections as versioned software, staffs for engineering rather than queue-clearing, and measures itself on coverage and precision instead of tickets closed.

Why the SOC operating model is breaking

The classic three-tier SOC — Tier 1 triages, Tier 2 investigates, Tier 3 hunts and tunes — was designed around a scarcity assumption: alert volume was low enough that a human could look at every event, and the rules generating those alerts changed slowly enough that a quarterly tuning cycle was adequate. Neither assumption survives contact with a modern environment. A mid-sized enterprise now ingests tens of thousands of events per second across cloud control planes, SaaS audit logs, identity providers, EDR telemetry, and network sensors. Attackers increasingly live off the land, chain legitimate administrative tools, and rotate infrastructure faster than a signature vendor can publish an update. The result is the well-documented pathology of modern SOCs: alert fatigue, high analyst turnover, and a detection backlog that grows even as headcount grows.

Detection engineering is the answer the industry converged on over the past several years, but the term is frequently misapplied to mean “the person who writes SIEM rules.” That is necessary but insufficient. A real detection engineering practice is an operating model: a lifecycle for producing detections, a data platform that makes detections cheap to write and validate, a set of roles with clear ownership, and metrics that tell you whether the practice is actually reducing risk. This article lays out that operating model end to end — how to structure the team, how to run the detection lifecycle as code, what to measure, and how to fold in the agentic AI capabilities that are now reshaping what a SOC analyst's day looks like.

The urgency is not academic. Dwell time statistics from incident response engagements consistently show that the gap between initial access and detection is measured in days, not minutes, for organizations without a mature detection practice, while organizations with detection engineering programs and automated triage routinely compress that to hours. The difference is not better analysts working harder; it is a fundamentally different production pipeline for detection logic, paired with automation that removes human bottlenecks from the parts of the workflow that do not require human judgment.

From alert triage to detection engineering

The mental model shift is best understood as a change in the unit of work. In a triage-centric SOC, the unit of work is the alert: an analyst opens a queue, works a ticket, closes it, and moves to the next. In an engineering-centric SOC, the unit of work is the detection: a versioned artifact with a defined purpose, a test suite, a deployment history, and an owner who is accountable for its precision and recall over time. Alerts still get triaged — someone has to respond when a detection fires — but triage becomes a downstream consequence of engineering quality, not the primary activity that defines the team.

This reframing has several practical consequences. First, false positive rates stop being an analyst problem and become an engineering defect. If a detection generates 200 alerts a week and 195 are benign, that is a bug in the detection, not a training gap in the analyst who has to close them. Second, detection coverage becomes a measurable, plannable asset rather than an emergent byproduct of whatever the SIEM vendor ships out of the box. Third, the SOC's relationship to the rest of the security organization changes: detection engineers work upstream with threat intelligence, red/purple teams, and vulnerability management to decide what to build next, rather than reactively writing rules after an incident review says “we should have caught that.”

None of this eliminates the need for human analysts. It changes what they spend their time on. A well-run detection engineering practice pushes the repetitive, high-volume, low-judgment work — enrichment, correlation, initial verdict on commodity alerts — onto automation and AI agents, and reserves human attention for the alerts and investigations that genuinely require judgment: ambiguous intent, novel techniques, and decisions with material business consequences. This is the operating premise behind the agentic SOC model: AI agents handle the first pass of triage, enrichment, and correlation at machine speed, and humans supervise, adjudicate edge cases, and own the engineering backlog that keeps detections sharp.

Roles and org design for a modern detection team

Org design for detection engineering fails most often because organizations try to bolt the function onto the existing tiered SOC without redefining reporting lines, career ladders, or success metrics. A durable structure separates four functions, which can be four people or four hats depending on team size, but which must be functionally distinct even in a small team:

• Detection engineers own the detection content lifecycle: writing, testing, tuning, and retiring detection logic. They are measured on coverage against a threat model and on the precision/recall of what they ship, not on how many detections they produce.
• Threat hunters operate hypothesis-driven, unstructured investigation against raw telemetry to find gaps that existing detections miss. Their output feeds the detection engineering backlog — a good hunt that finds nothing suspicious but confirms a detection gap is just as valuable as one that finds an active intrusion.
• SOC analysts (response tier) handle the alerts that automation escalates, own incident response execution, and are the human-in-the-loop for containment decisions. In a mature practice this tier shrinks in headcount but grows in seniority, because the low-judgment work has been automated away.
• Automation/platform engineers build and maintain the pipelines, playbooks, and integrations that let detections actually execute — ingestion, enrichment, SOAR playbooks, and the agent orchestration layer. This role is frequently underinvested in, and its absence is the single most common reason detection engineering programs stall: engineers write great detections that never get automated response paths, so every alert still ends up as a manual ticket.

Reporting structure matters more than title. Detection engineers should not report through the same manager as the Tier 1 triage queue if that manager is incentivized on queue-clearing SLAs, because that creates a structural conflict: the fastest way to hit a triage SLA is to suppress noisy detections rather than fix them, which is exactly the wrong instinct for an engineering function. The cleanest pattern places detection engineering and threat hunting under a single detection and threat intelligence lead, with a separate operations lead owning the response tier and shift coverage, both rolling up to the SOC director. This also creates a natural escalation path: hunters find gaps, engineers close them, operations validates them in production.

Staffing ratios vary by organization size and telemetry volume, but a workable starting ratio for a mid-sized enterprise (5,000–15,000 endpoints, multi-cloud) is roughly one detection engineer per 3–4 response analysts, and one threat hunter per 8–10 response analysts, with automation engineering scaled to the number of active integrations rather than headcount. Smaller organizations should resist the temptation to skip detection engineering entirely and outsource it to the SIEM or XDR vendor's default content — vendor-shipped rules are a starting point, not a substitute for tuning against your own environment and threat model.

The detection lifecycle: a concrete workflow

A detection is not done when it is written; it is done when it has survived contact with production traffic and has an owner accountable for its continued accuracy. The lifecycle below is the one we recommend building into tooling and process, regardless of which SIEM or XDR platform sits underneath it.

1. Hypothesize

Every detection should trace back to a specific adversary behavior, mapped to a framework such as MITRE ATT&CK, and to a specific data source that can observe it. The hypothesis stage forces the question: “what technique are we trying to catch, and do we actually have telemetry that would show it?” Detections written without this step tend to either duplicate existing coverage or target a technique the organization has no visibility into — both are wasted engineering effort. Feed this stage from three inputs: threat intelligence relevant to your industry and geography, red/purple team findings, and gaps surfaced by threat hunting.

2. Engineer

Write the detection logic in a portable, testable format — Sigma is the de facto standard for cross-platform detection-as-code, with platform-specific query languages (KQL, SPL, EQL, or your SIEM's native language) as compile targets. Define the expected true-positive test cases and, critically, the expected false-positive scenarios up front. A detection engineer who cannot articulate what will make this rule fire on legitimate activity has not finished the design.

3. Validate

Run the detection against historical data (retrohunt) before it ever goes live. This single step eliminates the majority of “shipped a rule that immediately floods the queue” incidents. Validation should include a purple team exercise for anything mapped to a high-priority technique — have red team or an attack simulation tool actually execute the technique in a controlled environment and confirm the detection fires, rather than trusting that the logic is theoretically correct.

4. Deploy with a tuning window

New detections should ship in a monitor-only or low-severity mode for a defined tuning window (typically 1–2 weeks depending on data volume) before being promoted to an alert-generating, response-triggering severity. During this window, every fire is reviewed by the owning engineer, not routed to the response queue. This is the step organizations skip most often under deadline pressure, and it is the single biggest driver of alert fatigue when skipped.

5. Operate and tune

Once promoted, the detection enters steady-state operation with a defined owner, a documented runbook for responders, and a feedback loop: every false positive gets logged against the detection, and a threshold (for example, more than 3 false positives in 30 days, or a precision below 80%) triggers mandatory re-tuning or demotion back to monitor-only.

6. Retire

Detections decay. Environments change, tools get decommissioned, attacker techniques evolve past what the logic catches. A detection that has not fired a true positive in 12–18 months and maps to a technique that is now covered by a more general detection should be retired, not left running to generate maintenance overhead and dashboard noise. Treat detection retirement with the same rigor as detection creation — document why, and confirm no coverage gap opens as a result.

Detection-as-code: repos, CI/CD, and testing

Every mature detection engineering practice we have seen converges on the same infrastructure pattern, borrowed directly from software engineering: detections live in a version-controlled repository, not in a SIEM's web UI. This is not a stylistic preference — it is what makes the lifecycle in the previous section actually enforceable.

The practical architecture looks like this: detection logic is authored in Sigma YAML (or your platform's native format if Sigma coverage is incomplete for a given data source), stored in a Git repository organized by ATT&CK tactic or by data source domain (identity, endpoint, network, cloud control plane). Each detection file carries structured metadata — author, creation date, ATT&CK technique ID, data source dependency, severity, and a status field (draft, testing, production, deprecated). A CI pipeline runs on every pull request: syntax validation, a linter that checks for required metadata fields, a compile step that converts Sigma to the target SIEM query language and confirms it compiles without error, and where feasible, an automated test against a fixture dataset of known-benign and known-malicious log samples.

Peer review is not optional. A second detection engineer should review every rule before merge, checking the false-positive hypothesis and confirming the ATT&CK mapping is accurate — misclassified techniques quietly corrupt coverage reporting over time. On merge to the production branch, a deployment pipeline pushes the compiled query to the SIEM via API, tags it with the version and commit hash, and opens the tuning window described above automatically, with a scheduled job to prompt the owning engineer for review at the window's end.

This structure delivers three things a UI-managed rule set cannot: an audit trail (who changed what, when, and why, which matters enormously during compliance audits and post-incident reviews of “why didn't this fire”), safe rollback (a bad detection that starts flooding the queue can be reverted with a single revert commit rather than someone hunting through a UI trying to remember what the rule looked like before), and reusability across tooling — Sigma-based detections are portable if the organization migrates SIEM platforms, which happens more often than most security leaders plan for.

Testing deserves particular emphasis because it is the step most teams shortchange. At minimum, maintain a fixture library of log samples that represent both the attack technique the detection targets and the top three or four legitimate activities most likely to resemble it. Run these fixtures through the compiled detection logic in CI. This catches the class of bug where a detection technically compiles but the underlying field mapping is wrong for your specific log source schema — an extremely common failure mode when detections are copied from public Sigma repositories without validating against your own normalized schema.

Data engineering foundations

Detection engineering is downstream of data engineering, and this is where most programs actually stall, not in the rule-writing itself. A brilliant detection hypothesis is worthless if the required telemetry is not collected, is collected but not normalized to a consistent schema, or is collected and normalized but retained for too short a window to support retrohunting.

Three data foundation decisions determine what a detection engineering practice can realistically achieve. First, telemetry coverage: map your data sources against the ATT&CK techniques relevant to your threat model and identify blind spots explicitly, rather than assuming that having an EDR agent and a SIEM means you have coverage. Identity provider logs (sign-in, conditional access, privilege changes), cloud control-plane logs (API calls, IAM changes, resource creation), and DNS/network egress logs are the three most commonly under-collected sources relative to their detection value, and they are disproportionately important because so much modern attacker activity — credential abuse, cloud persistence, C2 over legitimate protocols — lives in exactly those data sources rather than in classic endpoint process telemetry.

Second, normalization: detections written against raw, heterogeneous log formats are brittle and expensive to maintain across data source versions. A common information model — whether OCSF, the SIEM vendor's own normalized schema, or an internally defined one — lets a single detection logic pattern apply across multiple underlying data sources (for example, a “suspicious authentication” detection that works identically whether the raw event came from the identity provider, VPN concentrator, or a SaaS application's own audit log). This is also what makes Sigma-based detection-as-code actually portable in practice, since Sigma's field taxonomy assumes a normalized schema underneath it.

Third, retention economics: retrohunting and threat hunting both require historical data, but hot-tier SIEM storage is expensive at the volumes modern environments generate. The workable pattern is tiered retention — 30–90 days of hot, query-fast storage for active detection and response, backed by a cheaper cold or object-storage tier retaining 12+ months for retrohunt and compliance, with a query layer that can reach into cold storage for hunt investigations even if it is slower. Organizations that only budget for hot-tier retention find themselves unable to answer “has this indicator ever appeared in our environment” for anything older than a few weeks, which is precisely the question that matters most when new threat intelligence arrives about a campaign that may have been active for months.

This is also where a unified data foundation across security and IT operations pays a structural dividend rather than a cosmetic one: when the same normalized event pipeline feeds both detection engineering and IT operational monitoring, a single ingestion and normalization investment serves two functions instead of being duplicated. This is the design principle behind platforms like MoxDB as a shared data foundation and the broader AI-native stack approach — normalize once, reason many times, whether the consumer is a detection rule, an AI triage agent, or an IT operations correlation engine.

Metrics that actually matter

Ticket-closure metrics — mean time to acknowledge, mean time to close, tickets per analyst per shift — measure throughput of a queue, not quality of detection or reduction of risk. They persist because they are easy to pull from a ticketing system, not because they are meaningful. A detection engineering practice needs a different metric set, organized around three questions: are we covering the threats that matter, are our detections accurate, and are we getting faster at responding to the things that are real.

Coverage metrics answer the first question. Track the percentage of ATT&CK techniques in your threat-informed priority list (not all 200+ techniques equally — weight by relevance to your industry and observed adversary behavior) that have at least one validated detection, and separately track techniques with only partial data-source visibility versus full coverage. This turns “are we secure” from a vague question into a trackable engineering backlog.

Precision and recall answer the second question, and they matter more than raw alert volume. Precision is the share of alerts from a given detection that were confirmed true positives or at least warranted escalation; recall is harder to measure directly but can be approximated through purple team exercises that intentionally execute techniques a detection should catch and confirm it fires. A detection with 40% precision is not “a bit noisy” — it is broken, and every day it stays in production it trains analysts to dismiss its alerts, which is exactly how real incidents get missed inside a sea of routine dismissals.

Response metrics answer the third question, but should be scoped to alerts that survived automated triage, not the raw firehose. Mean time to detect (MTTD) and mean time to respond (MTTR) are meaningful when measured from the moment a genuine security-relevant event is escalated to a human, not from the moment a low-fidelity alert lands in a queue that automation should have filtered. Dwell time — the gap between initial compromise and detection, typically reconstructed during incident post-mortems — is the metric that most directly reflects whether the detection engineering practice is closing real gaps versus generating volume.

Publish these metrics to the same audience that currently sees the queue-clearing dashboard, and retire the old dashboard as the primary reporting artifact. Leadership visibility into precision and coverage, rather than ticket counts, is what sustains budget and headcount for detection engineering over multiple budget cycles — it is much easier to justify investment in a program that can show “we closed 12 coverage gaps against techniques used by threat actors targeting our sector this quarter” than one that can only show “we closed 4,200 tickets.”

Analyst experience and agentic workflows

The single biggest lever on SOC analyst retention is not compensation — it is whether the job feels like judgment or like data entry. Analysts who spend their shifts pivoting between four consoles, manually pulling context that a script could assemble in seconds, and closing alerts that never should have fired burn out fast, and the industry's attrition numbers reflect it. Rebuilding the analyst experience around AI agents is not a productivity nicety; it is a retention strategy with a direct line to detection quality, because experienced analysts leaving is itself a detection engineering failure — institutional knowledge about what “normal” looks like in your environment walks out the door with them.

The practical pattern for an agentic triage layer has three stages. First, enrichment: when an alert fires, an agent automatically gathers the context a human would otherwise spend ten minutes assembling — asset criticality, user risk score, related alerts in the same session or timeframe, threat intelligence matches on any indicators, and historical baseline for the entity involved. Second, correlation and initial verdict: the agent applies reasoning over that enriched context to produce a preliminary disposition — likely benign with rationale, likely malicious with rationale, or needs human judgment — and for high-confidence benign cases, closes the alert automatically with a full audit trail rather than routing it to a human. Third, case assembly for escalated alerts: rather than handing an analyst a bare alert, the system hands them a pre-built case with the enrichment, the correlated related events, the agent's reasoning trail, and suggested next investigative steps, so the human's first action is judgment, not data gathering.

This is the architecture behind AI-driven XDR alert triage and the broader agentic SOC model: agents absorb the volume and the repetitive reasoning, and humans supervise, spot-check the automated dispositions on a sampled basis, and own the cases that genuinely require contextual judgment about business impact or intent. The supervision step matters and should not be skipped for the sake of throughput — sample a percentage of auto-closed alerts weekly (5–10% is a reasonable starting rate, more for newly deployed agent logic) and have a detection engineer or senior analyst review the agent's reasoning, feeding disagreements back into the agent's tuning the same way a human analyst's false-positive report feeds back into detection tuning.

The workflow implication for detection engineering is direct: a detection is not finished when it fires correctly; it is finished when the response runbook attached to it is also codified well enough for an agent to execute the enrichment and initial triage steps automatically. Detection engineers and automation engineers should co-design the runbook at the same time as the detection logic, not as an afterthought once the rule is already in production and analysts are drowning in manually-triaged fires.

Threat-informed defense and exposure management

Detection engineering without a threat model is content production for its own sake. The prioritization question — which of the 200-plus ATT&CK techniques do we build detections for first — should be answered by a threat-informed defense process, not by whichever technique a vendor's latest blog post covered. This means maintaining an explicit, living mapping of the threat actors and campaign types most relevant to your industry, geography, and technology stack, sourced from threat intelligence feeds, ISAC sharing, and your own incident history, and prioritizing detection engineering backlog items against that mapping rather than against ATT&CK coverage in the abstract.

This connects tightly to exposure management. A vulnerability or misconfiguration that is both exploitable and reachable by a technique your organization has no detection for is a materially higher-priority finding than one that is exploitable but sits behind a technique you already detect reliably — the detection acts as a compensating control that changes the urgency calculus. Mature programs run continuous threat exposure management and detection engineering as coordinated functions rather than siloed teams: exposure findings inform which detections to prioritize, and detection coverage informs which exposures can tolerate a longer remediation window versus which need emergency patching because nothing would catch exploitation in progress. This is the operating logic behind treating continuous threat exposure management and detection engineering as two halves of the same risk-reduction loop rather than two separate program reports that never reference each other.

Purple teaming is the connective tissue that keeps this loop honest. Rather than an annual red team engagement that produces a report six months later, a working cadence runs smaller, more frequent purple team exercises — monthly or even biweekly for high-priority technique clusters — where red team or an automated attack simulation tool executes a specific technique, detection engineers watch in real time whether it fires, and any gap becomes an immediate backlog item rather than a line item in a report that gets filed away. Attack surface reduction and identity-focused detection deserve particular emphasis here: credential abuse, privilege escalation, and lateral movement via compromised identities are consistently among the highest-value detection investments precisely because so much modern intrusion activity routes through identity rather than through malware that endpoint tooling would catch, which is why identity telemetry and detections tied to identity and privileged access monitoring deserve a disproportionate share of early detection engineering investment relative to their share of the overall technique catalog.

Detection engineering in sovereign and air-gapped environments

Everything described so far assumes an internet-connected environment where threat intelligence feeds update in real time, detection content repositories sync from public sources, and cloud-hosted SIEM or XDR platforms handle scale elastically. A meaningful share of critical infrastructure, defense, and regulated financial environments cannot make that assumption, and detection engineering practices built without accounting for air-gapped or sovereign deployment constraints tend to fail quietly the first time they are asked to operate in one.

The core adaptations are threefold. First, threat intelligence and detection content updates need a controlled, auditable import pathway — a one-way data diode or a scheduled, reviewed manual transfer process for pulling in new Sigma rules, IOC feeds, and ATT&CK technique updates, rather than assuming live API connectivity to public detection repositories or intelligence feeds. This slows the pace of content updates and makes the CI/CD pipeline described earlier even more important, because every batch of imported content needs to go through the same validation and testing gate before deployment, with no exception for “it's from a trusted source so we skipped testing.”

Second, the data platform itself needs to run fully on-premises or in a sovereign cloud with no dependency on external services for core detection and response functions — enrichment sources like geolocation databases, threat intelligence context, and even the AI models used for agentic triage need locally hosted equivalents rather than calls out to a public API, both for security reasons and because air-gapped environments by definition cannot make that call. Third, the same rigor around versioning, testing, and audit trails matters even more in these environments because regulatory and compliance review of detection content is typically more stringent, and the ability to show a complete, signed change history for every detection rule is often a hard requirement rather than a nice-to-have.

This is a deliberate design constraint we build for rather than treat as an edge case: Algomox's platform, including CyberMox and ITMox, is architected to run in cloud, on-premises, and air-gapped or sovereign configurations without functional compromise, which matters directly for detection engineering because it means the same detection-as-code workflow, the same agentic triage capability, and the same metrics discipline can be maintained regardless of connectivity posture — a security team should not have to choose between operating in a sovereign environment and running a modern detection engineering practice.

Building the practice: a 90-day roadmap

Organizations rebuilding their SOC around detection engineering rarely benefit from a big-bang transformation. A phased approach that produces visible wins early sustains the organizational buy-in needed to get through the harder infrastructure work.

Days 1–30: Baseline and quick wins

Inventory existing detection content and tag it against ATT&CK techniques — this alone typically surfaces that 30–50% of production rules either overlap heavily or have no clear owner. Pull 90 days of alert history and compute precision per detection; identify and immediately demote (to monitor-only) the bottom 10–15% by precision, which usually accounts for a disproportionate share of analyst time. Stand up a Git repository for detection content even before the full CI/CD pipeline exists — moving rules out of a SIEM console and into version control is valuable on its own.

Days 31–60: Infrastructure and process

Build the CI pipeline for syntax validation and metadata linting at minimum; full automated testing against fixtures can follow. Define the tuning-window process and get agreement from SOC leadership that new detections do not go straight to alert-generating severity. Stand up or formalize the threat-informed prioritization list with input from threat intelligence and any available red/purple team history. Begin piloting agentic triage on one or two well-understood, high-volume, low-complexity alert types (a good starting point: known-benign administrative tool usage that currently generates high alert volume with low true-positive rate).

Days 61–90: Scale and measure

Expand agentic triage coverage based on pilot results, with the sampled human review process running alongside it from day one of any expansion. Publish the first version of the coverage and precision dashboard to leadership, replacing or supplementing the ticket-closure dashboard. Run the first formal purple team exercise against a subset of the prioritized technique list and route findings directly into the detection engineering backlog. Establish the retirement review cadence for stale detections so the practice does not simply accumulate content indefinitely.

By day 90, the goal is not a finished program — it is a running lifecycle with real metrics, at least one automated triage workflow in production, and organizational agreement that detection quality, not ticket volume, is the measure of success. Everything after that is iteration: expanding coverage against the threat model, deepening automation, and tightening the feedback loops between hunting, engineering, and response.

Common pitfalls to avoid

A handful of failure patterns recur often enough across organizations building this practice that they are worth naming explicitly, so they can be planned around rather than discovered the hard way.

• Skipping the tuning window under deadline pressure. Shipping straight to production severity because a new technique needs coverage “now” is how a single detection generates a week of alert fatigue and erodes trust in the whole content set.
• Measuring detection engineers on volume shipped. Incentivizing rule count produces a large, low-quality rule set fast. Measure precision and coverage against the threat model instead.
• Treating agentic triage as a replacement for human oversight rather than a force multiplier. Auto-closing alerts with no sampled review process is how a compromised agent disposition or a subtly wrong triage model quietly suppresses real incidents.
• Building detections without confirming underlying telemetry actually exists. A rule that references a field your log source doesn't populate will sit silently doing nothing, creating false confidence in coverage that isn't real.
• Never retiring anything. Detection sets that only grow accumulate maintenance overhead, dashboard noise, and false confidence in coverage that may no longer be relevant to current attacker behavior.
• Isolating detection engineering from exposure management and threat intelligence. Without a threat-informed prioritization loop, engineering effort spreads evenly across techniques instead of concentrating where it reduces the most real risk.

Frequently asked questions