MITRE ATT&CK Navigator: building a coverage heatmap step by step

Originally published on the ClearPath Security site: https://clearpathsecurity.co.uk/mitre-attck-navigator-building-a-coverage-heatmap-step-by-step/

MITRE ATT&CK Navigator is useful when you need to turn a long list of detections, controls, and test results into something a security team can reason about quickly. A heatmap does not prove that an organisation is safe, and it should never be treated as evidence of complete protection. What it does well is show where you have direct coverage, where you are relying on indirect controls, and where the gaps are large enough to justify work.

For UK SMEs, that matters because resources are usually limited. You may have a SIEM, an XDR platform, a handful of endpoint controls, and a small team trying to keep pace with day-to-day operations. In that environment, a coverage heatmap can help you prioritise effort, explain risk to leadership, and avoid spending time on detections that do not materially improve resilience. If you already map detections to ATT&CK techniques, the Navigator gives you a more visual way to manage that work, building on approaches such as mapping detections and controls to MITRE ATT&CK and measuring detection coverage against MITRE ATT&CK using DeTT&CT.

Key takeaways

• Use ATT&CK Navigator to visualise evidence-based coverage, not to claim complete protection.
• Keep scoring simple and consistent, and separate preventive controls from validated detections.
• Treat validation status, telemetry quality, and false positives as first-class fields in the heatmap.
• Start with a narrow scope and expand iteratively so the map stays usable for a small team.

What the ATT&CK Navigator heatmap is for

The ATT&CK Navigator is a layer-based interface for marking techniques and sub-techniques with scores, colours, notes, and metadata. In practice, that means you can represent different kinds of coverage in one place. For example, you might score a technique as fully detected, partially detected, prevented, or unvalidated. You can also attach notes about the telemetry source, the control owner, or the test that proved the coverage.

The key distinction is between visualisation and detection engineering. Detection engineering is the work of writing, tuning, and validating the actual logic in your SIEM, EDR, or NDR stack. Navigator is the management layer above that work. It helps you see whether your detection content is balanced across the ATT&CK matrix, whether you are over-invested in one area, and whether critical techniques have no meaningful coverage at all.

For a small security team, that can be especially helpful when you need to make decisions across several domains at once. A heatmap can show, for example, that you have good endpoint telemetry but weak identity coverage, or that you have many alerts for initial access but very little for lateral movement. That is often more actionable than a spreadsheet of individual rules. It also complements operational work such as building Microsoft Sentinel analytics rules from MITRE ATT&CK techniques and purple-team validation of detections against MITRE ATT&CK.

Define the scope before you start

The most common mistake is to start colouring techniques before the scope is clear. A useful heatmap needs a defined environment, a defined purpose, and a defined audience. Otherwise, the scoring becomes inconsistent and the output is hard to trust.

Start by deciding what you are mapping. For example, you might scope the heatmap to:

• a single business unit, such as finance or customer support
• a platform, such as Microsoft 365, Windows endpoints, or Azure
• a specific environment, such as production only
• a threat scenario, such as ransomware or credential theft

For SMEs, it is usually better to begin with one environment and one threat set rather than trying to model the entire enterprise. A focused scope makes the first version usable and reduces the amount of evidence you need to collect.

You also need to decide whether you are mapping preventive controls, detections, or both. Preventive controls include things like conditional access, application control, and hardening. Detections include SIEM rules, EDR alerts, and network analytics. Both matter, but they should be scored separately. A prevention control may reduce risk without giving you any visibility, while a detection may alert you without stopping the activity. Treating them as the same thing usually creates false confidence.

Prepare the ATT&CK data model

Before you build the first layer, decide which ATT&CK matrix you are using and which version you will track. ATT&CK changes over time, so version control matters. If you do not pin the version, your heatmap can drift as techniques are added, renamed, or restructured.

For most UK SME environments, the Enterprise matrix is the starting point. From there, choose the techniques and sub-techniques that are relevant to your environment. You do not need to map every item in the matrix on day one. A better approach is to start with the techniques most relevant to your threat model, then expand iteratively.

It also helps to define a simple scoring model up front. Keep it consistent and easy to explain. A practical model might use:

• 0 for no coverage
• 1 for indirect or partial coverage
• 2 for direct coverage with some validation
• 3 for direct coverage with strong validation and low ambiguity

That is only an example, but the important point is consistency. If one analyst uses 1 to mean “logged somewhere” and another uses 1 to mean “alerting in production”, the heatmap becomes unreliable. You should also define what you mean by confidence. A rule that exists in a lab is not the same as a rule that has been exercised against live telemetry and reviewed after tuning.

