What is the process of identifying assets and threats in devices or networks?

Last Updated: August 23, 2021

Threat modeling is defined as the process of proactively identifying and addressing potential threats to an organization’s systems based on inputs from both business and technical stakeholders. It is usually done while designing a product or a new feature to avoid the costs of security breaches in the future. This article covers what threat modeling is, the five steps involved in the process, and seven best practices for threat modeling in 2021.

Table of Contents

What Is Threat Modeling?

Threat modeling is the process of analyzing various business and technical requirements of a system, identifying the potential threats, and documenting how vulnerable these threats make the system. A threat refers to any instance where an unauthorized party accesses sensitive information, applications, or network of an organization.

The aim of the threat modeling process is to get a clear picture of various assets of the organization, the possible threats to these assets, and how and when these threats can be mitigated. The end product of threat modeling is a robust security system.

In April 2020, video communication app Zoom’s stock prices dropped from $159.56 to $111.41. Many of Zoom’s security flaws were exposed once its user base increased — most of which Zoom hadn’t anticipated. In July 2020, Twitter was hacked by targeting a group of employees with internal system access, which resulted in a loss of  $117,000 to users who had sent money over bitcoin at that time.

With security attacks like these, there is a loss of capital and trust for a brand. Incidents of malware attacks are not going to stop any time soon. Cybersecurity Ventures predicts cybercrime damages will cost the world around $6 trillion annually by 2021. This is where the threat modeling process can mitigate these risks to a great extent. 

Identifying an encryption algorithm used to store user passwords in your application that is outdated is an example of threat modeling. 

• • Vulnerability is the outdated encryption algorithm like MD5.
  • Threat is the decryption of hashed passwords using brute force.
  • Attacker is the hacker trying to sell personal information online.
  • Mitigation tactic is the change in an encryption algorithm to something more modern and robust.

Threat modeling can be approached in three different ways: 

1. 1. Asset-centric: Take stock of various assets and analyze the vulnerability of each. 
   2. Attacker-centric: Think of possible attackers, what asset each would want to attack, and how.
   3. Software-centric: Focus on the system design, how the data flows between various layers, and how it is configured. 

Now that you know why your organization needs to make threat modeling a standard practice. Let’s deep dive into the steps involved in setting up a good process.

Threat Modeling Process: 5 Key Steps

The holistic nature of threat modeling comes from the fact that it doesn’t just involve programmers. For effective threat modeling, you need input from the following stakeholders:

1. 1. Business stakeholders for providing the business impact of the application.
   2. Architect to supply an overview of the app ecosystem.
   3. Programmers for code-specific input like frameworks used, coding guidelines, etc.
   4. DevOps to give details of server and network configurations.
   5. Project manager for resource management.

It is also advisable to recruit a security consultant to steer the threat assessment exercise. Remember that the key objective of threat modeling is to align your business objectives with technical requirements. This means, besides the business goals, you also need to consider compliance requirements as well. There are five key steps associated with any threat modeling exercise.

5 Key Steps of Threat Modeling Process

1. Set objectives (What do we want to accomplish?)

Before you get started with threat modeling tools and methods, you need to be sure of what you want to achieve from this exercise. Usually, goals are set keeping in mind that your application must have:

• • Confidentiality to protect data against unauthorized disclosure
  • Integrity to prevent unauthorized information changes
  • Ability to render required services even while the system is under attack

Make a note of your committed SLAs in terms of availability and performance. What trade secrets and intellectual properties do you need to protect? Perhaps the most important question at this stage is how much time and money do you want to spend on threat modeling?

2. Visualize (What are we building?)

This is the step where you document the different components that make up your system. A clearly documented overview of your entire application will go a long way in making the process simpler. This includes noting down use cases, data flows, data schemas, and deployment diagrams. 

There are two types of visualizations you can build.

• Data flow diagram: It depicts how data is designed to move through your system. It shows the operational level and clearly displays where data enters and exits each component, data stores, processes, interactions, and trust boundaries. 
• Process flow diagram: It depicts how users interact and move through various use cases. It is at an application level. While DFDs focus on how your system works internally, PFDs concentrate on user and-third party interactions with your system. You can choose either one or use both.

Now that you’ve identified your application’s most important actors and assets, it is time to move on to threat assessment.

3. Identify threats (What can go wrong?)

In the previous step, you built the diagrams to understand your system. In this step, you will need to analyze these diagrams to understand the actual threats. At this stage, you need to figure out the various ways in which your assets can be compromised and who the potential attackers are. There are many methods of doing this. We will be covering the six most prominent methods for threat assessment modeling in the next section. 

4. Mitigate (What are we going to do about it?)

Once you’re done identifying threats, you will end up with a master list or library of threats associated with each asset and its operations and a list of possible attacker profiles. Now you need to figure out which of these threats your application is vulnerable to. 

