Constructing a Cloud Service Threat Model

Hello. In the previous lesson, you turned a reliability target into an error budget: a concrete allowance for user-impacting failures. This lesson shifts perspective from accidental failure to adversarial failure. A threat model asks how someone might intentionally compromise the same service, what would be harmed, and what the team will do about it.

You will build a practical threat model for a small cloud message service. By the end, you should be able to identify its important assets, draw its trust boundaries and data flows, use STRIDE to generate credible threats, and turn those threats into tracked mitigations. This is a core DevSecOps skill because it connects architecture decisions, application controls, cloud configuration, and operational evidence.

---

Threat modeling is structured design review

A threat model is a documented, repeatable analysis of what you are building, what needs protection, what can go wrong, and how the system will respond. It is not a penetration test, a generic compliance checklist, or a list of every imaginable vulnerability.

For a small service, the process can stay focused:

1. Define the service scope, users, assumptions, and assets.
2. Sketch the architecture and data flows.
3. Mark trust boundaries where control, identity, or privilege changes.
4. Identify threats for the important flows and components.
5. Choose concrete mitigations, rank the remaining risk, and assign ownership.
6. Review the model whenever the architecture or service behavior changes materially.

A useful distinction:

• An asset is something worth protecting: customer data, identities, credentials, service availability, or audit logs.
• A threat is a plausible way an attacker could harm an asset.
• A vulnerability is a weakness that may enable a threat.
• A mitigation reduces the likelihood or impact of a threat.

For example, “SQL injection” is not yet a complete threat model entry. A more useful statement is: “An unauthenticated attacker sends crafted input to the public message API, causing unintended database queries that disclose or alter other customers’ messages.” The mitigation might include parameterized queries, input validation, a least-privileged database identity, and monitoring for suspicious requests.

Before constructing the example, watch this concise introduction to using data-flow diagrams and trust boundaries.

---

Step 1: establish scope and identify assets

Consider a small cloud service called MessageBox. Authenticated customers can create, read, and delete their own saved messages through a browser-based web application.

For this initial model, assume:

• Customers authenticate with a cloud identity provider.
• The browser calls a public HTTPS API.
• The API runs in a managed cloud workload environment.
• Message records are held in a managed relational database.
• The API writes security-relevant events to a centralized audit-log store.
• File attachments, payment processing, and internal administration are out of scope for now.

Stating exclusions matters. A threat model is only reliable within its declared scope. If attachments are added next month, that is a reason to revisit the model rather than silently assuming the old analysis still covers the service.

Identify assets, not merely components

The database is a component, but the customer message data inside it is an asset. The API is a component, but the ability to call it as a legitimate customer is an asset. This distinction makes the security objective clearer.

Asset	Why it matters	Primary security properties
Customer message content and metadata	Contains private user information	Confidentiality, integrity, durability
Customer identities and roles	Determines who may access which message	Authentication, authorization
Access tokens and service credentials	Can grant access if stolen or misused	Confidentiality, short lifetime, controlled use
Database records	Must not be altered or deleted improperly	Integrity, availability, recoverability
Audit logs	Support investigation and accountability	Integrity, availability, appropriate retention
Message submission and retrieval service	Represents the user-facing journey	Availability, correctness

Notice that availability belongs in the asset discussion. From an SRE perspective, an attacker exhausting API or database capacity can harm the same user journey measured by an SLI, even if no data is exposed.

---

Step 2: model data flows and trust boundaries

A data-flow diagram, or DFD, represents external entities, processes, data stores, and the information moving between them. It does not need to be a complete deployment diagram. Include only the detail needed to ask good security questions.

For MessageBox, a compact diagram can look like this:

The boxes labelled as trust zones represent more than network location. A trust boundary exists where the system crosses into a different level of trust, administrative control, identity, or privilege.

For this service, the most important boundaries are:

Boundary	Why it is a boundary	Questions to ask
Browser to Message API	An untrusted client sends input and bearer tokens to a service you operate	Is the caller authenticated? Is every request authorized? Is input safe and bounded?
Browser to identity provider	The application relies on an external identity system	Does the API validate tokens from the correct issuer and audience? How are sessions protected?
API to database	A compromised API should not gain unrestricted data-store control	Does the API use a narrowly scoped database identity? Is the database private?
API to audit logs	An attacker who compromises the API may try to erase evidence	Can the workload alter or delete historical logs? Are security events retained and monitored?

A boundary is not an accusation that one side is malicious. It is a reminder to validate what crosses it. Even a trusted internal service can be compromised, misconfigured, or granted more permission than intended.

---

Step 3: use STRIDE to ask “what can go wrong?”

Once the architecture is clear, use STRIDE as a structured set of prompts. It is not a claim that every category applies to every component. Rather, it prevents obvious areas from being overlooked.

STRIDE category	Security property at risk	Question for MessageBox
Spoofing	Authentication	Could someone impersonate a customer or service?
Tampering	Integrity	Could someone alter a message, request, or record without permission?
Repudiation	Accountability	Could someone deny an action because evidence is missing or unreliable?
Information disclosure	Confidentiality	Could private messages, tokens, or operational details be exposed?
Denial of service	Availability	Could requests exhaust API, database, or network capacity?
Elevation of privilege	Authorization	Could a customer or workload obtain permissions it should not have?

A worked STRIDE threat register

The following is a credible first-pass threat register for MessageBox. It is intentionally small: a useful model prioritizes realistic risks over exhaustive speculation.

