In 2020, the United Nations Economic Commission for Europe released the final version of its vehicle regulations for cybersecurity and software updates. These regulations mark a new era for automakers: in addition to the existing type approval process, in almost all countries, automakers will need to prove that they have a secure, robust process and infrastructure for managing the remote delivery of software updates. More broadly, automakers will also need to prove that they have a comprehensive cybersecurity architecture and robust security lifecycle process. These regulations have major impacts to automakers and their suppliers, and some countries such as Japan are set to enforce these regulations within the next year.
Herein, we introduce the more important concepts in the new type approval process for both cybersecurity and software updates and provide specific recommendations to automakers and suppliers in the space.
Cybersecurity
While physical security has been a core topic for automakers for decades, cybersecurity did not truly enter the day-to-day lexicon until 2015 after the very public hacking of a Jeep Grand Cherokee platform by a pair of hackers in the United States. By proving that remote attack vectors can be exploited to affect the driving behavior of the vehicle, and thus the safety of its occupants, this moment forced automakers to reckon with the idea that they are going to have to invest in cybersecurity infrastructure if they want to compete in the connected, autonomous, and shared mobility ecosystem.
Another effect from this incident was the renewed focus by industry alliances and regulatory agencies on building standardized security frameworks for the sharing of information and uniform verification of vehicle cybersecurity. The Auto-ISAC, a non-profit focused on sharing security threat and vulnerability amongst industry stakeholders, launched its intelligence sharing platform shortly after in 2016.
In addition, SAE began development of its own cybersecurity guidelines, published in 2016 as J3061, built in part on some of the successful standards established in ISO 26262, the standard for functional safety in road vehicles. Based on J3061, ISO, in partnership in SAE International, began development of its own cybersecurity standard, ISO/SAE 21434.
This ISO standard forms the basis of the new regulation from the UNECE on vehicle cybersecurity. UNECE WP.29 Cyber Security establishes a framework wherein type approval authorities can judge whether an OEM has credibly designed and tested the cybersecurity of a vehicle platform. The standard is not yet published in its final form, but drafts offer a preview of what OEMs will need to do in order to meet UNECE type approval guidelines, such as proving a structured cybersecurity development lifecycle from concept to operations, with supporting activities such as risk assessment and on-going monitoring of the system for cybersecurity threats and vulnerabilities.
With this framework, OEMs can achieve the two core requirements within UNECE type approval guidelines for cybersecurity compliance: the provision of a Cyber Security Management System (CSMS) and type approval for individual vehicle models. A CSMS is an OEM’s end-to-end cybersecurity ecosystem, which includes both the business processes supporting cybersecurity management as well as the technologies and tools implemented by the OEM to design, develop, test, and monitor its cybersecurity disposition. An automaker is required to have its CSMS audited at least once every three years by an independent technical evaluation authority.
When a vehicle is submitted for type approval, the automaker includes a certificate of compliance issued for the CSMS, and in addition to verification of the authenticity of the certificate, the OEM must provide a variety of supplemental documents to prove that it has performed appropriate due diligence in the cybersecurity lifecycle of the vehicle model itself.
Some of the items that must be provided in the type approval file include an inventory of all cyber-critical elements, a detailed risk assessment of the vehicle, an inventory of mitigations and countermeasures, details of its cybersecurity testing procedure, and proof of its operational monitoring once the vehicle is on the road.
For many OEMs, this represents only a codification and minor iteration of its current cybersecurity profile as they have already invested in their cybersecurity lifecycles. For example, many have already integrated state-of-the-art security technologies, intrusion detection and prevention systems, modern cryptographic methods thanks to optimized hardware, and established security operations centers (SOCs) for the management of its global passenger vehicle fleets.
For some, however, this represents a major new required expenditure in organizational change, platform development, lifecycle development, and operational capabilities. These OEMs must adapt quickly or face the risk that their vehicles may not be approved for sale in a majority of global automotive markets.
Software Updates
While the concept of remote software updates to vehicles is not new, the proliferation of the technology across essentially all automakers, alongside the aggressive use of the technology by disruptors such as Tesla have created a need to regulate their use, in particular to ensure the continuing certification of safety-critical systems. This premise is the basis of WP.29 Software Updates.
WP.29 Software Updates consists of two major tenets that automakers must comply with: a secure Software Update Management System, or SUMS; and a process for modified type approval resulting from software updates which affect any function in the vehicle which is part of the regular type approval process. The SUMS is independently certified by a technical service, and any new model type approval must include a Certificate of Compliance (CoC) for the SUMS used by the vehicle. Automakers are obliged to self-regulate the modified type approval process. Furthermore, the SUMS must be re-certified at least every three years.The Software Update Management System is the end-to-end solution which delivers, manages, and secures software updates between the automaker and its vehicles. Some of these functions include the transfer of software updates to the vehicle, the security solution used to protect software update delivery and execution, the safe and secure installation process for software updates, and reporting of operational data related to the installation of software updates in the field.
The SUMS is to be certified by a technical service which evaluates documentation provided by the automaker to prove that it adheres to the requirements set forth in in the regulation. Some of the items to be evaluated by the technical service include:
- A process for identifying updates which affect the vehicle’s other type approved systems
- Security for delivering updates to vehicles
- A process for notifying users of relevant updates and associated notes
- Safe execution of updates during driving or while parked
- Clear documentation of update dependencies and rollback technical process
If the OEM’s SUMS meets the requirements as evaluated by the technical service, the service will issue the Certificate of Compliance (CoC). The OEM can then submit this certificate with any vehicle model for type approval which uses the defined SUMS.
Once the vehicle is in production, it is possible that the automaker releases a software update which changes the behavior of another type approved system. This case is one of the core targets of the regulation: the very mandate of the type approval process is broken if automakers are allowed to arbitrarily change the behavior of evaluated systems after launch with a software update.
Therefore, WP.29 further introduces a modified type approval process requirement to automakers. In short, automakers must implement an internal process for evaluating if any given software update changes the behavior of a type approved system. If so, then the update must go through an additional modified type approval process before release.
The real impact of this requirement to automakers is two-fold: first, a new compliance function will need to be added to manage software updates throughout the automaker’s vehicle portfolio. This compliance function will be tasked with evaluating if any given update impacts type approved systems in a target market.
This leads to the second real impact: planned software updates may result in a longer development cycle to release new features and services to production than is currently possible without regulation. The process, in addition to additional touchpoints with various regulatory bodies, will add bureaucratic overhead to the release process in the name of safety. In particular, this could affect automakers such as Tesla who already heavily rely on software updates to maintain their competitive advantage.The other major concept which automakers must now design for is the concept of RXSWIN¸ or Regulation X Software Identification Number. This is a new version number which encapsulates the entire vehicle’s software version. This can be thought of like an operating system version number: Windows 10 is a collection of software components, each with their own software version. For automakers, the RXSWIN for a specific vehicle is its “Windows version”, and automakers only increment this number when a type approved system is modified.
While this software version does not need to be stored on the vehicle itself, automakers must keep a record of which vehicle is on which RXSWIN to comply with the regulation. The purpose is to create a simple reference point which both automakers and regulatory agencies use to assist in the management of recalls as well as identify vehicles which are not properly receiving updates.
How the industry can prepare for new regulations
Automakers and their suppliers alike will need to invest in new organizations, technologies, and capabilities in order to meet the new regulations for cybersecurity and software updates. For automakers, cross-organizational changes will need to be made to ensure the appropriate business processes are enforced in the product development lifecycle. For suppliers, new tools and security mechanisms will need to be implemented to demonstrate all the requirements for cybersecurity controls and the SUMS. While there will be growing pains for all stakeholders involved – including the regulatory agencies in charge of enforcing the rules – the outcome should be more secure cars that allow for continuous innovation and improvement without sacrificing driver safety and privacy.
SBD Automotive has been deeply involved in the study, survey, benchmarking, planning, and development of over-the-air software update capabilities for automakers for over five years. In addition, our company’s heritage is security: the company began in 1996, focusing on the design and development of physical security systems, which has evolved into a world-class cybersecurity design and testing organization helping automakers meet and exceed emerging threats and regulatory challenges.
Author:
Alex is responsible for SBD’s information technology consulting practice. He works with SBD’s clients on a variety of strategic technology initiatives, ranging from technology management consulting to connected vehicle architecture, development, and cybersecurity. Alex’s publications at SBD include syndicated research on over-the-air software updates, infotainment software and ecosystems, and software-defined cars. Prior to joining SBD, Alex was a solution architect for a major connected vehicle software-as-a-service provider and mobile network operator in North America. Alex is currently based in Nagoya, Japan.
Published in Telematics Wire
