Detection engineering with MITRE ATT&CK and Sigma

Most SOCs do not have a detection problem so much as a useful detection problem: thousands of low-fidelity alerts, a handful of which are real, and analysts trained mostly to close tickets quickly. Detection engineering is the discipline of treating detections as code — designed, tested, versioned, and measured against real adversary behaviour. Done well, it produces fewer, better alerts that map cleanly to what attackers actually do. MITRE ATT&CK and Sigma are the two open standards that make this practical across vendors.

What MITRE ATT&CK actually gives you

MITRE ATT&CK is a curated knowledge base of tactics (the "why" — e.g. Persistence, Credential Access, Lateral Movement) and techniques (the "how" — e.g. T1003.001 LSASS Memory, T1059.001 PowerShell, T1078 Valid Accounts). It is descriptive, not prescriptive: it documents what real adversaries have been observed doing, with references to specific groups, campaigns, and tooling.

Two things make it useful in practice:

• A shared vocabulary – Instead of arguing whether "PowerShell encoded command" is a detection, an analytic, or a use case, the team agrees it is T1059.001 and moves on.
• Coverage measurement – Mapping every detection rule to one or more techniques (and sub-techniques) lets you see, on a single heatmap, where you have coverage and where you are blind. Tools like ATT&CK Navigator make this easy to maintain.

A common pitfall is treating ATT&CK as a checklist — "we have a rule for every technique, therefore we are covered". Coverage of a technique is not binary; T1059 PowerShell can be detected ten different ways with very different fidelity. ATT&CK is a map, not a score.

Log sources: you can only detect what you collect

Detection engineering lives or dies by the quality of telemetry. Before writing rules, get the right data flowing.

• Endpoint – Sysmon on Windows (config from SwiftOnSecurity or Olaf Hartong is a sensible starting point), auditd or auditbeat on Linux, plus EDR telemetry. Process creation with full command line, parent-child relationships, file writes, registry changes, image loads, network connections, and named pipes.
• Authentication – Windows Security event logs from DCs, member servers, and workstations (especially 4624, 4625, 4672, 4688, 4769, 4776), wtmp/auth.log on Linux, plus your identity provider (Entra ID sign-in and audit logs, Okta system log, Google Workspace).
• Cloud audit – CloudTrail (AWS), Activity Log + Defender (Azure), Admin Activity (GCP). These see API calls that endpoint telemetry never will.
• SaaS and email – Microsoft 365 unified audit log, Google Workspace audit, GitHub audit log, Salesforce setup audit, Slack audit (for enterprise).
• Network – DNS query logs, proxy logs, NetFlow/Zeek, TLS metadata (JA3/JA4 fingerprints). Encrypted traffic still produces useful patterns.
• Application – Web server, WAF, and application logs with consistent fields (user, source IP, request, response code).

Two non-negotiables: parse logs into a consistent schema (ECS, OCSF, or your SIEM's own model) so the same field name means the same thing everywhere; and validate that logs are actually arriving, end-to-end, with a "canary" event you trigger and confirm shows up.

Writing Sigma rules

Sigma is a generic, vendor-neutral YAML format for describing log-based detections. A Sigma rule can be converted into the query language of most SIEMs (Splunk SPL, Microsoft KQL, Elastic Lucene/EQL, Sentinel, Chronicle, etc.) with sigmac or modern tools like pySigma. The benefit is portability and a thriving community of open detections (SigmaHQ).

A minimal Sigma rule looks like this:

title: Suspicious PowerShell Download Cradle
id: 1a2b3c4d-...-...

status: experimental

description: Detects common PowerShell one-liners used to download and execute payloads.

references:

  - https://attack.mitre.org/techniques/T1059/001/

author: Your Team

date: 2026/05/20

tags:

  - attack.execution

  - attack.t1059.001

logsource:

  category: process_creation

  product: windows

detection:

  selection:

    Image|endswith: '\powershell.exe'

    CommandLine|contains|all:

      - 'Net.WebClient'

      - 'DownloadString'

  condition: selection

falsepositives:

  - Legitimate admin scripts that fetch payloads from internal repos

level: high

Good Sigma rules share a few habits: every rule has a stable ID, a clear description, ATT&CK tags, an honest falsepositives section, and a tested severity. They detect behaviour rather than specific strings ("any process spawned by winword.exe that is not in a small allowlist" generalises better than "the literal name payload.exe"). They are version-controlled in a git repo, reviewed like any other code, and shipped through CI that runs them against historical data to estimate noise.

A development workflow that actually scales

Detection engineering benefits enormously from treating rules like software.

• Detection-as-code – Rules live in a git repository, with branches, pull requests, and reviewers. Changes go through CI that lints YAML, converts rules to the SIEM's query language, and runs them against a historical sample to estimate hit rate before merge.
• Test data – Maintain a corpus of "true positive" events (from purple-team exercises, public ATT&CK Evals data, or BOTS-style public datasets) and "expected benign" events. A new rule should fire on the first and stay quiet on the second.
• Adversary emulation – Use Atomic Red Team, Caldera, or commercial BAS tools to actually run the techniques you claim to detect, in a controlled environment, and prove the rule fires end-to-end. This is the only honest way to know your detections work.
• Tuning loop – When a rule is too noisy, the answer is rarely "raise the threshold". Look at why it is noisy, refine the logic, add context (asset criticality, user role, time of day), or split it into a high-fidelity "alert now" rule and a low-fidelity "feed into UEBA" rule.
• Retire dead rules – Rules that have not fired in 12 months on a true positive, or that fire daily with no action, should be retired or rewritten. Detection debt is real.

Metrics worth tracking

Avoid vanity metrics ("number of rules", "events per second"). Useful detection metrics focus on outcomes.

• True-positive rate per rule – Out of all alerts that rule generates, how many were real incidents or worth investigating? Aim to retire or rewrite rules below a sensible floor (e.g. <5%).
• Mean time to detect (MTTD) – For confirmed incidents, how long between the attacker's first observed action and the first triggered alert. Compare to mean time to acknowledge and to contain.
• ATT&CK coverage trend – Heatmap of techniques covered, weighted by likelihood (ATT&CK Sightings, your industry's threat profile) rather than treating all techniques equally.
• Detection latency – How quickly a new technique seen in the wild becomes a deployed, tested rule. This measures the engineering pipeline, not just the catalogue.
• Analyst feedback – Built into the SOC workflow: every closed alert tags whether the detection was useful, noisy, or actively misleading. Feed that back into the engineering backlog.

Good detection engineering is unglamorous: log hygiene, careful rule design, honest testing, and a tight feedback loop with the SOC. The reward is alerts that analysts actually trust, coverage you can defend with data, and detections that keep up with the way real attackers work — which is exactly what ATT&CK and Sigma are designed to enable.