Module 1: Threat Modeling Andes Cargo
3. What threat modeling and the STRIDE framework are
Description
Lesson 2 left you with seven unanswered questions and no systematic way to find more. This lesson fixes that: threat modeling is the structured process of answering, for a real system, three questions — what are we building?, what can go wrong?, what are we going to do about it? — before something actually goes wrong. And STRIDE is the framework, created by Microsoft engineers in the late nineties and still the industry's most widely used, that structures the second question: six categories, each naming a distinct way a system can fail on security.
Connection to the module
This lesson is purely conceptual — on purpose, no commands yet. Each of the six categories you'll learn here, with a generic example, reappears in lesson 5 with a specific, real Andes Cargo finding. Think of this lesson as learning the alphabet before reading the whole word.
Threat modeling: the question before the question
Before STRIDE, before any framework, threat modeling is a discipline simple to name and hard to maintain under delivery pressure: instead of waiting for something to fail to ask why it failed, someone sits down — with a diagram of the real system, not an idealized one — and deliberately asks what could go wrong. The OWASP Foundation sums it up with three questions worth memorizing literally:
- What are we working on? — a diagram of the real system: what components exist, how they communicate, where they cross a trust boundary (for example, from the public internet into your VPC, or from an EC2 role into an S3 bucket).
- What can go wrong? — the question STRIDE structures, category by category.
- What are we going to do about it? — the answer becomes a concrete control, with an owner and, in this guide, with the exact module that builds it.
Lesson 4 of this module answers the first question for Andes Cargo (the real diagram, with commands, not imagined). Lesson 5 answers the second with STRIDE. Lessons 7 and 8 document the third.
Why this happens before writing security code, not after. The right analogy — and the one you'll use throughout this guide — is a building inspector: reviewing the blueprint before the first brick goes down costs an afternoon of work and a design change on paper; reviewing the finished building and discovering it's missing an emergency exit costs tearing down a wall. Threat modeling is, literally, reviewing the blueprint. Scanning infrastructure that's already deployed (what you'll do in Module 5 of this guide) is valuable, but it's the second kind of review, not a substitute for the first.
STRIDE: the six ways a lock can fail
STRIDE is a mnemonic acronym: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Each letter names a distinct threat category, and each answers a different question about a system. Before any technical example, it's worth a single everyday analogy that carries all six at once: think about your house, with a door, a lock, and the different ways that security can fail — not all of them are "someone kicked the door in." Most are more subtle than that, and that's exactly why STRIDE has six categories instead of one called "attack."
S — Spoofing
Official definition (Microsoft Learn): "Involves illegally accessing and then using another user's authentication information, such as username and password." — using, without permission, someone else's identity credentials to pass as them.
Everyday analogy. Someone shows up at your building's door with a key that isn't theirs — they copied it, stole it, or just found it — and the doorman, seeing only that the key turns in the lock, lets them in without verifying they're really the tenant. The lock doesn't distinguish between "the legitimate owner of this key" and "whoever happens to be holding this physical key."
Technical example. A long-lived AWS credential — a static AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY — works exactly like that physical key: whoever has it, no matter who they are, can authenticate as if they were the legitimate system that originally received it. If that credential leaks — in a log, in a Git commit, in a screenshot shared by mistake — whoever finds it can pass as the Andes Cargo pipeline to AWS, indistinguishable from the real pipeline from the API's point of view.
T — Tampering
Official definition: "Involves the malicious modification of data [...] such as that held in a database, and the alteration of data as it flows between two computers over an open network."
Everyday analogy. A package arrives at your door with the sender's seal broken and glued back — someone opened it in transit, maybe swapped what was inside, and closed it back up to make it look untouched. Without that seal, there's no way to tell a package that traveled untouched from one someone tampered with along the way.
Technical example. A deployment artifact — the .zip that packages a Lambda function's code — that nobody signs is exactly that unsealed package. Between the moment an engineer reviewed the code and the moment that .zip actually gets deployed, nothing stops the file from changing — a byte, a line, an entire dependency — without any step of the process noticing.
R — Repudiation
Official definition: "Associated with users who deny performing an action without other parties having any way to prove otherwise [...] a user performs an illegal operation in a system that lacks the ability to trace the prohibited operations."
Everyday analogy. Your building has neither a security camera nor a visitor log. If something disappears from an apartment, anyone who entered that day can deny having been there — and no one, neither the doorman nor the other tenants, has any way to prove otherwise. It's not that someone lies convincingly and gets away with it; it's that the system itself never captured the evidence that would allow disproving it.
Technical example. An infrastructure change applied with no audit trail at all — no CloudTrail, no record of which identity ran which call and when — leaves the team in the same position as the building with no cameras: if an IAM policy changes unexpectedly, there's no queryable record to answer "who did this, and when?" with evidence, only with memory and guesswork.
I — Information disclosure
Official definition: "Involves the exposure of information to individuals who are not supposed to have access to it [...] the ability of users to read a file that they were not granted access to."
Everyday analogy. A filing cabinet with private documents sits in a publicly accessible hallway, unlocked, because nobody thought it needed locking — not because someone forced it open, but because it never had a lock in the first place. Anyone walking through that hallway can open it and read what's inside.
Technical example. An S3 bucket with no public access block configured — neither at the account level nor at the bucket level — is that lockless filing cabinet: nothing in the current configuration makes it public today, but nothing stops a future change (a badly written policy, an ACL applied without thinking) from making it public with no layer catching it before it happens.
D — Denial of service
Official definition: "Deny service to valid users [...] you must protect against certain types of DoS threats simply to improve system availability and reliability."
Everyday analogy. Someone parks a car blocking your building's only entrance. Nobody broke in, nobody stole anything — but as long as that car stays there, no legitimate tenant can get in or out. The building's availability, not its contents, is what's compromised.
Technical example. This category is usually associated, first, with a network attack that floods a server with traffic — but Microsoft's official definition is broader: anything that denies service to a legitimate user counts. An infrastructure change that deletes the single table holding a system's business state — with nothing stopping it before it's applied — is, in this precise sense, a denial of service: nobody attacked the system from outside, but the outcome — the system stops being available to its real users — is exactly what this category names. You'll see this exact case in lesson 5.
E — Elevation of privilege
Official definition: "An unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system."
Everyday analogy. You're given a key card for your hotel room, and that same card, without anyone asking for it and without you even noticing, also opens every other room on the floor, the laundry room, and the manager's office. You didn't do anything to get that extra access — it was simply handed to you, in excess, with nobody checking whether you actually needed it.
Technical example. An IAM role granted, "just in case" or by copying and pasting an existing policy, more permissions than the code that uses it actually exercises — s3:* when the code only calls s3:GetObject, or access to the entire bucket when it only needs one prefix — is that extra hotel key card. Nobody "elevated" the privilege through an active attack; the excess privilege was already there by design, waiting for someone — or something, a process compromised while holding that role — to use it.
The data flow diagram: where each category lives
STRIDE is applied over a data flow diagram (DFD) — a simple representation of what components exist and where information crosses between them, with special attention to trust boundaries: the points where the level of trust changes (from "public internet" to "your VPC," from "an EC2 role" to "an S3 bucket"). A minimal sketch, applied to Andes Cargo's central flow — still without the real resource names, which arrive in lesson 4:
[ GitHub Actions runner ]
│
│ AWS credentials ──────────────── (1) TRUST BOUNDARY:
▼ who can authenticate
[ Terraform / awslocal ] as this pipeline?
│
│ calls to the AWS API
▼
[ S3 bucket ] ──(event)──▶ [ Lambda function ] ──(writes)──▶ [ DynamoDB table ]
▲ │
│ reads │ execution role
│ ▼
[ EC2 role / tracking app ] [ IAM Role ] ─────────────── (2) TRUST BOUNDARY:
can this role do
more than it needs?Every arrow in this diagram is a candidate for some STRIDE category: the credentials arrow (1) is where the Spoofing risk lives; the execution role (2) is where the Elevation of privilege risk lives; the bucket itself is where Information disclosure lives; and so on. Lesson 4 builds this same diagram with real names and evidence from real commands — not a sketch, an inventory.
A threat can fall into more than one category, and that's normal
A leaked long-lived credential isn't just a Spoofing risk (someone passes as the pipeline) — it also enables, downstream, Tampering (that identity could modify resources) and Elevation of privilege if the associated role has more permissions than necessary. STRIDE doesn't require that each threat have a single "correct" category — it requires that, for each component of the system, you ask all six categories, one by one, without skipping any. It's exactly the same kind of discipline a pilot uses with a preflight checklist: not because they expect every item to fail, but because the cost of missing one that did fail is too high to trust to memory.
Common mistakes
Treating STRIDE as a list of specific attacks instead of categories of question (definition mistake). What happens: someone tries to memorize "the Spoofing attacks" as a closed list (phishing, password theft, etc.) instead of understanding the underlying question the category asks. How to spot it: if, faced with a new system component, you don't know what to ask for each letter, even though you memorized examples from other systems. How to fix it: each letter is a reusable question, not a list of cases — Spoofing: "how does this component know that whoever is talking to it is who they claim to be?"; Tampering: "what stops someone from modifying this without it being noticed?"; and so on for all six. Apply the question to the real component, don't look for a match against a memorized example.
Confusing Information disclosure with "any data that exists in the system" (scope mistake). What happens: someone flags any sensitive data the system processes as an Information disclosure risk, regardless of whether there's actually a path by which someone unauthorized could read it. How to spot it: if your Information disclosure finding doesn't include any concrete mechanism by which the exposure could happen. How to fix it: the category requires a real path — a specific missing control (like a public access block that doesn't exist), not the mere existence of sensitive data somewhere in the system. "This system processes shipment data" is not, by itself, an Information disclosure finding; "this bucket has no public access block configured" is.
Thinking Denial of service always means a network attack (expectation mistake). What happens: someone dismisses category D for a system with no public-facing internet component, assuming DoS only applies to web servers under malicious traffic. How to spot it: if your D analysis for an internal system comes up blank, "not applicable." How to fix it: Microsoft's official definition is explicitly broader — anything that denies service to a legitimate user counts, including losing a critical resource to an uncontrolled infrastructure change. In lesson 5 you'll see an Andes Cargo example of D that has nothing to do with network traffic.
Exercises
Exercise 1 — Classify four everyday scenarios with the correct STRIDE letter. For each one, name the category (or categories) that applies and justify it in one sentence: (a) someone uses a copy of a coworker's key to enter the office after hours; (b) an employee signs a document but later denies having done so, and the company has no record to contradict them; (c) a web form lets any logged-in user edit any other user's profile, not just their own; (d) a streaming service goes down because a single user deliberately opened thousands of simultaneous connections.
See solution
(a) Spoofing — using another person's identity (the key) to gain access. (b) Repudiation — the absence of a verifiable record allows denying the action without consequence. (c) Elevation of privilege — a user gains, without explicit authorization, the ability to act on resources that aren't theirs (though it could also be argued as a broader authorization failure, the central category is E). (d) Denial of service — legitimate (or abusive) use of a system capability leaves other users without service, the category's classic case.
Exercise 2 — Explain why a plaintext secret in a Git repository can be classified under more than one STRIDE category. Using the .secrets file you already know from cicd-and-gitops-on-aws-guide, explain which STRIDE categories would apply if that file, by mistake, ended up committed to Git history, and why.
See solution
At least two categories apply directly. Information disclosure: the secret is exposed to anyone with read access to the repository — including, forever, Git history, even if the file is deleted afterward — with no control ever protecting it. Spoofing: once exposed, that credential lets anyone who reads it authenticate to AWS as if they were the legitimate system that uses it — the same impersonation risk you already saw in this lesson's technical example for category S. Depending on what permissions that credential carries, it could also enable Tampering or Elevation of privilege downstream. The exercise demonstrates, with a concrete case, why STRIDE doesn't require picking a single "correct" category.
Exercise 3 — Apply the Elevation of privilege question to a new scenario, without using the lesson's example. Without using this lesson's s3:* example, describe a cloud infrastructure scenario — any service, not necessarily Andes Cargo's — where a component has more privilege than its actual function requires, and explain how you'd detect it.
See solution
There's no single correct answer, but a typical example: an EC2 instance with an IAM role that includes iam:CreateUser or iam:AttachRolePolicy permission, when the application running on that instance only needs to read from an SQS queue. You'd detect it by comparing, line by line, the permission policy attached to the role against the API calls the application's code actually executes — exactly the same method you'll practice in lesson 4 of this module with AppServerRole and LambdaManifestProcessorRole. Any scenario where the granted permission verifiably exceeds the permission the code uses is a valid answer.
Summary and next step
In this lesson you learned this guide's core vocabulary: threat modeling as OWASP's three questions, and STRIDE as the framework that structures the second one. You saw the six categories — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege — each with its official Microsoft definition, a shared everyday analogy (your house, its lock, and the ways that security can fail), and a first technical example. And you saw the data flow diagram as the tool that locates where, within a real system, each category lives.
Before moving on you should be able to: name STRIDE's six categories from memory, with their core question, without needing the acronym written in front of you; explain why a single threat can fall into more than one category at once; and draw, from memory, a minimal data flow diagram with at least one trust boundary marked.
Lesson 4 leaves the generic examples behind: you'll build Andes Cargo's real attack surface inventory, with the exact commands a security professional would run first.
Resources
- Microsoft Learn — Threats: Microsoft Threat Modeling Tool — the official source for the six STRIDE definitions quoted literally in this lesson.
- OWASP Cheat Sheet Series — Threat Modeling Cheat Sheet — the three threat modeling questions ("what are we working on?", "what can go wrong?", "what are we going to do about it?") and the full guide to data flow diagrams and trust boundaries.
- AWS Well-Architected Framework — SEC01-BP07: Identify threats and prioritize mitigations using a threat model — AWS's official recommendation to model threats as a design practice, not an after-the-fact review.