Threat Modeling in Product Design

Threat modeling is a structured approach of identifying and prioritizing potential threats to a system to determine the value that potential mitigations would have in reducing or neutralizing those threats.

Use Threat Modeling at the early stages of your Product and Application Design, and every time there is a change in Product, Application Functionality, System Infrastructure or System Architecture. You can also use Threat Modeling after a Security Incident has occurred or new vulnerabilities discovered.

Without Threat Modeling, your security is a gamble, and in today’s business environment, your SaaS Products & Services are sure to be exposed to Business Loss.

A threat agent is an individual or group that is capable of carrying out a particular threat. It is fundamental to identify who would want to exploit the assets of a company, how they might use them against the company, and if they would be capable of doing so.

Likelihood is a measure of the probability of a threat being carried out.

Controls are safeguards or countermeasures that you put in place in order to avoid, detect, counteract, or minimize potential threats against your information, systems, or other assets.

Preventions are controls that may completely prevent a particular attack from being possible. For example, if you identify a threat that your users’ personal information may be identified by certain application logging, and you decide to completely remove that logging, you have prevented that particular threat.

Mitigations are controls that are put in place to reduce either the likelihood or the impact of a threat, while not necessarily completely preventing it.

A data flow diagram is a depiction of how information flows through your system. It shows each place that data is input into or output from each process or subsystem. It includes anywhere that data is stored in the system, either temporarily or long-term.

A trust boundary (in the context of threat modeling) is a location on the data flow diagram where data changes its level of trust. Any place where data is passed between two processes is typically a trust boundary.

Select a Threat Modeling Methodology that is right for your organization.

STRIDE is a model of threats implemented to help consider and identify potential threats to a system. The STRIDE methodology aims to ensure that an application meets the security directives of the CIA triad (Confidentiality, Integrity, and Availability), alongside Authentication, Authorization, and Non-Repudiation. The STRIDE formula is divided into 6 main categories:

• Spoofing: Spoofing attacks involve impersonating another person or computer without their knowledge, which violates authentication.
• Tampering: This involves modifying something on memory, disk, network, or somewhere else, which violates integrity.
• Repudiation: Repudiation involves claiming that you didn’t do something or were not involved or making it impossible to link an action back to you, which violates non-repudiation.
• Information Disclosure: This involves disclosing information to an unauthorized user, which violates confidentiality. Several systems contain confidential and sensitive information that is desired by a malicious attacker.
• Denial of Service: This involves exhausting resources required to offer services, which violates availability. Systems are typically used for a specific purpose, like a banking application.
• Elevation of Privilege: This involves allowing someone to do what they are unauthorized to do, which violates authorization.

DREAD is about evaluating each existing vulnerability using a mathematical formula to retrieve the vulnerability’s corresponding risk. The DREAD formula is divided into 5 main categories:

• Damage: how bad would an attack be?
• Reproducibility: how easy is it to reproduce the attack?
• Exploitability: how much work is it to launch the attack?
• Affected users: how many people will be impacted?
• Discoverability: how easy is it to discover the threat?

Risk Value = (Damage + Affected users) x (Reproducibility + Exploitability + Discoverability).

PASTA (Process for Attack Simulation & Threat Analysis) is a complete methodology to perform application threat modeling. It introduces a risk-centric methodology aimed at applying security countermeasures that are commensurate to the possible impact of each threat.

This methodology introduces complete risk analysis and evaluation procedures that you can follow to evaluate the risk for each of the identified threats. The main difference in using this approach is that you should evaluate the impact early on in the analysis.

The idea behind addressing the impact earlier in this approach is that the audience that knows impact knows the consequences on a product or use case failures more than participants in the threat analysis phase.

Application security risk assessments are not enough because they are very binary and leverage a control framework basis for denoting risks. Contextually look at threats impacts, probability and effectiveness of countermeasures that may be present.

R = (T * V * P * I) / Countermeasures

Using risk matrix rank risks from most severe to least severe based on Means, Motive & Opportunity. Below is a sample risk matrix table, depending on your risk approach you can define different risk ranking matrix:

Risk Value (DREAD, with each category scored from 1 to 3, giving values from 6 to 54):

• 01 to 12 → Risk Level: Notice
• 13 to 18 → Risk Level: Low
• 19 to 36 → Risk Level: Medium
• 37 to 54 → Risk Level: High

A threat modeling tool is defined as a software that enables you to proactively identify and resolve possible security threats to your software, data, or device. A good Threat Modeling tool suggests mitigation strategies for these vulnerabilities which can be added to the application’s development plan.

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.

For the assessors: After defining and analyzing the risks, the assessor should be working on the mitigation plan by firstly identifying risk owners which is the personnel that is responsible for mitigating the risk. i.e. one of the information security team or the development team.

For the designers or the architects: they should assign the risk mitigation to the development team to consider it while building the application.

You do not need a formal threat model for a prototype that holds no customer data, for an internal tool used by three people, or for a no-code workflow built entirely inside a vendor platform you have already assessed. A one-page checklist covering authentication, data storage and third-party access is enough at that stage.

Threat modeling is also the wrong tool when you have not yet fixed the known problems. If you are still running with shared admin accounts, no MFA on the cloud console, or public storage buckets, a workshop that produces a ranked list of hypothetical threats will not change your risk. Close the known gaps, then model.

Do not threat model every sprint ticket. As noted above, the trigger is a change in functionality, infrastructure or architecture. A new integration, a new tenant model, a new data category or a new AI agent with system access are triggers. A field added to a form is not. Update the model at those points and it stays useful instead of becoming a compliance artifact nobody reads.

• Reduce: building controls in the form of code upgrades; confirming a specific design for the application; building a specific configuration during the deployment phase to reduce risk.
• Transfer: The risk can be transferred through Insurance Protection if a third party owns and manages controls.
• Avoid: avoiding the risk is disabling a specific function in the application that is the source for that risk.
• Accept: Low risk that is within acceptable criteria, the risk owner can accept that risk.
• Selecting one of the controls to reduce the risk, either by upgrading the code, or building a specific configuration during the deployment phase and so on.

Talk to a Cybersecurity Trusted Advisor at IRM Consulting & Advisory