Research Library / Case Studies /

Cybersecurity Services / SaaS (Pentesting-as-a-Service)

Securing the Digital Realm of a Pentesting-as-a-service Provider with Threat Modeling

A well-recognized pentesting-as-a-service platform wanted to know exactly where its own risk was hiding before its customers found out. Payatu ran a STRIDE- based threat modeling exercise across five core modules and surfaced 24 threats the client didn't know it had.

Threat Modeling

At a glance

INDUSTRY

Cybersecurity Services / SaaS (Pentesting-as-a-Service)

CLIENT PROFILE

Well-recognized pentesting-as-a-service platform

SERVICES

Threat Modeling

ENGAGEMENT

STRIDE-based threat modeling across five platform modules

key Numbers

24

Threats and Vulnerabilities Identified

14

Existing Controls Already Mitigating Known Threats

10

New Control Recommendations Delivered

Key Takeaways

Client – A well-recognized platform that offers pentesting-as-a-service to its own customers.

Problem – The client had general security controls in place but no clear, structured picture of the threats and threat agents facing its platform, including client onboarding, scan scheduling and attack surface management modules.

What Payatu did – We ran a STRIDE-based threat modeling exercise, building data flow diagrams and a threat model diagram in the Microsoft Threat Modeling Tool to identify, rank and map threats across the platform's five core modules.

Outcome – We identified 24 threats and vulnerabilities, confirmed that existing controls already mitigated 14 of them, and delivered 10 new control recommendations to close the rest.

the challenge

Why the client called us in

As a platform that sells pentesting-as-a-service to its own customers, the client held itself to a higher bar for its own security. It had general controls in place but no structured, prioritized view of the threats facing modules like client onboarding, reporting automation and attack surface management, and no clear plan for which risks to close first. The client brought in Payatu to proactively identify threats and define countermeasures before those gaps could be exploited.

Identify all potential threats and vulnerabilities across the platform
Prioritize threats by risk to guide a mitigation roadmap
Determine which existing controls already covered identified threats and where new ones were needed

scope of engagement

What was in scope

To perform threat modeling of modules of the portal
To identify all potential threats and vulnerabilities to the platform

Our Approach

How Payatu ran the engagement

01

Scoping, Objective Finalization and Application Overview

We understood the client's security objectives, finalized scope and architecture type, and mapped user roles, data elements and technologies in use.

02

Methodology Decision

Based on that understanding, we selected the STRIDE framework, covering spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.

03

Application Decomposition

We decomposed the application, generated context and scenarios, and mapped trust levels, trust boundaries, and entry and exit points.

04

Data Flow Diagram Generation

We built data flow diagrams showing how data moves through the application end to end, to identify affected components at each critical point.

05

Threat Model Diagram Development

Using the Microsoft Threat Modeling Tool, we visualized system components, data flows and security boundaries, and defined identified assets, existing controls and threat agents.

06

Threat Identification

Applying STRIDE, we identified and ranked all potential threats by risk to build a prioritized mitigation list.

07

Countermeasure and Mitigation Determination

For each threat, we checked for existing countermeasures and identified new ones where gaps remained, classifying threats as non- mitigated, partially mitigated or fully mitigated.

Key findings

What we found

HIGH

Elevation of Privilege on Backend Web Server

An internal authorized user's Redis credentials could be used to escape the Docker container and gain access to the host system, with no existing security controls in place.

HIGH

Denial of Service on MySQL Database

Both internal and external users, authorized or not, could trigger a denial of service against the MySQL database with no existing controls to stop it.

HIGH

Sensitive Data Exposure via AWS S3 Bucket

An internal authorized user could read sensitive data, including report proof-of-concept files, directly from the AWS S3 bucket.

the outcome

Results and Impact

Before the engagement, the client had 14 general controls in place but no clarity on the threats those controls were actually stopping or missing. The threat modeling exercise gave the client a complete, STRIDE-categorized view of its risk, confirming which of its 24 identified threats were already mitigated and which needed new controls.

‍