Threat Modeling Exercises with Solutions

TLDR: Threat modeling is a skill you build by doing it. This part gives you a short plan for running a session with your team, then six exercises on the ticket shop from the earlier parts, each with a worked solution: STRIDE on an API, prioritizing four findings, an attack tree for account takeover, a new feature with privacy threats, an AI support assistant, and a review of someone else's threat model. Along the way you keep the model in the repository as code with OWASP pytm and run it.

Reading about STRIDE, risk ratings and attack trees is the easy part. The hard part is staying concrete in a meeting, finding the threats that are specific to your system, and turning them into work. The exercises build on the ticket shop from Part 1, so you can reuse its data flow diagram and threat register. Try each exercise before you open the solution; there is more than one good answer.

Prerequisites

• Parts 1, 2 and 3, or working knowledge of STRIDE, risk rating and attack trees.
• Paper or a diagram tool. For the pytm section: Python 3.11 or newer.

How to Run a Threat Modeling Session

The four questions from the Threat Modeling Manifesto make a good agenda for a 60 to 90 minute session:

• Who: three to six people. The developers who build the system, someone who runs it in production, a security engineer if you have one, and someone who can judge business impact.
• Before: one person drafts the DFD from the design document or the infrastructure code, so the session does not start from a blank page.
• After: commit the threat register next to the code, open tickets for each mitigation, and add tests that prove the mitigations work.
• When: for every new service, and for changes that move a trust boundary: a new public endpoint, a new third party, a new kind of personal data, a change to authentication, an AI feature. A question in the pull request template ("Does this change add a data flow or cross a trust boundary?") catches most of them.

To answer the last question, check a few things: the DFD matches what is deployed, every flow that crosses a trust boundary was walked, every threat has a response and an owner, mitigations have tests, and the findings from later penetration tests, bug bounty reports and incidents were in the model. If they were not, ask why, and change how you run the next session.

Exercise 1: STRIDE Analysis of a REST API

Scenario

The ticket shop's API has these endpoints. Some threats from Part 1 apply to them, and some endpoints are new to you:

POST /api/login                  Sign in with email and password
POST /api/orders                 Create an order and hold seats
GET  /api/orders/{id}            Order details and QR codes
GET  /api/events?q=...           Search events
POST /api/account/email          Change the account's email address
POST /api/account/avatar         Upload a profile picture
POST /webhooks/payments          Payment provider webhook
POST /admin/refunds              Refund an order (staff)
POST /admin/comp-tickets         Issue free tickets (staff)

Your Task

Find at least two threats for each STRIDE category. For each one, name the endpoint, write the threat as a sentence and propose a mitigation.

Sample Solution

Exercise 2: Prioritize Four Findings

Scenario

A penetration test of the ticket shop reports four findings:

• A: SQL injection in the admin event search. It needs a staff session.
• B: Stored cross-site scripting in event descriptions. Organizers write them in the partner portal, and every buyer sees them on the event page. Staff see them in the admin preview.
• C: No CSRF protection on POST /api/account/email, which accepts form posts and does not ask for the password. The session cookie is set with SameSite=None because the shop's ticket widget is embedded in organizers' websites.
• D: The order ID and the customer's email address are in the query string of the confirmation page, so they appear in the CDN's access logs.

Your Task

1. Rate the likelihood and impact of each finding as Low, Medium or High, with one sentence of reasoning each, and read the risk from the matrix in Part 2.
2. Score each one with DREAD as well and compare the two rankings.
3. Choose a response for each: mitigate, eliminate, transfer or accept.

Sample Solution

Exercise 3: Build an Attack Tree for Account Takeover

Scenario

Ticket resellers take over customer accounts and sell the tickets in them. Build an attack tree for the goal take over a customer account and resell its tickets. Use what you know about the ticket shop: email and password sign-in, password reset by email, session cookies, a support chat, and the findings from Exercise 2.

Your Task

Build a tree with at least four approaches and at least one AND node, mark each node OR or AND, and find the cheapest path. Which leaves are new threats that are not yet in the register?

Sample Solution

