Guest article
How to Enhance Your Pentest Using Threat Modeling
Introduction
Before we go into how a threat model can help you get more value from a security penetration test (pentest), let me provide some context and purpose. This article is based on my experience as a former professional requesting pen tests and utilizing their outcomes to ensure security assurance and requirements. Additionally, I have introduced threat modeling at my current company and continuously develop, evolve, and embed it into our security and development processes.
I hope this article will inspire you to harness the strengths of both tools to maximize the return on investment in pentesting and threat modeling.
Pentesting
How can you ensure your application withstands a hacker’s attack? How far should you go to protect it, and is it worth the time, effort, and money? Pentesting is a powerful tool to assess how well-protected you are against attacks. However, there are challenges in conducting pentests and utilizing their results effectively:
- Limited or Unclear Scope: An ambiguous scope can lead to bias and a narrow focus on specific attack vectors, creating blind spots and resulting in missed vulnerabilities or false negatives.
- Misinterpreted Reporting: Issues reported solely based on “ease of exploitation” can lead to findings being misjudged as more critical (false positives) or less critical (false negatives) than they actually are.
- Cost and Resource Intensity: Pentesting is expensive and requires time, expertise, and resources. Given the costs, it is crucial to maximize its value.
- Unrelatable Test Report: Reported test results are not relatable to the business value of the application. The severity of the findings can be rejected because of this mismatch. The absence of business context hinders the creation of clear priorities for the application’s responsible parties.
- Compliance-Driven Testing: Performing tests just because they are regulatory requirements can deprioritize potentially vulnerable applications. Skipping or delaying such tests requires specialist knowledge and clear rationale, especially in regulated sectors like finance.
Threat Modeling
Assuming you’re already familiar with threat modeling, let’s focus on how we position and perform it. Our practice uses threat modeling as a mandatory activity for teams managing applications of specific classifications. Governance ensures these applications maintain up-to-date threat models.
We use STRIDE-by-component, where components include data, technical elements, and processes. To guide the interaction between development teams and security specialists, we rely on Adam Shostack’s four questions:
- What are we doing?
- What can go wrong?
- What are we going to do about it?
- Did we do a good job?
Our process comprises four steps: intake, brainstorming, handover, and testing/review.
Threat Modeling and Pentesting
Pentesting integrates with the fourth step of threat modeling (testing and review), but there are additional opportunities to share information and integrate the two tools throughout the process. Using the mentioned process steps of intake, brainstorm, handover, review, and testing, we will answer the four questions and place the Threat Modelling and Pentest instruments side by side to solve the challenges mentioned above.
Intake
What Are We Doing?
- Threat Modeling: Define the service, solution, or product being analyzed, understanding its purpose and business value. Create data flow diagrams detailing components, data classifications, and connections.
- Pentesting: Use this information to scope the pentest. Understanding the business context allows for the creation of an effective test plan. Adding data value, flow, component purpose, and interfaces enables clear objectives for the test, identifying the targets.
As a result, the scope will align application value, attacker targets, and the technology in use, solving the challenge of “Limited or Unclear Scope.”
Brainstorm & Handover
What Can Go Wrong?
- Threat Modeling: Identify and categorize threats using STRIDE. Place threats in categories with targets, descriptions or methods, actors, and severity. This serves as a technical reflection and translation of business concerns and risks.
- Pentesting: These threats provide testers with a detailed understanding of where the targets reside. Testers will understand the undesired effect of the threat and its severity, supporting the design of the attack vector and plan.
“What would the attacker seek to achieve?”
What Are We Going to Do About It?
- Threat Modeling: Collaborate with developers to assess feasibility, cost, and effort for implementation. Develop countermeasures as actionable security requirements.
- Pentesting: Leverage the defined countermeasures to tailor attack plans. Pentesters can focus on potential vulnerabilities rather than redundant testing, saving time and resources. Efforts focus on simulating real-world attacker techniques effectively. Additionally, the countermeasures’ performance and effectiveness are tested.
Gathering information from the brainstorming session, the threats and countermeasures address the following challenges:
- Misinterpreted Reporting: Findings related to the target, its value, and threat severity from the threat model. This helps contextualize any additional threat vectors or attack methods.
- Cost and Resource Intensity: With known threats and undesired effects, an efficient test plan can be created. Testers can focus on how these threats might be successful. The test will still cost the same, but the return on investment will be improved.
Review and Testing
Did We Do a Good Job?
- Pentesting: Report findings and relate them to the target in the identified threats and their countermeasures. Describe the severity of findings that are aligned with the threats and their severity. New threats can be related to an undesired effect based on the value of the target, impact, and ease of exploitation.
- Threat Modeling: Review the threat model using pentest results and findings. The report will introduce new threats with relatable and more accurate severity, leading to the design of new countermeasures. These countermeasures can then be prioritized more effectively.
This approach solves the challenge of an “Unrelatable Test Report”. Using threat modeling results creates a report that businesses relate to. New threats or attack methods not identified in the threat model ensure application responsible parties are aware of them.
Compliance-Driven Testing
The problem of compliance-driven testing cannot be solved through individual threat models and their aligned pentests.
In industries with considerable IT security oversight, compliance will always drive pentesting. Threat models can help create a threat-based rationale for the prioritization of pentests. The following criteria should be in place:
- High Data Quality and Consistency: Capture threats and countermeasures in a structured, consistent, and complete manner. Include metadata like data classification, severity, alignment with internal controls, and service.
- Linking Threat Models: Applications in one threat model may represent part of an end-to-end process for a service, product, or solution. Connecting these using a nesting or linking technique provides more contextual knowledge about threats. It shows attack vectors as part of lateral movement from a low-value application to a high-value target in another application, enabling testing prioritization of overlooked applications.
Conclusion
Integrating threat modeling and pentesting can significantly improve the effectiveness and efficiency of security processes. By aligning these tools, organizations can create a seamless workflow where threat models inform pentests, and pentests validate or refine threat models. This synergy addresses common challenges such as unclear scopes, misinterpreted findings, and cost inefficiencies.
Incorporating threat modeling early in the development cycle—such as during the “Plan” phase of a DevOps workflow—ensures that pentests are scoped effectively and produce actionable insights. This approach fosters continuous improvement, aligning security efforts with business priorities and delivering more meaningful results.
The integration of these methodologies not only improves outcomes but also inspires confidence in security processes. While challenges remain in determining when to conduct pentests for a large volume of applications, structured approaches, better tools, and consistent data integration pave the way for scalable solutions. Use this framework as a starting point to explore how combining pentesting and threat modeling can transform your security practices.
Final Note
The described approach reflects our practices and is meant to inspire, not instruct. Adapt what resonates with your context and experiment with integrating pentesting and threat modeling for improved security outcomes. I consider creating a mapping table between the processes, if it does not yet exist.
