Threat Modeling - Identifying Risks by Design

About 2 min read

Threat modeling is a security design methodology that systematically identifies potential threats to a system or application at the design stage, prioritizes them, and applies countermeasures. By structurally analyzing "what to protect," "who the attackers are," and "where the weaknesses lie," it can dramatically reduce security defects discovered in later development phases. The cost of fixing a vulnerability after it is found in production is said to be 30 to 100 times that of the design stage, making threat modeling a highly cost-effective preventive measure.

Historical Background

The concept of threat modeling began in the late 1990s when Microsoft systematized it as part of its internal Security Development Lifecycle (SDL). After the 2002 "Trustworthy Computing" declaration, Microsoft incorporated threat modeling as a mandatory process in the development of Windows and Office, and published its results as the STRIDE model. Since then, OWASP and NIST have also adopted threat modeling into their respective frameworks, establishing it as an industry-standard design methodology.

The STRIDE Model

STRIDE is a threat classification framework developed by Microsoft, formed from the initials of six threat categories.

DREAD Scoring

After classifying threats with STRIDE, DREAD quantitatively assesses the severity of each threat. It scores five items, each on a scale of 1 to 10: Damage (the magnitude of harm), Reproducibility, Exploitability (the ease of attack), Affected Users (the number of users impacted), and Discoverability (the ease of discovery), then determines priority by the total score. However, DREAD has been criticized for being prone to subjective evaluation, and Microsoft itself now recommends using it together with CVSS (Common Vulnerability Scoring System).

The PASTA Framework

PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage framework that analyzes business risks and technical threats in an integrated manner. It starts with defining business objectives, then proceeds to identifying the technical scope, application decomposition, threat analysis, vulnerability analysis, attack simulation, and risk and impact analysis. Whereas STRIDE is a classification tool for engineers, PASTA is characterized by functioning as a common language between management and engineers.

Data Flow Diagrams and Trust Boundaries

At the core of threat modeling is the data flow diagram (DFD). It visualizes the flow of data within a system and makes the trust boundaries explicit. A trust boundary is the dividing line between regions with different security levels, such as the boundary between the internet and an internal network, or between the application layer and the database layer. Because the attack surface concentrates on these trust boundaries, each STRIDE threat is examined for every data flow that crosses a boundary.

Integration into the Development Lifecycle

Threat modeling is not a task confined to the design phase alone. In agile development, the threats of new features are assessed every sprint, and the existing threat model is updated. An approach that incorporates SAST (static analysis) and DAST (dynamic analysis) into the CI/CD pipeline to automatically verify whether the risks identified in the threat model are addressed at the implementation level is also spreading. The ideal cycle is to plan a defense-in-depth design at the threat modeling stage and verify its effectiveness through red team exercises.

The Record That Has to Remain Afterwards

What makes the practical difference is less the work of listing threats than whether the result can be used later. One point is how the items decided against are handled. Of everything that was drawn up, only some will actually be worked on; the rest are set aside on grounds such as the impact being small, the conditions for it to occur not coming together, or the cost not being warranted. If that decision to set something aside is not recorded, then the next time the same area is considered there is no way to tell that a decision was ever made. Either the same discussion is repeated or, the other way round, only the memory that it was already considered remains, with no way to check the grounds. What should be kept is not a list of items but the reason each was set aside and the conditions assumed at the time. The second point is those assumptions themselves. Analysis of this kind always treats something as trustworthy. Only by positing that traffic over a given stretch is protected, that a given process is called only from inside, or that a given value has already been checked upstream does the range to be examined become finite. When an assumption changes, the conclusions resting on it change with it. This is the part affected when some component is replaced by an outside mechanism or when the number of callers grows, but if the assumptions are not written down there is no way to identify which conclusions need revisiting. The third point is the drift that arises between the diagram and the implementation. A diagram is a copy of the design as it stood when it was drawn, and if the implementation moves ahead the diagram alone becomes out of date. Being out of date does not show up in the diagram itself, so unless a trigger for updating is placed on the side of the work, examination proceeds from a diagram that looks correct.

We explain building an organization's security posture in detail in the startup security checklist, designing a password policy in the corporate password policy article, and ransomware countermeasures in the ransomware protection article.