Module 4b · Threat Modeling — Case Study & Practice

Security Champions · Module 4b

Security Champions Program

Threat Modeling — Case Study

Applying the full process to a payment API. From asset identification to backlog tickets.

Part 2 of 2 · Case Study & Practice

01 / 20

Recap · Part 1

Part 1 Recap

Everything you need is above. Now let's apply it to a real system.

02 / 20 · Recap

Case Study

Let's walk through it

A payment API processes credit card transactions. We'll threat-model it from scratch — assets to backlog tickets.

This is the same 7-step process from Part 1. Now watch it work on a real system.

03 / 20

Step 1 · Assets

What's valuable?

Step 1 of 7

We identify three assets, each with a different value type:

Cash flow + Penalties

Transaction data

Card numbers, amounts, merchant IDs. Revenue depends on it. Leaking it triggers PCI DSS penalties.

Procurement value

User accounts

Auth tokens, session data. Years of user base building — losing it means losing that investment.

Cash flow

Processing capability

The ability to process payments at all. If it stops, revenue stops. Every minute of downtime has a price.

Three different value types. Each needs different protection — and different threat analysis.

04 / 20 · Assets

Step 2 · Adversaries

Who wants these assets?

Step 2 of 7

Intent ●●●●● · Capability ●●●○○

Fraud operators

Manipulate transactions, create fake refunds. Professional teams, financial motivation. Opportunity depends on your controls.

Intent ●●●○○ · Capability ●●○○○

Competitors

Want client lists, transaction volumes. Low opportunity unless there's a partnership or shared integration.

Intent ●○○○○ · Capability ●○○○○

Script kiddies

Looking for exposed endpoints. Low skill, public exploits only. High opportunity if your API is public without rate limits.

Fraud operators are the primary threat for this system. They have high intent and moderate capability — our job is to minimize their opportunity.

Pattern

Adversary profiling isn't about naming specific attackers — it's about understanding what motivations and capabilities your system attracts. Design controls for the capability level, not the name.

05 / 20 · Adversaries

Steps 3–4 · Decompose

Approach & decompose

Steps 3–4 of 7

We combine asset-centric (payment data is the crown jewel) with system-centric (STRIDE on each component).

Three trust boundaries (dashed lines). We'll run STRIDE on the first two — where the most threats cross.

Champion's takeaway

Start with asset-centric ("what's valuable?") then switch to system-centric ("how does it flow?"). Two perspectives, one threat model.

06 / 20 · DFD

Step 5 · STRIDE

STRIDE on boundary ①

User → API Gateway

Boundary: User → API Gateway (untrusted input)

Attacker reuses a stolen auth token to impersonate a legitimate user. Gateway accepts it without checking if the session was revoked.

User modifies the amount field in the POST body. Client-side validation only — no server-side check.

User claims "I never made that purchase." No transaction signing, no device fingerprint, no audit trail.

Error responses include stack traces with DB connection strings. Card numbers in URL query params get logged.

No rate limiting. An attacker sends 10,000 requests/second, blocking legitimate payments.

Same endpoint handles user payments and admin refunds. Regular user discovers the refund parameter.

Six questions, six concrete threats. Not abstract — specific things that can go wrong.

07 / 20 · STRIDE

Step 5 · STRIDE (cont.)

STRIDE on boundary ②

Gateway → Payment Service

Boundary: API Gateway → Payment Service (internal, crosses network)

Cat.	Threat	Sev.
S	Rogue service sends fake payment confirmations	High
T	Transaction amount modified in transit (no signing)	Crit.
R	No record of which gateway sent the request	Med.
I	Internal API returns full card numbers unmasked	High
D	No circuit breaker — timeout cascades	Med.
E	Any internal service can call payment API	High

Same 6 questions, different boundary, different threats. STRIDE is a checklist you run on every crossing point.

Pattern

Apply STRIDE at each trust boundary crossing — not at every component. Boundaries are where privilege changes, and that's where threats concentrate.

08 / 20 · STRIDE

Step 6 · DREAD

Score with DREAD

Step 6 of 7

Threat: Tampering — transaction amount modified in transit

Attribute	Score	Why
Damage	5	Direct financial loss per transaction
Reproducibility	4	Repeatable with any API request
Exploitability	3	Requires MITM or compromised gateway
Affected users	5	Every paying customer
Discoverability	3	Requires internal API knowledge

(5+4+3+5+3) ÷ 5 = 4.0 → HIGH PRIORITY

Contrast: "Repudiation — user denies payment" → D:2, R:2, E:1, A:2, D:2 = 1.8 → LOW. Bank chargebacks handle it. Not a technical priority right now.

4.0 vs 1.8 — that's a clear sprint priority. DREAD gives you a number you can defend.

09 / 20 · DREAD

Step 7 · Backlog

The backlog ticket

Step 7 of 7

