Application Threat Modeling

February 28, 2024

Hackers often use advanced techniques to break into companies’ networks and steal or compromise sensitive data
Application threat modeling identifies threats and vulnerabilities that pose a risk to functionality or data
Several methods are described here

Modern hackers often use advanced techniques such as endpoint security evasion, bypassing intrusion detection systems (IDS) and web application firewalls (WAF) to break into companies’ networks and steal or compromise sensitive data. Also, it may not be necessary to gain full administrative/root privileges on an application server for an attacker to accomplish these goals. As a result, it’s critical to secure applications and other necessary data they use

A variety of techniques inform the secure software development lifecycle (SDLC), with one of the most important being application threat modeling (which is implemented during the design process).

Application threat modeling visualizes an application's attack surface to identify threats and vulnerabilities that pose a risk to functionality or data. By decomposing the application architecture into its security-relevant components, teams can better understand the various threats and risks the application might face.

Development teams should understand that threat modeling isn’t a one-time activity – it’s iterative. When the application changes (e.g., applying bug fixes, introducing new features, optimizing the application for quicker load, etc.), the threat model needs to be updated.

Why Is Threat Modeling Necessary?

When building an application, performing threat modeling at the beginning of the secure SDLC process helps development teams identify attack surfaces and entry points that an attacker could use to breach the security of the application. Performing threat modeling during the design phase is, on average, cheaper than doing it at a later stage because of the resulting remediation costs.

For example, correcting an architectural flaw during the design phase after threat modeling is much easier than during the development or testing phases after significant engineering time has already been spent.

Threat modeling helps structure developer thinking about system security by adopting an attacker's perspective. Documentation from this process provides application teams with a useful "defender analysis" of probable attacker profiles, the most likely attack vectors and the assets most desired by adversaries.

How to Perform Threat Modeling

There is no one definitive way to perform threat modeling. Several methods can be used to achieve the same objective. The four main steps are noted here.

Figure 1: Threat Modeling Steps

Decompose the application – Studying the application and its components, features and data flow levels and understanding its interactions with external entities
Identify and determine the threats – Identifying various entry points and potential attack surfaces that an attacker can use. For example: In the case of a banking application, the following are some of the threats that can be listed:
- Attacker can steal money from another beneficiary
- Attacker can perform a reverse money transfer
- Attacker can steal credentials by sniffing or using other methods such as phishing or social engineering
- Attacker can use misconfigurations on the server to perform a DoS attack to render the application inoperable
- Attacker can perform common application attacks such as cross-site-request-forgery (CSRF), privilege escalation, SQL injection, etc., to compromise the security of the application

Identify countermeasures – After documenting threats and attack surfaces, it is important to select and design appropriate countermeasures. Some of the countermeasures that can be implemented for our banking application are:
- Implement proper input/output validation for all requests. Use parameterized queries, anti-CSRF tokens etc., to prevent common application attacks
- Implement fraud detection and use multi-factor authentication (MFA) when transferring money to other beneficiaries, thus preventing money from being stolen, or when trying to perform reverse transfers
- Use HTTPS and MFA, such as one-time passwords (OTP), to prevent credentials from being stolen
- Implement a web application firewall (WAF) and other anti-DoS solutions to prevent attacks on system availability

Rate the threats – Each threat identified should be rated based on the potential damage it could cause. Formulas such as Risk = Probability * Damage Potential can be used to calculate the risk. Other methods, such as DREAD, can be used to determine a risk value that can be mapped against a risk matrix. Qualitative classifications such as Critical / High / Medium can be assigned based on the matrix.

Benefits of Threat Modeling

Threat modeling helps development teams adopt an attacker's mindset and think offensively to understand better the value of a system, its assets and potential threats. This aids dev teams in designing a more secure system resistant to attacks.

The benefits of threat modeling include:

