MITRE ATT&CK

1. Introduction

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a globally accessible, evidence-based knowledge base of adversary behaviour, curated and maintained by MITRE, a not-for-profit organisation that operates federally funded research and development centres (FFRDCs) in the United States. Unlike a prescriptive compliance standard such as PCI DSS or ISO/IEC 27001, ATT&CK is a descriptive taxonomy: it catalogues how real-world threat actors actually operate once they are inside, or attempting to breach, an enterprise, mobile, cloud, or industrial control systems environment. Since its first public release in 2015, ATT&CK has become the lingua franca of defensive cybersecurity, adopted by security operations centres (SOCs), threat-intelligence teams, red teams, detection engineers, and boards of directors seeking a common vocabulary for measuring defensive coverage.

This CyberSigma Knowledge Center deep-dive is written for security leaders, SOC managers, detection engineers, threat hunters, purple-team practitioners, and auditors who need to operationalise ATT&CK as a measurable programme rather than a poster on the wall. It treats ATT&CK as an assessable capability model: we enumerate every tactic (the columns of the matrix), explain the technique and sub-technique hierarchy, and provide auditor-grade verification tables covering detection coverage, data-source instrumentation, threat-informed defence, and adversary emulation. Because ATT&CK is not a certification, the objective here is not a pass/fail audit but a rigorous, repeatable assessment of coverage, maturity, and defensive efficacy against the techniques most relevant to your threat model.

2. What is MITRE ATT&CK

MITRE ATT&CK is a curated knowledge base that organises adversary behaviour into a structured matrix. The framework answers a deceptively simple question that traditional vulnerability-centric security historically struggled with: what does an attacker actually do, step by step, to achieve their objectives? Rather than focusing on indicators of compromise (IOCs) such as file hashes or IP addresses that change constantly, ATT&CK focuses on tactics, techniques and procedures (TTPs) that describe adversary behaviour at a level of abstraction that is far more durable and difficult for an attacker to change.

The framework is expressed as a set of matrices. The columns of a matrix are tactics, representing the adversary's tactical goal or the reason for performing an action, such as gaining initial access or exfiltrating data. Within each tactic column sit the techniques, which describe how an adversary achieves that tactical goal, and many techniques are further decomposed into sub-techniques that describe more specific variants of behaviour. Each technique is documented with procedure examples drawn from observed intrusions, the data sources needed to detect it, mitigations that reduce its likelihood or impact, and references to the threat groups and software known to use it.

ATT&CK is versioned and released periodically (typically twice a year), with each release adding, deprecating, or revising techniques as the threat landscape evolves. The knowledge base is complemented by related MITRE resources: ATT&CK for adversary behaviour, the ATT&CK Navigator for visualising coverage as heat maps, D3FEND for defensive countermeasures, CAR (Cyber Analytics Repository) for detection analytics, and MITRE Engenuity's ATT&CK Evaluations which independently test commercial security products against emulated adversaries.

Why ATT&CK matters for defenders

• Common language: security teams, vendors, threat intelligence providers and executives can all reference the same technique identifiers, eliminating ambiguity.
• Threat-informed defence: coverage can be prioritised against the specific techniques used by the threat groups most relevant to an organisation's sector and geography.
• Detection engineering: each technique maps to observable data sources, giving detection engineers a concrete target for analytic development.
• Gap analysis and heat mapping: the ATT&CK Navigator lets teams visualise which techniques they can detect, mitigate, or are blind to.
• Red and purple teaming: adversary emulation plans are built directly from ATT&CK techniques, enabling repeatable, behaviour-based testing.
• Vendor evaluation: procurement decisions can be grounded in objective, technique-level coverage rather than marketing claims.

3. Who must comply / who should adopt ATT&CK

MITRE ATT&CK is not a regulatory mandate, so no organisation is legally required to comply with it in the way one must comply with the PCI DSS or the DPDP Act. However, ATT&CK adoption is increasingly expected as a matter of good practice, and a growing number of regulators, frameworks, and customers reference or require behaviour-based defensive coverage that maps naturally to ATT&CK. The table below sets out the audiences for whom ATT&CK adoption is effectively obligatory in practice.

4. Structure of MITRE ATT&CK

ATT&CK is organised into technology domains, each with its own matrix of tactics and techniques. Within a matrix, the hierarchy runs from tactics (the why) to techniques (the how) to sub-techniques (specific variants), each carrying a stable identifier. The table below summarises the domains, the object types, and the identifier conventions that make up the ATT&CK model.

The Enterprise tactics (matrix columns)

The Enterprise matrix comprises 14 tactics arranged roughly in the order an intrusion may unfold, from reconnaissance through to impact. These tactics form the backbone of the master assessment checklist in the next section.

5. Master assessment checklist

This is the core of the guide. For each ATT&CK Enterprise tactic we provide a verification table that an assessor can use to evaluate whether the organisation can detect, mitigate, and respond to the techniques within that tactic. Each row states what to verify and the typical evidence that demonstrates coverage. The intent is not to require detection of every one of the several hundred techniques, but to ensure deliberate, risk-prioritised coverage with instrumented data sources, tested analytics, and documented gaps. Assessors should cross-reference the organisation's ATT&CK Navigator coverage layer, detection catalogue, and adversary-emulation results throughout.

