unicornAll work
← All theoryFoundations

Threat modeling & attack surface

Four questions asked before building or attacking, plus attack surface and trust boundaries.

In a nutshell Threat modeling is sitting down before building or attacking a system and asking four questions: what are we protecting, who wants it, how could they get it, and what will we do about it. It turns "let's add security" into a concrete list of the things that actually matter here.

The four questions

  1. What are we working on? Draw the system: its parts, where data lives, where it crosses a trust boundary.
  2. What can go wrong? For each part, who could attack it and how.
  3. What are we going to do about it? For each realistic threat — mitigate, or accept it consciously.
  4. Did we do a good job? Review; the model is a living document, not a one-off.

Analogy — defending a castle. You don't buy random armour. You map the walls, the gate, the well, the tunnels; ask where an enemy would push; and put your soldiers there, not spread thin everywhere.

Trust boundaries — where attacks live

A trust boundary is a line where data or control passes from something less trusted to something more trusted — the internet → your web server, a normal user → an admin function, a club PC → your VPN server. Attacks concentrate exactly on these lines, because crossing one means gaining something.

Internet untrusted TRUST BOUNDARY every request Your server validate • authenticate authorize • log !
Attacks concentrate on the boundary where untrusted data crosses into trusted ground.

The rule that falls out of this picture: never trust what crosses the boundary — validate, authenticate, authorize and log at the line. It's the same lesson behind every injection fix in this encyclopedia.

Attack surface — the sum of the doors

The attack surface is every point where an attacker could interact with the system: open ports, login forms, file uploads, APIs, even employees (social engineering). The first move in both defence and offence is the same — enumerate the doors. You can't protect, or attack, a door you didn't know existed.

Smaller surface = fewer doors = less to defend. That's why hardening is mostly removing things:

close unused ports          →  fewer services to attack
delete demo / debug pages   →  no forgotten entry points
disable unneeded features   →  smaller code = fewer bugs
one exposed port (443) vs   →  a machine exposing SMB+RDP+FTP+MySQL

Naming threats with STRIDE

Walk each component through this checklist of threat kinds and they surface themselves:

Letter Threat Breaks (CIA+)
S Spoofing — pretending to be someone authenticity
T Tampering — changing data integrity
R Repudiation — "wasn't me", no proof accountability
I Information disclosure — a leak confidentiality
D Denial of service availability
E Elevation of privilege authorization
From the VANTAGE work This was the core move on VANTAGE: treat the club machine as an untrusted zone — users have admin, there's no antivirus — and design every check around that one boundary. Whitelist-only egress, no full tunnel, server-side verification. The threat model wrote the architecture.

Why it matters to you

It's the same skill from both chairs. Defending: you spend effort where the risk is, not everywhere. Attacking: you build a map of where to push instead of poking at random.

All theory