Goal: Take over a customer account and resell its tickets          AND
├── 1. Take over the account                                       OR
│   ├── 1.1 Get the password                                       OR
│   │   ├── 1.1.1 Credential stuffing with leaked passwords        S2
│   │   └── 1.1.2 Phishing page that copies the sign-in form
│   ├── 1.2 Abuse the password reset                               OR
│   │   ├── 1.2.1 Take over the customer's email account first
│   │   └── 1.2.2 Poisoned reset link                              AND
│   │       ├── Reset link is built from the request's Host header
│   │       └── Victim clicks the link to the attacker's host
│   ├── 1.3 Hijack the session                                     OR
│   │   ├── 1.3.1 Stored XSS reads the session cookie (finding B)
│   │   └── 1.3.2 CSRF changes the email, then reset (finding C)
│   └── 1.4 Social-engineer support                                AND
│       ├── Pretend to be the customer in the support chat
│       └── Support changes the email without verifying identity
└── 2. Get the tickets out                                         OR
    ├── 2.1 Download the QR codes and sell copies
    └── 2.2 Transfer the tickets to an account the attacker controls

Exercise 4: Threat Model a New Feature: Ticket Transfers

Scenario

The product team wants customers to send a ticket to a friend. The customer enters the friend's email address, the shop emails a link through an email provider, the friend signs in or creates an account with that address and accepts, and the shop issues a new QR code to the friend and voids the old one.

Your Task

Threat model the change, not the whole system:

1. Add the new elements and data flows to the DFD and mark any new trust boundary.
2. Apply STRIDE to the new flows.
3. Apply LINDDUN (Part 1): the friend's email address is personal data of someone who is not a customer yet.
4. Pick the two threats to fix before launch and write the tests that prove the fixes.

Sample Solution

transfer a ticket owned by another customer         -> 404
scan the old QR code after a completed transfer     -> rejected
accept with an account that has a different email   -> 403
open the same accept link twice                     -> 410 the second time
send an 11th transfer from one account in a day     -> 429

Keep the Threat Model in the Repository with pytm

A threat model in a wiki goes stale. Keeping it as code next to the application lets you review changes to it in pull requests and diff it over time. OWASP pytm is a Python library for this: you describe elements, boundaries and data flows in Python, and pytm draws the DFD (through Graphviz) and lists candidate threats from a rule library. Version 1.4.0, released in July 2026, ships 114 threat rules, most of them derived from MITRE's CAPEC attack patterns, plus rules for LLM components.

Install it in a virtual environment:

python3 -m venv ~/.venvs/pytm
. ~/.venvs/pytm/bin/activate
pip install pytm==1.4.0

Save the ticket shop from Part 1 as a pytm model in tm.py, in a new threat-model directory, and run every command in this section from that directory. Controls are set to True only where the team has checked that they exist; TLS inside the private network (DF5 to DF8) is not in place yet, so the model leaves it out:

#!/usr/bin/env python3
from pytm import TM, Actor, Boundary, Classification, Data, Dataflow, Datastore, ExternalEntity, Process

tm = TM("ticket-shop")
tm.description = "Customers buy event tickets; a third-party payment provider takes the payment."
tm.isOrdered = True

internet = Boundary("Internet")
app_tier = Boundary("Public app tier")
private = Boundary("Private network")
third_party = Boundary("Payment provider")

customer = Actor("Customer", inBoundary=internet)
admin = Actor("Staff admin", inBoundary=internet, isAdmin=True)
provider = ExternalEntity("Payment provider", inBoundary=third_party)

api = Process("API", inBoundary=app_tier, implementsAPI=True)
# Set a control to True only when it exists and has been checked.
api.controls.authenticatesSource = True
api.controls.hasAccessControl = True
api.controls.validatesInput = True
api.controls.sanitizesInput = True
api.controls.encodesOutput = True
api.controls.usesParameterizedInput = True
api.controls.implementsCSRFToken = True

worker = Process("Worker", inBoundary=private)
worker.controls.validatesInput = True
worker.controls.usesParameterizedInput = True

db = Datastore("Postgres", inBoundary=private, storesPII=True)
db.controls.isEncryptedAtRest = True
queue = Datastore("Job queue", inBoundary=private, isSQL=False)