5.0 Programme foundations (cross-cutting)

5.1 Reconnaissance (TA0043)

5.2 Resource Development (TA0042)

5.3 Initial Access (TA0001)

5.4 Execution (TA0002)

5.5 Persistence (TA0003)

5.6 Privilege Escalation (TA0004)

5.7 Defense Evasion (TA0005)

5.8 Credential Access (TA0006)

5.9 Discovery (TA0007)

5.10 Lateral Movement (TA0008)

5.11 Collection (TA0009)

5.12 Command and Control (TA0011)

5.13 Exfiltration (TA0010)

5.14 Impact (TA0040)

5.15 Mobile and ICS domain coverage (where applicable)

6. Scoping

Because ATT&CK is a descriptive framework spanning several hundred techniques across multiple domains, attempting to detect everything at once is neither feasible nor cost-effective. Scoping an ATT&CK programme is fundamentally an exercise in threat-informed prioritisation: deciding which domains, techniques, and threat groups matter most to your organisation and instrumenting accordingly.

Defining the assessment scope

• Domain selection: determine which matrices apply (Enterprise is near-universal; add Mobile if you have a managed device estate, and ICS if you operate OT/process control).
• Platform scope: within Enterprise, identify relevant platforms (Windows, macOS, Linux, cloud/IaaS, SaaS, identity providers, network, containers) as many techniques are platform-specific.
• Threat-actor scope: use CTI to identify the intrusion sets (Gxxxx) most relevant to your sector, geography, and value as a target; this yields a prioritised technique list.
• Crown-jewel scope: identify the assets, data, and business processes an adversary would target, and prioritise the techniques on the likely kill-chain to those assets.
• Data-source scope: map which telemetry sources are (or can be) instrumented, since detection is impossible without the underlying data component.
• Maturity scope: decide whether the current cycle targets detection coverage, mitigation coverage, or adversary-emulation validation.
• Out-of-scope declaration: explicitly document techniques deliberately deprioritised (e.g. platforms not in use) so the coverage map is honest.

7. Implementation approach

Operationalising ATT&CK is best delivered as a phased programme that moves from understanding the threat, through instrumentation and detection engineering, to continuous validation via adversary emulation. The phases below are cumulative; each produces concrete deliverables that feed the next.

Phase 1 — Threat modelling and prioritisation

• Activities: gather cyber threat intelligence; identify relevant threat groups and their known techniques; define crown-jewel assets and likely attack paths; agree the priority technique list.
• Deliverables: threat profile document, prioritised ATT&CK technique list, initial Navigator layer of target coverage.

Phase 2 — Data-source and visibility assessment

• Activities: inventory current log and telemetry sources; map them to the data components required by priority techniques; identify visibility gaps; plan instrumentation (e.g. enabling script-block logging, EDR, cloud audit logs).
• Deliverables: data-source coverage matrix, visibility gap register, instrumentation roadmap.

Phase 3 — Detection engineering

• Activities: develop, tune, and document analytics for priority techniques; tag each detection with its technique ID; establish a detection catalogue and a test harness; reduce false positives.
• Deliverables: detection library mapped to ATT&CK, detection-as-code repository, Navigator layer of achieved detection coverage.

Phase 4 — Mitigation and hardening

• Activities: implement ATT&CK mitigations (Mxxxx) that reduce technique feasibility (e.g. application control, MFA, network segmentation); map mitigations to techniques; verify configuration.
• Deliverables: mitigation-to-technique map, hardening baseline records, residual-risk register.

Phase 5 — Adversary emulation and validation

• Activities: build adversary-emulation plans from priority techniques; execute purple-team exercises and automated breach-and-attack simulation; measure detection and prevention efficacy; feed findings back into detection engineering.
• Deliverables: emulation plans, purple-team reports, validated coverage heat map, remediation backlog.

Phase 6 — Continuous improvement and governance

• Activities: re-baseline on each ATT&CK release; track KPIs; report coverage to leadership; integrate lessons from real incidents into technique coverage.
• Deliverables: recurring coverage reports, KPI dashboard, updated Navigator layers, governance review minutes.

8. Maturity / capability model

Organisations progress through recognisable stages of ATT&CK adoption. The model below, inspired by the concept of threat-informed defence maturity, lets an assessor place an organisation on a capability scale and set a target level. Levels are cumulative.

9. Assessment and audit approach

A rigorous ATT&CK assessment blends documentation review, technical validation, and adversary emulation. The following steps describe a repeatable assessment methodology an auditor can follow.

