Home > DevSecOps

Threat Modeling Basics

Threat modeling identifies how a system can be attacked, what assets need protection, where weaknesses exist, and what controls are required to reduce risk. It forces teams to understand the full threat landscape before writing code or deploying infrastructure. Threat modeling strengthens architecture, reduces vulnerabilities, and guides secure design patterns across the entire lifecycle.

Why Threat Modeling Is Essential

Threat modeling prevents insecure systems from being built. Instead of discovering vulnerabilities later, teams analyze how attackers might abuse components during planning. This saves development time, reduces fixes, and avoids production incidents.

Threat modeling identifies risks early, shapes design decisions, and prevents critical architectural flaws.

Core Concepts

Assets

Assets include anything valuable such as personal data, authentication tokens, APIs, infrastructure services, configuration files, and secrets.

Threat Actors

Threat actors include external attackers, insiders, malicious automation, compromised third-party services, and rogue scripts.

Attack Surface

Attack surface includes all system entry points such as login forms, APIs, webhooks, admin panels, mobile apps, exposed ports, and cloud consoles.

Trust Boundaries

Trust boundaries separate areas of different trust levels. Examples include client to server communication, server to database communication, or internal microservices communicating across networks.

Data Flows

Data flow diagrams visualize how data moves across components. They reveal exposure points and boundary crossings.

Vulnerabilities

Vulnerabilities include coding errors, configuration mistakes, logic flaws, dependency issues, insecure defaults, and cloud misconfigurations.

Controls

Controls include authentication, authorization, encryption, validation, rate limiting, monitoring, network segmentation, and secure coding practices.

Threat Modeling Methodologies

STRIDE

STRIDE identifies threats across: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.

DREAD

DREAD prioritizes threats using criteria such as damage, reproducibility, exploitability, affected users, and discoverability.

Attack Trees

Attack trees break down attacker objectives into smaller steps.

Data Flow Approach

Teams map flows, analyze boundaries, identify entry points, and evaluate risks.

Deep Practical Section

Below are extensive, hands-on practicals covering every part of threat modeling, with full depth and realistic workflows.

Practical 1: Build a Complete Data Flow Diagram

Create a diagram for a sample application:

• Web browser
• API gateway
• Authentication service
• Database
• Logging service
• CI/CD pipeline
• Cloud storage bucket

Steps:

  1. Draw each component as a node.

  2. Draw arrows for login requests, API calls, DB queries, and log flows.

  3. Mark each trust boundary.

  4. Mark external vs internal services.

  5. Identify where data leaves one trust level and enters another.

Analyze:

• Does sensitive data cross insecure boundaries?
• Are access controls applied at boundaries?
• Are logs exposing data?

Practical 2: Create a STRIDE Threat Table for Your Architecture

For every component in your diagram:

Evaluate all STRIDE categories.
Example for authentication service:

• Spoofing: Check if attackers can impersonate users
• Tampering: Check if JWT tokens can be modified
• Repudiation: Check if login events are logged
• Information Disclosure: Check if tokens leak over HTTP
• Denial of Service: Check if login can be brute forced
• Elevation of Privilege: Check if normal users can acquire admin access

Document findings for every component.

Practical 3: Identify and Document Attack Surfaces

For a realistic API-driven system, list attack surfaces:

• Public POST endpoints
• Admin PUT endpoints
• File upload routes
• Webhooks from third-party services
• API keys stored locally
• Secrets in environment variables
• Cloud console access
• Ports exposed by Kubernetes services

Manually document:

• Which endpoints accept user input
• Which endpoints modify state
• Which endpoints expose sensitive data
• Which endpoints run privileged actions

Practical 4: Trace a Single Attack Scenario End-to-End

Pick the goal: “Steal a user’s private data.”

Trace how an attacker might achieve it:

  1. Send malformed requests to bypass auth

  2. Exploit insecure direct object references

  3. Brute-force session tokens

  4. Abuse insecure API filtering

  5. Exploit weak rate limits

Document every step attacker could take.

Then propose countermeasures for each step.

Practical 5: Threat Model an Authentication System

Steps:

  1. Examine password storage method

bcrypt, argon2, scrypt?

  1. Examine how password reset tokens are generated

  2. Examine session expiry

  3. Examine cookie properties

  4. Examine MFA flow

  5. Analyze brute-force defenses

  6. Analyze whether email enumeration is possible

  7. Observe logout behavior

  8. Check if access tokens are invalidated after password changes

