Detection Engineering with MITRE ATT&CK: Writing Rules That Actually Work

What Is Detection Engineering?

Detection engineering is the discipline of designing, building, testing, and maintaining the detection logic that powers your SIEM. It bridges threat intelligence and operational security, translating knowledge of adversary behavior into automated, reliable detections that alert your SOC when those behaviors occur.

Unlike signature-based security that reacts to known IOCs, detection engineering builds behavior-based logic that detects techniques regardless of specific tooling an attacker uses. This is where MITRE ATT&CK becomes essential.

A detection rule is a hypothesis about adversary behavior, encoded as logic, and validated against real data. The best rules are specific, testable, and tuned.

Why MITRE ATT&CK Is the Foundation

The MITRE ATT&CK framework provides a community-maintained knowledge base of adversary tactics, techniques, and procedures (TTPs). For detection engineers it provides a universal taxonomy, detection coverage mapping via ATT&CK Navigator, prioritization guidance, and threat intelligence alignment.

Anatomy of a High-Quality Detection Rule

Every detection rule must answer: What behavior is this detecting? What data source is required? What is the logic? What is the severity? What is the analyst response?

Splunk SPL Detection Examples

T1053.005 - Suspicious Scheduled Task Creation

index=windows_events EventCode IN (4698, 4702)
| where NOT match(TaskName, "^(Microsoft|Windows|Adobe|Google)")
| stats count by Computer, SubjectUserName, TaskName
| eval severity="HIGH", technique="T1053.005", tactic="Persistence"

T1110.001 - Brute Force Login Detection

index=windows_events EventCode=4625
| bucket _time span=5m
| stats count by _time, TargetUserName, IpAddress
| where count >= 10
| eval severity="MEDIUM", technique="T1110.001"

T1021.001 - Lateral Movement via RDP from External IP

index=windows_events EventCode=4624
| where LogonType=10
| where NOT match(IpAddress, "^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)") 
| stats count by Computer, TargetUserName, IpAddress
| eval severity="HIGH", technique="T1021.001"

Sigma Rules - Platform-Agnostic Detection

Sigma is the de facto standard for platform-agnostic detection rules. Writing in Sigma means your rule converts to Splunk SPL, KQL, Elasticsearch DSL, or any other SIEM query language automatically.

title: Suspicious PowerShell Encoded Command
id: a2f04a67-0b02-4b2b-b6e8-d1e5b8a24f9c
status: production
description: Detects PowerShell execution with encoded commands
author: Asad Noor
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  product: windows
  category: ps_script
detection:
  selection:
    ScriptBlockText|contains:
      - '-EncodedCommand'
      - '-enc '
  condition: selection
level: high

Tuning for Low False Positives

At PostEx, we reduced false positives by 40% through systematic tuning: baseline normal behavior before enabling alerts, whitelist legitimate admin processes, enrich alerts with asset criticality and user role, use statistical anomaly rules over exact pattern matches, and version-control all rule changes in Git.

Detection-as-Code Pipeline

Git Repository (Sigma rules)
    |
Pull Request Review
    |
Automated Tests (syntax + test data)
    |
Conversion: Sigma to SPL/KQL/DSL
    |
Staging Deployment (1 week audit mode)
    |
Production with alerting enabled

Tactic	Technique	Data Source	Coverage
Initial Access	T1190 Exploit Public App	WAF Logs	High
Execution	T1059 PowerShell	EDR, Windows Events	High
Persistence	T1053 Scheduled Tasks	Windows Events 4698	High
Lateral Movement	T1021 Remote Services	Firewall, NetFlow	High
Exfiltration	T1041 C2 Channel	DNS, HTTP Proxy	Medium