When we build a house, we want security to be considered by evaluating the ground on which it is built and how its foundations are planted. Otherwise, cracks will start to appear sooner rather than later. The same applies to the cybersecurity of companies. That is why ensuring security from design and throughout its lifecycle is essential. How can this task be accomplished? Threat modeling is a process that structures and systematises the assessment of threats, risks and mitigation measures of an application, system or IoT device.

Threat modeling allows building a data flow to observe all the information related to the security of the asset to be modeled. Including the security requirements to be considered in its development, the threats and malicious actors that can breach its security, the risks to be faced and the measures that can be implemented to mitigate them.

Ensuring the security of software or a network is arduous since the number of cyber-attacks, their complexity, sophistication and potential impact on companies are increasing. Threat modeling provides the basis for implementing a comprehensive security strategy that ensures an efficient flow of information to detect new threats before they materialise.

Below, we will analyse the keys to threat modeling and why this process can help companies protect their IT infrastructure, place security at the heart of their business strategy and prevent attacks that undermine their reputation and profits.

1. What is threat modeling?

According to the OWASP Foundation, a global cybersecurity methodological benchmark, threat modeling is a process that «identifies, quantifies and addresses the security risks associated with an application». While, as noted above, threat modeling can protect any element of a company’s IT infrastructure, it is most commonly used in secure software development and securing software throughout its lifecycle.

This definition is based on three key verbs to understand what threat modeling is, how it works and what its objectives are:

• Identify: requirements, threats, risks, and security controls…
• Quantity: the level of impact of each risk on the system or application to be modeled and on the organisation.
• Address: implement effective security measures and controls to mitigate risks and respond to potential attacks.

Threat modeling should be considered a cohesive activity. Still, it must be perfectly aligned with an organisation’s development practices, addressing the early stages of development and all design changes throughout the lifecycle.

Performing threat modeling allows you to:

• Visualise how data flows through a system and which attack vectors can be exploited by malicious actors.
• Identify all possible threats.
• Define security controls that can mitigate the probability or impact of each threat.

1.1. Elements

Through threat modeling, it is possible to represent in a structured way all the information related to the security of an asset. Hence, when performing threat modeling, OWASP considers that elements such as the following should be included:

• The description of the asset to be modeled. A web application, a mobile app, hardware, a network…
• Issues to be considered in the future, depending on how the threat landscape or state-of-the-art and security risks evolve.
• A list of potential threats compromising the system’s security will be modeled.
• The set of measures to be taken to mitigate threats and prevent security incidents.
• The actions to be taken to validate the model and verify the measures are effective.

1.2. Find answers to 4 basic questions

How are the elements we have just described organised? OWASP proposes four basic questions that an organisation must be able to answer when performing threat modeling:

1. What are we working on? First, be clear about the object to be modeled. What object is it, and what work is being done around it? Are we at the beginning of software design and development? Are we about to release an application update?
2. What can go wrong? This question is where the threats to the system or application come into play. There are many methodologies for identifying and assessing threats, as shown below.
3. What can we do about them? Or, put another way, what countermeasures can be implemented to manage the risks effectively?
4. Have we done a good job? Assessing the controls in place is key in cybersecurity. Organisations must analyse the measures put in place and assess whether they are the right ones to mitigate threats. In this sense, it can be useful to audit web security, mobile applications, IoT, code, and cloud infrastructures…

Why these four questions? Because they serve to meet the objectives that threat modeling must fulfil to increase the protection of a system.

There is no single way to answer these questions, but as we will see later, various methodologies and tools can be used to carry out threat modeling.

2. Objectives of threat modeling

In light of the above, it is easy to see the central objectives of threat modeling and why this process is very useful for companies and their professionals to consider all aspects related to the security of their IT assets and to optimise communication flows.

2.1. Identifying security requirements

Each system has specific security requirements, in which compliance with the regulations in force also comes into play. RGPD, NIS2, DORA… Within the European Union, increasingly stringent cybersecurity standards are being adopted.

Threat modeling must take these issues into account when identifying security requirements.

2.2. Mapping threats and potential vulnerabilities

Rigorous modeling of a system must provide a complete picture of its threats and risks. Although we think of threats from a malicious point of view (a malware attack, theft of credentials, etc.), the fact is that threats also include accidental incidents, for example, a failure of the hardware on which backups are stored.

Threat mapping must therefore consider all scenarios, not only by putting itself in the position of potential attackers but also by considering incidental issues.

Threat mapping is one of the central elements of threat modeling since, to propose mitigation measures; it is essential to know what needs to be remediated in the first place.

2.3. Understanding the attackers

If threats come from malicious actions, it is essential to understand how these actors operate, their objectives, and their methodologies. Why?

In this way, it is possible to foresee which components or assets they will seek to breach and make an extra effort to search for threats and adopt measures to protect certain attack vectors.

2.4. Studying the potential impact of threats

