TL;DR

Most organizations map their SIEM alerts and EDR rules to MITRE ATT&CK techniques and present a heatmap as proof of detection coverage. It’s theater. A heatmap that shows green for every technique means nothing if no technique produces an alert. The right starting point is attacker behavior: what happens on the box between compromise and exfiltration, what data that behavior generates, and which logs actually capture it. Map the behavior first, then figure out which tools read that data. That’s the difference between a matrix that looks good and a matrix that works when the attacker hits.

The heatmap problem

Walk into most security ops reviews and you’ll see the same slide: a giant ATT&CK heatmap with colored cells for every technique. Green means “we detect it.” Yellow means “partial.” Red means “blind.” The matrix is impressive. It’s also misleading.

The problem is backward mapping. You start with your toolset — SIEM, EDR, firewall, proxy, DNS logs — and check which ATT&CK techniques each tool covers. Technique X has Windows event log → green. Technique Y has proxy logs → yellow. Technique Z has no direct log source → red. Fill in the grid, present to leadership, move on.

But here’s what that misses: techniques share log sources. Two dozen ATT&CK techniques all write to the same Windows event logs. A proxy covers a dozen techniques that share the same data model. Your heatmap will show green for every technique that touches those logs, even if the alert logic is tuned to catch only one of them. The green cells overcount detection because they count data availability, not alert coverage.

Worse, the heatmap doesn’t tell you what’s not generating an alert. If your SIEM ingests all 462 ATT&CK techniques’ worth of logs but has 14 active detection rules, the heatmap is green across 450 techniques and yellow or red across the remaining 12. You look well-covered. You’re not.

Map behavior, not tools

ATT&CK is a matrix of attacker behaviors, not a matrix of data sources. The right workflow starts from the behaviors and works backward to the data that captures them.

Step 1: Pick the kill chain. Don’t try to cover all 14 tactics at once. Pick one attack chain — say, a phishing email that leads to lateral movement via RDP and ends with credential theft from the LSASS process.

Step 2: List the behaviors in that chain. Each step on the chain is an observable behavior:

  1. User receives and opens email attachment (Email gateway)
  2. Office Word spawns mshta.exe (Process creation)
  3. mshta.exe downloads a DLL from cdn.example.com (DNS + HTTP)
  4. DLL writes to %TEMP% directory (File creation)
  5. DLL registers a COM object (Registry key creation)
  6. COM object spawns cmd.exe with /c whoami (Process creation with specific arguments)
  7. cmd.exe connects back to 10.0.5.20:4444 (Network connection)
  8. wmiprvse.exe spawns powershell.exe (Process parent-child)
  9. PowerShell reads LSASS memory (Process access)
  10. PowerShell exfiltrates to cdn.example.com via HTTPS (DNS + HTTP)

Step 3: List the data each behavior generates. This is where most orgs stop — they match step 2 to step 1’s toolset. But the data list is the real inventory:

Behavior Windows Event Log Process Creation (ETW) File Creation (ETW) Network Connection (ETW) DNS Query Log HTTP Proxy Log LSASS Access
Email opened 4663 on .docm Yes No No No No No
mshta.exe spawns Yes Yes No No No No No
DLL downloaded Yes Yes No Yes Yes Yes No
DLL written to TEMP Yes No Yes No No No No
COM registered Yes No No No No No No
cmd.exe with whoami Yes Yes No No No No No
Back connection Yes Yes No Yes Yes Yes No
wmiprvse → powershell Yes Yes No No No No No
PowerShell reads LSASS Yes Yes No No No No Yes
Exfiltration Yes Yes No Yes Yes Yes No

Step 4: Identify the gaps. The table above shows that:

  • Email gateway data (Step 1) isn’t in any Windows log
  • File creation on disk (Step 4) only appears in ETW, not in Windows Event Logs
  • LSASS access (Step 9) needs WMI or ETW — most basic SIEM agents don’t capture this by default
  • The HTTP proxy captures DNS queries, so if you have proxy logs but no DNS logs, Step 3 and Step 10 still get partial coverage

The gaps aren’t techniques you’re blind to. They’re data sources you don’t ingest. Your heatmap will show every technique as green if your EDR covers process creation, network connection, and file creation. But your SIEM might not be ingesting the ETW streams — it’s only reading Windows Event Logs. The heatmap lies. The data-inventory table doesn’t.

