How UNECE WP.29 Put the Brakes on Automotive Cybersecurity Threats

December 07, 2021

Story

For the past 5 years, most car manufacturers have incorporated advanced hardware capable of providing driver-assistance capabilities, such as automated steering, breaking, adaptive cruise control, automatic parking, collision avoidance, lane change assistance, and much more.

Some of these Advanced Driving Assistance Systems (ADAS) like the Tesla Autopilot AI, Volkswagen ID.3, and others, like GM’s Super Cruise, come standard and equipped in the vehicle. Other driver-assistance systems come as external devices, like comma.ai, which you can plug right into the vehicle’s on-board diagnostics II (OBD-II) port to access the vehicle’s computer and experience level 2 (steering and acceleration) autonomous driving.

ADAS relies on multiple real-time data sources collected from the vehicle’s outside environment in order to perform its capabilities and do them safely. Visual data from cameras, imaging from LiDAR, radar for distance measuring, telemetry data such as speed, location, and tracking, as well as vehicle-to-vehicle communication are just a few data sources to mention.

Collaboration and communication also need to occur between telematics, gateways, infotainment systems, and other ECUs in support of ADAS and take place over a controller area network (CAN bus). Communication expands into various technologies, like Bluetooth, into high-speed broadband or mobile networks, such as LTE and 5G, where you can lock and unlock your car doors, start your engine and see your vehicle status or where you parked it. All accomplished from a phone app. Make sure not to forget your personal identification number (PIN)!

Although having a secret 4-digit PIN will make you feel warm and comfortable, it's not enough to ensure your vehicle’s cybersecurity. As today's connected, automated, and autonomous vehicles become more and more complex, the danger of potential cyberattacks have increased substantially.

ECE WP.29 Vehicle Cyber Security

After much preparation, the United Nations Economic Commission for Europe (UNECE) released regulatory requirements on June 23, 2020, outlining new processes and technologies that automotive manufacturers must incorporate within their organization and vehicles. This does not just apply to original equipment manufacturers (OEMs), but also to Tier 1 and Tier 2 software and hardware components and mobile services.

The new regulation applies to 54 countries and is known as UNECE WP.29 Cybersecurity and Cybersecurity Management Systems (CSMS). This means that vehicle manufactures are required to put into the organizational structure a risk-based management framework for discovering, analyzing, and protecting against relevant threats, vulnerabilities, and cyberattacks. I’m sure you can incorporate security into your existing quality management system (QMS) and processes as required by ISO 26262-2 for attaining quality and safety.

Additionally, there are ECE WP.29 requirements for the vehicle type (category M and N, including categories L6 and L7 if equipped with automated driving functionalities from level 3 onwards) that include testing the implementation of its cybersecurity controls and passing inspection. Successfully achieving both organizational and vehicle ECE WP.29 key requirements means that the manufacturer receives a certificate of compliance from an approval authority. New vehicles without this certificate cannot be sold in the EU after June 2022.

A small sample list of threats and corresponding mitigations from ECE/TRANS/WP.29/2020/79 Annex 5 Table B1 are shown below. Table B1 focuses on threats and mitigation activities related to the vehicle communication channels. Note the mitigation “shall” statements represent requirements that must be fulfilled, while the mitigation “should” statements express a demonstration in the endeavor to mitigate the threat.

Table B1 - Mitigation to the threats related to "Vehicle communication channels"
Table A1 reference	Threats to "Vehicle communication channels"	Ref	Mitigation
4.1	Spoofing of messages (e.g. 802.11p V2X during platooning, GNSS messages, etc.) by impersonation.	M10	The vehicle shall verify the authenticity and integrity of messages it receives.
5.1	Communication channels permit code injection into vehicle held data/code, for example tampered software binary might be injected into the communication stream.	M10 M6	The vehicle shall verify the authenticity and integrity of messages it receives. Systems shall implement security by design to minimize risks.
6.1	Accepting information from an unreliable or untrusted source.	M10	The vehicle shall verify the authenticity and integrity of messages it receives.
7.2	Gaining unauthorized access to files or data.	M8	Through system design and access control it should not be possible for unauthorized personnel to access personal or system critical data. An example of Security Controls can be found in OWASP.
11.1	Malicious internal (e.g. CAN) messages.	M15	Measures to detect malicious internal messages or activity should be considered.

 

WP.29 paragraph 7.3.3 also mentions how the vehicle manufacturer shall perform an exhaustive “risk assessment” but does not tell you how to make that assessment. However, paragraph 5.3.1(a) hints at various standards regarding risk assessment knowledge. One of them being automotive cybersecurity standard ISO/SAE 21434—road vehicles—cybersecurity engineering.

