What Is Detection Engineering? A Practical Guide

Detection engineering is the discipline of designing, building, testing and maintaining the rules and queries that turn raw logs into security alerts. A detection engineer decides what malicious behavior looks like in your data, writes the logic to catch it, and keeps that logic accurate as attackers and environments change.

If you have ever closed an alert in a SIEM, someone built the rule behind it. That someone was doing detection engineering, whether or not their job title said so. In small teams it is a hat worn by senior analysts. In larger ones it is a dedicated role.

This guide covers what the work involves, the lifecycle a detection goes through, detection-as-code, the frameworks people mean by "detection engineering framework", how to measure whether your detections are any good, and how to move into the field from a SOC analyst seat.

What a Detection Engineer Actually Does

Day to day, the work looks like this:

• Researching attacker behavior. Reading incident reports, ATT&CK technique pages and threat intel to understand what an attack leaves behind.
• Checking the data. Confirming the logs needed to see that behavior are actually collected, parsed and searchable.
• Writing detection logic. Building rules in SPL, KQL, EQL, Sigma or whatever your platform uses.
• Testing. Running the attack technique and checking the rule fires. Also checking it stays quiet on normal activity.
• Tuning. Cutting false positives with exclusions, thresholds and better context.
• Tracking coverage. Mapping detections to techniques so the team can see what it can and cannot catch.

Detection engineer vs SOC analyst

The simplest split: SOC analysts work the alerts, and detection engineers work the alert supply. Analysts triage, investigate and escalate. Engineers decide which events deserve an alert at all, and how much context should come with it.

The two roles feed each other. Analysts see which alerts are noisy, which are missing context, and which attacks slipped through. That feedback is the best input a detection engineer has. In return, engineers write alerts with clear descriptions and investigation steps, so an analyst at 3am does not have to guess what a rule was meant to catch.

Detection engineering also overlaps with threat hunting. A hunt looks for something no alert caught. When a hunt finds a reliable pattern, the best outcome is turning it into a detection so nobody has to hunt for it by hand again.

The Detection Lifecycle

Good detections are not written once and forgotten. They move through a loop.

1. Idea and threat research. Start with a behavior worth catching. Sources include an ATT&CK technique, a recent incident in your own environment, a public threat report, or a gap found in a red team exercise. Write down the behavior in one sentence before touching any query.

2. Data source check. Ask what log would show this behavior, and whether you collect it. Many detection ideas die here, and that is a useful result: the real finding is a logging gap. For endpoint behavior, process creation logs with command lines are the usual starting point. Our Sysmon event ID cheat sheet shows which events cover which behavior.

3. Write the logic. Make the first version simple. Detect the behavior, not one tool's name. Keep the rule readable so the next person can maintain it.

4. Test. Generate the activity and confirm the alert fires. Atomic Red Team, an open library of small attack tests mapped to ATT&CK techniques, is a common way to do this safely in a lab. Then run the rule against historical data to see what else it matches.

5. Tune false positives. Every new rule meets legitimate activity: admin scripts, software updaters, vulnerability scanners. Decide whether to exclude known-good, raise the threshold, or add context. Document each exclusion and why it exists.

6. Deploy. Ship it with a name, severity, ATT&CK mapping, description, and a short note on what an analyst should check first.

7. Measure and retire. Watch how the detection performs in production. Rules that never fire, always fire, or are always closed as benign need a decision: fix them, merge them, or retire them. Environments change, and a rule written for last year's tooling can quietly stop working.

Detection-as-Code

Treating detections like software is now standard practice in mature teams. The idea is simple: rules live as files in a version-controlled repository instead of only inside a SIEM console.

That brings the usual benefits of software engineering:

• Version control. Every change has an author, a date and a reason. You can see who added an exclusion and roll back a bad edit.
• Peer review. A second person reads the logic before it goes live. This catches sloppy wildcards and missing context.
• Automated testing. A pipeline can check the rule's syntax, run it against sample logs, and fail the build if it breaks.
• Consistent deployment. The same rule goes to the same place every time, instead of someone copying a query between consoles.

