TTP Coverage

Expanded Definition

TTP coverage describes how well a detection or monitoring programme identifies attacker tactics, techniques, and procedures, not just fixed indicators such as file hashes, domains, or IP addresses. The practical boundary is important: indicator coverage can confirm a known bad artifact, while TTP coverage is designed to surface the behaviour that survives infrastructure changes and campaign rewrites.

In security operations, the term is usually used when comparing the durability of detections across different attack phases, such as reconnaissance, credential access, lateral movement, or persistence. Guidance-vs-consensus note: practitioners broadly agree that TTP-oriented detection is more resilient than pure IOC matching, but there is no single universal metric for what “good” coverage means. Coverage can be measured in different ways depending on whether the goal is threat hunting, control validation, alerting, or purple-team testing.

A common misunderstanding is to treat a long list of rules as evidence of TTP depth. Quantity alone does not show behavioural coverage if the rules all key off the same narrow pattern.

Examples and Use Cases

• Security teams map detections to ATT&CK-style techniques to see whether they can detect common actions such as command execution, process injection, or credential dumping.
• A threat hunting programme uses TTP coverage to prioritise gaps where indicators are already noisy but behaviour-based detections are still weak.
• Analysts validate whether an alert can still fire after an attacker changes domains, rotates payloads, or shifts from one toolset to another.
• Detection engineering teams use it to compare endpoint, identity, and network telemetry, because a behaviour may be visible in one layer even when it is absent in another.
• Purple-team exercises use TTP coverage to test whether controls detect the technique actually used, rather than the specific sample that was observed in testing.

The trade-off is straightforward: broader behavioural coverage usually improves resilience, but it can also increase tuning effort and false-positive handling if detections are too generic or poorly scoped.

Security Implications

When TTP coverage is weak, defenders often retain a false sense of visibility because they can still detect yesterday’s indicators while missing the underlying operation. That creates blind spots in cases where an adversary rehosts infrastructure, repackages malware, or uses living-off-the-land techniques that do not leave stable signatures.

Operationally, the result is slower detection of intrusion stages that matter most, especially when an attacker moves from initial access to privilege escalation or persistence. It can also distort risk reporting: a team may believe it has meaningful coverage because many rules exist, but those rules may all fail against the same class of behaviour.

Practitioner observation: weak TTP coverage is often revealed when a control performs well in lab conditions but fails once the test is repeated with different tooling or a different delivery method. The gap is not always absence of telemetry; it is often absence of behavioural interpretation.

Domain and Governance Relevance

TTP coverage matters most in detection engineering, threat-informed defence, and control validation. It helps organisations ask whether security controls are measuring adversary behaviour in a way that remains useful after the attacker changes infrastructure or tooling.

For identity-heavy environments, the term becomes especially relevant when techniques target authentication paths, delegated access, service accounts, or token abuse. In those cases, the question is not only whether an event was logged, but whether the detection can recognise the abuse pattern even if the attacker uses legitimate access paths. That makes TTP coverage a governance issue as much as a technical one: teams need to know which behaviours are actually covered, which telemetry sources support them, and where the blind spots remain.

Related resources from NHI Mgmt Group

• When do IAST and RASP create a false sense of coverage for NHIs?
• Should organisations prioritise least privilege or broad platform coverage first?
• How do you know if passwordless coverage is actually enterprise-wide?
• What do security teams get wrong about SAST and DAST coverage?