threat-modeling

name	threat-modeling
description	Conduct threat modeling using STRIDE methodology. Identify threats, assess risks, and design security controls. Use when designing secure systems or assessing application security.
license	MIT
metadata	{"author":"devops-skills","version":"1.0"}

Threat Modeling

Identify and mitigate security threats during system design.

When to Use This Skill

Use this skill when:

• Designing a new system, service, or feature
• Making significant architectural changes to existing systems
• Onboarding a new third-party integration or dependency
• Preparing for security audits or compliance reviews
• Responding to a security incident to improve defenses
• Reviewing infrastructure changes that affect trust boundaries

Prerequisites

• System architecture documentation or design diagrams
• Access to development and operations teams for context
• Understanding of the system's data classification (PII, PHI, financial, etc.)
• OWASP Threat Dragon or Microsoft Threat Modeling Tool (optional but helpful)
• Whiteboard or diagramming tool for collaborative sessions

STRIDE Methodology

Threat	Description	Property Violated	Mitigation Examples
Spoofing	Pretending to be another user or system	Authentication	MFA, mTLS, API key validation, certificate pinning
Tampering	Modifying data in transit or at rest	Integrity	HMAC, digital signatures, checksums, immutable logs
Repudiation	Denying having performed an action	Non-repudiation	Audit logging, digital signatures, tamper-evident logs
Information Disclosure	Exposing data to unauthorized parties	Confidentiality	Encryption (TLS, AES), access controls, data masking
Denial of Service	Making service unavailable	Availability	Rate limiting, autoscaling, CDN, circuit breakers
Elevation of Privilege	Gaining unauthorized higher access	Authorization	RBAC, principle of least privilege, input validation

STRIDE Worksheet Template

# stride-worksheet.yaml - Fill out one per component/trust boundary crossing
component:
  name: "API Gateway"
  owner: "Platform Team"
  data_classification: "Confidential"
  trust_boundary: "External -> Internal"

threats:
  - id: T001
    category: Spoofing
    description: "Attacker forges JWT tokens to impersonate users"
    attack_vector: "Stolen signing key or weak algorithm (HS256 with guessable secret)"
    likelihood: Medium
    impact: Critical
    risk_score: 15  # likelihood(3) x impact(5)
    existing_controls:
      - "JWT validation on every request"
      - "RS256 algorithm with rotated keys"
    gaps:
      - "No token binding to device/IP"
    recommended_mitigations:
      - "Add token binding claims"
      - "Implement short-lived tokens (15 min) with refresh"
      - "Monitor for token reuse from different IPs"
    status: "Mitigated (partial)"
    owner: "Auth Team"

  - id: T002
     
     
     
     
     
     
    
       
       
     []
    
       
     
     

    
      
     
     
     
     
     
    
       
    
       
    
       
       
     
     

    
       
     
     
     
     
     
    
       
    
       
       
    
       
       
       
     
     

    
       
     
     
     
     
     
    
       
    
       
    
       
       
       
     
     

Data Flow Diagram

Text-Based DFD Notation

                    Trust Boundary: Internet
                    ==========================
                           |
                    [External User]
                           |
                      HTTPS/443
                           |
                    ==========================
                    Trust Boundary: DMZ
                    ==========================
                           |
                    (WAF / CDN)
                           |
                    [API Gateway]---->[Auth Service]--->[Identity DB]
                           |
                    ==========================
                    Trust Boundary: Internal
                    ==========================
                           |
                    [App Service]
                       /       \
                      /         \
               [Cache]       [Message Queue]
                                  |
                           [Worker Service]
                                  |
                    ==========================
                    Trust Boundary: Data
                    ==========================
                                  |
                           [Primary DB]--->[Replica DB]
                                  |
                           [Object Store]

Legend:
  [Box]     = Process
  (Parens)  = External entity / proxy
  ====      = Trust boundary
  --->      = Data flow

Threat Dragon Model (JSON)

