MITRE ATT&CK as a Product Requirement — How to Use it Without Becoming a Checkbox Exercise

The Framework Cannot See What You Cannot Lose

Every major breach of the past five years—from SolarWinds' supply-chain poisoning in 2020 through Change Healthcare's ransomware capitulation in 2024—has been mapped post-facto onto MITRE ATT&CK. Incident response teams dutifully plot attack chains across tactics and techniques. Compliance officers tick boxes against NIST CSF. Chief Information Security Officers announce MITRE-aligned defence strategies to boards. And yet the incidents continue, often following paths that MITRE's kill-chain model categorises but does not illuminate, let alone prevent.

The problem is not MITRE ATT&CK itself—it is a taxonomy of adversarial behaviour executed against organisations that fundamentally assume data can be protected through visibility and response. That assumption is broken. MITRE ATT&CK has become the vocabulary of tactical detection without the architecture of resistance. It is treated as a product requirement, a grid against which security tools are purchased and tuned, rather than as a foundation for structural immunity. Organisations map their defences to MITRE; MITRE maps what defences fail to stop.

This article challenges that inversion. It argues that MITRE ATT&CK is useful only when it is reversed—when organisations engineer their infrastructure such that entire classes of MITRE techniques become impossible by design, not because they are detected and blocked. That requires leaving behind the detection-and-response paradigm entirely and building systems where the adversary cannot reach exploitable state in the first place.

The Industry Narrative: MITRE as Defensive Inventory

The story is familiar. In 2013, MITRE Corporation published the first comprehensive adversary tactics and techniques framework (ATT&CK), cataloguing how real adversaries behaved in real networks. By the time it was released to the public in 2015, organisations began using it as a measurement yardstick: Which MITRE techniques can our EDR, SIEM, and firewall detect? Security vendors rushed to tag their products with MITRE technique IDs. Gartner's Magic Quadrant became a secondary validator—SIEM vendors advertised "coverage" of 73% of MITRE TTP's, as though incomplete detection were a quantifiable virtue.

The 2020 SolarWinds campaign (CVE-2020-14644 through the Sunburst backdoor, compromising Treasury, Commerce, Homeland Security, and dozens of private sector firms) was dissected into MITRE terms: T1195 (Supply Chain Compromise), T1021.002 (SSH/Remote Access), T1102 (Web Service), T1041 (Exfiltration Over C2), T1052 (Exfiltration Over Physical Media). Maturity frameworks—CISA's CMMC, SANS' maturity model, ISO 27001 Annex A—all began requiring documented MITRE coverage. The UK's NIS2 implementation guidance (DCMS 2024) and Australia's APRA CPS 234 (effective 2025) both reference MITRE-aligned threat modelling.

Organisations responded rationally within that framework: they built MITRE heat-maps. They colour-coded detection coverage by tactic—command-and-control in green, lateral movement in amber, exfiltration in red. They hired red teams to walk attack chains and verify coverage. They tuned YARA rules and Sigma templates against MITRE profiles. They implemented behavioural EDR (CrowdStrike Falcon, Microsoft Defender, Sophos Intercept X, SentinelOne) and correlated alerts to MITRE technique IDs. They built SOAR playbooks that triggered on T1055 (Process Injection), T1574 (Hijack Execution Flow), T1547 (Boot or Logon Autostart Execution).

By 2023, major attacks were still succeeding—Scattered Spider against M&S (2024-2025), MGM Resorts and Caesars Entertainment (2023, both via social engineering and phishing), Change Healthcare (2024, via Citrix and Falcon detection evasion)—and the response was not to question the framework but to expand it. MITRE ATT&CK now includes 14 tactics, 200+ techniques, and over 600 sub-techniques. More coverage. More detection. More maturity.

Yet coverage did not correlate with resistance. The Synnovis NHS incident (June 2024, LockBit ransomware via compromised credentials) laid bare the mismatch: the organisation had documented controls, EDR, logging, and incident response procedures—all MITRE-aligned—but the adversary moved with such speed (encrypting systems in hours) that detection and response were irrelevant. The kill-chain happened faster than the kill-chain could be observed.

The Structural Failure: Detection Cannot Be a Substitute for Denial