Why the difference matters

When the attacker hits, you don’t care about the matrix. You care about which alerts fired and which didn’t.

Scenario: mshta.exe spawns from Word, downloads a DLL, registers a COM object, and spawns cmd.exe with whoami. The EDR detects the process parent chain and fires an alert. The SIEM, however, is only reading Windows Event Logs — it doesn’t have ETW. The SIEM sees event 4688 (process created) showing winword.exe → mshta.exe → cmd.exe, but without ETW there’s no command-line arguments on the cmd.exe event, so the SIEM rule for “cmd.exe with whoami” never fires. The EDR catches it. The SIEM misses it. The heatmap shows green for both because both tools have data for those techniques.

Now flip it: the attacker uses a fileless technique — PowerShell reads a DLL from memory and executes it without writing to disk. The file creation ETW stream never fires. The SIEM’s file-based rules are silent. But the process creation and network connection ETW streams still capture the behavior. Your heatmap shows yellow for “fileless execution” because file creation data is missing. But the actual data is there — just not in the log type you mapped.

This is why you need the data-layer inventory above the technique heatmap. The heatmap is the what. The data inventory is the how. You need both.

The practical workflow

Here’s the workflow I use when building or auditing a detection program:

1. Pick one tactic to start with. Usually Initial Access or Lateral Movement. Don’t boil the ocean. One tactic, fully mapped, is better than 14 tactics half-mapped.

2. List the 3–5 most likely techniques. ATT&CK has dozens of techniques per tactic. Use your environment’s data to narrow it. If you run Exchange, the top Initial Access techniques are Email Attachment (T1566.001), Drive-by Compromise (T1189), and Valid Accounts (T1078). If you run Jenkins, it’s Scripting (T1059) and SSH (T1105). Don’t map the generic list — map the ones your environment actually uses.

3. For each technique, list the required data sources. ATT&CK has a “Data Sources” section for each technique. T1059 (Command and Scripting Interpreter) requires: Process Creation, Process Command Line, File Creation, Network Connection. That’s four data streams. Check if your SIEM/EDR ingests all four. If one is missing, you get partial detection for that technique.

4. Map alerts to behaviors, not techniques. An alert like “suspicious process chain detected” should map to the specific behavior it catches (e.g., Word → mshta → cmd.exe with whoami). A technique mapping like “T1059.001 — Command and Scripting Interpreter: PowerShell” is too broad to be useful in a runbook. You need to know exactly what triggered the alert, not just which category the technique falls under.

5. Audit quarterly. New techniques enter ATT&CK every month. New data sources get added to your stack quarterly. Old alerts go stale. The behavior map changes. Update it.

What to check on Monday morning

You don’t need a six-month project to start doing this right. Here’s the audit:

  1. Pull your active alert list. How many alerts do you have? If you have 200 active alerts and 14 tactics in ATT&CK, that’s about 14 alerts per tactic. That’s a good distribution. If 180 of your alerts are in Initial Access and Reconnaissance, you’re building a detection program for phishing, not for lateral movement.

  2. Count your data sources. How many log streams feed your SIEM? Not dashboards — actual ingestion pipelines. Windows Event Logs, ETW process creation, ETW file creation, network connection ETW, DNS logs, HTTP proxy, Sysmon, EDR telemetry, Kubernetes audit logs. If you’re below 8 data sources for a mid-size org, you have blind spots.

  3. Find one full chain. Pick one attack chain that your org is realistically likely to see (phishing → execution → lateral movement → exfiltration). Map each step to the data source that captures it. Map each data source to an active alert. If any step in the chain has no alert, you have a gap in that chain. That’s your first priority.

  4. Remove one heatmap technique that isn’t alerted on. If your heatmap shows green for “Network Share Discovery” (T1135) but you have no alert for that behavior, remove the green cell. The heatmap should match the alert inventory, not the data inventory.

The takeaway

ATT&CK is a map of attacker behavior. A heatmap built by mapping tools to that map will always overcount coverage because tools share data sources. The reliable approach is: pick an attack chain, list the behaviors, list the data each behavior generates, then map tools to that data. Build alerts against the behavior, not the technique. Audit the full chain, not the individual techniques.

The heatmap is a dashboard. The behavior map is the source of truth. Both are useful. But when the alarm fires at 2 AM, the behavior map tells you what to check. The heatmap doesn’t.

Further Reading