Application Threat Modeling | Optiv
- 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?
Performing threat modeling at the beginning of the secure SDLC process, when the application is being built, helps development teams identify attack surfaces and entry points which 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 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 which 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 via 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 – Once the threats and attack surfaces are identified and documented, appropriate countermeasures can be selected or designed. 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 to 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 that’s 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 in understanding 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 on its own, this approach doesn't often work out well and requires a good amount of experience for determining 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 causes too much friction. In these cases, it’s better to embrace a security-focused mindset throughout the software development lifecycle. Unfortunately, threat modeling cannot be fully automated, as it's a mostly manual activity.
Threat modeling in Agile 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.
Threat modeling in Agile is performed by using short workshops that are scheduled within each sprint. Team collaboration and brainstorming play an important role here due to short release cycles. 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 should reflect controls as applied at launch | The threat model should be updated as security-relevant changes and controls are applied |
Figure 3: Table summarizing threat model in Agile
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 P.A.S.T.A, may require the use of questionnaires to gather information. Application engineers and owners may lack the expertise to effectively respond to questions security teams often ask to produce a useful model. Usage of 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.
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. Threatmodeler uses the VAST technique for creating threat models.
- Irisrisk – Another web-based threat modeling tool for risk analysis. This commercial tool is 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.
Gloss