1. IntroductionThe UNR155 regulation document Appendix 5 consists of three parts.PART A introduces vulnerabilities, threats, and attack methods related to vehicles;PART B and PART C categorize the threats from PART A into internal and external threats,with PART B discussing mitigation measures for internal threats to vehicles;and PART C discussing mitigation measures for external threats to vehicles;In the previous article on vehicle network security – UNR155 regulations – vulnerabilities and attack methods related to vehicles, we introduced vulnerabilities, threats, and attack methods related to vehicles. This article will translate the corresponding mitigation measures from PART B and PART C.2.PART B Mitigation Measures for Internal Threats to VehiclesPart B divides mitigation measures into 8 tables based on threats and attack methods.Table 1 introduces mitigation measures related to vehicle communication threats.Table 2 introduces mitigation measures related to the vehicle upgrade process.Table 3 introduces mitigation measures for risks of unintentional triggers by personnel.Table 4 introduces mitigation measures for risks of external links to vehicles.Table 5 introduces mitigation measures for threats with potential attack targets and motives.Table 6 introduces mitigation measures for risks of potential vulnerabilities that are not adequately protected or suppressed.Table 7 introduces mitigation measures for risks of vehicle data loss/leakage.Table 8 introduces mitigation measures for risks of physical tampering with systems.Below, we will introduce the mitigation measures in each table one by one.Table B1. Mitigation Measures for Vehicle Communication Threats
| Vulnerability/Threat ID | Vehicle Communication Threats | Ref | Mitigation Measures |
| 4.1 | Impersonationto deceive messages(e.g., in V2X platooning using the 802.11p protocol, GNSS messages) | M10 | The vehicle must verify the integrity and authenticity of received messages. |
| 4.2 | Sybil attack(to deceive other vehicles when many vehicles are on the road) | M11 | Secure controls should be implemented on stored encryption keys. |
| 5.1 | Communication channels allow code injection, for example, tampered software binary data may be injected into the communication stream. | M10 | The vehicle must verify the integrity and authenticity of received messages. |
| M6 | The system should implement security controls during the design phase to minimize security risks. | ||
| 5.2 | Communication channels allow tampering with data/code on the vehicle. | M7 | Access control techniques and designs should be applied to protect system data/code. |
| 5.3 | Communication channels allow overwriting data/code on the vehicle. | ||
| 5.4 | Communication channels allow erasing data/code on the vehicle. | ||
| 5.5 | Communication channels allow introducing data/code (writing data code) to the vehicle. | ||
| 6.1 | Receiving information from an unreliable or untrusted source | M10 | The vehicle must verify the integrity and authenticity of received messages. |
| 6.2 | Man-in-the-middle attack or session hijacking. | ||
| 6.3 | Replay attack, for example, an attack on the communication gateway allows the attacker to downgrade ECU software or gateway firmware. | ||
| 7.1 | Intercepting information/ interfering with transmissions/monitoring communications. | M12 | Encrypted data being sent or received should be protected. |
| 7.2 | Gaining unauthorized access to files or data. | M8 | Unauthorized access to system data should be prevented through system design and access control. |
| 8.1 | Sending a large amount of garbage data to the vehicle information system, causing it to fail to provide normal service | M13 | Establish detection and recovery mechanisms for denial-of-service attacks. |
| 8.2 | Black hole attack, to disrupt communication between vehicles, the attacker can block information between vehicles. | M13 | Establish detection and recovery mechanisms for denial-of-service attacks. |
| 9.1 | Non-privileged users can gain privileged access, such as root access. | M9 | Establish blocking and detection mechanisms for unauthorized access. |
| 10.1 | Viruses embedded in communication media affect vehicle systems. | M14 | Establish protection programs against viruses and malware. |
| 11.1 | Malicious internal communication information (e.g., CAN). | M15 | Establish mechanisms to detect malicious internal communications or activities. |
| 11.2 | Malicious V2X communication information, such as infrastructure-to-vehicle or vehicle-to-vehicle information (e.g., CAM, DENM). | M10 | The vehicle must verify the integrity and authenticity of received messages. |
| 11.3 | Malicious diagnostic information. | ||
| 11.4 | Malicious proprietary information (e.g., messages sent from OEMs or component/system/function suppliers). |
Table B2. Mitigation Measures for Threats Related to the Vehicle Upgrade Process
| Vulnerability/Threat ID | Vehicle Communication Threats | Ref | Mitigation Measures |
| 12.1 | Compromising over-the-air software updates, including creating system updates or firmware. | M16 | Secure software update mechanisms should be used. |
| 12.2 | Compromising local/physical software updates, including creating system updates or firmware. | ||
| 12.3 | Software being tampered before the update process (thus compromised), even if the update process is complete. | ||
| 12.4 | Compromising the software vendor’s encryption keys to allow invalid updates | M11 | Secure controls should be implemented on stored encryption keys. |
| 13.1 | Conducting denial-of-service attacks on update servers or networks to prevent critical software updates from being released and/or unlocking customer-specific features. | M3 | Security controls should be applied to backend systems. The backend server is crucial for providing services, and there should be recovery measures in case of system interruptions. Examples of security controls can be found in OWASP. |
Table B3. Mitigation Measures for Risks of Unintentional Triggers by Personnel
| Vulnerability/Threat ID | Vehicle Communication Threats | Ref | Mitigation Measures |
| 15.1 | Innocent victims (owners, operators, or maintenance engineers) being tricked into taking action and unintentionally loading malware or launching attacks. | M18 | Define and control user roles and access rights based on the principle of least privilege. |
| 15.2 | Defined security procedures not being adopted. | M19 | Organizations should ensure that defined security procedures are followed, including documenting behaviors and access related to security function management. |
Table B4. Mitigation Measures for Risks of External Connections to Vehicles
| Vulnerability/Threat ID | Vehicle Communication Threats | Ref | Mitigation Measures |
| 16.1 | Tampering with system functions designed for remote operation, such as remote keys, anti-theft control systems, and charging stations. | M20 | Security controls should be implemented for systems with remote access capabilities. |
| 16.2 | Tampering with vehicle remote information processing (e.g., tampering with temperature measurements of sensitive cargo, remotely opening cargo doors). | ||
| 16.3 | Interfering with short-range wireless systems or sensors. | ||
| 17.1 | Compromised applications, or those with poor software security, can be used as a means to attack vehicle systems. | M21 | Software should undergo security assessments, certifications, and integrity protection. |
| 18.1 | External interfaces such as USB or other ports are often used as attack points, for example, through code injection. | M22 | External interfaces should implement security controls. |
| 18.2 | Media systems connected to vehicle systems infected with viruses. | ||
| 18.3 | Diagnostic access interfaces being used to conduct attacks, such as tampering with vehicle parameters (directly or indirectly). | M22 | External interfaces should implement security controls. |
Table B5. Mitigation Measures for Threats with Potential Attack Targets and Motives
| Vulnerability/Threat ID | Vehicle Communication Threats | Ref | Mitigation Measures |
| 19.1 | Extracting copyrighted or proprietary software from vehicle systems (product piracy). | M7 | Access control techniques and designs should be applied to protect system data/code. |
| 19.2 | Unauthorized access to owner privacy information, such as personal information, payment account information, contacts, location, vehicle electronic ID, etc. | M8 | Unauthorized access to system data should be prevented through system design and access control. |
| 19.3 | Extraction of encryption key strings. | M11 | Secure controls should be implemented on stored encryption keys. |
| 20.1 | Illegally/unauthorized changes to vehicle electronic IDs. | M7 | Access control techniques and designs should be applied to protect system data/code. |
| 20.2 | Entity fraud, for example, users presenting as other entities when communicating with charging systems. | ||
| 20.3 | Behavior to evade monitoring systems (e.g., infiltrating/tampering/blocking ODR tracking data, motion data, etc.). | M7 | Access control techniques and designs should be applied to protect system data/code. |
| 20.4 | Data tampering to forge vehicle driving data (e.g., mileage, driving speed, driving direction, etc.). | ||
| 20.5 | Unauthorized changes to system diagnostic data. | ||
| 21.1 | Unauthorized deletion/tampering of system event logs. | M7 | Access control techniques and designs should be applied to protect system data/code. |
| 22.2 | Introducing malware or malicious software activities. | M7 | Access control techniques and designs should be applied to protect system data/code. |
| 23.1 | Vehicle control systems or information system software manufacturing. | ||
| 24.1 | Denial-of-service attacks, for example, CAN bus flooding may trigger DOS attacks on internal networks or trigger high-frequency message errors on ECU systems. | M13 | Establish detection and recovery mechanisms for denial-of-service attacks. |
| 25.1 | Unauthorized access to forged vehicle critical function configuration parameters, such as brake data, airbag deployment thresholds. | M7 | Access control techniques and designs should be applied to protect system data/code. |
| 25.2 | Unauthorized access to forged charging parameters, such as charging voltage, charging power, battery temperature, etc. |
Table B6. Mitigation Measures for Risks of Potential Vulnerabilities that are Not Adequately Protected or Suppressed
| Vulnerability/Threat ID | Vehicle Communication Threats | Ref | Mitigation Measures |
| 26.1 | Short keys and long effective periods allow attackers to crack encryption. | M23 | Best practices for cybersecurity should be followed in software and hardware development. |
| 26.2 | Insufficient use of encryption algorithms to protect sensitive systems. | ||
| 26.3 | Using deprecated or soon-to-be-deprecated encryption algorithms. | ||
| 27.1 | Hardware or software designed to be vulnerable to attacks or failing to meet design standards to prevent attacks. | M23 | Best practices for cybersecurity should be followed in software and hardware development. |
| 28.1 | Software defects, the presence of software defects may be the basis for potential exploitable vulnerabilities. This is especially true if the software has not been tested to verify that known bad code/errors do not exist and to reduce the risk of unknown bad code/errors existing. | M23 | Best practices for cybersecurity should be followed in software and hardware development. |
| 28.2 | Using remnants in development (e.g., debug ports, JTAG ports, microprocessors, development certificates, developer passwords, etc.) can allow access to ECUs or allow attackers to gain higher privileges. | ||
| 29.1 | Open excess internet ports provide a channel for accessing network systems. | ||
| 29.2 | Bypassing network segmentation to gain control. A typical case is using unprotected gateways or access points (e.g., train trailer gateways) to bypass protection mechanisms and gain access to other network areas to perform malicious actions, such as sending arbitrary CAN bus messages. | M23 | Best practices for cybersecurity should be followed in software and hardware development. |
Table B7. Mitigation Measures for Risks of Vehicle Data Loss/Leakage
| Vulnerability/Threat ID | Vehicle Communication Threats | Ref | Mitigation Measures |
| 31.1 | Information leakage. Personal data may be leaked when the vehicle changes ownership (e.g., vehicle sale or rental). | M24 | Storing personal data should follow best practices for protecting data integrity and confidentiality. |
Table B8. Mitigation Measures for Physical Tampering Systems Leading to AttacksMitigation Measures
| Vulnerability/Threat ID | Vehicle Communication Threats | Ref | Mitigation Measures |
| 32.1 | Tampering with electronic hardware, for example, unauthorized electronic hardware being added to the vehicle system to facilitate man-in-the-middle attacks. | M9 | Measures should be taken to prevent and detect unauthorized access. |
3.PART C Mitigation Measures for External Threats to VehiclesPART C introduces mitigation measures for external threats to vehicles, categorized into 3 tables.Table C1: Mitigation Measures for Threats Related to Backend Services
| Vulnerability/Threat ID | Vehicle Communication Threats | Ref | Mitigation Measures |
| 1.1&3.1 | Employee abuse of privileges leading to (internal attacks). | M1 | Security controls should be applied to backend systems to minimize the risk of internal attacks. |
| 1.2&3.3 | Unauthorized network access to servers (backdoors, unpatched system software vulnerabilities, SQL attacks, or other means). | M2 | Security controls should be applied to backend systems to minimize unauthorized access. Examples of security controls can be found in OWASP. |
| 1.3&3.4 | Unauthorized physical access to servers (USB deception or other media attacks connected to the server). | M8 | Unauthorized access to system data should be prevented through system design and access control. |
| 2.1 | Attacking backend servers to stop their functionality, for example, blocking vehicle interaction functions and services that vehicles depend on. | M3 |
Security controls should be applied to backend systems. The backend server is crucial for providing services, and there should be recovery measures in case of system interruptions. Examples of security controls can be found in OWASP. |
| 3.2 | Loss of information in the cloud. Sensitive data stored in third-party clouds may be lost due to attacks or incidents. | M4 | Security controls should be applied to minimize risks related to cloud computing. Examples of security controls can be found in OWASP and NCSC cloud computing guidelines. |
| 3.5 | Unintentional information leakage due to shared data (e.g., administrator privilege errors). | M5 | Security controls should be applied to backend systems to prevent data breaches. Examples of security controls can be found in OWASP. |
Table C2: Mitigation Measures for Unintentional Behavior Threats
| Vulnerability/Threat ID | Vehicle Communication Threats | Ref | Mitigation Measures |
| 15.1 | Innocent victims (owners, operators, or maintenance engineers) being tricked into taking action and unintentionally loading malware or launching attacks. | M18 | Define and control user roles and access rights based on the principle of least privilege. |
| 15.2 | Defined security procedures not being adopted. | M19 | Organizations should ensure that defined security procedures are followed, including documenting behaviors and access related to security function management. |
Table C3: Mitigation Measures for Physical Data Loss Threats
| Vulnerability/Threat ID | Vehicle Communication Threats | Ref | Mitigation Measures |
| 30.1 | Damage caused by third parties. In the case of traffic accidents or theft, sensitive data may be lost or leaked due to physical damage. | M24 | Storing personal data should follow best practices for protecting data integrity and confidentiality. |
| 30.2 | Loss caused by DRM (Digital Rights Management) conflicts. User data may be deleted due to DRM issues. | ||
| 30.3 | Due to wear and tear of IT components, the integrity of sensitive data may be lost, leading to potential cascading issues (e.g., in the case of key changes). |