Threat-Informed Defence Guide: Prioritising Controls by Real Adversary Behaviour

Most security programmes spend by framework checklist or by vendor category, and then cannot say which real attacks their controls would actually stop. Threat-informed defence turns the question around: start from how relevant adversaries behave, map your preventions and detections to those behaviours, and test them by emulating the behaviour. The MITRE Center for Threat-Informed Defense (CTID) frames it as three connected dimensions: cyber threat intelligence, defensive measures, and testing and evaluation. This guide explains that model, shows how to build a prioritised technique list from ATT&CK, how to apply the same lens to vulnerability, monitoring and third-party decisions, and how to measure progress. It is for SOC leads, security architects and CISOs who need a defensible way to rank control work.

Key takeaways

• Behaviour beats indicators. CTID's guidance is to align defences to observed adversary tradecraft rather than chase indicators of compromise, which attackers change cheaply.
• Three dimensions must connect. Intelligence that does not change a control, or a control that is never tested against a behaviour, is not threat-informed defence.
• Prioritise a short list, not the whole matrix. CTID's Top ATT&CK Techniques method scores techniques on prevalence, choke point value and actionability, then tailors the list to your controls.
• Test with emulation. Purple team exercises and open emulation plans turn "we think we detect this" into evidence.
• Apply the lens beyond the SOC. Vulnerability prioritisation (known exploited first), log onboarding and third-party reviews all improve when tied to the techniques adversaries use.

What threat-informed defence is

CTID describes threat-informed defence as the systematic application of a deep understanding of adversary tradecraft and technology to improve defences. Its three dimensions, as set out on the Center's mission page and in its INFORM assessment, are:

In CTID's earlier M3TID maturity research the dimensions were weighted CTI 35%, defensive measures 40% and testing and evaluation 25%; its successor, MITRE INFORM, keeps those weights and scores each maturity level by impact and complexity, producing an impact against complexity matrix and recommended next steps. It is a programme-level assessment that complements tactical maturity models for CTI and SOC functions.

Threat-informed defence is not a product or a team. It is a way of deciding: when a choice comes up (which detection to build, which patch first, which log source to onboard, which supplier to review), the question is which adversary behaviour it affects and how you would know.

Building a prioritised technique list

ATT&CK v20 Enterprise has hundreds of techniques and sub-techniques. Trying to cover all of them evenly spreads effort thin. Build a short, justified list instead.

1. Define your threat profile. Sector, geography, technology stack and crown jewels. Pull the groups and malware relevant to you from ATT&CK Groups, government advisories and your own incident history. See the Threat Actor Groups Guide and the Ransomware Groups Guide.
2. Map reporting to techniques carefully. CISA's Best Practices for MITRE ATT&CK Mapping sets out six steps for finished reports: find the behaviour, research it, translate it into a tactic, identify the technique, identify the sub-technique, and compare results with other analysts.
3. Score and rank. CTID's Top ATT&CK Techniques calculator combines prevalence, choke point (techniques many attack paths pass through) and actionability (whether defenders can realistically prevent or detect it) into a single score, and can be tailored to your system characteristics and existing controls. Its library also offers prebuilt lists, for example for ransomware.
4. Weight by your own evidence. Techniques seen in your own incidents, red team findings and hunting results should outrank generic prevalence.
5. Cap the list. Fifteen to thirty techniques is a workable quarterly focus for most teams. Revisit after each major intelligence change.

Correct for the biases CISA's mapping guide warns about: novelty bias (new techniques get more reporting), visibility bias (organisations report what they can see), producer bias (heavy publishers dominate), victim bias (some victims are reported more) and availability bias (authors map what they know). Prevalence data says what was reported, not necessarily what happened.

Example: techniques that recur across intrusions

The table shows commonly prioritised techniques and what threat-informed work on each looks like. All IDs are ATT&CK v20.

This list is illustrative. Your ranked list should come from your own threat profile and the scoring above.

Mapping defensive measures to behaviour

