Connected and autonomous vehicles (CAVs) present a difficult cybersecurity problem which is, perhaps, different from many similar cybersecurity issues because of its potential impact on adoption of the industry as a whole.

With CAVs, it is not only a matter of the confidentiality of personal data, it is also a matter of public safety. However, modern connected cars are highly complex, with upwards of 100 electronic control units (ECUs) and tens, if not hundreds, of millions of lines of code. Add to this a wide range of ingress points and a complex supply chain, and it is not surprising that Mary Barra, CEO of General Motors, said in 2016 that "[a] cyber incident is a problem for every automaker in the world."

It was estimated that in 2014, more than half of the vehicles sold in the U.S. were connected in some way. That number will only have increased since then. At the same time, the degree of connectivity, and the extent to which ECUs within a car communicate with each other, has also increased. Although level 4 and 5 autonomous vehicles (highly autonomous and fully autonomous) are still some way off, the industry is moving at such a pace that it is only a matter of time before such vehicles start appearing on the roads in numbers. Governments are also grappling with the issue, for example the UK government's stated desire for the UK to become a leader in connected cars, and engaging in discussions with the insurance industry about some of the insurance issues that arise in relation to connected vehicles (see our article on liability and insurance for more).

Potential cybersecurity issues

  • CAVs gather an ever-increasing amount of personal data. Telematics and location data are now big business in their own right, from insurers offering discounts based on safer driving, to manufacturers using data to monitor usage to improve products. However, that data can be used to identify individuals and monitor where they have been, which raises a number of privacy issues.
  • Perhaps the key driver (pun intended) of cybersecurity for connected vehicles is the risk of an attack that can, for example, disable the engine, or trick lane-tracking software into thinking a vehicle is driving out of lane and therefore correct course (wrongly). Public safety of not only the driver of the connected vehicle, but also other road users, is the key concern. A number of highly public vulnerabilities demonstrated by white hat hackers, for instance in relation to Jeep connected cars, have already resulted in significant product recalls.
  • As CAVs grow ever more sophisticated, the ability to update and patch remotely will become more important (and some manufacturers already do this). It may not be practical for millions of cars to be updated quickly when a vulnerability is discovered, particularly if those vehicles need to be taken to a dealer for an update. As recent cyberattacks in other sectors show, updates themselves can be used as a vector for attack (for example the Medocs accounting software used to spread the NotPetya cryptoware, and malware-seeded update of CCleaner earlier this year). In an industry with a complex and diverse supply chain, updates (including responsibility for them) is a difficult issue which needs to have clear responsibilities and reporting requirements
  • Some systems within a vehicle, for example the entertainment system, are likely to be 'connected' (for example, Bluetooth connectivity to mobile phones to access music stored on that phone), and compromise of such a system is not, in itself, a serious threat to the safety of the vehicle or its passengers (other than inflicting very bad taste in music). However, it is crucial in considering the security of the vehicle as a whole to identify how non-critical systems connect to gateway controllers and how a potential attacker can move between such systems. Attacks have already been demonstrated which were successful because of inadequate consideration of segregating systems which were low risk from those which were high risk, with serious consequences.
  • Understanding the risks that attach to components, and then integrating those components into a vehicle in such a way as to not create vulnerabilities, is a difficult problem. Ultimately, it is the vehicle manufacturer who has responsibility for the security of the vehicle, but the current fragmented supply chain, lack of industry standards and well documented poor security of, for example, IoT devices across a number of industries, means that a multi-layered approach to security is required by the end manufacturer.

End-user engagement and education is a key part of this puzzle. A vehicle may be secure when sold, but that is only part of the issue (although admittedly a good start). As mentioned above, 'on the fly' patching and updating is one way to deal with the issue, but this may not always be possible. If a vehicle does not have the latest critical updates installed, should it be automatically disabled as presenting a risk to other road users? What if a critical update is pushed out automatically that, in fact, creates new vulnerabilities, or compromises the car in some way? If for some reason a vehicle does need to be taken to a dealer, how can owners be educated (or incentivised) to do this quickly, when (as far as they can tell) the vehicle is behaving as it should and is perfectly roadworthy?

The ENISA guidance published in January 2017, provides a very useful and detailed guide to the issues. This guidance noted a number of critical issues with the current lifecycle for manufacture of connected cars, including no defence in depth strategies, no security or privacy by design, lack of communication protection on internal and external interfaces, lack of authentication and authorisation (particularly for privileged access to ECUs), lack of hardening, and lack of diagnosis and response capabilities. While it is perhaps to be expected that such a report would highlight serious issues in an industry which is still in relative infancy, these are major issues with the processes for designing and building CAVs which will need to be resolved.

There is some movement across the industry towards common standards which should deal with some of these issues. However, this is likely to take some time to achieve, and there is a risk of watering down to the minimum. While arguably this would, in itself, be an improvement on the current situation, it remains to be seen whether legislators will step in and impose standards on the industry. There have been moves in this direction; in 2015, Senators Markey and Blumenthal proposed standards to establish federal standards for vehicle cybersecurity in the USA, but other legislators consider that the market should be left to formulate solutions and set standards, arguing that anything proposed by government will quickly be out of date. Taking a cynical view, it may be that litigation or risk of significant liability, and the development of the insurance market, drives the industry to accelerate resolving some of these issues. There are already a number of safety and security initiatives in motion, and again, the ENISA guidance provides an excellent summary of those initiatives and what it considers to be good practice. Hopefully the industry will see significant development over the next few years to move to resolve these difficult issues.