ID	Threat statement	STRIDE	Impact	Priority	Mitigations to implement or verify
T1	An attacker reuses a stolen customer access token to impersonate that customer and read private messages.	Spoofing	Exposure of customer data	High	Use the identity provider for sign-in; validate token signature, issuer, audience, and expiry in the API; use short-lived tokens; protect browser sessions; log unusual sign-in and API activity.
T2	A customer modifies a message identifier in an API request and reads, edits, or deletes another customer’s message.	Tampering	Unauthorized alteration or disclosure	High	Enforce server-side ownership checks on every object-level action; use parameterized database queries; grant the API only required database permissions; test authorization rules.
T3	A customer deletes a message and later disputes the action, but the system lacks a reliable record of who performed it.	Repudiation	Weak incident investigation and accountability	Medium	Record actor identity, action, target identifier, time, outcome, request correlation ID, and source context; centralize logs; restrict deletion or modification of historical audit events.
T4	An API error response or a misconfigured database exposes message contents, tokens, or infrastructure details.	Information disclosure	Customer-data breach and possible further compromise	High	Keep the database private; encrypt traffic; return generic errors to clients; avoid secrets and message content in application logs; enforce per-record authorization; protect backups and exports.
T5	An attacker sends a high volume of expensive requests, exhausting API workers or database connections and preventing legitimate use.	Denial of service	Missed availability SLO and degraded user experience	Medium	Apply edge rate limits and request-size limits; bound expensive queries; configure timeouts and resource limits; monitor API error rate, latency, and database saturation.
T6	A compromised API workload uses an overly broad cloud role to read unrelated databases or modify logging controls.	Elevation of privilege	Broad cloud-account impact	High	Assign a dedicated workload identity with least privilege; separate production roles; restrict access to only this database and log-write actions; review permissions and alert on anomalous identity use.

Several entries contain more than one mitigation. That is normal. Strong defenses are usually layered:

• Authentication establishes who the caller claims to be.
• Authorization decides whether that identity may perform the requested action.
• Network controls reduce unnecessary reachability.
• Encryption protects data in transit and at rest, but does not replace authorization.
• Logging helps detect, investigate, and prove what occurred.
• Resource limits and rate controls protect availability.

For example, HTTPS protects data from passive interception in transit, but it does not stop a valid authenticated user from requesting another user’s message. That requires object-level authorization inside the API.

---

Step 4: turn threats into owned, testable mitigations

A mitigation is useful only if it becomes an engineering or operational requirement. “Secure the API” is not actionable. “Reject any message read request unless the authenticated subject owns the requested record; add an integration test for cross-account access” is actionable and verifiable.

The OWASP cheat sheet frames the response stage well: threats need a decision, not just a description.

For each threat, choose one of four responses:

Response	Meaning	Example for MessageBox
Mitigate	Reduce likelihood or impact	Add ownership checks, narrow IAM permissions, and rate limiting.
Eliminate	Remove the risky feature or component	Do not expose a public administrative API that is not needed.
Transfer	Shift some responsibility contractually or operationally	Use a managed identity provider rather than operating password storage directly.
Accept	Formally retain a known risk with rationale and approval	Accept limited availability risk for a low-value internal feature, with an explicit owner and review date.

“Transfer” never means responsibility disappears. A cloud provider may protect the underlying infrastructure of a managed database, for example, but the workload team still controls database access, application authorization, network exposure, and the cloud permissions granted to the workload. The exact division will become a major topic in the next module.

Make the threat model operational

A useful threat register has enough context for a developer, SRE, or security reviewer to act on it. In addition to the table above, track:

• Owner: the team or role responsible for the mitigation.
• Status: proposed, implemented, verified, deferred, or accepted.
• Evidence: a link or reference to the policy, infrastructure configuration, code change, test, dashboard, or alert that demonstrates the control exists.
• Residual risk: what remains possible after mitigation.
• Review trigger: architecture change, new data type, new public endpoint, security incident, or periodic review date.

For T5, denial of service, evidence might include configured rate limits, a load-test result, an API latency dashboard, and an alert for rapid error-budget consumption. This is where DevSecOps and SRE practices reinforce one another: a security control is stronger when its behavior is observable in production.

---

A compact template you can reuse

For a small cloud service, start with this lightweight structure:

1. Scope and assumptions
   What feature is being modeled? What is intentionally out of scope?

2. Assets and security objectives
   Which data, identities, capabilities, and operational records need protection?

3. Diagram and trust boundaries
   Show users, external systems, processes, data stores, and labelled sensitive flows.

4. Threat register
   State the attacker action, affected asset, likely impact, STRIDE category, and priority.

5. Mitigation plan
   Record the concrete control, its owner, implementation status, verification evidence, and residual risk.

6. Review record
   Capture who reviewed the model and the changes that require it to be updated.

The goal is not a perfect document. The goal is an architecture conversation that produces defensible, testable engineering decisions before an incident forces those decisions under pressure.

---

Key takeaways

A threat model starts with the actual service and user journey, not a generic threat list. For MessageBox, the important assets included customer messages, identities, service credentials, audit evidence, and service availability.

A data-flow diagram makes attack surfaces visible. Focus on the places where data crosses trust boundaries: from an untrusted browser to an API, from an API to a database, and from a workload to audit systems.

Use STRIDE to systematically generate threats:

• Spoofing threatens authentication.
• Tampering threatens integrity.
• Repudiation threatens accountability.
• Information disclosure threatens confidentiality.
• Denial of service threatens availability.
• Elevation of privilege threatens authorization.

Finally, record concrete mitigations with owners and evidence. A threat model becomes valuable when it drives changes to code, cloud permissions, network exposure, monitoring, tests, and operational runbooks.

This concludes the first module. Next, you will begin secure cloud foundations by applying the shared-responsibility model to AWS scenarios and identifying the corresponding responsibilities in Azure.