ISO/SAE 21434 Road Vehicles—Cybersecurity Engineering

A joint working group from the ISO and SAE organizations released a draft form of ISO/SAE 21434 in May 2020 for vehicle manufacturers and suppliers. The standard aims at ensuring that:

• Cybersecurity risks are managed successfully.
• Cybersecurity policies and processes are defined.
• A cybersecurity culture is fostered.

The draft standard is broken up into various “clauses” or parts. One of the clauses that caught my eye is on “risk assessment methods” where threat and damage scenarios need to be considered. Threats such as an attack path in spoofing CAN messages to the powertrain ECU that can lead to loss of control and possible harm. Since attacks can come from various mediums, like Bluetooth, LTE, USB, or physical access, ISO/SAE 21434, threats have been categorized by way of attack feasibility ratings:

• High
• Medium
• Low
• Very low

A defense-in-depth approach, which refers to utilizing layers of cybersecurity measures in case the attack can penetrate a layer, will need to be documented and put in place. Safety impact is to be addressed by the Road vehicles—Functional safety standard ISO 26262.

Cybersecurity Assurance Level

Threat paths also coincide with damage. The following damage impact ratings have been defined:

• Severe
• Major
• Moderate
• Negligible

A cybersecurity assurance level (CAL) can be determined based on threat and damage scenarios. CAL 4 level requires the highest level of rigor in cybersecurity design, testing, and review. CAL 1 requires a low level of rigor.

Example of CAL determination based on impact and attack vector parameters

		Attack Vector
		Physical	Local	Adjacent	Network
Impact	Negligible	_-	_-	_-	_-
	Moderate	CAL 1	CAL 1	CAL 2	CAL 3
	Major	CAL 1	CAL 2	CAL 3	CAL 4
	Severe	CAL 2	CAL 3	CAL 4	CAL 4

A CAL level assigned to a software or hardware component can affect methods used for their development and testing. For example, there are recommended verification methods for integration, such as requirements-based testing, interface testing, resource usage evaluation, control flow and data flow, and static code analysis for software. At the code unit level, structural coverage at the statement or branch may be recommended. The table below shows recommended methods for deriving test cases. The check marks indicate recommendations.

Methods for deriving test cases

Topics	CAL
	1	2	3	4
Analysis of requirements	✔	✔	✔	✔
Generation and analysis of equivalence classes			✔	✔
Boundary value analysis			✔	✔
Error guessing

 

Cybersecurity Throughout the SDLC

Per ISO/SAE 21434, cybersecurity must be addressed from the left and into the right side of the V-model. As an embedded engineer, you know this represents the entire software development lifecycle. Starting from requirements into design, implementation, integration, and verification & validation (V&V).

Therefore, make sure that you have a solid application lifecycle management (ALM) or requirements management (RM) tool. In addition to your stakeholder and all other safety regulatory requirements, ECE WP.29 cybersecurity requirements will also need to be satisfied. Employing a traceability matrix will ensure that no cybersecurity requirements are missed. 

Parasoft Standards Compliance and Test Configurations

For V&V, ISO/SAE 21434 recommends testing methods like static code analysis, control and data flow verification, boundary value analysis, structural code coverage, and more.

A perfect place to start tacking your cybersecurity requirements is using coding standards like SEI CERT, CWE, OWASP, and MISRA C:2012. These coding standards and others alike can detect security vulnerabilities as the code is being written and/or as part of your continuous integration (CI) pipeline.

Employ structural code coverage as recommended by the standard so that you know what pieces of software have not been tested. Take into consideration the evolutionary transformation that is taking place in the automotive industry and how it's going to impact not just the ISO/SAE 21434 standard but the development tools being used. Make sure they can easily accommodate this progression. For example, check that the tool has been TÜV certified for use on safety-critical systems. It will be well poised when the time comes for the tool to also be certified for use on cybersecurity-critical systems.

---

Ricardo Camacho is a Senior Technical Product Marketing Manager with Parasoft, focused on the embedded space, working with standards such as ISO 26262, DO-178, IEC 61508, IEC 62304 & more.  He has over 30 years of experience in Systems & Software engineering of real-time, safety and security critical systems.  His career expands multiple roles; software engineering lead at Xerox, and GE Rail, manager of solution architects at a UML model driven development startup, which was acquired by IBM.  Next, Ricardo took on the role of project manager at a software testing company, delivering software testing services, and then moved into technical product marketing.