A vulnerability discovered in production requires two simultaneous costs. The technical remediation cost, which in established architecture may require significant redesign. And the user impact cost, which in financial or healthcare systems carries regulatory consequence. Both are avoidable when the threat is identified before any code is written. The design stage is when changing a security decision costs a conversation, not a sprint of rework.
Subcapability 02 of 04 · Security Engineering
Threat Modeling
STRIDE and attack trees in design that identify threats before any code exists, eliminate forced redesign from production vulnerabilities and embed risk into architectural reasoning.
What is at stake
The team designed the partner integration without mapping what happens when the token is stolen. They discovered it in production, with a customer affected and a mandatory incident notification. Every architectural decision that ignores potential threats defers the cost of security to the moment of maximum impact.
What it is, in practice
How we work
STRIDE applied in design
We facilitate threat analysis using the STRIDE framework during the design of each critical feature and each integration with external systems. Each threat category, Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege, is systematically considered before any implementation decision.
Data Flow Diagrams with trust boundaries
We build data flow diagrams with explicit trust boundaries that make visible every point where data crosses a trust perimeter. Implicit assumptions about who can access what become explicit decisions with associated controls.
Attack trees for mitigation prioritization
We map plausible exploitation paths as attack trees that combine probability of execution with business impact. The result is a prioritized list of mitigations where investment goes where real risk is concentrated, not where the team has the most familiarity.
MITRE ATT&CK as adversary reference
We use MITRE ATT&CK to ground threat hypotheses in tactics and techniques observed in real attacks against similar organizations. Threats based on real adversary evidence take priority over theoretical threats that have never been observed in production.
Living threat model integrated into the SDLC
We establish a threat model review process at each relevant architectural change, integrating the analysis into the normal design review cycle rather than treating it as a separate event. The model grows with the system, capturing threats introduced by each new feature.
Measurable gains
What changes in the result when this subcapability matures.
Security issues identified before implementation begins
A threat identified in design has a mitigation cost equivalent to adjusting a diagram or adding a control to the backlog. The same threat discovered in production requires redesign, emergency remediation and user impact management.
Percentage of critical systems with an updated threat model
Systems with an active threat model have a documented attack surface and mapped controls. Systems without a threat model have an unknown attack surface. The difference shows in response time to each new published threat.
Forced architectural redesign cost from production vulnerabilities
An architectural decision that introduces a vulnerability costs, in design, a thirty-minute conversation. In established production, it costs a redesign sprint, a migration sprint and a testing sprint. Threat modeling eliminates the most expensive category of security decision.
Average time between architectural change and associated threat review
With a process integrated into the design review cycle, the threat model is reviewed in the same week the architectural change is discussed. Without a process, the review happens at the pentest, months later, at maximum remediation cost.
Frequently asked questions
Who should conduct threat modeling: the security team or the product team?
The most effective threat modeling is conducted collaboratively. The product team knows the domain and use cases. The security team knows attack patterns. Security Champions in squads are the bridge that makes this process scalable without depending on a centralized specialist for each feature. The result of collaboration is a threat model that covers both technical threats and threats specific to the business context.
How frequently should the threat model be updated?
Each relevant architectural change justifies a review: new integration with an external system, new personal data flow, change in the authentication model, new public endpoint. Systems that do not change may have a semi-annual review. Systems in active development should have a review at each significant design sprint. The criterion is change in attack surface, not calendar.
How to choose between STRIDE and PASTA for threat modeling?
STRIDE is more suitable for teams starting with threat modeling: the six-category structure is direct and applicable to any type of system. PASTA adds business impact analysis and attack scenario simulation, making it more suitable for systems with high direct financial or regulatory risk exposure. For most contexts, STRIDE with MITRE ATT&CK as an adversary reference covers the necessary spectrum.
What is MITRE ATT&CK and how does it help in threat modeling?
MITRE ATT&CK is a knowledge base of tactics and techniques used by real adversaries, organized by attack phase. In threat modeling, ATT&CK helps ground threat hypotheses in observed adversarial behavior rather than generic theoretical threats. For each system, it is possible to identify which techniques from the matrix are relevant given the most likely adversary profile, making the analysis more precise and prioritized.
Does threat modeling apply only to new systems or also to legacy systems?
It applies to both, with different approaches. For new systems, threat modeling occurs during design. For legacy systems, it starts with a current-state threat model that maps the existing attack surface, identifies present and absent controls, and prioritizes remediation by risk. Many organizations discover, in their first threat model of a legacy system, threats that existed for years without associated controls.
Other subcapabilities in this capability
Shift-Left Security
SAST, DAST and SCA integrated into the CI pipeline that reduce correction cost by an order of magnitude and eliminate the annual pentest as the only line of defense.
Compliance as Code
Open Policy Agent with NIST 800-53 controls as code that transform regulatory requirements into continuously verifiable properties and eliminate the pre-audit sprint assembled on the eve of every certification.
Security Champions Program
OWASP SAMM-structured Security Champions network that distributes security capability across squads, eliminates the central team bottleneck and multiplies protection without multiplying headcount.
Want clarity on where to invest first?
A complete technology capability assessment with an evolution roadmap connected to financial result.