Building secure systems through threat modeling

Threat modeling is one of the most critical practices in secure software development. It's a structured approach that helps security professionals, developers, and architects identify potential security threats before they can be exploited. By examining system behavior, data flows, trust boundaries, and potential misuse scenarios, teams can proactively reduce risks and design more secure architectures.

This article provides a comprehensive guide to threat modeling, using a real-world case study of Encrypt&Go - a browser-based secure file encryption and sharing system I developed, hosted, and deployed. After building the application, I created a comprehensive threat model to identify and mitigate security risks. Through this practical example, you'll learn how to apply threat modeling methodologies, identify attack surfaces, assess risks, and develop effective mitigation strategies.

What is Threat Modeling?

Threat modeling is a systematic process of identifying, quantifying, and addressing security risks in a system. It answers fundamental questions:

• What are we building? Understanding the system architecture and components
• What can go wrong? Identifying potential threats and vulnerabilities
• What should we do about it? Developing mitigation strategies
• Did we do a good job? Validating that threats are addressed

The goal isn't to create a perfect, impenetrable system - that's impossible. Instead, threat modeling helps you understand your security posture, prioritize risks, and make informed decisions about where to invest security resources.

Why Threat Modeling Matters

In today's threat landscape, security can't be an afterthought. Threat modeling provides several key benefits:

1. Proactive Security

Rather than reacting to security incidents, threat modeling helps you anticipate and prevent them. It's far more cost-effective to address security issues during design than after deployment.

2. Risk Prioritization

Not all threats are equal. Threat modeling helps you identify which risks pose the greatest danger to your system, allowing you to allocate resources effectively.

3. Security by Design

By considering threats from the beginning, you can design security into your system architecture rather than bolting it on later - a much more effective approach.

4. Compliance and Documentation

Many security frameworks and compliance standards (ISO 27001, NIST, OWASP) require threat modeling as part of secure development practices.

5. Team Alignment

Threat modeling creates a shared understanding of security risks across development, operations, and business teams.

The STRIDE Framework

STRIDE is one of the most widely used threat modeling methodologies, developed by Microsoft. It provides a systematic way to categorize threats:

• Spoofing: An attacker impersonates another user or system component
• Tampering: Unauthorized modification of data or system components
• Repudiation: Users deny performing actions, and there's no way to prove otherwise
• Information Disclosure: Unauthorized access to sensitive information
• Denial of Service (DoS): Attacks that prevent legitimate users from accessing the system
• Elevation of Privilege: An attacker gains unauthorized access to resources or privileges

STRIDE Threat Model Overview - Each category helps identify different types of security threats

Case Study: Encrypt&Go

Encrypt&Go is a lightweight, browser-based secure file encryption and sharing system I developed and hosted. The application is designed around a client-centric security model where all cryptographic operations occur exclusively on the client using AES-GCM encryption, ensuring that plaintext data never leaves the user's device or enters backend processing flows.

After developing and deploying the application, I conducted a comprehensive threat modeling assessment to identify potential security vulnerabilities and develop mitigation strategies. This threat model became an essential part of the security documentation and helped ensure the system's resilience against various attack vectors.

System Architecture

The system consists of three main components:

1. Client Browser: Performs encryption/decryption using AES-GCM
2. Backend API: Handles token generation and metadata management
3. Amazon S3 Storage: Stores encrypted files

Data Flow Diagram showing the complete system architecture and data flows

Design Principles

Encrypt&Go was intentionally designed to minimize security exposure:

• No user authentication: Reduces attack surface by avoiding authentication mechanisms
• No plaintext storage: Backend never handles or stores unencrypted data
• Client-side encryption: All cryptographic operations happen in the browser
• Stateless design: Minimal backend state reduces potential vulnerabilities

Despite these security-focused design choices, the system still faces meaningful risks that require careful analysis.

Step-by-Step Threat Modeling Process

Step 1: Define the System

First, clearly document what you're building. For Encrypt&Go, this included:

• Components: Client browser, backend API, S3 storage
• Data flows: How data moves through the system
• Trust boundaries: Where trust assumptions are made
• External dependencies: Third-party services and libraries

Step 2: Identify Attack Surfaces

Attack surfaces are interfaces where an attacker could potentially interact with your system. These are the entry points where security controls must be strongest. For Encrypt&Go, we identified five key attack surfaces:

Attack surfaces identified for Encrypt&Go with their descriptions and risk levels

Each attack surface represents a potential point of compromise:

• File Upload Endpoint: The first line of defense must validate file inputs to prevent DoS and tampering attacks
• Link Generation API: Critical for security - weak token generation could allow unauthorized access
• S3 Storage Bucket: Misconfiguration here could expose all encrypted files
• Client Browser Crypto Engine: While encryption happens client-side, weak entropy or compromised devices pose risks
• Download Endpoint: Must enforce proper access controls and rate limiting

