How does MITRE ATLAS relate to MITRE ATT&CK?

Updated

MITRE ATLAS and MITRE ATT&CK are separate, complementary knowledge bases built on the same tactical-technical mindset. ATT&CK catalogs adversary behavior against traditional enterprise IT and network environments; ATLAS catalogs threats and attacks against AI and machine-learning systems. They are not substitutes and not a parent-child hierarchy: an organization that runs both IT and AI workloads should treat them as two lenses on one security program, using ATT&CK for the conventional infrastructure layer and ATLAS for the AI layer, and mapping findings between them where an attack path crosses both.

The shared design logic

Both frameworks organize knowledge the same way in principle: adversary goals are grouped into high-level categories (tactics), and concrete ways of achieving those goals are described as techniques, with real-world or demonstrated procedures attached as evidence. This shared structure is why security teams can learn one and read the other without starting over.

The difference is the object of study:

Dimension MITRE ATT&CK MITRE ATLAS
Primary target Enterprise IT, endpoints, networks, cloud, identity AI and machine-learning systems and their supply chain
Unit of analysis Adversary tactics and techniques against conventional infrastructure Tactics and techniques against AI models, data, and pipelines
Typical examples of concern Credential access, lateral movement, command-and-control Data poisoning, model evasion, model extraction, prompt-level manipulation
Where it fits in operations Detection engineering, threat hunting, red teaming of IT AI risk assessment, ML red teaming, model and pipeline hardening

The table is a working orientation, not a claim that the two catalogs never overlap. An attack that compromises a training pipeline may begin with ordinary credential theft, which is squarely ATT&CK territory, and only later become an ATLAS concern.

Where they diverge in practice

The practical divergence is the attack surface and the evidence base. ATT&CK techniques are described in terms of host, network, and identity observables that most SOC tooling already collects. ATLAS techniques describe manipulation of data, models, and the interfaces around them, which often produce no conventional log signature at all — a poisoned training set or a subtly altered model may look normal to endpoint and network monitoring.

That difference drives how each framework is used. ATT&CK supports detection rules and hunts against telemetry you already have. ATLAS supports threat modeling and testing of AI systems, where the "detection" may be a data-integrity check, a model behavior test, or a supply-chain review rather than a log query.

Using both in security operations

A workable pattern is to keep the frameworks at different layers of the same program:

  1. Inventory AI assets separately. List models, training data, pipelines, and the APIs that expose them. These are the assets ATLAS is written for; they usually sit outside the scope of an ATT&CK-based asset inventory.
  2. Threat-model the AI layer with ATLAS. For each AI asset, walk the tactics and techniques and ask which apply given how the system is built, trained, and served.
  3. Keep ATT&CK for the surrounding infrastructure. The hosts, identities, and networks that train, store, and serve models remain conventional attack surface. Detection engineering and hunting there continue to use ATT&CK.
  4. Map the seams. Where an AI attack depends on a conventional intrusion step, record both the ATT&CK technique and the ATLAS technique so responders see the full path rather than half of it.
  5. Feed results into one risk register. Two frameworks, one prioritization process — otherwise AI findings and IT findings compete for attention without a common scale.

A concrete example of the seam: an adversary gains access to a model-training environment using stolen credentials (an ATT&CK-style intrusion), then alters training data so the deployed model misclassifies a specific input class (an ATLAS-style AI attack). A team that only tracks ATT&CK sees the intrusion and closes it; a team that only tracks ATLAS sees a degraded model with no idea how it happened. Tracking both reconstructs the chain.

Choosing where to start

If your organization has no AI systems in production, ATT&CK is the relevant framework and ATLAS can wait. If you are deploying or operating ML models — including third-party models and APIs — ATLAS becomes necessary because ATT&CK does not describe the AI-specific failure modes. If you are doing both, start with asset inventory and threat modeling at the AI layer, since that is where most teams currently have the least coverage, and keep ATT&CK running unchanged for the infrastructure underneath.