The module in brief

Threat analysis builds upon the previous module threat identification where potential threats were identified by first determining the affected assets and then assessing the likelihood of exploitation. The threat analysis will allow organisations to calculate and prioritise risks and allocate resources to mitigate high-priority threats effectively. 

Purpose of threat analysis

The objective of threat analysis is to determine which assets are affected by each threat and to assess the likelihood of the threat occurring. This step ensures that organisations understand the potential impact on critical assets, allowing them to prioritise risks effectively.

Practical Information

A threat analysis is typically conducted as a workshop, with its duration depending on the number of threats identified in the threat identification. Since this is a highly technical discussion, additional investigation is likely to be required following the workshop in order to validate findings or gather further information. The analysis should be based on system documentation, data flow diagrams, and the list of identified threats to ensure a structured approach. 

The workshop should primarily involve participants with a technical background, as they are best suited to assess the likelihood of attacks. However, individuals with business expertise can also contribute by providing insights into the operational and business impact of threats. For the discussion, it is recommended to use a whiteboard or flipboard for brainstorming, along with coloured markers, post-its, pens, and printed worksheets to be downloaded below. Threat catalogues can also serve as useful references for inspiration and validation. 

Step-by-step guide

1. Identify impacted assets 
   Using the list of threats from the Threat Identification, determine which specific assets are affected by each threat. Refer to system modelling, asset identification, and data flow diagrams to understand how threats interact with the system and which critical assets are at risk. 
   
   
2. Assess likelihood 
   Once assets have been linked to threats, evaluate the likelihood of each threat occurring. To ensure consistency in how likelihood levels are defined and interpreted, refer back to Context establishment  if needed. Likelihood is determined based on factors such as: 
   • • Complexity of the attack (e.g., does it require advanced technical skills or is it easily exploitable?)
     • Historical vulnerabilities (e.g., have similar attacks occurred in the past?) 
     • Potential threat actors (e.g., cybercriminals, insiders, or automated attacks)
     • Existing security controls (e.g., encryption, authentication mechanisms, intrusion prevention systems)
     • Use the scoring scale agreed in the context establishment step (e.g., 1 = Very Unlikely, 4 = Very Likely) to quantify the likelihood of each threat, enabling a structured approach to prioritising threats for evaluation.  
     • Summarise the results in a structured table as shown below, showing the threats, likelihood, CIA violations, and impacted assets to guide the next phase of risk assessment.

Read more regarding these distinct methods and gain inspiration from the IoT door lock example below. 

Threat Analysis Methods

In the previous Threat identification, a number of threats were identified. These threats need to be further analysed. This analysis can be split up into two distinct steps: 

1. Identify affected assets
   The first step is to determine which assets would be impacted if the threat was to be manifested. The easiest way to identify the affected assets is by looking at the system model and considering what components and interactions would be affected by the threat and considering which assets are stored/processed on the affected components. 
   
   Here, it is important to consider if the attacker can use the threat to ‘pivot’ into another threat. For example, if an attacker could obtain write access to a database, it would of course violate the integrity of any assets stored in the database. If the database is also used to control access to other parts of the system, the attacker could use the write access to bypass authentication mechanisms and perhaps obtain access rights to other parts of the system, violating additional assets. 
   
   In order to maintain an overview, it might be necessary to create new, more specific, variants of the previously identified threats. For example, it might be revealed that an attacker providing malicious input to an interface, can use that interface to a) gain unauthorised access to data or functionality of the system or b) cause an error in a sub-component, causing denial of service. In this case, the threat ‘attacker provides malicious input to X interface’ could be split into two new threats: ‘attacker provides malicious input to X interface to obtain access to Y’ and ‘attacker provides malicious input to X interface to crash system Z’. The two new threats might differ in both likelihood (DoS might be easier to achieve) and impact, and require different treatment. 
   
   
