Secure by Design: Threat Modeling – Design with Risk in Mind

Proactively identifying threats before they become exploits is the cornerstone of secure software design. This post introduces Threat Modeling and how it helps developers build defensible systems from day one.

🔍 Why Threat Modeling Matters

Security isn't something you bolt on at the end—it's something you build in. Threat modeling allows developers and architects to answer the question: "What can go wrong?" early in the lifecycle. Microsoft famously incorporated it into their Security Development Lifecycle (SDL), drastically reducing vulnerabilities in Windows and Azure services.

🧠 What is Threat Modeling?

Threat modeling is a structured process to identify and mitigate potential threats to a system. It’s most effective during design but valuable at any stage. The primary goal is to think like an attacker and design defenses before writing a single line of code.

🛠️ Key Steps in Threat Modeling

• Identify Security Objectives: What are we protecting?
• Create an Architecture Diagram: Visualize data flows and trust boundaries.
• Decompose the Application: Understand components, inputs, and outputs.
• Identify Threats (STRIDE): Use threat categorization frameworks.
• Assess Risks: Prioritize using DREAD or CVSS.
• Mitigate: Implement defenses or compensating controls.
• Review and Iterate: Threat models must evolve.

🧠 STRIDE and Friends: Comparing Popular Threat Modeling Frameworks

While STRIDE is the most widely used framework for identifying threats in software design, it's often used alongside—or compared with—other frameworks. Here's a breakdown of STRIDE and its “friends.”

• STRIDE (Microsoft): A mnemonic-based model that categorizes six types of security threats:
  • Spoofing – impersonating users
  • Tampering – modifying data/code
  • Repudiation – denying actions
  • Information Disclosure – leaking data
  • Denial of Service – degrading service
  • Elevation of Privilege – gaining unauthorized access

  Great for developers during architecture and design phases.

• PASTA (Process for Attack Simulation and Threat Analysis): A risk-centric, 7-stage threat modeling methodology that aligns with business impact.
  • Starts with business objectives
  • Simulates realistic attacks
  • Quantifies risk to prioritize remediation

  Ideal for organizations that want to tie threat modeling to business risk and compliance.

• LINDDUN (Privacy-Focused): A privacy threat modeling framework focused on data protection and GDPR-like regulations.
  • Linkability
  • Identifiability
  • Non-repudiation
  • Detectability
  • Disclosure of information
  • Unauthorized actions
  • Non-compliance

  Best suited for applications handling sensitive or personal data (e.g., healthcare, finance).

• OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation): Developed by CERT, this is a strategic, organization-level model.
  • Focuses on identifying critical assets
  • Includes organizational processes and policy review
  • Evaluates risk posture and cultural readiness

  Great for large enterprises aligning security with governance.

• VAST (Visual, Agile, and Simple Threat Modeling): Designed for scalability and integration into Agile/DevOps pipelines.
  • Uses application and operational threat modeling
  • Supports automation and CI/CD workflows

  Useful for teams practicing DevSecOps and looking to scale modeling across many teams.

• Trike: A risk-based model that focuses on user-defined acceptable risk levels.
  • Builds a risk matrix for each asset and actor
  • Maps actions and access levels

  Best for systems with complex access control and policy requirements.

📊 Framework Comparison Summary

💣 Real-World Breaches and How Threat Modeling Could Help

• Capital One (2019): Firewall misconfiguration exposed 100M+ records. A threat model would have identified SSRF risk in AWS metadata access.
• Zoom (2020): URL spoofing flaw allowed attackers to mimic Zoom domains. Threat modeling could have flagged this during input/output trust boundary analysis.

🚀 Threat Modeling in Agile & DevSecOps

Traditional threat modeling practices—often done during waterfall design phases—don't scale well in modern Agile and DevSecOps environments. Teams today iterate rapidly, deploy frequently, and embrace shift-left principles. To stay effective, threat modeling must evolve from a one-time compliance checklist to a continuous, collaborative, and lightweight practice.

⚡ Challenges in Agile Environments

• Short sprints leave little time for formal security reviews
• Architecture evolves rapidly, often without centralized diagrams
• Security teams are outnumbered by developers

✅ Adapting Threat Modeling for Agile

Agile teams can embed threat modeling without slowing delivery by adopting these approaches:

• Just-in-time Modeling: Conduct quick, focused threat modeling sessions during backlog grooming or sprint planning—especially for new epics or major changes.
• Story-driven Modeling: Add security considerations directly into user stories and acceptance criteria. Example: “As a user, I want to reset my password without exposing my email or account status.”
• Collaborative Whiteboarding: Use lightweight tools (e.g., Miro, Threat Dragon) to map out components and trust boundaries in live team sessions.

🔄 Continuous Threat Modeling in DevSecOps

DevSecOps extends Agile by tightly integrating security into the software delivery pipeline. Here's how threat modeling fits in:

👥 Developer-Led Threat Modeling

