Threat Modeling: Find Security Flaws Before Attackers Do

The most expensive vulnerability is the one you discover in production. The cheapest one - the one you catch on the board before anyone writes a line of code. Threat modeling is the systematic asking of the question “what could go wrong?” at the design stage. It’s one of the most cost-effective security practices - and yet it’s still rarely used outside of large organizations.

What is threat modeling

Threat modeling is a structured analysis of a system’s design in terms of who could attack it, how it could be attacked, and what should be done about it. It doesn’t require working code or tools - just an architecture diagram, a few people, and the discipline to ask the right questions.

The framework that Adam Shostack recommended and is most often used is the four questions:

1. What are we working on? - understanding and modeling the system.
2. What could go wrong? - hazard identification.
3. What will we do about it? - selection of security measures.
4. Did we do the job well? - verification and iteration.

Everything else - methods, diagrams, classifications - are merely tools to support the answers to these four questions.

Step 1: model the system (data flow diagram)

The starting point is a data flow diagram (DFD) - a simple diagram showing how information flows through the system. Four basic elements:

• Processes - data processing components (service, API, application).
• Data stores - databases, queues, files, cache.
• External entities - users, third-party systems, integrations.
• Data Flows - arrows connecting the above.

The key are *trust boundaries - the lines that data crosses, changing the level of trust: entry from the Internet to the application, from the application to the database, from your system to the external API. It is on these boundaries that most of the risk is concentrated and where the analysis focuses.

Step 2: Find threats using the STRIDE method

The most popular method for systematically looking for threats is STRIDE, an acronym for six categories, each of which is the opposite of a desired property:

Category	Threat	Violates
Spoofing	Impersonating someone/something	Authentication
Tampering	Unauthorized data modification	Integrity
Repudiation	Denial of the action performed	Non-repudiation
Information disclosure	Information leak	Confidentiality
Denial of service	Denial of service	Availability
Elevation of privilege	Elevation of Privilege	Authorization

The method is simple: you go through each element of the diagram and ask whether it falls into any of the categories. Can this user be impersonated (S)? Can this data flow be modified in transit (T)? Can this database leak (I)? Does this endpoint allow escalation of privileges (E)? STRIDE does not guarantee completeness, but it effectively forces you to think about threats that are easy to forget.

Pay particular attention to trust boundaries - this is where spoofing, data manipulation, and privilege escalation are most likely to occur.

Step 3: Decide what to do about each threat

For each identified threat, you have four possible decisions:

• Mitigate - implement security measures to reduce risk. The most common choice.
• Eliminate - remove the function or component that generates the risk.
• Transfer - transfer risk to another party (e.g. supplier, insurer).
• Accept - consciously accept a risk if the cost of defense outweighs the potential loss.

It is important that the decision is informed and documented. “We accepted the risk” is fine, as long as someone in authority actually understood and accepted it - not just overlooked it.

When to model threats

Threat modeling is not a one-time event, but a practice worth repeating:

• When designing a new system or larger function - then it is the cheapest.
• When there is a significant change in architecture - a new integration, migration to the cloud, adding a queue or a new data warehouse changes the threat map.
• After the incident - a real attack is the best reason to review the model and see what was missing.

You don’t have to model the entire system at once. It may be more effective to focus on the most critical flows - authentication, payment processing, personal data processing - and expand gradually.

Threat modeling and other layers

Threat modeling does not replace testing, but directs it. The model created at the design stage becomes a map for the subsequent penetration test: the tester knows where the trust lines are and which flows are considered critical. In turn, findings from pentest and vulnerability management return to the model and update it. These are complementary layers: modeling works “to the left” (at the design stage), testing - “to the right” (on the working system).

It is also worth noting that some of the STRIDE threat classes map directly to OWASP Top 10 - privilege escalation is Broken Access Control, information leakage is often Security Misconfiguration or Cryptographic Failures. Modeling helps catch them before they become code.

A new dimension: threats in AI systems

With the implementation of language models, threat modeling gains a new layer. Classic STRIDE must be supplemented with AI-specific threats: prompt injection, data leakage through the RAG context, redundant agent privileges. The boundaries of trust lie in non-obvious places - the content of the document read by the model becomes a potential attack vector. We write about it in more detail in the article AI security in the company.

Summary

Threat modeling is the cheapest security investment you can make - because it operates at a stage where a patch costs minutes, not an emergency deployment. It does not require expensive tools: just a diagram, the STRIDE method and the discipline of asking four questions. The key is regularity and focus on the boundaries of trust.

If you are designing a system that will process sensitive data and want to conduct threat modeling with security practitioners - or verify the finished design - let’s talk. Consulting in the design of security architecture is one of the areas in which we support IT and development teams.

Frequently asked questions (FAQ)

Does threat modeling require specialized tools? No. These can be done on a whiteboard, in a document, or in a free diagramming tool. There are dedicated applications (e.g. for STRIDE), but it is the method and discipline of asking questions, not the tool, that determine the value. A team starting out will benefit more from a simple whiteboard session than from expensive software.

Who should attend a modeling session? Preferably a combination of perspectives: an architect or developer who knows the system, someone with security knowledge, and someone who understands the business context. Developers know the system best, but may be blind to attack vectors - which is why it’s valuable to have someone who thinks like an attacker.

What is the difference between threat modeling and risk analysis? Threat modeling is technical and specific - it deals with a single system and its architecture. Risk analysis operates at a higher level of organization and processes. They complement each other: threat modeling provides detailed threats that feed the organizational risk assessment.

Is it worth modeling threats to an existing, working system? Yes. Although it provides the greatest value at the design stage, a model of a working system organizes knowledge about its weak points, directs tests and helps prioritize corrections. This is a good starting point before planning your pentest.