Sigma: one rule format for many platforms

Sigma is an open, vendor-neutral format for describing detections in YAML. You write the rule once, then convert it into the query language of your SIEM using tools from the Sigma project. The SigmaHQ GitHub repository also holds a large community library of rules you can read and learn from.

Here is a small Sigma rule that flags PowerShell started by Microsoft Word, a pattern common after a malicious document is opened:

title: PowerShell Spawned By Microsoft Word
id: 6f1c2d4e-3b7a-4c58-9e21-0a5d8b7c9f13
status: experimental
description: Detects PowerShell launched as a child of Word, which is rare in normal use and common after a malicious document is opened.
tags:
    - attack.execution
    - attack.t1059.001
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        ParentImage|endswith: '\winword.exe'
        Image|endswith: '\powershell.exe'
    condition: selection
falsepositives:
    - Rare legitimate Word macros or add-ins that call PowerShell
level: high

The required parts are title, logsource and detection. Everything else is metadata that makes the rule easier to manage. The logsource says what kind of log the rule needs, and the |endswith modifier matches the end of a field value.

Here is the same idea as a Splunk search, assuming Sysmon process creation data:

sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
ParentImage="*\\winword.exe" Image="*\\powershell.exe"
| table _time host User ParentImage Image CommandLine

And in KQL for Microsoft Sentinel, with Sysmon forwarded into the Event table:

Event
| where Source == "Microsoft-Windows-Sysmon" and EventID == 1
| extend Image = extract(@'<Data Name="Image">([^<]+)</Data>', 1, EventData),
         ParentImage = extract(@'<Data Name="ParentImage">([^<]+)</Data>', 1, EventData),
         CommandLine = extract(@'<Data Name="CommandLine">([^<]+)</Data>', 1, EventData)
| where ParentImage endswith @"\winword.exe" and Image endswith @"\powershell.exe"
| project TimeGenerated, Computer, ParentImage, Image, CommandLine

All three express one idea. Sigma is the portable description, and SPL and KQL are what your platform runs. For more query patterns, see the SPL cheat sheet and the KQL cheat sheet.

Detection Engineering Frameworks

When people search for a "detection engineering framework", they usually mean one of a few well-known ideas rather than a single official standard. These are the ones worth knowing.

MITRE ATT&CK for coverage mapping

MITRE ATT&CK is a public knowledge base of adversary tactics and techniques, built from real-world observations. Detection teams use it as a shared vocabulary: tag each detection with the technique it covers, and you can see which techniques have detections and which have none.

The free ATT&CK Navigator tool lets you color a matrix by coverage. Treat the result carefully. "One rule exists for this technique" does not mean the technique is covered, because most techniques can be carried out in many ways. Coverage is a question of how well, not just whether.

The Pyramid of Pain

David Bianco's Pyramid of Pain ranks the indicators you can detect by how much it hurts the attacker when you detect them. At the bottom are things like file hashes and IP addresses, which are trivial for an attacker to change. Higher up are domain names, network and host artifacts, tools, and at the top, tactics, techniques and procedures (TTPs).

The lesson for detection engineers: detections built on behavior survive longer than detections built on a single indicator. A rule for one file hash dies when the attacker recompiles. A rule for the behavior behind it keeps working. We cover this idea in more depth in IOCs vs TTPs.

Detection maturity models

A maturity model describes how developed a detection capability is, from ad hoc rules to a managed, measured program. One published example is the Detection Maturity Level (DML) model by Ryan Stillions, which grades a team's detection capability by the level of attacker behavior it can detect, from raw indicators up to goals and objectives. Other organizations build their own internal versions covering things like whether rules are version controlled, tested, documented and reviewed.

You do not need to adopt a formal model. The useful idea is to ask honestly where your program sits and what the next step up is.

How to Measure Detections

A detection you never measure is a detection you cannot improve. These are the measures that matter, none of which need an industry benchmark to be useful:

