In the last decade, the cybersecurity has stunningly spread in the automotive industry, mainly because of the recent UN155 regulation. While most of the actors have reached a good maturity level by securing adequately the vehicles and their components, some others organisations are still progressing. And amongst them, there is a specific type of organisation where Securing Cars has observed an interesting phenomenon: the “over-security”, which means the implementation of more security controls than really needed.

Obviously, this “over-security” has a direct impact on the cost of the ECUs (Electronic Control Units) and on the final cost of the vehicles. Indeed, the car manufacturer and the ECU supplier have to design, implement and test the security controls, which may even require to upgrade to a more capable and more expensive HW.

So it is interesting for the automotive actors to try to understand the causes of this phenomenon, in order to implement a more efficient and more reasonable cybersecurity in the vehicles.

Generic “one-size-fits-all-ECUs” cybersecurity specifications

The first cause of the “over-security” phenomenon is the systematic implementation of generic cybersecurity specifications, whatever the ECU and its criticality in the vehicle.

For example, we recently worked on a project where the car manufacturer required the implementation of a full set of cybersecurity specifications on a lit emblem (you know, the logo of the car brand located on the front grille which lights up in the dark on the most recent cars). It included a secure boot and a complex certificate management. This component is not involved in any essential function of the vehicle, it is not even safety-related. The only purpose of this component is to bring dome additional style to the vehicle. For sure, this device is connected to the vehicle on-board network, so the network needs to be secured in order to ensure that no one can use this node to send illegitimate messages, by replacing the emblem by a malicious device for example. But the device itself probably does not expose so many intrinsinc risks that it would require the implementation of the complete set of specifications.

A simple way for the car manufacturer to avoid such situation is to perform a Threat Analysis and a Risk Assessment (TARA) at a vehicle level, focusing on this particular piece of equipment. The TARA highlights the actual risks coming with this new ECU. The car manufacturer then tailors the cybersecurity specifications to cover these risks and it sends this set of specifications to the tier-1 supplier. This is actually the regular process that a lot of car manufacturers already apply. But some other don’t, most probably by lack of human resources.

Wrong and conservative TARA assumptions

The car manufacturer often requires the tier-1 supplier to perform a TARA of the electronic component to be developped. This TARA may help identifying risks that the car manufacturer could have missed, resulting in some additional security requirements and security controls to be implemented.

However, in order to be able to perform this TARA, the tier-1 supplier shall have a comprehensive understanding of the role of the component in the vehicle and the impacts on the road users in case of some attacks successfully target this particular component. Thus the tier-1 needs some important input from the car manufacturer, like the vehicle functions that the component will contribute to, the exhaustive list of the damage scenarios associated to the component, and also the detailed ASIL (Automotive Safety Integrity Level) quotation with the severity criteria for each damage scenario, -and not only the overall ASIL level of the component which is useless for the TARA.

Without these important input data, the risk assessor of the tier-1 supplier may make wrong and conservative assumptions, like a too severe safety impact. This leads to additional cybersecurity requirements and the implementation of unnecessary cybersecurity controls.

Unlikely attack scenarios

When the risk assessor has to perform the TARA, they have to evaluate, on one hand, the impacts of the damage scenarios associated to the different assets of the item, and on the other hand, the threat scenarios targetting these assets, with their respective feasibility.

The problem comes when the risk assessor evaluates the feasibility of the threat scenario without keeping in mind the attacker profile and the real attack situation.

Indeed, let’s consider the attack ”key extraction from internal flash memory using the JTAG interface”. The feasibility of this attack will be different depending on the attacker profile. If we are considering a “vehicle insider” like the owner of the vehicle who may want to unlock some feature, the window of opportunity is very large, as the owner has plenty of time to work on the ECU. If we are considering a “vehicle outsider” like a thief who would need to extract a secret from the ECU to steal the vehicle, the window of opportunity is much shorter.

This is the reason why the risk assessor has find a way to explicitely mention the attacker profile in the TARA, particularly if the resulting attack feasibility can be considered low enough to accept the associated risk.

Conservative risk apetite

In the automotive industry, there is no golden rule to define the boundaries between an acceptable risk and a risk that must be mitigated. The ISO21434 standard does not specify anything more than some ways to compute the risk level and the possible options for the risk treatment (avoid, reduce, share, retain). The risk treatment decision is left to the risk assessor through his own risk apetite, which may be very conservative, leading to the mitigation of risks and the implementation of security controls where the risk could have been accepted.

In order to help the risk assessors to not be too conservative, their organisation may release a “cybersecurity risk appetite statement”. It can include for example the boundary between an acceptable risk and a risk to be mitigated based on the risk level computed by the risk assessor (e.g. “if the risk level is 1, the risk can be accepted. If the risk level is greater or equal to 2, the risk shall be mitigated). The cybersecurity risk appetite statement can also include some statements like: “The self-sabotage of the vehicle components by the user himself is not considered in the TARA. The related risks can thus be accepted.”. For the risk assessor, this statement will translate into “Any risk resulting from the combination of a damage scenario having only a safety or a functional impact, and a threat scenario requiring a physical access to a component located inside the vehicle, can be accepted”.

With this cybersecurity risk apetite statement, the risk assessor can rely on valid rationales to justify the acceptance of some risks.

So what the automotive actors should do to tackle the “over-security” phenomenon?

Let’s summarize the outcome of the analysis above:

• The car manufacturers should systematically perform a risk analysis for each ECU and they should tailor the cybersecurity specifications sent to the tier-1 which develops the ECU.
• The car manufacturers should provide all the necessary information (vehicle functions, damage scenarios and detailed ASIL cotation) to the tier-1 suppliers in order to allow them to perform the most accurate TARA of the component and to avoid making too conservative assumptions.
• The cybersecurity risk assessors shall mention the attacker profile in the threat scenario in order to make sure this is a realistic threat scenario.
• Each automotive actor should define its own risk appetite statement to help its risk assessors to make relevant assessment without being too conservative. Even better : all the automotive actors should agree on a common risk appetite statement in order to reduce the discussions customer/supplier during the project development.

Tackling this “over-security” phenomenon will contribute to lower the cost of the vehicles, by implementing a more efficient and more reasonable cybersecurity.

However, there are many other ways to make the cybersecurity more cost-effective (training, standards, tooling…). And Securing Cars is your best partner to identify the potential improvements in your organisation and to help you implementing them.