Adversary emulation produces a per-technique detection gap list — a precise accounting of which ATT&CK techniques produce alerts, which produce logs but no alert, and which produce neither. That gap list is the input. Detection engineering is the discipline that closes those gaps systematically: mapping the required telemetry, authoring detection logic, validating it against adversary behavior, tuning false positives, and iterating until coverage is confirmed. This article covers the detection engineering lifecycle, the Sigma rule standard for portable detection logic, ATT&CK's restructured analytics catalog, gap classification, and the maturity progression from ad-hoc alert writing to continuously validated detection coverage.

This is part 4 in a series on threat-informed defense. Start with part 1.

The Detection Engineering Lifecycle

Detection engineering is not writing SIEM rules. It is a structured lifecycle that begins with understanding what needs to be detected and ends with confirmed, validated detection coverage that has been tested against adversary behavior. The lifecycle operates in six phases, each feeding the next.

1. Requirement — Map the Technique to Observable Behavior

Every detection starts with a specific adversary technique. The requirement phase extracts the observable behaviors — the data artifacts — that the technique produces when executed. ATT&CK v18 provides this through its Data Components mapping: each technique lists the data sources required to detect it, and the specific observable events within those sources that indicate technique execution.

For T1059.001 (PowerShell), the required data components are Process Creation events, Command Execution telemetry, and PowerShell Script Block Logging (Event ID 4104). Without all three, detection coverage for this technique is incomplete. The requirement phase documents exactly which log sources and event IDs are needed before any detection logic is written.

2. Telemetry Verification — Confirm the Data Exists

Before writing a detection rule, verify that every required data source is collected and forwarded to the SIEM. This step catches the most common and most expensive failure mode in detection programs: writing rules against data that does not exist in production. If Sysmon Event ID 10 (Process Access) is not configured, no amount of detection logic for T1055.012 (Process Hollowing) will produce results. Telemetry verification makes this gap visible before engineering time is invested.

3. Author — Write the Detection Logic

With confirmed telemetry, write detection logic that maps to the observable behavior. This is where detection rules move from idea to executable code. The Sigma rule standard — a vendor-neutral YAML format for detection logic — has become the de facto authoring language, with over 3,000 community-maintained rules mapped to ATT&CK techniques.

4. Validate — Test Against Adversary Execution

Execute the corresponding Atomic Red Team test or CALDERA ability for the technique. Record whether the detection fires. If it does not fire, determine whether the failure is in the detection logic, the telemetry pipeline, or the rule configuration. Validation produces a pass/fail result per technique — the core metric of detection engineering.

5. Tune — Reduce False Positives Without Losing True Positives

A detection that fires on every PowerShell execution is technically complete — it detects T1059.001 — but operationally useless. The 26% false positive rate reported by Picus in 2025 reflects detection rules that were written for coverage without tuning for operational signal-to-noise. Tuning adds context filters (parent process, command-line patterns, user context) that separate adversary PowerShell from admin PowerShell while preserving the detection logic.

6. Iterate — Re-Validate After Changes

Every rule change — adding a filter, changing a threshold, modifying a log source — requires re-validation. The iteration phase feeds back to the requirement phase when new ATT&CK releases add techniques or modify existing ones. ATT&CK updates twice per year, and each update may require new detections or modifications to existing ones.

Sigma: The Portable Detection Standard

Sigma is an open standard for detection rule authoring, maintained by the SigmaHQ community. A Sigma rule is a YAML document that describes what to detect in vendor-neutral terms. The rule can then be converted to the query language of any SIEM — Splunk SPL, Microsoft KQL, Elastic KQL, Carbon Black query syntax — through the sigma-cli conversion pipeline. This portability is what makes Sigma the de facto standard for threat-informed detection engineering.

A Sigma rule for detecting T1555.003 (Credentials from Web Browsers) specifies the conditions under which a process accesses browser credential database files. The rule references the file paths (Login Data, key4.db, cookies.sqlite), the process names that legitimately access those files (Chrome, Firefox, Edge), and the detection logic: any process accessing a browser credential database that is not itself a browser. This logic is then converted to the target SIEM's native query language.