2. Assess the likelihood of the threat
   The next step is to assess the likelihood of the threat happening. This can be difficult, as it, in general, is hard to estimate the likelihood of an event occurring, and it will ultimately be a subjective estimation rather than an objective truth. Even though the likelihood ultimately is a guess, there are methods to help make it a more qualified guess:
   
   
   1. Complexity of the attack: Is it something that is easy to do or does it require special knowledge, access to source code or special equipment? Is it easy to discover or would it require reverse engineering protocols or client applications?
   2. Potential threat actors: Who would try to launch an attack and what would their capabilities and motivation be? If there are few potential threat actors, with limited capabilities and motivation, a threat is less likely to occur as opposed to a highly motivated and capable threat actor.
   3. Historical vulnerabilities: Is the threat something we have experienced before? If we have experiences related to the threat, estimating the likelihood should build on those experiences.
   4. Existing security controls: What do we already have in place that could prevent the threat from occurring? If a threat requires some kind of access credentials, it is less likely to occur, than if it can be done using no authentication. If the system is placed behind a firewall/intrusion prevention system, some attack vectors will be prevented by that system.

These factors are all relevant to consider and by scoring the likelihood of threat as the average of the scores of these categories can make the likelihood more objective than just guessing. 

Another, simpler, approach is to consider 4 likelihood categories (ranging from least to most likely) as follows: 

1. 1. 1. 1. The threat could in theory happen, but we have never heard of real-world occurrences.
         2. We have heard of the threat happening, but only in sectors/countries that are not similar to ours.
         3. We have heard of the threat in sectors/countries/companies/organizations similar to ours.
         4. We have experienced the threat within our company or organization.

By the end of the threat analysis, the list of threats previously identified should be enriched with information on affected assets and the likelihood of the threat occurring.  

 “Threat Likelihood and Impact Assessment Table” by CyPro under license CC BY-SA 4.0 

Threat Likelihood and Impact Assesment Table 
Printable version of the tool in large format 

IoT Door Lock Example

To illustrate the Threat analysis process, we apply the outlined method to an IoT door lock system. The outcome of this process is captured in the table below. 

Step 1: Identify impacted assets

Starting from the identified threats, we map each threat with the impacted  assets. For example: 

The threat “unauthorised access to communication between the IoT gateway and cloud service” was identified as a confidentiality violation, impacting user credentials, lock control commands, and operational logs. 

The threat “tampering with commands or data transmitted between the IoT gateway and mobile application” was classified as an Integrity violation, affecting command and access functionality. 

A Denial-of-service (DoS) attack on the IoT gateway or Cloud Service was marked as an availability violation, disrupting remote access functionality. 

Step 2: Assess likelihood 

We evaluate the likelihood of each threat occurring based on: 

Historical vulnerabilities in IoT systems (e.g., cloud-based breaches, API attacks). 

Technical complexity, such as the ease of intercepting communication or manipulating transmitted commands. 

Existing security mitigations and their effectiveness in preventing such attacks. 

For example: 

• • • • Unauthorized access to IoT gateway communication was rated as "Likely" (3) due to the potential for network interception attacks.
      • Tampering with transmitted commands was rated as "Unlikely" (2) because of existing API security measures.
      • A DDoS attack on the cloud service was rated as "Very Likely" (4) due to the prevalence of such attacks on cloud-based services.
      • The table below is a direct output of this process, where each threat, likelihood, CIA impact, and affected assets were evaluated to ensure a structured and comprehensive security assessment. 

Threat Likelihood and Impact Assessment Table 

Output

The output of a threat analysis is a structured evaluation of identified threats, linking each threat to its affected assets and assessing the likelihood of exploitation. 

Expert advice

Sometimes a full risk analysis is not needed, whereas only a threat assessment is needed. This can be the case if the impact on the customer/user is impossible to estimate. If this is the case, step 1 ‘Identify affected assets’ can be skipped and only the likelihood of the threat is assessed.

Next step

The output of threat analysis is a detailed assessment of identified threats, focusing on the specific assets impacted and the likelihood of exploitation. In the next module Risk management, organisations use this analysis to prioritise risks and develop targeted mitigation strategies as part of the risk management process. 

The contents described above have been developed in the project:

’CyPro – Cybersecure manufacturing in Denmark’ by Aarhus University, Alexandra Institut, DAMRC, UGLA Insights and FORCE Technology funded by The Danish Industry Foundation. Material from the project is published under licence CC BY-SA 4.0

CyPro