Measuring detection coverage against MITRE ATT&CK using DeTT&CT

Detection teams often talk about alert volume, false positives, and mean time to respond. Those are important, but they do not tell you whether your environment is actually visible. A SIEM can generate hundreds of alerts and still miss the techniques that matter most to your business. That is where measuring detection coverage against MITRE ATT&CK using DeTT&CT becomes useful.

For UK SMEs, the point is not to build a perfect security operations programme. The point is to understand where you can see adversary activity, where you cannot, and what to improve next. DeTT&CT gives you a structured way to model telemetry, detections, and gaps against the MITRE ATT&CK framework so you can make better prioritisation decisions. If you have already started mapping detections and controls to ATT&CK, this is the next step: turning that mapping into a living coverage model rather than a static spreadsheet. It also complements work on measuring detection quality and false positives, because coverage and quality answer different questions.

Why detection coverage matters

Coverage is about visibility. It asks whether you have the telemetry and detections needed to observe a given technique, sub-technique, or behaviour. Quality is about usefulness. It asks whether the alert is accurate, actionable, and worth an analyst’s time. A detection can be high quality and still cover only a narrow slice of the attack surface. Equally, a broad coverage model can look impressive while producing noisy or low-confidence alerts.

In practice, blind spots usually appear in predictable places. Identity events are often incomplete because audit settings are inconsistent across cloud and on-premises systems. Endpoint telemetry may be present on laptops but missing on servers or domain controllers. Network visibility may be strong at the perimeter but weak for east-west traffic. Cloud control plane logs may exist, but only for a short retention period. DeTT&CT helps you make those gaps explicit instead of relying on assumptions.

For a small team, that matters because you rarely have the capacity to cover everything. You need to know which techniques are visible through multiple sources, which are visible only indirectly, and which are effectively dark. That gives you a defensible basis for deciding whether to improve logging, write a new detection, or accept a gap for now.

What DeTT&CT is and where it fits

DeTT&CT is a framework and tooling approach for documenting detection and visibility coverage against ATT&CK. It is designed to help defenders answer three practical questions: what data do we collect, what techniques can we detect, and how mature is that coverage. It is not a replacement for ATT&CK Navigator. Navigator is useful for visualising technique mappings and heatmaps, but it does not model the quality of the underlying data sources in the same way. DeTT&CT adds that extra layer of operational context.

The core concepts are straightforward. A data source is a telemetry source such as Windows Event Logs, Sysmon, Entra ID sign-in logs, Microsoft Defender for Endpoint, DNS logs, or firewall logs. Visibility means you can observe activity related to a technique, even if you do not yet have a specific alert. Detection means you have a rule, query, or analytic that can identify the behaviour. Coverage is the relationship between the ATT&CK technique and the data source or detection that supports it.

That distinction is important. A technique may be visible through a log source, but not detected. For example, process creation telemetry may show suspicious PowerShell usage, but unless you have a tuned analytic, you only have raw visibility. Conversely, a detection may exist but be based on weak telemetry, which makes it brittle. DeTT&CT lets you represent both states.

If you are building out a broader detection programme, it is worth pairing this with a clear logging architecture. Our article on centralised security visibility explains why consolidating endpoint, identity, and network telemetry is usually the prerequisite for meaningful coverage analysis.

Preparing the ATT&CK model for your environment

Before you start scoring coverage, scope the ATT&CK model to your environment. ATT&CK is broad, and trying to model every matrix from day one usually creates noise rather than insight. For most UK SMEs, the most relevant matrices are Enterprise techniques across Windows, Linux, macOS, cloud identity, and SaaS platforms. If you operate industrial or specialised environments, you may need to include other matrices, but only where they reflect your actual estate.

Start with the systems and identities you actually have. That means listing your crown-jewel assets, such as domain controllers, admin workstations, finance systems, customer data platforms, and privileged cloud tenants. Then identify the telemetry available for each. A simple scoping table can be enough:

Asset, operating system, identity provider, logging source, retention period, and whether the source is centralised. This is not just housekeeping. It tells you where your coverage model will be reliable and where it will be misleading because the underlying data is incomplete.

For example, if you have Microsoft 365 and Entra ID, you may be able to map sign-in risk, consent grants, mailbox access, and audit events to techniques around credential abuse and persistence. If you also have Sysmon on endpoints, you can extend the model to process creation, image loads, network connections, and named pipe activity. If you only have default Windows logging, your coverage will be much thinner, and the model should say so plainly.

