Threat Modeling & Risk Assessment

Before you build the vault, sit down and imagine every way a thief might try to break in — then design against those, not just the obvious front door.

At a glance

• What it is: a structured process for enumerating how a system could be attacked (using techniques like STRIDE), then ranking those risks so limited security effort is spent where it reduces the most risk.
• Why it matters: without a structured pass, teams tend to defend against the attack they can imagine, not the one that’s most likely or damaging — threat modeling makes the exercise systematic instead of ad hoc.
• For developers: before building a new feature that touches sensitive data or trust boundaries, ask what could go wrong here, and who would benefit from misusing it? — the same question from Security by Design, applied at a system level.
• When to use it: before major design decisions (new feature, new integration, new trust boundary) and periodically for existing systems, not just once at launch.
• When not to use it: trivial, non-sensitive internal tools with no access to real data or credentials may not need a full exercise — a lightweight pass is still worthwhile.
• Prerequisites: none — this is typically the first step before deciding which controls (segmentation, encryption, etc.) to prioritize.

Mental model

flowchart LR
    A[Describe the system and its trust boundaries] --> B[Enumerate threats per boundary - STRIDE]
    B --> C[Rank by likelihood x impact]
    C --> D{High risk?}
    D -- Yes --> E[Prioritize mitigation now]
    D -- No --> F[Track and revisit later]

Step-by-step walkthrough

1. Diagram the system, including every trust boundary — where data crosses from one level of trust to another.
2. For each boundary, enumerate threats using a framework like STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege).
3. Estimate each threat’s likelihood and impact, and rank them — don’t try to fix everything with equal urgency.
4. Assign the highest-ranked risks a concrete mitigation and owner; track lower-ranked ones for a future pass.
5. Repeat the exercise when the system changes meaningfully — a new integration or feature can introduce new trust boundaries.

Worked example

After the phishing incident and the discovery of a flat network (see Zero Trust & Network Segmentation), the security team runs a structured threat-modeling session across checkout, payment, and warehouse services instead of patching whatever seems most obvious.

• Input: a system with several known weak points (no MFA, flat network, unscanned dependencies) but no ranked view of which to fix first.
• Process: the team diagrams trust boundaries between the storefront, payment gateway, and warehouse, applies STRIDE to each boundary, and scores the results by likelihood and impact.
• Output: network segmentation and MFA rank highest (likely and high-impact) and are prioritized immediately; dependency scanning in CI/CD ranks next (see DevSecOps & Secure SDLC) and is scheduled for the following sprint. The team diagrams trust boundaries and runs the STRIDE pass using the free Microsoft Threat Modeling Tool, which generates the ranked threat list directly from the data-flow diagram.

Common use cases

Use case	When to use	Notes
Designing a new feature that crosses a trust boundary	At design time, before implementation	Cheaper to change a design than to patch after release
A security incident reveals unknown gaps	Immediately after containment	Use the incident to drive a structured pass, not just a one-off fix
Prioritizing a backlog of known security issues	Quarterly or before major releases	Rank by likelihood x impact rather than fixing in reported order

Advanced details

• STRIDE: a mnemonic for threat categories — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege — used to systematically ask “could this happen here?” at each boundary.
• Likelihood x impact scoring: a simple risk score that helps compare unrelated threats (e.g. a rare-but-catastrophic threat vs. a common-but-minor one) on the same scale.
• Trust boundary: any point where data or a request crosses from one level of trust to another (e.g. public internet to internal network, one team’s service to another’s).

Quick reference

Term	Meaning
Threat model	A structured map of how a system could be attacked
STRIDE	Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege
Trust boundary	A point where data crosses from one trust level to another
Risk score	A ranking based on likelihood and impact, used to prioritize mitigation

Troubleshooting

Symptom	Likely cause	Fix
Security effort goes to the most recently reported issue, not the riskiest one	No ranking step in the process	Score by likelihood x impact before deciding what to fix first
The same category of vulnerability keeps recurring in new features	Threat modeling only happens once, at launch	Repeat the exercise whenever a system gains a new trust boundary
A “threat model” is just a vague conversation	No structured framework used	Use STRIDE (or an equivalent) to make the exercise systematic and repeatable

Check your understanding

• Why is ranking threats by likelihood and impact more useful than trying to fix every identified issue immediately?
• What is a trust boundary, and why does STRIDE get applied per-boundary rather than to the system as a whole?

Related pages

Part of Introduction to Security Architecture. See also Zero Trust & Network Segmentation, DevSecOps & Secure SDLC, Security by Design (Application-Level), and the Glossary.