"For Best View, Please Open this Website on Laptop / Desktop Or Mobile"

Search
Cancel
04 February 2022 / RQ SPEAK

Threat Modelling: What is it & why is it important during Software Development?

Application Controls Audit

Threat Modelling is a necessary and important step in Software Development. This blog will give you a good understanding on how to Threat Model.

RQ SPEAK

Introduction

Threat Modelling is the process of identifying threats to a system. A system may be ‘threatened’ due to inherent vulnerabilities within the system or due to lack of appropriate safeguards in the system.

Threat Modelling has been adopted in the IT and infosec field to defend Computer Systems against Cyber Attackers. 

Broadly, there are three important steps:

  1. Know the system

  2. Know the threats

  3. Treat the threats

 

Know The System

This is the most important step when doing Threat Modelling. Understand in detail the system you are trying to protect. How will you adequately protect a system you don’t understand?

Usually, a diagrammatic representation of the system helps. Below is an example using the OWASP Threat Dragon tool.

Once you understand the system, you will be in a better position to determine the threats.

 

Know The Threats

To determine threats within your system, you will need to be aware of general Cyber Security threats. Following are some of the sources from where you can get details of threats:

  1. Risks with OWASP Top 10

  2. Testing Procedure with OWASP ASVS

  3. Risks with SANS Top 25

  4. Microsoft STRIDE

Once you determine the threats, you will need to understand the Risk Value. You can utilize any Risk Assessment methodology to determine the Risk Value. One of the examples is DREAD.

  • Damage - how bad would an attack be?

  • Reproducibility - how easy it is 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 it is to discover the threat?

We can rate each parameter above on a scale of 1 to 3. An example from OWASP is shown below. 

Reference link - https://owasp.org/www-pdf-archive/AdvancedThreatModeling.pdf

You can then classify Risks as shown below:

Risk Value

8 to 10

High

4 to 7

Medium

1 to 3

Low

 

Treat The Threats

The next stage after identifying the risks is to identify and evaluate the most appropriate action of how to deal with the risk. There are four possible actions for risk management decision (nomenclature as per ISO27005)

Reduce Risk

To reduce the assessed risks, appropriate and justified controls should be identified and selected. The aim of control selection is to reduce risk to an acceptable level.

Avoid Risk

Risk avoidance describes any action where resources are moved away from risky areas or change the technology or the process so that the risk doesn’t exist. When evaluating the option of risk avoidance, it has to be balanced against business and monetary needs.

Transfer Risk

Risk transfer might be the best option if it seems impossible to avoid the risk, or it is difficult or too expensive to reduce the risk. For e.g. risk transfer can be achieved by insuring or using third parties and outsourcing partners to handle critical business functions.

Retain (accept) Risk

Retain (accept) Risk concerns the communication of residual risks to the decision makers. When no further controls can be applied to reduce the risks, a decision needs to be made on how to deal with them. This decision is to retain (accept) risk.

 

Threat Modelling Tools

Various tools exist for performing Threat Modelling. Some of them include:

  1. OWASP Threat Dragon

  2. Microsoft Threat Modelling Tool

  3. Threat Modeller

  4. IriusRisk

  5. SDElements by Security Compass

 

Conclusion

Threat Modelling is an important process in the overall Software Development Life Cycle. A good Threat Model will identify potential security issues early in the project and help in the development of a more secure software.

However, it should also not just be a “tick in the box” exercise and should be done with the true intent of identifying security issues. The security and software development teams within an organization should come together and ensure that maximum benefit is reaped from such an exercise.