MITRE ATT&CK Coverage Mapping: A Practical Guide to Finding and Fixing Detection Gaps

1. Introduction: ATT&CK as the Lingua Franca of Detection

The MITRE ATT&CK framework has become the universal language of threat detection. When a SOC analyst writes a detection rule, they tag it with an ATT&CK technique ID. When a vendor ships a new runtime security product, they publish a coverage matrix showing which techniques they detect. When a CISO reports to the board, they frame security posture in terms of ATT&CK coverage percentages.

This is genuinely useful. Before ATT&CK, every vendor had their own taxonomy, and comparing tools required translating between incompatible classification systems. ATT&CK gave us a shared vocabulary for talking about adversary behavior, and that shared vocabulary has driven real improvements in how organizations think about detection engineering.

But there is a growing problem: the gap between claimed ATT&CK coverage and actual detection capability is enormous.

We have tested dozens of production environments running popular runtime security monitors, including Falco, Tracee, Tetragon, Wazuh, auditd, and osquery. In nearly every case, the gap between the vendor's published ATT&CK coverage and the techniques that actually generate alerts under adversarial conditions was significant. Rules that should fire do not. Monitors that should detect are silently disabled. Detection latency that should be milliseconds is minutes or never.

This guide walks through a practical, step-by-step process for mapping your real MITRE ATT&CK detection coverage against Linux runtime threats. Not the theoretical coverage your vendor claims. Not the coverage you would have if every rule were perfectly tuned. The actual, empirically verified coverage you have right now, under conditions that resemble a real attack.

2. The ATT&CK Matrix for Linux: Techniques That Matter

The full ATT&CK matrix contains hundreds of techniques. For Linux runtime security, not all of them are equally relevant. Some techniques (like Spearphishing Attachment) are primarily Windows or email-layer concerns. Others are so rare in practice that investing detection resources into them yields minimal return.

Below are the thirteen ATT&CK techniques we consider the highest priority for Linux runtime detection coverage. These span the full kill chain from initial access to impact, and they represent the techniques most commonly used in real-world Linux compromises, container breakouts, and cloud-native attacks.

T1562.001 deserves special emphasis. If an attacker can disable your security monitor before executing their attack chain, your coverage for every other technique effectively drops to zero. Blinding resistance is not just another technique to detect; it is the foundation on which all other detection depends.

3. The Coverage Gap Problem

Every major runtime security vendor publishes ATT&CK coverage claims. A typical marketing page might state something like "covers 85% of Linux ATT&CK techniques" or "maps to 120+ ATT&CK sub-techniques." These numbers are technically defensible: the vendor has a rule or a policy that references each technique ID. But having a rule and having effective detection are very different things.

Here is what we consistently find when we empirically test claimed coverage:

Rules that exist but do not fire

Many default rulesets ship with rules that are either disabled by default, require additional configuration, or depend on kernel features that are not enabled in the target environment. A Falco rule that detects memfd_create is meaningless if the deployment is running a kernel version that uses a different syscall path, or if the rule priority is set below the alert threshold.

Rules that fire but are too noisy to be actionable

Some rules generate so many false positives that SOC teams disable them within the first week. The rule technically exists and technically detects the technique, but operationally it provides zero coverage because nobody is looking at its output. A rule that fires 10,000 times per day on legitimate activity is indistinguishable from no rule at all.

Rules that fire but can be trivially evaded

Detection rules often match on specific patterns, command names, or file paths. An attacker who knows the rule can trivially evade it. If your /etc/shadow detection rule matches on cat /etc/shadow, an attacker can simply use cp /etc/shadow /tmp/s && cat /tmp/s or read the file using a custom binary. The rule fires against naive execution but fails against any attacker with basic operational security.

The monitor itself can be blinded

Perhaps most critically: many monitors can be disabled by an attacker who has already achieved privilege escalation. If your Falco instance runs as a non-privileged container with a mounted socket, a root-level attacker can simply kill it. If your auditd configuration is writable by root, the attacker can add exclusion rules. The entire coverage matrix collapses the moment the monitor goes dark.

4. Step-by-Step: Assessing Your Real ATT&CK Detection Coverage

The following process will produce an empirically validated ATT&CK detection coverage map for your Linux runtime security stack. It requires access to a staging or test environment that mirrors production, access to the monitors you want to assess, and the ability to execute controlled adversary simulations.

Step A: Inventory Your Monitors

Start by documenting every security monitor deployed across your infrastructure. For each monitor, record:

• Monitor name and version (e.g., Falco 0.38.1, Tracee 0.22.0, Tetragon 1.2.0)
• Deployment method (DaemonSet, sidecar, host-level service, eBPF agent)
• Rule configuration (default rules, custom rules, disabled rules)
• Host coverage (which hosts/clusters run this monitor)
• Alert destination (where do alerts go? SIEM? Slack? /dev/null?)
• Kernel version and features (BTF support, eBPF capabilities, audit subsystem status)