It is also worth deciding whether you are modelling techniques at the technique level or sub-technique level. Sub-technique mapping is more precise, but it needs better telemetry and more maintenance. For a small team, a mixed approach often works best: use technique-level coverage for broad planning, then sub-technique detail for the highest-risk areas such as credential access, persistence, and lateral movement.

Building a coverage view from your telemetry

Once the scope is clear, map your log sources to ATT&CK techniques. The aim is not to create a theoretical matrix. The aim is to show which telemetry sources support which detections and where the evidence is weak. In DeTT&CT terms, you are building a coverage view from the bottom up.

Begin with direct detections. These are rules or queries that explicitly look for a technique or a close proxy. For example, a Sigma rule for suspicious service creation, a KQL query for risky Entra ID sign-ins, or a Defender for Endpoint analytic for credential dumping behaviour. Direct detections should be linked to the specific technique or sub-technique they cover.

Then add indirect detections. These are signals that do not prove the technique on their own, but contribute to confidence. Examples include unusual parent-child process chains, abnormal authentication patterns, or rare administrative actions. Indirect detections are still useful, but they should be labelled as such so you do not overstate coverage.

Finally, record gaps. If you have no telemetry for a technique, say so. If you have telemetry but no retention long enough to investigate, say that too. If the source exists but is not enabled on the relevant hosts, note that. The value of DeTT&CT is partly in making these limitations visible to technical and non-technical stakeholders.

A practical way to do this is to align your telemetry inventory with ATT&CK techniques in a YAML or spreadsheet-backed model, then maintain a separate evidence field for each mapping. That evidence might be a log source name, a detection rule ID, a query link, or a test result. If you already use Sigma rules, you can reference the rule names or repository paths directly, which makes the model easier to operationalise.

Using DeTT&CT to assess visibility and detection maturity

DeTT&CT is most valuable when you use it to assess maturity, not just coverage. A simple yes or no view is rarely enough. You need to know whether the data source is reliable, whether the detection is tuned, and whether the alert can be investigated within your operational constraints.

One useful pattern is to score each data source across a few dimensions: collection enabled, centralised, retained long enough, normalised, and validated. A source that is enabled but not retained for long enough may be useful for live monitoring but poor for incident investigation. A source that is retained but not normalised may be hard to query consistently across platforms. A source that is centralised but never tested may create false confidence.

For detection maturity, consider whether the rule is tested, whether it has a known false positive rate, whether it is mapped to a response playbook, and whether it has been exercised in a safe simulation. This is where ATT&CK coverage and operational readiness meet. A technique with a detection but no response path is not fully useful in practice.

Weak signals deserve special attention. These are techniques where you have some evidence, but not enough to rely on it. For example, you may see PowerShell script block logging on some endpoints, but not all. Or you may have cloud audit logs, but no identity protection telemetry. DeTT&CT helps you identify these partial views so you can decide whether to improve them or accept the residual risk.

High-risk blind spots should be prioritised by business impact, not by elegance of the technique. For most SMEs, that means identity compromise, privilege escalation, lateral movement, and data exfiltration paths that would affect operations, customer data, or financial control. If you need a broader context for prioritisation, our article on using incidents and alerts to improve defence shows how to feed real operational lessons back into the detection programme.

Practical workflow for a small security team

If you are a small team, keep the workflow simple. Start with the systems that matter most and the techniques that are most likely to be used against them. For many UK SMEs, that means identity attacks, endpoint execution, and privilege abuse. You do not need to model every possible ATT&CK technique before you get value.

A workable sequence is:

1. Identify crown-jewel systems and privileged identities.
2. List the telemetry sources available for those assets.
3. Map the current detections to ATT&CK techniques and sub-techniques.
4. Mark visibility only, detection present, or gap.
5. Rank gaps by business impact and feasibility.

That ranking step is where the model becomes useful. A gap on a low-value workstation may be less important than a partial view of domain controller activity or cloud admin actions. Similarly, a detection that is easy to add because the data already exists should usually be prioritised over a gap that would require a major platform change.

In many SME environments, a good first pass is to focus on common identity attacks, suspicious PowerShell, service creation, scheduled task persistence, remote service execution, and credential access behaviour. These areas tend to produce useful coverage quickly because they map to telemetry you may already have. If you need a deeper identity-focused baseline, the article on detecting credential theft and misuse patterns is a natural companion.

Turning coverage gaps into detection work

Once gaps are identified, turn them into a backlog of detection work. The backlog should be specific enough that an engineer can act on it without reinterpreting the problem. Instead of writing, “improve lateral movement coverage,” write, “add detection for remote service creation on Windows servers using Event ID 7045 and correlate with admin account usage.”