The Sigma ecosystem includes over 3,000 rules maintained by the community, mapped to ATT&CK technique IDs. The sigma-cli tool supports conversion to 15+ backend query languages. Organizations that adopt Sigma gain three structural advantages: detection rules are version-controlled alongside infrastructure code, rules are portable across SIEM migrations, and the community-maintained rule library provides a baseline of coverage that teams can extend rather than author from scratch.

ATT&CK Detection Strategies and Analytics

ATT&CK v18 introduced a restructuring of the detection information associated with each technique. The previous flat "Detections" field was replaced with two layers: Detection Strategies (691 total) and Analytics (1,739 total).

Detection Strategies describe what to look for at a conceptual level. For T1055 (Process Injection), the detection strategies include monitoring for process injection API calls, observing cross-process memory access patterns, and detecting unexpected module loads in running processes. These are not detection rules — they are guidance that describes the observable behavior.

Analytics are specific, implementable detection logic tied to particular data sources and event types. Each analytic references a specific Data Component (e.g., Sysmon Event ID 10 — Process Access) and provides the conditional logic for identifying the technique. The separation between strategies and analytics enables teams to work at the appropriate level of abstraction: leaders plan coverage at the strategy level, while engineers implement at the analytic level.

Layer Count Purpose Audience
Detection Strategies 691 Conceptual what-to-look-for guidance per technique Detection engineering leads, SOC managers
Analytics 1,739 Implementable detection logic tied to specific data sources Detection engineers, rule authors
Data Components 106 Minimum required log sources per technique Telemetry engineers, SIEM administrators

This three-layer structure solves a structural problem in detection programs. Without the distinction between strategies and analytics, teams wrote detection rules without understanding whether their logic was at the right level of abstraction. Analytics provide the implementation detail; strategies provide the coverage narrative. Planning coverage at the strategy level produces a coverage map that leadership can review. Implementing at the analytic level gives engineers specific, testable rules.

Gap Classification: Telemetry, Detection, or Tuning

When adversary emulation reveals that a technique produced no alert, the root cause falls into one of three categories. Misclassifying the gap type wastes resources — fixing the wrong type produces no improvement in coverage.

Telemetry Gaps

The required log source does not exist or is not forwarded to the SIEM. This is the most common gap type and the most foundational. A detection rule for T1055 (Process Injection) requires Sysmon Event ID 10 (Process Access) and Event ID 7 (Image Loaded). If Sysmon is not deployed on the endpoint, or if Event ID 10 is not configured to forward to the SIEM, the detection rule will never have data to evaluate. Telemetry gaps must be resolved first — no detection logic can compensate for missing data.

Detection Gaps

The telemetry exists but no rule evaluates it. The log source is present, the events are flowing to the SIEM, and no detection logic triggers on the adversary behavior. Detection gaps are resolved by authoring new Sigma rules (or native SIEM queries) that evaluate the relevant events against the condition patterns described in the ATT&CK analytics.

Tuning Gaps

A detection rule exists but is not producing useful output. The rule may be disabled due to high false positive rates, thresholded to a level that misses relevant events, or scoped to exclude the relevant log source. Tuning gaps are the most insidious — they create a false sense of coverage. A rule that exists in the repository but is suppressed or misconfigured is not providing detection. Tuning gaps require refining the rule logic to reduce false positives while preserving true positive detection.

Gap Type Root Cause Resolution Typical Effort
Telemetry gap Log source not collected or not forwarded Deploy log source, configure forwarding pipeline Days to weeks (infrastructure change)
Detection gap No rule evaluates available telemetry Author and deploy Sigma rule or native query Hours to days (logic authoring)
Tuning gap Rule exists but disabled, thresholded, or mis-scoped Refine logic, adjust thresholds, re-enable Hours to days (iterative tuning)

