Detection engineering: writing, testing and mapping detections

What detection engineering is

Detection engineering is the discipline of building and maintaining the rules that turn logs into alerts. In immature SOCs, rules are switched on from vendor packs and never reviewed. In mature ones, every rule has an owner, a purpose, a test and a record of how well it performs. This approach is often called detection as code: rules live in version control, changes are reviewed, and deployment is automated.

Writing a good detection

Start with a hypothesis about attacker behaviour, not a single indicator. "Attackers dump credentials from LSASS memory" is a better starting point than "block this one hash", because it still works when the tool changes. Then ask which data source shows that behaviour (for example Sysmon process access events or EDR telemetry) and whether you actually collect it.

Good detections are:

• Specific enough to avoid drowning analysts, but not so narrow that a renamed tool slips past.
• Explained: each has a short runbook saying why it matters and how to triage it.
• Tested: you have proved it fires on the behaviour and noted known false positives.

Sigma: a common rule language

Sigma is an open, YAML-based format for describing log detections independently of any SIEM. Converters such as the pySigma-based sigma-cli translate a rule into Splunk, KQL, Elastic and other query languages. A simplified example that flags an office application starting PowerShell:

title: Office application spawning PowerShell
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
    Image|endswith: '\powershell.exe'
  condition: selection
falsepositives:
  - Approved macros used by finance
level: high
tags:
  - attack.execution
  - attack.t1059.001

The tags link the rule to MITRE ATT&CK technique T1059.001 (PowerShell). Public repositories hold thousands of community Sigma rules, which are a useful starting point, but always test and tune them for your environment.

Testing, mapping and measuring

1. Reproduce the behaviour safely in an isolated lab you own. Open frameworks such as Atomic Red Team provide small, documented tests mapped to ATT&CK techniques.
2. Confirm the logs arrive and the rule fires; save the test as a regression check.
3. Run the rule over several weeks of historical data to estimate false positives before going live.
4. Map each rule to ATT&CK techniques and keep a coverage view; tools such as ATT&CK Navigator can colour in what you detect.
5. Track each rule's alert count and true positive rate, and retire or fix rules that only create noise.

Tip: coverage maps can mislead. One weak rule against a technique does not mean the technique is "covered"; record confidence too.