Thesis

1. Introduction

MITRE ATT&CK® has been extraordinarily successful. It provides a shared vocabulary for adversary behaviour, underpins threat intelligence, drives detection engineering, and enables purple team exercises across the industry. That success is not in dispute here.

What is in dispute is whether ATT&CK's current design is as principled as it could be. The framework has grown through accretion — new techniques, sub-techniques, and platforms added as threat intelligence accumulates — without revisiting the underlying model. The result is a corpus with inconsistent technique granularity, a technique (T1078 Valid Accounts) that fails the basic criteria for what a technique should be, and an entire tactic (T1059 Execution) that conflates technique with Execution Medium.

ATT&CK But Better is not a replacement for ATT&CK. The ecosystem — the SIEM integrations, the CTI workflows, the compliance mappings — is too large and too valuable to discard. It is a demonstration of what falls out naturally when you apply more opinionated design principles to technique modelling, and an argument that those principles are worth adopting.

2. Three Structural Critiques

2.1 Valid Accounts is not a technique

T1078 Valid Accounts appears across almost every tactic and is among the most-referenced techniques in threat intelligence. Yet it fails four criteria that any well-formed technique should satisfy.

In this framework, T1078 is removed. Valid accounts are modelled as an access precondition on techniques — they describe how the attacker arrived at the point of technique execution, not a technique in their own right.

2.2 Execution is not a tactic — it describes an Execution Medium

The Execution tactic covers every instruction executed on any CPU. Like Valid Accounts, attackers cannot choose to avoid it — all techniques involve code execution at some level. More precisely: Execution does not describe what the attacker is doing to the victim's system; it describes how the technique was triggered.

Consider creating a scheduled task for persistence. The technique is the same regardless of whether the attacker triggers it via schtasks.exe, PowerShell, WMI, or a direct COM API call. What changes is the Execution Medium — the channel through which the technique was triggered. The scheduled task artifact is created in every case; the defensive question (was a new scheduled job created?) is unchanged. A Sigma rule that gates on actor.process.file.name = schtasks.exe has a hard STP 3 ceiling because the attacker switches Execution Medium and the technique continues unchanged.

The sub-techniques of T1059 — PowerShell, Bash, Python, AppleScript — are not techniques of varying granularity. They are Execution Mediums: the channels through which techniques are triggered. ATT&CK currently has two containers — tactic and technique — and has been forcing this third concept into the technique slot. This framework introduces Execution Medium as a separate, orthogonal dimension.

As a consequence, the Execution tactic is removed entirely. Techniques currently listed under it that describe real attacker behaviour — scheduled tasks used for persistence, service creation for lateral movement — are correctly categorised under the tactics they actually serve. What remains of Execution after those are re-homed is the Execution Medium layer, which belongs in the Execution Medium dimension, not a tactic.

2.3 Techniques lack definitional criteria

ATT&CK techniques are defined by prose descriptions and threat intelligence citations. There is no formal test for whether something qualifies as a technique — which is why Valid Accounts and Execution were able to enter the framework. There is also no formal test for technique boundaries, which is why granularity is inconsistent: some techniques cover a family of behaviours, others a single tool configuration.

Without a definition criterion, there is no principled way to derive detection requirements. Which OCSF event class does this technique map to? Which fields are invariant to the technique's identity versus variable across implementations? These questions are currently answered heuristically, which is why STP ratings must be assigned manually and why coverage gaps are difficult to characterise formally.

3. Framework Design

3.1 Ontological definitions

Every technique in this framework is defined as an action on a D3FEND artifact class:

D3FEND provides a rigorous hierarchy of digital artifact classes — ProcessSegment, RegistryKey, UserAccount, DocumentFile — that anchor technique definitions formally. The action vocabulary is grounded in D3FEND's own verb taxonomy (d3f:reads, d3f:modifies, d3f:creates), extended with domain-specific terms where the standard verbs are insufficient — for example, Inject for cross-process memory writes. Deriving a complete, closed action set from D3FEND's ontology is ongoing work.

If you cannot name the artifact being acted on, the technique is not well-formed. This is the test that eliminates T1078 Valid Accounts: it has no artifact, no action, and no state change that can be observed.

3.2 Technique / sub-technique as superclass / subclass

A technique is an abstract event definition. A sub-technique is the same definition with one or more variable fields promoted to invariant — their values constrained to specific constants. This makes the relationship formally derivable rather than editorial.

A sub-technique is justified if and only if it constrains one of the three ontological slots — Actor, Verb, or Artifact — to a more specific value. T1003.001 LSASS Memory constrains the Artifact slot: Process reads Password becomes Process reads Password[process.name = lsass.exe]. The sub-technique hierarchy is a field-constraint lattice, not an editorial choice about granularity. The STP implication — that a sub-technique has a higher achievable detection ceiling than its parent — is an emergent consequence of the constraint, not the criterion itself. The same mechanic governs the medium hierarchy: a sub-medium is a medium with one or more fields constrained to specific values.

3.3 Execution Medium as a separate dimension

Execution Medium is orthogonal to technique. The same technique can be triggered through many Execution Mediums, and switching Execution Medium does not change which technique is being performed. The model is: Tactic / Technique / Execution Medium — three dimensions, not two. Execution Mediums have their own type hierarchy parallel to techniques:

Execution Medium–scoped Sigma rules are samples, not canonical definitions. They constrain detection to a specific trigger channel and have a hard STP 3 ceiling. Three Execution Medium–scoped rules at STP 3 do not combine to exceed STP 3 — the attacker switches Execution Medium, the rules all miss. The definitional rule (STP 5) is the canonical form; Execution Medium–scoped rules illustrate what detection looks like when you accept the trigger constraint and make the ceiling cost explicit. This framework displays both on each technique page.

3.4 Environment-Dependent Entities (EDEs)

Some techniques target resources that are organisation-specific: the wiki the org uses, its identity provider, its code repositories. MITRE cannot enumerate all possible platforms, and attempting to produces the T1213 problem: Confluence is a sub-technique but Notion is not, and GitHub and GitLab share T1213.003 despite requiring completely different detection rules.

The solution is to define the technique against a D3FEND artifact class (e.g., DocumentFile, UserAccount, ScheduledJob). Each organisation then enumerates their instances of that artifact class and generates organisation-specific sub-techniques using the naming convention:

The full form is T1213.003.github: everything after the ATT&CK sub-technique level can be ignored by vanilla ATT&CK consumers, preserving cross-organisation comparability at the sub-technique level while enabling precise, organisation-specific coverage tracking. Canonical names for well-known platforms are seeded by the framework to prevent naming collisions (github, not github.com or GitHub). This seeding role should ultimately belong to MITRE; this POC begins the process. Tooling to walk organisations through enumerating their EDE instances against each D3FEND artifact class is a planned deliverable.

4. What Falls Out Naturally

4.1 OCSF field taxonomy

Each technique maps to an OCSF event class. Fields on that event are classified by their role relative to the technique definition:

Fields are also annotated with whether the entity they describe is under attacker control at the time of the event: attacker-controlled, victim, post-success (not controlled before the technique succeeds, but becomes so afterward), or tainted (victim entity that has been modified by the attacker). Attacker-controlled and post-success entities identified at detection time are the immediate IR response targets.

4.2 Derived STP ratings for detection

The Summiting the Pyramid (STP) framework rates detection rules by robustness to attacker evasion. In this framework, STP ratings are derivable from the technique definition rather than assigned heuristically. This framework uses the following five-level scale:

Ontological invariance establishes the theoretical STP ceiling — the property a rule must have to be STP 5 for this technique. Whether a sensor observes the invariant field in practice, and whether the attacker has a way to suppress or alter that observation, determines the practical STP. The framework addresses the theoretical question; sensor coverage analysis is a separate exercise that practitioners must perform against their own telemetry.

Definitional Sigma rules are auto-generated on each technique page from invariant fields. These rules are intentionally broad — they are specifications, not operational alerts. Their purpose is to make the technique definition executable. Medium-scoped example rules are shown alongside them to make the STP ceiling cost explicit.

4.3 Derived STP ratings for mitigation

The same logic applies to mitigations. A mitigation tied to a specific Execution Medium — blocking PowerShell execution — has a hard STP 3 ceiling because the attacker switches Execution Medium. A mitigation that operates on the artifact modification that defines the technique — for example, Arbitrary Code Guard preventing cross-process memory writes for T1055 Process Injection — is STP 5.

"No high-STP mitigation exists" is a useful and explicit output of this framework. It means detection is the primary defensive lever for that technique, and defenders should be told this clearly rather than left to infer it from a sparse mitigation list.

4.4 Post-attack state and IR posture

Each technique carries a post-attack state describing what happened to the target artifact after the technique succeeds. The taxonomy is response-oriented — each state implies a distinct IR posture — rather than ontologically structural. "Modified" is not a parent of "Controlled" even though process injection technically modifies a ProcessSegment; the IR responses are completely different.

4.5 D3FEND countermeasure classification

D3FEND countermeasures are split into Mitigate (preventive controls applied before an attack) and Respond (IR actions taken after detection). Preventive controls include d3f:NetworkTrafficFiltering, d3f:ExecutionIsolation, and d3f:SystemConfigurationPermissions. Response actions include d3f:ProcessTermination, d3f:AccountLocking, and d3f:CredentialRevoking. This split is a framework-level classification derived from D3FEND class semantics, not a per-technique editorial choice.

5. What ATT&CK Does Well

ATT&CK's breadth and community adoption are genuine strengths. The framework has motivated threat-informed defence as a discipline, given red and blue teams a shared vocabulary, and produced a body of threat intelligence that references a stable identifier space. The ecosystem built on ATT&CK — the SIEM integrations, the CTI platforms, the purple team methodologies — represents years of coordinated work.

The critiques here are structural and definitional, about the model not the effort. The goal is not to discard what ATT&CK has built but to demonstrate that the model can be improved, and that those improvements have concrete, measurable consequences for detection quality and defensive prioritisation.

6. Status

This is a proof of concept. Techniques were selected to demonstrate distinct properties of the framework rather than for breadth of coverage. The selection criteria were: at least one technique that is removed, at least one that is reclassified, and for defined techniques, coverage of each major framework concept — clean ontological definition, medium orthogonality, environment-dependent entities, and derived STP at both ends of the spectrum.

OCSF field paths are illustrative and should be verified against the OCSF schema for production use. Machine-readable formats (STIX, OWL) are deferred until the model is stable.