Introduction
At Praetorian, we believe that good security advisors always dedicate the start of a security assessment toward understanding your product’s threat landscape. This is why we perform a baseline threat model before every engagement, including those that do not explicitly contain an in-depth threat model analysis. A baseline threat model ensures that we have examined the entire attack surface of your product and sufficiently understand its threat landscape prior to the start of testing.
The purpose of this article is to share our methodology for creating baseline threat models and to explain why this is an important part of a successful security assessment. By the end of this article, you will be able to create your own baseline threat models for internal security assessments and understand the value that they can bring to your product’s development cycle.
This article uses the terms “application”, “product”, and “environment” interchangeably. While these are very different entities in the field, our approach is incredibly flexible and works with minimal modification for most security engagements. Whether you are preparing for a network security assessment, a web application penetration test, or a red team, a baseline threat model is the best way to start.
What is a Threat Model?
A threat model is a written document that describes your environment’s threat landscape. It is created by assessing the risk and impact of potential threat actors who are poised to do harm to your product.
A baseline threat model analyzes the user roles, attack surfaces, and assets of an application and then uses this information to enumerate and prioritize attack paths and test cases. It is meant to give the security engineers a set of guidelines for how to delegate time and resources during testing.
How Does Praetorian Threat Model?
Praetorian does not rely on one established framework such as PASTA or STRIDE. Instead, we begin by taking a high-level overview of the threat environment to gather a comprehensive understanding of the target product. This is done via application walkthroughs, developer interviews, design documentation review, manual inspection, and more.
The information we gather is organized into four sections: User Roles, Attack Surfaces, Attacker Terminal Goals, and Prioritization Matrix. Depending on the size and complexity of the environment, we may also include sections for trust boundaries, data flow stories, and test cases.
Figure 1: Praetorian Threat Modeling Methodology
Why is this Helpful?
Threat modeling guides our engagements to ensure that we are efficiently and strategically testing your product rather than hunting for random bugs.
Baseline threat models also provide an opportunity to sync with you before testing begins. In this way, we ensure our understanding of your product’s business value, greatest threats, and points of compromise is aligned with your concerns. This allows us to confirm that we are providing sufficient coverage to each area of your application.
Furthermore, performing a baseline threat model dedicates a small period at the start of an engagement to employ an adversarial mindset and look at the application through the lens of an attacker. This frequently results in uncovering vulnerabilities that would have gone unnoticed from a purely defensive perspective. For example, while threat modeling on a recent engagement, it became clear that privilege escalation would be an exceptionally detrimental attack if realized. Because we knew how important preventing this attack path was to the overall security posture of the application, access controls were prioritized during testing. This extra attention was rewarded with the discovery of a complicated token forgery vulnerability. We exploited this to impersonate valid users and escalate privileges within the application. In this situation, threat modeling effectively highlighted a critical area of the application and helped us address our customer’s greatest concern.
Threat Modeling the Praetorian Way
Each section in the Praetorian threat model looks at your application from a distinct perspective. Taken together, they provide a comprehensive map to thoroughly analyze your product’s security posture and risk.
User Roles
What is it?
In the User Roles section, we identify actors within your environment and its supporting infrastructure. These include traditional, application-specific roles such as “super administrator”, “administrator”, and “user” but also broader actors such as AWS administrators, network admins, tech support accounts, unauthenticated users, and more. We want to consider all potential access to your environment, no matter how limited.
What does it accomplish?
When testing a product, we extend our view beyond the native roles and users provided by the application as just as much harm can be done by actors with adjacent access to the environment. This section enables us to avoid the tunnel vision that typically comes with a more limited scope and effectively enumerate all types of access to the target environment.
How do we write it?
Throughout our baseline threat model analysis, we complete application walkthroughs, developer interviews, architecture reviews, and other relevant conversations. Our customers may also provide us with user manuals, architecture diagrams, API endpoints, and other types of documentation. By reviewing this information and combining it with what we learn by manually inspecting the application, we can derive a comprehensive list of theoretical threat actors. This information is compiled into a table containing each role and a brief description of its intended function and permission level.
Attack Surface
What is it?
In the Attack Surface section, we enumerate all major components and supporting infrastructure of your product. This includes native applications, backend databases, third-party libraries, integrated automation tools, cloud environments, and anything else that is critical to your product’s operation.
What does it accomplish?
The Attack Surface section itemizes potential entry points for a partial or complete compromise. It highlights all launch pads a threat actor may use to initiate an attack.
How do we write it?
Like the User Roles section, we begin with a series of conversations, walkthroughs, readings, and inspections of your environment to collect a trove of useful information. We review this information to take stock of all environmental components and how they relate to one another. For larger products, we may also generate architectural diagrams to provide a visual structural model.
We also research public information on your product to learn more about its intent and business value. This can help us identify which portions of your environment should be prioritized during testing.
In the written model, each attack surface is listed with a brief description of what compromises it.
Figure 2: Decomposition and Attack Surfacing
Attacker Terminal Goals
What is it?
In the Attacker Terminal Goals section, we take inventory of all valuable assets and functionality within your environment. This section describes each of these items and why a threat actor would be interested in them. A good terminal goal should answer the question: “What ultimate goal does the adversary hope to achieve?” For this reason, “accessing payroll information”, “shutting down IoT devices”, and “bypassing software licensing” are more useful terminal goals than “compromising the domain administrator”, “achieving remote code execution”, or “modifying trust policies”.
What does it accomplish?
We enumerate terminal goals to explicitly outline the critical assets of your product. In an ideal world, every security bug could be caught, reported, and patched. Unfortunately, time and resource restrictions make this an unlikely reality. Understanding which parts of the application protect important assets, and which do not, can drastically streamline effective security testing.
How do we write it?
Like the above sections, we enumerate attacker terminal goals by conducting interviews, reviewing environment components, and manually inspecting your product. Researching the business value and function of your product is greatly important in this section, as it is much easier to understand how a threat actor could compromise a critical asset after we understand what and where those assets are.
In the written report, each terminal goal is catalogued with a short description of what the goal entails and why an adversary may be interested in achieving it.
Prioritization Matrix
What is it?
The Prioritization Matrix can be thought of as the culmination of the preceding three sections. Here, we enumerate and rank valid attack paths that could be used by an adversary to reach one or more terminal goals. The attack paths are ranked in order of importance such that the paths higher in the matrix will typically receive more attention during testing. Example attack paths include “vertical privilege escalation”, “password-spraying”, and “SQL injection”.
What does it accomplish?
We use the Prioritization Matrix to accomplish two important tasks. First, the matrix serves as a guide for security testing and is used as a reference to determine how much time and effort should be spent on each area of your environment. For time-boxed security assessments, this is a critical means of ensuring sufficient coverage of the whole product. Second, the Prioritization Matrix allows us to explicitly outline our concerns for your environment’s threat environment and ensure that you agree with our assessment. It is not uncommon for a customer to request that we rearrange items in our matrix, or that we add or remove an item. This is an excellent sign, as it shows that our customer is actively engaged in the security process and devoted to improving their security posture.
How do we write it?
The Prioritization Matrix is built by assembling the preceding information. We use our adversarial mindset to enumerate different types of attacks that may be carried out against each attack surface, the user roles needed to achieve them, and the terminal goals that they will reach. If these three points can be connected by a chain of attacks, the attack path is added to the matrix.
In the written threat model, this information is compiled into a ranked list, which details the type of each attack and a brief description of how it works.
Figure 3: Prioritization Matrix
Important Considerations
Always be threat modeling
We believe that threat modeling is a crucial first step toward a productive security assessment. A baseline threat model provides an orientation of the application’s threat landscape and a prioritized guide for allocating testing resources. Without this, it is very easy to waste time blindly shooting for vulnerabilities.
A baseline threat model is non-exhaustive
A baseline threat model is not an exhaustive enumeration of every possible attack and threat actor. It is meant to provide an initial intuition for how the environment is laid out. Testing begins as soon as the threat model has given us a sufficient understanding of your environment’s threat landscape.
No threat model is final
While testing, it is not uncommon to encounter new information that warrants an adjustment to our initial threat model. Perhaps a hidden domain of the environment is discovered, or an offline network is reached. In these situations, modifications to the initial threat model are necessary. Similarly, if updates are deployed to the environment at a later point in time, the threat model must change with it. The threat model should be thought of as an organic, living document that changes and grows with the application (and one’s understanding of it).
Flexibility is important
Depending on the product and the customer, we may add or remove sections from our baseline threat model as appropriate. Sometimes an application has only one user type and an incredibly complex backend API. In this situation it may make sense to leave out the User Roles section and focus more on the Attack Surface, perhaps with diagrams. Whatever the reason, we always tailor the threat model to fit your environment.
Conclusion
Threat modeling is a great way to orient oneself to an environment’s threat landscape. This is why we perform a baseline threat model of your environment prior to every security assessment. The Praetorian threat model is typically divided into four sections but may be adjusted for products that do not match this form. Once completed, we use our threat model to confirm that our understanding of your application’s threat environment is congruent with yours and to ultimately guide our technical testing.
We believe firmly in the value of preliminary threat modeling as it ensures a solid understanding of your product’s threat landscape. A good threat model can be what separates a productive security engagement from a non-directional bug hunt.