Collect the evidence you need for scoring

A heatmap should be evidence-based. If you cannot point to the control, the detection, or the test result that supports a score, the score is probably too optimistic. Good inputs usually come from three places: control configurations, detection content, and validation results.

Control configurations include settings such as audit policy, PowerShell logging, Sysmon deployment, identity protection policies, or endpoint hardening baselines. Detection content includes SIEM rules, correlation logic, EDR detections, and alerting thresholds. Validation results include purple-team exercises, Atomic Red Team tests, or controlled simulations that show whether the telemetry and logic behave as expected.

When you collect evidence, separate three states that are often confused:

• coverage exists on paper
• coverage exists in production but has not been validated
• coverage has been validated and is producing usable signals

That distinction matters because many teams overstate their maturity by counting a control as coverage simply because it is enabled. A logging policy does not automatically mean a detection exists. A detection rule does not automatically mean it is tuned well enough to be useful. This is where the heatmap becomes a management tool rather than a vanity metric.

If you already maintain detection content as code, the evidence collection step can be linked to your pipeline. For example, a Sigma rule repository can store the ATT&CK technique ID, the log source, the test case, and the validation status alongside the rule itself. That makes it easier to keep the Navigator layer aligned with operational reality, especially if you are using a detection-as-code pipeline with Sigma and CI/CD.

Build the first layer in ATT&CK Navigator

Once the scope and scoring model are defined, create your first layer. You can start from a technique list, a CSV-style mapping, or an existing ATT&CK layer file. The aim is not to make it perfect. The aim is to make it usable enough to support discussion and prioritisation.

In the Navigator, load the relevant matrix and import the techniques you want to score. Then apply your colour scale. A common pattern is red for no coverage, amber for partial or unvalidated coverage, and green for direct validated coverage. Some teams prefer to use numeric scores with a gradient. Either approach is fine as long as the meaning is documented and used consistently.

Add metadata to each technique where possible. Useful fields include:

• control or detection owner
• log source
• validation date
• last review date
• notes on false positives or telemetry gaps

That metadata is what turns a picture into an operational artefact. Without it, the heatmap is just a coloured matrix. With it, you can trace each score back to a real control or detection and challenge weak assumptions.

Map coverage by technique and sub-technique

ATT&CK now relies heavily on sub-techniques, and that creates a common modelling problem. If you only score the parent technique, you may hide important detail. If you score both parent and child techniques without a rule, you may double count coverage. The answer is to define a hierarchy rule and apply it consistently.

A practical approach is to score sub-techniques first, then roll up to the parent technique only when that makes sense for reporting. For example, if you have direct coverage for one sub-technique but not another, the parent should not automatically be marked as fully covered. Instead, note the partial coverage and explain which child techniques are in scope.

When mapping coverage, distinguish between direct detections, indirect detections, and preventive controls:

• Direct detection means the control or rule is designed to identify the specific technique.
• Indirect detection means the signal may reveal the activity, but only as a side effect.
• Preventive control means the activity may be blocked or constrained, but not necessarily observed.

This distinction is important because a prevention-only control can still leave you blind to attempted abuse. For example, application control may stop a tool from running, but if you do not log the attempt, you may miss an indicator of compromise. Likewise, a network control may block a connection without telling you whether the host was already compromised. That is why many teams pair heatmap work with broader visibility design, such as achieving centralised visibility across endpoints, identity, and network.

Add confidence and validation context

Coverage without confidence is only half the picture. A technique that is theoretically covered but never tested is not the same as one that has been exercised against production telemetry. The heatmap should therefore carry validation status as a first-class attribute.

One useful pattern is to tag each technique with separate fields for:

• coverage type, such as preventive, detective, or both
• validation status, such as lab-tested, production-tested, or untested
• telemetry quality, such as high, medium, or low
• operational confidence, such as high, medium, or low

That gives you a more honest view of the environment. A rule that fires in a lab but produces noisy alerts in production should not be scored the same as a rule that has been tuned and monitored for several weeks. Similarly, if the underlying logs are delayed, incomplete, or frequently dropped, the detection may exist but still be operationally weak.

False positives and false negatives should also be captured in the notes. If a rule is too noisy, that is a maintenance issue. If a technique is repeatedly missed during testing, that is a coverage issue. If telemetry is missing entirely, that is a platform issue. Keeping those categories separate makes it easier to assign work to the right team.

Use the heatmap to spot blind spots and priorities

