Performing Threat Modeling With Owasp Threat Dragon

Performing Threat Modeling with OWASP Threat Dragon

Overview

OWASP Threat Dragon is an open-source threat modeling tool that enables security teams and developers to create threat model diagrams, identify threats using established methodologies (STRIDE, LINDDUN, CIA, DIE, PLOT4ai), and generate comprehensive reports. Threat Dragon runs as both a web application and desktop application (Windows, macOS, Linux), supporting distributed teams working collaboratively on threat models. Version 2.x provides drag-and-drop diagram creation, an auto-generation rule engine for threats and mitigations, and PDF report output for documentation and GRC compliance.

When to Use

Trigger phrases:

• "performing threat modeling with owasp threat dragon"

• "Use OWASP Threat Dragon to create data flow diagrams, identify threats using STR"

• When conducting security assessments that involve performing threat modeling with owasp threat dragon

• When following incident response procedures for related security events

• When performing scheduled security testing or auditing activities

• When validating security controls through hands-on testing

Prerequisites

• OWASP Threat Dragon desktop application or web instance
• Understanding of data flow diagram (DFD) notation
• Familiarity with STRIDE or LINDDUN threat classification
• Application architecture documentation and network diagrams
• Stakeholder access for design review sessions

Threat Modeling Methodologies

This section covers threat modeling methodologies for performing threat modeling with owasp threat dragon.

• Ensure all prerequisites are met before proceeding
• Follow the documented workflow steps in sequence
• Record results and any anomalies encountered during this phase

STRIDE

LINDDUN (Privacy-Focused)

Workflow

1. Scope the task — define objectives, boundaries, and success criteria
2. Gather information — collect all necessary data and context before proceeding
3. Execute the core workflow — follow the domain-specific steps methodically
4. Validate results — verify outputs against expected outcomes or baselines
5. Document findings — record results, anomalies, and recommendations

Step 1 --- Install Threat Dragon

Desktop Application: Download the installer from the OWASP Threat Dragon releases page for Windows (.exe), macOS (.dmg), or Linux (.AppImage/.deb/.rpm).

Web Application (Docker):

docker run -p 3000:3000 \
  -e ENCRYPTION_JWT_SIGNING_KEY=$(openssl rand -hex 32) \
  -e ENCRYPTION_JWT_REFRESH_SIGNING_KEY=$(openssl rand -hex 32) \
  -e ENCRYPTION_KEYS='[{"isPrimary":true,"id":0,"value":"'$(openssl rand -hex 16)'"}]' \
  -e NODE_ENV=production \
  owasp/threat-dragon:latest

Step 2 --- Define the Scope

Before creating diagrams, document the scope:

• System name and description
• Assets being protected (user data, credentials, payment info)
• External dependencies (third-party APIs, cloud services)
• Compliance requirements (GDPR, HIPAA, PCI DSS)
• Trust boundaries (network segments, authentication zones)

Step 3 --- Create Data Flow Diagrams

In Threat Dragon, create a new threat model and add diagrams using the following DFD elements:

Processes: Applications, microservices, API endpoints that transform data. Represented as circles/rounded rectangles.

Data Stores: Databases, file systems, caches, message queues that persist data. Represented as parallel lines.

External Entities: Users, external systems, third-party services outside the trust boundary. Represented as rectangles.

Data Flows: Communication channels between elements showing data direction. Represented as arrows with labels describing the data.

Trust Boundaries: Dashed lines separating zones of different trust levels (internet/DMZ/internal network, user/admin).

Step 4 --- Identify Threats

For each DFD element, apply the STRIDE methodology:

Threat Dragon's rule engine automatically suggests threats based on element types. Review each suggestion and mark as:

• Mitigated: Existing controls address the threat
• Not Applicable: Threat does not apply to this context
• Open: Threat needs to be addressed (assign priority and owner)

Step 5 --- Define Mitigations

For each open threat, document:

• Mitigation strategy (prevent, detect, respond, transfer)
• Specific technical controls (encryption, authentication, rate limiting)
• Owner responsible for implementation
• Priority and timeline for remediation

Step 6 --- Generate Reports

Threat Dragon produces PDF reports containing:

• Executive summary of the threat model
• Data flow diagrams with annotations
• Threat inventory with severity ratings
• Mitigation status and recommendations
• Compliance mapping where applicable

Step 7 --- Integrate into SDLC

• Conduct threat modeling during the design phase of new features
• Update threat models when architecture changes occur
• Review threat models during security design reviews
• Store threat model files in version control alongside code
• Reference threat model findings in security acceptance criteria

Threat Model File Format

Threat Dragon uses JSON format for threat models, enabling version control and programmatic manipulation:

{
  "version": "2.2.0",
  "summary": {
    "title": "E-Commerce Application",
    "owner": "Security Team",
    "description": "Threat model for the checkout flow"
  },
  "detail": {
    "contributors": [
      {"name": "Security Architect"}
    ],
    "diagrams": [
      {
        "id": 0,
        "title": "Checkout Flow",
        "diagramType": "STRIDE",
        "cells": []
      }
    ]
  }
}

CycloneDX TMBOM Integration

Threat Dragon participates in the CycloneDX Threat Model Bill of Materials (TMBOM) effort, enabling export to a common format that can be consumed by other threat modeling tools and GRC platforms, preventing vendor lock-in.

Best Practices

1. Start simple: Begin with high-level DFDs (Level 0) before decomposing into detailed diagrams
2. Involve developers: Include development team members in threat modeling sessions for realistic threat assessment
3. Time-box sessions: Limit initial sessions to 90 minutes; iterate in follow-up sessions
4. Prioritize by risk: Use severity ratings (Critical, High, Medium, Low) to prioritize mitigations
5. Living documents: Treat threat models as living documents that evolve with the system
6. Automate where possible: Use the rule engine for initial threat generation, then refine manually

When NOT to Use

• You don't have explicit written authorization to test
• Task is about defense/detection, not offense (use detection skills)
• You need to implement security controls (use implementing-* skills)
• Task requires compliance auditing (use auditing-* skills)
• You're investigating an incident (use incident response skills)
• Target is out of scope for your engagement
• Task is about vulnerability scanning only (use scanning tools)

Red Flags

• Performing actions without explicit written authorization from the asset owner
• Testing against production systems without a defined scope and rules of engagement
• Testing without rate limiting, potentially causing service degradation
• Storing sensitive test data (credentials, tokens) in plain text logs
• Using automated scanners blindly without reviewing results for false positives

Verification

• All steps executed successfully against a test environment before production use
• Output documented with screenshots or logs demonstrating expected behavior
• Vulnerabilities reproduced with proof-of-concept and impact analysis
• False positives filtered out through manual verification
• Fix recommendations include code-level remediation guidance

References

• OWASP Threat Dragon
• Threat Dragon GitHub Repository
• OWASP Threat Modeling Cheat Sheet
• STRIDE Threat Model
• LINDDUN Privacy Threat Modeling

Process

1. Analyze the task requirements
2. Apply domain expertise
3. Verify output quality

Anti-Rationalization Table