Why Threat Modeling Is Worth Your Time

Every other security tool finds problems in code that already exists. Threat modeling finds problems before the code exists β€” when they're cheapest to fix. Changing a data model or authentication flow at design time is a discussion. Changing it after deployment is a migration, a security patch, and potentially a compliance event.

Microsoft's research found that design-phase security issues are 30x cheaper to fix than post-deployment vulnerabilities. SAST and DAST catch implementation bugs. Threat modeling catches architectural decisions that no scanner can see.

What threat modeling is not: It's not a long academic exercise. A useful threat model for a new feature can be done in 60-90 minutes with a whiteboard and the development team. Perfection is the enemy β€” a good-enough threat model done regularly beats a perfect one never done.

The Four Questions

Microsoft's threat modeling framework starts with four questions:

  1. What are we building? β€” Create a data flow diagram of the system, including all components, data stores, trust boundaries, and external entities.
  2. What can go wrong? β€” Apply STRIDE categories to each element in the diagram.
  3. What are we going to do about it? β€” For each threat, decide: mitigate, accept, transfer, or eliminate.
  4. Did we do a good enough job? β€” Validate that your mitigations address the threats identified.

Data Flow Diagrams

A DFD shows how data moves through your system. Four elements:

  • External entities (rectangles): Actors outside your system β€” users, third-party services, IoT devices
  • Processes (circles/ovals): Components that transform data β€” your web server, microservices, functions
  • Data stores (parallel lines): Places data rests β€” databases, file systems, caches, message queues
  • Data flows (arrows): Movement of data between components, labeled with what data moves

Trust boundaries (dashed boxes) mark where data crosses a privilege level β€” from internet to DMZ, from DMZ to internal, from user to admin context. Trust boundaries are where most threats occur.

Start simple: A DFD doesn't need to be exhaustive. Start with a high-level diagram covering the 5-10 main components. Drill into a specific feature or flow for detail. Getting the team to draw a diagram at all is more valuable than perfecting it.

The STRIDE Categories

STRIDE is a mnemonic for six threat categories. For each element in your DFD, ask whether each STRIDE threat applies:

  • S β€” Spoofing: Can an attacker pretend to be another user or component? Applies to: external entities, processes. Mitigated by: authentication.
  • T β€” Tampering: Can data be modified without authorization? Applies to: data flows, data stores. Mitigated by: integrity controls, digital signatures, access control.
  • R β€” Repudiation: Can a user deny performing an action? Applies to: processes, external entities. Mitigated by: audit logging, non-repudiation mechanisms.
  • I β€” Information Disclosure: Can data be read by unauthorized parties? Applies to: all elements. Mitigated by: encryption, authorization, need-to-know data access.
  • D β€” Denial of Service: Can the system be made unavailable? Applies to: processes, data stores. Mitigated by: rate limiting, resource limits, redundancy.
  • E β€” Elevation of Privilege: Can an attacker gain more access than authorized? Applies to: processes. Mitigated by: authorization, least privilege, input validation.

Running a Threat Modeling Session

Practical approach for a 60-90 minute session:

  1. 10 min: Draw the DFD on a whiteboard. Include all participants β€” developers know the implementation, security knows the attacks.
  2. 20 min: Walk through each trust boundary and data flow. For each, ask the STRIDE questions out loud: "Can someone spoof this? Can this data be tampered with?"
  3. 20 min: For each identified threat, assign a severity and a mitigation. Capture in a table: Threat | Component | Severity | Mitigation | Owner.
  4. 10 min: Review and prioritise. Which findings need immediate design changes before development starts?

Don't try to solve everything in the session: The session finds threats. Solutions can be worked out separately. Stopping the session to design the perfect authentication mechanism kills momentum and reduces participation.

Tools

  • Microsoft Threat Modeling Tool: Free, generates STRIDE threats automatically from DFDs. Opinionated β€” good for teams new to threat modeling.
  • OWASP Threat Dragon: Open-source, web-based DFD tool with integrated threat management. Stores models as JSON in your repository.
  • draw.io / Lucidchart: For DFDs only β€” no threat automation. Good when you already have a threat management process.
  • IriusRisk / ThreatModeler: Commercial tools with rule-based threat generation and integration with Jira.

When to Threat Model

  • New features with significant scope: Authentication changes, payment processing, new API endpoints, data sharing with third parties
  • Architecture changes: Moving to microservices, adding a message queue, changing authentication providers
  • Before penetration tests: Threat modeling helps focus pen test scope on the highest-risk areas
  • Annually for existing systems: As systems evolve, threat models go stale β€” refresh them annually

Supplement Threat Modeling with Automated Scanning

Threat modeling finds design flaws. AquilaX SAST, DAST, and IaC scanning find implementation flaws β€” together they cover your full security posture.

Start Free Scan