What Are Automotive Cybersecurity Contingency Plans?

 

Interruptions from natural disasters

Hackers are not the only source of threats to autonomous and connected vehicles. There are also concerns in automotive cybersecurity where natural phenomena can cause problems that result in degraded security, which can then force systems into a degraded mode or can bring some systems down. Business impact analysis is huge.

New call-to-action

With cybersecurity being such an integral part of the operation of autonomous and connected vehicles, you must understand what could happen to your products and business if the supporting infrastructure fails. For example, if we are talking about servers, what happens to your business if that server goes down? Think about a flood within a power outage, think about all these different natural occurrence events. A robust recovery plan must be thought out and written down to make sure that if the business relies on external data storage, the data remain accessible. How fast can the system come back online, regardless of the type of disaster? And if availability is critical, will restoration be measured in seconds, minutes, hours, or days?

Businesses must have a way to recover from natural disasters. If availability is the number one priority, then there must be hot storage that can be flipped over to in an instant. However, if confidentiality or integrity is higher on the priority list than availability, and the web server goes down for three, four, or five hours until it is restored, then perhaps it will not be as big of a deal.

That’s all well and good for stationary data needs. But what about a vehicle? What if your car can't communicate back to the web service? Certain systems on an autonomous vehicle constantly communicate back to their supporting servers. They pull mapping information from the cloud, and they are constantly communicating mapping information back. That information builds a perspective for the car as it drives down the road. If that service is interrupted by days or weeks, that could affect the drivability of the vehicle. If you have never driven the vehicle down that road, and the car itself hasn't mapped the route before, there may not be any good mapping data for that area at all. The car won’t know what to do, or it could guess wrong, with disastrous results.

In this case, you would want those mapping servers to be recoverable very quickly in the event of a natural disaster. A risk analysis would have to be performed to determine if the service is interrupted or lost and how badly the vehicle is going to drive. That is a critical question that must be answered with certainty.

Failures while the vehicle is active

When an autonomous vehicle is stationary and inactive, threats from unplanned interruptions are low. If the system experiences an interruption while the vehicle is sitting still and recharging, downloading updates in the background, and communicating with the land-based infrastructure, the worst that might happen is that you might have to reboot the vehicle when service is restored and perhaps run some of those processes again. But that would be an inconvenience, not necessarily a threat to safety. Once the land-based systems communicate to the vehicle and determine that the vehicle has received the latest updates and they are properly installed, the vehicle would once again be deemed safe for a human to get in and drive. The vehicle would then remain in that version state until the next time updates were installed.

Dollarphotoclub_74989983_3-1438347546

But when the vehicle is active, either in motion or in constant communication, there are a different set of considerations. You could have a scenario where the vehicle is constantly communicating to the cloud, sending and receiving data, regardless of whether it is moving or standing still, and occupied or empty. In this latter scenario, what happens when the stream is interrupted, and you experience a data stream failure while the vehicle is in motion or mid-update?

A thorough risk assessment must be performed to determine what the impacts would be to the vehicle and the driver. It is a matter of functional safety. For example, if your vehicle was downloading the firmware, and connectivity were temporarily lost and then came back, the system would pick up where it left off and eventually build the complete disk image needed to install the firmware. The system would not start the firmware update itself unless the vehicle was sitting still in a safe state.

However, if it's a drivability issue, and you lose connectivity, you need to have some safety margins built in, where it's not critical that the connection must be maintained constantly and flawlessly without interruption. No connection will ever remain that perfect. If this system needs that data, then it must be able to queue it up in a buffer or something. You just can't have a vehicle driving down the road and 100% rely on constant uninterrupted connectivity. That degree of reliability in the infrastructure simply does not exist. Not yet anyway.

Human override capability and operability of the vehicle

As EVs become more autonomous, less human intervention will be required. When driving tasks are split between the driver and the vehicle, and the vehicle takes on more driving tasks, the human will become complacent and, eventually, fall out of practice. Even if the driver earned a license a long time ago, what happens when we essentially train humans to stop remembering how to drive? As vehicles gain more autonomy, drivers will fall out of practice. As they learn to trust the vehicle, drivers will pay less and less attention because they're taking a nap or playing games on their device or whatever. What is to prevent a human with degraded skills from taking control when they are no longer qualified to do so? What are we doing security-wise to make sure that the human side of the system maintains viability?

