The development of vehicle components and systems is becoming increasingly reliant on efficient cybersecurity solutions. It is essential that the Threat Analysis and Risk Assessment (TARA) required by ISO/SAE 21434, which is now considered a central component of the development of modern vehicles, is carried out correctly and meaningfully on the one hand, and efficiently and in a resource-saving manner on the other. The TARA methodology is a sophisticated risk-based investigation of cybersecurity influencing factors, providing a foundation for defence against potential threats. It provides a structured methodology for identifying, evaluating and prioritising cybersecurity risks in vehicle systems. However, the potential challenges associated with this approach will be outlined below.
Jan-Peter von Hunnius
In the current era, when in-vehicle connectivity is becoming a standard feature and critical vehicle functions are based on complex software systems, any weaknesses in the implementation of security measures can have significant implications, not only for individual vehicles but also for entire fleets and beyond.
In light of the above, UN Regulation No. 155 requires OEMs and suppliers to conduct a comprehensive risk assessment. The TARA methodology, which is defined in detail in ISO/SAE 21434, is becoming an increasingly important element of cybersecurity strategies.
It is important to note that a TARA should not be considered a standalone technical document. Instead, TARA serves as an ‘evolutionary development sketch’ that supports engineering teams in making informed security decisions throughout the entire vehicle lifecycle, from initial concept to operation and decommissioning.
Despite the advent of specialised tools and solutions for crafting TARA, some systematic challenges remain in the application of the methodology. This indicates that the industry has not yet implemented a solution that adequately addresses the increasing complexity of modern automotive systems.
To illustrate this, three key challenges that continue to present difficulties for the industry are outlined below: the automatic aggregation of attack paths, the excessive dependence on threat-centred risk matrices, and the lack of collaboration opportunities for TARA collaboration between OEMs and suppliers.
Automated aggregation as a starting point for serious inaccuracies?
The TARA methodology places significant emphasis on attack paths and attack trees, facilitating traceability and a comprehensive understanding of potential cyber security risks through visualisation.
What are attack trees within the TARA methodology?
Attack trees are designed to compile and visualise systematised information through a structured, hierarchical representation of how an attacker might achieve certain objectives, for example, gaining unauthorised access to a system or impairing vehicle functions. In these trees, each branch represents a possible attack path that breaks down complex attacks into individual steps that could be used by an attacker. This visualisation is of critical importance within TARA, as it enables engineers to identify and evaluate every possible path an attacker could take. The aim is to gain a clear picture of the potential vulnerabilities from the initial access point to the final attack target.
AND/OR: the issue of the AND and the OR in a potential attack
A number of specialised TARA solutions adopt this approach, utilising attack trees to represent entire attack paths as nodes connected by AND/OR gates. They demonstrate the circumstances under which an attack could be successful. The AND/OR gates serve as logical links and are intended to represent the requirements for each individual step in the attack path:
- The use of AND gates indicates that all conditions must be met.
- The use of OR gates indicates that any of the specified conditions is sufficient.
Using this methodology, the TARA solution can model different attack scenarios and assess their probability and impact.
By systematizing the assessment of each branch of the tree, TARA solutions seek to assist the teams involved in calculating risk assessments and prioritizing risk mitigation measures.
This ensures that resources (which are always limited) are focused on the most critical threats. This is one of the key objectives in the effective implementation of cybersecurity in vehicle development.
Excursus: How does ISO/SAE 21434 rate the feasibility of cyber attacks?
ISO/SAE 21434 establishes a scoring system for evaluating the feasibility of attacks, known as the “attack feasibility rating”. The standard (see clause 15) defines five parameters to which a score is assigned. These parameters are:
- the duration of the attack (including research, etc.)
- the expertise required to carry it out
- the availability of relevant information about the system
- the window of opportunity within which an attack can be carried out (this is particularly relevant if, for example, physical access to the attacked system is required)
- and the commonality of the equipment required for the attack.
In the TARA system, the ratings of these parameters for each attack path are aggregated across all its steps (e.g. by always selecting the highest value) and then summed up to a rating for the overall feasibility of an attack.
A high rating indicates an infeasible attack, while a low rating indicates an easy attack.
What is the automated aggregation of attack paths in TARA and why can they pose a problem?
Although this method of evaluating and handling attack trees is one of the central foundations of TARA, it can still lead to limitations and inaccuracies.
These result from the automated aggregation of the scores of the individual parameters of an attack path.
Most TARA solutions automatically aggregate various elements, such as attack duration, to produce a final risk assessment. However, this automated process can lead to (serious) inaccuracies in real-world scenarios.
An example of this is the estimation of the required expertise for a successful attack, which is an element that should not be underestimated when assessing the actual feasibility of a successful attack.
Let’s look at a fictional, simplified example where a malicious software change is made (see diagram below).
There are various possibilities here that could lead to a successful attack. Each of these possibilities is evaluated on the basis of the parameters discussed.
The ‘Specialist expertise’ and the actual probability of attack
Regarding the expertise required for each step, it is important to note that according to the ISO/SAE 21434 rating scale, the highest level of ‘multiple experts’ is defined as requiring several highly qualified specialists from different fields.
Anyone who understands the content of the attack tree will see that these are different domains, so the value for the expertise parameter should actually increase (it would then be ‘multiple experts’ with 8 points). However, this is not the case, as common TARA tools and solutions only pass through the given rating for the expertise level (here ‘expert’ with 6 points). The result is that the expertise score for this attack is too low, and in practice the likelihood is overestimated.
As a result of this incorrect risk assessment, in practice unnecessary security mechanisms may be implemented to mitigate an incorrectly assessed risk. Wasted resources.
The equipment and the actual probability of attack
This problem of possible incorrect aggregation also exists for the parameter of the equipment required for an attack. Again, the equipment can be either ‘bespoke’ (with 7 points) or ‘multiple bespoke’ (with 9 points).
Again, the question of whether an aggregated total of 7 or 9 points is correct can only be answered after a closer examination of the content of the required equipment.
The attack duration and the actual attack probability
However, this problem becomes most apparent when considering the time required for an attack, the attack duration.
According to the ISO/SAE 21434 rating scale, a situation in the above example with two ratings of ‘≤ 1 month’ combined can have any value between 16 and 60 days.
(It is important to know: The standard does not define any steps between ‘≤ 1 month’ (4 points) and ‘≤ 6 months’ (17 points); however, 17 points already changes the probability of attack from ‘high’ to ‘medium’).
This lack of clarity is reflected in the corresponding values: a period of 16 days would be assigned to the ‘≤ 1 month’ value and scored with 4 points – a period of 60 days would be assigned to the ‘≤ 6 months’ value and scored with 17 points.
This difference of 13 points will inevitably lead to significant differences in the overall risk assessment and, again, in case of doubt, result in an excessively high probability and unnecessary security mechanisms.
Here is the same example as an attack path with a more optimistic (or, from the attacker’s point of view, more pessimistic) manual aggregation. The total attack paths now take ‘<6 months’ and one requires ‘multiple experts’.
This approach can be found in many manually developed TARAs (e.g. using Excel spreadsheets).
The assessment of the feasibility of the two possible attacks is now more accurate – and, due to the higher scores, significantly lower (21 vs. 36/38) – than in the previous diagram.
As a result of the more accurate assessment, it is highly likely that effort can be saved on unnecessary security mechanisms in downstream development, as these attacks can be classified as unrealistic or negligible in practice anyway.
The problem with threat-oriented risk matrices
When considering the overall security risk of an attack or threat, the damage it can cause is one dimension of the final risk assessment; the other is the feasibility of a realized threat or attack. In the first diagram, the tree is a threat – a malicious software change. It is rather abstract.
Many TARA tools use threats rather than attack vectors to generate the final risk score, probably because of the aggregation strategy described above. However, this approach limits the granularity of the TARA results and results in rather abstract recommendations (the so-called “Cybersecurity Goals”) that are too general to be implemented during development.
A threat-based approach might lead to a Cybersecurity Goal such as ‘prevent malicious software modifications’ if the risk is too high to accept.
However, such an objective does not provide details of how this threat might actually occur in practice, or how an attack is carried out.
Does the attacker use a debug interface? Are they directly manipulating memory?
Without this information, it is difficult for development teams to implement specific and effective cybersecurity measures, such as protecting debug ports and internal microcontroller flash memory.
The information about the specifics is already in the TARA – but in the attack vectors. Deriving risk assessments and the resulting Cybersecurity Goals and Claims from the attack path assessments, rather than from the threats, tends to result in a detailed Cybersecurity Goal such as “Prevent malicious changes to the software via an unlocked JTAG debug interface” or “Prevent malicious changes to the software via direct access to the flash memory”. This provides clear direction on how to reduce risk.
This is because the cybersecurity goals are derived from a specific attack vector rather than an abstract threat.
Lack of (tools and) collaboration between OEMs and suppliers
The third and perhaps most pressing problem associated with the efficient application of the TARA methodology is the lack of collaboration tools. This is not only a structural problem in many organizations, where TARAs often have to be evaluated and transferred manually (at immense cost in terms of resource consumption), but also the exchange of information, work status or complete TARAs between OEMs and suppliers seems impossible.
As vehicles and their components become more complex and interconnected, the sole responsibility for cybersecurity can no longer lie with one party.
In practice, OEMs need to work effectively with their suppliers to develop comprehensive TARAs that cover the entire risk and threat landscape along the supply chain.
Unfortunately, today’s TARA tools and solutions do not have the necessary interfaces to map this important collaboration cleanly and without loss.
As a result, OEMs and suppliers often work in silos.
In fact, to date there is no standardized way of sharing relevant parts of a TARA with development partners. This often leads to inefficiencies and gaps in the risk assessment process as different organizations struggle to integrate their assessments and security measures.
Unlike application lifecycle management (ALM) tools, there is no widely adopted standard exchange format to facilitate information sharing.
Without such a coordinated exchange system that allows the sharing of assessments from different perspectives, it becomes difficult to get the full picture and ensure that all potential attack vectors are covered.
In terms of the ultimate purpose of TARA, this disconnect can lead to vulnerabilities and risks being overlooked or redundant cybersecurity efforts being undertaken, neither of which leads to efficient cybersecurity implementations.
Solutions for collaboration around the TARA
Instead of simply defining interfaces for the exchange of information, which can easily become out of balance, another model of collaboration is suggested: working with the same data model when developing a TARA.
In the silo-like way that the automotive industry works, this suggestion sounds almost provocative: hosted by the OEM, a TARA for a new vehicle (system) could be developed jointly by all parties involved, with access controlled for all parties. This would eliminate data exchange and possible inconsistencies between suppliers’ and OEMs’ TARAs. Everyone can see and edit the parts that are relevant to them, and the result is a comprehensive and consistent TARA – for the whole vehicle.
For example, a detected compromise of a control unit (e.g. a denial of service by maliciously modified software) could lead to a much more destructive attack on the vehicle (e.g. by spoofing messages that the compromised control unit can send to affect other systems in the vehicle).
When these dependencies are modelled together in the same TARA, as shown in the following figure, changes in the vulnerability of one ECU automatically and consistently lead to coherent changes in the whole vehicle. Conversely, vehicle-wide adaptations can then be consistently and automatically broken down to the individual ECU suppliers and their risk assessments and point distributions.
TARA as intellectual property?
It is clear that intellectual property concerns need to be addressed. However, it is important to make the right choices in terms of collaboration and efficiency, especially given the challenges currently facing the global automotive industry. At the same time, as with so many business applications, it is the responsibility of solution and tool providers to use intelligent access management features to control the allocation of access rights in a way that protects the intellectual property of all parties involved.
Recognizing collaboration as a driver of future competitiveness is not only a technical issue, but also a cultural one.
Summary and perspective
What sounds a bit sensational is the current reality: the automotive industry is at a crossroads when it comes to cybersecurity. Although more and more tools and solutions for TARA are available on the market, their limitations and shortcomings – automatic aggregation, threat-oriented risk matrices and inadequate collaboration mechanisms – sometimes lead to far-reaching problems that hinder the effectiveness and efficiency of risk assessments.
It is therefore not surprising that Excel solutions for TARA can still be observed in practice in a surprisingly large number of projects. The security engineers involved prefer the MS solution for a simple reason: dedicated (and often expensive) TARA software solutions offer too little added value to justify their cost.
One thing is certain, however: cybersecurity in vehicle development and the tools and solutions used to work efficiently in this area are constantly evolving.
