Security Threat Modelling (abbreviation: STM), as the name implies, is a methodology for the analysis of threats to IT security systems, applications, interfaces, exploitation model (Cloud vs. OnPrem), etc. This type of threat analysis is not exclusively limited to IT systems but is particularly relevant when companies and organisations are dealing with assets that require protection against threats.

 

For those not familiar with IT think of this ordinary example: If the owner of a residential property installs a smoke detector in their living room for the purpose of alerting them when smoke is present in the property, the owner has "analysed" the threat of smoke inhalation from a fire and has taken steps to "mitigate" the threat by using a smoke detector.

 

Transfer this scenario to the world of information technology and you can see how potential threats to an IT system are analysed and mitigated accordingly. Threat analysis and the introduction of mitigation measures is ideally carried out before the system concerned is developed. If we return to our example and the threat that smoke may develop in the property or that a fire may likewise erupt then it is understandable that special attention should be paid to the use of fire-resistant materials during the construction of the property, as a "mitigation" measure. The above example also illustrates how it might not be possible to avert the threat after the property has been constructed and the need to analyse threats during development.

 

So one could make the following statement: Threat analysis should form a central part of the software development process to allow any identifiable threats to be properly addressed during the "construction" of the system.

 

WHY DO WE USE SECURITY THREAT MODELLING?

If we continue with our property example: Decisions regarding construction methods and materials made early in the construction phase can drastically affect the overall safety of the property. Of course, you can always (and should) install smoke detectors in a property – but is it not better and safer to use fire-resistant building materials from the outset?

 

In this way threat analysis can help prevent inappropriate or incorrect decisions regarding IT architecture. This can even be achieved before a single line of system code has been generated. Furthermore, threat analysis can be helpful when determining the security requirements of the system and which measures to implement.

 

This can be illustrated by the following IT specific example: Does the data need to be encrypted? Data may not necessarily need to be encrypted on a server, but it is far more likely that data should be encrypted when accessed from a mobile device. As you can see from the examples given there is a close relationship between the determination of threat scenarios, prevention (mitigation) measures and system requirements. By taking into account the (security-related) requirements and incorporating them at the earliest opportunity into the design phase it is possible to develop a robust and reliable solution.

 

HOW IS SECURITY THREAT MODELLING CARRIED OUT IN PRACTICE?

In short, Security Threat Modelling involves proactive planning and consideration of what may happen to specified points of any given system in terms of threats and risks to IT security. The process also includes the preparation of a corresponding protection strategy based on the threats identified in order to prevent the worst-case scenario. To achieve this objective, the following questions are considered:

 

  1. What is being developed/designed?
  2. What could happen?
  3. What can be done to prevent or mitigate against the risk of said event?
  4. What is the overall assessment?
  5. What was the standard of the analysis?

 

Each of these five questions should be treated as a process step in the threat analysis.

 

STEP 1: WHAT IS BEING DEVELOPED/DESIGNED?

A common way to depict an IT system is through the use of technical diagrams. Data flow diagrams are ideally suited for this purpose. All relevant interfaces and data flows are visualised in such a diagram. As threats only arise where data exists and/or "flows". Let's look at a "typical" web application as an example:

 

Our application is operated within a data centre and consists of a proxy, a web application and a database. It goes without saying that every web application also has at least one user, namely the end-user, who has access to the proxy and thus to the web application and the database via the Internet.

 

When creating a data flow diagram it is important to consult with one or more developers and system admins alongside the architect concerned. Only by consulting with others can a diagram be created upon conclusion of this step that is considered to be accurate in the opinion of all participants – and an accurate diagram is of fundamental importance to Security Threat Modelling.

 

STEP 2: WHAT COULD HAPPEN?

Once the data flow diagram for the system has been created, the next step is to think about what could happen in terms of events or incidents. At this point, it is helpful to formulate assumptions to narrow down potential threat scenarios.

 

Example: If we consider the system example from step 1 and assume that the operating system being used is up-to-date it is possible to exclude certain threats from the outset. But exercise caution when using assumptions: Any assumptions should always be reviewed and taken into account as part of the threat analysis.

 

Some responses to the question "what could happen" are self-evident:

 

  • Does the web server and stated server configuration correspond?
  • Can the data between the proxy and the web application be compromised?
  • In what ways does the web application ensure that the database has received the data?
  • Can an end-user also see the underlying architecture behind the database through the web application?
  • Can the web application (or the database) be compromised by excessive traffic?
  • Can an end-user complete actions in the web application that they are not authorised to do?

 

