Thinking Like an Attacker: Threat Modeling

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: You cannot defend everything, so you must know what is actually worth attacking — and that means deliberately thinking like an attacker. Threat modeling is that thinking made into a repeatable process: for any system, you ask what’s valuable, who’d want it, how they’d try, and what you’ll do about it. Done before a line of code is shipped, it is the cheapest security win there is.

Part 1: The Problem

Defenders have a structural disadvantage: they must protect every way in, while an attacker needs only one to work. If you defend at random — hardening whatever you happen to think of — you’ll pour effort into unlikely paths and leave the obvious one open.

The fix is to stop guessing and start modeling. Before building defenses, systematically ask: what here is worth stealing or breaking, who would want to, and how would they go about it? That deliberate attacker’s-eye walk-through is threat modeling, and it’s the foundation of the “attacker mindset” you’ll use forever.

Part 2: The Concept — What a Threat Model Is

A threat model is a structured answer to four questions about a system:

   1. What are we building?      → understand the system
   2. What can go wrong?         → find the threats
   3. What will we do about it?  → decide on defenses
   4. Did we do a good job?      → review and iterate

(That four-question framing comes from security engineer Adam Shostack and is widely used.)

It is not a tool you buy or a scan you run. It’s a thinking exercise, usually done with a diagram and a discussion, ideally before a system is built — when fixing a flaw is just an edit, not an emergency.

Part 3: The Building Blocks

To answer “what can go wrong,” you need four concepts.

Assets — what’s worth protecting. The things of value: user data, passwords, payment information, the service’s availability, intellectual property, reputation. If you don’t know your assets, you can’t know what you’re defending.

Threat actors — who might attack. Different attackers have different goals, skills, and resources:

You model against realistic actors for your system — a personal blog and a bank face very different ones.

Attack surface — the ways in. Every input, port, page, form, API, and account, as in section 0.4. The attacker probes all of it; your model should enumerate it.

Trust boundaries — where control changes hands. A trust boundary is any line where data crosses from a less-trusted zone into a more-trusted one — the browser into your server, your app into the database, the public internet into your network. Trust boundaries are where most vulnerabilities live, because they’re where assumptions get violated. The classic rule “never trust user input” is really “data crossing a trust boundary must be checked.”

   ┌────────────┐   trust boundary   ┌────────────┐
   │  Browser   │ ─ ─ ─ ─ ║ ─ ─ ─ ─► │  Server    │
   │ (attacker- │         ║           │ (you       │
   │  controlled)│        ║           │  control)  │
   └────────────┘   validate here!    └────────────┘

Part 4: STRIDE — A Checklist for “What Can Go Wrong”

Staring at a system and asking “what could go wrong?” is hard with a blank page. STRIDE (from Microsoft) gives you six prompts so you don’t miss whole categories of threat:

Walk each component of your system through all six letters: Could someone spoof here? Tamper here? … It turns a vague worry into a concrete, checkable list. STRIDE pairs naturally with the CIA triad from 1.1 — each threat type maps to a property being attacked.

Part 5: How to Actually Do It — A Worked Example

Let’s threat-model a tiny system: a web app where users log in and view their profile.

Step 1 — Diagram what we’re building.

   ┌─────────┐         ┌──────────────┐         ┌──────────┐
   │ Browser │ ──────► │  Web server  │ ──────► │ Database │
   │ (user)  │  HTTPS  │  (app logic) │   SQL   │ (users)  │
   └─────────┘         └──────────────┘         └──────────┘
        ║ trust              ║ trust
        ║ boundary           ║ boundary
   Two boundaries: internet→server, and server→database.

Step 2 — Identify assets. User credentials; personal profile data; the integrity of “who is logged in”; the app’s availability.

Step 3 — Apply STRIDE at the boundaries. A sample of what surfaces:

• Spoofing — could an attacker log in as another user? (weak passwords, stolen sessions)
• Tampering — could a user alter the request to view someone else’s profile? (broken access control)
• Information disclosure — do error messages leak system details? Is data encrypted in transit and at rest?
• Denial of service — can the login be flooded to take the app down?
• Elevation of privilege — can a normal user reach admin-only functions?

Step 4 — Decide defenses. Each threat gets a planned response: strong password rules and MFA; server-side access-control checks on every profile request; generic error messages; rate-limiting on login; strict role checks on admin routes.

Step 5 — Review. Did we cover every component and boundary? Revisit when the system changes.

Notice: nearly every threat this surfaced is a real category you’ll study deeply in Phase 2. Threat modeling is the map; the rest of the curriculum is the territory.

Part 6: The Attacker Mindset as a Daily Habit

Threat modeling is a formal process, but its real value is the habit it builds. Professionals can’t switch it off — and you shouldn’t want to. Faced with any system, an automatic background question runs:

• “What’s valuable here?”
• “What is this trusting that it maybe shouldn’t?”
• “What happens if I send something unexpected here — too long, wrong type, malformed, malicious?”
• “What’s the worst thing someone could do with this feature?”

This is not paranoia and not cynicism. It is constructive suspicion — the same instinct an engineer uses asking “what if this input is zero?” pointed at security. Every page from here on is, in a sense, training this reflex. Threat modeling is simply its disciplined, written-down form.

📓 Key Terms

🧪 Hands-On Lab

Task 1 — Threat-model an app you know well. Pick something simple you use or have built (a to-do app, a blog, a small API). Work the four questions from Part 2:

1. Draw what it is — boxes for components, arrows for data flow.
2. Mark every trust boundary on the diagram.
3. Apply STRIDE to each component — write at least one concrete threat per applicable letter.
4. For each threat, write a one-line defense.

Task 2 — Profile the threat actors. For that same app, list which threat actors from Part 3’s table are realistic for it. A hobby project and a payments app have very different lists — capturing why is the point.

Task 3 — Hunt trust boundaries. For any system you use daily, list every trust boundary you can find — every point where data crosses from something less trusted to something more trusted. This sharpens the single most useful diagram-reading skill in security.

Task 4 — “Send something unexpected.” For one input field in any app, brainstorm ten unexpected things to put in it: empty, enormous, wrong type, special characters, code-like text, another user’s ID. You won’t submit them anywhere unauthorized — this is the imagination drill behind every Phase 2 technique.

⚠️ Common Mistakes

• Threat modeling only after building. Its power is being early — when a fix is an edit, not an incident. Model before and during, not just after.
• Skipping the diagram. You cannot reason about what you can’t see. The diagram, with trust boundaries marked, is half the work.
• Modeling against unrealistic actors. A personal blog doesn’t need a nation-state threat model. Match the model to plausible attackers.
• Treating it as one-and-done. Systems change; new features add new attack surface. A threat model is a living document.
• Confusing constructive suspicion with cynicism. The attacker mindset is a professional tool you apply on purpose — not a way of moving through the world distrustfully.

✅ Recap & What’s Next

• Threat modeling answers four questions — what are we building, what can go wrong, what will we do, did we do well — ideally before building.
• Its building blocks are assets, threat actors, attack surface, and trust boundaries — and most vulnerabilities cluster at the boundaries.
• STRIDE is a six-category checklist that turns “what could go wrong?” into a concrete list, and the lasting payoff is the attacker mindset as a daily habit.

Next (1.3): One defense appears in nearly every threat model — cryptography. We’ll demystify it: what encryption and hashing really do, how they differ, and why crypto is almost always misused rather than broken.