Threat Modeling
Threat modeling is a structured process for identifying, quantifying, and addressing security risks in a system at design time — before any code is written. It transforms security from a reactive audit into a proactive architectural discipline. Source: DevOps to DevSecOps in 9 Hours
Why Threat Model?
Most security vulnerabilities are not clever exploits; they are predictable consequences of design decisions. A database exposed to the internet, a service running with excessive privileges, or a trust boundary drawn in the wrong place — these are architectural flaws that no amount of late-stage scanning can fully remedy.
Threat modeling answers four questions:
- What are we building? — Diagram the system: data flows, components, trust boundaries
- What can go wrong? — Identify threats using a structured methodology
- What should we do? — Prioritize mitigations by risk
- Did we do a good job? — Validate and iterate as the system evolves
The STRIDE Framework
STRIDE is Microsoft’s mnemonic for six categories of threats. It is the most widely used classification in practical threat modeling:
| Category | Definition | Example Mitigation |
|---|---|---|
| Spoofing | Pretending to be someone/something else | Authentication, MFA, mutual TLS |
| Tampering | Modifying data or code | Integrity checks, digital signatures, immutable artifacts |
| Repudiation | Denying that an action occurred | Audit logging, non-repudiable signatures |
| Information Disclosure | Exposing data to unauthorized parties | Encryption at rest and in transit, least-privilege access |
| Denial of Service | Disrupting service availability | Rate limiting, redundancy, resource quotas |
| Elevation of Privilege | Gaining unauthorized capabilities | RBAC least privilege, sandboxing, container boundaries |
Each data flow and component in the system diagram is examined against all six STRIDE categories. A threat is documented with a severity rating (often DREAD: Damage, Reproducibility, Exploitability, Affected Users, Discoverability) and assigned a mitigation owner.
OWASP Threat Dragon
DevOps to DevSecOps in 9 Hours uses OWASP Threat Dragon, an open-source threat modeling tool, for hands-on practice. Threat Dragon provides:
- Diagramming: Drag-and-drop data flow diagrams (DFDs) with trust boundaries
- Threat generation: Suggests threats based on STRIDE and diagram elements
- Risk scoring: Assigns severity and tracks mitigation status
- Report export: Generates PDF or JSON reports for compliance and review
Threat Dragon Workflow
- Create a model for the target application (e.g., a three-tier web app)
- Draw the diagram: processes, data stores, data flows, external entities, trust boundaries
- Add threats to each element using STRIDE prompts
- Score and prioritize: rank threats by business impact and exploitability
- Export and review: share the model with engineering and security stakeholders
Data Flow Diagram (DFD) Elements
| Element | Symbol | Security Relevance |
|---|---|---|
| Process | Circle | Where computation happens; may run with elevated privileges |
| Data Store | Parallel lines | Where data rests at rest; encryption and access control matter |
| Data Flow | Arrow | Data in motion; interceptable if unencrypted |
| External Entity | Rectangle | Outside the system’s control; may be malicious |
| Trust Boundary | Dashed line | Crossing this line is a security event; authenticate and authorize |
Three-Tier Application Example
A classic three-tier application (frontend → backend → database) has these trust boundaries:
- User → Frontend: Internet boundary; requires HTTPS, input validation
- Frontend → Backend: Internal cluster boundary; may use mTLS or signed JWTs
- Backend → Database: Internal network boundary; requires credential rotation and least-privilege DB user
Threat modeling this architecture would flag:
- Spoofing: What if an attacker impersonates the backend to the database? → mutual auth
- Tampering: What if a man-in-the-middle modifies the request? → TLS + request signing
- Information Disclosure: What if the database is accidentally exposed? → NetworkPolicies + no public IPs
- Denial of Service: What if the frontend is flooded with requests? → rate limiting + HPA
- Elevation of Privilege: What if the backend container escapes? → non-root user + read-only root FS
Integrating Threat Modeling into DevSecOps
Threat modeling is the first stage of the DevSecOps pipeline. Its outputs directly inform subsequent controls:
- A “Spoofing” threat drives authentication requirements (SAML, OIDC, mTLS)
- An “Information Disclosure” threat drives encryption and NetworkPolicy design
- A “Denial of Service” threat drives resource limits and autoscaling policies
Without threat modeling, pipeline scanners operate blindly. With it, every security control has a documented rationale tied to a specific architectural risk.
See Also
- DevSecOps Fundamentals — Threat modeling as the design-time stage of the secure pipeline
- Shift Left Security — The economic case for finding flaws at design time
- SAST, DAST, and SCA — Testing stages that verify threat model assumptions
- Kubernetes Network Policies — Network-layer enforcement for identified information-disclosure threats
- Zero-Trust Access — Trust boundary design philosophy
- Abhishek Veeramalla — Instructor demonstrating OWASP Threat Dragon in the 9-hour DevSecOps course
Tags: threat-modeling stride owasp devsecops design security risk-analysis