Save money brushing your teeth - unveiling the Threat Modeling - part 1 of 3

Threat modeling is a cyclic process to avoid future problems. Just like brushing your teeth, that prevents decay, tartar or dental calculus, threat modeling should be a daily proess, implemented in the software development lifecycle to prevent incidents promoted by cyber threats. This is why understanding Theat Modelling is crucial for effective cybersecurity.

In this first article in a series of three about Threat Modeling we will drill down the process, explaining its objectives, importance, the step-by-step process for creating a model, as well as the security requirements and controls associated with threats so the articles will be divided into the following themes:

1. Introduction, motivation, and theory of threat modeling (this post)
2. Applying threat modeling with an offensive perspective in practice and developing security controls and requirements
3. How to test the proposed requirements and controls to ensure the application is secure

1. Introduction

Threat Modeling is a process in software development where a representation of the proposed application is created, starting with the mapping of assets, structuring and understanding the entire data flow from the moment data enters, how it is processed, and how it is stored or returned. The goal of threat modeling is to plan and develop strategies to analyze and ensure the overall security of an application.

By mapping assets, which include software, applications, systems, networks, distributed systems, mobile applications, and Internet of Things (IoT) devices, and understanding how the data flow operates, it is possible to identify and address potential vulnerabilities. Threat modeling clarifies how these vulnerabilities could exist in the designed application.

According to the Threat Modeling Manifesto, "Threat modeling analyzes representations of a system to highlight concerns about security and privacy features" and according to OWASP, we can ask four questions that help plan and organize all actions in threat modeling:

1. What are we working on?
2. What is the likelihood of something going wrong?
3. What can be done about it?
4. Was the work good enough?

2.  Why Perform Threat Modeling?

According to IBM's 2024 Cost of a Data Breach Report, the average cost incurred by an organization due to a breach caused by a cyber threat is $4.88 million. IBM also lists the most frequent initial attack vectors, as shown in Figure 1.

Among these initial vectors presented, all could be addressed in a threat modeling process to put in place controls that prevent such attacks. Obviously, it's not always straightforward to create controls for these vectors, especially those involving human factors like Phishing and Stolen or Compromised Credentials, or even Unknown Vulnerabilities (zero-day). However, some of these vectors are directly addressable through security controls and could have been anticipated in a comprehensive threat modeling process, preventing the risk from materializing.

For example, consider the initial vector "Cloud misconfiguration," with an average cost of $3.98 million. According to CheckPoint, some examples of incorrect security configurations include:

• Default accounts and passwords
• Publicly accessible assets
• Excessive access
• Unnecessary resources enabled
• Unencrypted storage
• Missing updates and patches

Each of these items would be present in a comprehensive threat modeling process, which would subsequently produce a security requirements document to address these potential vulnerabilities, furthermore these requirements would be described as part of the development, ensuring that items are only deployed to the production environment if the controls are implemented.

3. Application of Threat Modeling

Threat modeling should be included in the software development lifecycle to help reduce organizational risks and ensure security during development. Typically, the software lifecycle is divided into six stages:

1. Planning
2. Analysis
3. Design
4. Development
5. Testing & Integration
6. Maintenance

Threat modeling fits into Stage 3 - Design, right after the initial architecture diagrams of the application have been created. At this stage, threat modeling identifies assets and threats that, depending on the context, can be addressed while still in the design phase, through changes in the architecture or minor additions that allow for the inclusion of controls. Anticipating the identification of risks facilitates the implementation of controls, as development has not yet begun. It is also possible to modify the threat model during other stages if it is later identified that changes in the architecture are necessary, assessing whether this new addition introduces any risk to the organization and updating both the threat model and the requirements document accordingly.

Threat modeling is an iterative process. As the system evolves or new threats emerge, it is important to revisit and update the threat model regularly.

4. Prerequisites for Threat Modeling

As the basis for the threat modeling process, architecture diagrams and use cases of the application project are used. Any document from the design phase of the project can serve as input for developing the threat modeling process, such as:

