Threat Modelling: Think Like an Attacker

By the end of this lesson you can:

• Use the four threat-modelling questions to analyse any system.
• Apply STRIDE to categorise threats.
• Identify trust boundaries and attack surface in a design.
• Rank threats by risk and pair each with a mitigation.

Picture a simple login page that checks a username and password against a database. An attacker doesn't see "a login form" — they see a list of opportunities:

• Can I guess passwords (no rate limit)?
• Can I inject SQL into the username field?
• Can I read the password database if I get in?
• Is the traffic encrypted, or can I sniff it?
• Can I reset someone else's password?

STRIDE — the six threat categories

S  Spoofing               pretending to be someone you're not   → maps to: Authentication
T  Tampering              altering data or code                  → Integrity
R  Repudiation            denying you did something (no proof)   → Non-repudiation / logging
I  Information disclosure  leaking data you shouldn't see         → Confidentiality
D  Denial of service       making the system unavailable          → Availability
E  Elevation of privilege  gaining rights you shouldn't have      → Authorization

For each component of your system, ask the six STRIDE questions. "Could someone spoof this? tamper with it? deny doing it? leak its data? deny service to it? elevate privileges through it?" You'll be surprised what surfaces.

Trust boundaries

A trust boundary is any line where data crosses from a less-trusted zone to a more-trusted one — and where you must not trust the input.

[ Browser ] ──── trust boundary ────► [ Your server ]
   (anyone can send anything)            (must validate everything)

[ Your app ] ──── trust boundary ────► [ Database ]
[ Internet ] ──── trust boundary ────► [ Internal network ]

The classic rule: validate at the boundary. SQL injection, XSS, and command injection all happen because untrusted input crossed a boundary without being checked. Mark every boundary in a design — that's where most threats live.

Attack surface

The attack surface is the sum of all the places an attacker can interact with your system: every input field, API endpoint, open port, file upload, query parameter, and dependency. A core defensive principle is to minimise it — fewer entry points, fewer things to get wrong.

• Close ports you don't use.
• Remove endpoints and features you don't need.
• Drop dependencies you don't use (each is attack surface — Lesson 35).

Ranking by risk

# a simple risk score: how likely × how bad (1-5 each)
def risk(likelihood: int, impact: int) -> int:
    return likelihood * impact      # 1 (trivial) … 25 (critical)

threats = [
    ("SQL injection on login",        5, 5),   # easy + total compromise
    ("Weak password policy",          4, 4),
    ("Verbose error pages leak stack", 3, 2),
    ("DoS via huge upload",           2, 3),
]
for name, l, i in sorted(threats, key=lambda t: risk(t[1], t[2]), reverse=True):
    print(f"{risk(l, i):2}  {name}")

25  SQL injection on login
16  Weak password policy
 6  Verbose error pages leak stack
 6  DoS via huge upload

You can't fix everything at once, so rank: likelihood × impact. Fix the 25s before the 6s. This turns a vague list of fears into a prioritised work plan.

Let's model the login system from the warm-up, end to end, producing a ranked threat table with mitigations — the actual deliverable of a threat-modelling session.

SYSTEM (Q1: what are we building?)
  Browser → [TLS] → Flask /login → SQL query → users table
                    ▲ trust boundary here (untrusted input enters)

THREATS via STRIDE (Q2: what can go wrong?) + risk (L×I):

threat_model = [
    # (STRIDE, threat, likelihood, impact, mitigation)
    ("S", "credential stuffing / brute force", 5, 4,
         "rate limit + lockout + MFA"),
    ("T", "SQL injection in username field", 5, 5,
         "parameterised queries (L8-31)"),
    ("I", "password DB stolen → plaintext leak", 3, 5,
         "bcrypt-hash passwords (L8-13)"),
    ("I", "traffic sniffed on open wifi", 3, 4,
         "enforce HTTPS/TLS (L8-09)"),
    ("R", "user denies a malicious action", 2, 3,
         "audit logging (L8-45)"),
    ("E", "low-priv user reaches admin route", 3, 5,
         "RBAC access control (L8-40)"),
    ("D", "login flooded, service down", 2, 3,
         "rate limit + CAPTCHA"),
]

def risk(l, i): return l * i
print(f"{'risk':>4}  {'cat':3}  threat → mitigation")
for cat, threat, l, i, fix in sorted(
        threat_model, key=lambda t: risk(t[2], t[3]), reverse=True):
    print(f"{risk(l, i):>4}  [{cat}]  {threat}\n        → {fix}")

risk  cat  threat → mitigation
  25  [T]  SQL injection in username field
        → parameterised queries (L8-31)
  20  [S]  credential stuffing / brute force
        → rate limit + lockout + MFA
  15  [I]  password DB stolen → plaintext leak
        → bcrypt-hash passwords (L8-13)
  15  [E]  low-priv user reaches admin route
        → RBAC access control (L8-40)
  12  [I]  traffic sniffed on open wifi
        → enforce HTTPS/TLS (L8-09)
   6  [R]  user denies a malicious action → audit logging (L8-45)
   6  [D]  login flooded, service down → rate limit + CAPTCHA

Read the model

Notice three things. First, STRIDE made us consider threats we'd have skipped (repudiation, elevation) — the framework catches what intuition misses. Second, every threat has a concrete mitigation, most of which are later lessons in this very level — threat modelling is literally the map of Level 8. Third, the ranking tells us SQL injection and brute force come first. A threat model isn't paperwork; it's a prioritised to-do list for making something safe.

Threat modelling is structured paranoia, driven by four questions — what are we building, what can go wrong, what will we do, did we do well? Use STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) to surface threats systematically; map your trust boundaries (validate everything that crosses them) and minimise your attack surface. Rank threats by likelihood × impact and pair each with a mitigation. The output is a prioritised plan — and for this course, it's essentially the map of every lesson ahead.