Threat Modeling for Engineering Teams

Threat modeling is the practice of systematically identifying what can go wrong before it does. Done well, it catches architectural security flaws during design — when fixes cost $100 instead of $100,000 in production. Done poorly, it produces 50-page documents that nobody reads.

This guide covers practical threat modeling that fits into engineering workflows, not security theater.

---

STRIDE Framework

Threat	Definition	Example	Mitigation
Spoofing	Pretending to be someone else	Stolen JWT token	MFA, token binding, session management
Tampering	Modifying data or code	SQL injection, modified API request	Input validation, integrity checks, signing
Repudiation	Denying an action took place	”I didn’t delete that”	Audit logging, digital signatures
Information Disclosure	Exposing protected data	Database dump, error messages with stack traces	Encryption, access control, error handling
Denial of Service	Making system unavailable	Flood API with requests	Rate limiting, WAF, auto-scaling
Elevation of Privilege	Gaining unauthorized access	Admin API without auth check	RBAC, principle of least privilege

---

Threat Modeling Process

1. What are we building?
   └── Data flow diagram
       ├── External entities (users, APIs)
       ├── Processes (services, functions)
       ├── Data stores (databases, caches)
       └── Trust boundaries

2. What can go wrong?
   └── Apply STRIDE to each element
       ├── Each data flow: can it be tampered?
       ├── Each data store: can it be accessed?
       └── Each trust boundary: can it be bypassed?

3. What are we going to do?
   └── Mitigation for each threat
       ├── Accept (risk is low)
       ├── Mitigate (implement control)
       ├── Transfer (insurance, SLA)
       └── Avoid (change design)

4. Did we do a good job?
   └── Review and validate
       ├── All threats addressed
       ├── Mitigations implemented and tested
       └── New threats from changes

---

Data Flow Diagram

                    Trust Boundary: Internet
┌──────────────────────────────────────────────────────┐
│                                                      │
│  [User Browser]                                      │
│       │                                              │
│       │ HTTPS (TLS 1.3)                              │
│       ▼                                              │
│  ┌─── CDN/WAF ───┐   Trust Boundary: DMZ           │
│  │  Rate limiting │─────────────────────────────┐    │
│  │  DDoS protect  │                             │    │
│  └────────────────┘                             │    │
│       │                                         │    │
│       ▼                                         │    │
│  ┌─── API Gateway ──┐   Trust Boundary: App    │    │
│  │  Auth validation  │─────────────────────┐    │    │
│  │  Schema validate  │                     │    │    │
│  └───────────────────┘                     │    │    │
│       │                                    │    │    │
│       ▼                                    │    │    │
│  ┌─── App Service ──┐                     │    │    │
│  │  Business logic   │                    │    │    │
│  └───────────────────┘                    │    │    │
│       │                                   │    │    │
│       ▼              Trust Boundary: Data │    │    │
│  ┌─── Database ─────┐─────────────────┐  │    │    │
│  │  Encrypted at rest│                │  │    │    │
│  │  Row-level security│               │  │    │    │
│  └──────────────────┘                 │  │    │    │
└──────────────────────────────────────────────────────┘

---

When to Threat Model

Trigger	Action
New service or feature	Full threat model as part of design review
New external integration	Assess data flows across trust boundaries
Authentication/authorization change	Review all access paths
Data storage change	Assess encryption, access, retention
Major architecture change	Refresh entire threat model

---

Anti-Patterns

Anti-Pattern	Problem	Fix
50-page threat model document	Nobody reads it, instantly stale	Focused threat model per feature/service
Threat modeling once	Security landscape changes constantly	Refresh on significant changes
Security team does all modeling	Developers know the system best	Train developers, security coaches
Only modeling new features	Existing systems have unknown threats	Annual review of critical existing systems
No follow-through	Threats identified but never mitigated	Track mitigations as engineering work items

---

Checklist

• Threat model template established for the team
• Data flow diagram: all services, data stores, trust boundaries
• STRIDE applied to each component and data flow
• Risk scoring for each identified threat
• Mitigations: accept, mitigate, transfer, or avoid per threat
• Mitigations tracked as backlog items with deadlines
• Trigger policy: when to create/update threat models
• Training: developers trained in basic threat modeling

---

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For threat modeling consulting, visit garnetgrid.com. :::