Step 3: Apply STRIDE Analysis

For each component and data flow, we systematically evaluated threats using STRIDE:

Spoofing Threats

• Risk: Low
• Impact: Low
• Threat: An attacker could attempt to impersonate the system or guess access tokens
• Mitigation: Use high-entropy randomized links; avoid identity-based trust

Tampering Threats

• Risk: Medium
• Impact: High
• Threat: Attackers could modify encrypted files or API parameters
• Mitigation: HTTPS enforcement, integrity validation, strong API parameter handling

Repudiation Threats

• Risk: Low
• Impact: Low
• Threat: Users could deny uploading files
• Mitigation: Minimal metadata storage; no plaintext logs (by design, this is acceptable)

Information Disclosure Threats

• Risk: Medium
• Impact: High
• Threat: S3 bucket misconfiguration could expose encrypted files or metadata
• Mitigation: Strict IAM policies, S3 block-public-access, link expiry, access monitoring

Denial of Service Threats

• Risk: Low–Medium
• Impact: Medium
• Threat: Attackers could flood the system with uploads or requests
• Mitigation: Rate limiting, upload throttling, file-size caps

Elevation of Privilege Threats

• Risk: Low
• Impact: High
• Threat: Backend vulnerabilities could allow unauthorized access
• Mitigation: Principle of least privilege, endpoint hardening, IAM validation

Step 4: Create a Risk Matrix

A risk matrix helps prioritize threats by combining likelihood and impact. This visual representation makes it easy to see which threats require immediate attention and which can be addressed with lighter safeguards.

Risk matrix showing threat prioritization based on likelihood and impact

The matrix above clearly shows:

• High-risk threats (Tampering, Information Disclosure): Require immediate attention and strong mitigation controls
• Medium-risk threats (Denial of Service, Elevation of Privilege): Need appropriate safeguards but may not require the same level of urgency
• Low-risk threats (Spoofing): Can be addressed with lighter safeguards

This prioritization guides where to focus security efforts and helps allocate resources effectively. By focusing on high-impact, high-likelihood threats first, you can maximize your security investment.

Step 5: Develop Attack Scenarios

Attack scenarios help you understand how threats might be exploited in practice. Here are three realistic scenarios for Encrypt&Go:

Scenario 1: Link Token Brute Force

Attack: An attacker attempts high-volume enumeration of file-access tokens to retrieve encrypted objects.

How it works:

• Tokens are generated with insufficient entropy
• Attacker can systematically guess valid tokens
• Automated tools scan for accessible files

Mitigation:

• Use cryptographically secure random token generation (minimum 128 bits)
• Implement rate limiting on download endpoints
• Monitor for suspicious access patterns
• Automatically ban IPs showing brute-force behavior

Scenario 2: S3 Bucket Misconfiguration

Attack: Misconfigured bucket policies may expose data inadvertently.

How it works:

• S3 bucket accidentally set to public
• Access control lists (ACLs) misconfigured
• Bucket policy allows unauthorized access

Mitigation:

• Strict IAM policies with principle of least privilege
• AWS Access Analyzer for continuous monitoring
• Automated configuration validation
• Regular security audits of bucket policies

Scenario 3: Malicious Upload Flood

Attack: Attackers upload large files repeatedly to exhaust backend resources.

How it works:

• Automated scripts upload maximum-size files
• Multiple concurrent uploads overwhelm server
• Storage costs escalate rapidly

Mitigation:

• Enforce upload size caps (e.g., 100MB per file)
• Implement API throttling (rate limits per IP)
• Use WAF (Web Application Firewall) for traffic filtering
• Monitor storage usage and costs

Step 6: Create Attack Trees

Attack trees visualize how an attacker might achieve their goal through multiple attack paths. They help identify the most likely attack vectors and where to place defenses.

Attack tree showing different paths an attacker might take to gain unauthorized access

The attack tree above shows various paths an attacker could take:

• Direct token guessing: Brute force or social engineering
• S3 misconfiguration: Exploiting bucket policy errors
• Client-side attacks: Compromising the browser or encryption process
• Backend vulnerabilities: Exploiting API weaknesses

By understanding these paths, we can place defenses at the most effective points.

Step 7: Sequence Diagram Analysis

Sequence diagrams help visualize the flow of operations and identify where threats might occur during normal system operation.

Sequence diagram showing the complete workflow from encryption to secure retrieval

Key security considerations at each step:

1. Client Encryption: Ensure strong random key generation
2. Upload to Backend: Validate file size and format
3. Token Generation: Use cryptographically secure randomness
4. S3 Storage: Verify bucket security configuration
5. Link Sharing: Implement expiration and access controls
6. Download: Validate token and enforce rate limits

