Threat Analysis
Once the model is complete, the next step is to assess its security. ThreatGet thoroughly investigates potential cyber threats that could exploit any existing vulnerabilities. The analysis process in ThreatGet examines all security information provided in the system design, identifying possible weaknesses that attackers might exploit. Additionally, ThreatGet can generate an attack path propagation, illustrating potential attack paths that an attacker could follow, step-by-step, to achieve a malicious goal.
Both threat analysis techniques are rule-based approaches. Users can manage the built-in rules and expand the rules database as needed, adding new cyber threats to keep the database up-to-date with a custom set of rules that cover specific system domains. More details about managing rule-set can be found in the ThreatGet Rules section.
analysis apporach is the threat can be initiated through the Analysis path, where the ThreatGet rule engine plays a crucial role in examining potential weaknesses within the system model in depth.
Analysis
To begin the analysis, select the "Analysis" phase as shown in the diagram below. The first time you have to click on the "Next" button to initialize the analysis step.
In the background the analysis is automatically conducted. By default, the AS option (representing Attack Steps) on the left side is selected.
The list provides a brief overview of the identified threats, including:
- ID: A unique identifier for each identified threat.
- Title: The name of the identified threat.
- Source: The affected source element.
- Target: The affected target element.
- Likelihood: The severity level of likelihood.
- Threat Type: Each threat is classified according to its malicious impact. ThreatGet categorizes all identified threats based on the STRIDE model:
- S – Spoofing: Violates authentication
- T – Tampering: Violates integrity
- R – Repudiation: Violates non-repudiation
- I – Information Disclosure: Violates confidentiality
- D – Denial of Service: Violates availability
- E – Elevation of Privilege: Violates authorization
For more details on each threat, click of the row in the table. The row will expand and display more details.
More details about the selected threats are displayed, providing additional information. The Description field offers further insights into the threat, elaborating on the specific elements and connections impacted by it. The Likelihood Level indicates the probability of the threat occurring. Additionally, the Category field displays the STRIDE classification of the threat, which the user can modify by selecting the desired option from the menu. The Attack Feasibility describes multiple attributes indicating the feasibility of a successful attack. According to ISO 21434, this includes the following:
-
Elapsed Time: Represents the time to identify and exploit vulnerabilities for an attack, which can range from days to months.
-
Expertise: Capabilities of attackers, which can vary as follows:
- Layman: Unknowledgeable with no expertise.
- Proficient: Knowledgeable with familiarity with security behavior.
- Expert: Familiar with algorithms, protocols, hardware, structures, and security techniques.
- Multiple Experts: Multiple highly experienced engineers with expertise in different fields.
-
Knowledge: It represents the knowledge about the target, varying based on available information.
- Public: Public or shared information, such as data shared on the internet.
- Restricted: Internal documents shared between restricted parties.
- Confidential: Confidential information about the item itself.
- Strictly confidential: Strictly confidential information about the item itself.
-
Window of opportunity: This represents access type (physical or virtual) and time spent accessing the target (limited or unlimited), including various levels:
- Unlimited: Highly available through untrusted or public networks without a time limit.
- Easy: Highly available with limited-time access.
- Moderate: Have restricted limits for access using special tools or methods.
- Difficult: Very low availability, with limited windows of opportunity for performing an attack.
-
Equipment: Describes attack tool classifications:
- Standard: This type of equipment is available to attackers, and it could also be part of the target item itself, such as debuggers in Operating Systems.
- Specialized: It is equipment that is not easily available to attackers but can be acquired with effort.
- Bespoke: This type of equipment is not available to the public, such as specific manufacturer-restricted tools.
- Multi Bespoke: Refers to bespoke equipment for various attack stages.
Security Property & Likelihood Calculation
Each Security property value is assigned one of the following values:
- Strong (Robust protection; highly resistant to attacks)
- Moderate (Reasonable protection with some manageable vulnerabilities; risk is present but controlled through existing safeguards)
- Weak (Minimal protection; vulnerable to common attacks)
- No (No security measures in place; fully exposed to risks)
- Undefined (Security status is unclear or not assessed; no evaluation has been made regarding potential risks or protections)
The stronger the security measures, the lower the likelihood of an attack or breach, and vice versa. Each security measure is assigned a numerical value by ThreatGet, and the average likelihood value is then determined.
Mapping Likelihood - Attack Feasibility
The following table assigns numerical values to various Factors that influence the Attack Feasibility. These factors include Elapsed Time, Expertise, Knowledge, Window of Opportunity and Equipment. Each factor is evaluated based on the level of preparation, skill, timing, and resources required, with higher values typically indicating a higher likelihood of success (See ISO/SAE 21434 Annex G).
Attack Feasibility Factors (Assumptions) | |
Elapsed Time | Elapsed time directly correspond to the strenght of security control. Longer then 6 months is not used. |
Expertise | Expertise also direclty correspond to the strength of security control. Weak security controls could be assumed to be vulnerable against Layman. Multiple experts could not be used, could be reserved if we refine our approach to consider multiple security controls (e.g. if security controls of very different types are used, this could be selected.) |
Knowledge | Availalbe knowledge about the security control does not correspond to the strength of a security control and is set to restricted as standard assumption |
Window of opportunity | Window of opportunity does also not correspond to the strength of a security control but to the ease of access the target system. Therefore it is set to moderate as standard value, denoting that most car systems are somehow reachable, but not directly connected to public networks. Could be added in future, could be based on length of attack path |
Equipment | Required equipment is assumed to correspond to the strength of security control, e.g stronger security control require more specialized equipment |
Attack Feasibility Factors | Sum of Factors | Rating | |||||||||
Elapsed Time | Value | Expertise | Value | Knowledge | Value | Window of Opportunity | Value | Equipment | Value | ||
<= 1 days | 0 | Layman | 0 | Public | 0 | unlimited | 0 | Standard | 0 | 0-9 and 10-13 | High |
<= 1 week | 1 | Proficient | 3 | Restricted | 3 | easy | 1 | Specialised | 4 | 14-19 | Medium |
<= 1 month | 4 | Expert | 6 | Confidential | 7 | moderate | 4 | Bespoke | 7 | 20-24 | Low |
<= 6 months | 17 | Multiple experts | 8 | Stricly confidential | 11 | difficult | 10 | Multiple Bespoke | 9 | > 25 | Very Low |
> 6 months | 19 |
Here an example of how likelihood is calculated by assigning numerical values to various attack feasibility factors, which are then used to determine the overall likelihood of an attack or breach. This approach ensures consistency and automation in assessing risk based on predefined security properties:
How to set Attack Feasibility Factors to achieve alignment with automated Likelihood calculiation | |||||||
Security Control | Elapsed Time | Expertise | Knowledge | Window of Opportunity | Equipment | SUM | Likelihood |
0 - No | 0 | 0 | 3 | 4 | 0 | 7 | High |
1 - Weak | 1 | 3 | 3 | 4 | 4 | 15 | Medium |
2 - Moderate | 4 | 6 | 3 | 4 | 7 | 24 | Low |
3 - Strong | 17 | 8 | 3 | 4 | 9 | 41 | Very Low |
This table evaluates the Attack Feasibility based on five key Factors: Elapsed Time, Expertise, Knowledge, Window of Opportunity, and Equipment. Each Factor is assigned a Security Control value ranging from No (0) to Strong (3). The sum of these scores provides an overall Security Feasibility Rating:
- High (0-13): Strong security controls, low attack feasibility.
- Medium (14-19): Moderate security controls, moderate attack feasibility.
- Low (20-24): Weak security controls, high attack feasibility.
- Very Low (>25): Very weak or no security controls, very high attack feasibility.
The table sums the scores for all factors to categorize the overall security posture and likelihood of a successful attack.
The CIA-STRIDE Matrix
The CIA-STRIDE Matrix (or Security Attributes - Threat Types Matrix) is a combination of two well-known frameworks used in risk assessment and threat modeling: CIA and STRIDE.
- CIA (Security Attributes) stands for Confidentiality, Integrity, and Availability, which are the core principles of information security.
- STRIDE (Threat Types) is a threat modeling framework that helps identify various types of security threats based on six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege
The CIA-STRIDE Matrix is used to cross-reference these principles with potential threats. By combining the two frameworks, you can assess how each security attribute (Confidentiality, Integrity, and Availability) may be impacted by different types of threats.
Here is a general outline of how the Matrix is structured:
Explanation of Matrix:
- Confidentiality: Ensures that information is only accessible to authorized individuals.
- Spoofing: Impersonating another user or system to gain unauthorized access to information.
- Information Disclosure: Unauthorized exposure of information.
- Integrity: Ensures the accuracy and reliability of data.
- Tampering: Unauthorized modification of data.
- Repudiation: Denying the occurrence of an action, making it difficult to track whether an action (like data modification) occurred.
- Availability: Ensures that information and systems are available for use when needed.
- Denial of Service (DoS): Making a system or service unavailable.
- Elevation of Privilege: Gaining higher access or control than intended, which could disrupt availability or integrity.
What the Matrix does:
The CIA-STRIDE Matrix helps to evaluate which assets have which security attributes (Confidentiality, Integrity, Availability) and compares them to the STRIDE threat categories. If the asset under investigation matches the relevant STRIDE category, a result (threat scenario) is generated. If there is no match, no threat scenario is created.
How the Matrix helps:
By using this matrix, you can quickly see how each threat type affects each of the security attributes. This helps identify vulnerabilities in systems and ensures that proper countermeasures are put in place to protect confidentiality, integrity, and availability from various types of threats.
Risk Treatment
- Risk Treatment defines the proper action that should be taken for handling the cyber risk. The user can define their decision for controlling the risk, which can be classified into four different actions:
- Mitigate: Specific actions should be taken to reduce the probability or impact of a potential risk. The objective of mitigation strategies is to lower the risk to an acceptable level, usually through the use of preventive actions, controls, or protective measures.
- Transfer: This action involves transferring the responsibility for managing and controlling the risk to an individual or organization that is better equipped to handle it. The goal is to shift the financial or operational burden to a party with the resources, expertise, or capacity to manage the risk, typically through insurance, outsourcing, or contractual agreements.
- Accept: This is a risk treatment strategy where an organization decides to acknowledge and live with the risk without taking any further action to mitigate, transfer, or avoid it. This typically happens when the risk is deemed low, the cost of addressing it is too high compared to its potential impact, or the organization has a high tolerance for certain risks. Accepting the risk means that the organization is prepared to manage any potential consequences if the risk materializes.
- Avoid: This is a risk treatment strategy where an organization takes proactive steps to eliminate a risk entirely by changing its approach, processes, or activities. This can involve discontinuing certain operations, avoiding risky actions, or adopting safer alternatives to prevent the risk from occurring. The goal is to remove the risk completely, ensuring that the potential consequences are entirely avoided.
Once the user selects the appropriate risk treatment plan based on their knowledge of mitigating cyber risks, a text field labeled "Rationale" becomes active. This field allows the user to provide a brief description explaining their reasoning for addressing the risk based on the chosen treatment plan.
- Mitigate -> Security Goal: The objective you want to achieve, such as protecting confidentiality, integrity, or availability of information.
- Transfer -> Security Claim: A claim to transfer responsibility or the financial burden of a security risk to another party.
- Accept -> Security Claim: A claim to accept the risk as is, typically because the potential impact is minimal or the cost of mitigating the risk outweighs the benefit.
- Avoid -> Rationale: The rationale for deciding to avoid the risk entirely, rather than mitigating, transferring, or accepting it.
Re-Analysis
In case you make changes to the diagram directly or within the analysis results, by changing security controls or systemproperties, you can click on the "Re-Analyse"-Icon (the Magnifier). This is to ensure that all new threats are listed and removed ones are marked as deleted. Still existing ones will be updated.
In case an entry is modified by the user, the row is marked as "MOD.". This happens, when changing any of the values within the expanded row. If only the attack feasibility is modified, the value that the user set will remain the same and the entry will remain "MOD.". However in case a security control is changed, this indicates a modification of the calculacted Attack Feasibility of the analysis engine. Therefore, changes to the Attack Feasibility will be overriden by the system. In this case the respective table entry is marked as "UPD." (for updated by the system).
To put it simple:
-
NEW: defines entries that where not present in the previous analysis or were removed and later on added again
-
DEL. defines entries that were present in a previous analysis but were removed due to changes to the architecture or the system properites
-
MOD. defines entries that were changed by the user. (Note: In case of a re-analysis this might change to "UPD." (in case of changes to security controls) or "DEL." (in case of changes to system properties or the architecture))
-
UPD. defines entries that where updated to to changes by the analysis that orignated from the user.
Security Property & Likelihood Calculation
Each Security property value is assigned one of the following values:
- Strong (Robust protection; highly resistant to attacks)
- Moderate (Reasonable protection with some manageable vulnerabilities; risk is present but controlled through existing safeguards)
- Weak (Minimal protection; vulnerable to common attacks)
- No (No security measures in place; fully exposed to risks)
- Undefined (Security status is unclear or not assessed; no evaluation has been made regarding potential risks or protections)
The stronger the security measures, the lower the likelihood of an attack or breach, and vice versa. Each security measure is assigned a numerical value by ThreatGet, and the average likelihood value is then determined.
Mapping Likelihood - Attack Feasibility
The following table assigns numerical values to various Factors that influence the Attack Feasibility. These factors include Elapsed Time, Expertise, Knowledge, Window of Opportunity and Equipment. Each factor is evaluated based on the level of preparation, skill, timing, and resources required, with higher values typically indicating a higher likelihood of success (See ISO/SAE 21434 Annex G).
Attack Feasibility Factors (Assumptions) | |
Elapsed Time | Elapsed time directly correspond to the strenght of security control. Longer then 6 months is not used. |
Expertise | Expertise also direclty correspond to the strength of security control. Weak security controls could be assumed to be vulnerable against Layman. Multiple experts could not be used, could be reserved if we refine our approach to consider multiple security controls (e.g. if security controls of very different types are used, this could be selected.) |
Knowledge | Availalbe knowledge about the security control does not correspond to the strength of a security control and is set to restricted as standard assumption |
Window of opportunity | Window of opportunity does also not correspond to the strength of a security control but to the ease of access the target system. Therefore it is set to moderate as standard value, denoting that most car systems are somehow reachable, but not directly connected to public networks. Could be added in future, could be based on length of attack path |
Equipment | Required equipment is assumed to correspond to the strength of security control, e.g stronger security control require more specialized equipment |
Attack Feasibility Factors | Sum of Factors | Rating | |||||||||
Elapsed Time | Value | Expertise | Value | Knowledge | Value | Window of Opportunity | Value | Equipment | Value | ||
<= 1 days | 0 | Layman | 0 | Public | 0 | unlimited | 0 | Standard | 0 | 0-9 and 10-13 | High |
<= 1 week | 1 | Proficient | 3 | Restricted | 3 | easy | 1 | Specialised | 4 | 14-19 | Medium |
<= 1 month | 4 | Expert | 6 | Confidential | 7 | moderate | 4 | Bespoke | 7 | 20-24 | Low |
<= 6 months | 17 | Multiple experts | 8 | Stricly confidential | 11 | difficult | 10 | Multiple Bespoke | 9 | > 25 | Very Low |
> 6 months | 19 |
Here an example of how likelihood is calculated by assigning numerical values to various attack feasibility factors, which are then used to determine the overall likelihood of an attack or breach. This approach ensures consistency and automation in assessing risk based on predefined security properties:
How to set Attack Feasibility Factors to achieve alignment with automated Likelihood calculation | |||||||
Security Control | Elapsed Time | Expertise | Knowledge | Window of Opportunity | Equipment | SUM | Likelihood |
0 - No | 0 | 0 | 3 | 4 | 0 | 7 | High |
1 - Weak | 1 | 3 | 3 | 4 | 4 | 15 | Medium |
2 - Moderate | 4 | 6 | 3 | 4 | 7 | 24 | Low |
3 - Strong | 17 | 8 | 3 | 4 | 9 | 41 | Very Low |
This table evaluates the Attack Feasibility based on five key Factors: Elapsed Time, Expertise, Knowledge, Window of Opportunity, and Equipment. Each Factor is assigned a Security Control value ranging from No (0) to Strong (3). The sum of these scores provides an overall Security Feasibility Rating:
- High (0-13): Strong security controls, low attack feasibility.
- Medium (14-19): Moderate security controls, moderate attack feasibility.
- Low (20-24): Weak security controls, high attack feasibility.
- Very Low (>25): Very weak or no security controls, very high attack feasibility.
The table sums the scores for all factors to categorize the overall security posture and likelihood of a successful attack.
The CIA-STRIDE Matrix
The CIA-STRIDE Matrix (or Security Attributes - Threat Types Matrix) is a combination of two well-known frameworks used in risk assessment and threat modeling: CIA and STRIDE.
- CIA (Security Attributes) stands for Confidentiality, Integrity, and Availability, which are the core principles of information security.
- STRIDE (Threat Types) is a threat modeling framework that helps identify various types of security threats based on six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege
The CIA-STRIDE Matrix is used to cross-reference these principles with potential threats. By combining the two frameworks, you can assess how each security attribute (Confidentiality, Integrity, and Availability) may be impacted by different types of threats.
Here is a general outline of how the Matrix is structured:
CIA - STRIDE Matrix | ||||||
CIA / STRIDE | Spoofing | Tampering | Repudiation | Information Disclosure | Denial of Service | Elevation of Privilege |
Confidentiality | X | X | ||||
Integrity | X | X | ||||
Availability | X | X |
Explanation of Matrix:
- Confidentiality: Ensures that information is only accessible to authorized individuals.
- Spoofing: Impersonating another user or system to gain unauthorized access to information.
- Information Disclosure: Unauthorized exposure of information.
- Integrity: Ensures the accuracy and reliability of data.
- Tampering: Unauthorized modification of data.
- Repudiation: Denying the occurrence of an action, making it difficult to track whether an action (like data modification) occurred.
- Availability: Ensures that information and systems are available for use when needed.
- Denial of Service (DoS): Making a system or service unavailable.
- Elevation of Privilege: Gaining higher access or control than intended, which could disrupt availability or integrity.
What the Matrix does:
The CIA-STRIDE Matrix helps to evaluate which assets have which security attributes (Confidentiality, Integrity, Availability) and compares them to the STRIDE threat categories. If the asset under investigation matches the relevant STRIDE category, a result (threat scenario) is generated. If there is no match, no threat scenario is created.
How the Matrix helps:
By using this matrix, you can quickly see how each threat type affects each of the security attributes. This helps identify vulnerabilities in systems and ensures that proper countermeasures are put in place to protect confidentiality, integrity, and availability from various types of threats.
Risk Treatment
- Risk Treatment defines the proper action that should be taken for handling the cyber risk. The user can define their decision for controlling the risk, which can be classified into four different actions:
- Mitigate: Specific actions should be taken to reduce the probability or impact of a potential risk. The objective of mitigation strategies is to lower the risk to an acceptable level, usually through the use of preventive actions, controls, or protective measures.
- Transfer: This action involves transferring the responsibility for managing and controlling the risk to an individual or organization that is better equipped to handle it. The goal is to shift the financial or operational burden to a party with the resources, expertise, or capacity to manage the risk, typically through insurance, outsourcing, or contractual agreements.
- Accept: This is a risk treatment strategy where an organization decides to acknowledge and live with the risk without taking any further action to mitigate, transfer, or avoid it. This typically happens when the risk is deemed low, the cost of addressing it is too high compared to its potential impact, or the organization has a high tolerance for certain risks. Accepting the risk means that the organization is prepared to manage any potential consequences if the risk materializes.
- Avoid: This is a risk treatment strategy where an organization takes proactive steps to eliminate a risk entirely by changing its approach, processes, or activities. This can involve discontinuing certain operations, avoiding risky actions, or adopting safer alternatives to prevent the risk from occurring. The goal is to remove the risk completely, ensuring that the potential consequences are entirely avoided.
Once the user selects the appropriate risk treatment plan based on their knowledge of mitigating cyber risks, a text field labeled "Rationale" becomes active. This field allows the user to provide a brief description explaining their reasoning for addressing the risk based on the chosen treatment plan.
- Mitigate -> Security Goal: The objective you want to achieve, such as protecting confidentiality, integrity, or availability of information.
- Transfer -> Security Claim: A claim to transfer responsibility or the financial burden of a security risk to another party.
- Accept -> Security Claim: A claim to accept the risk as is, typically because the potential impact is minimal or the cost of mitigating the risk outweighs the benefit.
- Avoid -> Rationale: The rationale for deciding to avoid the risk entirely, rather than mitigating, transferring, or accepting it.
!!! Warning "⚠️ Important Note" Any changes or updates to threat factors, such as updating the STRIDE categories, attack feasibilities, or risk treatment, must be saved; otherwise, the user will lose all modifications. Therefore, after making changes, the black 💾 icon button should be pressed.
Filtering ThreatGet Analysis Results
A threat may be identified multiple times based on its propagation within the system model, which can make locating a particular threat challenging. To address this, ThreatGet lists each identified threat once on the left side, along with its occurrences in the results. ThreatGet also provides advanced filtering options to help users refine analysis results according to specific needs.
When the Filter by option is set to Rule Name, the filter activates, allowing users to locate specific threats quickly. In the Search bar, users can enter keywords to find threats by title. Additionally, users can filter results by Source or Target components, offering more precise threat identification within the system model. By selecting Filter by for source or target, ThreatGet will search for threats based on the selected filter option, matching the keywords entered for source or target component names.
Attack Tree
As mentioned earlier, ThreatGet can generate a set of paths illustrating how an attacker might follow specific steps toward a malicious goal. To switch the analysis approach to the attack tree, the user can click on AT on the left side.
A new window will appear, displaying a list of all threats on the left side of the window. Once the user selects a particular threat, the attack tree propagation will be displayed, outlining the sequence of steps an attacker might follow to reach a malicious goal. This malicious goal refers to the system asset(s) that represent the primary target the attacker aims to compromise. These assets indicate the main objectives that motivate the attacker’s actions.
Each node in the tree represents a step or threat that an attacker can exploit to progress further toward the malicious goal. To view each step more clearly, click on any node in the tree. A sublist will appear in the lower half of the window, showing a list of threats associated with that specific tree node.
Each of these threats has more details. Click on any threat to display additional information within the same window.
Prioritization of Risk Treatment Options in Attack Trees
In an Attack Tree for risk management, when multiple risk treatment options (Mitigate, Transfer, Accept, Avoid) are available for a specific risk or attack step, they are prioritized in the following order: Mitigate > Transfer > Accept > Avoid.
This prioritization ensures that the most effective or protective solution is applied to address the risk.
Example:
Let's consider two different Attack Trees with overlapping nodes:
- Attack Tree 1: Asset 1: Execution (Gateway ECU)
The Risk Treatment of the Root node in the Attack Tree 1 was assigned the value MITIGATE:
Since all child nodes inherit the risk treatment from the parent node, all nodes in this attack tree will also have the MITIGATE risk treatment applied.
- Attack Tree 2: Asset 1: Privilege Escalation (Gateway ECU)
The Risk Treatment of the Root node in the Attack Tree 2 was assigned the value TRANSFER:
However, since MITIGATE is stronger than TRANSFER, the nodes that overlap in both trees (in this example the node 'Interface 21' ) will automatically inherit the MITIGATE treatment from the Attack Tree 1 (where MITIGATE is applied):
RECAP: If Attack Tree 1 has the MITIGATE treatment on the root node, and Attack Tree 2 starts with TRANSFER for the root node, then any overlapping nodes between these trees would inherit MITIGATE because it is the stronger treatment.