Once the first layer is populated, the real value starts to emerge. Look for clusters of weak coverage in techniques that are relevant to your environment. For many SMEs, the biggest blind spots are not exotic techniques. They are common paths such as credential theft, privilege escalation, persistence, and lateral movement.

Prioritisation should not be based on colour alone. Combine the heatmap with three other factors:

• threat relevance, based on the techniques most likely to be used against your sector
• asset criticality, based on the systems that would hurt most if compromised
• implementation effort, based on the time and tooling needed to improve coverage

This is where the heatmap becomes a planning tool. A technique with no coverage on a critical system should rise quickly in priority. A technique with weak coverage on a low-value system may be lower priority, even if it looks alarming on the matrix. That trade-off is part of normal risk management.

If you want to improve the quality of the underlying detections, it helps to link the heatmap back to the engineering backlog. For example, a red or amber technique can become a ticket to add telemetry, write a Sigma rule, tune a Sentinel analytic, or run a validation test. That creates a closed loop between strategy and implementation.

Operationalise the heatmap in a security programme

A heatmap is only useful if it is maintained. Treat it as a living artefact, not a one-off workshop output. In practice, that means assigning ownership, review cadence, and update triggers.

Good update triggers include:

• new log sources or telemetry changes
• major platform changes, such as identity migration or endpoint tooling replacement
• new detection content or rule tuning
• purple-team or simulation results
• changes in threat intelligence or incident lessons learned

For most teams, a quarterly review is a sensible starting point, with ad hoc updates after major changes. If the environment is changing quickly, monthly reviews may be more appropriate. The point is not frequency for its own sake. The point is to keep the heatmap aligned with reality.

It also helps to connect the heatmap to existing governance. If you already run management reviews, risk reviews, or security steering meetings, use the heatmap as an input. It can show whether planned improvements are actually reducing blind spots over time. That makes it easier to justify investment in logging, detection engineering, or validation work.

Common mistakes when building ATT&CK coverage heatmaps

The first mistake is treating a control as coverage just because it exists. A hardening baseline, a policy setting, or an enabled feature may reduce risk, but it does not necessarily give you visibility or proof of effectiveness. If you score it too highly, you will understate the work still needed.

The second mistake is mixing scoring methods across teams. If one team scores by control presence and another scores by validated detection quality, the resulting heatmap is not comparable. Agree the model first, then apply it consistently.

The third mistake is overloading the map with too much detail. If every technique has a paragraph of notes, the layer becomes hard to use. Keep the score simple and put the detail in linked documentation, tickets, or rule repositories.

The fourth mistake is failing to separate parent and sub-techniques. That can make coverage look better than it is. Be explicit about how roll-up works and avoid double counting.

The fifth mistake is letting the heatmap become static. ATT&CK coverage changes as your environment, tooling, and threat landscape change. If the map is not reviewed, it will drift away from reality and lose credibility.

Example workflow for a UK SME security team

A practical workflow might look like this. First, define a narrow scope, such as Windows endpoints and Microsoft 365 identity events. Second, choose the ATT&CK techniques most relevant to your threat model, such as phishing, credential access, persistence, and lateral movement. Third, gather the evidence: existing controls, SIEM rules, EDR detections, and recent test results.

Next, score each technique using a simple scale and record whether the coverage is preventive, detective, or both. Add notes on validation and telemetry quality. Then build the first Navigator layer and review it with the people who own the controls and detections. Expect to find some techniques that are only partially covered, some that are covered but unvalidated, and some that are simply missing.

From there, turn the heatmap into a backlog. Add the missing telemetry, tune the noisy rules, and schedule validation for the areas that matter most. If you already have a detection engineering process, the heatmap should feed it. If you do not, it can be the starting point for one.

When presenting the output to leadership, avoid overselling certainty. Say what the map shows, what it does not show, and what the next steps are. A good summary might be: we have reasonable coverage for common endpoint activity, weaker coverage for identity abuse, and limited validation for several high-value techniques. That is a more useful statement than claiming broad protection because many controls are enabled.

If you need support turning this into a repeatable programme, or want help aligning the heatmap with an ISMS or broader security roadmap, speak to a consultant.

Frequently asked questions

How often should an ATT&CK Navigator heatmap be updated?

At minimum, review it quarterly. Update it sooner if you add new telemetry, change major controls, run validation exercises, or respond to an incident that exposes a gap.

What is the difference between ATT&CK coverage and detection coverage?

Detection coverage is about whether you can observe or alert on a technique. ATT&CK coverage is broader and may include preventive controls, indirect signals, and validated detections. A technique can be ATT&CK-covered without having a direct alert, but you should record that distinction clearly.