Automotive Cybersecurity Threat Analysis and Risk Assessment Part 1

Welcome dear networkseclearners to this new tutorial on Threat Analysis and Risk Assessment applied to the automotive industry. This topic might sound completely new to you if you are not from the automotive industry. But don’t worry, I will try to explain things in a simple and understandable way so that everybody no matter the background can easily follow and understand. The only prerequisite to follow this tutorial is to read the tutorials on the Automotive Cybersecurity Introduction and the one on Risk Management. If you have already read these two articles and remember the concepts, you can continue the reading of this article. 😉

If you have read the article on Automotive Cybersecurity Introduction, you should know by now that Cybersecurity is a critical concern in today’s automotive industry. Modern vehicles, often referred to as “computers on wheels,” contain around 80-100 onboard computers to enhance comfort, safety, and connectivity. With this increase in electronic systems and connectivity comes a significant rise in potential cyber threats. ☹️ Therefore, it is crucial to protect these systems from cyber-attacks, not only for the safety and security of the vehicle occupants but also for maintaining trust in automotive brands and being compliant to standards and regulations like ISO/SAE 21434 and UNECE WP.29.

This is where Threat Analysis and Risk Assessment (TARA) comes into play. Indeed, TARA is a methodology used to identify, analyze, assess and mitigate the risks associated with cybersecurity threats in automotive electronic systems. Thanks to TARA, automotive manufacturers and suppliers can better protect their electronic systems and vehicles from potential cyber attacks.

In this Part 1 tutorial, I would like to present you the TARA process according to the ISO/SAE 21434 and then I will show you how to perform the TARA concretely with a real example of an automotive system called the Brake By Wire System in Part 2 which will be a separate article. If you want to be notified as soon as the Part 2 is published, subscribe please to my newsletter. 😉

1. TARA Process according to ISO/SAE 21434

Just for reminder, TARA stands for Threat Analysis and Risk Assessment and is an essential method used to identify, analyze, assess and mitigate the risks associated with cybersecurity threats in automotive electronic systems. The clause number 15 of the ISO/SAE 21434 standard is dedicated to the TARA method. Indeed, this clause outlines methods to determine the extent to which a road user can be impacted by a threat scenario. There are 7 different steps defined in this clause for the TARA process which are Assets Identification, Threat Scenario Identification, Impact Rating, Attack Path Analysis, Attack Feasibility Rating, Risk Value Determination and finally Risk Treatment Decision. I would like to mention that in practice, it is better to have 2 more different steps which are Item Definition and Damage Scenario Identification. The standard considers that Damage Scenario is part of Asset Identification but I personally prefer considering it as a whole step because this is an huge activity itself. So, here is an illustration of all 9 steps needeed to perform the TARA :

In the following sections, we will discuss these steps in detail. Let’s start with Item Identification.

1.1 Item Definition

In order to identify the relevant assets, one important precondition is to define the item under analysis. This item is also often referred to as the “Target of Evaluation” or even as the “System of Interest” which is a term commonly used in Systems Engineering.

Item definition is part of clause 9 of the ISO/SAE 21434 standard which requires to define the boundary of the system, the system functions and its preliminary architecture. Indeed, According to ISO/SAE 21434 :

The item boundary distinguishes the item from its operational environment. The description of
the item boundary can include interfaces with other items internal and/or to the vehicle.

The system functions describe the intended behaviour of the item during the lifecycle phases [e.g. product development (testing), production, operations and maintenance, decommissioning] and includes the vehicle functionality that is realized by the item.

The preliminary architecture can include identification of components of the item and their connections, and external interfaces of the item.

1.2 Assets Identification

According to ISO/SAE 21434, an Asset is an object that has value, or contributes to value and which has one or more cybersecurity properties (Confidentiality, Integrity, Availability) whose compromission can lead to one or more damage scenarios. It is basically any items or information like hardware components, software, data, and communication channels that have value to stakeholders and therefore need to be protected. Protecting these assets against cyber threats is essential to ensure the safety, security, and privacy of the vehicle and its users.

