30 May, 2019

Benefits of Threat Modeling

by Sangita Prajapati

Threat modeling is one of the most under-appreciated and misunderstood activities in application security. I always have mixed feelings when it comes to performing threat modeling. I like the idea of threat modeling and appreciate the value it brings to secure an application. However, the process is lengthy and time consuming. Threat modeling requires patience, knowledge, skills, and time. The process requires hours of focused discussion between the application and security teams to understand the application from inside out. The most tedious thing about threat modeling is maintaining the documentation and writing reports. I have been engaged in a few threat model assessments, and each one was different depending on the size and complexity of the application as well as the client’s requirement. I do not have any expertise in threat modeling. In the past, the thought of performing a threat model has made me nervous. For these reasons, I decided to get out of my comfort zone and write about it. This blog is my first step in making an effort to research, learn, and eventually, possess skills to be able to perform a threat modeling assessment myself.

Benefits

So why threat modeling? Threat modeling helps to identify, enumerate, communicate, and understand threats and mitigations to protect the application assets. It helps produce a prioritized list of security improvements. Threat modeling can occur during planning, design, and/or during later feature implementation phases. Threat modeling not only allows the team to understand the product better, but it also helps the team better understand various components that are being utilized by the application. The knowledge of why and how the components are interconnected with the product is valuable. This knowledge helps understand the positive and negative impacts on the product.

Is threat modeling suitable for every organization? Yes, the amount of time, money, and energy should be in proportion to the risk associated with the application and to the business. Threat modeling can help to make products secure and trustworthy. With all the information available from the process, the threat model allows making rational security decisions. If done the right way, it provides a clear view across any product that justifies security efforts. Some organizations would see immediate positive results from the process, while for some, it may take some time to see the positive results. The results depend on how the security is integrated within the organization as well as the goals of the product teams.

Methods

There are about 12 threat modeling methods that have been developed over the years. These methods can be combined or used individually depending on the particular needs of the project. You need to think about specific areas such as risk, security, and privacy to choose the best suitable method for your project. For this blog, I will list the features available with each threat modeling methods.


Threat Modeling Method Features
STRIDE - Helps identify relevant mitigating techniques
- Most mature method
- Easy to use but time consuming
PASTA - Helps identify relevant mitigating techniques
- Direct contribution to risk management
- Allows collaboration among stakeholders
- Built-in prioritization of threat mitigation
- Has rich documentation
LINDDUN - Helps identify relevant mitigation techniques
- Built-in prioritization of threat mitigation
- Labor intensive and time consuming
CVSS - Built-in prioritization of threat mitigation
- Provides consistent results when used
continuously
- Includes automated components
- Includes score calculations
Attack Trees - Helps identify relevant mitigation techniques
- Provides consistent results when used continuously
- Easy to use if the team understand the system
Persona non Grata - Helps identify relevant mitigation techniques
- Direct contribution to risk management
- Provides consistent results when used
continuously
- Detects only some subsets of threats
Security Cards - Allows collaboration among stakeholders
- Targets out-of-the ordinary threats
- One too many false positives
hTMM - Built-in prioritization of threat mitigation
- Allows collaboration among stakeholders
- Provides consistent results when used continuously
Quantitative TMM - Built-in prioritization of threat mitigation
- Includes automated components
- Provides consistent results when used continuously
Trike - Helps identify relevant mitigation techniques
- Direct contribution to risk management
- Built-in prioritization of threat mitigation
- Allows collaboration among stakeholders
- Includes automated components
- Very little documentation available
VAST - Helps identify relevant mitigation techniques
- Direct contribution to risk management
- Built-in prioritization of threat mitigation
- Allows collaboration among stakeholders
- Provides consistent results when used continuously
- Designed to be scalable
- Very little documentation available
OCTAVE - Helps identify relevant mitigation techniques
- Direct contribution to risk management
- Built-in prioritization of threat mitigation
- Allows collaboration among stakeholders
- Provides consistent results when used
continuously
- Designed to be scalable
- Time consuming and very little documentation
available

Of all the methods above, I am summarizing STRIDE in this post since it has always stood out for me the most. STRIDE was introduced in 1999 at Microsoft to aid developers for finding threats within their products. STRIDE is one of the oldest and most mature methods available for threat modeling. STRIDE approach includes building data-flow diagrams (DFDs) to identify the system entities, events, components, actors, and trust boundaries within and outside the product. STRIDE applies a set of known threats, which is a mnemonic as shown in the following table:


Threat Property Threat Definition
S Spoofing identity Authentication Pretending to be someone other than yourself
T Tampering with data Integrity Malicious modification of data on disk, network, memory or database
R Repudiation Non-repudiation Denying performing an action without other parties having a way to prove otherwise
I Information disclosure Confidentiality Exposing information to unauthorized entities
D Denial of service Availability Exhausting resources needed to provide service
E Elevation of privilege Authorization An unprivileged user gaining privileged access to systems

Integrating Threat Modeling into the SDLC

Threat modeling should be performed as early as possible in the software development lifecycle (SDLC) when potential issues can be caught early and remediated. This not only helps to build a more secure product, but saves resources such as time, money, and man hours to fix the issues later. The inclusion of threat modeling into SDLC is best when applied continuously. The process is same at different levels of abstraction; however, the information gets more granular throughout the life cycle. A high-level threat model should be applied in the planning phase and refined throughout the lifecycle. New attack vectors are identified as more details are added to the project. Therefore, the continuous threat modeling process allows the team to examine, triage, and address these threats while the project is ongoing.