The Picus Blue Report 2025 found that of the 76% of techniques that produced no alert, approximately 40% were telemetry gaps, 35% were detection gaps, and 25% were tuning gaps. The distribution varies by technique category: cloud techniques have a higher telemetry gap rate (Azure AD audit logs are frequently not exported), while endpoint techniques have a higher tuning gap rate (PowerShell and process creation rules are often suppressed due to false positives from admin activity).

Enabling Missing Telemetry

Resolving telemetry gaps requires enabling log sources on endpoints, servers, and cloud platforms. The most impactful telemetry sources for detection engineering, mapped to the techniques they enable, are:

Telemetry Source Key Event IDs Techniques Enabled Deployment Effort
Sysmon 1, 7, 10, 13 T1055, T1059, T1566, T1053, T1106 Medium — GPO or config management deployment
PowerShell ScriptBlock Logging 4104 T1059.001, T1059.003, T1086 Low — Group Policy or registry key
Azure AD / Entra ID Audit Sign-in logs, Audit logs T1078.011, T1136.003, T1098 Medium — export via diagnostic settings to SIEM
Windows Security Events 4624, 4625, 4648, 4688, 4698 T1078, T1053, T1070, T1087 Low — enable via Group Policy
Cloud Audit Logs (AWS CloudTrail) AssumeRole, ConsoleLogin, API calls T1078.004, T1537, T1089 Low — enable multi-region trail to S3

The sequence matters. Deploy Sysmon and PowerShell ScriptBlock Logging first — they enable detection for the top techniques (T1059, T1055, T1555) that represent the highest volume of adversary behavior. Then enable Windows Security Events for authentication and task scheduling coverage. Cloud audit logs follow for organizations with cloud attack surface. Each deployment should be followed by verification: confirm the events appear in the SIEM before investing in detection logic that depends on them.

Detection-as-Code

Detection engineering benefits from the same practices that improved software reliability: version control, peer review, automated testing, and continuous deployment. Detection-as-code applies these practices to detection rules.

In a detection-as-code workflow, Sigma rules are stored in a Git repository. Rule changes follow pull request workflows with peer review. The sigma-cli tool converts rules to the target SIEM query language, and CI/CD pipelines deploy validated rules to production. Automated testing executes Atomic Red Team atomics against deployed rules, recording pass/fail results in a detection coverage dashboard.

The structural advantage is traceability. Every detection rule has a provenance: when it was written, who reviewed it, which ATT&CK technique it covers, and whether it passed its most recent validation test. When a rule fires a false positive, the tuning change is a commit with an explanation. When an ATT&CK update adds a new technique, the gap is visible because no rule in the repository covers the new technique ID. Detection-as-code turns the detection rule inventory from an undocumented collection of SIEM queries into a managed, versioned, and tested asset.

Detection Maturity Progression

Organizations move through detectable stages as their detection engineering practice matures. The CTID detection engineering maturity model defines four levels:

Level 1 — Ad-Hoc Detection

Detection rules are written reactively in response to incidents or regulatory requirements. Rules are authored directly in the SIEM's query language without version control. No formal mapping to ATT&CK techniques exists. Telemetry gaps are discovered only when a detection fails to fire during an incident. Most organizations at this level rely on vendor-provided detection packages without customization.

Level 2 — Mapped Detection

Rules are mapped to ATT&CK technique IDs. A coverage map exists showing which techniques have detections and which do not. Telemetry sources are inventoried. Adversary emulation validates a subset of detections — typically the top-10 techniques. The Sigma rule standard may be adopted for portability, but detection-as-code practices are not yet in place.

Level 3 — Validated Detection

All detection rules are validated through adversary emulation. Telemetry gaps are classified and prioritized. Detection-as-code practices are in place — rules are version-controlled, peer-reviewed, and deployed through CI/CD. False positive rates are tracked per rule. The organization runs quarterly detection engineering sprints aligned with threat group emulation cycles.

Level 4 — Continuously Validated

Detection validation is automated and continuous. Every rule change triggers a re-validation pipeline that executes the relevant Atomic Red Team tests against the modified rule. Telemetry completeness is monitored — if a log source stops forwarding events, the affected detection rules are automatically flagged as unreliable. Coverage maps update in near-real-time. ATT&CK releases are incorporated within weeks, not months.

