In a prior post, we wrote about the importance of developing robust, comprehensive threat models in order to drive intelligence and overall security practices. This is blog we will look at various models and discuss how to apply each one, specifically to the hypothetical case introduced last time.

Securing a Database with PASTA

In the case study, we will describe how an organization may develop threat models in order to protect a highly sensitive database. The security team faces several threats, from technical issues to prevent direct hacking attempts from the internet wilderness to phishing attempts which may target personnel at the organization. Using the intelligence cycle and the Mitre PRE-ATT&CK framework, the team has many of the necessary tools it needs to understand potential threats, but it is still missing a solid framework to bring all of the necessary information together.

Threat models cover various levels of the security paradigm – some focus on the strategic level and some focus on the operational and tactical levels, some focus on technical matters whereas others focus on more general aspects of security.

This post will discuss the Process for Attack Simulation and Threat Analysis (PASTA) model and then the Persona non Grata technique for developing potential adversary profiles. This will give us a high-level framework within which we can look at sub-processes for specific details.

Process for Attack Simulation and Threat Analysis (PASTA)

The Process for Attack Simulation and Threat Analysis (PASTA) methodology is risk-centric, meaning that its primary focus is on the business impact, inherent application risk, trust, threat correlation, and attack patterns. PASTA works in seven stages:

  1. Defining the Business Context of an Application – This stage considers the inherent risks of a particular application and addresses business impact considerations should a problem arise with that application.
  2. Enumeration of Technology – This stage provides a holistic view of the application’s entire technology stack.
  3. Decomposition of the Application – This stage breaks down the application’s data pipeline into its constituent parts
  4. Threat Analysis – Stage four analyzes threat intelligence relevant to the application as well as threats to data integrity within the application itself.
  5. Vulnerability Identification – This step looks at vulnerabilities and weaknesses within the application’s design, focusing on known CVEs as well as other research in order to identify previously unknown vulnerabilities
  6. Attack Simulation – This step tests typical attack patterns against the application and organization. This is also known as “red teaming”.
  7. Residual Risk – The final stage remediating problems and vulnerabilities in order to mitigate risk.

pasta_threat_model

How might PASTA apply to our “crown jewels” scenario? First, the business context for the database is that the organization relies on that data for its core business functions. If the data were stolen, myriad privacy, compliance, and potential fraud problems would certainly arise. However, perhaps more importantly, if the data were somehow altered or erased, as would be the case with ransomware, the organization’s activities would suddenly grind to a complete halt, and all business processes would cease.

Second, the security team must understand the technology in place to run the database. This include all of the constituent parts of the network – from the DMZ to the routers to the servers hosting and backing up the database – as well as the other technologies running on all of those myriad machines. After all, if a workstation is running a vulnerable app that touches the internet directly, such as some sort of peer-to-peer application or remote desktop application, that workstation can lead to the entire network becoming infected or compromised.

In the same vein, the third step looks at the application itself in a similar manner. What type of database is the organization running? MySQL, SAP, Postgres, etc? What dependencies do the database and codebase use? Which languages did the developers use to interact with the database? To interact with the end user across the internet?

Fourth, threat analysis will inform the security team of what is happening out in the wild. Threat intelligence will describe new and emerging threats and provide IOCs to assist in identifying of those threats have made their way onto the network. In addition, intelligence sheds light onto ongoing phishing and spam campaigns, often including clues for compromised and malicious infrastructure, such as domains and URLs.

Next, the team must identify the weaknesses and vulnerabilities associated with both the technology stack and all of the individual components of the application itself. Understanding each piece of the larger puzzle is key to this step, as knowing the full range of vulnerabilities and weaknesses is only possible if the team knows the full range of components inside and out. Here, weaknesses also include the human factor.

Sixth, the team must simulate attacks and other exploits in order to educate non-security personnel and train the security team itself to respond to potentially malicious activity. This step also assists the team in identifying weaknesses that are impossible, or exceedingly difficult, to mitigate.

Finally, the team must patch the discovered vulnerabilities and establish means and methods for mitigating those weaknesses that have no patch. This is also where the team must report both the good and bad news to executive leadership so that the entire organization is on the same page.

With PASTA, the security team has developed a full, front-to-back process for ensuring the security of the crown jewels database files. Yes, there are several limitations, such as how to process certain analyses, and other frameworks are better suited for those circumstances.

Persona non Grata

The Persona non Grata model seeks to understand who may want to attack an organization by analyzing motives and other traits. By defining potential adversaries and assigning risk scores to each type, the security team can better understand the Tactics, Techniques and Procedures (TTPs) used against the organization.

In the crown jewels example, understand adversary motives generally involves understanding the data stored in the database. Is the data personally identifiable information (PII) that someone can use for identity fraud, payment card information, health care records, government employee records, sensitive data, etc? Each of these examples presents a different, if not somewhat overlapping, group of threat actors who may try to exploit it.

For example, threat actors seeking to make money from their theft will likely try to steal the database files and sell the information to willing buyers. However, these actors often operate with limited resources and remain relatively unsophisticated. On the other hand, governments, who are less likely to seek payment card or bank account information (with the exception of North Korea), are highly sophisticated and will likely seek sensitive blueprints or contingency planning materials, among other types of data.

Therefore, for most businesses which do not execute government contracts, there is little need to spend significant time and effort protecting against large, government-backed operations. Of course there are many exceptions to this, and every individual case is different.

The security team should instead focus its efforts on defending against opportunistic attacks, such as securing internet-facing infrastructure, and defending against malware. To this point, commodity malware is currently simple to obtain and can devastate an organization with little effort on the part of the threat actor, meaning that malware, and especially ransomware, should be a high priority for all organizations.

Focus on the Cycle, Not the Steps

As noted before, although the models presented in this article are described in a linear fashion, every step in every model is cyclical, and referencing past steps both within a model as well as within sub-models, which we will discuss next time, should be standard operating procedure.

This article continued a discussion into threat models and methodologies by explaining the Process for Attack Simulation and Threat Analysis (PASTA) model and introducing the Persona non Grata technique. A future post will look at the STRIDE model for defining risks and vulnerabilities to computer and network systems and applications, which integrates into PASTA stages 3 and 5, and later we will discuss the attack trees methodology to describe potential attacks against a system, which integrates in PASTA steps 4 and 6.