Threat Modeling

What is Threat Modeling¶

Threat modeling is a systematic process for identifying security threats. It is not about intuition or the experience of a single person — it is a structured method that ensures you don’t overlook critical risks.

Why it matters¶

Most security incidents exploit vulnerabilities that were identifiable at design time. SQL injection, broken access control, insecure direct object references — these are not sophisticated zero-day attacks. They are design flaws that a threat model reveals in hours.

Our approach: STRIDE + DREAD¶

STRIDE — Threat categorization¶

For each system component we analyze six categories:

• Spoofing — Can an attacker impersonate a legitimate user or service? How do we verify identity?
• Tampering — Can an attacker modify data in transit or at rest? Is data integrity protected?
• Repudiation — Can a user deny an action? Do we have an audit trail?
• Information Disclosure — Can sensitive data leak? Error messages, debug info, API responses?
• Denial of Service — Can an attacker make a service unavailable? Rate limiting, resource exhaustion?
• Elevation of Privilege — Can a user obtain permissions they don’t have? Horizontal and vertical escalation?

DREAD — Risk prioritization¶

Each identified threat is scored:

• Damage — How much damage? (1–10)
• Reproducibility — How easily can the attack be repeated? (1–10)
• Exploitability — How easy is the vulnerability to exploit? (1–10)
• Affected users — How many users are affected? (1–10)
• Discoverability — How easy is the vulnerability to find? (1–10)

The resulting score prioritizes what to address first. Critical (40–50), High (30–39), Medium (20–29), Low (10–19).

Attack Surface Mapping¶

Data Flow Diagram¶

We start with a map of the system: where data originates, how it flows, where it is stored. Each trust boundary (the point where the security context changes) is where an attacker looks for a weakness.

Typical trust boundaries: - Internet ↔ Load balancer (WAF) - Load balancer ↔ API gateway - API gateway ↔ Backend services - Backend ↔ Database - Service ↔ Service (east-west traffic) - CI/CD pipeline ↔ Production environment

Supply Chain Analysis¶

The attack surface is not just your code. It includes: - Dependencies — npm packages, NuGet, PyPI. Known CVEs, typosquatting, dependency confusion. - Container images — Base images, multi-stage builds, vulnerability scanning. - CI/CD pipeline — Build server credentials, artifact integrity, deployment secrets. - Third-party integrations — API keys, webhook endpoints, OAuth flows.

Workshop format¶

Day 1: System Discovery¶

• Architectural overview
• Data flow diagrams
• Identification of trust boundaries
• Asset inventory (data, services, infrastructure)

Day 2: Threat Identification¶

• STRIDE analysis per component
• Attack tree construction for critical scenarios
• Supply chain threat assessment
• Business logic attack scenarios

Day 3: Risk Assessment & Mitigation¶

• DREAD scoring
• Risk prioritization
• Mitigation design
• Backlog integration

Output¶

1. Threat Model document — Data flow diagrams, identified threats, DREAD scores, proposed mitigations
2. Security backlog — User stories for mitigation implementation, prioritized by risk
3. Attack surface map — Visual overview of all entry points and trust boundaries
4. Continuous process — How to update the threat model as architectural changes occur

Automation¶

For larger systems we automate parts of threat modeling:

• IaC scanning — Terraform, Kubernetes manifests → automatic identification of exposed services, missing encryption, overly permissive RBAC
• API scanning — OpenAPI spec → automatic identification of missing authentication, injection points
• Dependency scanning — Continuous monitoring of new CVEs in dependencies

Automation does not replace the workshop — it complements it. It catches known patterns; the workshop uncovers business logic and architectural issues.

Technology and tools¶

Microsoft Threat Modeling Tool, OWASP Threat Dragon, draw.io for DFD, Jira/Azure DevOps for security backlog, Snyk/Dependabot for dependency scanning, Trivy for container scanning, custom STRIDE templates.