Dimension Level 1 — Ad-Hoc Level 2 — Mapped Level 3 — Validated Level 4 — Continuous
Rule authoring SIEM-native queries, no versioning Sigma rules, initial ATT&CK mapping Detection-as-code, peer review, CI/CD Automated authoring from threat intel
Validation None — rules fire on production traffic Adversary emulation for top techniques Full emulation validation per threat group Automated re-validation on every change
Telemetry Unknown gaps — discovered during incidents Inventoried with known gaps Classified (telemetry/detection/tuning) Monitored — alerts on source failure
False positive mgmt Suppress or disable noisy rules Track FP rate per rule Tune with context filters, track precision/recall Auto-tune with behavioral baselines
ATT&CK alignment No mapping Technique-level mapping Sub-technique-level mapping with analytics Auto-updated on ATT&CK releases
Cadence Reactive — incident-driven Quarterly detection sprints Aligned with emulation cycles Continuous — detection backlog managed like product backlog

False Positive Reduction Strategies

The Picus Blue Report 2025 measured a 26% false positive rate across security tools — meaning roughly one in four alerts does not represent genuine adversary behavior. Left unmanaged, false positive fatigue erodes analyst trust and delays response to genuine detections. Reduction strategies that preserve true positive coverage include:

  • Context filters. Add parent process, user context, or network zone conditions. A PowerShell execution detection (T1059.001) that fires on every PowerShell launch becomes operationally useful when filtered to exclude known admin accounts, approved parent processes, and management tools. The rule still detects the technique — it narrows the result set to the context where the technique is suspicious.
  • Allowlisting known benign patterns. Many legitimate administrative tools execute techniques that overlap with adversary behavior. Document the known-good patterns for your environment and exclude them from the detection rule. This is environment-specific — the allowlist for a development team with frequent PowerShell usage differs from the allowlist for a finance department that rarely uses command-line tools.
  • Correlation over single-event detection. Replace single-event rules with multi-event correlation. A single execution of whoami (T1033 — System Owner/User Discovery) is admin activity. A sequence of whoami → ipconfig → net user → credential access within a 60-second window is adversary reconnaissance. Correlation rules produce fewer alerts but higher fidelity.
  • Threshold tuning with burst detection. Some techniques are volume-dependent. Brute force authentication (T1110) is detectable through multiple failed logins, but the threshold between admin typos and actual brute force varies by environment. Set thresholds at the 95th percentile of normal login failure rates and add burst detection logic that triggers on deviation from baseline within a time window.

From Emulation Output to Detection Sprint

The adversary emulation cycle from Part 3 produces a per-technique detection gap list. Detection engineering operationalizes that output. The workflow connects the two:

  1. Receive the emulation report. For each technique tested, the report provides: technique ID, test result (alert fired / log only / no visibility), execution context, and observed telemetry.
  2. Classify each gap. Telemetry gap → deploy the missing log source. Detection gap → author a new rule. Tuning gap → refine the existing rule.
  3. Prioritize by technique frequency. Gaps in the top-10 techniques (which represent 93% of adversary behavior) receive immediate attention. Gaps in rare techniques are placed in the backlog.
  4. Sprint. Allocate a timeboxed sprint (typically 2 weeks) to close the top-priority gaps. At the end of the sprint, re-run the relevant Atomic Red Team tests to confirm closure.
  5. Update the coverage map. Move closed gaps from "open" to "validated" status. The coverage map now reflects actual, tested coverage rather than assumed coverage.

This loop — emulate, classify, prioritize, sprint, validate — turns detection engineering from a reactive activity into a structured, measurable process that directly reduces the percentage of techniques without detection coverage.

Exceptions and Limits

Detection engineering for technique coverage has boundaries where its methodology does not apply or produces diminishing returns.

