A SIEM full of default rules generates alerts, not security. Detection engineering treats detections like software: designed against real adversary behaviour, tested, version-controlled and continuously improved. MITRE ATT&CK provides the common language for that work.
1. Start from your threat model
ATT&CK catalogues hundreds of techniques. Don't try to cover them all. Start with those most relevant to your likely adversaries — for most organizations, ransomware operators and business email compromise actors. Common priorities include:
- Valid Accounts (T1078) and Phishing (T1566) for initial access.
- OS Credential Dumping (T1003) and Remote Services (T1021) for escalation and lateral movement.
- Inhibit System Recovery (T1490) and Data Encrypted for Impact (T1486) — late-stage ransomware activity where speed of response is critical.
2. Map what you already have
Inventory existing detections and map each to the technique it addresses. Be honest about quality: a rule that fires on one known tool is not the same as coverage of the underlying technique. The gaps this exercise reveals become your backlog.
3. Get the right telemetry
Detections are limited by data. Confirm you're collecting what your priority techniques need: EDR process and command-line telemetry, Windows security events and Sysmon where appropriate, identity provider sign-in logs, cloud audit logs and DNS or proxy logs. Check retention periods against your investigation needs.
4. Write detections as code
- Store rules in version control, with a description, the ATT&CK technique, data sources and expected false positives.
- Peer-review changes and deploy them through a pipeline, not by hand in the console.
- Prefer behavioural logic — parent-child process relationships, unusual authentication patterns — over brittle indicators like file hashes.
5. Test continuously
Validate detections by emulating the technique in a controlled environment, for example with the open-source Atomic Red Team tests, and confirm the alert fires with useful context. Re-test after changes to logging, EDR agents or infrastructure, which silently break detections more often than people expect.
6. Tune and measure
- Track false-positive rates per rule and tune or retire noisy detections.
- Measure time to detect and time to triage for real incidents and exercises.
- Report coverage as tested techniques, not coloured cells on a heat map.
The goal isn't the most rules. It's reliable, well-understood detections for the behaviours that matter most — and analysts who trust them.