Security in System Design

In 2014, Sony Pictures Entertainment suffered one of the most devastating corporate cyber attacks in history. Attackers exfiltrated over 100 terabytes of data—including unreleased films, employee personal data, executive emails, and salary information. The attack paralyzed operations for weeks and caused over $100 million in damages.

What's remarkable isn't that attackers found a way in—it's that many of the attack vectors were entirely foreseeable. Email phishing, weak network segmentation, unencrypted sensitive files, and inadequate access controls were all exploited. A systematic threat modeling exercise would have surfaced these risks months before the breach.

Threat modeling is the practice of anticipating attacks before they happen. It forces you to think like an adversary: What assets are valuable? How might someone try to steal or destroy them? What weaknesses could they exploit? This proactive analysis is far cheaper than reactive incident response.

This page teaches you to systematically identify, analyze, and prioritize threats—giving you the attacker's perspective so you can defend against it.

Threat modeling is a structured approach to identifying security threats, vulnerabilities, and the mitigations needed to protect a system. It's performed during design—before code is written—but can be applied to existing systems as well.

The core questions of threat modeling:

1. What are we building? — Understand the system's architecture, components, data flows, and trust boundaries.

2. What can go wrong? — Systematically identify potential threats and attack scenarios.

3. What are we going to do about it? — Define mitigations, accept risks, or redesign to eliminate threats.

4. Did we do a good enough job? — Validate the model, test mitigations, and iterate.

Threat modeling isn't about achieving perfect security—it's about making informed decisions about which risks to address and which to accept.

When to perform threat modeling:

• New System Design: Before writing code, model the planned architecture.
• Major Feature Additions: When adding significant functionality, assess new threats.
• Infrastructure Changes: Migrating to cloud, adding new data stores, changing authentication.
• Security Incidents: Post-breach, revisit the threat model to understand what was missed.
• Periodic Review: At least annually, review existing threat models for relevance.

Threat modeling is not a one-time activity—it's a continuous practice that evolves with your system.

While many threat modeling methodologies exist, they generally follow a common process. Here's a practical workflow you can apply to any system:

Step 1: Decompose the System

Before identifying threats, you must understand what you're protecting. Create a clear picture of:

• Components: Services, databases, caches, message queues, external APIs
• Data Flows: How data moves between components, what data is transmitted
• Trust Boundaries: Where trust levels change (e.g., internet → load balancer → application → database)
• Entry Points: Where external actors can interact with the system
• Assets: What's valuable—user data, credentials, intellectual property, availability

Step 2: Create a Data Flow Diagram (DFD)

A Data Flow Diagram visualizes how data moves through your system. It uses standard symbols:

┌──────────────────────────────────────────────────────────────────┐
│  DFD Symbol Legend                                               │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌─────────┐                                                     │
│  │ Process │   — A process that transforms data                  │
│  └─────────┘                                                     │
│                                                                  │
│  ═══════════   — Data store (database, cache, file system)       │
│                                                                  │
│  ⬤ External   — External entity (user, external service)         │
│                                                                  │
│  ──────────→   — Data flow (direction shows data movement)       │
│                                                                  │
│  - - - - - -   — Trust boundary (crossing = potential threat)    │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

Example DFD for an e-commerce checkout:

                         ┌───────────────────────────────────────┐
                         │          Internal Network             │
  ⬤ Customer             │                                       │
       │                 │  ┌─────────────┐   ┌─────────────┐    │
       │ HTTPS           │  │   API       │──→│  Order      │    │
       ▼                 │  │   Gateway   │   │  Service    │    │
- - - - - - - - - - - - -│- - - - - - - - - - - - - - - - - - - -│
   Trust Boundary        │  └──────┬──────┘   └──────┬──────┘    │
                         │         │                  │          │
                         │         ▼                  ▼          │
                         │  ════════════        ════════════     │
                         │   Auth DB             Order DB        │
                         │  ════════════        ════════════     │
                         │         │                  │          │
                         │         └────────┬─────────┘          │
                         │                  │                    │
                         │                  ▼                    │
- - - - - - - - - - - - -│- - - - - - - - - - - - - - - - - - - -│
   Trust Boundary        │         ⬤ Payment                     │
                         │           Gateway                     │
                         └───────────────────────────────────────┘

Each trust boundary crossing is a potential attack surface. Each data flow represents potential data exposure or manipulation.

