Understanding Threat Modeling A Comprehensive Guide with Real-World Example
Understanding Threat Modeling: A Comprehensive Guide with Real-World Example
Threat modeling is a structured approach to identifying, communicating, and understanding threats and mitigations within a system. This guide will help you understand the fundamentals of threat modeling and how to implement it effectively in your projects, complete with a real-world example of an e-commerce application.
What is Threat Modeling?
Threat modeling is a fancy name for something we all do instinctively. Think about how you protect your house - you consider valuable items inside (family, heirlooms, electronics), potential entry points (doors, windows), and possible threats (burglars, natural disasters). Similarly, in software and systems security, threat modeling helps us:
- Find security issues early in the development process
- Improve understanding of security requirements
- Engineer and deliver more secure products
- Address issues that other security techniques might miss
The Four-Step Framework
Effective threat modeling can be broken down into four key questions:
- What are you building?
- What can go wrong?
- What should you do about those things that can go wrong?
- Did you do a decent job of analysis?
Let’s explore each step using both general principles and a real-world example of an e-commerce application.
Real-World Example: E-Commerce Application
Throughout this guide, we’ll use the example of “SecureShop” - a modern e-commerce platform that includes:
- User authentication and profile management
- Product catalog and search
- Shopping cart functionality
- Payment processing
- Order management
- Admin dashboard
- Customer support chat system
Step 1: Creating a System Model
Start by creating a diagram of your system. Data Flow Diagrams (DFDs) are particularly useful, showing:
- Processes (running code)
- Data stores (files, databases)
- Data flows (network connections, API calls)
- Trust boundaries (where different security contexts meet)
SecureShop System Model:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
+----------------+ +---------------+ +------------------+
| Customer Web | | CDN/Cache | | Load Balancer |
| Browser |---->| (Static) |---->| |
+----------------+ +---------------+ +------------------+
| |
v v
+----------------+ +---------------+ +------------------+
| Mobile App | | API Gateway | | Web Servers |
| |---->| |---->| (Containers) |
+----------------+ +---------------+ +------------------+
| |
v v
+----------------+ +---------------+ +------------------+
| Admin Panel | | Auth Server | | Product Service |
| |---->| (OAuth2) | | |
+----------------+ +---------------+ +------------------+
| |
v v
+----------------+ +---------------+ +------------------+
| Payment Gateway| | User Data DB | | Product Data DB |
| (3rd Party) | | (Encrypted) | | (Replicated) |
+----------------+ +---------------+ +------------------+
Architectural Diagrams
1. High-Level Architecture
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
+----------------------------------------------------------------------------------------+
| Client Layer |
| +----------------+ +----------------+ +----------------+ +----------------+ |
| | Web Browser | | Mobile App | | Admin Panel | | 3rd Party | |
| | (React/Vue) | | (iOS/Android) | | (React Admin) | | Integrations | |
| +----------------+ +----------------+ +----------------+ +----------------+ |
+----------------------------------------------------------------------------------------+
|
v
+----------------------------------------------------------------------------------------+
| Security Layer |
| +----------------+ +----------------+ +----------------+ +----------------+ |
| | WAF/CDN | | API Gateway | | Auth Service | | Rate Limiter | |
| | (Cloudflare) | | (Kong/AWS) | | (OAuth/JWT) | | (Redis) | |
| +----------------+ +----------------+ +----------------+ +----------------+ |
+----------------------------------------------------------------------------------------+
|
v
+----------------------------------------------------------------------------------------+
| Application Layer |
| +----------------+ +----------------+ +----------------+ +----------------+ |
| | Product API | | Order Service | | User Service | | Payment API | |
| | (Node.js) | | (Python) | | (Java) | | (Go) | |
| +----------------+ +----------------+ +----------------+ +----------------+ |
+----------------------------------------------------------------------------------------+
|
v
+----------------------------------------------------------------------------------------+
| Data Layer |
| +----------------+ +----------------+ +----------------+ +----------------+ |
| | Product DB | | Order DB | | User DB | | Cache Layer | |
| | (MongoDB) | | (PostgreSQL) | | (MySQL) | | (Redis) | |
| +----------------+ +----------------+ +----------------+ +----------------+ |
+----------------------------------------------------------------------------------------+
2. Security Zones and Trust Boundaries
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Internet (Untrusted)
│
▼
┌──────────────────────────────────────────────────┐
│ DMZ (Semi-Trusted) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ WAF │-->│ CDN │-->│ LB │ │
│ └─────────┘ └─────────┘ └─────────┘ │
└──────────────────────────│───────────────────────┘
│
▼
┌──────────────────────────────────────────────────┐
│ Application Zone (Trusted) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ API │-->│ Auth │-->│ Apps │ │
│ │Gateway │ │Service │ │ │ │
│ └─────────┘ └─────────┘ └─────────┘ │
└──────────────────────────│───────────────────────┘
│
▼
┌──────────────────────────────────────────────────┐
│ Data Zone (Most Trusted) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Primary │<->│ Replica │<->│ Backup │ │
│ │ DB │ │ DB │ │ DB │ │
│ └─────────┘ └─────────┘ └─────────┘ │
└──────────────────────────────────────────────────┘
3. Data Flow Model with Security Controls
1
2
3
4
5
6
7
User Input Processing Storage
┌──────────┐ Validation ┌──────────┐ Encryption ┌──────────┐
│ Web Form │─────╲ ╱─────>│ Backend │─────╲ ╱─────>│ Database │
└──────────┘ ╳ └──────────┘ ╳ └──────────┘
╱─╲ │ ╱─╲ │
Input Sanitization │ Data at Rest Backup
Validation Authentication Encryption
Threat Modeling Templates
1. STRIDE Threat Matrix Template
1
2
3
4
5
6
7
8
9
10
11
12
┌────────────────┬────────────────┬────────────────┬────────────────┐
│ Component │ Threat │ Mitigation │ Status │
├────────────────┼────────────────┼────────────────┼────────────────┤
│ Web Frontend │ XSS Attack │ Input Escaping │ Implemented │
│ │ CSRF │ CSRF Tokens │ In Progress │
├────────────────┼────────────────┼────────────────┼────────────────┤
│ API Gateway │ DDoS │ Rate Limiting │ Implemented │
│ │ Auth Bypass │ JWT Validation │ Implemented │
├────────────────┼────────────────┼────────────────┼────────────────┤
│ Database │ SQL Injection │ Prepared Stmts │ Implemented │
│ │ Data Leakage │ Encryption │ In Progress │
└────────────────┴────────────────┴────────────────┴────────────────┘
2. Risk Assessment Matrix
1
2
3
4
5
6
7
8
9
┌─────────────┬───────────────────────────────────────────┐
│ │ Impact Severity │
│ ├───────────┬───────────┬───────────┬───────┤
│ │ Low │ Medium │ High │Critical│
│ Likelihood ├───────────┼───────────┼───────────┼───────┤
│ High │ Medium │ High │ Critical │Critical│
│ Medium │ Low │ Medium │ High │ High │
│ Low │ Low │ Low │ Medium │ High │
└─────────────┴───────────┴───────────┴───────────┴───────┘
3. Attack Tree Model
1
2
3
4
5
6
7
8
9
10
11
12
13
Compromise System
│
┌──────────────────┴──────────────────┐
▼ ▼
Gain Access Exploit System
│ │
┌─────┴─────┐ ┌──────────┴──────────┐
▼ ▼ ▼ ▼
Brute Force Social Engineer Buffer Overflow Code Injection
│ │ │ │
└─────┬─────┘ └──────────┬──────────┘
▼ ▼
Unauthorized Access System Control
Security Control Implementation Models
1. Authentication Flow
1
2
3
4
5
6
7
8
9
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Client │────>│ Login │────>│ Auth │────>│ Token │
│ │<────│ Form │<────│ Service │<────│ Gen │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
│ │
│ ┌──────────┐ │
└─────────────>│Protected │<──────────────────────┘
│Resource │
└──────────┘
2. Data Encryption Model
1
2
3
4
5
6
7
8
9
┌─────────────────────────────────────────────────────────┐
│ Encryption Layers │
├─────────────┬─────────────┬─────────────┬─────────────┤
│ Transport │ Application │ Database │ Backup │
│ Layer │ Layer │ Layer │ Layer │
├─────────────┼─────────────┼─────────────┼─────────────┤
│ TLS │ JWE │ TDE/Field │ At-Rest │
│ 1.3 │ Tokens │ Encryption │ Encryption │
└─────────────┴─────────────┴─────────────┴─────────────┘
Step 2: Identifying Threats - The STRIDE Model
STRIDE is a proven framework for identifying security threats. Let’s apply it to SecureShop:
Spoofing
- Definition: Pretending to be something or someone else
- SecureShop Examples:
- Attacker impersonating a legitimate user
- Fake admin login attempts
- Phishing attacks targeting customers
- Mitigation:
- Implement MFA for all admin accounts
- Use OAuth2 with secure token management
- Email verification for new accounts
- IP-based login anomaly detection
Tampering
- Definition: Modifying data or code without authorization
- SecureShop Examples:
- Price manipulation in shopping cart
- Modifying order details in transit
- Tampering with product reviews
- Mitigation:
- Server-side price validation
- Digital signatures for order data
- Audit logs for all data modifications
- Input validation and sanitization
Repudiation
- Definition: Denying having performed an action
- SecureShop Examples:
- Customer denying placing an order
- Admin denying product price changes
- User denying leaving negative reviews
- Mitigation:
- Comprehensive logging system
- Digital signatures for transactions
- Email confirmations for all actions
- Blockchain for critical transactions
Information Disclosure
- Definition: Exposing information to unauthorized parties
- SecureShop Examples:
- Credit card data exposure
- Customer personal information leak
- Internal pricing strategy exposure
- Mitigation:
- Data encryption at rest and in transit
- PCI DSS compliance for payments
- Role-based access control (RBAC)
- Data masking in logs
Denial of Service
- Definition: Making a system or resource unavailable
- SecureShop Examples:
- Shopping cart service overload
- Payment processing disruption
- Product search service crash
- Mitigation:
- Rate limiting on all APIs
- CDN for static content
- Auto-scaling infrastructure
- DDoS protection service
Elevation of Privilege
- Definition: Gaining capabilities without proper authorization
- SecureShop Examples:
- Customer accessing admin functions
- Support staff accessing payment data
- API endpoint permission bypass
- Mitigation:
- Strict RBAC implementation
- Regular permission audits
- API gateway authorization
- Least privilege principle
Step 3: Addressing Threats in SecureShop
For each identified threat, implement specific responses:
- Mitigate: Implement controls to reduce risk
- Example: Implementing rate limiting on login API
1 2 3 4 5
@app.route('/api/login', methods=['POST']) @limiter.limit("5 per minute") # Rate limiting def login(): # Login logic with audit logging audit_log.info(f"Login attempt from IP: {request.remote_addr}")
- Example: Implementing rate limiting on login API
- Eliminate: Remove vulnerable components
- Example: Removing direct database access from public API ```python
BAD - Direct DB access
@app.route(‘/api/products/
') def get_product(id): return db.query(f"SELECT * FROM products WHERE id = {id}")
GOOD - Using ORM with parameter binding
@app.route(‘/api/products/
') def get_product(id): return Product.query.filter_by(id=id).first_or_404() ``` - Example: Removing direct database access from public API ```python
- Transfer: Shift risk to specialized services
- Example: Using Stripe for payment processing
1 2 3 4 5 6 7 8 9 10 11
@app.route('/api/payment', methods=['POST']) def process_payment(): try: # Use Stripe SDK instead of handling cards directly charge = stripe.Charge.create( amount=request.form['amount'], currency='usd', source=request.form['token'] ) except stripe.error.CardError as e: return jsonify(error=str(e)), 400
- Example: Using Stripe for payment processing
- Accept: Document and monitor acceptable risks
- Example: Accepting the risk of product image hotlinking
1 2 3 4 5 6 7 8
# Document accepted risk """ Risk: Product image hotlinking Impact: Increased bandwidth costs Mitigation: Monitor usage, implement CDN if costs exceed threshold Accepted by: Security Team (2024-01-01) Review Date: 2024-06-01 """
- Example: Accepting the risk of product image hotlinking
Step 4: Validation for SecureShop
Implement comprehensive validation:
- Automated Testing
1 2 3 4 5 6 7 8 9 10 11 12 13 14
def test_authentication_security(): # Test failed login attempts assert client.post('/api/login', json={ 'email': 'admin@example.com', 'password': 'wrong' }).status_code == 401 # Test rate limiting for _ in range(6): response = client.post('/api/login', json={ 'email': 'admin@example.com', 'password': 'wrong' }) assert response.status_code == 429
- Security Headers Check
1 2 3 4 5
def test_security_headers(): response = client.get('/') assert response.headers['X-Frame-Options'] == 'DENY' assert response.headers['X-Content-Type-Options'] == 'nosniff' assert 'strict-transport-security' in response.headers
- Regular Security Scans ```yaml
GitHub Actions workflow for security scanning
name: Security Scan on: schedule:
- cron: ‘0 0 * * *’ jobs: security_scan: runs-on: ubuntu-latest steps:
- uses: actions/checkout@v2
- name: Run OWASP ZAP scan uses: zaproxy/action-full-scan@v0.4.0 ```
- cron: ‘0 0 * * *’ jobs: security_scan: runs-on: ubuntu-latest steps:
Best Practices
- Start Early: Incorporate threat modeling in the design phase
- Keep it Simple: Use clear, understandable diagrams
- Be Systematic: Follow the STRIDE framework
- Document Everything: Record threats, decisions, and assumptions
- Review Regularly: Update models as systems change
- Involve the Team: Include developers, architects, and security experts
Common Pitfalls to Avoid
- Making the model too complex
- Focusing only on known threats
- Not considering trust boundaries
- Skipping validation steps
- Failing to document assumptions
Implementing Security Controls
Example Security Middleware
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
from functools import wraps
from flask import request, abort
import jwt
def require_auth(f):
@wraps(f)
def decorated(*args, **kwargs):
token = request.headers.get('Authorization')
if not token:
abort(401)
try:
payload = jwt.decode(token, app.config['SECRET_KEY'])
request.user = payload
except:
abort(401)
return f(*args, **kwargs)
return decorated
@app.route('/api/admin/users', methods=['GET'])
@require_auth
def get_users():
if request.user['role'] != 'admin':
abort(403)
# Process request
Example Rate Limiting Implementation
1
2
3
4
5
6
7
8
9
10
11
12
13
from flask_limiter import Limiter
from flask_limiter.util import get_remote_address
limiter = Limiter(
app,
key_func=get_remote_address,
default_limits=["200 per day", "50 per hour"]
)
@app.route("/api/products")
@limiter.limit("1000 per day")
def get_products():
return Product.query.all()
Additional Security Implementation Patterns
1. API Security Pattern
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
@app.route('/api/v1/resource', methods=['POST'])
@rate_limit(max_requests=100, period=60) # 100 requests per minute
@require_auth
@validate_input
@audit_log
def protected_resource():
try:
# Business logic
result = process_request(request.json)
# Audit logging
audit_logger.info({
'action': 'resource_access',
'user': g.user.id,
'resource': request.path,
'status': 'success'
})
return jsonify(result), 200
except ValidationError as e:
# Error handling with proper logging
error_logger.warning({
'error': str(e),
'user': g.user.id,
'path': request.path
})
return jsonify({'error': 'Validation failed'}), 400
2. Secure Database Access Pattern
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class SecureRepository:
def __init__(self, connection_pool, encryption_service):
self.pool = connection_pool
self.encryption = encryption_service
async def get_sensitive_data(self, user_id: str) -> Dict:
async with self.pool.acquire() as conn:
# Use prepared statements to prevent SQL injection
query = """
SELECT encrypted_data
FROM sensitive_table
WHERE user_id = $1
"""
result = await conn.fetchrow(query, user_id)
if result:
# Decrypt data before returning
return self.encryption.decrypt(result['encrypted_data'])
return None
Conclusion
Threat modeling is a critical security practice that helps identify and address potential security issues early in the development process. By following the four-step framework and using tools like STRIDE, teams can build more secure systems and maintain them effectively over time.
Remember: Threat modeling is not a one-time activity but an ongoing process that should evolve with your system. Regular reviews and updates ensure your security posture remains strong as threats and requirements change.