Security can't scale unless developers own it. Empowering developers with simple checklists and templates makes threat modeling a natural part of their workflow.

• Threat modeling cards: Lightweight STRIDE examples tied to dev use cases
• Security champions: Appoint 1–2 devs per squad to lead security discussions
• Security as Code: Use Git repositories to track threat models and link to stories or epics

With these practices, threat modeling becomes a shared responsibility—not a bottleneck.

⚙️ Tooling and Automation

Modern threat modeling is supported by a range of tools—some lightweight and open source, others enterprise-grade with deep integrations. Here's a curated list of tools you can start with:

• Microsoft Threat Modeling Tool – A free Windows desktop app that helps developers create data flow diagrams (DFDs) and auto-generates STRIDE-based threats. Great for teams using Microsoft tech stacks.
• OWASP Threat Dragon – An open-source, web-based threat modeling tool developed by OWASP. Supports diagramming, threat generation, and GitHub integration. Ideal for agile teams.
• IriusRisk – A powerful, commercial threat modeling platform that integrates with Jira, CI/CD pipelines, and architecture diagrams. Offers risk scoring, test case generation, and full DevSecOps support.
• ThreatModeler – An enterprise tool that automates threat identification, integrates with AWS and Azure, and helps generate compliance-ready reports.
• Foreseeti securiCAD – A modeling and simulation tool that uses attack graphs to evaluate system resilience. Good for complex enterprise environments and infrastructure threat modeling.

Choose a tool based on your needs: lightweight modeling (Threat Dragon), STRIDE automation (Microsoft TMT), or full DevSecOps integration (IriusRisk, ThreatModeler).

🔧 STRIDE Applied to an ASP.NET Core Endpoint

Let's explore how each STRIDE threat category applies to a simple GET /user/profile API, along with examples showing both vulnerable and secure implementations.

1. Spoofing

Vulnerability: Endpoint allows impersonation by accepting a username as input.

[HttpGet("user/profile")]
public IActionResult GetProfile(string username)
{
    var user = _db.Users.FirstOrDefault(u => u.Username == username);
    return Ok(user);
}

Fix: Use [Authorize] and extract the authenticated username.

[Authorize]
[HttpGet("user/profile")]
public IActionResult GetProfile()
{
    var username = User.Identity?.Name;
    var user = _db.Users.FirstOrDefault(u => u.Username == username);
    return Ok(user);
}

2. Tampering

Vulnerability: Application does not enforce HTTPS, enabling MITM attacks.

services.AddHttpsRedirection(options => {
    options.HttpsPort = 0; // Disabled
});

Fix: Force HTTPS and HSTS in production.

app.UseHttpsRedirection();
app.UseHsts();

3. Repudiation

Vulnerability: Changes are not logged, allowing users to deny actions.

public IActionResult UpdateProfile(Profile profile)
{
    _db.Update(profile);
    _db.SaveChanges();
    return Ok();
}

Fix: Add audit logging.

public IActionResult UpdateProfile(Profile profile)
{
    var actor = User.Identity?.Name;
    _logger.LogInformation($"User {actor} updated profile at {DateTime.UtcNow}");

    _db.Update(profile);
    _db.SaveChanges();
    return Ok();
}

4. Information Disclosure

Vulnerability: Full user model is exposed in API response.

return Ok(user);

Fix: Use a DTO to control what is returned.

public class UserDto {
    public string Name { get; set; }
    public string Email { get; set; }
}

return Ok(new UserDto {
    Name = user.Name,
    Email = user.Email
});

5. Denial of Service (DoS)

Vulnerability: Endpoint lacks validation or throttling.

public IActionResult Search(string term)
{
    var result = _db.Users.Where(u => u.Name.Contains(term)).ToList();
    return Ok(result);
}

Fix: Validate and limit input/output.

public IActionResult Search(string term)
{
    if (string.IsNullOrWhiteSpace(term) || term.Length > 50)
        return BadRequest("Invalid input");

    var result = _db.Users
        .Where(u => u.Name.Contains(term))
        .Take(100)
        .ToList();

    return Ok(result);
}

6. Elevation of Privilege

Vulnerability: Anyone can delete users.

[HttpPost("admin/delete-user")]
public IActionResult DeleteUser(string id)
{
    _db.Users.Remove(_db.Users.Find(id));
    _db.SaveChanges();
    return Ok();
}

Fix: Require admin role.

[Authorize(Roles = "Admin")]
[HttpPost("admin/delete-user")]
public IActionResult DeleteUser(string id)
{
    _db.Users.Remove(_db.Users.Find(id));
    _db.SaveChanges();
    return Ok();
}

📊 STRIDE Summary Table

✅ Conclusion

Threat modeling isn't just for security experts—it's a critical practice for developers and architects to embed into the SDLC. By using STRIDE and a risk-first mindset, you can identify issues before attackers do and build secure systems by design.