Loading...
Loading...
Detection engineering is the discipline of building, tuning, and retiring the rules that decide what your security tools alert on. Alert triage judges one event; detection engineering decides whether the next one fires at all. CardinalOps' 2025 State of SIEM report found SIEMs miss 79% of MITRE ATT&CK techniques adversaries use, and roughly 13% of deployed rules never fire.
Closing an alert does not fix the thing that produced it. Your team knows this, and closes the alert anyway, because the queue is what gets measured and the root cause belongs to somebody else's quarter.
An alert is downstream evidence of an upstream condition: a misconfigured control, a detection gap, an exploitable workflow, a process nobody tuned after the environment changed. When the investigation stops at "true positive, remediated," your team has handled the output and left the root cause where it was. The condition keeps generating alerts, and the SOC keeps paying analyst-hours to process them one at a time.
Detection engineering is the discipline of building, tuning, and retiring the rules that decide what your security tools alert on. Underneath the job title it is one balancing act: catch every abuse, and nothing but abuse. Authoring new rules buys recall. Tuning out false positives buys precision.
Recall means real attacks stop slipping past in silence. Precision means the detections you already have stop drowning in noise. Most teams are better at one than the other, and few can tell you which.
Three structural facts make that balance hard to hold. Detection tools each see one slice of the environment, so no single tool can judge its own coverage. They have no visibility into business context, so a rule cannot know that the service account signing in at 2 a.m. from an unusual region is a nightly batch job. And the organization keeps moving, so an assumption that was correct last quarter rots quietly until someone notices at audit.
That is why detection engineering is one of the most skilled, most understaffed, and least measurable functions in security. Anvilogic and SANS put roughly 80% of organizations at actively investing in it, rising to about 85% among large enterprises, yet a dedicated detection engineer remains rare outside the biggest teams. A SOC that is quietly precision-heavy and recall-poor looks excellent on every dashboard it owns. The 79% of ATT&CK techniques it never sees appear on none of them.
| Alert triage | Detection engineering | |
|---|---|---|
| Question it answers | Was this event malicious? | Will the next one fire at all? |
| Unit of work | One alert | A technique class |
| Output | A verdict and a closed ticket | A new or tuned rule, deployed |
| Time horizon | This shift | Next quarter's alert volume |
| Success looks like | The queue is cleared | The queue gets smaller on its own |
| Breaks when | Volume exceeds analyst hours | Nobody owns coverage as an outcome |
Most SOCs are staffed for the left column and judged on the right.
Every alert is downstream of a condition that produced it, and a single case usually exposes three of them at once. An EDR alert fires on a suspicious PowerShell process spawned by winword.exe. An analyst pulls the process tree, checks the command line, correlates against DNS and proxy logs, and confirms a true positive: a malicious attachment reached a user, survived the endpoint's Mark-of-the-Web controls, and dropped a loader. The host is isolated, the process killed, the ticket closed.
In ATT&CK terms that chain is T1566.001 (spearphishing attachment) into T1204.002 (user execution of a malicious file) into T1059.001 (PowerShell). Three techniques. One ticket. One rule tuned, at best.
Now notice what nobody asked. How did that attachment reach an inbox in the first place? Nobody checked whether anyone else received the same message. Nobody checked whether a rule exists that catches this loader's next variant, or only this exact sample. And nobody put the delivery technique on an offensive test schedule.
None of those questions are optional if the goal is fewer alerts next quarter. The alert is a single frame of a longer video. It is evidence of a gap in mail filtering, a gap in detection coverage, and possibly a gap a pentest would have found first.
Fewer alerts is a poor goal on its own. A lower alert count is a proxy for something bigger: fewer successful techniques in your environment, whether or not they trip anything noisy. A team that optimizes for volume alone can quietly reduce noise while risk stays flat, simply by tuning detections quieter and leaving the environment exactly as easy to compromise.
Alert triage stops at the ticket because of volume, not because analysts do not know better. A SOC handling hundreds or thousands of alerts a day does not have the hours to fully investigate each one and turn the good ones into hunts, tuning tickets, and test scenarios.
Something gives.
What gives is the upstream work, because clearing the queue is what gets measured. Every experienced analyst knows a good case should feed back into hunting and detection. Almost none of them has the afternoon.
The evidence shows up in what teams switch off. Prophet Security's 2026 survey of 250 practitioners found 14% had disabled a detection rule because they lacked the capacity to investigate what it produced, and another 26% could see themselves doing it. In roughly two of every five programs, capacity rather than risk is setting coverage.
Even for the cases a team does have time to follow up on, converting an investigation into a durable improvement is hard. Four things stand in the way:
Detection as code is the practice of managing detection rules the way engineering teams manage software: written in a query language or a portable format like Sigma, stored in version control, peer-reviewed through pull requests, tested against historical data, and deployed through a pipeline rather than clicked into a console.
It solves a real problem. Before detection as code, rules lived in a SIEM console with no record of who changed what or why, and a rule that broke stayed broken until someone noticed the silence. Version control gives you review, rollback, and an audit trail. The lifecycle it supports runs hypothesis, implement, test, deploy, tune, retire.
What detection as code does not give you is the supply. It is the machinery for shipping a rule safely; it says nothing about where good rules come from, or how you learn that a deployed one has quietly stopped mattering. That question is answered by what your SOC sees every day, which is why the rest of this argument is about the alert your team just closed.
SOAR closes the detection gap only partly, and only for alert classes you already understand well enough to have written a playbook for. A well-built playbook auto-closes known-shape, low-risk alerts unattended, and for that narrow slice it genuinely works. The relief carries two costs teams routinely underestimate.
The first is maintenance. Building a playbook takes real upfront engineering time, and keeping it accurate as tools and attacker behavior shift is a standing job most SOCs have no spare capacity for.
The second is structural. SOAR closes the loop in the wrong direction: an alert that auto-resolves never reaches a human who might ask what it implies upstream. It leaves the queue, so it leaves everyone's mind, and the technique behind it never gets hunted, tuned for, or tested.
Automation at the bottom of the funnel makes the top of the funnel invisible.
A detection engineering loop closes when a confirmed verdict stops being an ending and becomes an input to three things: a hunt for where else the technique landed, a sharper rule for the next variant, and a targeted test for where else it works.
A true positive tells you a technique worked at least once. It does not tell you whether it worked more than once, before this alert fired. If a loader got through on one workstation, proactive threat hunting asks whether it landed anywhere else that never tripped a detection.
Anchor that hunt on behavior, not on the indicators an attacker can change between Tuesday and Wednesday. Domains and IP addresses rotate cheaply. Beacon timing and jitter, TLS fingerprints, and the parent-child execution chain do not. Search on those and you find the campaign you have not caught yet. Search on the C2 address from this ticket and you find only the one you already closed.
If the alert caught this attempt, ask what it would take to catch the next one. It may have fired on a specific command-line string that a slightly different loader would sidestep entirely. A case that ends in "remediated" leaves that gap open. A case that ends in "remediated, and here is the rule that catches the technique class" raises the bar, and gives the SOC back the hours it just spent.
A real-world true positive proves a technique is viable in your environment, which makes it a far better test hypothesis than a generic suite item. If a delivery technique got a loader past your controls once, that is a signal to test its variants before an adversary does. That makes the next test evidence-driven. You are probing a technique you already know works here.
There is a quieter shift underneath all three. Red-team and blue-team activity traditionally run on separate calendars, and a blue-team finding might inform a pentest scope months later if anyone remembers. Make that connection immediate and the two stop occasionally syncing up: prove a gap exists, hunt its full extent, test where else it is exploitable, detect it earlier next time, repeat.
Adversary simulation improves detection engineering by proving whether a rule fires before an attacker tests it for you. Breach-and-attack simulation platforms such as SafeBreach, AttackIQ, Cymulate, and Picus, along with open-source frameworks like Atomic Red Team and MITRE Caldera, replay ATT&CK techniques against live controls and turn coverage from an assumption into a measured result.
Simulation and replay answer different questions, and mature programs use both. Simulation proves a rule fires against a synthetic version of a technique, which is how you find gaps you have not been attacked through yet. Replaying a rule against the real telemetry from a campaign you missed proves it fires against what your environment genuinely produced, noise included. Simulation gives you breadth; your own missed attacks give you fidelity.
Neither closes the handoff. A simulation result nobody converts into a deployed rule is a report. A missed campaign nobody replays is just a ticket.
Detection engineering needs shared context because the investigation, the hunt, the rule, and the test scope have to reason over the same picture of the environment for the loop to close in hours instead of a quarter. Hand-feeding each function the previous one's output is the step that gets skipped when everyone is behind.
That is the job Simbian's Context Lake™ does: one data layer fusing SIEM, EDR, and cloud telemetry with tribal knowledge, entity intelligence, and prior verdicts into a single correlated view instead of four tools each holding a partial one. The AI SOC Agent, AI Threat Hunt Agent, AI Pentest Agent, and AI Detection Engineering Agent all run on that same layer, which is what removes the handoff the four blockers above describe.
When the SOC Agent closes a case, the Threat Hunt Agent is reasoning over the same context plus whatever that case just found. The Pentest Agent scoping a follow-up works from a technique that was confirmed hours ago in this environment. The Detection Engineering Agent tuning a rule uses the same live picture everything else just touched, and it carries forward what no single investigation can see on its own: how many investigations a rule has driven, its false-positive history, and whether it still holds today.
One guardrail matters here more than any speed claim. Every rule the agent produces is a candidate, replay-validated against the real telemetry that was missed and against a baseline window of your own normal traffic, then put in front of a human to approve. Human-approved, never auto-deployed — and once you approve it, the push to your SIEM is automatic, with rollback and a full audit trail. This is self-improving SecOps, not self-driving SecOps, and the difference is the approve step.
Detection engineering changes what a closed case is worth. Under the old model the value of an investigation is capped at the alert it resolves, so a SOC processing an endless queue works at a constant rate forever, no matter how fast each individual case gets.
Under a closed loop, each investigation also buys a hunt, a better rule, and a sharper test. The queue shrinks because the conditions generating it get fixed, and that shows up as a number. Across three cycles of the loop — test the technique, hunt for it, check whether detection fired, write the rule that was missing — measured ATT&CK coverage in one deployment moved from 33% to 56% to 83%. Each cycle closed more gaps than the last, which is the only reason the second quarter costs less than the first.
The verdict quality underneath that has to hold, or the downstream work is wasted. In NTT Data Japan's 2026 evaluation, Simbian's AI SOC Agent reached 94.9% agreement with human analysts on true-positive and false-positive judgments across 138 alerts, and cut end-to-end response time from 154 minutes to 12. A hunt seeded by a shaky verdict costs a hunter a week.
Start with one question at your next case review. For the last ten true positives your team closed, what got written, hunted, or tested as a result?
If the answer is nothing, the loop is open. Most teams already know it is. What they lack is the afternoon to close it.
Q: What is detection engineering? Detection engineering is the discipline of building, tuning, and retiring the rules that decide what your security tools alert on. It covers two jobs: authoring new detections so real attacks stop slipping past unseen, and tuning out false positives so the detections you already have are not drowned in noise. Roughly 80% of organizations report actively investing in it, per Anvilogic and SANS research.
Q: What is the difference between detection engineering and alert triage? Alert triage evaluates a single event and reaches a verdict on whether it was malicious. Detection engineering works one level up, deciding which rules exist, how they are tuned, and whether the next instance of that technique fires at all. Triage handles the symptom; detection engineering treats the root cause producing it.
Q: What is detection as code? Detection as code manages detection rules like software: written in a query language or a portable format such as Sigma, kept in version control, peer-reviewed, tested against historical data, and deployed through a pipeline. It gives a team review, rollback, and an audit trail for every rule change. It does not, on its own, tell you which rules are worth writing.
Q: How does proactive threat hunting fit into the detection engineering process? Hunting supplies the evidence detection engineering needs. A hunt that finds a legitimate kill-chain pattern which never fired an alert has identified a detection gap precisely, and that gap becomes a rule. Hunts that come back benign still harden coverage, because the pattern was real even when the activity was not malicious.
Q: Can AI write detection rules safely? Yes, provided every rule arrives as a candidate that a human still has to approve. Simbian's AI Detection Engineering Agent generates rules from your own missed-attack telemetry and replay-validates each one before a human ever sees it. Nothing reaches your SIEM without approval, and every deployment carries a rollback and an audit trail.
Q: Where should a team start if the loop is completely open today? Pick one alert class your SOC sees weekly and run a single case all the way through: hunt for other instances, write or tune the rule that would catch the next variant, and scope a test against the same technique. One full cycle on a real case teaches more about your gaps than a coverage assessment does, and it gives you a baseline to measure the next cycle against.
If you want to see what a closed loop looks like against your own alert queue, book a demo and bring a case your team argued about.
