Edição original em inglês. A tradução desta nova análise está em preparação.

Policy & leadership

MITRE ATT&CK: From Adversary Behaviour to Defensible Security Decisions

A CISO guide to prioritisation, detection evidence and the limits of a coverage matrix.

Published: 9 October 2026

What ATT&CK contributes

MITRE ATT&CK is a knowledge base of observed adversary behaviour, organised across Enterprise, Mobile and industrial-control contexts. It is not a compliance standard or a guarantee that every possible attack has been catalogued. [1] For a security officer, its value is a common vocabulary that allows threat intelligence, engineering, operations and leadership to discuss the same behaviour without relying only on product names.

Read the model before colouring the matrix

A tactic describes an adversary objective; a technique describes a way of pursuing it; a sub-technique provides a more specific form; a procedure is an observed implementation. [1] These distinctions matter when evidence is mapped. A report that mentions a compromised account may justify a carefully scoped mapping, but not every technique associated with a named group. Record the source, observation, mapping rationale and uncertainty separately.

Version discipline is part of the analysis

The version record consulted for this article lists ATT&CK 19.2. The April 2026 release changed the Enterprise taxonomy by separating Stealth and Defense Impairment. [2][3] A historical dashboard using older labels is not automatically wrong, but it must say which release it represents. Keep stable identifiers, object versions and review dates in the detection register. Review changed and deprecated objects before comparing coverage across reporting periods.

Begin with a mission scenario

Our recommended starting point is one consequential scenario, not the entire matrix. Consider a hypothetical deployed support organisation whose privileged identity is used to access maintenance information. Define the assets, access path, business impact and plausible adversary actions. Select relevant behaviours from evidence and architecture. Then ask which action could be prevented, which could be observed and what the team would do with that observation. This makes prioritisation explainable.

Worked example: legitimate access used inappropriately

MITRE’s T1078 entry concerns adversary use of valid accounts. [4] In our example, the account owner’s legitimate entitlement does not make every session trustworthy. Useful evidence could include authentication context, device state, privilege elevation, sensitive-resource access and subsequent export. The analytic should explain the suspicious combination, such as an unapproved privileged session followed by an unusual sensitive-data operation. A successful login or a foreign IP address alone does not prove malicious intent.

A detection is a chain of dependencies

For every proposed analytic, specify the telemetry, collection method, required fields, time synchronisation, retention, processing delay and owner. Document what is invisible when a device is offline, a licence feature is absent or a provider does not expose the required log. Then define the rule logic, expected legitimate explanations and the response procedure. A rule listed in a SIEM is not coverage if its input never arrives or nobody can act on the alert. These are editorial implementation recommendations.

Use explicit evidence states

We recommend distinguishing mapped, instrumented, tested and operationally validated. Mapped means a relationship has been documented. Instrumented means the necessary observations are available. Tested means an authorised scenario produced the expected result. Operationally validated means an analyst could understand and handle that result within the service requirement. Store the last test date, scope and known limitations. A coloured cell without these distinctions overstates confidence.

Test safely and learn from missed detections

Use authorised simulations in an appropriate test environment and coordinate any production validation with service owners. Start with benign test actions where possible; do not reproduce destructive behaviour on operational equipment merely to obtain a coverage mark. A failed test should lead to a diagnosis: missing data, incorrect logic, insufficient context, alert routing or an unavailable response action. Retest the relevant change, rather than changing the dashboard colour by assumption.

Connect ATT&CK to governance and controls

ATT&CK describes behaviours; CSF describes cybersecurity outcomes. [1][6] Our proposed mapping adds a third layer: the organisation’s actual controls, owners and evidence. One control may address several behaviours, and one behaviour may require multiple controls. Record the relationship as an analytical judgement, not an equivalence claim. Leadership should see the residual scenario and investment choice, not simply a percentage of techniques associated with a security product.

What the board should measure

Useful measures include tested visibility for priority scenarios, time to a meaningful analyst decision, unresolved telemetry gaps and response actions that can actually be executed. Report false positives and operational disruption alongside detection success. Do not use the number of rules or the percentage of the whole matrix coloured green as a proxy for mission protection. Those figures can increase while the most consequential access path remains poorly understood.

Tools and implementation choices

MITRE supplies data and tooling resources, including structured datasets and Navigator-related resources. [5] Use a versioned dataset and keep local annotations under change control. A practical record links the technique identifier to the source observation, affected platform, analytic, required data, test evidence, response owner and residual gap. The tool is a means to maintain those relationships; purchasing a platform does not create them automatically.

Conclusion: a vocabulary must lead to a decision

ATT&CK is most useful when it changes what the organisation tests, instruments or funds. For the hypothetical privileged-access scenario, the deliverable is a demonstrated ability to identify and handle inappropriate access, with limitations understood. It is not a claim to know the identity or motivation of every actor behind an account. Use the model to sharpen evidence and priorities, then connect the result to accountable risk decisions.

References

1. MITRE · ATT&CK FAQ
2. MITRE · ATT&CK version history
3. MITRE · April 2026 release notes
4. MITRE · Valid Accounts, T1078
5. MITRE · ATT&CK data and tools
6. NIST · CSF 2.0

Original editorial analysis and paraphrases. Recommendations are distinguished from documented facts; references do not imply institutional endorsement.

Francisco Javier Jurado Alonso