In order to build out a truly robust threat model for an organization, security teams must consider high-level aspects of their systems and applications as well as low-level design features inherent to those systems and applications. By integrating multiple frameworks in the appropriate places, security teams will develop granular visibility into anything that could go wrong on their systems as well as possibilities to integrate mitigation systems to prevent breaches and limit any damage that may occur if a breach were to take place.

PASTA and Persona non Grata Threat Actor Profiles

In a previous post, we discussed the PASTA methodology and Persona non Grata war-gaming method for developing profiles for threat actors who could potentially target the organization. These methods provide high level insights into system design and the types of TTPs that a threat actor may use to attempt an attack or intrusion on a network.

For this series we are using an example of a “crown jewels” database and discussing how a security team might apply the threat model examples to the protection of that database. PASTA looked at the various aspects of the database, including the technology stack, business risks associated with events that may occur during the protection of the database, and how the intelligence cycle provides a constant, and constantly evolving, security posture in place to proactively search for threats.

The Persona non Grata method provided an overview of just who might be interested in stealing the database files, what they might want to do with those files, and the potential sophistication levels of the threat actors. These profiles help build an understanding of the primary threats to the organization and the tools those threats may employ to stage a potential attack.

This article will look at the STRIDE model, which provides detailed insight into specific security concepts affecting systems, networks, and applications. The STRIDE model fits neatly into stages 3 and 5 (application decomposition and vulnerability assessment) of the PASTA methodology, providing a strong synergy between models.


The STRIDE threat model is technically-focused, looking at system design with data-flow diagrams and specific points of reference. STRIDE provides security teams with a framework to understand the technical limitations of specific systems by enumerating and defining specific issues associated with cyber security and the specific properties which those issues violate.

STRIDE covers six domains:

ThreatProperty ViolatedDefinition
Spoofing IdentityAuthenticationPretending to be something or someone you are not
Tampering with DataIntegrityAltering data
RepudiationNon-RepudiationClaiming you didn’t do something or were not responsible
Information DisclosureConfidentialityProviding information to an unauthorized entity
Denial of ServiceAvailabilityExhausting resources to the point of disruption
Escalation of PrivilegeAuthorizationAllowing someone to do something they are not authorized to do

In effect, STRIDE provides a framework to understand how the CIA (confidentiality, integrity, availability) methodology interacts with system design, though the model also provides other essential themes for consideration as well. All secure systems must adhere to all six points in the STRIDE models, or else a gaping hole with emerge within that system’s design, and threat actors will exert their energy to exploit that hole.

Let’s discuss each domain individually with some practical examples.

Spoofing Identity

One of the most difficult and frustrating aspects of security is that it is nearly impossible to truly know who is on the other end of the email, chat line, phone, etc. Threat actors will profile potential victims using open source tools in order to impersonate contacts as a means of gaining a victim’s trust. Then, any link or document the threat actor sends the victim will have a higher chance of being met with trust, allowing the attacker to gain a foothold with either credential harvesting links or even malware payloads. Once the attacker gains this foothold, he can essentially become the victim on the organization’s network and move laterally as necessary.

Tampering with Data

Perhaps the only thing more disruptive and dangerous than stealing data from the database is a direct attack against the database where the threat actor either changes the data or, even worse, deletes it. Secure backups that are kept entirely separate from the main system would assist in mitigating such damage, but downtime would likely be significant as sysadmins scramble to get the breached servers offline and replaced with the secure backups.

As special consideration with data tampering is ransomware, which is a primary threat that has already claimed thousands of victims and cost organizations billions of dollars. Ransomware is data tampering is its most deadly form, as remediation efforts require significant effort and may still fall short of truly solving the problem. In addition, paying the ransom is not guaranteed to retrieve the data, as many modern ransomware strains are also known as wipers and will delete all encrypted contents even if the encryption key is provided.


The concept of repudiation lies in the tampering of log data in order to either show that no event occurred on the system or that an account other than the one which performed the action did so. If logging is not enabled and those logs regularly reviewed, or if log retention is too short, an attack can easily go unnoticed with no evidence left for a subsequent investigation. With modern logging systems, every step along the system and network chain should record all activity, which is then available for searching and correlation via the enterprise’s SIEM system.

Information Disclosure

This can come in many forms, from disclosing too much personal information on social media, which can then be exploited in spearphishing campaigns, to leaking confidential data through carelessness or inadvertent misconfiguration. Indeed, many of today’s most egregious breaches involve unprotected or poorly protected databases exposed to the internet.

Denial of Service

Distributed Denial-of-Service (DDoS) attacks are always a concern, and modern load balancers, especially those on large cloud platforms, are built to withstand such attacks to a degree. However, many of denial of service tactics are available, such as defacement, which would prevent customers from accessing a site, or infection, which may lead an organization to proactively take their services offline while it remediates the problem.

Escalation of Privilege

Privilege escalation is when a threat actor gains access to a system and is able to take control by making himself an administrator or root user, giving him full access to the entire system and all of its components. For example, standard users should have little access to the computer’s system, they should not be able to install any software or run certain networking functions without explicitly entering administrator credentials. Therefore, if a threat actor can steal credentials from an administrator, by running a keylogging Powershell script, for example, he can then use those credentials locally on that machine to install more malware and edit OS logs, and then attempt to use those credentials on other machines, such as servers, in order to further spread around the network.

In terms of our database example, security teams must profile each system in the environment, as well as the networks on which those systems communicate and the applications running on those systems and across the network. Each piece will provide its own idiosyncratic challenges in terms of the STRIDE model, and each must be addressed individually in order to protect the entire stack.

Full Enumeration May Be Daunting, But a Necessary Challenge

Filling in the details of various threat models can be a daunting task, as the more information that goes into each individual piece generally creates even more work by uncovering previously unknown details as well as new avenues that now need protection. Generally, enumerating these models is a process handled by multiple teams, each with its own specialty, though knowledgeable personnel in a small shop can easily produce such models in support of the organization’s overall security goals.