A PASTA Threat Modeling Example

In this article, I’m going to provide a PASTA threat modeling example. PASTA stands for Process for Attack Simulation and Threat Analysis (PASTA). It is a risk-centric threat modeling method developed by Tony UcedaVélez and Marco M. Morana from VerSprite.

I wrote about a threat modeling example using the STRIDE method, it’s similar in style, but the difference is in the threat modeling method used. Another similar article I wrote describes many different examples of STRIDE threats. Many of the STRIDE threats can also be used in PASTA threat modeling (but must be applied differently).

A Short Description of PASTA Threat Modeling

PASTA is an in-depth threat modeling method. It has 7 distinct stages that look into different aspects of the application (to be threat modeled), the background of the application and how it fits within a business, the application itself, and the threats that may apply (this is threat modeling after all), the potential mitigations (or countermeasures), and more.

Here are the 7 stages of PASTA threat modeling:

1. Define the Objectives
2. Define the Technical Scope
3. Decompose the Application
4. Analyze the Threats
5. Vulnerability Analysis
6. Attack Analysis
7. Risk and Impact Analysis

The output of early stages feeds as input into the later stages.

Want to learn more about PASTA? Read it here! And also read about how PASTA works well in DevOps.

The Example Business and Application Case to be Threat Modeled using PASTA

The example business case, for our PASTA threat modeling example, consists of:

• Company and industry: Health care insurance provider, within the health care and insurance industry.
• Object in the scope of threat modeling: The company is in the process of developing a new web application called ‘MyHealth’. It will allow customers to view their medical data, billing, appointments with healthcare providers, and potential deals that customers can purchase.
• Scoping limitations: Currently, the business processes related to the MyHealth application are not in scope.
• Tech stack of the application: The MyHealth web application will be cloud-based, hosted in Azure, and will have a Javascript framework front-end.
• Team: Various DevOps teams are involved in the project, as well as business driving the transformation to provide as many health insurance services through the newly developed MyHealth application.

Note that this development will connect to various parts of the IT landscape which is considered legacy, and thus not in the scope of the current threat modeling case.

The above is meant to provide you with a general idea of the business case, development environment, and tech stack used in this PASTA threat modeling example.

How I Proceed with the PASTA Threat Modeling Example

I’m going to follow the 7 PASTA threat modeling stages using the example business and application case described above. In each stages I’ll recap what the result is.

Stage 1: Define the Objectives

What’s needed in this stage:

• Define the business objectives of the application or program.
• Define the security and compliance requirements.
• Define business impact (i.e., through a Business Impact Analysis).
• Define the risk profile.

The business objectives: The business objective of this project is to create a new web application that allows customers to interact with the main company service (which is health care insurance). In 2020 and beyond customers expect their customer details at their fingertips instantly, on any device (laptop, tablet, smartphone, etc.). And they expect the user experience to be top-notch. Customers expect all data to be accessible (so billing, medical procedures, doctor consultations, etc.).

The security and compliance requirements:

• Overall, the absolute highest security requirements are expected, given that the data involved relates to health data.
• The most important security and compliance requirement is adhering to HIPAA (The Health Insurance Portability and Accountability Act). Other countries, outside of the USA, have similar health-specific security frameworks.
• The company uses NIST CSF as an overall means of adhering to and measuring security requirements. Therefore, this project must fit within the overall security program based on NIST CSF.
• The company has many detailed security policies, baselines, standards, and procedures. The project must adhere to these. An overview of these documents is available in Excel format.

The business impact: The business impact of this project is very high because it is the main application used by all customers. A full Business Impact Analysis is needed but is left out here.

Risk profile: A full risk profile would include existing risks or risks from a similar project/application. A full risk profile is needed but is left out here.

Stage 2: Define the Technical Scope

What’s needed in this stage:

• Enumerate software components
• Identify actors & data sinks/sources
• Enumerate system-level services
• Enumerate third-party infrastructures
• Asset completeness of secure technical design

Enumerate software components: The full tech stack is a moving target considering that the application is in the process of being built. But the current known components consist of:

• Azure cloud, including:
  • Web app services are split into front-end and back-end applications, the front-end will be running React JS, and the back-end will be running Django.
  • iOS and Android clients, as well as a web application version, these will all use the same core codebase but are prepared specifically for each environment.
  • SQL database services such as Azure Cosmos DB.
  • Some IaaS level components, such as VMs, using hardened Linux Operating Systems, for the purposes of connectivity to legacy systems, and a hosted legacy database.
• Connectivity to legacy company applications, all of the connectivity infrastructure will be hosted on-premises, in a newly built network segment.

Identify actors & data sinks/sources:

• Actors:
  • Customers (end-users).
  • Various IT supporters, for general application maintenance.
  • Various IT admins, for application and underlying infrastructure maintenance. This will consist of the current IT organization. The IT organization is already managed via a strong user Identity & Access Management process.
  • Third-party connectors and their users – the health care industry has many third parties which must be interacted with (i.e., hospitals, doctors, oversight organizations, etc.), these connect to the application in many different ways (full description to be provided elsewhere).
• Data sinks/sources
  • Project specific databases, with customer data in it (synchronization from legacy/backend databases)
  • Legacy databases, including billing, and medical procedures.
  • Connectors to data sources at hospitals, doctors, and various medical institutions.

Enumerate system-level services: I will not include this here, but this consists of looking at each system or service type and listing all relevant services running.

Enumerate third-party infrastructures: I will not include this here, but this consists of looking at each third-party and listing all relevant services running.

Asset completeness of secure technical design: I will not include this here, but this consists of looking at all types of systems and services, and determining whether hardening is available.

Stage 3: Decompose the Application

What’s needed in this stage:

• Enumerate all application use cases
• Perform data flow diagram exercise of identified components
• Security functional analysis and use of trust boundaries

Enumerate all application use cases: The overall use case of the application is to provide a central application for end customers to view and edit their health insurance information. This consists of the typical features you would expect as a central location to manage health insurance matters.

A breakdown of use cases (a non-exhaustive list for the purposes of this PASTA threat modeling example):

• Customer:
  • View/edit basic customer data, like name, address, etc.
  • View medical procedures that have been performed, at hospitals, doctors, dentists, etc.
  • View billing information:
    • Billing information from care providers to the health insurance provider
    • Billing information from the health insurance provider to the customer
    • Outstanding bills and invoices
  • Dispute system, to dispute bills.
  • Medical advice system, to provide independent medical advice about care providers.
  • Etc.
• Company employees:
  • Manage information, i.e., manually add data sources, and update data when there are errors.
  • View information in case help is required for the customer.
• Tracking usage
  • The health care industry is subject to strict usage requirements. For all actions, a log must be kept of the action (i.e., view, update, delete, create of data).
    • A full breakdown of the usage tracking should be included.
• Etc.

Perform data flow diagram exercise of identified components: The results of the Data Flow Diagram activities are shown below. Note that this is a simple DFD. It may be necessary to create multiple DFDs to zoom in on relevant aspects of the overall application.

Security functional analysis and use of trust boundaries: There are a number of trust boundaries, the main ones being: External (e.g., internet), internal, and internal backend (which contain the legacy systems).

Stage 4: Analyze the Threats

What’s needed in this stage:

• Analyze the overall threat scenario
• Gather threat intelligence from internal sources
• Gather threat intelligence from external sources
• Update the threat libraries
• Threat agents to asset mapping
• Assign probabilistic values around the identified threats

Analyze the overall threat scenario:

To start I will provide a high-level overview of potential threats, along with key information per threat. Subsequent stages would zoom into these threats for further decomposition.

Threat Title	Threat Description	Impact	Relevant Component(s)	Countermeasures
Unauthorized outsider access to customer medical data	Due to exposure of the application to the internet, and generally the outside world, there is a potential for unauthorized access to medical data.	High – This is the main threat that the company must defend against.	MyHealth application, and key components are the logical application, database/data-stores.	Range of countermeasures required: application hardening, analysis per application feature and associated access rights, OWASP top 10 (for common application mistakes), etc.
Unauthorized insider access to customer medical data	There are various ways for employees to access medical data, e.g., through the application itself, the database, Azure cloud management interfaces and databases. This is an important threat at many technical layers.	High – This is an important threat (and family of threats).	Backend components, that are accessible to company employees, and in particular the IT administrators. Various contractors, and externals also need to be considered.	Range of countermeasures required, mostly in the realm of IT security management, such as strong joiner, mover, leaver processes, reviews of access rights, reviewing the entire access path (cloud management, normal management interfaces, OS, database, network, etc.).
Many more, the above are example high level threats

