Cybersecurity Update: What Do the Latest WP.29 UNECE Regulations Cover?
With the growth in the number of electric and autonomous vehicles, where the vast majority of components are built on software, the amount of code in a vehicle is only going to increase. Connectivity, both within the vehicle and outside, is also increasing, meaning that the security of these systems has become more critical than ever before.
For any system where there is communication between components or with the outside world, there is an increase in possible software cybersecurity threats. A cyberattack either directly or indirectly on an automotive system could lead to potential safety, financial, operational, or privacy losses. Fortunately, WP.29 was adopted to specifically address cybersecurity concerns for automotive software.
Background on WP.29
The objective of the United Nations Economic Commission for Europe (UNECE) World Forum for Harmonization of Vehicle Regulations (WP.29) is to “initiate and pursue actions aimed at the worldwide harmonization or development of technical regulations for vehicles.” The aims of these regulations include improving vehicle safety, protecting the environment, and promoting energy efficiency. They also aim to improve security.
In 2020, two WP.29 UNECE Regulations on Cybersecurity and Software Updates were adopted specifically to address security concerns. They assist in tackling the cybersecurity risks by establishing clear process requirements for automotive manufacturers which apply to the whole supply chain.
The two regulations cover:
- Cyber Security Management System (CSMS)
- Software Update Management Systems (SUMS).
They require that measures are applied across 4 distinct areas:
- Managing vehicle cyber risks
- Securing vehicles by design
- Detecting and responding to security incidents
- Providing safe and secure software updates.
The regulations apply to passenger cars, vans, trucks, and buses manufactured in the European Union from July 2022 and have also been adopted in Japan and South Korea.Back to top
How to Enforce R155 Cybersecurity Guidelines: Cyber Security Management Systems
The first regulation, R155, describes a Cyber Security Management System (CSMS) which applies to the whole product lifecycle from development, through production and into post-production.
The core of the CSMS is a threat analysis which identifies all the threats listed in Annex 5, Part A applicable to the system together with the possible impact, and appropriate mitigations for both inside and outside the vehicle, as listed in Part B.
Types of threats can include:
- Vehicle communication channels
- Unintended human action
- External connectivity and connections
- Potential vulnerabilities that could be exploited if not sufficiently protected or hardened.
4.3.7 Potential vulnerabilities that could be exploited if not sufficiently protected or hardened
Parts or supplies could be compromised to permit vehicles to be attacked
Hardware or software, engineered to enable an attack or fails to meet design criteria to stop an attack
Cybersecurity best practices for software and hardware development shall be followed
Software or hardware development permits vulnerabilities
Software bugs. The presence of software bugs can be a basis for potential exploitable vulnerabilities. This is particularly true if software has not been tested to verify that known bad code/bugs are not present and reduce the risk of unknown bad code/bugs being present
Cybersecurity best practices for software and hardware development shall be followed.
The processes in the CSMS must then ensure that security is adequately considered (including all the threats and mitigations identified in the threat analysis) for the whole product lifecycle.
This includes monitoring, detecting, and responding to cyberattacks, cyber threats, and vulnerabilities and updating when new cyber threats and vulnerabilities are identified. This may include the use of OWASP or CWE lists especially where security controls are required.
Cybersecurity best practices for software development include the use coding standards. ISO 21434, which is referred to in section 5.3.1 and is complementary to WP.29, gives examples of MISRA or CERT to detect security issues. Furthermore, static analysis, performed with tools such as Perforce's Helix QAC or Klocwork, are recommended methods of verification of the coding standard.Back to top
How to Enforce R156 Cybersecurity Guidelines: Software Update Management Systems
The second regulation, R156, dictates standards and requirements for the implementation of a Software Update Management System (SUMS).
Software updates for connected vehicles are becoming increasingly advanced and successful execution of these is pivotal to an OEM’s success in the competitive and ever-changing landscape of technological innovations.
Software updates serve as a vital way to continuously deliver not only new features that customers expect — as they would from a smartphone — but also to deploy critical updates that ensure the safety of drivers, passengers, and even pedestrians.
Threats related to software updates are noted in R155, as detailed below.
4.3.3. Threats to vehicles regarding their update procedures
It is possible to deny legitimate updates
Denial of Service attack against update server or network to prevent rollout of critical software updates and/or unlock of customer specific features
Security Controls shall be applied to back-end systems. Where back-end servers are critical to the provision of services there are recovery measures in case of system outage. Example Security Controls can be found in OWASP
SUMS is defined as a systematic approach that includes organizational processes and procedures to mitigation of those threats and to ensure the safe and successful delivery of software updates.
To create the update, there are processes in SUMS to ensure the quality of both the update and the update mechanism.
Section 18.104.22.168. describes the processes used to verify and validate software functionality and code for the software used in the vehicle. This is to ensure that only properly tested software updates are sent to the vehicle which should minimize bug-fixing of errors.
Although the specific testing process is not specified, once again ISO 21434 is referenced with its requirements to use a coding standard and static analysis.
Additional processes need to be in place to ensure that the update mechanism cannot be compromised to provide unauthorized updates. These development processes to create the update system are intended to build in security by design – this is related to the ISO 21434 with its requirement to develop a culture of security from the start of the project.
Other processes in SUMS include safety assurance mechanisms to prevent updates from being installed when they may impact driver safety. Updates can only occur when the vehicle is in a "safe state" has sufficient power to complete the update. ("Safe state," as defined by ISO 26262, is an “operating mode in case of a failure of an item without an unreasonable level of risk.”)
There must also be a mechanism that notifies the owner before an update is executed, as well as whether the update was successful or unsuccessful.
The overall requirement of SUMS is to develop processes for all activities necessary for software updates and to implement a strategy of cybersecurity at all stages of development.Back to top