The core failure is this: MITRE ATT&CK maps the adversary's options in a world where those options exist. It is descriptive, not prescriptive. It assumes the adversary has reached a state where they can enumerate techniques—because they have already compromised something. It catalogues what the attacker does once they are inside. It does not—and cannot—address the architectural question: Why is the adversary inside at all?

Detection-and-response frameworks operate on a false premise: that seeing an attack is the same as stopping it. The Synnovis incident revealed the truth: an attacker moving at operational speed (days to encryption) will outpace a detection system that must observe, alert, investigate, escalate, and act. The MITRE heat-map becomes a post-mortem artifact, not a defensive tool. NIST CSF's Respond function executes too slowly. EDR's dwell-time measurement (days to detection, sometimes weeks) is an admission of defeat masked as a metric.

The problem deepens when MITRE becomes a purchasing driver. Security teams buy tools evaluated against MITRE coverage rather than against the organisation's actual threat model. A vendor claims T1021 (Remote Services) detection across 15 sub-techniques. An organisation adds it to the stack. Neither has asked: In our architecture, why would Remote Services be necessary? This is the checkbox exercise—coverage without consequence.

Change Healthcare's ransomware attack (February-March 2024, UnitedHealth Group subsidiary) illustrates the inversion. The attackers (attributed to LockBit 3.0) exploited a known Citrix NetScaler vulnerability, achieved persistence, and escalated to domain administrator—all of which map neatly to MITRE tactics. The organisation had endpoint detection, network logging, and incident response drills. But the infrastructure was designed around the assumption that compromises would happen and that response would be timely. It was not. The attacker controlled patient data and pharmacy systems faster than the organisation could react, forcing capitulation and a reported $22 million settlement. The MITRE mapping was forensically accurate and operationally worthless.

The PULSE Reading: Immunity by Substrate, Not by Visibility

PULSE's doctrine inverts this logic. Rather than ask "Which MITRE techniques can we detect?", it asks: "Which MITRE techniques are impossible in our architecture?" The distinction is architectural, not procedural.

Consider the foundational principle: zero-knowledge substrate. An adversary can execute no technique against data they cannot see. If the organisation's data is encrypted at the point of storage, in transit, and in use—such that the organisation itself cannot read it without proof of authorisation from a cryptographic substrate, not a policy server—then T1020 (Exfiltration Over Different Protocol), T1041 (Exfiltration Over C2), T1048 (Exfiltration Over Alternative Protocol) become impossible. The data has no unencrypted representation for the adversary to find or move. This is not detection; it is denial by design.

Similarly, data-plane and control-plane separation eliminates entire technique families. If compute processes cannot directly write to storage—if all writes pass through a immutable, cryptographically-sealed audit interface that logs before accepting modification—then T1485 (Data Destruction), T1561 (Disk Wipe), T1488 (Service Stop and Restart) cannot execute without creating detectible evidence in the control plane. The adversary cannot silently destroy or modify data. Ransomware's entire value proposition—encrypt or destroy, then extort—collapses.

Adaptive active defence (continuous adversarial posture adjustment) further contracts the attack surface. Rather than assume a static security posture and respond to deviations, the system continuously shifts: cryptographic keys rotate hourly, network routing changes based on anomaly scoring, privilege elevation requires continuous re-attestation against zero-trust predicates. An adversary who achieved persistence (T1547, T1053, T1547.001 Scheduled Task/Job) discovers that their scheduled task now runs in an isolated, ephemeral execution environment with no access to persistent state. Lateral movement (T1021) fails because the network topology is unpredictable, and inter-node communication requires cryptographic proof of non-compromise.

Domain-specific automation, engineered into the substrate, eliminates the response-time problem. Incident handling is not a human-orchestrated workflow (SOAR as a separate layer). It is built into the infrastructure itself. If an anomaly crosses a threshold, the system does not alert; it automatically isolates the affected node, preserves state cryptographically, and initiates recovery—all within milliseconds, not hours. The adversary faces isolation and forensic capture, not a window of opportunity.

Reframing MITRE as a Design Constraint