Of course, this list is not intended to be read as an exhaustive list. It is important to note that important issues are often overlooked when matters are rushed. We recommend that the following approach is taken in relation the present questions. We use the so-called STRIDE method, which was first developed by Microsoft. STRIDE stands for:

 

  • S: Spoofing
  • T: Tampering
  • R: Repudiation
  • I: Information Disclosure
  • D: Denial of Service
  • E: Elevation of Privilege

Using this method, we can categorise our "what could happen?" questions accordingly and reduce the risk that we may overlook something by taking a structured or rigid approach. In effect, every question we have listed above by way of an example can be assigned to these categories.

 

STEP 3: WHAT CAN BE DONE TO PREVENT OR MITIGATE AGAINST THE RISK OF SAID EVENT?

If the "What could happen?" question has been comprehensively answered then there should be a list of threats relating to all interactions and data listed in the data flow diagram. We proceed to go through the list and address all the threats found during the next step. This can be completed in four different ways:

 

Mitigation includes taking steps to mitigate a threat or the introduction of measures that mean the threat is less likely to be exploited due to an increase in the number of obstacles for example.

 

Example: Passwords can be used to prevent unauthorised access to an administrative interface which mitigates the threat posed by someone pretending to be a system admin.

 

Removal of a threat is often only achieved by limiting functionality.

 

Example: You can protect an administrative interface with passwords but the threat of someone impersonating an admin remains. If you were to disable the administrative interface then the threat would be removed.

 

Transfer is achieved when you transfer the threat to another party.

 

Example: One could allocate the authentication of user credentials to an Active Directory Service that would manage access to the administrative interface.

 

Accept is when you decide that you will take no action in relation to an identified threat. There can be a number of different reasons for this decision. Often the motivation is directly related to a cost-benefit decision.

 

You now possess a list of threats and different strategies to address those threats. The next step is to assess and prioritise the mitigation measures. The mitigation measures chosen are then incorporated into the software development process. For this purpose, one can use user feedback or simply use bugs reports, for example.

 

Example: A hacker may be able to crash the database by submitting too many automated requests.

 

By the end of this process, in all likelihood, you will have a lot of to-dos that need to be implemented. But before you can implement anything, we need to assess all threats and measures to be introduced and perform a cost-benefit analysis.

 

STEP 4: WHAT IS THE OVERALL ASSESSMENT?

Following completion of the previous two activities, you now have a detailed list of threats and possible countermeasures. Now it is time to prioritise those threats and/or countermeasures. To this end, the so-called threat risk is determined for each threat.

 

One way to determine the threat risk is to use the following formula:

 

Threat risk = probability of occurrence X impact/effect

 

There are a number of different approaches that can be used to assess such threat risks, e.g.: Microsoft Bug Bar or CVSS (Common Vulnerability Scoring System).

 

In larger companies, threat risk assessments are often recorded in the company's security policies. For simplicity, the probability of occurrence and impact/effect can be classified into four common risk assessment categories: Very High, High, Medium, Low.

 

There are many different ways to assess a given threat. For the first step, it is important that a coordinated approach to threat assessment is applied in a uniform and consistent manner.

 

Once all threats without countermeasures have been assessed accordingly, the threats with countermeasures can be re-assessed. However, it should be noted that the latter is generally for the purpose of documentation only and is useful should there be a requirement to review a past decision.

 

STEP 5: WHAT WAS THE STANDARD OF THE ANALYSIS?

The final step in Security Threat Modelling is to conduct a quality assessment of the threat analysis.

 

Reviewing architecture

You begin by reviewing your data flow diagram and assess whether the contents is still accurate. Decisions regarding the architecture may be changed at short notice: Functions can be added, use cases not previously considered introduce other data sets, system to system interaction change. As a result, it becomes necessary to update or supplement the data flow diagram.

 

Reviewing threats

As one would anticipate, if the architecture is modified then new threats associated with the architecture must be identified. Once the new threats have been duly identified, all previously identified threats need to be reviewed again having regard to any mitigation measures. To complete this process it is necessary to review the threat list again and ask the following questions: Was every single threat properly addressed? Was every single threat properly mitigated?

 

Testing of measures

Tests should be performed on all measures. Testing can be executed manually or by means of an automated process. All measures that are to be implemented must also be subject to quality control checks. Ideally, these tests should be integrated into an existing testing framework during the development phase.

 

CONCLUSION

It goes without saying that "real-world" Security Threat Modelling is much more detailed and complex than the process we have outlined here. Notwithstanding the above, it is evident that security concepts must be integrated into the development process and routinely updated to ensure the security of a system. Particularly, when new features are under development or when changes occur that could impact the exploitation model.

 

The analysis method depicted here, that is to say any methodology that incorporates mitigation and cost-benefit considerations is the only way to ensure greater security from the outset.
Share this article