order = Data("Order and session cookie", classification=Classification.RESTRICTED, isPII=True)
event = Data("payment.succeeded event", classification=Classification.RESTRICTED)

flows = [
    Dataflow(customer, api, "DF1 orders, tickets", protocol="HTTPS", dstPort=443, data=order),
    Dataflow(admin, api, "DF2 admin actions", protocol="HTTPS", dstPort=443),
    Dataflow(api, provider, "DF3 checkout, refunds", protocol="HTTPS", dstPort=443),
    Dataflow(provider, api, "DF4 payment webhook", protocol="HTTPS", dstPort=443, data=event),
    Dataflow(api, db, "DF5 users, orders", protocol="PostgreSQL", dstPort=5432),
    Dataflow(api, queue, "DF6 issue-tickets job", protocol="RESP", dstPort=6379),
    Dataflow(queue, worker, "DF7 job", protocol="RESP"),  # the worker connects and pulls
    Dataflow(worker, db, "DF8 tickets, status", protocol="PostgreSQL", dstPort=5432),
]
for flow in flows[:4]:
    flow.controls.isEncrypted = True  # TLS on the Internet and provider flows only

if __name__ == "__main__":
    tm.process()

python3 tm.py --dfd | dot -Tpng -o dfd.png draws the diagram if Graphviz is installed. For the threat list, pytm fills a report template. Save this one-line template as findings.md next to tm.py; it prints one finding per line:

{findings:repeat:{{item.threat_id}} | {{item.severity}} | {{item.target}} | {{item.description}}
}

96 findings for a small system, and most of them are generic. Triage them like scanner output: confirm the ones that apply, record why the others do not, and look for what is missing.

• Useful: the worker findings AA01 and AA02 are threat T2 from Part 1 (forged jobs), found because the model does not claim that the worker authenticates its source. The DF7 findings say the same about the flow.
• New: iFrame overlay on the API is clickjacking. An attacker's site loads the shop's admin or checkout page in an invisible frame and tricks a signed-in user into clicking. The STRIDE session missed it. The fix is Content-Security-Policy: frame-ancestors 'none' on the admin, account and checkout pages, and a list of allowed organizer sites only on the routes of the embeddable ticket widget.
• Noise: iFrame overlay, cross-site scripting and cross-site request forgery do not apply to a background worker with no web interface.
• Missing: pytm knows nothing about prices, seat holds, discount codes or refunds. T1, T3, T4 and D1, the threats most specific to this business, come only from people.

Record triage decisions in the model, so the next run and the next reviewer see them. Add this to tm.py before the if __name__ line:

from pytm import Assumption

worker.assumptions = [
    Assumption(
        "The worker has no web interface, so browser attacks do not apply",
        exclude=["INP20", "INP27", "INP28", "INP29", "INP30", "AC18", "AC20", "AC21"],
    ),
]

The eight excluded findings no longer appear, and the reason is in the code for the next reviewer. Run the model in CI and fail the build when a new finding appears that nobody has triaged; that turns "did we do a good job?" into a check.

Exercise 5: Threat Model an AI Support Assistant

Scenario

The ticket shop adds a chat assistant built on a third-party large language model (LLM). It answers questions from the FAQ and from event descriptions (which organizers write), it can look up the signed-in customer's orders, and it can request refunds of up to 50 euros without a human. The API sends the customer's question and order details to the LLM provider (DF11) and receives answers and tool calls (DF12).

Your Task

1. Add the assistant to the pytm model and run it.
2. Map the findings to the OWASP Top 10 for LLM Applications 2025 and add the threats the tool cannot know about.
3. Propose mitigations, and decide which of them must not depend on the model behaving well.

Sample Solution

#!/usr/bin/env python3
from pytm import LLM, Boundary, Classification, Data, Dataflow

from tm import api, tm