Let’s consider our previous example in the first section of the article. You will observe that ‘password hack using brute force’ was the threat, while ‘using MD5 algorithms to store passwords’ was the system vulnerability. Once vulnerabilities have been mapped out, you need to analyze the risks associated with each of them. Based on this risk analysis, you can deal with the vulnerabilities in the following ways: 

1. 1. Don’t do anything (too low risk or too difficult to make the associated threat)
   2. Remove the feature associated with it
   3. Turn the feature off or reduce the functionality
   4. Bring in code, infrastructure, or design fixes

You will also be creating a log of vulnerabilities to be subsequently addressed in future iterations.

5. Validate (Did we do a good job?)

During validation, you check if all vulnerabilities have been addressed. Have all the threats been mitigated? Are the residual risks clearly documented? Once this is done, you need to decide the next steps to manage the identified threats and decide when the next iteration of threat modeling will be. Remember that threat modeling is not a one-time activity. It needs to be repeated either at scheduled intervals or during specific milestones in the application development. 

Top 6 Threat Modeling Examples and Methods

While all threat modeling methods use the five steps described above, the actual way they go about threat assessment differs. There are several methods available right now. This section covers the five most popular ones. 

1. STRIDE

Popularized by Microsoft, this method gives a set of threats to answer the question ‘what can go wrong?’. It is best for organizations that are highly development-focused and new to threat modeling. It is developer-focused. STRIDE is an acronym that stands for Spoofing identity, Tampering with data, Repudiation, Information disclosure,  Denial of service, and Elevation of privilege. 

Each one is a direct violation of the system. For example, spoofing identity is a violation of authenticity, while tampering with data violates system integrity. Participants in the threat modeling process try to create abuse scenarios that fall under each threat. While this method is the most mature and easy to use, allows proper documentation, and is ideal for new threat modelers, it is also time-consuming and can lead to redundancy.

2. Trike

Trike is a method known for its unique threat assessment model. It is best for organizations looking for a compliance-focused methodology to satisfy security audits. The following steps are involved in Trike-based threat assessment:

1. 1. Create a requirement model. This model consists of a risk score attached to each asset by the stakeholders.
   2. Create an actor-asset-action matrix. 
   3. Against each actor in the system, assign if each of the CRUD operations are allowed, disallowed, or allowed with rules. 
   4. Each element in the data flow diagram (created as part of the ‘visualize’ step) is mapped to the set of actors and assets in the matrix. 
   5. Enumerate threats by iterating through each element and figuring out if it falls under the elevation of privilege or denial of service.
   6. Now, using this threat matrix and the requirement model, assign risk weightage to each asset. This way, you also understand the threat exposure of each asset, action, and role.

Although Trike allows built-in risk management, it is not scalable in nature.

3. Vast (Visual, agile, and simple threat)

VAST is a method created by ThreatModeler, an automated threat modeling platform. The biggest advantage of this method is that it works with automation, integration, and collaboration in mind. It is best for large enterprises that need threat modeling to work across multiple teams and products. In this method, two threat models are built to address both the development and infrastructure teams:

• • Application threat model: This looks at the application from an architectural point of view. It analyzes threats that may result from the system interacting with users and other integrated systems. It is done at the design level.
  • Operational threat model: This looks at the application from an infrastructure point of view. It helps put security controls in place during mitigation. The DevOps team usually works on this.

Because it follows two independent models, VAST can be plugged into the existing workflow. This makes it agile-friendly. It is scalable, automation-friendly, and can be plugged into agile. However, this platform is relatively new and does not have enough documentation.

4. Attack trees

Attack trees are a way of representing the potential threats to the system. This is an attacker-centric approach where you think of each attacker as a persona with goals and skill sets. It is best used for complex systems. Attack trees work in the following fashion:

1. 1. Each root node in this tree is an attacker’s goal. 
   2. Each leaf node is the potential means of reaching this goal.
   3. Each node is then associated with a vulnerability, which, in turn, is evaluated for impact.
   4. Based on vulnerability and impact, a countermeasure is put in place.

This structure makes it very easy for developers and testers to create use cases. It also helps architects and project managers evaluate the security cost.  

Most attack trees also include the method of attack and required conditions. It is easy to create reusable ‘attack patterns’ based on attack trees. Threat mitigation becomes a lot easier when you can identify common attack techniques using these patterns. It is usually combined with STRIDE or CVSS. 

The pros of this system include reusable security components and being easy to use. However, there are no common guidelines for assessing each threat. It requires a cybersecurity expert since there is the possibility that threats can be easily overlooked. 

5. CVSS (Common vulnerability scoring system)

Usually used in conjecture with other methods, CVSS is a risk calculator developed by NIST. CVSS assigns a severity (low/medium/high) to each vulnerability discovered in the threat assessment stage, based on predefined metrics. 

