Threat Models

The only question that matters

Security questions are almost always too vague to answer. "Is HTTPS secure?" "Is this password good?" "Is using Wi-Fi on a plane safe?" The honest reply is the same every time: against whom? A password that resists your nosy cousin will not resist a state-funded attacker. A protocol that resists a casual eavesdropper may collapse against someone who controls a router along the path.

A threat model is just the written form of that answer. It names what you are protecting, who you are protecting it from, and what would actually go wrong if they win.

Shostack's four questions

Adam Shostack popularized a tiny checklist that captures most of what a real threat model does. You can do it on a whiteboard in twenty minutes:

1. What are we building? Draw the system: components, data flows, who calls what.
2. What can go wrong? Walk through the diagram, naming attacks at each spot.
3. What are we going to do about it? Pick a defense for each one, or accept the risk explicitly.
4. Did we do a good job? Have someone else stress-test the model. Update it as the system changes.

Trust boundaries

The single most useful idea in threat modeling is the trust boundary: a line in your diagram where data crosses from somewhere you control into somewhere you do not, or where the level of trust changes.

Every trust boundary is a candidate for an attack and deserves a defense. Examples:

• The browser-to-server boundary (the user can lie about anything they send).
• The server-to-database boundary (a compromised app should not be able to read every table).
• The you-to-cloud-provider boundary (encrypt-at-rest matters because the storage layer is not yours).
• The signed-in-to-admin boundary (a regular account being taken over should not become an admin takeover).

Adversary classes

Different attackers have different goals, budgets, and patience. Naming the class up front keeps your defenses honest.

• Opportunistic, scanners, script kiddies, broad criminal operations. They go where it is cheapest. Basic hygiene defeats most of them.
• Targeted criminal, ransomware crews, credential stuffers, fraud rings. They will spend real time on a juicy target.
• Insider, someone with legitimate access who abuses it. Hardest to detect, easiest to underestimate.
• State-funded, long timelines, unique tooling, willing to burn unknown vulnerabilities. Almost no one beats them with off-the-shelf controls alone.

Most projects only need to worry about the first two seriously and the last two contingently. Pretending you are defending against a nation-state when you have not done the basics is a common and expensive mistake.

A small worked example: a login form

Pretend we are reviewing a sign-in form. Walk the four questions:

1. What is it? A form that sends an email and password over HTTPS to a server, which compares against a stored password hash and returns a session cookie.
2. What can go wrong? Credentials phished. Password reused from another breach. Brute-force attempts. Session cookie stolen on a shared machine. Reset link guessable.
3. What do we do? Strong password hashing, rate limiting, breach-list checks, MFA, short session lifetimes, HttpOnly + Secure cookies, single-use reset tokens.
4. Are we sure? Pen-test it. Read your own logs for suspicious patterns. Re-run the model when the form changes.

Nothing in that list is dramatic. Most real attacks succeed because one or two of those small controls were missing, not because someone wrote a clever exploit.