Threat Modeling

Introduction to Threat Modeling

In software engineering, security is often treated as an afterthought. A team builds a massive, complex e-commerce application over six months, deploys it to production, and then hires a cybersecurity team to perform a “Penetration Test” to see if it can be hacked. By the time the security team discovers a fatal flaw in the database architecture, it is too late. Fixing the flaw requires rewriting 50,000 lines of code, costing the company millions of dollars and delaying the launch by months.

Threat Modeling is the process of shifting security to the absolute beginning of the development lifecycle (“Shifting Left”).

It is a structured, analytical exercise where software architects, developers, and security engineers sit in a room with a whiteboard before any code is written. They map out the proposed system and deliberately attempt to think like a hacker to identify potential vulnerabilities in the design itself.

The Threat Modeling Process

A formal threat modeling session typically answers four core questions:

1. What are we building? (Creating an architectural diagram).
2. What can go wrong? (Brainstorming specific attacks).
3. What are we going to do about it? (Designing mitigations).
4. Did we do a good job? (Validating the fixes).

Visualizing the Architecture (Data Flow Diagrams)

The team begins by drawing a Data Flow Diagram (DFD). They map out every component: The user’s web browser, the API Gateway, the Microservices, and the PostgreSQL database. Crucially, they draw “Trust Boundaries” (e.g., the line between the public internet and the internal corporate network). Any time data crosses a Trust Boundary, it is considered highly vulnerable.

The STRIDE Methodology

When brainstorming “What can go wrong?”, security teams use established frameworks to ensure they don’t miss anything. The most famous is Microsoft’s STRIDE framework. The team looks at every arrow on their diagram and asks if it is vulnerable to:

• S - Spoofing: Can a hacker pretend to be someone else? (e.g., Replaying a stolen session cookie to impersonate an admin).
• T - Tampering: Can a hacker alter the data in transit? (e.g., Intercepting a checkout request and changing the price from $100 to $1).
• R - Repudiation: Can a malicious user perform an illegal action and later deny they did it? (e.g., Deleting a database table without the system generating an audit log).
• I - Information Disclosure: Is data exposed? (e.g., Passing an unencrypted Social Security Number over HTTP).
• D - Denial of Service (DoS): Can a hacker crash the system? (e.g., Sending 1 million API requests per second to overwhelm the server).
• E - Elevation of Privilege: Can a normal user trick the system into granting them Admin rights? (e.g., Exploiting a SQL Injection flaw).

Designing Mitigations

Once the team identifies the threats using STRIDE, they design architectural mitigations before writing the code.

• Threat Identified: Information Disclosure between the API and the Database.
• Mitigation: The architectural spec is updated to mandate strict TLS 1.3 encryption for all internal network traffic.
• Threat Identified: Spoofing the Admin panel.
• Mitigation: The spec is updated to mandate Okta Multi-Factor Authentication (MFA) for the Admin route.

Conclusion

Threat Modeling transforms cybersecurity from a reactive panic into a proactive engineering discipline. By systematically identifying structural vulnerabilities during the design phase—when they cost nothing but time on a whiteboard to fix—organizations can build inherently secure architectures, preventing catastrophic breaches and massive code rewrites long before the software ever reaches production.