1.3 Damage Scenario Identification

Once the Assets are identified, we have to identify the damage scenarios associated with each Asset. Basically, a damage scenario is the harmful consequence that will happen if one of the cybersecurity proprieties (Confidentiality, Integrity, Availability) is compromised.

In order to illustrate what a damage scenario is, let’s assume an attacker managed to access a vehicle network remotely. If he finds out the CAN messages that are sent to ECU in charge of the braking, he could send fake messages/signals to make the braking function malfunction.

With this example, the CAN message/signal that provides command information to the braking ECU is a security Asset and its cybersecurity property that is violated is the Integrity. Therefore, if this integrity property is compromised, the consequences or the damages scenarios associated are for instance the failure of the brake to activate when the driver presses the brake pedal, leading to a failure to stop the vehicle and the unexpected or excessive application of the brakes, causing the vehicle to stop abruptly, potentially resulting in a rear-end collision. As you can see, the safety of the vehicle’s occupants and other road users is compromised which can lead to a risk of injury or even death.

I hope with this concrete example, you understand better what an asset, an item and a damage scenario are. If not, don’t worry, it will be clearer when you read Part 2 which of this tutorial which will focus on a concrete example. Now, let’s move to the next step. 😊

1.4 Threat Scenario Identification

A threat scenario according to ISO 21434 is a potential cause of compromise of cybersecurity properties of one or more assets in order to realize a damage scenario. In simple words, it describes how an attacker or threat actor might try to compromise the cybersecurity properties of cybersecurity assets in order to cause damage. Basically, for each asset for which the cybersecurity properties can be compromised leading to a damage scenario, you describe how indeed this can be done. We therefore have to really think like the attacker which is trying to compromise our assets.

The identification of threat scenarios can be done through group discussions using the following methods :

-> Elicitation of Malicious Use Cases : This involves identifying potential misuse or abuse cases that could lead to security threats. By foreseeable misuse or abuse, we can uncover scenarios in which the system might be exploited in harmful ways. In order to elicitate those malicious use cases, we can rely on UNECE WP.29 Regulation No. 155 (R155) Part A. Vulnerability or attack method related to the threats.

Here is a screenshot from the UN R155 part A where we have the descriptions of threats/vulnerabilities with the attack methods example or threat scenarios.

-> Threat Modeling Frameworks: Utilizing established frameworks helps in systematically identifying and categorizing potential threats. Some examples include :

• EVITA : it focuses on the security of in-vehicle communication networks and components.
• TVRA (Threat, Vulnerability, and Risk Assessment): A structured approach to evaluate the risks associated with different threat scenarios.
• PASTA (Process for Attack Simulation and Threat Analysis): A risk-centric methodology that aligns business objectives with technical requirements to identify threats.
• STRIDE: A model that categorizes threats into Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege, helping to identify potential threat. scenarios systematically.

One example of threat scenario identification using the STRIDE framework can be : Spoofing of CAN messages for the braking ECU leads to loss of integrity of the CAN messages and thereby to loss of integrity of the braking function.

1.5 Impact Rating

Impact Rating is an essential part of the Threat Analysis and Risk Assessment (TARA) process which involves evaluating the severity of damage scenarios for road users in terms of financial, operational, and privacy (SFOP). For each of this impact category, we determine the impact value which can be Severe, Major, Moderate or Negligible. For example, for Safety impact category, we will choose value “Severe” if there are potential death or serious injuries to vehicle occupants, pedestrians, or other road users. But, if there is no risk of injury at all, we will rather choose the value “Negligible”. The ISO 21434 standard provides examples of rating of Financial, operational and privacy related impacts in its Annex F. We can therefore use them accordingly for our own rating.

1.6 Attack Path Analysis