Living-off-the-land techniques. Techniques like T1078 (Valid Accounts) and T1059 (Command and Scripting Interpreter) are used by both adversaries and legitimate administrators. Technique-level detection for these behaviors produces high false positive rates regardless of tuning. Behavioral analytics — modeling normal admin patterns and detecting deviations — is the appropriate approach, but it operates outside the ATT&CK detection-as-code framework. The coverage map for LotL techniques should reflect this distinction: mark them as "behavioral analytics required" rather than "detection gap."

Zero-day and novel techniques. Detection engineering maps to known ATT&CK techniques. Novel techniques not yet cataloged in ATT&CK have no technique ID, no Analytics, and no Sigma rules. Threat-informed detection is inherently reactive to observed behavior. Organizations that face advanced persistent threats using novel techniques must supplement technique-level detection with anomaly detection and threat hunting.

Cloud and identity coverage gaps. ATT&CK's analytics coverage for cloud-native techniques (OAuth abuse, IAM role assumption, storage misconfiguration) lags behind endpoint coverage. The v18 restructuring added cloud analytics, but the count remains low compared to the Windows endpoint analytics that represent the bulk of the catalog. Cloud-heavy organizations should expect to author a larger proportion of custom detections rather than relying on community Sigma rules.

Resource constraints at smaller teams. The detection engineering lifecycle — requirement, telemetry, author, validate, tune, iterate — presupposes dedicated detection engineering capacity. Teams without a dedicated detection engineer should start at Level 2 (mapped detection) and prioritize the top-10 techniques. Attempting to validate all 200+ techniques without dedicated capacity produces a map that is broad but shallow — many techniques nominally covered but few actually tested.

Honest Assessment

Dimension Rule-Authoring Without Validation Detection Engineering with Validation
Coverage confidence Low — rules exist but are untested High — rules validated against adversary behavior
False positive rate 26% average (Picus 2025) Reduced — context filters and correlation remove known benign patterns
Telemetry visibility Unknown — gaps discovered during incidents Classified — telemetry/detection/tuning gaps documented per technique
Rule maintainability Ad-hoc — SIEM-native queries, no versioning Detection-as-code — version-controlled, reviewed, tested
Time to coverage Fast to write, slow to verify — rules deployed but not confirmed Slower per rule, but each rule is confirmed effective
Adaptability to new threats Reactive — new technique → new rule, no re-validation Structured — ATT&CK update → gap analysis → sprint cycle

Actionable Takeaways

  • Audit telemetry before writing any detection rules. For each technique in your threat group profile, verify that the required data components are collected and forwarded to the SIEM. This single step eliminates the 40% of gaps caused by missing telemetry. Deploy Sysmon and PowerShell ScriptBlock Logging first — they cover the top techniques for the least effort.
  • Adopt Sigma as your detection authoring standard. Author rules in Sigma YAML, convert to your SIEM's native query language through sigma-cli, and store rules in a Git repository. This provides version control, portability, and access to the 3,000+ community-maintained rules mapped to ATT&CK techniques.
  • Classify every gap before fixing it. When adversary emulation produces no alert, determine whether the cause is a telemetry gap, a detection gap, or a tuning gap. Fixing the wrong type wastes resources — adding more Sigma rules to a telemetry gap produces no alerts, while deploying new log sources to a detection gap produces data but no detections.
  • Start with Level 2 maturity and the top-10 techniques. Map detection rules to ATT&CK technique IDs. Validate the top-10 techniques (T1055, T1059, T1082, T1083, T1555, T1071, T1566, T1078, T1105, T1053) through Atomic Red Team tests. This creates a validated coverage map for the techniques that represent 93% of observed adversary behavior while keeping the scope manageable.
  • Run detection engineering sprints aligned with emulation cycles. After each adversary emulation round, classify gaps, prioritize by technique frequency, and execute a 2-week sprint to close the highest-priority gaps. Re-validate at the end of the sprint. This transforms detection engineering from reactive alert writing into a structured, measurable process.

This is part 4 in a series on threat-informed defense. Start with part 1. Upcoming installments will cover purple teaming operations and AI-augmented threat profiling.