Business Impact Analysis

Understanding the business impact of security threats is crucial for risk prioritization. For Encrypt&Go, potential impacts include:

Confidentiality Breaches

• Impact: High
• Consequences: Exposed sensitive files could lead to data breaches, regulatory fines, and loss of customer trust

Regulatory Exposure

• Impact: High
• Consequences: GDPR violations could result in fines up to 4% of annual revenue

Operational Disruption

• Impact: Medium
• Consequences: DoS attacks could prevent legitimate users from accessing the service

Reputational Harm

• Impact: High
• Consequences: Security incidents damage brand reputation and customer confidence

Security Testing Plan

A comprehensive security testing plan validates that your threat model is accurate and mitigations are effective:

1. API Fuzzing

Test endpoints with malformed, oversized, or unexpected inputs to identify vulnerabilities.

2. Automated Vulnerability Scanning

Use tools like OWASP ZAP or Burp Suite to scan for common vulnerabilities.

3. Token Strength Evaluation

Analyze token entropy and randomness to ensure they can't be easily guessed.

4. AWS Policy Validation

Regularly audit S3 bucket policies, IAM roles, and access controls.

5. Load Testing

Test system resilience against DoS attacks and resource exhaustion.

6. Penetration Testing

Engage security professionals to attempt real-world attacks against the system.

Best Practices for Threat Modeling

Based on this experience, here are key lessons for effective threat modeling:

1. Start Early

Begin threat modeling during the design phase, not after implementation. It's much easier to design security in than to add it later.

2. Involve the Right People

Include developers, security professionals, operations staff, and business stakeholders. Different perspectives reveal different threats.

3. Use Structured Methodologies

Frameworks like STRIDE provide systematic coverage. Don't rely solely on ad-hoc brainstorming.

4. Document Everything

Maintain clear documentation of threats, risks, and mitigations. This becomes invaluable for future reviews and onboarding.

5. Review Regularly

Threats evolve as your system changes. Regularly review and update your threat model.

6. Prioritize Realistically

Not all threats require the same level of mitigation. Use risk matrices to focus on high-impact, high-likelihood threats.

7. Think Like an Attacker

Consider what an attacker would actually do, not just theoretical vulnerabilities. Attack scenarios help ground your analysis in reality.

8. Validate Assumptions

Question your security assumptions. For Encrypt&Go, we assumed client-side encryption was secure - but what if the client environment is compromised?

Common Pitfalls to Avoid

1. Over-Engineering

Don't try to mitigate every possible threat. Focus on realistic, high-impact risks.

2. Under-Documentation

Threat models are only useful if they're well-documented and accessible to the team.

3. Static Analysis

Threats change as your system evolves. Keep your threat model current.

4. Ignoring Business Context

Security decisions must balance risk with business needs. Not every system needs military-grade security.

5. Skipping Validation

A threat model is only as good as its validation. Test your assumptions and mitigations.

Conclusion

Threat modeling is an essential practice for building secure systems. Through the Encrypt&Go case study, we've seen how structured methodologies like STRIDE can help identify, assess, and mitigate security threats systematically.

Key takeaways:

• Threat modeling is proactive: It helps prevent security issues rather than react to them
• Structured approaches work: Frameworks like STRIDE provide comprehensive coverage
• Risk prioritization matters: Focus resources on high-impact, high-likelihood threats
• Documentation is critical: Well-documented threat models guide security decisions
• Regular reviews are essential: Threats evolve, and so should your threat model

For Encrypt&Go, the threat modeling process revealed that despite its client-centric security design, the system still faced meaningful risks - particularly around information disclosure and tampering. By identifying these threats early and developing appropriate mitigations, we were able to strengthen the system's security posture significantly.

Whether you're building a new system or securing an existing one, threat modeling provides the foundation for making informed security decisions. Start with a clear understanding of your system, apply structured methodologies, prioritize risks realistically, and validate your assumptions through testing.

Remember: the goal isn't perfect security - it's understanding your risks and making informed decisions about how to address them.

References

• Microsoft (1999). The Threats from STRIDE. Microsoft SDL.
• OWASP Foundation (2021). OWASP Threat Modelling Cheat Sheet. Available at: https://cheatsheetseries.owasp.org
• Howard, M. & Lipner, S. (2006). The Security Development Lifecycle. Microsoft Press.
• Schneier, B. (2015). Data and Goliath: The Hidden Battles to Collect Your Data and Control Your World. W. W. Norton & Company.
• Amazon Web Services (2023). Security Best Practices for Amazon S3. Available at: https://docs.aws.amazon.com