These predefined metrics are divided into three groups:

1. 1. Base metric group: Privileges required, scope, user interaction
   2. Temporal metric group: Code maturity
   3. Environmental metric group: Modified base metrics

Based on the organization’s assets and security goals, an analyst usually assigns a severity to each of these metrics. A CVSS score is derived from these assigned values using [the online calculator.] CVSS allows standardized measuring but doesn’t take the environment into consideration and cannot be used standalone.

6. PASTA

PASTA stands for Process for Attack Simulation and Threat Analysis. It is a seven-step risk-centric methodology. It is best for organizations that want to align their business strategies with product security. It looks at threats as a business problem. 

PASTA essentially follows the five key steps mentioned above, but with greater attention to detail. With PASTA, you don’t just set business objectives, but you create a ‘Risk Portfolio’ of the organization. This is based on business, financial, and operational objectives, superimposed with compliance requirements.

The threat analysis will be comprehensive with the following steps in place:

1. 1. List known threats: This isn’t just application-level threats; it also includes human resource threats.
   2. Gather threat intelligence: Internally, this is done with existing logs from all possible venues — firewalls, servers, DB, and incident reports. Externally, this is done by utilizing the threat libraries available or by contacting security service providers.

Once the list of threats is documented, an attack tree is created. Vulnerabilities are attached to each threat and ranked using something like CVSS. Countermeasures are then decided based on vulnerability rank, attack pattern, and attack history gathered by threat intelligence.

This methodology allows more collaboration between teams, has risk management encapsulated in the process, and results in robust security documentation. However, on the flip side, it is also laborious and expensive. 

So far, we’ve covered the five key steps involved in robust threat modeling and what choices you have when it comes to actually analyzing threats and vulnerabilities. There are threat modeling tools available for each of these individual steps. You can also use threat modeling platforms that allow you to perform all these steps synchronously.

Top 7 Best Practices for Threat Modeling in 2021

Now that you know the steps to create a secure application proactively, here are a few practices for a robust threat modeling process.

Best Practices for Threat Modeling

1. Keep reiterating

Considering the time and effort threat modeling requires, it is tempting to do it just once and never look back. But this is the biggest mistake you can commit. Functionalities, assets, roles, and use cases are bound to change in any application. Always create a schedule based on time intervals or milestones in the SDLC process. 

2. Create an easily accessible document

The most important part of threat modeling is having a clean, exhaustive document in the end. This document must not be cluttered and should be formatted well enough to absorb the changes that come with the iterations. When a change is made, do not forget to update all stakeholders. Also, share this document as broadly as possible. This serves as the base for any work taken up by your developers, architects, and product managers. 

3. Integrate the model into your existing workflow and DevOps process

Wherever possible, integrate the threat modeling steps into your existing workflow. For example, if your company uses JIRA and has opted for the VAST method of threat assessment, make sure the effort involved in creating the application threat model is tracked in JIRA. 

4. Do not try to tackle all vulnerabilities in one go

Once you have the list of vulnerabilities, do not rush to implement the countermeasures for all of them. Calculate the costs of putting the security controls required to mitigate each threat. If the cost of implementing these controls is more than the cost of the anticipated threat, you will not gain anything. Ensure that you maintain a robust log of vulnerabilities. Do not let the associated tech debt pile up.

5. Set a time frame for the threat modeling activity

The sheer magnitude and scope of this activity can make it never-ending. This is why it is important to determine your objectives, time, and budget scope before you begin. 

6. Use existing resources

While it is tempting to build your own custom threat library, this is not a good idea. It might end up with critical vulnerabilities being missed. There are many libraries available that you can borrow — CAPEC, OWASP, and WASC-TC are a few resources. Take advantage of existing specifications such as the UEFI spec—leverage existing automation tools such as Intel’s HBFA. 

7. Decide on which method to use based on your app and business

There is no one-size-fits-all threat modeling process. If you have a complex system running across multiple platforms, STRIDE alone might not do the trick. If your organization already thrives on agile, VAST makes sense. Analyze your requirements carefully and choose the right method.

Wrapping up

It is evident when you go through these recommendations that threat modeling can easily end up becoming a time- and resource-consuming exercise. This is why you must follow the above best practices. A robust, secure application is undoubtedly a source of comfort and confidence for investors, stakeholders, and consumers alike. 

With the world becoming increasingly digital, cyber attacks have become more common and frequent, and, as such, threat modeling is no more an optional activity. It is high time that security efforts catch up with our application’s designs and development life cycles. Even legacy systems cannot be exempt from the process. 

Did you enjoy reading this article? Comment below or let us know on LinkedIn, Twitter, or Facebook. We’d love to hear from you!

What is the process of identifying assessing and controlling threats to an organization's cybersecurity called?

What is the process of threat modeling?

What is threat identification procedure?

What are 4 methods of threat detection?