Attack Path Analysis helps to understand how a potential attack could progress through various steps or stages to compromise the cybersecurity properties of an automotive system. The standard allows for both deductive and inductive approaches to conduct Attack Path Analysis, each offering a different way to identify and analyze these potential attack paths.

• The Top-Down or Deductive Approach involves deducing attack paths by analyzing the various ways an attacker could reach his attack goal. Essentially, you start with a potential attack goal and work downwards to identify the different steps or methods an attacker might use to achieve their goal.

• The Bottom-Up or Inductive Approach involves building attack paths starting from the known vulnerabilities. By identifying weaknesses in the system, you can construct potential paths an attacker might take to exploit these vulnerabilities and reach his attack goal.

These methods can be used individually or in combination to provide a comprehensive analysis of potential attack paths within a system.

1.7 Attack Feasibility Rating

Attack Feasibility Rating consists in evaluating how easily an attacker can exploit a vulnerability or realize a threat scenario based on the corresponding attack path. It considers various factors that influence the difficulty or likelihood of an attack being successful. According to ISO 21434, the feasibility of an attack is typically rated on a scale ranging from High to Very Low :

• When the attack path can be accomplished utilizing low effort, then the rating is High.

• When The attack path can be accomplished utilizing very high effort, then the rating is Very Low.

ISO 21434 recommends to define the attack feasibility rating based on one of the following approaches :

1.7.1 attack potential-based approach

The attack potential-based approach is a method used to assess the feasibility of a potential attack by evaluating the resources, the time and capabilities required by an attacker to successfully exploit a vulnerability or carry out a threat scenario.

The attack potential-based approach in ISO/SAE 21434 uses specific core factors to determine the attack feasibility rating. These factors help in evaluating how feasible it is for an attacker to successfully execute an attack. Here are the core factors :

• Elapsed Time : The amount of time an attacker would need to carry out the attack.

• Specialist Expertise : The level of specialized knowledge or skills required to execute the attack. This ranges from Layman to Multiple experts level skills.

• Knowledge of the Item or Component : this refers to the amount of information the attacker has acquired about the target system, including its architecture, vulnerabilities, and functionalities.

• Window of Opportunity : The access conditions and timeframe during which the attack can be successfully performed, including the availability of the system to the attacker and the duration needed to complete the attack.

• Equipment : The availability to the attacker of the tools, both hardware and software required to carry out the attack. This can range from standar tools to to multiple bespoke equipment.

1.7.2 CVSS-based approach

The CVSS-based approach for rating attack feasibility is a method that uses the Common Vulnerability Scoring System (CVSS) to evaluate the ease with which a security vulnerability can be exploited. This approach is maintained by the Forum of Incident Response and Security Teams (FIRST) and is widely recognized in the field of information security.

In the CVSS-based approach, the following exploitability metrics are used to rate the feasibility of an attack:

• Attack Vector (V) : Describes the proximity required for an attacker to exploit the vulnerability. Values range from 0.2 to 0.85, with lower values indicating that physical proximity is needed and higher values indicating remote exploitability.

• Attack Complexity (C) : Reflects the difficulty of carrying out the attack. Values range from 0.44 to 0.77, with higher values representing lower complexity and easier attacks.

• Privileges Required (P) : Indicates the level of access needed to exploit the vulnerability. Values range from 0.27 to 0.85, where lower values mean higher privileges are needed and higher values mean less or no privileges are required.

• User Interaction (U) : Measures whether the attack requires human interaction, such as clicking a link. Values range from 0.62 to 0.85, with lower values indicating the necessity of user interaction.

The overall exploitability value (E) is calculated using the following formula : E=8.22×V×C×P×U

Consequently, the exploitability values range between 0,12 and 3,89.

The CVSS exploitability values can be mapped to attack feasibility ratings using the following example ranges:

This mapping helps to categorize the likelihood of an attack being feasible based on the calculated exploitability value.

1.7.3 attack vector-based approach

