Understanding How to Mitigate Security Threats and Risks with Threat Modeling

In the field of security of web applications and mobile apps, threat modeling is a method that can be considered primarily as a means of performing deliberate risk management. There are many ways to identify and assess threats. Although the techniques differ: The basic principle is always to use them to identify the risks to an application or IT system and, more importantly, to agree on what these risks are in detail.

Threat modeling is about better understanding the respective risks. All experts involved in the IT infrastructure should reach a common view of the threats and the most appropriate countermeasures.

In this article, you will find out more about the drivers for threat modeling and some of the main modeling methodologies in use today. We’ll also cover threat sources as well as attack modeling with respect to cyber security.

Note: Threat modeling can be performed at different levels, whether for applications or IT systems. In this paper, I use both terms.

What is Needed for Threat Modeling?

Threat modeling allows an organization to better understand the risks it faces. At the same time, the method helps in understanding which risks it will mitigate and which it may not mitigate because it would not be economically feasible to. In addition, businesses and organizations should have the ability to determine who is responsible for what within their team structures. For example, one team might be tasked with maintaining threat mitigations against certain types of attacks. In contrast, another team is responsible for maintaining vigilance over a certain part of the IT infrastructure. Different organizations will have different priorities that come out of their threat modeling. But they all need certain things to run a threat modeling program. For simplicity, these can be broken down into four distinct prerequisites.

1. Requirement: Full Understanding of the Application

First, threat modelers must fully understand their application. Typically, this means creating an overview of the architecture of all the components and connections within an application. Most threat models contain a schematic diagram of the application architecture for this purpose. This is used not only to identify attack opportunities, but also to assign responsibilities within the structure. This makes it possible to determine who is responsible for what and where demarcations end.

2. Requirement: Definition of Assets

Secondly, threat modeling relies upon defining assets fully. This will mean understanding the value of data and applications as the system’s principal assets. It should also be mentioned that defining assets will be unique to each threat model because the value of certain types of data and applications will necessarily differ from one organization to the next.

3. Requirement: Definition of Trust Boundaries

Another prerequisite for threat modeling is defining trust boundaries. In a threat model, trust boundaries are often defined by identifying the architectural aspects that are part of the same organisational structure and external parts, for example, those in the cloud. Technical know-how is required for this part of threat modeling.

4. Requirement: Impact Assessment

Fourth and finally, threat modeling requires a process of understanding what might happen if things were to go wrong. This means: threat modelers think about the sort of attacks an organization may face and the potential fallout from them. When this is understood, it is possible to proceed with rational decisions on countermeasures, their intensity, .

Designing a Threat Model

Designing a threat model only once would usually mean adopting a classic waterfall approach at in the design stage of an application or system. Depending on the business model, this may not always be possible, and it may be necessary to take another approach. If all four of the above requirements for a threat model are met, a linear waterfall model is certainly possible. As systems engineers in many fields know, waterfall modeling means fixing a design. Although this can occur in IT applications, it is not as common because digital systems can usually evolve and adapt even after they are deployed.

Therefore, other design approaches are more common in threat modeling, such as a cyclical or agile approach. In cyclical threat model designs, planning goes through the following phases:

• Analysis
• Design
• Implementation
• Training
• Integration phases

It then moves into a maintenance phase before returning to planning. In short, cyclical threat modeling is thus continuous and also usually corresponds to many software development cycles. Therefore, it is very useful from a cybersecurity system perspective.

Starting Point: Application Illustration

To design a threat model under either approach, a good starting point is to draw the application in a schematic or systemic way. This allows threat modelers to visually display applications and assets’ integration into the wider digital landscape. Including communication links provides modeling with the following benefits:

• Identify users and roles
• Define login workflows
• Identify technologies that may be deployed
• Point out already known threats and vulnerabilities
• Add security concepts when they are available

It is important to include in the design, such as source code, personal and private data, company secrets, and intellectual property.

A good draft threat model also usually considers the so-called CIA triad (confidentiality, integrity and availability) triad to understand the security properties of each of the previously identified assets. This is a classic method widely used in threat modeling today, which gets modelers to think about each asset in three ways so they don’t assume a risk could only manifest itself in one way. For example, personal data might be stolen from an application which would constitute a confidentiality risk. However, it could also be tampered with, for example, by improperly changing data records. If so, this would constitute an integrity risk.

Understanding PASTA, STRIDE and LINDDUN

Diving deeper into some of the common models used for risk and threat This threat modeling methodology can be broken down into seven basic steps:

1. The objective definition is the first step that defines commercial goals, regulatory compliance issues and business impact analysis.
2. The next is the technical scope definition, which aims to capture the application infrastructure, software dependencies and the boundaries of the technical environment being modelled.
3. The third step deals with application decomposition, which would involve things like potential entry points, trust levels, use cases, data sources, data flow diagrams and trust boundaries, among other issues.
4. From there, threat analysis is the next step within PASTA, a step that can sometimes also include the STRIDE methodology, where appropriate. This fourth step requires modelers to think about attack risk scenarios and their relative probabilities, along with regression analysis on security events and threat intelligence correlation and analytics.
5. After that, step five identifies vulnerabilities through weakness analysis. This involves using queries of existing vulnerability reports and current issue tracking, mapping vulnerabilities on threat trees and the like. It can also include design flaw analysis and scoring vulnerabilities according to various methods.
6. Finally, the penultimate step in PASTA is attack modeling and includes, among other things, the development of an attack tree, exploitation analysis, and attack surface analysis.
7. The final step is risk and impact assessment, which is concerned with qualifying and quantifying the impact on the enterprise. Risk and impact assessments typically include residual risk analysis, identification of mitigation strategies, and appropriate countermeasures.

Please note that this overview of PASTA is just that – an example of one type of threat modeling method. Others exist, such as STRIDE, which stands for spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Some threat models may use STRIDE without PASTA but as previously mentioned, STRIDE can, in certain circumstances, be utilised in step four of PASTA for the purposes of threat analysis.

Another example of a reasonably common threat modeling methodology is LINDDUN, which stands for linkability, identifiability, non-repudiation, detectability, disclosure of information, unawareness, and non-compliance.

Although each methodology has pros and cons, the key point to consider when modeling application threat is that multiple techniques are available. They help to meet different commercial imperatives within different system architectures.

Identifying Threat Sources

One of the most important parts of any threat modeling exercise is the identification of threat sources. PASTA, STRIDE and LINDDUN all deal with this crucial aspect of threat modeling in their own way. However, threat modelers should know that they can also use several resources for known security threats that are currently available. These help modelers think about all the threat types that tend to affect application security today.

For instance, there is a software system known as Threat Dragon made by OWASP. It is typically used to create threat model diagrams as part of a secure development lifecycle process. As a visual modeling tool, it will interface handily with a system architecture diagram. It allows modelers to add trust boundaries, communication channels, various types of assets and, of course, different types of threats. This software is primarily designed to work with the STRIDE and LINDDUN threat modeling methodologies mentioned above.

Another example of a threat source resource is the Microsoft Threat Modeling Tool. Widely used, this tool runs in Windows and is often used by threat modelers using the STRIDE methodology. It is also visual and allows you to draw or import your architectural model. The MS system can add threats in the background when any asset connections are added to the schematic. The tool allows users to pick the threat that might be most relevant and whether or not to add mitigations. That said, the default threats are generic, so some thought is still required to add tailored risks.

The Role of Attack Modeling in Cyber Security

It is important to note that you don’t necessarily need software tools to build attack models in a cybersecurity environment. One of the oldest methods is a so-called attack tree, which can be modelled with a pen and paper or in any software system that allows you to draw. Essentially, attack trees boil down to mapping the various methods an attacker might have at their disposal to reach their objective. In this scenario, the objective is represented by the trunk of a tree. Branches represent the different routes to it. At the other end of the ‘tree’ are individual leaves. These represent all the ways an attacker could start their attack, thereby allowing threat models to enumerate the number of potential entry points a cyber threat could take.

In addition, threat models can make use of attack analysis that scores individual threats. This is typically done by scoring each threat in two ways:

1. How likely is it?
2. How much damage may it cause?

Combining these scores makes it possible to identify the most important and least important threats. As such, it helps organizations to make decisions regarding which ones to deal with first and which require the least mitigation, if any.

Some threat models may also contain the common vulnerability scoring system (CVSS). With this approach, a score is obtained by measuring attack vectors and complexity with system privileges and user interactions and combining them with a figure for the scope, confidentiality, integrity, and availability of data. The higher the number under the CVSS scoring system, the greater the level of threat.

Security Threat Modeling in Summary

To conclude, threat modeling can be tailored to specific organizational requirements using tried and tested methodologies. Some of the security gains of threat modeling include the identification of risks, the evaluation of mitigations and fact-based decision-making. In addition, all assets being fully inventoried lead to commercial and organizational gains. Furthermore, a better understanding of where security responsibilities lie, along with improved regulatory compliance and reputational defense, will be achieved.

More information:

• Sequel: How Architectural Decisions Impact Threat Modeling

Contact to experts

Do you have questions about mgm’s Threat Modeling expertise? Contact us via email, call us or use our special contact form.