Post

Understanding Threat Modeling A Comprehensive Guide with Real-World Example

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:

  1. What are you building?
  2. What can go wrong?
  3. What should you do about those things that can go wrong?
  4. 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:

  1. 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}")
      
  2. 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() ```

  3. 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
      
  4. 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
      """
      

Step 4: Validation for SecureShop

Implement comprehensive validation:

  1. 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
    
  2. 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
    
  3. 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 ```

Best Practices

  1. Start Early: Incorporate threat modeling in the design phase
  2. Keep it Simple: Use clear, understandable diagrams
  3. Be Systematic: Follow the STRIDE framework
  4. Document Everything: Record threats, decisions, and assumptions
  5. Review Regularly: Update models as systems change
  6. Involve the Team: Include developers, architects, and security experts

Common Pitfalls to Avoid

  1. Making the model too complex
  2. Focusing only on known threats
  3. Not considering trust boundaries
  4. Skipping validation steps
  5. 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.

Resources

This post is licensed under CC BY 4.0 by the author.