Anyone can Threat Model Anything

Threat modeling is a foundational design time activity and good developmental practice, the key goal is to understand threats and risks to the systems and services as early in the lifecycle as possible before spending too much time, effort and money, to the uninitiated it can sometimes feel overwhelming or need specialist skills.

In this basic introduction I will start with basic design time collaborative threat modelling, that anyone can do!

By breaking down the early solution or systems components design and using structured methodologies like the 4-Question Framework, STRIDE methodology, and Data Flow Diagrams (DFDs) makes the threat modelling process logical and highly actionable.

Here is a basic overview of how these concepts work together, applied to a three-tier photo-sharing web application.

1. The 4-Question Framework

This framework, popularized by Adam Shostack, simplifies threat modeling into four practical phases. It serves as the overarching lifecycle for your security analysis.

1. What are we working on? (System modeling using architectural diagrams and DFDs).

2. What can go wrong? (Threat identification using methodologies like STRIDE).

3. What are we going to do about it? (Mitigation planning—e.g., encryption, input validation).

4. Did we do a good enough job? (Validation, review, and penetration testing).

2. Data Flow Diagrams (DFDs)

To answer the first question ("What are we working on?"), you build a DFD. A DFD is a visual representation of how data moves through your system. It highlights where data is exposed and where trust levels change.

Core DFD Elements:

• External Entities (Rectangles): Outside users or systems (e.g., a Mobile User, a Third-Party API).

• Processes (Circles): Code or services that modify or route data (e.g., Web Server, Authentication Service).

• Data Stores (Two parallel lines): Where data rests (e.g., SQL Database, AWS S3 bucket).

• Data Flows (Arrows): The movement of data between the other elements.

• Trust Boundaries (Dotted lines): The critical borders where data moves between different security domains (e.g., the internet vs. your internal network, or the web tier vs. the database tier).

3. The STRIDE Methodology

Once your DFD is drawn, you use STRIDE to answer the second question ("What can go wrong?"). You apply STRIDE to every element and data flow in your DFD to systematically uncover threats.

Threat	Desired Property Violated	Definition
Spoofing	Authenticity	Pretending to be someone or something else.
Tampering	Integrity	Modifying data in transit or at rest.
Repudiation	Non-repudiability	Claiming you didn't perform an action, and the system lacks the logs to prove otherwise.
Information Disclosure	Confidentiality	Exposing data to unauthorized individuals.
Denial of Service	Availability	Exhausting resources so the system is unusable for legitimate users.
Elevation of Privilege	Authorization	Gaining access or capabilities you shouldn't have (e.g., a user becoming an admin).

4. Example: Three-Tier Photo Sharing Web App

Let's apply this to a standard three-tier application where users can log in, upload photos, and view friends' photos.

How this maps to standard DFDs:

• External Entities: (e.g., the User persona).

• Processes: Represented by create a circle (e.g., the Web/API Server that runs code).

• Data Stores: Represented by the cylinder shape (e.g., the Database and Object Storage).

• Trust Boundaries: Represented by borders red and dotted, which is the standard visual language for a trust boundary in threat modeling.

Architecture Context

• Tier 1 (Presentation): The user's web browser.

• Tier 2 (Application): The web/API server handling logic.

• Tier 3 (Data): A relational database (for user data/metadata) and object storage (for the actual image files).

Phase 1: What are we working on? (The DFD Summary)

• Flow 1: User enters credentials $\rightarrow$ Web Server. (Crosses the Internet Trust Boundary).

• Flow 2: Web Server queries Database $\rightarrow$ Database returns Auth token. (Crosses the App-to-Data Trust Boundary).

• Flow 3: User uploads Photo $\rightarrow$ Web Server processing $\rightarrow$ Object Storage.

Phase 2: What can go wrong? (Applying STRIDE)

Let's look at Flow 3 (Uploading a Photo) and apply STRIDE:

• Spoofing: An attacker steals a user's session cookie and uploads a photo under their name.

• Tampering: An attacker intercepts the photo upload in transit and replaces the image with malware or inappropriate content.

• Repudiation: A user uploads an illegal image, but because there are no server logs linking their IP to the upload, the company cannot prove who did it.

• Information Disclosure: The object storage bucket is misconfigured as "Public," allowing anyone to view private photos.

• Denial of Service (DoS): A user writes a script to upload millions of massive 4K photos in seconds, filling up the server's storage and crashing the app.

• Elevation of Privilege: A standard user manipulates the API request to change the role=user flag to role=admin during the upload process, giving them access to delete other people's photos.

Phase 3: What are we going to do about it? (Mitigations)

Now we design security controls for the threats we found:

• For Spoofing/Tampering: Enforce strict HTTPS/TLS for all data in transit. Implement Multi-Factor Authentication (MFA) and secure, short-lived session tokens.

• For Repudiation: Implement centralized, immutable logging that records the User ID, IP address, and timestamp for every upload.

• For Info Disclosure: Enforce strict Identity and Access Management (IAM) policies on the storage bucket, ensuring photos are only retrieved via authenticated, signed URLs.

• For DoS: Implement rate limiting on the API and restrict the maximum file upload size (e.g., 10MB max).

• For Elevation of Privilege: Enforce strict server-side input validation and Role-Based Access Control (RBAC). Never trust client-side role definitions.

Phase 4: Did we do a good enough job? (Validation)

Finally, the team reviews the DFD, ensures every identified STRIDE threat has a corresponding mitigation in the backlog, and schedules a penetration test to verify the rate limiting and bucket permissions actually work in production.

Would you like me to map out a more detailed list of mitigations for the database tier specifically, or would you prefer to dive deeper into how to structure the logging to prevent Repudiation?

I hope you found this introduction to threat modelling useful and I would certainly recommend Adam's books and training here https://shostack.org/training