Threat Modeling: The Architectural Framework for Identifying Security Risks Early

Regardless of the specific framework chosen, every threat modeling exercise seeks to answer four fundamental questions, originally codified by Adam Shostack, a pioneer in the field:

1. What are we building? This requires creating a comprehensive architectural diagram (usually a Data Flow Diagram) of the application, including its components, data stores, external dependencies, and user interactions.
2. What can go wrong? This is the core brainstorming phase where the team identifies potential threats against the components mapped out in the first step.
3. What are we going to do about it? This phase involves defining mitigation strategies or security controls to address the identified threats.
4. Did we do a good enough job? This is the validation phase, ensuring that the mitigations were properly implemented and actually resolve the identified risks.

The cybersecurity industry has developed several structured methodologies to guide the brainstorming phase (Question 2: What can go wrong?). Selecting the right framework depends heavily on the organization's maturity and specific goals.

1. STRIDE

Developed by Microsoft, STRIDE is arguably the most widely adopted threat modeling framework in the world. It is highly developer-centric and focuses on classifying threats into six specific categories. It is particularly effective for evaluating the technical architecture of an application.

• Spoofing Identity: Can an attacker masquerade as a legitimate user or another system component? (Violates Authentication).
• Tampering with Data: Can an attacker modify data while it is in transit over the network or at rest in a database? (Violates Integrity).
• Repudiation: Can a user perform an action and later deny having performed it, without the system being able to prove otherwise? (Violates Non-Repudiation/Logging).
• Information Disclosure: Can an attacker access sensitive data they are not authorized to see? (Violates Confidentiality).
• Denial of Service: Can an attacker crash the system or consume all its resources, making it unavailable to legitimate users? (Violates Availability).
• Elevation of Privilege: Can an unprivileged user exploit a flaw to gain administrative access to the system? (Violates Authorization).

2. PASTA (Process for Attack Simulation and Threat Analysis)

Unlike STRIDE, which is highly technical, PASTA is a risk-centric framework. It aligns technical threats with business objectives. PASTA involves a seven-step process that requires heavy collaboration between developers, security teams, and business stakeholders. It focuses on identifying the threats that would cause the most significant financial or reputational damage to the organization, ensuring that mitigation efforts are prioritized based on actual business risk rather than just technical severity.

3. DREAD

While STRIDE helps identify threats, DREAD is a methodology used to rate and prioritize them. It scores threats based on five categories:

• Damage Potential (How bad would the attack be?)
• Reproducibility (How easy is it to replicate the attack?)
• Exploitability (How much effort and expertise is required to pull off the attack?)
• Affected Users (How many users would be impacted?)
• Discoverability (How easy is it for an attacker to find the vulnerability?)

Note: While historically popular, DREAD has fallen out of favor in many modern organizations due to the subjective nature of its scoring, often being replaced by standard Risk Matrices or CVSS scoring.

Executing a successful threat model requires a structured, iterative approach involving the entire engineering team.

Step 1: System Decomposition and Data Flow Diagrams (DFDs)

You cannot secure what you do not understand. The first step is to break the application down into its constituent parts. Engineers create Data Flow Diagrams (DFDs) to visually map the system. A proper DFD must include:

• External Entities: Users, browsers, external APIs, or third-party services that interact with the application.
• Processes: The internal application components that manipulate data (e.g., a web server, an authentication microservice).
• Data Stores: Where data is kept at rest (e.g., SQL databases, S3 buckets, local file systems).
• Data Flows: The pathways data takes as it moves between entities, processes, and stores.

Crucially, the DFD must clearly define Trust Boundaries. A trust boundary represents a location where data moves from a less trusted environment to a more trusted environment (e.g., data moving from the public internet into the internal web server). Attackers almost always focus their efforts on crossing these trust boundaries.

Step 2: Identifying Threats

Once the DFD is complete, the team systematically analyzes every component and data flow crossing a trust boundary. Using a framework like STRIDE, the team asks specific questions. For example, looking at the data flow between the user's browser and the web server: Can this data be Tampered with in transit? (Yes, if HTTPS is not enforced). Can the user Spoof their identity? (Yes, if session cookies are predictable). This phase requires creative, adversarial thinking.

Step 3: Mitigating Threats

For every threat identified, the team must define a mitigation strategy. Mitigations usually fall into one of four categories:

1. Redesign: Change the architecture to eliminate the threat entirely (e.g., removing a feature that requires storing plain-text passwords).
2. Mitigate: Apply standard security controls to reduce the risk (e.g., implementing TLS 1.3 to prevent data tampering in transit, or parameterized queries to prevent SQL injection).
3. Accept: If the threat is low impact and the cost of mitigation is too high, the business may choose to accept the risk. This requires explicit sign-off from management.
4. Transfer: Shift the risk to a third party (e.g., buying cybersecurity insurance or outsourcing payment processing to Stripe).

These mitigations must be documented as explicit security requirements or Jira tickets in the development backlog.

Step 4: Validation

Threat modeling is not a one-and-done activity; it is a living document. As the application is built and features change, the threat model must be updated. Validation involves confirming that the defined mitigations were actually implemented in the code (often verified via code review or Static Application Security Testing - SAST) and that they effectively neutralize the threat (often verified via dynamic testing or penetration testing).

Historically, threat modeling was a slow, manual process that frustrated agile development teams. To succeed in modern DevSecOps environments, the process must be streamlined and integrated into the existing CI/CD pipeline.

• Threat Modeling as Code: Instead of using clunky whiteboard drawings, teams are moving towards "Threat Modeling as Code" using tools like Threatspec or automated platforms like IriusRisk. Developers define the architecture and trust boundaries in YAML or Python scripts, allowing the threat model to live in version control alongside the application code.
• Automation: Modern platforms can automatically ingest infrastructure-as-code (IaC) templates (like Terraform or CloudFormation), automatically generate the DFD, and suggest potential STRIDE threats based on known cloud misconfigurations.
• Agile Integration: Instead of modeling the entire monolithic application at once, Agile teams perform "micro-threat models" during the sprint planning phase for every new epic or significant user story.