Security by Design · Part 4 — Cloud Threat Modelling & Controls: From Threat to Native Guardrail

This is Part 4 of the Security by Design program — threat modelling pointed at the cloud. The method from Part 2 and the pipeline wiring from Part 3 were framed around software you write; this part adapts them to the reality that most of what you run is software you rent. Your architecture is increasingly a composition of managed services — a queue here, a serverless function there, a managed database, an object store, an identity provider — spread across AWS, GCP or Azure, and possibly all three. Threat modelling a cloud architecture is the same four-question ritual, but the answers move: the components are services you configure rather than code you own, the trust boundaries fall in different and often surprising places, the threats skew heavily toward identity and configuration rather than memory-safety and injection, and — the good news — the mitigations are overwhelmingly cloud-native controls that already exist and just need to be turned on and enforced. This part is about making that shift, and about connecting your cloud threat models to the guardrails the Cloud Security Program builds.

The connective logic of the whole program comes to a head here. The Cloud Security Program gave you a catalogue of native controls across the five phases — foundation, network, data, detection, governance. But a catalogue does not tell you which controls matter most for your system; only a threat model does. Part 4 is the exercise that turns that catalogue from a generic best-practice checklist into a targeted, ranked plan: you threat-model your actual cloud architecture, and each high-priority threat points at the specific native guardrail that closes it, which then becomes policy-as-code exactly as Part 3 described. Threat modelling makes the cloud program proportionate; the cloud program gives the cloud threat model its mitigations.

Scope of this phase

Every part of this program is scope-bounded so you know exactly when you are done.

• In scope: how the four-question method changes for cloud architectures; where trust boundaries actually fall in a managed-service system (and the identity boundary that dominates); the cloud-specific threat categories that STRIDE under-prompts (especially the confused-deputy, over-broad-IAM, and public-exposure classes); and mapping each threat to the specific AWS / GCP / Azure native control that mitigates it, expressed as policy-as-code.
• Explicitly out of scope: the deep configuration of each native control, which the Cloud Security Program covers phase by phase and which this part references rather than reproduces; application-code threats (Parts 2–3); and organization-wide measurement (Part 5).
• Definition of done: the exit checklist at the end of this part. When every box is ticked, your cloud architectures are threat-modelled, each high-priority cloud threat maps to a named native control enforced as policy, and the practice is repeatable per new cloud service.

The shape below is the same across all three clouds — the threat categories are identical; only the control names change — which is exactly why the Cloud Security Program taught the controls as a three-column comparison. Learn the cloud threat once, apply the mitigation three ways.

How cloud threat modelling differs

The four questions do not change, but the way you answer each one does. "What are we building?" now means a diagram of services and their configurations, not processes and code — the boxes are the managed services, and the most important thing on the diagram is the identity and access relationships between them: which service can assume which role, which principal can read which store. In the cloud, the data-flow diagram is half about data and half about identity, because identity is the perimeter.

"What can go wrong?" shifts categories. Classic application threats recede (the managed database is patched for you; the serverless runtime handles memory safety) and cloud-native threats dominate: over-broad IAM permissions that let a compromised component do far more than its job, the confused-deputy problem where a service is tricked into using its privileges on an attacker's behalf, public exposure of storage or endpoints through misconfiguration, secrets sprawl across environment variables and images, and the blast-radius question of what an attacker reaches once they compromise one identity. STRIDE still helps, but it under-prompts these, so cloud threat modelling adds explicit prompts for them.

"What are we going to do about it?" has a happier answer than in application code: most cloud mitigations are native controls you enable and enforce, not code you write — which is why the mapping to the Cloud Security Program is so direct. And "did we do a good job?" gains a cloud-specific check: is the mitigation enforced preventatively (a guardrail that stops the misconfiguration) rather than just detected after the fact? In the cloud, prevention via policy is usually available and always preferable.

The trust boundaries move — and identity is the main one

In a hand-written application, the trust boundaries are mostly network and process boundaries. In a cloud architecture, the dominant trust boundary is identity: the line an attacker crosses is not usually a network hop but an assume-role, a permission grant, a token exchange. This reframes the whole exercise. When you draw the diagram, you draw the identity edges — this function assumes this role, this role can read this bucket, this user federates into this account — because those edges are where the highest-impact threats live. A compromised component with a narrowly-scoped identity is an incident; the same component with an over-broad identity is a breach, because the identity is what determines blast radius.

This is why the Cloud Security Program's foundation phase (identity and guardrails) is the substrate for cloud threat modelling: the least-privilege identity model it builds is precisely the mitigation that most cloud threats call for. When your cloud threat model finds "this function's role can read every bucket in the account, so compromising it exposes all data," the mitigation is a scoped role — a foundation-phase control — enforced so it cannot regress. Drawing the identity boundaries well is most of the value of a cloud threat model, in the same way that drawing trust boundaries well was most of the value of an application one.