Under this model, MITRE ATT&CK becomes not a menu of techniques to detect but a checklist of vulnerabilities to engineer away.

Take the Change Healthcare case again. The attack depended on persistence through legitimate credentials and the ability to move laterally through the network with those credentials. In a zero-knowledge architecture, credentials are ephemeral cryptographic proofs, not long-lived tokens. They expire within minutes. They are tied to device state (T1571: Non-standard Port, T1071: Application Layer Protocol, T1001: Data Obfuscation—all require stable network paths and persistent credential validity). If credentials are continuously revoked and re-issued only after re-attestation, the adversary cannot maintain a stable connection. T1021 (Remote Services) becomes impossible to sustain.

Similarly, ransomware's cascade relies on administrative privilege elevation (T1134: Access Token Manipulation, T1548: Abuse Elevation Control Mechanism) and the ability to enumerate and access shared resources (T1135: Network Share Discovery, T1003: OS Credential Dumping). In a substrate where privilege is revoked and re-earned per-action (not per-session), where shares are cryptographically isolated and accessible only after zero-trust verification, the attack cannot propagate. Synnovis' infection would have halted at the first encrypted partition it could not write to—not because detection fired, but because denial by design made further movement impossible.

For regulatory compliance (NYDFS Part 500, SEC 4-day breach notification rule, DORA, NIS2), this model provides evidence of material control rather than evidence of attempted detection. Instead of reporting "we detected 47 T1005 incidents and escalated to incident response," the organisation reports "our architecture makes T1005 impossible; here is the cryptographic proof." That shifts the narrative from breach-and-response to breach-resistance.

Building the Substrate

This requires moving beyond frameworks and into engineering. The components are not new—zero-knowledge proofs, threshold cryptography, hardware security modules, immutable logs, ephemeral execution environments, continuous attestation—but their integration into the baseline security architecture is. They cannot be bolted on via SIEM, EDR, or SOAR; they must be woven into the operating system, the network stack, the storage layer, and the access control primitives.

Organisations beginning this transition should:

Map MITRE techniques to architectural dependencies. For each technique in your threat model, identify what system state must exist for the technique to execute. Lateral movement requires network reachability and credential reuse. Persistence requires writable storage and execution contexts. Data exfiltration requires data visibility and outbound connectivity. Document each dependency.

Replace dependencies with cryptographic predicates. Rather than firewalls that block ports (inspectable and circumventable), use cryptographic identity and zero-knowledge proofs that execution is authorised. Rather than EDR that monitors process behaviour (observable and evadable), use secure enclaves and sealed execution environments where behaviour is constrained by hardware.

Separate control and data planes explicitly. Do not allow data-plane operations to modify security policy or logging. Ensure all writes are logged before they are accepted. Make data-plane and control-plane components cryptographically independent such that compromise of one does not leak the other.

Measure resistance, not detection. The metric is not MTTR (mean time to respond) or dwell-time (days to detection) but the number of MITRE techniques made architecturally impossible. Aim for a zero-attack-surface model where the adversary has exhausted all TTPs and found no executable path.

Conclusion: From Compliance to Resistance

MITRE ATT&CK remains a superb taxonomy of real-world adversarial behaviour. The mistake is treating it as a requirement for security tools rather than as a design constraint for security architecture. Organisations that continue to purchase EDR and SIEM coverage against MITRE heat-maps are buying expensive insurance policies. Those that engineer their infrastructure to make entire MITRE tactic families structurally impossible are building immunity.

The 2024-2025 incident landscape—Scattered Spider's credential theft at M&S, the cascading Snowflake tenant compromise, the Change Healthcare ransomware acceleration—all suggest that detection-and-response has reached its ceiling. Organisations with maturity frameworks and comprehensive MITRE coverage still failed. The future belongs to architectures where the adversary's options—enumerated in MITRE, tactical in execution—are rendered moot by design.

This transition is not incremental. It requires rethinking infrastructure from cryptographic substrate upward. It demands specificity about which MITRE techniques are architecturally denied, with proof. It places compliance not in detection logs but in control-plane cryptography.

Qualified operators seeking to move beyond MITRE-mapped detection into architecturally-grounded resistance may request a technical briefing under executed NDA.