Threat modeling complements other security activities, such as code reviews and penetration testing, when designing more secure system architecture
It helps engineering teams understand the application’s interactions with internal and external systems
It helps in defining the security posture of the application
It identifies the application’s potential threats and vulnerabilities
When performed at an initial stage, it helps in identifying architectural flaws sooner
It allows development teams to make security trade-offs and determine what risks can be accepted and which ones should be fixed or mitigated

Types of Threat Modeling

Threat modeling can be classified into the following categories:

Asset-centric threat modeling: In this approach, development teams identify the assets that need to be protected and consider the various things that can go wrong. When used independently, this approach doesn't often work out well and requires a good amount of experience to determine the right assets to be protected.
Attacker-centric threat modeling: Here, more focus is placed on attackers and their capabilities. This approach is also less useful, as it’s challenging to know the capabilities of the attacker accurately.
Software-centric threat modeling: The application is decomposed, as mentioned in the methodology section above, to understand the system. Once the system is mapped, teams can look at boundaries between different components (e.g., DMZ, Internet, etc.) and understand what can go wrong.

Software-centric threat modeling has become the de facto method for threat modeling in the last few decades.

Implementing Threat Modeling in an Agile World

With agile development methodologies and DevOps taking center stage in recent years, implementing traditional threat modeling to modern workstreams requires a significant cultural shift and likely cause too much friction. In these cases, embracing a security-focused mindset throughout the software development lifecycle is better. Unfortunately, threat modeling cannot be fully automated, as it's a mostly manual activity.

Agile threat modeling is, by necessity, different than in waterfall or other software development methods. As the agile methodology is based on fixed timeframes of work (sprints), an approach like a time-boxed STRIDE methodology can be applied. In this case, each threat modeling activity is given a specific duration of time (e.g., 30 minutes) and focuses only on a small subset of the application.

Agile threat modeling is performed by using short workshops that are scheduled within each sprint. Due to short release cycles, team collaboration and brainstorming play an important role here. The workshop activities are:

Figure 2: Agile Threat Modeling Steps

Threat modeling across sprints phases:

Sprint Planning Phase	Sprint 1 – N (last sprint)	Final Release (Go-Live)	Post-Release Updates
Complete threat modeling and release it to the team based on the overall design	Make changes to the threat model as the design or source code changes, and new user stories invalidate the previous model	The threat model should reflect the final operational system state and the controls as applied at launch	Update the threat model as security-relevant changes and controls are applied

Figure 3: Summary of a threat model leveraging the agile methodology

Threat Modeling Methodologies

The most common threat modeling methods used today include:

STRIDE is a tried and well-tested model for application threat modeling. Other methods may not scale well and may be helpful only with limited use cases — some models, such as PASTA, may require the use of questionnaires to gather information.

Application engineers and owners may lack the expertise to respond to questions security teams effectively often ask to produce a useful model. Using the attack tree method may require in-depth knowledge of the system environment and its associated components to prepare all possible relationship trees.

Threat Modeling Tools

As threat modeling has continued to emerge, several tools have been developed to help in the creation and maintenance of threat models.

Here’s an example of a threat modeling diagram with threats derived using STRIDE.

Application Threat Modeling Image 3
Figure 4: Sample Threat Model

The following are some of the free and commercial threat modeling tools currently in use:

Microsoft Threat Modeling tool – Microsoft’s original threat modeling tool, updated to include Azure cloud solutions.
ThreatModeler – Considered the industry-leading automated threat modeling solution and uses the VAST technique for creating threat models.
Irisrisk – Another web-based threat modeling tool for risk analysis, produced by Continuum Security.
SecuriCAD – Produced by Scandinavian company Foreseeti, SecuriCAD helps in cyber risk simulation and does automated threat modeling.
SDElements – Another threat modeling tool developed by Security Compass.
OWASP Threat Dragon – Web-based free threat modeling tool developed by OWASP.

Learn how Optiv can revolutionize your application threat modeling process. Contact us today to see how our industry-leading tools and expertise can help you identify and mitigate security risks within your application architecture. Don't wait to enhance your cyber defense strategy – take the proactive step towards safeguarding your critical assets.