Autonomous vehicles and their cyber security

They may not be quite like Glen A. Larson depicted them in the 80’s TV series “Knight Rider”, but autonomous vehicles are here. Dozens of organisations are developing self-driving cars, including the likes of Google, Tesla, and Uber. However, as the technology and connectivity in vehicles evolve, so does their vulnerability to cyber attacks. And with cases like the Jeep hack in 2015, Nissan in 2016 and Tesla in 2020, these attacks are no longer confined to the scripts of movies (although the writers of “Fast and Furious 8” did take it a bit far!). It’s therefore essential that these vulnerabilities are identified, understood and mitigated.

We had the chance to work with an autonomous vehicle developer to help them overcome the challenges of assessing cyber risks in this emerging field. To achieve this, we helped them implement a risk management process in accordance with ISO 21434 to manage their cyber security risk when it comes to their vehicles and supporting infrastructure.

The challenges

While working with our client we identified some key challenges that needed to be addressed:

• What’s in scope?
• What are the key risks?
• When little data is available, how do you evaluate the probability of an event?

Our approach

Scope definition

When beginning a project like this, one of the first things we ask for is a diagram of the network and adjoining systems. This serves two purposes: Firstly, it allows us to quickly get up to speed on what the overall network looks like and understand what we’re dealing with. Talking through the network diagram with the internal teams and questioning elements of it also often yields insights into key assets, dependencies, and vulnerabilities. Secondly, a network diagram allows us to physically draw out the boundary of the scope we agree for the assessment. This avoids any uncertainties over in-or-out of scope, and ensures everyone is on the same page.

Identifying key risks

Before worrying about whether an autonomous vehicle could be hacked and hijacked to use its onboard computer to run cryptomining software, we wanted to understand what we are defending, then break down the ways that the ‘crown jewels’ could be attacked. By taking this top-down approach we could concentrate on the critical assets and before even evaluating the risks, begin to form a picture of what would be minor incidents and what could potentially bring the business to its knees.

This approach is used by ISO 21434, the standard for cyber security risk management in road vehicles. Overall we liked the methodology of the standard, and adopted some of its terminology to facilitate certification for our client if and when they choose to get certified.

In just a few workshops with our client we were able to go from a network diagram to a full breakdown of the assets, damage scenarios – the consequences of the compromise of one or more of the assets – and a list of risk scenarios identifying a source, risk event, and consequence.

Evaluating risks

It was important to us to define a method for objectively evaluating risks. ISO 21434 identifies different ways of doing this, one of which uses the concept of attack feasibility. This method breaks down the likelihood of an event based on different aspects of an attack. These categories are:

• Time elapsed - the time to develop and exploit a vulnerability
• Specialist expertise - the level of expertise required by the attacker to carry out the attack
• Knowledge of the component - the availability of information concerning the item or component (e.g. public, restricted, confidential, etc.)
• Window of opportunity - Can the attack be carried out remotely, is access limited? Does it require physical access?
• Equipment - The level of equipment required to carry out the attack from standard to multiple bespoke

This gave us a repeatable way of breaking down the components of the risk, and also allowed us to identify where controls were present or missing, and could therefore be implemented.

As controls are implemented this method also allows the organisation to adjust specific areas of the attack feasibility score, rather than subjectively deciding whether the control is sufficient to reduce the likelihood of the event coming to pass.

One element of risk evaluation that we felt was not taken into account by the attack feasibility method was motivation. In some cases, risks were scoring highly on attack feasibility, but the motivation behind the attack was lacking. For example, a competitor could exploit a critical vulnerability that would allow them to connect to the vehicle and extract a copy of proprietary software onboard. A competitor would have the capability to carry out such an attack, and as such the risk would rate highly in terms of attack feasibility. However, there are other ways that they could acquire this information with less effort, such as coercing or bribing an employee. The addition of motivation as a factor meant that we could take this into account to ensure that risks’ ratings truly match their likelihood.

Key takeaways

In summary here are the key points we learnt from the experience:

• Scope definition is key to understanding the assets in question and how they might be compromised
• Adopting a top-down view of risk focuses attention on the key risks, concentrating on the assets in-scope
• Selecting an evaluation method befitting of the scope is important, but don’t be afraid to adjust it to work for your organisation

Photo by Arthur Besnard from Unsplash