The Threat Modeling Process

While threat modeling is becoming an important part of the security lifecycle, we at Harness are also in the process to bake threat modeling in our software delivery lifecycle (SDLC). In this blog, we’ll provide a general overview of the threat modeling process we use, its challenges, benefits, and a high-level look at the steps within the process. 

What is Threat Modeling?

Threat modeling is a process to identify security needs, locate threats and vulnerabilities, assess their severity, and prioritize solutions. 

As OWASP defines,

Threat modeling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value.

A threat model is a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through the lens of security.

Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, distributed systems, Internet of Things (IoT) devices, and business processes.

Threat modeling looks at a system from a potential attacker’s perspective, as opposed to a defender’s viewpoint. Making threat modeling a core component of our SDLC can help increase product security.

What is the Benefit of Threat Model?

You cannot patch a vulnerability you cannot see, and you cannot defend against an attack you don’t know is coming. However, at a high-level, these are the issues that threat modeling can actually address. It equips your security team with a standardized means of both shoring up existing architecture against attacks and evaluating new security additions to your technological ecosystem hence organization has overall enhanced security posture.

The primary benefit of threat modeling is that design flaws can be addressed before a single line of code is written, thereby reducing the need to redesign and fix security issues in code at a later time hence saving cost,time and resources. Since this is a discussion which involves everybody, helps achieve greater collaboration between developers, architects, security professionals and business stakeholders.This practice helps organizations build a security-first approach into their SDLC. There by inching a step towards compliance and regulatory requirements.

There's also value in  conducting a threat model after deployment. Understanding the issues in the current deployment provides best practices for  future security architecture strategy. Monitoring weaknesses also allows for faster and more effective remediation.

Who is Responsible for Creating a Threat Model?

The entire team – including security architects, developers, testers, and DevOps teams — have a key role to play in developing a threat model:

• Entire team first identifies the threat applicable to their system/software during the threat modeling exercise and publishes a threat model report.
• Development team then uses the threat model to implement controls and write secure code.
• Testing teams use the threat models to not only generate security test cases but also to validate the controls that need to be present to mitigate the threats identified in the threat models.
• Operations teams can use threat models to configure the software securely so that all entry points have the necessary protection controls in place.

What are the Challenges with the Threat Model?

Though the benefits of threat modeling are extensive, it does come with some challenges, the most common of which are:

• Can be a time-consuming process since it involves your security team start from design phase
• Requires a fairly mature SDLC to accommodate all the requirements from threat modeling
• Requires the training of employees to correctly model threats and address vulnerability

Threat Modeling Steps

Broadly speaking, the process of threat modeling involves five essential steps

1. Identify and define security objectives
2. Analyze and decompose the application
3. Identify and rank potential threats
4. Establish countermeasures and mitigation strategies
5. Generate a comprehensive  threat modeling report

Step 1: Identify Security Objectives

Security objectives are goals and constraints related to the confidentiality, integrity and availability of your application. They include:

• Confidentiality: This includes protecting against unauthorized information changes.
• Integrity: This includes preventing unauthorized information changes.
• Availability: This includes providing the required services even while under attack.

Step 2: Decompose the Application

The second step in the threat modeling process is concerned with decomposing the application, or gaining a fundamental understanding of the application and how it interacts with external entities. This involves:

• Identify use cases, define application entry points and trust levels
• Identify actors, assets, services, roles, and data sources.
• Document data movement (in transit or at rest) via data flow diagrams (DFDs). Show trust boundaries, including existing as well as proposed changes.
• Identifying areas that the attacker would be interested in.

This information is documented in a resulting threat model document. It is also used to produce DFDs for the application. The DFDs show the different user paths through the system, highlighting the access privilege boundaries.

Step 3: Determine and Rank Threats

Identify possible attackers or threat agents that could exist within the target of evaluation. Use Means, Motive, and Opportunities to understand Threats posed by Attackers. Then, associate threat agents with system components they can directly interact with.

Work on minimizing the number of threat agents by:

• Treating them as equivalent classes
• Considering the attacker’s motivation when evaluating likelihood
• Consider insider threats

It has below sub sections:

• Threat categorization
• STRIDE
• Threat analysis
• Ranking of threats
• DREAD
• Qualitative risk model

Step 4: Determine Countermeasures and Mitigation

Identify risk owners and agree on risk mitigation with risk owners and stakeholders. Provide the needed controls in forms of code upgrades and configuration updates to reduce risks to acceptable levels.

The risk mitigation strategy might involve evaluating threats from the business impact they pose. Once the possible impact is identified, options for addressing the risk include:

• Accept: Decide that the business impact is acceptable
• Eliminate: Remove components that make the vulnerability possible
• Mitigate: Add checks or controls that reduce the risk impact, or the chances of its occurrence

Step 5: Create Threat Modeling Report

In this step we create a detailed threat modeling report which can be shared with respective business/function owners.

The report can contain detailed information about the risks identified, risk score, mitigation strategy, impact, threat targets etc. It can also contain tracking references of bugs created in your issue tracking system to tackle each of the threats. 

Conclusion 

This provides a concise summary of the key aspects, significance, and participants involved in the threat modeling process. In an upcoming part 2 of the blog post on this topic, we will delve into each step in greater depth and examine how Harness can assist you achieve part of this process.

‍