Mapping cloud threats to native controls

The payoff of the exercise is a direct map from each high-priority cloud threat to the specific native control that closes it — the same "threat → mitigation" traceability from Part 3, but where the mitigations are cloud guardrails. The mapping is portable across providers because the control concepts are identical; only the service names differ.

Each row is a threat your model might surface and the native control that mitigates it on each cloud — and each of those controls is one the Cloud Security Program builds in depth. The Security by Design contribution is the selection: your threat model tells you which of these rows matter for this system and in what priority, so you are not enabling every control equally but weighting effort at your actual risk. A high-priority cloud threat then becomes policy-as-code, named for the threat, exactly as Part 3 established — here, a policy enforcing that a data-handling function's role cannot be over-broad:

package sbd.cloud.tm031

# Threat TM-031: export function's role must not grant account-wide S3 read.
deny[msg] {
    stmt := input.resource_changes[_].change.after.policy.Statement[_]
    stmt.Effect == "Allow"
    stmt.Action[_] == "s3:GetObject"
    stmt.Resource == "*"
    msg := "TM-031: wildcard S3 read on a scoped function role is prohibited"
}

The result is that a cloud threat identified on a whiteboard becomes a guardrail enforced on every infrastructure change — the same durability guarantee as Part 3, applied to the cloud, and drawing its mitigation from the Cloud Security Program's catalogue.

Threat-modelling managed services you don't control

A distinctive cloud challenge is modelling the services inside the provider's boundary — the managed database, the queue, the function runtime — which you configure but do not operate. The discipline is to model at your trust boundary: you are not responsible for the provider's patching of the managed database (that is the shared-responsibility line), but you are responsible for how you configure it, who can reach it, what identity it runs as, and whether its data is encrypted with a key you control. So the threat model for a managed service focuses on the configuration surface you own — public accessibility, network reachability, identity and access, encryption and key ownership, and logging — and treats the provider's internals as a trust boundary you rely on and verify through their compliance attestations rather than model directly. This keeps the exercise bounded: you model your half of the shared-responsibility line, thoroughly, and stop.

Definition of done — Cloud threat modelling & controls exit checklist

You are ready for Part 5 when every one of these is true, for the cloud architectures you run:

• Method adapted: teams run the four-question ritual on cloud architectures, drawing service-and-identity diagrams where the identity edges are explicit and trust boundaries (especially the identity boundary) are marked.
• Cloud threat prompts: the enumeration explicitly covers the cloud-native categories STRIDE under-prompts — over-broad IAM, confused deputy, public exposure, secrets sprawl, and blast radius.
• Native-control mapping: each high-priority cloud threat maps to a specific named AWS / GCP / Azure native control drawn from the Cloud Security Program's catalogue, with the mapping recorded in the threat register.
• Enforced as policy: high-priority cloud mitigations are enforced preventatively as policy-as-code, named for their threat, so they cannot regress — not merely detected after the fact.
• Shared-responsibility scoping: managed services are modelled at your half of the shared-responsibility line — configuration, reachability, identity, encryption, logging — with the provider's internals treated as a verified trust boundary.
• Repeatable: the practice is repeatable per new cloud service or architecture change, triggered by the same design-change events as Part 2.

Tick every box and your cloud architecture is threat-modelled with the same rigour as your application code, each real cloud risk closed by a native guardrail that cannot regress. Skip the native-control mapping and you will have a list of cloud worries with no home; skip the enforcement and you will have controls that are true today and drifted by next quarter.

What's next

Part 5 — Govern, measure & sustain is the finale, and it answers the question every stakeholder eventually asks: is this working, and is it worth it? With culture (Part 1), a threat-modelling ritual (Part 2), pipeline enforcement (Part 3) and cloud coverage (Part 4) all in place, Part 5 builds the measurement and governance that proves the program's value, keeps it funded, and sustains it frictionlessly as the organization scales past the point where any central team can be in every design review. It covers the metrics that matter to Product and Business — threat-model coverage, risk burndown, mean time to remediate, security debt — how to demonstrate ROI, and how to keep the practice alive under its own momentum. It ships next month.

If you would like experienced hands to run cloud threat modelling across your AWS, GCP and Azure estate and wire each finding to the native guardrail that closes it, that is exactly what Axelia's cloud-security consultants do — and ISMShed maps each cloud threat and its mitigation to the ISO 27001, ENS, NIS2, DORA, SOC 2 and GDPR controls it satisfies, turning the exercise into continuous compliance evidence. Threat-model your cloud now, and Part 5 shows how to prove and sustain the whole program.