Communicating a Threat Model

Definition

A threat model identifies what could go wrong, how likely it is, what it would cost, and what to do. Its value is entirely in whether the outputs become work.

The method that produces useful results

Walk the data flow diagram, boundary by boundary. For each trust boundary crossing, ask the standard categories: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.

This is far more productive than free-form brainstorming because it is systematic, bounded and repeatable — and because it produces threats attached to a specific place in the system rather than to the system in general.

Two hours with the right people covers most systems.

Who should be in the room

Engineers who know the system, someone with security expertise, and someone who understands the business impact. Threat modelling done by security alone produces findings nobody owns; done by engineers alone it misses attacker perspectives.

Making it actionable

• Prioritise by risk, not by cleverness. An unlikely, sophisticated attack with low impact ranks below a mundane misconfiguration with high impact — and the mundane one is what actually happens.
• One line per threat, with an owner and a decision: mitigate, accept, transfer, or avoid. Accepting a risk explicitly is a legitimate outcome and is far better than an unaddressed finding.
• Findings become backlog items with the same visibility as features. A threat model whose output is a document is a threat model that changes nothing.
• State the assumption behind each acceptance, so it can be revisited when the assumption changes.

Communicating it upward

Executives need risk in business terms: what could happen, how likely, what it would cost, what it costs to prevent. Not a list of vulnerability categories.

The most effective framing is comparative: "these three risks are outside our stated appetite; the remainder are within it" — which invites a decision rather than an acknowledgement.

Failure scenarios

• A document nobody reads, produced for a compliance checkbox.
• Findings with no owner, so nothing is fixed.
• Every threat treated as equally urgent, so nothing is prioritised.
• Done once at design time and never repeated as the system changes.
• Security in the room alone, producing findings the team does not accept.

Interview question

"How do you run a threat model that results in code changes rather than a report?"