Threat modelling with STRIDE, ATT&CK and CAPEC

Why this matters

Threat modelling is the activity that turns a design into a list of things that could go wrong, before anything is built. It is the cheapest security control available, because a threat found on a diagram costs a conversation and the same threat found in production costs an incident.

CAS-005 places it in the governance domain rather than in architecture, and that placement is deliberate: a threat model is only useful if it produces prioritised, owned work that enters the risk register. A model drawn once, admired, and filed is a common and recognisable failure, and scenarios are built on it.

The three named frameworks do different jobs and are frequently confused. STRIDE is a method for finding threats in a design. ATT&CK is a catalogue of observed adversary behaviour. CAPEC is a library of attack patterns. Knowing which to reach for is most of what this objective tests, and it is also the practical skill — reaching for ATT&CK during a design review produces a list of techniques with no relationship to the thing being designed.

The lesson

Threat actor characteristics: capability, intent and resources, and why attribution is not the point

Modelling starts with who you are defending against, because the same asset warrants different controls depending on the adversary.

The characteristics that change a decision:

• Capability. What they can actually do — commodity tooling, purchased access, bespoke exploit development, supply chain compromise.
• Intent. What they want. Financial return, disruption, espionage, ideology, or no particular interest in you beyond opportunity.
• Resources. Time, money and people. This is what separates an adversary who will move on from one who will persist for months.
• Risk tolerance. How much attention they will accept. A state-aligned actor optimising for stealth behaves very differently from a ransomware operator who wants to be noticed at the end.
• Access. Where they start. External, an insider, a supplier, or a compromised customer.

Grouped conventionally: unskilled opportunists using published tooling; hacktivists seeking visibility; organised crime optimising return per hour; insiders, whose distinguishing property is legitimate access and knowledge rather than skill; state-aligned actors with time and budget; and competitors seeking specific information.

The point about attribution is worth being precise about. Naming the actor is rarely possible with confidence, frequently wrong, and — importantly — does not change what you should build. What changes your design is the characteristics. An adversary with bespoke capability and unlimited time defeats controls that assume a noisy opportunist, whether or not you know who they are. Scenarios that dwell on attribution are usually testing whether you will spend effort on a question that does not affect the answer.

The useful application is scoping. If the credible adversary is an opportunist, internet exposure and known vulnerabilities dominate. If it is an insider, separation of duties, monitoring of privileged activity and data egress dominate. If it is a resourced external actor, assume initial access succeeds and design for detection and containment instead.

STRIDE applied to a real data flow diagram, category by category

STRIDE is a checklist applied to the elements of a design, and its value is that it is exhaustive over a small set of categories, so it finds the threats nobody thought of rather than the ones everybody already worries about.

Start with a data flow diagram containing four element types: external entities, processes, data stores, and data flows — plus trust boundaries drawn wherever the level of trust changes. The boundaries are the important part and the next lesson is entirely about them.

Then apply the six categories, each of which is the violation of one property:

Applied to a single flow — a browser submitting a form to an API which writes to a database — STRIDE generates: can the client be spoofed, or the API endpoint impersonated; can the request be tampered with in transit or the stored record altered afterwards; can the user deny submitting it, and does the log prove otherwise; can the payload be read en route or the store be read directly; can the endpoint be flooded or the database exhausted; can a submitted value cause the API to act with higher privilege than the caller holds.

Two practical notes. Not every category applies to every element, and recording "not applicable, because..." is a result rather than a gap — an unexplained blank is indistinguishable from an unconsidered one. And the output is a list of threats, not vulnerabilities: each becomes a question for testing or a control decision, and the ones you choose not to address become accepted risks with owners.

MITRE ATT&CK as a behaviour catalogue, and reading a technique back to a detection

ATT&CK is a structured, evidence-based catalogue of what adversaries have actually been observed doing, organised as tactics (the adversary's objective — initial access, persistence, lateral movement, exfiltration) each containing techniques and sub-techniques (the specific ways of achieving it).

The difference from STRIDE matters. STRIDE reasons about a design you are building and asks what could be done to it. ATT&CK describes behaviour that has been done, in operational terms, across real environments. So ATT&CK is weak at design review and strong at three other things:

• Detection coverage. Map your existing detections to techniques and the gaps become visible as a map rather than a feeling. This is the single most common professional use and it reappears in domain 4.
• Threat-informed prioritisation. Where intelligence says a relevant actor favours certain techniques, those move up the queue.
• Common language. A shared identifier for a behaviour lets an intelligence report, a detection rule and a hunt hypothesis refer to the same thing.

Reading a technique back to a detection is the applied skill. For each technique, ask what data source would show it — process creation, command line, authentication logs, network flow, file modification, cloud audit events — then whether you collect that source, from what proportion of the estate, with what retention, and whether a rule exists over it. That chain is where coverage claims usually break: the rule exists, the data source is collected from 40% of hosts, and the coverage map is green.

A caution worth carrying: a technique marked covered by one brittle rule is not covered. Techniques have many implementations, and a signature matching one tool's default behaviour fails against the same technique performed differently.

CAPEC as an attack-pattern library and where it complements ATT&CK rather than repeating it

CAPEC — a catalogue of attack patterns — describes how attacks work at the level of the mechanism, abstracted from any particular campaign. Where ATT&CK says "adversaries have used this technique against enterprise systems", CAPEC says "here is the general pattern of this class of attack, its prerequisites, the skill required, the weaknesses it exploits, and the mitigations".

The distinction in one line: ATT&CK is adversary behaviour observed in operations; CAPEC is attack mechanism described in the abstract. They overlap and cross-reference, and they are strong in different places.

CAPEC is more useful when:

• You are modelling a design or an application rather than an enterprise estate. CAPEC covers application, hardware, physical and social patterns that enterprise ATT&CK does not aim at.
• You want the prerequisites and mitigations for a class of attack, because CAPEC entries state them explicitly.
• You are connecting to weaknesses in code, because CAPEC patterns reference weakness identifiers, which links a threat model to the specific defect class a code review or test should look for.

ATT&CK is more useful when you are planning detection, responding to an incident, consuming intelligence, or assessing an operational environment.

In a mature process all three appear in sequence: STRIDE over the diagram to generate threats systematically; CAPEC to understand the mechanism and mitigations of the interesting ones; ATT&CK to decide what detection is required for those that will not be fully prevented.

Turning a model into a prioritised control list instead of a diagram nobody revisits

The failure mode is well known: a modelling workshop, a large diagram, a long threat list, genuine enthusiasm, and no change to anything. Four practices prevent it.

Every threat gets a disposition. Mitigated by a named control, transferred, accepted with an owner, or eliminated by a design change. A threat with no disposition is an open item, and the count of those is the model's real output.

Accepted threats go into the risk register, in the form from the previous lesson, with the affected property and a residual. This is the connection that makes threat modelling governance rather than an engineering exercise, and it is why the objective sits in domain 1.

Prioritise by risk, not by category. STRIDE produces a flat list; prioritisation needs impact and likelihood, and the discriminator is usually what sits behind the trust boundary the threat crosses.

Re-model on change, not on schedule. A threat model describes a design, so it expires when the design changes — a new integration, a new data flow, a new environment, a change of provider. Tying re-modelling to architecture change review keeps it current; tying it to an annual date guarantees it is wrong for most of the year.

Two measures make the practice visible to management: the proportion of changes that had a model before build, and the number of threats still without a disposition. Both are small numbers that can go in the board report from lesson three, and both are far more informative than the number of models produced.