Once you have a list, map what you own against it. CTID's Mappings Explorer publishes mappings from ATT&CK to security controls and capabilities, including NIST SP 800-53, CIS Controls, the CSA Cloud Controls Matrix, the CRI Profile, CISA's Known Exploited Vulnerabilities (KEV), VERIS, Microsoft 365 controls and native AWS, Azure and Google Cloud security capabilities. That lets you answer "which of our controls address T1078.004?" with a sourced answer rather than a guess. The Center's project to map KEV entries produced over 800 mappings for more than 400 CVEs, which links vulnerability data to the behaviours it enables.

• Prevention coverage: for each technique, list the controls that block it and whether they are enforced everywhere or only in part of the estate.
• Detection coverage: list analytics that fire on it, their data sources and their false positive rate. Heatmaps overstate coverage; CTID's Summiting the Pyramid project measures implementation coverage (how many behaviourally distinct ways of performing a technique an analytic observes) and detection quality (how robust the signal is). See the Detection Engineering Guide.
• Response readiness: for each high-priority technique, is there a playbook and a containment action?
• Visibility gaps: techniques you cannot detect because the log source is missing feed straight into log onboarding priorities (threat-informed log analytics).

A separate guide in this series on MITRE ATT&CK coverage mapping covers the mechanics of coverage matrices in more depth; the MITRE ATT&CK Guide for Defenders covers the framework itself.

Testing and evaluation

Testing is what separates threat-informed defence from a mapping exercise. Results should be recorded per technique: prevented, detected, detected late, logged only, or missed.

CTID's open Adversary Emulation Library includes full plans for named groups such as APT29, FIN7, menuPass, OilRig, Sandworm, Turla and Wizard Spider, and micro emulation plans for behaviours shared across adversaries, including Active Directory enumeration, log clearing, process injection and web shells. The micro plans are designed so they can run without a red team. See the Purple Teaming Guide and the Breach and Attack Simulation (BAS) Guide.

Applying the lens across the programme

• Threat-informed SOC and monitoring: alert severity and triage order follow the technique list, and hunting hypotheses come from intelligence on relevant groups. See the Threat Hunting Guide and the SOC Guide.
• Threat-informed vulnerability prioritisation: rank by evidence of exploitation (CISA KEV) and by whether the vulnerability enables a technique on your list, not by CVSS alone. The joint Five Eyes MSP advisory makes the same point: prioritise KEV entries rather than only high-CVSS flaws. See the Exposure Management and CTEM Guide.
• Threat-informed log analytics: onboard log sources in the order that closes detection gaps for priority techniques. A data source that supports no priority technique is a cost question, not a security one. See the SIEM Guide.
• Threat-informed response: write and rehearse playbooks for the techniques most likely to appear in your incidents first.
• Threat-informed third-party risk management: ask suppliers with access how they handle the techniques that would let an attacker pivot through them, such as T1199 Trusted Relationship and T1078 Valid Accounts, instead of sending a generic questionnaire. See the Third-Party Risk Management Guide.
• Threat-informed posture control: cloud and identity posture findings are ranked by the techniques they enable. Exposed long-lived NHI credentials map to T1078.004 and are usually high on the list.

Where identity fits

Valid account abuse appears across initial access, persistence and privilege escalation in ATT&CK, and for many organisations it is the top-ranked technique family. Non-human identities (service accounts, API keys, OAuth tokens, workload identities) are frequently part of that picture because they are long-lived, rarely protected by MFA and often over-privileged. A threat-informed programme should therefore treat NHI inventory, rotation and anomaly detection as defensive measures for T1078 and T1550.004 Web Session Cookie, and test them like any other control. In the Cloudflare Thanksgiving breach, credentials that were not rotated after a supplier compromise were enough for a nation-state attacker to get in. See the Identity Attack Paths Guide.

Rolling it out: a phased approach

