Practical Cyber Security Architectures
Threat Modeling Architectures
Blueprint for Threats
Threat modeling isn't about guessing what might go wrong. It's a structured way to find security weaknesses in a system before it's attacked. To do this, you first need a clear picture of the system itself. This is where Data Flow Diagrams (DFDs) come in.
A DFD is a simple map that shows how data moves. It doesn't show every line of code or server configuration. Instead, it focuses on the big picture: where data comes from, how it's processed, and where it goes. DFDs help us spot potential weak points by forcing us to define what we trust and what we don't.
The most important concept in a DFD for security is the trust boundary. This is a line we draw around the parts of the system we control and, theoretically, trust. In the diagram above, our web server and database are inside our network, so we draw a boundary around them. The user's browser and the third-party payment processor are outside this boundary. Attacks often happen when data crosses these boundaries, so they are the most critical places to examine.
Frameworks for Finding Flaws
Once we have our map, we can use a framework to systematically identify potential threats. Two popular methodologies are STRIDE and PASTA. They approach the problem from different angles.
STRIDE is a technical, model-centric approach developed by Microsoft. It's a mnemonic that helps engineers find common types of threats based on the components of their system.
| Threat | Violated Property | Description |
|---|---|---|
| Spoofing | Authentication | An attacker pretends to be someone or something else. |
| Tampering | Integrity | Data is modified without authorization. |
| Repudiation | Non-repudiation | An attacker denies having performed an action. |
| Information Disclosure | Confidentiality | Sensitive data is exposed to unauthorized parties. |
| Denial of Service | Availability | The system is made unavailable to legitimate users. |
| Elevation of Privilege | Authorization | An attacker gains permissions they shouldn't have. |
Using STRIDE, you look at each component and data flow in your DFD and ask, "Could an attacker Spoof this? Tamper with this?" For example, looking at the DFD, we'd ask if a malicious user could tamper with the HTTP request to change an item's price. STRIDE is great for development teams because it's direct and maps well to technical controls. It helps answer the question: "What can go wrong with this thing we're building?"
PASTA, on the other hand, is a risk-centric methodology. It stands for Process for Attack Simulation and Threat Analysis. Instead of starting with the technology, PASTA starts with the business.
PASTA is a seven-step process that aims to align security decisions with business objectives. It focuses on the impact of an attack, not just the technical possibility of one.
The seven stages of PASTA are:
- Define Business Objectives: What is the application supposed to do and why is it valuable?
- Define the Technical Scope: What technologies make up the application?
- Decompose the Application: Map out data flows and trust boundaries, just like we did earlier.
- Analyze Threats: Research known threats against the technologies in use.
- Analyze Vulnerabilities: Look for weaknesses in code, design, and configuration.
- Analyze Attacks: Model how threats could be exploited to target vulnerabilities.
- Analyze Risk & Impact: Evaluate the likelihood and business impact of successful attacks and prioritize fixes.
PASTA answers the question: "What are the most meaningful attacks against our business that we need to prevent?"
Choosing Your Approach
So, when do you use STRIDE versus PASTA? It depends on your goal and resources.
STRIDE is best for:
- Tactical, component-level analysis. It's perfect for a development team analyzing a new feature or microservice.
- Quickly identifying common threats. It gives developers a security checklist without requiring deep business context.
- Environments with a mature security program where business risk is already well-understood.
PASTA is better suited for:
- Strategic, system-wide analysis. It's ideal for new, complex projects or for assessing the overall risk of a critical business application.
- Prioritizing work based on business impact. It helps justify security investments by tying them directly to business objectives.
- Organizations where security and business teams need to collaborate closely.
They aren't mutually exclusive. A team might use PASTA to define the overall risk landscape for a new e-commerce platform. Then, during development sprints, individual developers could use STRIDE to analyze the specific components they are building, like the shopping cart or the user profile service.
When you use the threat modeling process, you create consistent, repeatable steps for thinking through what can go wrong with — the cybersecurity impact arising from malicious actors successfully attacking — a software, application, or system that you're building, designing, or deploying.
Threat modeling turns security from a reactive, panicked clean-up into a proactive, engineering discipline. By mapping your systems and using frameworks like STRIDE or PASTA, you can find and fix flaws before they ever become a problem.
What is the primary purpose of a Data Flow Diagram (DFD) in the context of threat modeling?
In a Data Flow Diagram, the most critical places to examine for potential attacks are where data crosses a trust boundary.