Threat modelling, STRIDE, attack surface, and secure coding

Threat modelling: abstract first, then enumerate

You cannot reason about the security of a system you are holding in your head all at once. Threat modelling starts by abstracting the system — usually as a set of data flow diagrams showing processes, data stores, flows and the trust boundaries they cross — and then walks that abstraction element by element asking what an attacker with a given ability could do to it. The abstraction is what makes the enumeration finite. Without it you brainstorm attacks and stop when you run out of imagination; with it you stop when you have crossed off every element, which is a criterion someone else can check.

STRIDE, and the property each threat violates

STRIDE is the classification most teams use for that walk. Six threat categories, each the mirror image of a security property you were relying on: Spoofing violates authentication; Tampering violates integrity; Repudiation violates nonrepudiation; Information disclosure violates confidentiality; Denial of service violates availability; and Elevation of privilege violates authorization. The pairing is the useful half. Reciting the six threats gets you a list; naming the property each one breaks tells you which control family answers it, because the control that restores authentication is not the control that restores integrity. A typical implementation decomposes the system with data flow diagrams, maps each element to the categories that can apply to it, and then works a checklist of mitigations per category — manually, or with tooling that automates the mapping.

Attack surface: the points, not the bugs

The attack surface is the set of points at which an attacker can attempt to enter the system or extract data from it. Every network endpoint, every protocol left enabled, every file the system will parse, every physical interface, and all the code reachable before a caller has authenticated. The definition's load-bearing clause is that a point counts whether or not it is currently known to be vulnerable. That is what separates surface reduction from bug fixing, and it is where the exam marks are: patching a defect removes one known way in, while removing an entry point removes every way in through it — including the ones nobody has discovered yet. Reduction is therefore preventive rather than reactive: delete entry points, close unused channels and protocols, run components with the least privilege that lets them work, and shrink the amount of code an unauthenticated caller can reach. Threat modelling and surface reduction are complements — the model reasons about what an attacker can do with the surface you have, and reduction shrinks the surface the model has to cover.

Secure coding, measurement, and maturity

The rest of the chapter is the machinery that keeps the first two honest. Secure coding standards and static analysis catch the recurring implementation classes — unvalidated input, unsafe defaults, secrets in source. Security measurement gives the programme numbers to argue with: surface size over time, mean time to patch, the proportion of components covered by a threat model. Security maturity models stage the whole effort the way CMMI stages a process, so an organisation can tell whether it is doing security by heroics or by design.

Worked example — STRIDE over the BorrowBox locker channel

Take one element: the message that tells a locker to open. Spoofing — an attacker forges the reservation service's identity and sends an open command, so mutual TLS with a per-locker client certificate. Tampering — the locker identifier is rewritten in flight so the wrong door opens, so the command is signed over its whole payload. Repudiation — a member denies collecting the tool, so every open is written to an append-only log with the token, the door and the timestamp. Information disclosure — the channel leaks who borrowed what, so the payload is encrypted and identifiers are opaque. Denial of service — flooding the bank keeps legitimate members out, so commands are rate-limited per locker with a fail-secure default. Elevation of privilege — a member's app credential is accepted for the maintenance command set, so authorization is checked per command, not per session.

Now the surface, which is a different question. BorrowBox's is the mobile app, the public reservation API, the Bluetooth pairing channel used to commission a locker, the vendor's firmware update endpoint, and a physical keypad bolted to a wall on a public street. Disabling Bluetooth pairing once a locker is commissioned removes an entire class of attack without fixing a single defect — no patch, no test, nothing to regress. That single decision is worth more than any amount of hardening on a channel that did not need to exist.