Security Threat Model
Red-team a system to find how an attacker would actually break it.
A threat model with ranked attack paths and the mitigations that matter.
Threat models drift into checkbox theatre without an adversarial mind in the room, so the Security Engineer walks the attack paths while the Devil’s Advocate plays the motivated attacker who does not care about your compliance certificate. The Software Architect maps where the trust boundaries actually sit versus where the diagram claims, the Privacy Counsel prices data exposure in regulatory terms, and the Risk Officer forces the ranking — because a model that flags everything protects nothing.
Build a threat model for this system. Think like a motivated, intelligent attacker. THE SYSTEM: [describe the system, the data it holds, who uses it, the trust boundaries] ARCHITECTURE: [auth, data stores, third parties, network boundaries] WHAT YOU MOST WANT TO PROTECT: [the crown-jewel assets] Debate: 1. The assets — what is actually worth stealing, corrupting or taking down. 2. The adversaries — who would attack this and what they want. 3. Attack paths — auth bypass, injection, data exposure, supply chain, social engineering, insider, abuse of features. 4. The weakest link and the most plausible real-world breach. 5. Mitigations ranked by risk reduced versus friction added. 6. What we are over-protecting (security theatre) versus under-protecting. FINAL SYNTHESIS: - A ranked list of the top attack paths (likelihood × impact), each with the concrete mitigation. - The single change that most reduces real risk. - A note on what genuinely needs a professional security review or pen test.
An illustrative excerpt for a hypothetical brief of this type: A telehealth startup stores consultation notes and prescriptions, authenticates with magic links, and has just added a patient-facing API for a partner’s mobile app. Every real run is generated fresh from your specifics, debated across rounds, and audited before the verdict.
The new partner API moves the perimeter and nobody redrew it: it authenticates the partner app, not the patient behind it. If the partner’s mobile client is compromised or its token leaks, every record it can query is exposed. Per-patient scoping on API tokens is the finding to fix first — the crown jewels are consultation notes, and this is the shortest path to them.
As the attacker, I skip your API entirely: magic links mean patient security equals email security, and patients reuse webmail passwords. Credential-stuff a thousand email accounts, request magic links, harvest sessions. No exotic exploit, no CVE — just your own login flow used as designed. What in this architecture notices that happening?
The severity maths is different for this data class: prescriptions and consultation notes are special-category data, so a breach is not just an engineering incident but a notifiable regulatory event with per-record consequences. That multiplies the impact score of both paths just described, and it means retention is a control too — data you deleted on schedule cannot leak.
Ranked: partner-API scoping first — highest impact, cheapest fix, days of work. Anomaly detection on magic-link volume second: it converts the credential-stuffing path from invisible to monitored. Everything else on the list is real but behind those two, and the report should say so plainly rather than presenting twelve co-equal findings.
Prefer drop-and-go? Use the AI Security Review tool — team pre-seated, included with Plus.
Is this a replacement for a professional penetration test?
No, and the output says so explicitly where it matters — the deliverable flags which findings genuinely need a professional review or pen test. What it replaces is the blank page: you arrive at the security review knowing your ranked attack paths, trust boundaries and priorities instead of paying a consultancy to discover them from scratch.
What do I describe — I don’t want to paste credentials or code?
Architecture, not secrets: what data you hold, who uses the system, how authentication works, what third parties connect, and where the boundaries sit. The threat model reasons about structure. Never paste live credentials — structure is what the attack paths are made of.
How does the council decide what is worth fixing versus security theatre?
Every mitigation is scored as risk-reduced versus friction-added, and the model explicitly names what you are over-protecting. In most runs something on the existing to-do list turns out to be theatre while an unglamorous control — token scoping, rate limits, retention — tops the list.