Not all threats are of equal significance. OWASP argues that a potential threat exists when the combination of the probability of a threat occurring and the impact it could have on the organisation poses a significant risk.

In this sense, threat modeling should serve not only to identify threats but also to understand their potential impact on the company and, thus, establish the criticality level of each threat.

To this end, not only security aspects and requirements must be taken into account, but also business objectives, the characteristics of the business model and the role played by each IT asset in the company’s operations.

A threat less likely to materialise than another may be more critical because it affects a high-value asset, or the impact on the organisation may be significant.

2.5. Prioritise remediation methods

Understanding the impact of a potential threat and establishing its criticality are two fundamental objectives for prioritising mitigation measures and establishing actions to improve the concept, requirements, design or implementation of an application or system.

Companies have limited economic, technical and human resources. Therefore, any cybersecurity strategy must consider the resources available to mitigate vulnerabilities and achieve a sufficient level of protection.

In this sense, if threat mapping reveals a series of risks, it is essential to undertake mitigation measures by prioritising the most serious threats to the company.

2.6. Improving security controls early and continuously

Threat modeling throughout the entire lifecycle of software or hardware is essential to prevent security incidents and take action as early as possible.

Hence, this process is fundamental to secure development, preventing the emergence of risks and remediating problems before an asset is attacked. For example, before the software is released to the market or deployed in production systems.

The same could be said concerning its continuity over time. Implementing continuous threat modeling helps detect new threats and undertake mitigation measures and security controls to help address them. Either because there have been changes to the system, e.g. a software upgrade. Or simply because the passage of time brings new attack tools, tactics and procedures.

2.7. Validating the effectiveness of the measures taken

The security measures put in place during threat modeling must be adequate. It is therefore not enough to propose solutions alone, but it is of great value to audit them to validate whether or not they are effective.

Cybersecurity professionals can conduct a security audit to verify that the measures meet the objectives and contribute to reducing risks.

2.8. Facilitate dialogue between professionals, teams and organisations

Threat modeling graphically represents the components of a system, the assets to be protected, security controls, threats, malicious actors, etc. A diagram can provide a broad overview of all aspects of security. This helps enable the exchange of information between all stakeholders and establish effective communication channels to detect emerging threats and act to reduce security risks.

3. The 4 stages of threat modeling

OWASP envisages three fundamental phases in threat modeling:

• Decomposition of the application to understand how it works.
• Identification of threats.
• Design of risk mitigation measures.

We could add a final phase to these three steps, focused on analysing the efficiency of all the actions carried out.

Thus, each threat modeling step would answer one of the four basic questions indicated at the beginning of this article.

3.1. Decompose

In this phase, the central objective is understanding how the application or system works and interacts with external elements. To do this, we must:

• Gather information about the object to be modeled. For example, it is important to have an exhaustive description of the software to examine its version, which users use it, and what privileges they need…
• Evaluate the external elements. For example, the external components of an application.
• Identify the entry points for attacks. As well as those of exit, fundamental in attacks that seek to exfiltrate information.
• List the assets that could be attacked.
• Identify the levels of trust that represent the access rights to the application or system being modeled.

This allows for establishing the access rights or privileges for each entry point and for interacting with each asset.

From this information, data flow diagrams can be developed to understand the system paths and take into account the set privilege limits.

3.2. Identifying and classifying threats

Based on all the information gathered and systematised in the first step of threat modeling, it is necessary to identify and classify potential threats. Therefore, OWASP proposes the following steps in this phase:

• Categorise the threats to identify them in a systematised and repeatable way, using methodologies such as STRIDE.
• Analyse the threats, taking into account the probability of an attack occurring, its impact and the cost it may entail for the organisation. Matrices can be designed to carry out this task. Threats are analysed both from the perspective of potential attackers and the point of view of defence, studying the security controls that serve to mitigate them.
• Establish a ranking of threats according to risk factors such as impact, possibility or ease of exploitation. In this way, a list of threats is obtained with a priority order to mitigate and remedy the problems related to the threats with a higher level of risk.
• Mapping abuse cases. In other words, list and model possible attacks or malicious scenarios.

3.3. Establish countermeasures and mitigation actions.

All the data obtained in the previous phase is the raw material for selecting the appropriate countermeasures to address threats and prevent them from materialising into security incidents.

In this regard, it is interesting to note the difference between threats and vulnerabilities, two basic concepts in the field of cybersecurity.

A threat is a situation that can cause a negative impact. A vulnerability, on the other hand, is how the threat materializes. Particularly dangerous are zero-day vulnerabilities, which are unknown to the organization and can be exploited by attackers to achieve their objectives.

During threat modeling, previously categorised threats can be directly related to the most suitable mitigation measures and actions to address them.

3.4. Evaluating the work done

When discussing the essential elements of threat modeling, it is important to incorporate a protocol for evaluating the model’s validity.