When you implement a new detection, keep the ATT&CK mapping attached to the rule metadata. In practice, that means storing the technique ID, data source, and expected response in the detection-as-code repository. If you use Git-based workflows, include the ATT&CK mapping in the rule file or adjacent documentation so it survives refactoring. This makes coverage reporting much easier later.

For Sigma and KQL, the same principle applies. A Sigma rule should carry the ATT&CK technique reference, log source, status, and test notes. A KQL analytic in Microsoft Sentinel should include the technique mapping in the rule description or tags. If a detection is promoted from hunting query to alert, update the DeTT&CT model at the same time.

Validation matters. Safe simulation and tuning are what separate theoretical coverage from operational coverage. Use controlled test cases, lab accounts, and approved simulation tools to confirm that the telemetry arrives, the query fires, and the alert is actionable. If you already run purple-team exercises, they can be used to validate the model as well as the detection. The article on purple-team validation of detections against MITRE ATT&CK is relevant here because it closes the loop between mapping and real-world testing.

How to keep the coverage model current

Coverage models decay quickly if they are not maintained. Logging changes, platform migrations, new SaaS services, and identity control updates all affect what you can see. A model that was accurate six months ago may now be misleading if a source was disabled, a tenant was reconfigured, or a server estate changed.

Build review points into your operational rhythm. Revisit the model after major changes such as endpoint rollout, SIEM migration, identity platform changes, or a significant incident. You should also review it when you change log retention, add a new data source, or retire a legacy system. The model should reflect the current state of visibility, not the state you hoped to achieve.

Use the model in continuous improvement cycles. Each review should answer three questions: what changed, what coverage improved or degraded, and what should be done next. That makes DeTT&CT part of your security operations process rather than a one-off exercise. It also helps when you need to explain progress to leadership, because you can show concrete movement in visibility and detection maturity over time.

Common mistakes to avoid

The first mistake is treating coverage as a percentage target. A high percentage can hide serious blind spots if the mapped techniques are low value or if the detections are weak. Coverage should be risk-based, not vanity-driven.

The second mistake is confusing ATT&CK mapping with validation. A technique mapped in a spreadsheet is not the same as a detection that has been tested against representative telemetry. If you have not confirmed that the log source exists, is retained, and produces the expected event, the mapping is only a hypothesis.

The third mistake is over-claiming visibility. If a detection depends on one endpoint family, one cloud tenant, or one log source with short retention, say so. Honest limitations are more useful than optimistic coverage charts.

The fourth mistake is trying to model everything at once. Start with the techniques that matter most to your environment and expand gradually. A smaller, accurate model is better than a large, fragile one.

The fifth mistake is leaving the model disconnected from engineering work. If DeTT&CT does not influence logging decisions, detection backlog priorities, or validation activities, it will become shelfware. The model should drive action.

Bringing it together

Measuring detection coverage against MITRE ATT&CK using DeTT&CT is most useful when you treat it as a visibility and prioritisation tool. It helps you see where telemetry is strong, where detections are mature, and where the blind spots are likely to hurt you most. For UK SMEs, that is usually enough to make the detection programme more focused and more defensible without adding unnecessary complexity.

If you already have a SIEM, some endpoint telemetry, and a few identity logs, you can start small and still get value. Map what you have, mark what you do not, and use the results to guide the next round of logging and detection work. Over time, that gives you a clearer picture of your defensive posture and a better way to invest limited security effort.

If you would like help turning ATT&CK coverage into a practical detection roadmap, or aligning it with broader governance and ISMS priorities, speak to a consultant.

Frequently asked questions

How does DeTT&CT differ from MITRE ATT&CK Navigator?

MITRE ATT&CK Navigator is mainly a visualisation tool for technique mapping and heatmaps. DeTT&CT goes further by modelling data sources, visibility, detection coverage, and maturity so you can see not just what is mapped, but how reliable that coverage is.

What should we measure first if we only have limited logging and detection capacity?

Start with crown-jewel systems, privileged identities, and the techniques most likely to affect business operations, such as credential abuse, privilege escalation, persistence, and lateral movement. Focus on the telemetry you already have and improve the highest-risk gaps first.

Do we need every ATT&CK technique covered?

No. Most organisations do not need full coverage of every technique. A better approach is to cover the techniques that are relevant to your environment, validate them properly, and accept that some low-value areas may remain uncovered for now.

Is ATT&CK coverage the same as detection effectiveness?

No. Coverage tells you whether you can observe or detect a technique. Effectiveness tells you whether the detection is accurate, actionable, and useful in practice. You need both to build a mature detection capability.