STRIDE is a threat classification framework developed at Microsoft that provides a structured way to identify threats. Each letter represents a category of threat:

• Spoofing — Pretending to be someone or something else
• Tampering — Modifying data or code without authorization
• Repudiation — Denying actions were taken
• Information Disclosure — Exposing data to unauthorized parties
• Denial of Service — Making the system unavailable
• Elevation of Privilege — Gaining unauthorized capabilities

For each component and data flow in your DFD, systematically ask: 'How might an attacker achieve each STRIDE threat here?'

Applying STRIDE to components:

Different components are susceptible to different STRIDE categories:

Example STRIDE analysis for a user authentication flow:

Component: Login API Endpoint

S - Spoofing: Attacker sends credentials stolen from another site
    → Mitigation: Rate limiting, breach password checking, MFA

T - Tampering: Request modified in transit to change username
    → Mitigation: HTTPS (TLS) for all communication

R - Repudiation: User claims they never logged in
    → Mitigation: Audit log with timestamp, IP, user agent

I - Information Disclosure: Error messages reveal valid usernames
    → Mitigation: Generic 'invalid credentials' message

D - Denial of Service: Attacker floods login endpoint
    → Mitigation: Rate limiting per IP, CAPTCHA after failures

E - Elevation of Privilege: SQL injection grants admin access
    → Mitigation: Parameterized queries, input validation

Attack trees are a complementary technique that models the steps an attacker might take to achieve a goal. The root of the tree is the attacker's objective, and branches represent different ways to achieve it.

Attack trees help identify:

• Multiple paths to the same objective
• Which attack paths are easiest (guiding prioritization)
• Shared sub-goals that, if protected, block multiple paths

Structure of an attack tree:

                    ┌─────────────────────────────┐
                    │   GOAL: Steal User Data     │ (Root: attacker objective)
                    └──────────────┬──────────────┘
                                   │
             ┌─────────────────────┼─────────────────────┐
             │                     │                     │
     ┌───────▼───────┐     ┌───────▼───────┐     ┌───────▼───────┐
     │ Exploit API   │     │ Compromise    │     │ Social        │
     │ Vulnerability │     │ Database      │     │ Engineering   │
     └───────┬───────┘     └───────┬───────┘     └───────┬───────┘
             │                     │                     │
      ┌──────┴──────┐       ┌──────┴──────┐       ┌──────┴──────┐
      │             │       │             │       │             │
   ┌──▼──┐       ┌──▼──┐ ┌──▼──┐      ┌──▼──┐ ┌──▼──┐      ┌──▼──┐
   │SQL  │       │Auth │ │Creds│      │Unenc│ │Phish│      │Bribe│
   │Inj  │       │Byps │ │Theft│      │rpted│ │Admin│      │Emply│
   └─────┘       └─────┘ └─────┘      └─────┘ └─────┘      └─────┘

Reading the tree:

• AND nodes: All children must succeed (represented by arc connecting children)
• OR nodes: Any child success achieves the parent goal (default, no arc)

In the example above, 'Steal User Data' can be achieved through API exploitation OR database compromise OR social engineering. Each of those has further sub-goals.

Annotating attack trees:

To prioritize mitigations, annotate nodes with attributes:

• Likelihood: How probable is this attack step? (Low/Medium/High)
• Difficulty: How hard is it for an attacker? (Easy/Medium/Hard)
• Cost to attacker: Resources needed (time, money, expertise)
• Detectability: How likely are we to notice? (Unlikely/Possible/Likely)

Example with annotations:

┌─────────────────────────────────────────────────────────┐
│ SQL Injection                                           │
├─────────────────────────────────────────────────────────┤
│ Likelihood: High (common vulnerability)                 │
│ Difficulty: Easy (automated tools available)            │
│ Impact: Critical (full database access)                 │
│ Detectability: Medium (can be logged if monitored)      │
│ PRIORITY: CRITICAL - Mitigate immediately               │
└─────────────────────────────────────────────────────────┘

vs.

┌─────────────────────────────────────────────────────────┐
│ Bribe Employee                                          │
├─────────────────────────────────────────────────────────┤
│ Likelihood: Low (requires finding willing employee)     │
│ Difficulty: Hard (risk of exposure, uncertain outcome)  │
│ Impact: Varies (depends on employee access)             │
│ Detectability: Low (insider threat harder to detect)    │
│ PRIORITY: Medium - Monitor, background checks           │
└─────────────────────────────────────────────────────────┘