It is only possible to implement this process if you incorporate a way to accurately check that you have successfully identified the threats and the relevant security controls.

The evaluation of the work leads directly to one of the keys to threat modeling: that it is executed throughout the life cycle of the software or system under analysis and not just at a specific point in time, prioritising, in addition, the early phases of development.

4. Continuous threat modeling throughout the life cycle

Threat modeling cannot be conceived as a static process carried out at a specific moment in the life cycle of software or hardware. On the contrary, one of the keys to threat modeling is that it can be implemented at the beginning of the development process to support a security system from the design stage, for example, in the conceptual phase or during the planning of the software or device.

In addition to helping to ensure secure development, threat modeling is important in all phases of the IT infrastructure’s life cycle since it is more than plausible that threats that arise later are not considered at an early stage. Hence, threat modeling serves to improve and refine the model designed at the beginning of the lifecycle.

Only through continuous threat modeling can new threats be detected and analysed, new malicious actors be taken into account, and the model be matched to the actual risks.

Beyond this commitment to continuity over time, we must emphasise that this is a process of great added value after:

• The launch of a new function
• A security incident
• Changes in architecture

It is also advisable to perform a security audit in the pre-production phase, i.e. before the websites and apps go into production. This allows vulnerabilities to be remediated before becoming exploitable risks for malicious actors.

Software, apps, IoT devices… These are living business assets that do not remain unchanged over time, and threat modeling must adapt to this fact by continuously analysing the threats to which they are exposed.

5. Methodologies and tools for modeling

How is threat modeling executed in practice? Cybersecurity professionals who perform threat modeling have various methodologies for categorising threats and managing the phases of the process. In addition, some tools are very useful for performing this process.

5.1. Methodologies

Several methodologies can be used to carry out threat modeling of software or infrastructure focused on threat analysis. Some of the most common ones are:

• STRIDE. The name of this framework, designed by Microsoft, is the result of the initials of the six threat categories on which it is based: impersonation, manipulation, repudiation, information disclosure, denial of service and elevation of privileges. These threats have their respective security controls associated with them to mitigate them.
• PASTA. This framework includes seven steps to perform threat modeling and reconcile security requirements with business objectives.
• DREAD. The key to this methodology is that it allows you to quantify the different threats and thus help prioritise their mitigation.
• OCTAVE. This framework is implemented in three phases:
  • Creating a profile of all assets and their threats
  • Identifying vulnerabilities
  • Creating an efficient risk management strategy
• Data-Centric Systems Threat Modeling. This NIST framework has four steps for performing threat modeling:
  • Identification of the system and information of interest.
  • Selection of the attack vectors to be included in the model.
  • The definition of security controls to mitigate the attack vectors.
  • Analysis of the threat modeling.
• VAST. It allows visual and scalable modeling focusing on three pillars: automation, integration and collaboration.

There are other methodologies for threat modeling, such as Persona non grata, which focuses on creating a profile of potential attackers, or Attack trees, which graphically represent vulnerabilities, threats and entry points. This is a good example of the existing methodological material.

5.2. Tools

Beyond the frameworks we have just outlined, there are some tools in the cybersecurity field to implement them successfully, automating tasks and facilitating the modeling of threats throughout the life cycle of the software, device or system.

Some of these tools to carry out threat modeling are:

• IriusRisk. A tool that has adaptable questionnaires and guides professionals through key aspects such as application architecture.
• ThreatModeler. This tool serves to automate threat modeling and is directly related to VAST.
• OWASP Threat Dragon. The OWASP Foundation has an open-source tool for creating diagrams to easily visualise components and attack surfaces. It is used to record threats and decide how to mitigate them.

The combined use of methodologies and tools enables effective threat modeling tailored to each company’s needs, business objectives and resources.

6. Facilitating business security decision making

Ultimately, threat modeling is a process that helps make security decisions based on data and a comprehensive analysis of the risks associated with a system or software.

Business decision-making involves professionals who can be something other than cybersecurity experts.

Threat modeling graphically represents the threats to combat and their criticality level to the organisation. This helps managers to make strategic decisions that help protect business assets from security incidents.

Threat modeling can also be used as an assurance argument, demonstrating that threats are effectively tracked, and security controls are implemented to reduce risks.

Beyond its potential for decision-making, the Threat Modeling Manifesto highlights that threat modeling contributes to:

• Installing a culture of continuous problem-finding and problem-solving.
• Foster collaboration between individuals and teams.
• Establish a holistic view of security rather than snapshots of specific aspects or moments.
• Continuously work on perfecting security controls and countermeasures.

In short, threat modeling is a comprehensive IT risk analysis process that seeks to graphically represent all the elements to be considered, design efficient measures against potential threats and evaluate security risks from the early stages of development and throughout the entire life cycle to prevent incidents.

Houses do not start with the roof but with the foundations, taking care of every column and wall. The same applies to cybersecurity. So starting with a secure design is crucial to minimise risks.