llm_vendor = Boundary("LLM provider")
assistant = LLM(
    "Support assistant",
    inBoundary=llm_vendor,
    isThirdParty=True,
    processesUntrustedInput=True,  # customer messages
    hasRAG=True,  # FAQ and event descriptions written by organizers
    processesPersonalData=True,  # order details in the context
    hasAgentCapabilities=True,  # tools: look up orders, request refunds
    hasAccessToSensitiveSystems=True,
    hasSystemPrompt=True,
)
chat = Data("Customer question and order context", classification=Classification.RESTRICTED, isPII=True)
for flow in (
    Dataflow(api, assistant, "DF11 question, context", protocol="HTTPS", dstPort=443, data=chat),
    Dataflow(assistant, api, "DF12 answer, tool calls", protocol="HTTPS", dstPort=443),
):
    flow.controls.isEncrypted = True

if __name__ == "__main__":
    tm.process()

Exercise 6: Review a Threat Model

Scenario

The ticket shop moves to Kubernetes, and a colleague hands you this threat model for review:

system: ticket-shop on Kubernetes
components:
  - name: Ingress controller
    threats:
      - type: Denial of service
        description: Rate limiting protects against DoS
        status: mitigated
  - name: API (Deployment)
    threats:
      - type: Tampering
        description: Session cookies are signed, so requests cannot be tampered with
        status: mitigated
  - name: Postgres (StatefulSet)
    threats:
      - type: Information disclosure
        description: The database volume is encrypted at rest
        status: mitigated

Your Task

1. Which components and STRIDE categories are missing?
2. Which "mitigated" statuses are wrong or overconfident?
3. Which Kubernetes-specific threats are not covered?

Sample Solution

components:
  - name: API (Deployment)
    threats:
      - id: T1
        type: Tampering
        description: Customer changes the price in the order request
        mitigation: Totals computed on the server from the database
        status: mitigated
        evidence: test_order_total_ignores_client_price
      - id: E1
        type: Elevation of privilege
        description: Customer calls an admin endpoint without a role check
        mitigation: Deny-by-default admin blueprint, route tests
        status: open
        owner: platform-team
  - name: Job queue (Redis)
    threats:
      - id: T2
        type: Tampering
        description: Any pod can write issue-tickets jobs for unpaid orders
        mitigation: Redis TLS, separate ACL users for the API and the worker, NetworkPolicy allowing only those two, worker re-checks the order
        status: open
        owner: platform-team
  - name: Cluster
    threats:
      - type: Elevation of privilege
        description: Default service account tokens mounted in every pod
        mitigation: automountServiceAccountToken false, least-privilege RBAC
        status: open

Self-Assessment Checklist

After these exercises, check that you can:

• Draw a data flow diagram with trust boundaries for a system you work on
• Apply all six STRIDE categories per element or per interaction
• Write threats as sentences with an actor, an action and an impact
• Rate threats with likelihood and impact, and explain why DREAD scores are inconsistent
• Build an attack tree with AND and OR nodes and find its cheapest path
• Apply LINDDUN to a feature that handles personal data
• Threat model an LLM feature with the OWASP Top 10 for LLM Applications
• Spot gaps and overconfident claims in someone else's threat model
• Turn threats into owned work with tests that prove the mitigations

Next Steps

1. Model one real system: pick a service you run, draw its DFD and run a 60 minute session with the people who build it.
2. Model changes, not only systems: add the trust boundary question to your pull request template.
3. Keep the model with the code: a Markdown register or a pytm file in the repository, reviewed like any other change.
4. Test the mitigations: every "mitigated" entry should point at a test or a policy.
5. Close the loop: when a penetration test, bug bounty or incident finds something, check whether the model had it.

Further Reading

• Threat Modeling Manifesto: the shared definition, values and principles
• OWASP Threat Modeling Cheat Sheet
• Shostack + Associates threat modeling resources, including the Four Question Framework, and Adam Shostack's book Threat Modeling: Designing for Security (Wiley, 2014)
• LINDDUN privacy threat modeling
• OWASP Top 10 for LLM Applications 2025
• OWASP pytm, OWASP Threat Dragon and the Microsoft Threat Modeling Tool

Keep Learning

• Insecure design in the OWASP Top 10 guide
• Kubernetes security checklist, for Exercise 6
• Pod Security Standards flashcards
• The MCP Design Flaw That Exposes 150M Downloads to RCE, threat modeling for agent tools
• Interview question: security architecture and DevSecOps