Gather threat intelligence from internal sources: By looking at existing security-related incidents, it is possible to build a repository of past threats & security weaknesses.

Security Incident	Learnings	Covered by Countermeasures / Security Requirements?
Incident A: An administrator accessed medical data about a famous person, they did this out of curiosity.	A) Administrator access must be monitored. B) Administrator access should be restricted to customer & health data where possible. Etc.	A) Yes by security requirement #123. B) No, a relevant security requirement will be created under A) Yes by security requirement #234.
Incident B: A hacker was able to perform an SQL attack on an existing web application. The hacker was able to exfiltrate a large portion of the customer database.	A) Sufficient care must be provided to each application feature to prevent SQL injection (i.e., input filtering, parameterized query, etc.). B) Permissions to medical data must be carefully analyzed, to ensure that in case of a SQL vulnerability, it will not impact the entire database.	A) Yes by security requirement #123. A) Yes by security requirement #123.
List all security incidents (remember this is confidential information and should be shared carefully).

Gather threat intelligence from external sources: A similar step must be performed as in the internal threat intelligence example, however expert opinions should be included from external sources (e.g., from industry bodies, security companies, etc.).

Update the threat libraries: In this example, I will use the CAPEC threat modeling library. I can use it to iterate through all the CAPEC threats, and determine which are potentially impactful for the MyHealth application. I’ll show a limited example below.

CAPEC-ID	CAPEC Description	Applicable
CAPEC …
CAPEC 65	Sniff Application Code An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.	Yes – The application sends code and data through the network.
CAPEC 66	SQL Injection This attack exploits target software that constructs SQL statements based on user input. An attacker crafts input strings so that when the target software constructs SQL statements based on the input, the resulting SQL statement performs actions other than those the application intended. SQL Injection results from failure of the application to appropriately validate input.	Yes – SQL is applicable, because the application uses databases to store data.
CAPEC 67	String Format Overflow in syslog() This attack targets applications and software that uses the syslog() function insecurely. If an application does not explicitely use a format string parameter in a call to syslog(), user input can be placed in the format string parameter leading to a format string injection attack. Adversaries can then inject malicious format string commands into the function call leading to a buffer overflow. There are many reported software vulnerabilities with the root cause being a misuse of the syslog() function.	Yes – The IaaS part of the application infrastructure uses syslog.
CAPEC …

Threat agents to asset mapping: This involves mapping the threats to the relevant assets.

Assign probabilistic values around the identified threats: This involves providing a likelihood of a threat being abused by an attacker. This can be a simple high, medium or low rating per threat. When assigning, think about access rights required, window or opportunity, the attack surface (whether it is a large one or a small one), etc.

Stage 5: Vulnerability Analysis

What’s needed in this stage:

• Review and correlate existing vulnerability data
• Identify weak design patterns in the architecture
• Map threats to vulnerabilities
• Provide contextual risk analysis based on threat-vulnerability
• Conduct targeted vulnerability testing

Review and correlate existing vulnerability data:

• Historically, for our example application and company – the company has had issues in life cycle management of legacy systems. Many of the underlying systems have various patch and update issues, meaning that they are vulnerable to attack if exposed. The company has setup layers of networking segments to limit exposure (as a response).

Identify weak design patterns in the architecture: Taking the DFD from stage 3, we can analyze it to determine if there are design or architectural weaknesses. I can notice that there are only a few layers of defense (external, internal, and internal backend). I can also notice that there are various legacy systems with potential weaknesses. I can deduce some sample weaknesses in the design:

• More segmentation may be required in order to protect the application. Remember that this application is provided externally to customers from the internet.
• The backend legacy systems must have more defensive measures, especially given the fact that these have lifecycle management issues (read lack of security updates).

Map threats to vulnerabilities: Here I can map threats that I have identified, to a list of vulnerabilities. I will not include this step for this example.

Provide contextual risk analysis based on threat-vulnerability: In my example, I will highlight some fictional components that have lots of threats and vulnerabilities: an IaaS server that runs a legacy system has a significant back-log of security patches.