First, let’s examine basic access to the vehicle controls. You must have some way to make sure that the right person is at the controls. There are efforts toward biometric fingerprint authentication for vehicles. You can thumbprint the car and that becomes the key that allows you to operate it.

The biggest factor in the long term may come down to time. Way out in the future, we may no longer own cars. It will become a service. Like an Uber of today, I could call for a car to be available to me at five o'clock. This car shows up, and I simply get in and go. I could be 12 years old; it doesn't matter because the car is doing the driving. I no longer need to know how to drive it to use it.

New call-to-action

Summary

Cybersecurity is and will remain a constant presence in the automotive realm that will only increase in importance over time. It is paramount for the organization to achieve a level of maturity capable of providing security guidance for the whole organization, from development to production. And we must embrace the ethical hacking community and use tools like bug bounties to encourage the mass exploration of our systems. We can’t fix what we don’t know about, and there is strength in numbers.

EVs will lead to autonomous vehicles. There will be a transition period that might at times be bumpy. But at some point in the future once Level Four autonomy really takes off, we are going to lose manual driving skills in most of the population, just like riding horses and handwriting in cursive have faded from most of the collective memory of today. I believe that is still at least 50 years out. But the driving skill set, and the joy of driving, are going to inevitably fade away, as they are replaced by other things.

It is hard to predict the future. Personally, in my lifetime, I think I am always going to have a car that I can manually drive and some sort of road system to drive it on. But increasingly, we will just think of cars as people movers taking us from point A to point B, where we just pay for that access as we need it. In the meantime, during this transitional era, there will be choices. I think we will still enjoy driving. But there will also be scenarios where it will be nice to trust in automotive cybersecurity and leave the driving to the car, freeing us to do other things with our time as we are whisked safely to our destination. It will be interesting to see how all of this turns out.

Further reading and references

Why is Cybersecurity Important for Autonomous Vehicles?

What Can Be Done to Secure Autonomous Vehicles from Cyber Attacks? 

What are the Cybersecurity Challenges for Connected and Autonomous Vehicles?

How is automotive cybersecurity controlled? 

 

Kelly Stephenson

Written by Kelly Stephenson

Kelly joined LHP in 2022 as a Solutions Architect in Cyber Security and brings over 30 years of engineering experience in automotive and industrial IoT products. Kelly is an innovative security engineer with extensive cyber security and software development experience within automotive design markets. Kelly has experience incorporating cybersecurity standards and processes such as ISO 21434 and UNCECE requirements into all systems to help ensure safety and security of all designs. Kelly has worked with organizations such as Toyota Industrial, Ford, Cummins, John Deere, Vantage Mobility and Xalt to provide various solutions. At Ford, Kelly worked with the Connected Mobility In-Vehicle Cyber Security team and created threat models and security requirements for Driver Assisted System (DAT) modules as well as created and managed the Core Automotive Ethernet and Operating Systems security requirements for the newest technologies at Ford.. At Toyota Industrial, Kelly was the lead cyber security engineer that provided the guidance for the organization on the adoption of cyber security practices from the business, development, and production domains of the organization. Kelly was also instrumental in creating secure connectivity, secure boot, and performing a full Risk Management assessment using the Octave Allegro Risk Management Framework. At John Deere, Kelly created Certificate Policies and Third-Party Supplier agreements. He also provided additional guidance on certificate handling within the embedded controllers. At Cummins, Kelly implemented support for Automotive Ethernet technologies like XCP within the ECU’s, created Automotive Ethernet topologies for complex product solutions that included fail-safe redundancies. At Xalt, Kelly lead the development team in SafeRTOS implementation for their Battery Management System as well as thorough hardware penetration and vulnerability assessment. Kelly has received his Bachelor of Science degree in Computer & Information Technology from Purdue University and his Master of Science in Cyber Security from Valparaiso University where his thesis was Battery Management System Hardware Vulnerabilities. He currently has active certifications in Certified Automotive Cybersecurity Professional from SGS-TUV Saar, CERT Secure Coding in C and C++ from Carnegie Mellon University and Security+ from CompTIA. Kelly has also received two patent awards which are a Proximity Warning System for Parked Vehicles Patent 10,850,665 B1, December 1, 2020 and Variable Travel Valve Apparatus for an Internal Combustion Engine Patent 8,528,511, September 10, 2013.