HIGH · DREAD 4.0

Implement request signing for Payment Service API

Payment Service accepts unsigned requests from API Gateway. MITM can modify transaction amounts.

ACCEPTANCE CRITERIA

☐ HMAC request signing · ☐ Per-request nonce · ☐ Signature validation · ☐ Rejected requests alerted

securitypaymentstride-TSprint: current

This is what threat modeling produces. Not a report. A ticket that ships in the next sprint.

Champion workflow: run threat modeling when a new feature crosses a trust boundary, when architecture changes, or after an incident. Involve 2–3 people who know the system. File the tickets in your team's tracker. Share DREAD scores with your security team for validation.

Champion's takeaway

The output of threat modeling is a backlog ticket, not a report. If it doesn't become a story with acceptance criteria, it was a conversation — not a process.

10 / 20 · Backlog

Step 7 · Backlog (cont.)

Low vs. high priority

LOW · DREAD 1.8

Add transaction audit trail for repudiation protection

Users can dispute transactions with no cryptographic proof. Bank chargebacks handle this for now, but scale will make it expensive.

ACCEPTANCE CRITERIA

☐ Request signing with device ID · ☐ Audit log with timestamp + hash

securitycomplianceSprint: backlog (Q3)

Both tickets from the same STRIDE. DREAD put them in different sprints. Fix the 4.0 now, schedule the 1.8 for later. No gut feelings. Just scores.

Practical rule

DREAD below 2.0 doesn't mean "ignore" — it means "schedule, don't rush." Low priority is still priority.

11 / 20 · Backlog

Case Study · Summary

Case Study Output

12 / 20 · Summary

Knowledge check · Case study

Knowledge check

Which threat modeling output is most valuable to a product owner?

D. The DFD, STRIDE list, and DREAD scores are intermediate artifacts. The backlog tickets are what the product owner can schedule, assign, and ship.

13 / 20 · Quiz

Time to think · Full pipeline

Payment API — Complete Pipeline

One feature. Seven steps. The output: prioritized security stories your team can actually ship.

14 / 20 · Pipeline

Practice · Tools

Tools

The original. Draw DFDs visually, STRIDE auto-suggested per element. Free, well-documented, Windows-only. Best for Microsoft ecosystem teams.

Lightweight, runs in browser. Free, portable. Less polished than Microsoft TMT but works on any OS. Community-maintained.

Enterprise-grade. Jira, Jenkins, Azure DevOps integration. Auto-generates threats from architecture. Audit trails + compliance.

From academia. For AI/ML threats — prompt injection, model poisoning, embedding exfiltration. Emerging but worth watching.

A whiteboard + STRIDE checklist beats a tool nobody uses. Start simple.

15 / 20 · Tools

Practice · Implementation

Start small, prove value

Don't try to threat-model every feature at once. Start with a pilot: one project, one feature, one afternoon.

"We found three design flaws in the payment flow and it took one afternoon" is a stronger argument than "best practice says we should do threat modeling."

Frame it as risk reduction with ROI: "We spent 3 hours and found issues that would have cost 2 weeks to fix in production." Show the backlog tickets — that's language POs understand. Don't lead with "security compliance."

The goal: demonstrate value on one project, then scale. Not the other way around.

16 / 20 · Implementation

Practice · Assignment

Your assignment

Pick one feature from your product. Run the 7-step process:

1. Identify the assets at stake
2. Identify the adversaries (use ICO)
3. Choose your approach
4. Decompose into a DFD
5. Run STRIDE on each trust boundary
6. Score 3 threats with DREAD
7. Write backlog tickets with acceptance criteria

Pick a feature you know well — familiarity matters more than complexity. Keep the DFD to 5–7 components. Focus STRIDE on the 2–3 most exposed trust boundaries. Perfect is the enemy of done.

The deliverable: 3 backlog tickets with DREAD scores and acceptance criteria. Share them with your team.

17 / 20 · Assignment

Closing

What you covered

Threat modeling produces tickets, not reports. The output is a prioritized backlog.

STRIDE is a checklist. Run it on every trust boundary in your DFD.

DREAD makes priorities defensible. 4.0 vs 1.8 — no gut feelings needed.

Same adversary, different threats. Each boundary produces different risks.

Start with a pilot. One feature, one afternoon. Prove value first, scale second.

A threat model isn't a one-time deliverable. Revisit it when: (1) a new feature crosses a trust boundary, (2) architecture changes — a new service, database, or external integration, (3) after an incident — the post-mortem already has half the updated model. These are the same three triggers from Module 2.

18 / 20

Complete

Part 2 complete

Your results

—

Quiz correct

—

XP earned

—

Rank

—

Best streak

—

Reflections

—

Wager style

19 / 20

Module 5

Supply Chain Security

Your code is only as secure as the dependencies it imports. Next: how to manage the supply chain.

20 / 20