Application Threat Modeling: Build Risk-Based Threat Models with PASTA Application Threat Modeling: Build Risk-Based Threat Models with PASTA

Home  |  Offerings  |  AppSec  |  Application Threat Modeling

Application Threat Modeling

Helping Clients Learn & Build Risk-Based Threat Models

category icon

Apply a Risk-Based Approach to Threat Modeling

Modeling your application for threats helps to preemptively address security within your software development lifecycle. There's more to threat modeling than mapping a handful of threat categories to your application and building a data flow diagram. Learn how we can tailor the PASTA approach to fit your development timelines and maximize the output of application threat models.

Why PASTA (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.

Threat Modeling with PASTA

The 7 Stages of PASTA:

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

Identifies 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.

Inputs/Outputs to the PASTA Threat Modeling Methodology

Some of the inputs/outputs to PASTA are shown below:

Input

  • Business requirement documents
  • Functional requirement documents
  • Information security policies
  • Regulatory compliance documents
  • Security standards & guidelines
  • Data classification documents

Stage

1

Define the Objectives

Define Business Objectives

Define Security Requirements

Define Compliance Requirements

Perform Preliminary Business Impact Analysis (BIA)

output

  • Description of the application functionality
  • List of business objectives
  • Definition of the application security and compliance requirements
  • Business impact analysis report

Input

  • High level design documents
  • Sketches from white-board exercises
  • Network diagrams
  • Logical and physical architecture diagrams
  • Software and technical specifications

Stage

2

Define the Technical Scope

Capture the Application Boundaries

Identify the Application Dependencies From Network Environment

Identify the Application Dependencies from Servers -Services Infrastructure

Identify the Application Dependencies from Software

output

  • High level, end-to-end view of the application architecture
  • List of all protocols and the type of data
  • List of all the application servers/services
  • List of all hosts and servers and type of software/technology dependencies
  • List of all network devices/appliances

Input

  • Architecture diagrams-design documents
  • Sequence diagrams
  • Use cases
  • Users, roles and permissions
  • Logical diagrams
  • Physical-network diagrams

Stage

3

Decompose the Application

Data Flow Diagramming & Trust Boundaries

Identify Users & Actors, Roles and Permissions

Identify Assets, including Data as well as Hardware and Software

Identify Data Entry Points and Trust levels

output

  • Data flow diagrams
  • Access control matrix
  • List of assets including data and data sources, classification and trust levels
  • List of interfaces and trust levels
  • Mapping of use cases with actors and assets

Input

  • Threat agents and motives
  • Security incidents (SIRT) report
  • Fraud detection report
  • Secure incident event monitoring (SIEM) reports
  • Application and server logs
  • Threat intelligence reports

Stage

4

Analyze the threats

Analyze Probabilistic Scenarios

Analyze Security Incident Reports and Fraud - Case Management Reports

Analyze Application and System Logs For Security Incidents and Fraud Cases

Correlate Security Incidents and Fraud with Threat Intelligence Source-Feeds

output

  • Attack scenario-landscape report
  • List of threat agents and attacks vector
  • Report on incidents-events relevant to the likelihood of threats and attack scenarios
  • Correlation to threat intelligence reports for the likely attack scenarios

Input

  • Library of threat trees
  • Attack scenarios (from Stage IV)
  • Vulnerability assessment reports
  • Standards for vulnerability enumeration (MITRE CWE, CVE)
  • Standards for vulnerability scoring (CVSS,CWSS)

Stage

5

Vulnerabilities & Weaknesses Analysis

Correlate Vulnerabilities to Assets

Map Threat-Attacks to-Vulnerabilities Using Threat Trees

Map Threat To Security Flaws Using Use and Abuse Cases

Enumerate and Score Vulnerabilities

output

  • Map of existing vulnerabilities to the nodes of a threat tree
  • Enumeration of these vulnerabilities using CVE-CWE
  • Scoring of these using CVSS-CWSS list of threats-attacks-vulnerabilities

Input

  • Application Technical Scope (Stage II)
  • Application Decomposition (Stage Ill)
  • Attack libraries-patterns
  • List of threats, attacks and vulnerabilities to the application assets (Stage V)

Stage

6

Model The Attacks

Identify Application Attack Surface

Derive Attack Trees For Threats and Targets-Assets in Scope

Map Attacks and Attack Vectors To Nodes of Attack Trees

Identify Exploits and Attack Paths Using Attack Trees

output

  • Application attack surface
  • Attack trees with attack scenarios fo targeted assets
  • Attack tree mapping to vulnerabilitie for impacted assets
  • List of possible attack paths to exploits including the attack vectors

Input

  • Preliminary BIA (Stage I)
  • Technical scope (Stage II)
  • Application decomposition (Stage III)
  • Threat analysis (Stage IV)
  • Vulnerability analysis (Stage V)
  • Attack analysis (Stage VI)
  • Mapping of attacks to controls
  • Technical standards for controls

Stage

7

Risk and Impact Analysis

Quality and Quantity Business Impact

Identify Gaps in Security Controls / Countermeasures

Determine Residual Risks and Impacts

Identify Risk Mitigation Strategies

output

  • Application risk profile
  • Quantitative and qualitative risks repo
  • Threat matrix with threats, attacks, vulnerabilities, business impact
  • Residual risk to business
  • Risk mitigation strategy-option

PASTA as a threat modeling framework is adopted and used by worldwide organizations today. Allow us to tailor a PASTA application threat model for your application so you can effectively apply the risk-centric methodology within the regiment of their software security assurance process.

Key Characteristics of PASTA – Risk-Centric Threat Modeling

If you’re wondering what key characteristics make PASTA unique, they are the following:

1. It is a Methodology

If you’re looking for a process to follow, PASTA is designed for that. With seven phases with underlying activities in each phase, this approach is intended to guide new and experienced threat modelers across risk-centric application threat modeling activities.

2. Risk-Focused

PASTA not only looks at the variables of threat, vulnerability, countermeasures, and impact. Most importantly, it considers the probability of each variable and other supporting qualities like threat motives, current threat evidence, and countermeasure effectiveness.

3. Collaborative

Most threat modeling exercises simply include an audience of developers. This is a limited approach since developers depend on design, underlying infrastructure, managed corporate services (e.g. SSO, IAM, PKI, etc.), and the configuration of open frameworks. For this reason, architects, DevOps team members, systems engineers, business analysts, and SOC team members are also good candidates for collaborative threat modeling discussions under PASTA.

4. Prescriptive

In the end, PASTA is focused on providing prescriptive guidance on the exploitable vulnerabilities that are of greater priority. The last phase, residual risk analysis, focuses on addressing security countermeasures to non-accepted application risks and providing remediation alternatives, all depending on the team’s risk impact considerations, threat likelihood, and cost of countermeasure implementation.

5. Evidence-based

Concrete evidence around quantitative business impact values, threat information driven threat assertions, and attack trees with probability values on each branch help to denote threat likelihood.

6. Maturity Modeling Integration

Whether you have never done threat modeling before or are a team of security champions, the activities defined within each phase of PASTA can correlate to both BSIMM and OpenSAMM maturity models for secure software development programs. Inquire more on how you can track maturity over time with PASTA and these maturity models.

7. Pre-emptive Compliance

PASTA considers technical requirements for applications as part of its first stage since non-compliance can affect product assurance towards varying regulatory requirements.

Let us build a tailored engagement for you.

We are an international squad of professionals working as one.

logos