monitors:
  - name: falco
    version: "0.38.1"
    driver: modern_ebpf
    deployment: daemonset
    rules: default + 12 custom
    hosts: prod-k8s-cluster-01 (47 nodes)
    alert_dest: elasticsearch via falcosidekick

  - name: auditd
    version: "3.1.2"
    deployment: host service
    rules: /etc/audit/rules.d/ (STIG baseline)
    hosts: all bare-metal (23 hosts)
    alert_dest: rsyslog to SIEM

Step B: Map Each Monitor's Rules to ATT&CK Techniques

For each monitor in your inventory, extract the detection rules and map them to specific ATT&CK technique IDs. Most modern monitors already include ATT&CK tags in their rule definitions. For those that do not, you will need to manually classify each rule.

The goal is to produce a mapping like this:

Pay special attention to gaps in this mapping. If no monitor has a rule for a technique, that is a confirmed blind spot. But even if a rule exists, you have not yet verified that it actually works, which is the next step.

Step C: Test Each Technique

This is the step that separates theoretical coverage from real coverage. For each technique that has at least one mapped rule, execute the technique in your test environment and verify whether the expected alert is generated.

Testing should use multiple execution variants. If you are testing T1003.008 (reading /etc/shadow), do not just run cat /etc/shadow. Test with:

# Variant 1: Direct read
cat /etc/shadow

# Variant 2: Copy then read
cp /etc/shadow /tmp/.s && cat /tmp/.s

# Variant 3: Read via head/tail
head -n 5 /etc/shadow

# Variant 4: Read via custom binary (open + read syscall)
./read_file /etc/shadow

# Variant 5: Read via Python
python3 -c "print(open('/etc/shadow').read())"

# Variant 6: Read via proc self fd
exec 3

For each variant, record whether the monitor detected it, the alert that was generated, and how closely the alert matches the actual technique. A rule that detects Variant 1 but misses Variants 2 through 6 provides weak coverage; an attacker with basic Linux knowledge will use an evasion variant.

Step D: Measure Detection Latency

Detection coverage is not binary. A monitor that detects an attack ten minutes after execution provides fundamentally different value than one that detects it in 200 milliseconds. For each detected technique, measure the time delta between:

• Execution timestamp: when the adversary command or action was executed
• Alert timestamp: when the alert appeared in the monitor's output or SIEM

Categorize results into tiers:

Detection latency is especially important for techniques in the Execution and Privilege Escalation tactics. If an attacker can escalate to root and disable your monitor within 2 seconds, a detection latency of 30 seconds is effectively zero coverage.

Step E: Test Blinding Resistance

This is the most critical and most frequently skipped step. For each monitor in your inventory, attempt to disable, blind, or degrade it using techniques available to an attacker at the same privilege level the monitor is designed to detect.

Common blinding vectors to test include:

• Process kill: Can you kill -9 the monitor process?
• Service stop: Can you systemctl stop the monitor service?
• eBPF program unload: Can you detach the monitor's eBPF programs via bpffs or bpf syscall?
• Rule deletion: Can you delete or empty the monitor's rule files?
• Log sink disruption: Can you kill the log forwarder (Fluentd, Fluent Bit, rsyslog)?
• Resource exhaustion: Can you exhaust the monitor's perf ring buffer with noise, causing event drops?
• Namespace escape: Can you use kernel namespace manipulation to hide from the monitor's view?

If any of these vectors succeed, the monitor's entire ATT&CK coverage is conditional on the attacker not knowing about the vulnerability. That is not a security control; it is a hope.

5. Building a Coverage Matrix

Compile the results from Steps A through E into a coverage matrix. This table is the single most useful artifact your assessment will produce. It shows, at a glance, which techniques are detected, which are missed, and which monitors are vulnerable to blinding.

Here is an example coverage matrix from a real assessment (monitor names anonymized, results representative):

The "Blind" designation in the last row is critical. It means that the monitor can be disabled by an attacker, which means all of its "Pass" results above are conditional. An attacker who first blinds the monitor can then execute any technique undetected.

6. Prioritizing Gaps: Severity-Weighted Scoring

Not all detection gaps are equally urgent. A gap in detecting T1046 (Network Discovery) is important but less critical than a gap in detecting T1611 (Container Escape) or T1562.001 (Disable Security Tools). Your remediation priority should reflect the severity of the gap relative to your threat model.

We recommend a three-factor scoring model:

• Technique severity (1-5): How damaging is this technique if undetected? Container escape and privilege escalation score 5. Discovery techniques score 2-3.
• Prevalence in the wild (1-5): How commonly is this technique used by real adversaries targeting your environment type? Cron persistence in cloud-native environments scores 4. Timestomping scores 2.
• Monitor coverage breadth (1-5): How many of your monitors fail to detect this technique? If all five monitors miss it, that is a 5. If only one misses it, that is a 1.

Gap priority score = Severity * Prevalence * Coverage breadth. This produces a score from 1 to 125. Sort by this score to determine your remediation order.