{
  "summary": {
    "title": "E-Commerce Platform",
    "owner": "Security Team",
    "description": "Threat model for the e-commerce API platform"
  },
  "detail": {
    "diagrams": [
      {
        "title": "API Data Flow",
        "diagramType": "STRIDE",
        "cells": [
          {
            "type": "tm.Actor",
            "name": "Web Client",
            "threats": []
          },
          {
            "type": "tm.Process",
            "name" 
                
          
          
             
             
             
          
          
             
             
             
          
          
             
             
          
          
             
             
          
        
      
    
  

Threat Library

# threat-library.yaml - Reusable threat patterns
categories:
  authentication:
    - id: TL-AUTH-001
      name: "Credential stuffing"
      description: "Attacker uses leaked credential databases to attempt logins"
      applicable_to: ["login endpoints", "API authentication"]
      mitigations: ["MFA", "rate limiting", "credential breach monitoring", "CAPTCHA"]

    - id: TL-AUTH-002
      name: "Session hijacking"
      description: "Attacker steals session tokens via XSS or network sniffing"
      applicable_to: ["web applications", "APIs with session tokens"]
      mitigations: ["HttpOnly cookies", "TLS", "session binding", "short TTL"]

    - id: TL-AUTH-003
      name: "OAuth token theft"
      description: "Access tokens stolen from logs, URLs, or insecure storage"
      applicable_to: ["OAuth/OIDC integrations"]
      mitigations: ["PKCE", "short-lived tokens", "token binding", "secure storage"]

  injection:
      
       
       
       [, ]
       [, , , ]

      
       
       
       [, ]
       [, , ]

      
       
       
       [, , ]
       [, , ]

  
      
       
       
       []
       [, , ]

      
       
       
       []
       [, , , ]

  
      
       
       
       [, , ]
       [, , ]

      
       
       
       []
       [, , ]

Risk Scoring Matrix

Likelihood Rating

Score	Level	Description
1	Very Low	Requires nation-state resources; no known exploits
2	Low	Requires significant expertise and specific conditions
3	Medium	Moderately skilled attacker with available tools
4	High	Script-kiddie level; public exploits available
5	Very High	Trivial to exploit; automated scanning detects it

Impact Rating

Score	Level	Description
1	Negligible	No data exposure; cosmetic only
2	Minor	Limited data exposure; single user affected
3	Moderate	Significant data exposure; service degradation
4	Major	Large-scale data breach; extended outage
5	Critical	Complete system compromise; regulatory breach

Risk Matrix

Impact ->     1        2        3        4        5
Likelihood
    5      Medium    High     High   Critical Critical
    4       Low     Medium    High    High   Critical
    3       Low      Low     Medium   High    High
    2      Info      Low      Low    Medium   High
    1      Info     Info      Low     Low    Medium

Risk Treatment Decisions

risk_treatment:
  critical:  # Score >= 20
    action: "Immediate remediation required"
    sla: "24 hours"
    approval: "CISO"
  high:      # Score 12-19
    action: "Remediation in current sprint"
    sla: "1 week"
    approval: "Security Lead"
  medium:    # Score 6-11
    action: "Remediation in next sprint"
    sla: "1 month"
    approval: "Team Lead"
  low:       # Score 2-5
    action: "Track and address in backlog"
    sla: "1 quarter"
    approval: "Team Lead"
  info:      # Score 1
    action: "Accept risk and document"
    sla: "None"
    approval: "Team Lead"

OWASP Threat Dragon Setup

# Run Threat Dragon locally with Docker
docker run -d \
  --name threat-dragon \
  -p 3000:3000 \
  -e ENCRYPTION_KEYS='["threat-dragon-encryption-key-change-me"]' \
  -e NODE_ENV=production \
  owasp/threat-dragon:v2.2.0

# Access at http://localhost:3000

# Or install as desktop application
# Download from: https://github.com/OWASP/threat-dragon/releases

Integration with CI/CD

# .github/workflows/threat-model-review.yml
name: Threat Model Review
on:
  pull_request:
    paths:
      - 'docs/threat-model/**'
      - 'architecture/**'

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Validate threat model files
        run: |
          for model in docs/threat-model/*.yaml; do
            echo "Validating $model..."
            python -c "
          import yaml, sys
          with open('$model') as f:
              data = yaml.safe_load(f)
          required = ['component', 'threats']
          for r in required:
              if r not in data:
                  print(f'ERROR: Missing required field: {r}')
                  sys.exit(1)
          for t in data.get('threats', []):
              if t.get('status') == 'Open' and t.get('risk_score', 0) >= 12:
                  print(f'WARNING: High-risk open threat: {t[\"id\"]} - {t[\"description\"]}')
          print(f'OK: {len(data[\"threats\"])} threats documented')
          "
          done

      - name: Check for unaddressed critical threats
        run: |
          CRITICAL=$(grep -r "risk_score: \(1[5-9]\|2[0-5]\)" docs/threat-model/*.yaml | grep "status: \"Open\"" | wc -l)
          if [ "$CRITICAL" -gt 0 ]; then
            echo "WARNING: $CRITICAL critical/high-risk threats still open"
            echo "Review required before merging architectural changes"
          fi

Troubleshooting

Problem	Cause	Solution
Threat model sessions are unproductive	Participants don't understand the system	Share architecture docs before the session; include a system walkthrough
Too many threats identified	Scope too broad	Focus on one component or trust boundary per session
Threats are too vague	No structured methodology	Use STRIDE per element; fill in the worksheet template for each
Team doesn't follow up on findings	No ownership or tracking	Assign each threat to a team with SLA; track in issue tracker
Threat model becomes stale	No trigger to update	Require review on architecture changes (CI/CD gate on diagram changes)
Disagreements on risk scores	Subjective scoring	Use the scoring matrix consistently; calibrate with historical incidents

Best Practices

• Integrate threat modeling into the SDLC at the design phase
• Review threat models when architecture changes occur
• Include developers, ops, and security in sessions
• Use the threat library to ensure consistent coverage
• Document all risk acceptance decisions with rationale
• Track threats in the same system as other work items
• Conduct annual reviews of all active threat models
• Start with the most critical data flows and expand
• Keep sessions timeboxed (90 minutes maximum)
• Maintain a living threat library updated with new patterns

Related Skills

• sast-scanning - Code analysis
• penetration-testing - Validation of threat model findings
• incident-response - Response when threats materialize