Cybersecurity Threat Modelling Part 2:
Threat Modelling & Risk Assessment

Ensure success with an analysis and detailed plan. Get started now!
Start Now


This article was published on: May 11, 2019

Cybercrime is estimated to cost $6 trillion annually by 2021 and is said to be the greatest threat to every business in the world. To begin understanding this complex battle between security experts and cybercriminals it helps to develop and understand a basic Threat and Risk Model.

This primer on cybersecurity threat modelling is split into 3 parts: Introduction to Risk & Asset Selection, Threat Modelling & Risk Assessment, and Security Attributes.

This is part 2: Threat Modelling & Risk Assessment

Now that the fundamentals have been covered, we can move into basic threat modelling and risk assessment. A critical point to start off with is that you can never have 100% security, nor can you have zero risk – you can never completely protect your assets and that’s why fallacies such as “build me a 100% secure system” falls apart. Aside from nothing being 100% infallible (see the Quadriga CX $200M loss when a health threat was overlooked), there is also the vague use a “secure system”. The idea of “security” varies on the entity and the owner of that entity – i.e., everyone has their own version of what “security” means. We all have to accept a level of risk that is tolerable and decide (with the help of others if needed) what those tolerance levels are when assessed against our own circumstances. The threat landscape – or model – is the combination of threats and exploiters that are fighting against your assets and security. As we’ve established, the threat landscape is unique to each entity despite sharing common exploiters such as hackers, however, it is critical to note that security does not exist in isolation – and effectively, there is any “one size fits all” solution.

The general process of threat modelling and risk assessment is – on the surface – a straightforward one. That is, you must first determine your asset, then explore the vulnerabilities that the asset may have. Following that you would assess the threat to the exploitation of that vulnerability, and who the exploiter may be.

Finally, you weigh the consequences of that asset being compromised or threatened and deploy security controls to mitigate the risks. It gets far more complex as you dive deeper into the intricacies of multiple systems, policies, and operational procedures and the way they impact (directly or indirectly) the security of one another

Image module

Let’s examine a simple case as follows:

Your asset is a company laptop with business data on it, and the vulnerability is that the data on the laptop is unencrypted. In this situation, the threat is the laptop being stolen by a thief who is the exploiter – while the consequences are identity theft, reputational damage, and private company information being made public. Based on your risk tolerance, you would select security controls such as encryption, remote data-wipe, and device-based GPS to mitigate risk in the order of greatest to least.

Something a little more complex is creating a basic model or map of a risk to a SaaS application that has a public URL as there are multiple threats (far more than we’ll cover here) and multiple exploiters.

You have a webserver hosting your application which is your asset. The application allows users to access it over the internet without any form of confirmation of identity aside from a username and password – this is your vulnerability. The threats to user authentication are:
Brute Force authentication through harvesting of valid user accounts, and dictionary attacks.

The exploiter is a hacker or malicious employee attempting to attack your system, and the consequence is compromised financial data; identity theft; damaged reputation; loss of revenue; law suits; and so on.

You’ve decided to mitigate your risks by setting up security controls as follows:

  • 2step authentication to help validate the user accessing the application is authentic.
  • Generic error message on failed attempted (e.g., “incorrect login details” as opposed to “password does not match the user account”).
  • Lock account after N number of failed login attempts.
  • Enforce minimum length and complexity on passwords.
Image module

Keep in mind that security controls go through the process of Select, Implement, Assess, and Monitor. In the example above, we have selected a 2-step authentication process to verify and validate the user that is logging in is actually an employee of the company by using a second (more controlled) method of authentication. One of the ways to implement this security control is to use RSA SecurID Hardware tokens (authenticator) that are issued and managed by the business.

Over the next several months we monitor the use and assess the feedback from users on their experiences with it – and also take into account any attempts (successful and unsuccessful) at breaching the implemented control. After some careful evaluation, we’ve come to realize that most users forget to carry their authenticators with them, leaving them unable to access the application. We now decide to implement a text message being sent to the user’s registered cell phone, containing an authentication code as an alternative to the authenticator token so that users are not entirely dependent on the RSA hardware after assessing the risks of using a cell phone as an authenticator.

At this point, your basic threat model should look something like this


This is a good example of how a security control was implemented to secure an asset, but caused challenges with respect to ease of use. After careful evaluation and a risk assessment, the business felt it could accept the risk of sending a text message to a cell phone (registered in the company’s directory) with the authentication code – knowing that there is a risk that the cell phone could be threatened by another exploiter.

Note that while trying to secure the asset (the SaaS application) we’ve introduced 6 new assets to the process:

  1. The RSA SecurID Hardware Token.
  2. The process for registering the RSA SecurID Hardware.
  3. The process for unregistering the RSA SecurID Hardware.
  4. The user’s cell phone.
  5. The process for registering the cell phone.
  6. The process for unregistering the cell phone.

These 6 will then have their own individual threat models and risk assessments, and the process is repeated. It seems endless, but based on your risk appetite, you may determine that you don’t need to further investigate risks and threats to using the hardware token for example, because of RSA’s reputation – whereas a cell phone poses greater risk that would warrant further exploration.


The final section, part3: Security Attributes will examine how to assign security controls based on the classification (or attribute) of the asset.

Get in touch with an expert

Our industry leaders are ready to explain how you can accelerate and simplify your digital transformation.
Schedule a consultation