Threat Modeling

Threat modeling is finding design flaws before you build them, rather than finding bugs after you ship. Security bugs in code can be patched in an afternoon. Security flaws in architecture can take quarters to unwind. A 90-minute whiteboard session with the team that owns the system will catch more design-level issues than a 40-page security document that nobody reads.

The Four Questions

Every threat modeling exercise boils down to four questions, originally framed by Adam Shostack:

1. What are we building? Understand the system — its components, data flows, external dependencies, and users.
2. What can go wrong? Systematically identify threats. This is where frameworks like STRIDE help.
3. What are we going to do about it? For each threat, decide: mitigate, accept, transfer (insurance, SLA), or eliminate the feature.
4. Did we do a good job? Review the model. Did we miss anything? Are our mitigations actually implemented?

The power is in the structure. Without it, security reviews devolve into "what if an attacker does X" brainstorms that miss entire categories of threats while fixating on exotic attack scenarios.

Data Flow Diagrams and Trust Boundaries

Before you can find threats, you need to see the system. A data flow diagram (DFD) maps how data moves through your application: processes, data stores, external entities, and the connections between them.

The critical addition is trust boundaries — lines you draw wherever data crosses from one trust level to another. Between your browser and your API server. Between your API server and a third-party payment processor. Between your application and its database. Between two microservices owned by different teams.

Every place data crosses a trust boundary is where threats live. That's where authentication, authorization, input validation, and encryption matter most. If you can only focus your security effort on a handful of places, focus on the trust boundaries.

You don't need fancy tooling. A whiteboard, boxes for components, arrows for data flows, and dashed lines for trust boundaries. Keep it at the level where design decisions happen — not every function call, but every service, data store, and external system.

STRIDE

STRIDE is a mnemonic that ensures you consider six categories of threats systematically. Each maps to a security property and a corresponding mitigation:

Spoofing — Can an attacker pretend to be someone or something else? This attacks authentication. Mitigations: strong authentication, MFA, certificate pinning, API key validation.

Tampering — Can an attacker modify data in transit or at rest? This attacks integrity. Mitigations: input validation, checksums, digital signatures, TLS, immutable audit logs.

Repudiation — Can a user deny performing an action, and you can't prove otherwise? This attacks accountability. Mitigations: comprehensive logging, audit trails, digital signatures, timestamps.

Information Disclosure — Can an attacker access data they shouldn't see? This attacks confidentiality. Mitigations: encryption at rest and in transit, access control, data classification, minimal data exposure in APIs.

Denial of Service — Can an attacker make the system unavailable? This attacks availability. Mitigations: rate limiting, auto-scaling, input size limits, circuit breakers, CDN-level DDoS protection.

Elevation of Privilege — Can an attacker gain higher access than intended? This attacks authorization. Mitigations: least privilege, role-based access control, input validation to prevent injection, sandboxing.

The process: for each element in your DFD that crosses or sits on a trust boundary, walk through all six STRIDE categories. Not every category applies to every element, but the exercise ensures you don't skip entire threat classes.

Attack Trees

Attack trees provide a more structured way to explore a specific threat. The root node is the attacker's goal (e.g., "exfiltrate customer payment data"). Child nodes represent the ways to achieve that goal. Each child can have its own children, branching into increasingly specific attack paths.

Exfiltrate payment data
├── SQL injection on payment API
│   ├── Find unparameterized query
│   └── Bypass WAF rules
├── Compromise database credentials
│   ├── Extract from source code
│   ├── Steal from config management
│   └── Phish a database admin
└── Exploit insider access
    ├── Rogue employee with DB access
    └── Compromised developer laptop

Attack trees are useful for prioritization. You can annotate nodes with difficulty, cost, or likelihood and focus mitigation on the most probable paths.

Risk Ranking

Not all threats are equal. You need a way to prioritize. A common approach is rating each threat on likelihood (how probable is this attack?) and impact (how bad is it if it succeeds?).

High likelihood + high impact = fix this now. Low likelihood + low impact = document and accept. The tricky ones are high impact + low likelihood — rare but catastrophic events that need mitigation even if they seem unlikely.

Don't overthink the scoring. A simple high/medium/low matrix is more useful than a precise-seeming numerical score that gives false confidence. The goal is relative prioritization, not actuarial precision.

Alternative Frameworks

PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage risk-centric methodology that starts with business objectives and works down to technical threat analysis. It's more structured and heavyweight than STRIDE — better suited to formal security programs.

LINDDUN focuses specifically on privacy threats: Linking, Identifying, Non-repudiation (from the user's perspective — they want deniability), Detecting, Data disclosure, Unawareness, Non-compliance. If you're building systems that handle personal data under GDPR or similar regulations, LINDDUN complements STRIDE well.

When and Who

When: During the design phase, before code is written. And again whenever the architecture changes significantly — adding a new external integration, changing authentication mechanisms, introducing a new data store, or adding a new user role.

Who: The engineers who know the system. Not a separate security team producing a document in isolation. The people who designed the service, wrote the API, and chose the database know where the bodies are buried. A security engineer can facilitate and bring threat expertise, but the system knowledge has to come from the team.

Making It Practical

A common failure mode is treating threat modeling as a heavyweight, document-heavy process that nobody wants to do. The fix is to keep it lightweight and focused.

Book a 90-minute session. Put the architecture on a whiteboard. Draw the trust boundaries. Walk through STRIDE at each boundary. Write down the threats you find and the decisions you make (mitigate, accept, transfer, eliminate). Put the results in your design doc or ticketing system, not in a separate 40-page threat model document.

The output should be actionable: specific tickets for mitigations, documented risk acceptances with owners, and a record that the analysis happened. Review the model when the architecture changes. That's it.

Key Takeaways

• Threat modeling finds design flaws before implementation — far cheaper than finding them in production.
• Start with four questions: what are we building, what can go wrong, what do we do about it, and did we do a good job.
• Data flow diagrams with trust boundaries show you exactly where threats concentrate — every trust boundary crossing is an attack surface.
• STRIDE ensures you systematically consider spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
• The team that built the system should do the threat modeling — they know where the risks actually live.
• Keep it lightweight: a 90-minute whiteboard session that produces actionable tickets beats a formal document nobody reads.

Next up: Penetration Testing Basics — finding out what's actually exploitable through authorized simulated attacks.