Detection engineering is the practice of designing, building, testing, deploying and maintaining the logic that finds attacker activity in your telemetry. Each detection is treated like software, with an owner, documentation, tests and a retirement date. That is close to how Wiz defines it, and most practitioners would sign it. The definition is the easy part. The hard part is why so many teams that fund the work still cannot say whether their detections fire when it matters.
Picture a rule that fires at 06:00 every morning. It flags a service account running a remote command on forty servers, which is exactly what a backup job does, so the analyst on shift closes it in seconds. After a month nobody reads it at all. The rule is not wrong, because the behavior it describes really happened. It is simply unengineered, and everything below is about what turns that rule into a detection someone trusts.
What is detection engineering, and why it became its own discipline
For years detections were written the way the 06:00 rule was, by whoever had a free afternoon after an incident. Palantir’s incident response team described the result honestly when it published its framework in 2017. There was a lack of rigor around creating alerts, which sent sub-optimal alerts to production without documentation or peer review, and some of them earned a reputation for low quality that led to fatigue and alerting apathy.
The industry has since put money behind the fix, though the money has moved faster than the practice. The 2025 SANS Detection Engineering Survey, drawn from 264 respondents, found that nearly 80% of organizations fund detection engineering while only 60% have a dedicated team. The same survey shows where detections now come from, and the answer surprised us less than it should surprise vendors.
The likeliest reason sits in the same survey. High false positive rates (64%) and accuracy issues (61%) were the most commonly cited problems with vendor-provided detection tools. Writing your own only helps, though, if what you write is better than what you replaced.
Why detections fail: noise is usually a context problem
The most useful research on this question is a qualitative study of SOC analysts that Oxford researchers presented at USENIX Security 2022 under the blunt title “99% False Positives”. Practitioners in their survey confirmed that their tools produced high false positive rates which needed manual validation. When the authors dug in, though, most of those “false positives” turned out to be benign triggers, true alarms explained by legitimate activity in the environment. The rule saw what it was built to see. Nobody had told it about the backup job.
That distinction changes the fix. A rule producing benign triggers does not need rewriting from scratch, it needs context (an allow-list owned by someone, an asset tag, a schedule) and a written statement of what normal looks like. The same paper warns that alarm validation is tedious enough to cause burnout and eventually desensitization, and it proposes that good alarms be reliable, explainable, analytical, contextual and transferable. Our 06:00 rule fails on contextual. That is the cheapest property to add, which means it is where a new program should start.
Where to aim detections: up the Pyramid of Pain
Context makes a detection quiet. Aim decides whether it is still useful next month. David Bianco’s Pyramid of Pain ranks indicators by how much it costs an attacker when you deny them, from hash values, IP addresses and domains at the bottom to tools and TTPs at the top. A hash changes when a single bit in the file flips. A behavior forces the adversary, in Bianco’s words, to “learn new behaviors”, which is the most expensive thing you can ask of them.
Practitioners have reached the same conclusion from the other direction. In the SANS survey, 67% named behavior-based detection as their most effective methodology, well ahead of threat intelligence-driven and correlation-based approaches.
Our advice is to keep indicator matching, because it is cheap and catches the lazy attacker, but to spend engineering hours on behaviors. One caveat applies, and it loops back to the 06:00 rule. In our experience behavioral detections produce more benign triggers than hash matches do, because legitimate administrators behave a lot like attackers. Aiming higher on the pyramid raises the bar for context, and teams that skip that step end up with behavioral rules that nobody reads. Where a rule cannot express “unusual for this account”, a baseline engine can help, which we covered in UEBA and detection engineering.
The detection engineering lifecycle
Once you know what to aim at, the lifecycle is what keeps each detection honest. We use five stages, and Palantir’s own history shows which two get skipped first, documentation and peer review.
| Stage | What happens | Evidence it was done |
|---|---|---|
| Hypothesis | Name the behavior, the ATT&CK technique and the data source that would show it | A written goal and technical context |
| Build | Write the logic and the known benign triggers next to it | Rule plus documented false positives |
| Validate | Reproduce the behavior and confirm the rule fires | A recorded test run |
| Review | A second engineer reads the strategy, blind spots and response steps | Peer approval in version control |
| Maintain | Track fire rate, triage outcome and data health; tune or retire | Owner, last-reviewed date, retirement criteria |
Palantir’s Alerting and Detection Strategy framework is still the best template we know for the documentation half. It requires Goal, Categorization, Strategy Abstract, Technical Context, Blind Spots and Assumptions, False Positives, Validation, Priority and Response before a detection reaches production. The Blind Spots section is the one we would never drop, because it is where an engineer admits what the rule cannot see, and that admission is what the next engineer needs.
Validation needs a repeatable way to produce the behavior. Atomic Red Team is a library of small tests mapped to MITRE ATT&CK that lets a team test its environment “quickly, portably, and reproducibly”. A detection without a test is a guess, and a guess that has never fired looks exactly like a detection that works.
Detection as code
Detection as code is the lifecycle above, run through the same tooling your developers already trust. Rules live in a repository, changes arrive as pull requests, a pipeline checks syntax and runs the validation tests, and deployment to the SIEM is automatic. Palantir’s framework already asked for detections to sit in a durable, version-controlled and centralized location. The pipeline turns that request into a gate nobody can skip on a busy afternoon.
The format question has a sensible default. Sigma is a generic, open signature format for describing log events, which its maintainers sum up by saying that Sigma is for log files what Snort is for network traffic and YARA is for files. Rules are YAML, converters translate them into each SIEM’s query language, and the main repository holds more than 3,000 rules to learn from. Writing in Sigma keeps your logic portable when the SIEM contract changes, and you will be glad of that during the next renewal.
How to measure detection engineering
Here is the uncomfortable number. In the SANS survey, only 45% of organizations can reliably measure the effectiveness of their detection engineering, and 49% report difficulty evaluating it at all. That is the gap that lets a rule like the 06:00 one survive for years.
You do not need a perfect metric to start. Track, per detection, how often it fires, what share of its alerts end as true positive, benign trigger or false positive, when it last passed its validation test, and whether its data source is still arriving. A rule whose test has not run in a quarter is unverified, however green its dashboard tile looks. For the program as a whole, a maturity model gives you a shared vocabulary. Elastic’s Detection Engineering Behavior Maturity Model defines five tiers (Foundation, Basic, Intermediate, Advanced and Expert) and focuses on team behaviors rather than tools, which is where the 06:00 rule’s real problem lived.
AI in detection engineering: drafts, not decisions
The SANS respondents expect a lot from AI. Only 45% use it for detection today, yet 88% expect a significant impact within three years. The research on generating rules with language models shows why adoption trails the enthusiasm. LLMCloudHunter, which turns cloud threat reports into detection candidates, reported that 99.18% of its generated rule candidates compiled and converted into Splunk queries. That is a strong result for syntax, and it says nothing about whether the rule catches the behavior without burying the queue in benign triggers.
The more careful systems now build validation in. SIGMERGE, presented at USENIX Security 2026, was evaluated against 16 baselines and 13 models, and four of its rules were accepted into the official Sigma repository. AUTOSIGMA, still under review, grounds generated rules against existing ones and validates them with an LLM judge. Our position is that a model is a fast first author and nothing more. Its draft goes through the same hypothesis, validation and review gates as a human’s, because the lifecycle is the control, not the author. The same caution applies at triage, where the research we covered on AI SOC agents shows them closing real attacks after an empty search.
If you want help standing up the pipeline, the tests and the review gates, that is the core of our security engineering work.
Frequently asked questions
What does a detection engineer do?
A detection engineer turns knowledge about attacker behavior into detections that run in production. Day to day that means writing rules, documenting their assumptions and blind spots, testing them against reproduced attacks, tuning out benign triggers, and retiring rules that no longer earn their alert volume. It is a scarce skill. The SANS survey found 41% of organizations struggle to find skilled detection engineering staff.
What is the difference between detection engineering and threat hunting?
The two are partners with different jobs. Hunting starts from a question and a person, and it is meant for activity your detections do not cover yet. Detection engineering takes what a hunt proved and makes it permanent, tested and owned. The Sigma project draws the same line in its own repository, which keeps generic detection rules separate from broader threat hunting rules meant as a starting point for an analyst. A hunt that finds something and does not end in a pull request has only done half its job.
Do you need Sigma for detection engineering?
No. The discipline is the lifecycle, and you can run it in any query language. Sigma earns its place because it keeps detection logic portable across SIEMs and gives you a large public library of more than 3,000 rules to adapt. Our default is to write in Sigma and convert, then keep a small set of native rules for the features Sigma cannot express.
Can AI write detection rules?
It can draft them, and research systems now produce rules good enough to be accepted into the Sigma repository. What it cannot yet do is know your environment’s benign triggers. Treat every generated rule as a pull request from a new colleague, test it and review it before it ships.
Bottom line: what to do this week
Pick your ten noisiest rules this week and write each one up in the ADS format, starting with its false positives and blind spots. Any rule you cannot test or explain gets tuned or retired, and the 06:00 rule is a good one to start with.