Detection Engineering: How to Build the Function Behind Your SOC's Alerts

Detection engineering is the discipline of designing, testing, deploying, and retiring the rules that turn security logs into alerts, run with the habits of software engineering: rules live in version control, changes go through peer review, tests run before anything reaches production, and every rule has a named owner. The function decides whether a security operations center (SOC) sees real attacks or drowns in false positives. A working function has four parts: a backlog prioritized by threat intelligence and incident findings, a pipeline that deploys rules as code, a test method that proves each rule fires on the attack it targets, and metrics that track precision and tested coverage of the MITRE ATT&CK techniques that matter to your business.

What does a detection engineer do?

A detection engineer owns the life of each rule from request to retirement. Requests come from five places: threat intelligence about a technique in active use, an incident or red team finding the SOC missed, a new log source, an audit requirement, and analysts complaining about a noisy rule. For each request the engineer confirms that the needed telemetry exists, writes the rule logic, tests it against a simulated attack and against recent history, deploys it, and writes the triage guidance analysts will use when it fires.

The work continues after deployment. Environments change, software updates rename processes, and attackers shift techniques, so rules decay. Joint SIEM and SOAR guidance from the Australian Signals Directorate, CISA, the NSA, and partner agencies says that evaluating detection capabilities should identify obsolete alert rules to retire and new rules to test, so detection keeps pace with the threat model, and that testing should confirm the security information and event management (SIEM) platform produces true positives and true negatives. A detection engineering team that never retires a rule is accumulating noise.

What is detection as code?

Detection as code means managing rules the way developers manage application code. Each rule sits in a Git repository with its logic, metadata, ATT&CK mapping, test data, and triage notes. A pull request triggers peer review and automated checks, and a pipeline deploys the approved rule to the SIEM. The repository becomes the system of record, which gives you an audit trail of who changed what and why, a rollback path when a change misfires, and the ability to deploy one rule set to several workspaces or business units.

Microsoft Sentinel supports the pattern directly. Its repositories feature connects to GitHub and Azure DevOps and deploys custom content, including analytics rules, automation rules, hunting queries, parsers, playbooks, and workbooks. Microsoft recommends editing repository-managed content only in the repository, because changes made in the portal are overwritten at the next deployment. That recommendation is the core discipline of detection as code: if production and the repository disagree, the repository wins.

Portability is the second benefit. Sigma, an open project, defines a generic signature format for SIEM systems, and its public repository holds more than 3,000 detection rules. The official Sigma command-line tool and the pySigma library convert those rules into the query languages of specific SIEMs. Teams that write in Sigma, or keep a Sigma version of each rule beside the native one, spend less effort when they change SIEM platforms, because the detection logic does not have to be rediscovered from vendor-specific queries.

How do you decide what to detect?

Start with a threat model: which adversaries target your sector, which techniques they use, and which of your systems they would need to reach. MITRE ATT&CK supplies the shared vocabulary, and our explainer on the MITRE ATT&CK framework covers how teams use the matrix. The defensive side of ATT&CK changed in October 2025, when version 18 replaced the detection notes in each technique with Detection Strategies and added Analytics. The Valid Accounts technique (T1078), for example, now points to detection strategy DET0560, Detection of Valid Account Abuse Across Platforms. Those strategies give engineers a starting design, which they still have to adapt to their own log sources and normal activity.

Next, check the data. A technique you cannot see in telemetry cannot be detected, so the first output of a prioritization exercise is often a list of log sources to onboard, such as command-line logging on endpoints, sign-in logs from the identity provider, or audit logs from the cloud control plane. Then rank the backlog. Put techniques seen in your own incidents and red team reports first, then the initial access, credential theft, and lateral movement techniques common to the actors in your threat model. Avoid chasing a percentage of the whole matrix. A coverage map that counts untested rules shows breadth on paper and tells you nothing about whether the rules fire.

How do you prove a detection works?

Every rule needs two tests before deployment. The first runs a safe simulation of the technique in a test environment and confirms the rule fires. The second runs the rule against recent production data and counts what it would have flagged, which predicts the false-positive load before analysts feel it. Keep both tests in the repository so they rerun whenever the rule, the log source, or the parser changes.

Scheduled exercises close the loop. The ASD and CISA practitioner guidance recommends regular and repeated exercises that test well-known attacker tactics, techniques, and procedures to track improvement over time. Purple team exercises do this well, because the red team executes techniques while the detection engineers watch which rules fire and which stay silent. Our comparison of red, blue, and purple teams explains how those exercises run. Rerun the full test suite after any SIEM migration, because parsers and field names change, and a rule fails silently when a field it depends on is renamed.

What happens to detections during a SIEM migration?

A SIEM migration is a detection engineering project with a platform attached. Every rule in the old SIEM needs one of three decisions: translate it, replace it with a vendor rule that does the same job, or retire it. Start with an inventory that records each rule's ATT&CK mapping, its true-positive rate over the last quarter, and the log sources it depends on. Rules that have not produced a useful alert in that quarter are candidates to retire instead of translate. Vendors now offer tooling for the translation step. Microsoft's SIEM migration tool for Sentinel analyzes Splunk and QRadar detections, including custom ones, and recommends best-fit Sentinel and Defender XDR detections along with the data connectors they need. The same page states that the tool does not install connectors or enable detection rules, so engineers still build, test, and switch on each detection. Run the old and new SIEMs in parallel until the test suite passes on the new platform.

Which metrics show the function is working?

Report these to the CISO quarterly, with the true-positive trend and the tested coverage of priority techniques on the first page. Mean time to detect matters too, but it reflects the whole SOC, while the measures above isolate the detection layer.

How many detection engineers do you need, and should you build or buy?

Staffing depends on the number of log sources, the rate of change in the environment, and how much vendor-supplied content the team can adopt instead of writing. BD Emerson planning range: one to two dedicated detection engineers for a single SIEM with a few dozen log sources, and three to five for a multi-cloud enterprise with several business units and its own threat intelligence function. Below that size, detection work usually falls to senior analysts between shifts, which is where backlogs start.

Managed SOC and managed detection and response (MDR) providers bring rule libraries built across many clients, which covers common techniques quickly. Ask four questions before relying on one. Do the rules run in your SIEM or only in the provider's platform? Do you receive the rule logic, or only the alerts? Does the provider test each rule before deployment? Who owns the custom rules written for your environment when the contract ends? The answers decide whether you are building a detection library or renting one.

Detection engineering is a core part of BD Emerson's SOC as a service. We map detections to MITRE ATT&CK, test them before deployment, and ship every rule with a triage runbook that says what the alert means, what to check first, and when to escalate. The rules run in your tenant on Microsoft Sentinel or a comparable SIEM, so the library we build stays yours. Some clients keep business-hours triage in-house and use us for engineering depth alone.