This analysis helps prioritize: fix SQL injection first, even though bribery is harder to detect.

Threat modeling typically identifies more risks than you can address immediately. Prioritization ensures you focus on the most critical threats first.

The DREAD Model:

DREAD is a risk assessment model that scores threats across five dimensions:

• Damage Potential: How severe if exploited? (1-10)
• Reproducibility: How easy to reproduce? (1-10)
• Exploitability: How easy to exploit? (1-10)
• Affected Users: How many impacted? (1-10)
• Discoverability: How easy to find? (1-10)

Total DREAD score = sum of all dimensions (5-50). Higher scores = higher priority.

Addressing threats — the four strategies:

For each identified threat, you have four options:

1. Mitigate — Implement controls to reduce likelihood or impact

   • Example: Add input validation to prevent SQL injection

2. Transfer — Shift risk to another party

   • Example: Use a third-party payment processor to avoid handling card data directly

3. Accept — Acknowledge the risk and proceed without mitigation

   • Example: Low-severity information disclosure that's too expensive to fix
   • Document thoroughly — Accepted risks should be tracked and reviewed periodically

4. Avoid — Eliminate the threat by removing the feature or component

   • Example: Don't store SSNs if not legally required

Most threats are mitigated. Acceptance should be rare and documented. Avoidance is the most secure but may conflict with business requirements.

Threat modeling is a collaborative activity. Here's how to run an effective threat modeling session:

Preparation (before the session):

1. Gather documentation: Architecture diagrams, data flow descriptions, API specs
2. Identify participants: Developers, architects, security team, product owners
3. Define scope: What system or feature are we modeling? What's out of scope?
4. Prepare materials: Whiteboard/digital canvas, STRIDE reference, existing threat models

Tips for effective sessions:

• Timebox ruthlessly. You won't cover everything in one session. Focus on the most critical areas.
• Separate identification from solution. First, capture all threats. Then discuss mitigations. Mixing them slows both.
• Encourage diverse perspectives. Developers think differently from security engineers. Both perspectives are valuable.
• Use prompts. 'What if an attacker had access to this?' 'What's the worst thing that could happen here?'
• Document everything. Threats identified today might become relevant tomorrow as the system evolves.
• Make it regular. Threat modeling isn't one-and-done. Schedule periodic reviews.

A threat model is a living document that should be maintained alongside the system it describes. Good documentation enables future teams to understand security decisions and update the model as the system evolves.

Essential threat model components:

Example threat table format:

Storing threat models:

Treat threat models as code artifacts:

• Store in version control alongside the codebase
• Review changes during code review
• Update when architecture changes
• Link from design documents and ADRs (Architecture Decision Records)

While threat modeling can be done with whiteboards and spreadsheets, specialized tools can improve efficiency and consistency:

Microsoft Threat Modeling Tool:

Free tool that uses DFD-based approach with automated STRIDE analysis. Generates threat reports based on diagram elements. Good for beginners and Microsoft-centric environments.

OWASP Threat Dragon:

Open-source, web-based threat modeling tool. Supports STRIDE, generates reports, integrates with version control. Cross-platform and free.

IriusRisk:

Commercial platform that automates threat modeling based on architecture patterns. Integrates with CI/CD for continuous threat assessment. Best for enterprises with mature security programs.

Threagile:

Open-source, code-based threat modeling. Define architecture in YAML, generate threat analysis programmatically. Fits DevOps workflows well.

Threat modeling in CI/CD:

Advanced teams integrate threat modeling into their pipelines:

1. Architecture-as-code: Define system architecture in YAML/JSON
2. Automated analysis: Tools like Threagile analyze for known threat patterns
3. Alerting on changes: When architecture changes, flag for threat model review
4. Tracking coverage: Monitor what percentage of components have been modeled

This doesn't replace human judgment but ensures threat modeling isn't forgotten as systems evolve.

We've covered the systematic practice of identifying and addressing threats before they become incidents. Let's consolidate the key takeaways:

What's next:

Now that we can identify and prioritize threats, we face a practical challenge: security often conflicts with usability. The next page addresses the critical tension between Security vs. Usability—how to design systems that are both secure and user-friendly, without sacrificing either.