The attack vector-based approach in ISO/SAE 21434 is a method for assessing the feasibility of an attack based on how an attacker could potentially exploit a vulnerability, taking into account the physical or logical proximity required for the attack. The attack feasibility rating increases the more remote the attacker can be from the system :

High (Network) :

• Criteria: The potential attack path is directly connected to a network and can be exploited without any physical limitations.
• Example: A cellular network connection that allows an ECU (Electronic Control Unit) to be directly accessible and vulnerable over the internet.

Medium (Adjacent):

• Criteria: The attack path is connected to a network but has physical or logical limitations that restrict access.
• Example: A Bluetooth interface or a connection through a virtual private network (VPN).

Low (Local) :

• Criteria: The attack path requires direct access to the system, with no network connection involved.
• Example: Using a USB mass storage device or memory card to carry out an attack.

Very Low (Physical) :

• Criteria: The attack can only be carried out if the attacker has physical access to the component or system.
• Example: A scenario where the attacker needs to physically interact with the hardware to exploit a vulnerability.

1.8 Risk value determination

The risk value according to ISO/SAE 21434 is a numerical representation of the cybersecurity risk associated with a particular threat scenario in an automotive system. The risk value is determined by combining two key factors :

• Impact Rating : This reflects the severity of the consequences if the threat scenario were to be realized. It is about how the associated damage scenarios would impact safety, financial, operational, and other critical aspects.

• Attack Feasibility Rating : This assesses how easy or difficult it is for an attacker to exploit the identified vulnerabilities to carry out the threat scenario. It considers factors like the time required, expertise needed, and the attack vector.

The risk value is usually a number between 1 and 5, where:

• 1 indicates minimal risk.
• 5 indicates the highest level of risk.

The risk value helps prioritize which threat scenarios need more immediate security measures. It is typically used in risk matrices or risk formulas to guide decision-making on mitigating cybersecurity threats.

1.9 Risk treatment decision

The risk treatment decision according to ISO/SAE 21434 involves determining how to manage the identified risks. For each threat scenario, the standard requires selecting one or more of the following risk treatment options based on the associated risk values :

Avoiding the Risk :

• Deciding not to engage in the activity that generates the risk or eliminating the risk sources altogether.
• Example : Removing or redesigning a system component that is particularly vulnerable.

Reducing the Risk :

• Implementing measures to lower the risk to an acceptable level.
• Example : Adding cybersecurity controls to strengthen the system against potential attacks.

Sharing the Risk :

• Distributing the risk with other parties, such as through contracts or transferring it via insurance.
• Example: Collaborating with suppliers who assume responsibility for certain cybersecurity aspects.

Retaining the Risk :

• Accepting the risk as is, often because the cost or difficulty of mitigation is not justified by the risk level.
• Example : Deciding to proceed with a certain level of risk and monitoring it continuously.

CONCLUSION

In this tutorial, we’ve embarked on a comprehensive journey into the world of Threat Analysis and Risk Assessment (TARA) in the automotive industry. We’ve laid the groundwork by discussing the importance of cybersecurity in modern vehicles and introduced you to the key steps in the TARA process as outlined by the ISO/SAE 21434 standard.

From defining the item under analysis to identifying assets, damage scenarios, and potential threats, we’ve explored how each step contributes to a robust cybersecurity strategy. We delved into the methodologies for evaluating impact and attack feasibility, and how these feed into the determination of risk values and the subsequent decisions on risk treatment.

As complex as this subject may seem, breaking it down into these structured steps makes it manageable and applicable, even for those new to the automotive sector. Remember, protecting the cybersecurity of automotive systems is not just about compliance with standards, it’s about safeguarding the safety, privacy, and trust of vehicle users.

Stay tuned for Part 2, where we’ll bring these concepts to life with a real-world example of a Brake By Wire system, illustrating how to apply the TARA process in practice. Until then, make sure you’ve subscribed to our newsletter so you don’t miss out on future updates. Keep learning and stay secure! 😊