1. Define scope and objectives: agree the domains, platforms, priority threat groups, and whether the assessment targets detection, mitigation, or full validation.
2. Review the threat profile: confirm CTI-driven prioritisation is current and defensible against the organisation's sector and geography.
3. Inventory data sources: verify which required data components are instrumented and retained, and identify blind spots.
4. Review the detection catalogue: confirm detections are mapped to technique IDs, documented, version-controlled, and tuned.
5. Review mitigations: verify implemented ATT&CK mitigations and their configuration against priority techniques.
6. Assess the coverage layer: examine the Navigator layer for honesty (claimed vs validated coverage) and currency against the latest ATT&CK release.
7. Execute adversary emulation: run purple-team or breach-and-attack-simulation tests against priority techniques and measure detection/prevention outcomes.
8. Analyse gaps: reconcile claimed coverage with emulation results; classify gaps as visibility, detection, or mitigation deficiencies.
9. Rate maturity: place the organisation on the capability model and agree a target level with a roadmap.
10. Report and remediate: deliver a findings report with prioritised remediation, feed the backlog into detection engineering, and schedule re-assessment.

10. Evidence request list

The following categorised evidence should be requested at the outset of an assessment to enable efficient, thorough review.

Programme and governance

• Threat-informed defence programme charter and RACI
• Steering-committee or governance review minutes
• Current threat profile / CTI reports mapping threats to ATT&CK groups and techniques
• ATT&CK version-currency and remapping records

Coverage and detection

• Exported ATT&CK Navigator coverage layer(s)
• Detection catalogue / SIEM-EDR content library tagged with technique IDs
• Detection-as-code repository history and test results
• False-positive and tuning records

Data sources and visibility

• Log-source and telemetry inventory
• Data-source coverage matrix mapped to data components
• Log retention and integrity (immutability/forwarding) evidence

Mitigations and hardening

• Mitigation-to-technique mapping
• Hardening baselines (application control, MFA, segmentation, PAM)
• Configuration evidence and exception register

Validation

• Adversary-emulation plans and purple-team reports
• Breach-and-attack-simulation results
• Incident post-mortems mapped to ATT&CK techniques
• KPI dashboards and trend data

11. Roles and responsibilities

12. KPIs to track

• Technique coverage: percentage of priority techniques with at least one documented, tuned detection.
• Validated coverage: percentage of priority techniques whose detections have been confirmed by adversary emulation.
• Data-source coverage: percentage of required data components instrumented and retained.
• Detection efficacy: true-positive rate and false-positive rate per detection over time.
• Mean time to detect (MTTD) and mean time to respond (MTTR) by technique or tactic.
• Emulation pass rate: proportion of emulated techniques detected and/or prevented per exercise.
• Coverage drift: change in coverage after each ATT&CK release before remapping.
• Mitigation coverage: percentage of priority techniques with an implemented ATT&CK mitigation.
• Time-to-detection-content: mean time from a new relevant technique/threat to deployed detection.
• Gap closure rate: percentage of identified coverage gaps remediated within target SLA.

13. Readiness checklist

• A named owner and mandate for a threat-informed defence programme exist.
• A current CTI-driven threat profile maps priority threat groups and techniques to your organisation.
• An ATT&CK Navigator coverage layer is maintained and version-controlled.
• Required data sources are inventoried and instrumented, with a documented gap register.
• Detections are catalogued and tagged with technique IDs in a detection-as-code repository.
• Detections are tuned, with false-positive rates tracked.
• ATT&CK mitigations are implemented and mapped to priority techniques.
• Adversary-emulation or purple-team exercises validate coverage on a defined cadence.
• Breach-and-attack-simulation or equivalent continuous validation is in place.
• Coverage is re-baselined after each ATT&CK release.
• KPIs are tracked and reported to leadership.
• Real-incident findings are fed back into technique coverage.
• Mobile and/or ICS domains are assessed where the estate warrants.
• IT/OT segmentation is verified where operational technology is in scope.

14. Common gaps

• Vanity coverage: Navigator layers claiming detection that has never been validated by emulation.
• Missing data sources: analytics written for techniques whose underlying telemetry is not actually collected or retained.
• IOC dependence: reliance on hashes/IPs rather than durable behaviour-based detection.
• No threat prioritisation: attempting broad, shallow coverage instead of focusing on relevant threat actors.
• Stale mapping: coverage never remapped after ATT&CK releases, leaving deprecated or newly split techniques uncovered.
• Detection sprawl without tuning: noisy rules that analysts ignore, undermining efficacy.
• No purple teaming: detection efficacy assumed rather than tested against live emulation.
• Cloud and identity blind spots: on-premises focus while modern intrusions pivot through IdPs and SaaS.
• Sub-technique neglect: coverage claimed at parent-technique level while specific sub-techniques go undetected.
• No feedback loop: real incidents not mapped back to ATT&CK to close the discovering gaps.
• Fragmented ownership: CTI, SOC, and red team operating in silos with no shared coverage view.
• Ignoring mitigations: over-investment in detection while feasible preventative controls (MFA, application control, segmentation) are neglected.

15. MITRE ATT&CK mapped to other frameworks

ATT&CK is complementary to control-based standards: it describes adversary behaviour, while standards prescribe controls. Mapping the two lets organisations demonstrate that their controls actually counter real-world techniques. The table below sketches how ATT&CK relates to widely used frameworks.

16. How CyberSigma helps

Frequently asked questions

Need help with MITRE ATT&CK?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.