Conduct targeted vulnerability testing: This consists of running vulnerability management scanners across our IT landscape. This capability should already exist in your company – if not, you will have to setup the capability first. One challenge you often see if this capability exists: how do you link IT assets from the scans to your project or application. This is often difficult to achieve in practice (when you have a large company, with a large IT landscape).

Stage 6: Attack Analysis

What’s needed in this stage:

• Analyze possible attack scenarios
• Update the attack library/vectors and the control framework
• Identify the attack surface and enumerate the attack vectors
• Assess the probability and impact of each attack scenario
• Derive a set of cases to test existing countermeasures
• Conduct attack-driven security tests and simulations

Analyze possible attack scenarios:

Attack Scenario	Internal / External	Requirements for Attack
Outside hacker (no accounts, no knowledge), attacks the web application for common weaknesses	External	No requirements
Outside hacker (with accounts, no knowledge), attacks the web application for common weaknesses	External	An attacker needs accounts to access the application, this can be achieved by being a customer
Insider IT administrator, attacks in retaliation for past treatment, and uses administrator interfaces	Internal	An attacker needs to be assigned an IT administrator (i.e., internal employee, or contractor)
Etc.

Update the attack library/vectors and the control framework: Here we can refer to the CAPEC attack scenarios, or other attack scenarios, and determine whether the attacks are covered via the control framework and security requirements.

Identify the attack surface and enumerate the attack vectors: Here we can enumerate through the attack vectors and determine the exposure of the attack surface (think whether this is large exposure, such as the internet, or small exposure such as the internal network).

Assess the probability and impact of each attack scenario: In this example, I’ll look at the SQL injection attack from CAPEC 66. The probability is low because the framework used to develop the application, is a standards built framework meaning that limited custom SQL is built, rather pre-defined queries are developed within the framework. However, the threat remains that a mistake can be made.

Derive a set of cases to test existing countermeasures: Working on the SQL injection example, this can be tested via: 1) automated code analysis, and 2) manual code review by a security specialist (manually going through the code, and looking for signs of SQL injection weaknesses). In this step we would define the list of test cases, and not necessarily perform the testing at this point.

Conduct attack-driven security tests and simulations: In this step, actual testing of the threats is performed, in a risk-based manner. It is unlikely that every threat can be fully tested, so careful consideration must be taken to determine how to test, and how to get sufficient coverage.

Stage 7: Risk and Impact Analysis

What’s needed in this stage:

• Calculate the risk of each threat
• Identify the countermeasures
• Calculate the residual risks
• Recommend a strategy to manage risks

Calculate the risk of each threat: In this example, I look at the SQL injection example, and provide the following risk: LOW likelihood, and HIGH impact, meaning an overall MEDIUM risk rating. I will need to do this for all relevant threats identified in earlier steps.

Identify the countermeasures: Per threat, assign countermeasures. In the SQL injection example, the countermeasures are: 1) use parameterized query, 2) use database user accounts that have hardened access rights (and not administrator rights, 3) use automated code scanning tools that look for signs of SQL injection in the code, 4) perform manual code reviews.

Calculate the residual risks: Per threat, determine residual risks. In the SQL injection example, determine how much residual risk you expect there to be, based on the selected countermeasures. In this case, the residual risk is low, but not 0.

Recommend a strategy to manage risks: Define a high level strategy to manage risks in the long term. In this example I would recommend:

• Periodic review of the control framework.
• Periodic review of security incidents, and ensuring that relevant updates are made to the control framework (with lessons learned).
• A separate security review of each and every feature update to the application.
• Periodic penetration testing of either the entire application, or parts of it.
• Weekly or monthly vulnerability management scanning, of application components.
• External (from the internet) scanning of the application, to assess the attack surface.

PASTA Threat Modeling Example Conclusion

In this article, I provided an example PASTA threat modeling example to show you step-by-step how to use PASTA in a real-world situation.

What can we conclude from this example:

• PASTA threat modeling is a thorough threat modeling method, with many stages that provide extra input and insight into understanding an application or IT system.
• The thoroughness, and in-depth modeling is a PRO and a CON: on the PRO side it gives us great insight, on the CON side it can be a lot of work to have to go through this (especially for security teams that are already squeezed for time).
• PASTA provides many different angles of understanding, from business to technical/IT.