1. Weeks 1 to 4, baseline: agree the threat profile with the CTI, SOC and architecture leads, build the first ranked technique list and record current coverage honestly (tested, mapped only, none). Run INFORM or an equivalent assessment to set a starting score.
2. Weeks 5 to 8, pilot: pick five priority techniques. Run micro emulation for each in a lab or a pilot ring of production hosts, fix the gaps found, and re-test. New detections go in audit or low-severity mode first so analysts can measure noise before they page anyone.
3. Weeks 9 to 12, expand: extend testing to the full list, move tuned detections to production severity, and connect the list to vulnerability and log onboarding queues.
4. Ongoing: schedule regression tests, a quarterly purple team cycle and a list refresh after significant intelligence or incidents.
5. Rollback: keep detection content in version control so a noisy or broken analytic can be reverted in minutes, and never retire an existing control because a mapping says another covers the technique until a test proves it.

Small teams can start with a prebuilt Top ATT&CK Techniques list and free micro emulation plans, and buy testing as a service if needed. Large organisations usually justify a dedicated threat-informed or purple team function, continuous BAS and formal intelligence requirements owned by the CTI team. In both cases the first deliverable is the same: a short, ranked list everyone has agreed to work from.

Detection and measurement

• Priority technique coverage: percentage of the ranked list with at least one tested prevention or detection, not just a mapped one.
• Validated detection rate: percentage of emulated behaviours detected within the target time in the last test cycle.
• Detection regression rate: analytics that passed last cycle and failed this one.
• Intelligence to control lead time: days from a relevant new technique report to a deployed and tested defensive change.
• KEV exposure age: median days that known exploited vulnerabilities stay open on internet-facing assets.
• INFORM or equivalent maturity score: reassessed after each improvement cycle.

See the Security Operations Metrics Guide.

Common failure patterns

• The heatmap as the goal. Colouring the matrix green from vendor claims creates false confidence. Only tested coverage counts.
• Intelligence that changes nothing. Threat reports are read and filed. Each relevant report should produce a mapping, a coverage check and either a change or a recorded decision not to change.
• Mapping errors. CISA's guide names leaping to conclusions (for example assuming a protocol from a port), missed opportunities and miscategorisation. Peer review of mappings is the fix.
• Prevalence without context. Copying a generic top 10 without weighting for your sector, stack and own incidents.
• Ignoring defence impairment. Detections that rely on an agent or log that the attacker disables first (T1685, T1685.001 Disable or Modify Windows Event Log) fail silently. Monitor sensor and log health as a priority technique.
• Testing once. A detection validated a year ago may have been broken by a schema change. Automate regression tests.

Framework mapping

Practitioner checklist

• Write a threat profile naming the adversary types, groups and techniques relevant to your sector and stack.
• Build a ranked list of 15 to 30 ATT&CK v20 techniques using prevalence, choke point and actionability, weighted by your own incidents.
• Peer review technique mappings and record the source for each.
• Map existing preventions, detections and playbooks to each priority technique, using Mappings Explorer where it covers your controls.
• Test each priority technique with micro emulation or BAS, and record prevented, detected, logged or missed.
• Run a purple team exercise each quarter on the weakest techniques.
• Rank vulnerabilities by known exploitation and technique impact, not CVSS alone.
• Monitor sensor and log health as a defence against defence impairment.
• Reassess maturity with INFORM or an equivalent model after each improvement cycle.

Standards and references

• MITRE Center for Threat-Informed Defense: Our Mission
• MITRE Center for Threat-Informed Defense: INFORM Your Defense
• MITRE Center for Threat-Informed Defense: Top ATT&CK Techniques
• MITRE Center for Threat-Informed Defense: Mappings Explorer
• CISA: Best Practices for MITRE ATT&CK Mapping
• MITRE Center for Threat-Informed Defense: Adversary Emulation Library
• MITRE Center for Threat-Informed Defense: Summiting the Pyramid
• MITRE ATT&CK: Valid Accounts

Related NHI Mgmt Group resources: MITRE ATT&CK Guide for Defenders · Purple Teaming Guide · Detection Engineering Guide · Threat Intelligence Guide · SOC Guide