List all threats and fixes.

Practical 6: Threat Model a File Upload Feature in Depth

Evaluate:

• Unrestricted file types
• Malware uploads
• Executable scripts
• Path traversal attempts
• Permission issues in storage buckets
• Overwriting existing files
• Storing files in publicly accessible locations

Test with:

test.php
../../../etc/passwd
large_file_10GB.bin
malware.docx
image_with_hidden_payload.png

Document risks and mitigation strategies.

Practical 7: Threat Model a Microservices Architecture

Choose simple services:

• User service
• Payment service
• Logging service
• Notification service

Evaluate threats:

• JWT token reuse
• Service-to-service authentication gaps
• Internal API spoofing
• Missing rate limits
• Unencrypted internal traffic
• Log injection
• Unauthorized access to payment APIs

Identify fixes such as mTLS, tokens per microservice, RBAC policies, and network segmentation.

Practical 8: Analyze Third-Party and Dependency Risks

For any open-source library:

Run:

npm audit
pip audit
osv-scanner

Document:

• Known CVEs
• Supply chain risks
• Package maintainability
• Update frequency
• Popularity and trust level

Map how exploited dependencies affect system data flows.

Practical 9: Build an Attack Tree

Goal: “Gain admin access”

Branches:

• Steal admin token
• Bypass login
• Privilege escalation exploit
• Exploit API misconfiguration
• Use leaked credentials
• Tamper with cookies
• Abuse admin JWT signing key
• Modify request parameters
• Inject malicious code into admin panel

Break each branch into sub-steps.

Practical 10: DREAD Scoring for Prioritization

Score three threats:

• SQL injection
• Broken access control
• Session hijacking

Score each across DREAD categories (numerical scoring allowed in threat modeling).
Finalize prioritization list.

Practical 11: Threat Model a Cloud Deployment

Choose AWS or GCP.

Analyze:

• IAM misconfigurations
• Misconfigured S3 buckets
• Public EC2 ports
• Exposed cloud metadata endpoints
• Insecure security groups
• Unencrypted volumes
• Overly permissive roles
• Public load balancers

Test configurations using IaC scanning:

checkov -d infrastructure/

Document all findings and improvements.

Practical 12: Threat Model a CI/CD Pipeline (Full Depth)

Analyze threats:

• Compromised build agents
• Unsigned artifacts
• Secret leaks
• Manipulated pipeline scripts
• Dependency poisoning
• Malicious PR triggers
• Overprivileged runners
• Plaintext environment variables

Document mitigations:

• Sign commits
• Cosign for image signatures
• Ephemeral runners
• Policy-as-code
• Secure secret management
• Restrict pipeline modification rights

Practical 13: Conduct a Team Threat Modeling Session

Steps:

  1. Present system diagram

  2. Identify attack surfaces together

  3. Apply STRIDE for each component

  4. Score threats

  5. Create mitigation list

  6. Assign tasks to dev, ops, sec teams

  7. Reevaluate after fixes

Document outputs and store them in repository.

Practical 14: Build a Threat Model Repository Folder

Create folder structure:

/threat-models
  /diagrams
  /stride-tables
  /attack-trees
  /dread-scores
  /mitigation-plans
  /reviews

Populate after every modeling session.

Practical 15: Create a Living Threat Model Document

Document must include:

• System overview
• Data flow diagrams
• Trust boundaries
• Threats identified
• Vulnerability list
• Risk prioritization
• Controls selected
• Remaining risks
• Reassessment timeline

This becomes a long-term reference.

Intel Dump

• Threat modeling identifies threats before coding begins
• It analyzes assets, actors, attack surfaces, boundaries, data flows, and vulnerabilities
• STRIDE, DREAD, attack trees, and data flow analysis are core methodologies
• Threat modeling prevents insecure design and reduces long-term risk
• Attack scenarios, system flows, and boundaries guide mitigation decisions
• Extensive practicals include diagrams, STRIDE, data flow analysis, full attack trees, authentication modeling, file upload modeling, dependency risk analysis, microservices threats, cloud threats, CI/CD pipeline threats, team modeling, and living documentation

HOME LEARN COMMUNITY DASHBOARD