What Do Detectioneers Actually Do?

Ten. Billion.

The CISO says this like it's a flex. And everyone in the room nods, deeply impressed, because big numbers feel like big safety.

Nobody asks the obvious follow-up: And then what?

Detection engineers are the people who have to answer that question. And the answer, most days, is deeply unglamorous.

Let's Start With What Everyone Thinks They Do

The popular imagination of a detection engineer looks something like this: threat intel drops in their inbox, they write a slick rule in under an hour, the attacker gets caught, handshakes all around, maybe someone buys pizza.

The cinematic version skips the part where the rule you just wrote fires 10,000 times in the first hour because your sysadmin runs whoami every time he opens a terminal. It skips the Slack message from the SOC analyst at 11pm: "Hey, this thing is screaming again." It skips the three weeks of tuning a rule that was originally one line in a Sigma file until it finally, finally, starts behaving like an adult.

What detection engineers actually do is closer to being a plumber who also has to prove, every quarter, that pipes exist and that water is bad.

The Job, Honestly

Here's what the job actually looks like, broken into its true constituent parts.

Writing rules (10% of the time). Yes, detection engineers write detection rules. SIEM queries in SPL, KQL, YARA-L depending on which SIEM your company has committed to and now deeply regrets. Sometimes they write in Sigma, a vendor-agnostic format that lets you write a rule once and theoretically deploy it anywhere. The keyword there is "theoretically."

Tuning the same rules forever (40% of the time). A detection rule is not a thing you write and forget. It's a thing you write, deploy, watch explode into a false positive storm, suppress, tune, re-suppress, re-tune, argue about in a ticket, suppress again, and eventually either promote to production or quietly retire in shame. The consequence of skipping this process is a rule that generates 10,000 false positive alerts on day one because someone forgot to check what legitimate admin behavior looks like. Detection engineers who skip baselining are the reason SOC analysts develop thousand-yard stares.

Explaining to someone why the alert isn't the thing they think it is (20% of the time). This is the diplomatic part. A stakeholder sees an alert fire and assumes breach. The detection engineer has to explain, calmly, that the alert fired because someone in accounting ran a PowerShell script to export a birthday calendar. The rule works perfectly. The environment is just chaos. These are different problems.

Staring at MITRE ATT&CK and feeling feelings (10% of the time). MITRE ATT&CK is a framework that catalogs every technique a threat actor has ever used, organized into a grid that becomes a heat map of your shame when you map it against your actual detection coverage. The goal isn't "we have 3,000 detections." The goal is behavioral coverage against techniques that matter to your environment. Most organizations look at their Navigator heat map and discover they've been lighting up the same 15 techniques for years while ignoring entire tactic columns that ransomware groups actively exploit.

Everything else (20% of the time). Data pipeline debugging. Log source onboarding. Arguing about whether a field should be called src_ip or source_ip. Writing runbooks nobody will read. Justifying headcount. Attending threat intel standups where someone says "APT29" like it's a death sentence and you're already mentally mapping coverage gaps you know you have and cannot fix this sprint.

The False Positive Problem Is Actually a Philosophy Problem

Here's a thing most people misunderstand: false positives aren't just annoying. They're a signal that your detection logic doesn't understand its environment.

Logs capture behavior, not intent. Therefore, an alert based on logs is a collection of signals, not a verdict. A detection rule for DCSync activity fires on legitimate domain replication all the time. Not because the rule is broken, but because the behavior overlaps. The rule sees the what. You need context to determine the why.

This is the fundamental problem detection engineers spend their careers working on. It should be mandatory for every new detection: not only does baselining provide clear red flags indicating the new idea needs refinement, but sometimes this exercise is a threat hunt in itself. You deploy the Sigma rule as-is with level: high and discover that your medium-sized Active Directory environment fires on domain controller replication every few minutes, twenty-four hours a day, because it's just... doing normal AD things.

And this is where the craft lives. Not in writing the query. In understanding your environment well enough to separate the signal from the absolutely staggering volume of noise that modern enterprise infrastructure produces at rest.

The Dirty Secret About Rule Coverage

Fewer than 20% of detection rules ever trigger alerts. Under 5% of rules generate most of the alert noise. Over 70% of detection gaps can be addressed using existing data in the SIEM. Over 50% of SIEM data is never used for detection.

Your organization is probably paying seven figures for a SIEM, ingesting everything, and using half of the data for nothing. Meanwhile the rules that exist are either on fire all the time or gathering cobwebs since 2019. The middle ground, a set of well-tuned, high-fidelity detections with documented coverage, is the thing detection engineers are supposed to build. It's also the thing that gets deprioritized every time there's an incident, a platform migration, a vendor renewal, or someone reads a threat intel report and sends an urgent email with "can we detect this?" in the subject line.