• Architecture Documentation: Information about the system architecture, including diagrams, data flows, components, and interfaces.
• Asset Information: Valuable assets that need to be protected, such as sensitive data, intellectual property, and more.
• Business Logic Information: The business logic of the application, including flows, validations, and key inputs and outputs.
• Supplementary Information: API documentation (Swagger), data flow diagrams (Figma), context explanations, and other information that may aid in understanding the application.

Understanding sessions may be conducted before starting the threat modeling process.

5. Threat Modeling Patterns

There are various threat modeling methodologies today, each following a desired pattern. It can be said that there is no single way to perform threat modeling, meaning there is no universal method. The goal is to determine the potential threats that may exist in a given analyzed space. We should then create a model that is useful and effective, well-structured, making the process more efficient and manageable.

For the threat modeling process to be useful and effective, we need to define the scope of the work, identify vulnerabilities and potential existing threats, assess risks and implement countermeasures to address those vulnerabilities. With these pillars in mind, we can effectively begin the threat modeling process.

5.1. Trust Boundaries

In the threat modeling process, trust boundaries are established to define the attack surfaces of assets, where threats might be identified. The concept of a trust boundary can be used to identify points where data flows in and out may encounter access control. Within these boundaries, assets trust each other, and due to this trust, security controls may be less robust.

In a Zero Trust scenario, where it is assumed that any asset could be compromised, trust boundaries cease to exist, and each asset no longer trusts the others, always requiring access control or some specific security control for data flow. However, even in this scenario, there are different levels of trust and establishing these different levels in the design of threat modeling helps in understanding the system and the possible threat levels. For example, a resource exposed to the internet may be vulnerable to different threats than a resource on an internal network. This can be achieved through containers, which essentially define where one environment ends and another begins but does not necessarily indicate a trust between the components within it.

5.2. Threat agents or potential vulnerabilities?

According to NIST, a threat can be defined as “any circumstance or event with the potential to negatively impact organizational operations, organizational assets, or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.” Threat agents can be defined as “the intent and method directed at intentionally exploiting a vulnerability or a situation and method that may accidentally trigger a vulnerability.” Some threat modeling methodologies focus on mapping WHO would be responsible for compromising the involved assets, while others focus on defining WHAT could be exploited in the assets, given the conditions for occurrence.

In our analysis, both aspects are important to define, but the focus should be on WHAT, that is, the event that could happen to the assets, so that controls can be more easily mapped. For example, in an internal network scenario where credentials are stored in source code, instead of mapping that the threat agent would be the developer (internal employee) or their compromised account, it is more useful to focus on the threat being exposed credentials in the code. This way, the control is directed towards this threat, which in this case would be: using a password vault.

6. Components of Threat Modeling

6.1. Diagrams

Create diagrams to help to understand the flow of data in the network. To create the diagram below, you can use a free platform, such as Drawio.

6.2. Interaction

Identify entry points that an attacker might use to interact with the application. These can be represented by arrows.

6.3. Assets

Map and identify the assets in the threat modeling project. This includes the following assets:

Physical Assets:

• Hardware equipment (servers, computers, mobile devices)
• Physical facilities (offices, data centers)

Digital Assets:

• Software and applications used in the project
• Critical data and databases
• Important documents and files

Intangible Assets:

• Intellectual property (patents, copyrights, trademarks)
• Team knowledge and expertise

6.4. Trust

An important point is to clearly define trust levels when granting access permissions to external users of the application. It is essential to ensure that permissions are assigned based on the level of trust the application has in each user, to protect the integrity and security of the system.

We conclude that data flow diagrams are frequently used to map what we are working on and help us detect privilege boundaries, assets, and trust rules between assets. This process of breaking down the architecture significantly aids us in constructing a Threat Model.

7. Threats Categorization

For threat determination, various methodologies and frameworks can be used to help map potential threats in threat modeling. Below are some models that can be utilized in a threat modeling project.

7.1. MITRE ATT&CK Framework

• Description: A widely used knowledge model for describing the techniques and tactics employed by adversaries. It includes a detailed list of techniques, tactics, and procedures (TTPs) that can be used to categorize threats.
• Usage: Helps map adversarial activities across different phases of an attack and understand attacker behavior.

7.2. STRIDE model