Notice that blinding resistance (T1562.001) dominates the priority list. This is consistent across virtually every assessment we have conducted. The single highest-leverage improvement any organization can make is ensuring their monitors cannot be silenced by a privileged attacker.

7. Continuous Coverage Validation

A point-in-time ATT&CK coverage assessment is valuable but insufficient. Detection coverage degrades over time due to several factors:

• Configuration drift: Rules are tuned, disabled, or accidentally deleted during routine maintenance. A Falco rule that worked in January may be commented out in March because someone was troubleshooting a false positive.
• Infrastructure changes: New hosts, new clusters, new container images may not have the same monitor coverage as existing infrastructure. Shadow IT and rapid scaling frequently outpace security tooling deployment.
• Monitor updates: Version upgrades to your security monitors can change default behavior, rename rules, or alter the syscall hooks they use. An upgrade that fixes a bug might silently break a detection rule.
• Kernel changes: Kernel updates can affect eBPF program compatibility, audit subsystem behavior, and the availability of kernel features that monitors depend on.
• Adversary evolution: Attackers adopt new evasion techniques. A detection rule that caught every known variant of a technique in Q1 might miss a new variant introduced in Q2.

For these reasons, ATT&CK coverage validation must be continuous. The question is not "what was our coverage on the day we tested?" but "what is our coverage right now, in production, under conditions that resemble a real attack?"

The best detection engineering teams we work with run coverage validation on a weekly cadence. They treat their ATT&CK coverage matrix as a living document that is continuously updated, not a compliance artifact that is produced once per quarter.

8. How OZIPHR Automates ATT&CK Coverage Assessment

The process described above is rigorous, but performing it manually is time-consuming. Inventorying monitors, mapping rules, executing test variants, measuring latency, and testing blinding resistance across multiple monitors and multiple hosts requires significant engineering effort. Most teams cannot justify running a full assessment more than once or twice per year.

OZIPHR was built to automate this entire workflow. Here is what the platform provides:

20 Tests Mapped to ATT&CK

OZIPHR ships with 20 pre-built adversarial tests, each mapped to one or more ATT&CK technique IDs. Tests cover the full spectrum of runtime threats: execution, persistence, privilege escalation, defense evasion, credential access, discovery, and impact. Each test uses multiple execution variants to avoid rewarding pattern-matching rules that only catch naive implementations.

Automated Coverage Matrix Generation

After running the test suite against a host with one or more monitors deployed, OZIPHR automatically generates a coverage matrix showing which techniques each monitor detected, which it missed, and which were partially detected. The matrix is exportable and can be loaded into the MITRE ATT&CK Navigator for visualization.

Detection Speed Benchmarking

OZIPHR measures detection latency for every test, providing per-technique latency data across all monitors. This allows you to compare monitors not just on coverage breadth but on detection speed, which is critical for techniques in the early stages of the kill chain where seconds matter.

Blinding and Evasion Testing

OZIPHR includes dedicated blinding tests that attempt to disable each monitor using the same vectors a real attacker would use. This goes beyond traditional ATT&CK coverage testing to answer the fundamental question: if the attacker tries to kill my monitor first, does it survive?

Attack Chain Simulation

Beyond individual technique testing, OZIPHR simulates multi-step attack chains that combine techniques in realistic sequences. This tests not just individual rule coverage but whether your monitoring stack can correlate events across a full kill chain: initial access, privilege escalation, blinding attempt, lateral movement, data exfiltration.

9. Sample Coverage Report

Below is a simplified version of what an OZIPHR coverage assessment report looks like for a single host running two monitors. A production report would include per-technique detail, detection latency histograms, blinding test results, and remediation recommendations.

In this assessment, the combined Falco + auditd stack detected 62% of tested techniques under standard execution conditions. However, blinding resistance was only 25%: both Falco and auditd could be disabled by a root-level attacker, reducing effective coverage against a skilled adversary to the techniques that Tetragon (not deployed on this host) would have caught. The primary recommendation is to deploy a blinding-resistant monitor or harden the existing monitors against the identified blinding vectors.

10. Conclusion

MITRE ATT&CK is the right framework for thinking about detection coverage. But the framework itself is just a vocabulary. The hard work is verifying that your detection capabilities actually match the coverage you claim, under conditions that resemble a real adversary, not just a compliance checkbox.

The process we have outlined, inventorying monitors, mapping rules to techniques, testing each technique with multiple execution variants, measuring detection latency, and testing blinding resistance, is straightforward in concept. The challenge is doing it consistently, thoroughly, and continuously. Infrastructure changes, rule drift, kernel updates, and adversary evolution all erode coverage over time, making one-time assessments insufficient.

If you take away one thing from this guide, let it be this: test your T1562.001 coverage first. If your monitors can be blinded, nothing else in your ATT&CK coverage matrix matters. The attacker will simply disable your detection before running their attack chain, and your 90% coverage claim will be worth exactly nothing.

Start with blinding resistance. Then work outward through the kill chain: execution, persistence, privilege escalation, defense evasion. Prioritize based on severity and prevalence. Validate continuously. And never confuse having a rule with having a detection.