1. Define Business Context of Application

This considers the inherent application risk profile and address other business impact considerations early in the SDLC or for given Sprint under Scrum activities.

2. Technology Enumeration

You can’t protect what you don’t know is the philosophy behind this stage. It’s intended to decompose the technology stack that supports the application components that realize the business objectives identified from Stage 1.

3. Application Decomposition

Focuses on understanding the data flows amongst application components and services in the application threat model.

4. Threat Analysis

Reviews threat assertions from data within the environment as well as industry threat intelligence that is relevant to service, data, and deployment model.

5. Weakness / Vulnerability Identification

dentifies the vulnerabilities and weaknesses within the application design and code and correlates to see if it supports the threat assertions from the prior stage.

6. Attack Simulation

This stage focuses on emulating attacks that could exploit identified weaknesses/vulnerabilities from the prior stage. It helps to also determine the threat viability via attack patterns.

7. Residual Risk Analysis

This stage centers around remediating vulnerabilities or weaknesses in code or design that can facilitate threats and underlying attack patterns. It may warrant some risk acceptance by broader application owners or development managers.

Process for Attack Simulation & Threat Analysis
The Risk-Centric Threat Modeling Methodology

VerSprite leverages our PASTA (Process for Attack Simulation & Threat Analysis) methodology to apply a risk-based approach to threat modeling. This methodology integrates business impact, inherent application risk, trust boundaries amongst application components, correlated threats, and attack patterns that exploit identified weaknesses from the threat modeling exercises. Prior to PASTA, most application threat models were not even considering actual threats.

As the name implies, a key goal for threat modeling is to do just that – model threats. Threat categorization mnemonics (like STRIDE) are helpful for beginners, but product managers and their superiors are eager to know which threats are topical to their business, product, and platform. Furthermore, limiting threats to a handful of categories may not include the actual threats adversarial groups are planning.

PASTA provides a risk-centric threat modeling approach that is evidence-based. VerSprite’s security experts correlate real threats to your attack surface of application components and identify risk by first understanding the context of what the software or application is intended to do for the business or its clients. We also conduct exploitation tests that support threat motives within the model to validate whether they are probabilistic. Correlating viability with sustained impact allows this methodology to resonate as a highly effective risk-focused threat modeling approach.

Applying PASTA to Penetration Testing

The use of PASTA and VerSprite’s Threat Modeling methodology will guide the ensuing penetration test exercise, which can be performed in different ways depending on the approach to take and how much information is to be shared during the testing. The best way to see this is as follows:

• Blackbox Application Penetration Testing takes a DAST (Dynamic Application Security Testing) approach and assumes no prior information is provided about the target. With this type of approach, VerSprite attempts to simulate an attack by a threat that would have little to no insight into the environment or application architecture.

• Whitebox Application Penetration Testing takes a SAST (Static Application Security Testing) approach where the source code of the application is provided for its review. Depending on the size of the application, this can be time consuming, but if performed along with an application threat model, this could be the way to go if you are looking to find as many issues as possible and understand if secure development best practices are being followed. If a test environment is available during the exercise, every finding can be validated dynamically to provide a better Proof of Concept that shows the real impact of exploiting the vulnerability

• Greybox Application Penetration Testing takes a DAST approach, and credentials are provided to perform authenticated testing. Additional documentation can be shared around the environment and architecture of the application to help in understanding its inner working and how the different components work together. If the source code of the application is also provided in order to support the testing, the Application Pentest takes a mixed approach between dynamic and static analysis instead. This Greybox approach allows for combining the convenience of DAST with the depth of analysis provided by SAST, which not only saves time during dynamic testing but also enables the possibility of going deeper in the review of critical functions to the business.