• Description: A threat modeling methodology developed by Microsoft. STRIDE is an acronym for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.
• Usage: Helps in identifying and categorizing threats based on the types of attacks that can be carried out.

7.3. DREAD

• Description: A threat classification model used to assess the risk associated with each threat. DREAD is an acronym for Damage, Reproducibility, Exploitability, Affected Users, and Discoverability.
• Usage: Helps prioritize threats based on their severity and potential impact.

7.4. Common Vulnerability Scoring System (CVSS)

• Description: A scoring system that evaluates the severity of security vulnerabilities based on metrics such as ease of exploitation and potential impact.
• Usage: Helps categorize and prioritize potential vulnerabilities according to their severity and risk.

Each of these methodologies provides a different perspective and can be used in a complementary way for threat analysis. Depending on the context and objectives, one or more of these approaches can be chosen to categorize and manage threats effectively.

According to OWASP, the most commonly used frameworks in the threat modeling process are the STRIDE methodology and kill chains, including MITRE ATT&CK. The goal of using these frameworks is to assist in identifying and categorizing threats from potential attackers. These efforts are interconnected because, by combining the asset mapping stage using diagrams with threat detection methodologies, we can identify potential targets for an attacker. This helps us understand the attacker’s mindset, protect sensitive data, and defend the security triad: Confidentiality, Integrity, and Availability (CIA).

Therefore, using frameworks to identify and categorize threats is crucial for protecting data and applications. Integrating asset mapping with threat detection methodologies helps anticipate and mitigate risks and attacks, with the aim of ensuring the security of the CIA (Confidentiality, Integrity, and Availability).

8. Definition of Controls and Countermeasures

The process of implementing countermeasures in the project is crucial, as it is essential to protect and secure applications against threats and risks. This process helps neutralize identified vulnerabilities, ensuring that security flaws are properly addressed and cannot be exploited by an attacker. Implementing countermeasures includes integrating mechanisms that assist in detecting suspicious activities and potential attacks.

According to OWASP, “The risk mitigation strategy may involve assessing these threats based on the business impact they represent. Once the potential impact is identified, options for addressing the risk include:

Accept the Risk: In this criterion, accepting the risk means deciding not to take any action to mitigate or eliminate it. It is very important to document who made the decision to accept the risk. This ensures that there is a record of the associated responsibility.

Eliminate the Risk: Eliminating the risk involves completely removing vulnerabilities. This means removing or updating software, services, etc.

Mitigate the Risk: Mitigation is a way to implement measures to reduce the impact or likelihood of a risk. However, it is important to note that this does not eliminate the risk but makes it more manageable.

Transfer the Risk: If the organization does not have a specialized information security team, it may be acceptable to transfer the risk to an insurer, which can cover losses related to security incidents, or to a client with experience in the area. This means that the responsibility for managing and mitigating the risk is shifted to an external entity with the necessary capacity and resources.

Implementing countermeasures is used to manage vulnerabilities and understand risks, including accepting, eliminating, mitigating, and transferring the risk, considering factors such as the probability of impacts and costs. 

The decision should be based on an analysis of the business impact and should measure the effectiveness of the solutions.

9. Being a Threat - the best way to anticipate risks

Of course, dentists understand the need to brush our teeth, but is there anyone who could identify better than them which teeth are vulnerable? If only we could think like a bacterium, visualizing which tooth it prefers to cause decay… In the cybersecurity field we can do that, behaving like a threat to anticipate attacks.

As seen, threat modeling is a creative exercise, and the more the analyst understands about cyberattacks, the more effective the threat modeling will be. An offensive mindset is extremely relevant at this point, as when visualizing a component, a hacker immediately thinks about the paths an attacker might use to compromise the system. For example, if an application involves the use of Spring Boot, someone experienced in attacks on this component would already know that critical actuator endpoints like heapdump and env should never be exposed, as this would allow access to critical data, including credentials for other systems. Someone who has never explored such vulnerabilities might research common attacks on Spring Boot but might not fully understand the exploitation, potentially resulting in incomplete security controls and requirements.

Thus, threat modeling within the software development lifecycle is a crucial part of organizations that take cyber risk seriously, becoming an essential part of software engineering.