• True positive rate. Of the alerts this rule produced, how many were real malicious or policy-violating activity? Analyst closure reasons are the data source.
• False positive rate. How many were benign? A rule with a high false positive rate wastes analyst time and teaches people to ignore it.
• Alert volume. How many alerts per day or week does it create, and can your team realistically work them?
• Coverage. Which ATT&CK techniques have at least one tested detection? Which of the techniques relevant to your environment have none?
• Time to detect. How long between the malicious activity and the alert? This depends on log latency, scheduled search intervals and rule design.
• Test results. When you re-run the attack test, does the rule still fire? Detections can break silently when a log source changes.

Compare each number to your own past numbers, not to a figure from a blog post. A rule that fires 20 times a week might be fine in a large enterprise and unbearable in a team of three.

One caution: no alerts does not mean no attacks. A quiet rule might be quiet because nothing happened, or because it is broken. Regular testing is how you tell the difference.

Detection Engineering Career Path

Most detection engineers start as SOC analysts, and that is the best route in. Working alerts teaches you what real logs look like, which alerts are noise, and how investigations actually go.

A typical path:

1. SOC analyst. Learn triage, common log sources, and your SIEM.
2. Senior analyst or tuner. Start suggesting and making changes to rules, then take ownership of tuning.
3. Detection engineer. Own the lifecycle for a set of detections.
4. Senior detection engineer or detection lead. Set strategy, coverage priorities and quality standards.

Titles vary a lot between companies, so read job descriptions rather than titles.

Skills to build

• Log sources. Know Windows event logs, Sysmon, authentication logs, DNS, proxy and cloud audit logs well enough to say what each shows and misses.
• Query languages. Get fluent in at least one of SPL or KQL, then learn the basics of the other.
• Scripting. Python or PowerShell for automating tests, parsing data and building pipelines. Basic Git matters too.
• ATT&CK. Be able to explain how a technique works and what it leaves behind, not just recite its ID.
• Attack testing. Run simple attack simulations in a lab and watch the logs they create.

What to put in a portfolio

Hiring managers want proof you can do the work. A small public repository does that well:

• Five to ten detections, each as a Sigma rule or a query, with a README for each.
• For every detection: the behavior it targets, the ATT&CK technique, the log source needed, how you tested it, and the false positives you found and how you handled them.
• One write-up of a detection you improved after finding it too noisy.

Never publish rules or data from an employer. Use lab data or public datasets.

FAQs

What is detection engineering in cyber security?

It is the practice of building and maintaining the detection rules that generate security alerts. It covers research, data checks, writing logic, testing, tuning and measuring, so alerts catch real threats without burying analysts in noise.

What is the difference between detection engineering and threat hunting?

Hunting is a manual, hypothesis-driven search for threats that no alert caught. Detection engineering builds the automated alerts. They work best together: a successful hunt often becomes a new detection.

Do detection engineers need to code?

Not heavy software engineering, but yes, some. You need to be strong in query languages and comfortable with scripting and Git. Detection-as-code makes those skills more important each year.

Can I become a detection engineer with no experience?

It is uncommon to start there. Most people spend time as a SOC analyst first, then move across by taking on tuning and rule-writing. A portfolio of tested detections helps a lot.

What tools do detection engineers use?

A SIEM (such as Splunk or Microsoft Sentinel), Sigma for portable rules, Git for version control, ATT&CK for mapping, and Atomic Red Team or similar for testing.

TL;DR

Detection engineering is building and maintaining the rules that turn logs into alerts. Each detection goes through research, a data check, logic, testing, tuning, deployment and ongoing measurement. Modern teams treat rules as code, often in Sigma. ATT&CK, the Pyramid of Pain and maturity models help you decide what to build and how well you are doing. Most people get in through the SOC, so build log, query and attack-testing skills and show your work.

How EpicDetect Can Help

Detection engineering starts with knowing what attacks look like in the logs. The Detection zone on the EpicDetect Atlas lays out what to learn, in order. When you want to practise on real evidence, Adventures puts you in a SOC investigation where you find the attack yourself. Season Zero is free.