The answer is almost always: "We can try. Give us a week."

What Good Actually Looks Like

Detection engineering done well looks boring from the outside. No fires. Alerts fire occasionally, and when they do, they mean something. Modern CI/CD pipelines run integration tests automatically whenever new detection code is committed, spinning up a test environment, loading the rule, and executing known test events through it. Rules have owners. Coverage is mapped. Gaps are documented and prioritized, not discovered during an incident post-mortem.

The mature version of this function operates like software engineering, not firefighting. Detection engineering has long been a function of the incident response team. Over the last several years, it has gained momentum, becoming a dedicated and more well-defined role within many security operations teams. The organizations still treating it as a side function of IR, where someone writes rules between incident tickets, are the ones whose rules haven't been reviewed since a long time.

The AI Bit (Since You Were Going to Ask)

There is a version of AI in detection engineering that deserves the skepticism it gets. Someone opens ChatGPT, types "write me a Sigma rule for lateral movement," pastes the output into production, and goes home. The rule fires 10,000 times on day one because the LLM has never seen their environment, doesn't know their service accounts, and has no idea that their IT team runs PsExec every Thursday for patch deployment.

That's not AI-assisted detection engineering. That's delegation without judgment, and it fails for the same reason a Sigma rule copied from GitHub without baselining fails: the logic is contextless.

The actual shift happening is different, and it's worth being precise about.

Detection engineering has always had a scaling problem. One engineer, eight hundred rules, four SIEM platforms, and a backlog that grows faster than anyone can close it. The craft work is writing a hypothesis, understanding a technique, knowing what the benign version looks like that judgment has traditionally lived entirely in one person's head. What AI changes is both the work around that judgment and, increasingly, the judgment itself.

Start with the infrastructure layer, because that's where the relief is most immediate. AI handling translation (Sigma to KQL to SPL to YARA-L), surfacing broken or stale rules, flagging FP patterns across thousands of alerts, drafting first-pass rule logic from a threat intel report, all of that removes the mechanical overhead that consumes most of a detection engineer's week. An engineer who used to own 50 rules well can now own 500 rules well, because the maintenance, the translation, and the noise triage are handled. That alone changes what a detection program can realistically achieve.

But the more interesting change is what happens to the craft work itself.

A good detection starts with a hypothesis: a falsifiable claim about adversary behavior, grounded in a specific technique, mapped to specific observables, with the benign version already accounted for. That thinking used to happen entirely in the engineer's head, drawing on whatever threat intel they'd read, whatever incidents they'd worked, whatever intuition they'd built over years. AI augments all three. It can surface relevant threat actor TTPs the engineer hasn't read yet. It can pull similar historical detections to stress-test a new hypothesis. It can propose the benign cases the engineer might have missed , the service accounts, the scheduled tasks, the legitimate admin tools that exhibit the same behavior.

The engineer isn't replaced in this loop. They're the reviewer, the final judgment, the person who knows that the finance team runs a weird PowerShell script every Thursday that will break this rule the moment it goes live. But they're no longer working from a blank canvas. The hypothesis gets sharper faster. The blind spots surface earlier. The time from "I need to detect this technique" to "I have a tested, tuned rule in production" compresses significantly.

The detection engineers who thrive aren't the ones who resist this or the ones who delegate blindly to it. They're the ones who understand the discipline deeply enough to direct AI effectively, who can look at an AI-generated hypothesis and immediately identify the evasion gap, the missing benign filter, the data dependency that isn't available in their environment. That judgment is not learnable from a model. It comes from understanding how attackers actually operate and how your environment actually behaves.

What changes is the ceiling. Detection programs that used to stall at "we have 200 rules we sort of trust" can now build toward comprehensive, tested, tuned coverage across their full threat model. The bottleneck shifts from volume to quality of thinking which is where it should have been all along.

So What Do They Actually Do?

Detection engineers build, test, and maintain the logic that separates a genuine breach from a sysadmin having a weird afternoon. They work at the intersection of threat intelligence, data engineering, and security operations, constantly translating attacker behavior into query syntax and back again. They are the reason some alerts mean something and the reason (when things go wrong) some alerts mean absolutely nothing.

They write rules, break rules, tune rules, and explain rules to people who are convinced the tool is lying to them.

Most of the time, the tool isn't lying. Most of the time, the environment is just doing its thing, and detection engineers are the ones who have to know the difference.

That's the job.

If you're building or scaling a detection engineering function, the Detection Engineering Maturity Matrix by Kyle Bailey and the community at detect.fyi are the two resources I'd start with. The matrix is the map. Detect.fyi is the practitioners who've already walked it.