Securing the Connected and Autonomous Vehicle

Difficult, yet fulfilling

By DRP; Cybersecurity Lab Engineer

Vehicles have been connected and on the road for years throughout the nation. This has been placed in the various vehicles and platforms to better the user experience. The consumers have enjoyed the radios with added functionality, safety services, the convenience of having the vehicle start and defrost in mid-January while the owner is walking to the vehicle. Other connected features include the user’s cell phone being connected with the car being a pass-through, current maps to guide the driver to their final destination, and other services to maintain a seamless transition through life with the vehicle as just another point of existence.

The natural extension of this has been an autonomous vehicle. The autonomous vehicles projects are closing in and will be a fully realized and executed project in the very near future. These have been promised by the manufacturing community in the next 5-7 years. Initially these may cohabitate with user-driven vehicles, however, the autonomous vehicle systems are where the driving experience is clearly headed. On a tangent, this also has a number of very useful and consumer-friendly options. The benefits are present on many levels, from efficiency to safety, and other measures. This will truly be another paradigm shift not only for the auto market but also for consumers.

Potential Issues
These clearly are and will be a fantastic addition for the vehicles and the fleets. These assuredly will continue to increase our efficiency and enjoyment of riding to our destination. As autonomous vehicles become an increasingly integral part of our society, there is one aspect that has not been properly or fully addressed. If there is any doubt regarding this, there are a number of vehicle compromises requiring recalls and OTA updates that have been present. These devices are starting to take over a greater level of the user’s responsibilities in driving, monitoring, and ownership. With this increase, the users are more dependent on the vehicle for these and other functions integral to the user’s experience, e.g. safety.

These functions, the vehicle modules, and the vehicle itself needs to be fully secured from unauthorized access and attempted unauthorized access. The OEMs should use the present InfoSec standards with equipment. When this has not been accomplished and groups have not included security into the process, except at the very end, there have been significant issues. If third party equipment is used with these vehicles, the manufacturer’s efforts at security should not be automatically trusted. These should likewise be tested. The other party’s idea and definition of security may be a bit different than the standard, accepted version.

This is required by necessity. Without this in place and actively used, there is a rather direct potential positive correlation with the user’s being in hazard’s way due to a lack of properly applied security. If the vehicle’s systems are not secure from an attack and compromise, the vehicle could be directed to brake during heavy traffic, make a sharp right turn while on the expressway during rush hour and other malicious driving patterns the vehicle would normally not complete.

This is not an easy task. The vehicle is a rather complex machine. Mechanically, there are many different systems interacting and communicating within the vehicle. The electronics present a separate and distinct set of security parameters. The attack points, physical and wireless, are massive in number in a vehicle. To test every point repeatedly would require a large amount of time.

On another point, the security surrounding the vehicle is not static. The red teams may test a module or vehicle, recommend remediation for any issues, and once implemented believe the subject is secure. As time passes, however, there may be more insecure areas and attack points that are present. This moving target makes security ever-changing and interesting.

Solution
With the complexity involved, any security function needs to be fully integrated throughout the modules, guarding the process and embedded devices. The best alternative is to maintain a quality research implementation from the design stage forward. Too many times, security is thought of within the last stage prior to production, and the interested parties then are substantially rushed. At this point also, any changes may need to be implemented with the next iteration of the part or module, which allows for the end-users to have their vehicle open to compromise until the change or patch is applied to their vehicle’s application.

This does deserve more attention and focus from manufacturers at all levels. Until this is implemented in the appropriate manner, there will continue to be the extra costs for recalls and too many patches being uploaded.

About the Author
DRP is a Cybersecurity Lab Engineer focused on securing the world for the users one module at a time. DRP’s interests include the intersection AI & ML and automotive cybersecurity.