Building a Detection Engineering Program with MITRE ATT&CK

Detection engineering is no longer optional. As adversaries adopt increasingly sophisticated tradecraft — living off the land, abusing legitimate tools, chaining low-severity events into high-impact attacks — reactive security operations aren’t enough. You need a systematic program that maps your detection capability to real adversary behavior.

The MITRE ATT&CK framework gives you that map. Here’s how to use it to build a detection engineering program that actually works.

Step 1: Baseline Your Current Coverage

Before writing a single new detection rule, you need to know where you stand. Most SOC teams are surprised by how few ATT&CK techniques they actually cover.

Start by inventorying your existing detection rules — from your SIEM (Sentinel, Splunk, Elastic), your EDR (Defender, CrowdStrike, SentinelOne), and any custom rules your team has written. Map each rule to the ATT&CK technique it detects.

You’ll likely find:

• Clustering around execution and initial access — lots of rules for PowerShell, phishing, and malware execution
• Sparse coverage for persistence and defense evasion — techniques like T1546 (Event Triggered Execution) and T1070 (Indicator Removal) often have no dedicated detections
• Almost no coverage for credential access beyond basic brute force — techniques like T1003.001 (LSASS Memory) and T1558 (Steal or Forge Kerberos Tickets) require specific detection logic

Use a tool like the df00tech ATT&CK Matrix to visualise your coverage. Seeing empty cells in the matrix makes coverage gaps concrete — and makes the case for investment in detection engineering much easier.

Step 2: Prioritise by Threat Intelligence

You can’t detect everything on day one. Prioritise based on what’s actually being used against organisations like yours.

Three prioritisation inputs matter:

1. Your threat landscape. Which threat actors target your industry? APT groups targeting financial services use different techniques than those targeting healthcare or government. MITRE’s threat group pages map actors to techniques — use this to weight your priorities.

2. Prevalence in the wild. Some techniques appear in nearly every intrusion. T1059.001 (PowerShell) is used by everything from commodity malware to nation-state operations. T1105 (Ingress Tool Transfer) is the universal second-stage delivery mechanism. These high-frequency techniques should be detected first, regardless of your industry.

3. Your data sources. You can only detect what you can see. If you don’t collect Sysmon Event ID 10 (ProcessAccess), you can’t detect LSASS credential dumping. If you don’t have Azure AD sign-in logs, you can’t detect cloud-based password spraying (T1110.003). Map your available data sources to ATT&CK techniques to identify which detections are feasible today versus which require new telemetry.

A practical approach: rank techniques by (threat_relevance × prevalence × data_availability) and work down the list.

Step 3: Write Detections That Work in Production

The biggest failure mode in detection engineering isn’t missing techniques — it’s writing rules that generate so many false positives that analysts disable them.

Production-quality detections require:

Specificity over breadth. A rule that alerts on “any PowerShell execution” is useless. A rule that detects PowerShell with encoded commands, AMSI bypass attempts, or download cradles from non-standard parent processes is actionable. Our T1059.001 detection demonstrates this approach — it evaluates multiple specific suspicious patterns rather than flagging all PowerShell activity.

False positive documentation. Every detection should list known false positive sources. Software deployment tools, monitoring agents, IT automation — these all trigger security rules. Document them explicitly so analysts can quickly triage.

Severity calibration. Not every detection deserves a “critical” severity. LSASS memory access from an unknown process? Critical. A scheduled task created by a standard user? Medium. Severity should reflect the actual risk, not the theoretical worst case.

Response context. A detection that fires without guidance on what to do next wastes analyst time. Every rule needs at minimum: what to check first, when to escalate, and what containment actions to take. This is where df00tech’s Pro tier adds significant value — every detection includes a complete response playbook.

Step 4: Validate with Atomic Testing

Writing a detection rule isn’t enough. You need to prove it fires when the technique is actually used.

Atomic Red Team tests — small, focused tests that simulate a single ATT&CK technique — are the standard approach. For each detection:

1. Deploy the detection rule to your SIEM/EDR
2. Execute the corresponding atomic test on a test endpoint
3. Verify the alert fires within your expected timeframe
4. Check that the alert contains enough context for triage

If the detection doesn’t fire, debug the gap: is the telemetry being collected? Is the query logic too narrow? Are log shipping delays causing the lookback window to miss?

Test quarterly at minimum. Detection drift is real — OS updates, EDR version changes, and log schema modifications can silently break detections.

Step 5: Measure and Improve

Track three metrics over time:

Coverage percentage. What fraction of ATT&CK techniques (weighted by your prioritisation) do you have detections for? Track this monthly. If it’s not trending up, your program isn’t working.

Mean time to detect (MTTD). How quickly do your detections fire after a technique is executed? This measures the end-to-end pipeline from telemetry collection through SIEM processing to alert generation. Under 15 minutes for critical techniques; under an hour for high.

False positive rate. What percentage of alerts from each detection are true positives? Detections below 30% true positive rate need tuning or rewriting. Detections above 80% are well-calibrated.

Review these metrics in a monthly detection engineering review. Retire or rewrite underperforming detections. Add new ones as your coverage baseline improves.

The 80/20 of Detection Engineering

If you’re starting from scratch, focus on these technique categories first — they appear in the majority of real-world intrusions:

1. Execution — PowerShell (T1059.001), command-line abuse, WMI
2. Credential Access — LSASS dumping (T1003.001), password spraying (T1110.003), Kerberoasting
3. Persistence — Scheduled tasks (T1053.005), registry run keys, services
4. Defense Evasion — Log clearing (T1070.001), signed binary proxy execution (T1218), obfuscation
5. Lateral Movement — RDP (T1021.001), SMB (T1021.002), WinRM

These 15-20 sub-techniques account for a disproportionate share of attacker activity. Detect them well before chasing the long tail.

Accelerating with df00tech

Building a detection engineering program from scratch is a multi-quarter effort. df00tech accelerates this by providing the complete detection library — 704 production-ready KQL and SPL rules with response playbooks and atomic tests.

Instead of spending months writing queries, your team can focus on deploying detections, tuning for your environment, and building operational processes around them. Start with the free tier to explore the full query library, or upgrade to Pro for complete playbooks and testing coverage.

Browse all detections on the ATT&CK Matrix and start building your program today.