712-50 Question 357
Single answerThreat modeling principles, methodologies, techniques and simulationsA global financial services company is launching a new customer onboarding platform that uses web, mobile, API, and third-party identity verification components. The CISO wants a threat modeling approach that can be repeated across product teams, helps identify trust boundary issues early in design, and produces outputs that can be directly prioritized for remediation and validation through later security exercises. The organization has limited time with senior architects, so the method must be structured and practical rather than purely brainstorming-based. Which approach would BEST meet these objectives?
- A
Use a STRIDE-based threat modeling workshop centered on data flow diagrams to identify threats by component and trust boundary, then map findings to risk treatment and targeted validation scenarios
- B
Rely primarily on an annual red team exercise after deployment, since live attack simulation provides more realistic findings than design-stage analysis
- C
Adopt a vulnerability scanning program during system testing, because scanner results provide a complete list of threats without requiring architectural input
- D
Use only MITRE ATT&CK techniques to enumerate adversary behaviors, without modeling the application architecture or data flows
- E
Conduct an informal brainstorming session with developers and record any security concerns, avoiding formal methods so teams can move faster
Show answer and explanation
Correct answer: A
Explanation
The best answer is the structured STRIDE-plus-DFD approach because it aligns with core threat modeling principles: understanding the system, decomposing the architecture, identifying assets and trust boundaries, systematically enumerating threats, and supporting risk-based treatment. STRIDE is widely used for application and system threat modeling because it gives teams a repeatable way to examine spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege across architectural elements. Data flow diagrams are especially useful for identifying where data crosses trust boundaries, which is critical in platforms involving web, mobile, APIs, and third-party services.
From a CCISO perspective, the key leadership consideration is selecting a methodology that is scalable, repeatable, and actionable across teams. The chosen method should also produce outputs that can feed simulations and assurance activities. For example, identified threats can become abuse cases for secure design review, test cases for application security assessments, and objectives for tabletop, purple-team, or red-team validation. This is consistent with common industry guidance from sources such as OWASP Threat Modeling materials, Microsoft Threat Modeling guidance around STRIDE and DFDs, and NIST secure development and risk management practices that emphasize early identification of design risk and ongoing validation. In contrast, red teaming, vulnerability scanning, and ATT&CK-based analysis are valuable complementary techniques, but they are not by themselves the best primary methodology for early, repeatable, architecture-focused threat modeling.
- A. Correct.
Correct. A STRIDE-based approach applied to data flow diagrams (DFDs) is a well-established, structured threat modeling method for identifying threats across processes, data stores, data flows, external entities, and especially trust boundaries. It is practical for product teams because it is repeatable and can be integrated early in the SDLC. The resulting threats can then be prioritized using risk criteria and translated into validation activities such as abuse cases, penetration test objectives, tabletop scenarios, or purple-team exercises. This directly supports the CISO's need for consistency, early identification, and downstream remediation and testing.
- B. Incorrect.
Incorrect. Red teaming is valuable for validating defenses and simulating realistic adversary behavior, but it is not a substitute for design-stage threat modeling. Waiting until after deployment is more expensive, misses the opportunity to address architectural weaknesses early, and does not provide a repeatable methodology for all product teams. This option reflects the common misconception that simulation alone can replace systematic architecture-based analysis.
- C. Incorrect.
Incorrect. Vulnerability scanning is useful for discovering known technical weaknesses in implemented systems, but it does not provide a complete view of threats, especially business logic abuse, trust boundary failures, authentication design flaws, or risks introduced by third-party integrations. Scanners are an important control, but they are not a threat modeling methodology and cannot replace architecturally informed analysis.
- D. Incorrect.
Incorrect. MITRE ATT&CK is a strong knowledge base for adversary tactics and techniques and is highly useful for threat-informed defense, emulation, and detection engineering. However, using ATT&CK alone without modeling the application's components, assets, entry points, and trust boundaries would not adequately address the CISO's need for structured, design-phase analysis. ATT&CK complements threat modeling; it does not replace it.
- E. Incorrect.
Incorrect. Informal brainstorming may identify some issues quickly, but by itself it is less repeatable, more dependent on participant experience, and more likely to miss systematic categories of threats. In a large organization seeking a consistent practice across product teams, purely informal methods usually produce uneven results and weaker traceability to remediation and later validation exercises.