UNR 155 Complete Mitigation Reference (M1–M24)
Below is a quick reference from UNR 155 Cybersecurity Mitigations (Annex 5), Parts B & C.
Source: UN Regulation No. 155, Annex 5, Parts B & C (Supplement 3 to the original version — Date of entry into force: 10 January 2025)
All text reproduced verbatim from the regulation. No language has been altered.
M1 — Insider Attack Risk Minimisation (Back-end)
Mitigation: Security Controls are applied to back-end systems to minimise the risk of insider attack
| Annex 5 Part A Ref | Threat |
|---|---|
| 1.1, 3.1 | Abuse of privileges by staff (insider attack) |
M2 — Unauthorised Back-end Access Prevention
Mitigation: Security Controls are applied to back-end systems to minimise unauthorised access. Example Security Controls can be found in OWASP
| Annex 5 Part A Ref | Threat |
|---|---|
| 1.2, 3.3 | Unauthorised internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means) |
M3 — Back-end System Recovery Controls
Mitigation: Security Controls are 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
| Annex 5 Part A Ref | Threat |
|---|---|
| 2.1 | Attack on back-end server stops it functioning, for example it prevents it from interacting with vehicles and providing services they rely on |
| 13.1 | Denial of Service attack against update server or network to prevent rollout of critical software updates and/or unlock of customer specific features |
M4 — Cloud Computing Risk Controls
Mitigation: Security Controls are applied to minimise risks associated with cloud computing. Example Security Controls can be found in OWASP and NCSC cloud computing guidance
| Annex 5 Part A Ref | Threat |
|---|---|
| 3.2 | Loss of information in the cloud. Sensitive data may be lost due to attacks or accidents when data is stored by third-party cloud service providers |
M5 — Back-end Data Breach Prevention
Mitigation: Security Controls are applied to back-end systems to prevent data breaches. Example Security Controls can be found in OWASP
| Annex 5 Part A Ref | Threat |
|---|---|
| 3.5 | Information breach by unintended sharing of data (e.g. admin errors, storing data in servers in garages) |
M6 — Security by Design
Mitigation: Systems shall implement security by design to minimize risks
| Annex 5 Part A Ref | Threat |
|---|---|
| 5.1 | Communication channels permit code injection into vehicle held data/code, for example tampered software binary might be injected into the communication stream |
M7 — Access Control for System Data/Code
Mitigation: Access control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP
Note: For threats 20.3 and 20.4, the standard adds: “Data manipulation attacks on sensors or transmitted data could be mitigated by correlating the data from different sources of information”
| Annex 5 Part A Ref | Threat |
|---|---|
| 5.2 | Communication channels permit manipulation of vehicle held data/code |
| 5.3 | Communication channels permit overwrite of vehicle held data/code |
| 5.4, 21.1 | Communication channels permit erasure of vehicle held data/code |
| 5.5 | Communication channels permit introduction of data/code to vehicle systems (write data code) |
| 19.1 | Extraction of copyright or proprietary software from vehicle systems (product piracy / stolen software) |
| 20.1 | Illegal/unauthorised changes to vehicle’s electronic ID |
| 20.2 | Identity fraud. For example, if a user wants to display another identity when communicating with toll systems, manufacturer backend |
| 20.3 | Action to circumvent monitoring systems (e.g. hacking/ tampering/ blocking of messages such as ODR Tracker data, or number of runs) |
| 20.4 | Data manipulation to falsify vehicle’s driving data (e.g. mileage, driving speed, driving directions, etc.) |
| 20.5 | Unauthorised changes to system diagnostic data |
| 21.1 | Unauthorized deletion/manipulation of system event logs |
| 22.2 | Introduce malicious software or malicious software activity |
| 23.1 | Fabrication of software of the vehicle control system or information system |
| 25.1 | Unauthorized access to falsify configuration parameters of vehicle’s key functions, such as brake data, airbag deployed threshold, etc. |
| 25.2 | Unauthorized access to falsify charging parameters, such as charging voltage, charging power, battery temperature, etc. |
M8 — Protection of Personal and System Critical Data
Mitigation: Through system design and access control it should not be possible for unauthorized personnel to access personal or system critical data. Examples of Security Controls can be found in OWASP
| Annex 5 Part A Ref | Threat |
|---|---|
| 1.3, 3.4 | Unauthorised physical access to the server (conducted by for example USB sticks or other media connecting to the server) |
| 7.2 | Gaining unauthorized access to files or data |
| 19.2 | Unauthorized access to the owner’s privacy information such as personal identity, payment account information, address book information, location information, vehicle’s electronic ID, etc. |
M9 — Prevention and Detection of Unauthorized Access
Mitigation: Measures to prevent and detect unauthorized access shall be employed
| Annex 5 Part A Ref | Threat |
|---|---|
| 9.1 | An unprivileged user is able to gain privileged access, for example root access |
| 32.1 | Manipulation of electronic hardware, e.g. unauthorized electronic hardware added to a vehicle to enable “man-in-the-middle” attack. Replacement of authorized electronic hardware (e.g., sensors) with unauthorized electronic hardware. Manipulation of the information collected by a sensor (for example, using a magnet to tamper with the Hall effect sensor connected to the gearbox) |
M10 — Message Authenticity and Integrity Verification
Mitigation: The vehicle shall verify the authenticity and integrity of messages it receives
| Annex 5 Part A Ref | Threat |
|---|---|
| 4.1 | Spoofing of messages (e.g. V2X cooperative awareness or manoeuvre coordination messages, GNSS messages, etc.) by impersonation |
| 5.1 | Communication channels permit code injection into vehicle held data/code, for example tampered software binary might be injected into the communication stream |
| 6.1 | Accepting information from an unreliable or untrusted source |
| 6.2 | Man in the middle attack / session hijacking |
| 6.3 | Replay attack, for example an attack against a communication gateway allows the attacker to downgrade software of an ECU or firmware of the gateway |
| 11.2 | Malicious V2X messages, e.g. infrastructure to vehicle or vehicle-vehicle messages (e.g. CAM, DENM) |
| 11.3 | Malicious diagnostic messages |
| 11.4 | Malicious proprietary messages (e.g. those normally sent from OEM or component/system/function supplier) |
M11 — Cryptographic Key Storage Controls
Mitigation: Security controls shall be implemented for storing cryptographic keys (e.g., use of Hardware Security Modules)
| Annex 5 Part A Ref | Threat |
|---|---|
| 4.2 | Sybil attack (in order to spoof other vehicles as if there are many vehicles on the road) |
| 12.4 | Compromise of cryptographic keys of the software provider to allow invalid update |
| 19.3 | Extraction of cryptographic keys |
M12 — Confidentiality of Transmitted Data
Mitigation: Confidential data transmitted to or from the vehicle shall be protected
| Annex 5 Part A Ref | Threat |
|---|---|
| 7.1 | Interception of information / interfering radiations / monitoring communications |
M13 — Denial of Service Detection and Recovery
Mitigation: Measures to detect and recover from a denial of service attack shall be employed
| Annex 5 Part A Ref | Threat |
|---|---|
| 8.1 | Sending a large number of garbage data to vehicle information system, so that it is unable to provide services in the normal manner |
| 8.2 | Black hole attack, disruption of communication between vehicles by blocking the transfer of messages to other vehicles |
| 24.1 | Denial of service, for example this may be triggered on the internal network by flooding a CAN bus, or by provoking faults on an ECU via a high rate of messaging |
M14 — Virus and Malware Protection
Mitigation: Measures to protect systems against embedded viruses/malware should be considered
| Annex 5 Part A Ref | Threat |
|---|---|
| 10.1 | Virus embedded in communication media infects vehicle systems |
M15 — Malicious Internal Message Detection
Mitigation: Measures to detect malicious internal messages or activity should be considered
| Annex 5 Part A Ref | Threat |
|---|---|
| 11.1 | Malicious internal (e.g. CAN) messages |
M16 — Secure Software Update Procedures
Mitigation: Secure software update procedures shall be employed
| Annex 5 Part A Ref | Threat |
|---|---|
| 12.1 | Compromise of over the air software update procedures. This includes fabricating the system update program or firmware |
| 12.2 | Compromise of local/physical software update procedures. This includes fabricating the system update program or firmware |
| 12.3 | The software is manipulated before the update process (and is therefore corrupted), although the update process is intact |
M17
Note: M17 is not defined in the current version of UN R155 Annex 5. The numbering skips from M16 to M18.
M18 — User Roles and Access Privileges
Mitigation: Measures shall be implemented for defining and controlling user roles and access privileges, based on the principle of least access privilege
| Annex 5 Part A Ref | Threat |
|---|---|
| 15.1 | Innocent victim (e.g. owner, operator or maintenance engineer) is tricked into taking an action to unintentionally load malware or enable an attack |
M19 — Security Procedure Compliance
Mitigation: Organizations shall ensure security procedures are defined and followed including logging of actions and access related to the management of the security functions
| Annex 5 Part A Ref | Threat |
|---|---|
| 15.2 | Defined security procedures are not followed |
M20 — Remote Access Security Controls
Mitigation: Security controls shall be applied to systems that have remote access
| Annex 5 Part A Ref | Threat |
|---|---|
| 16.1 | Manipulation of functions designed to remotely operate vehicle systems, such as remote key, immobiliser, and charging pile |
| 16.2 | Manipulation of vehicle telematics (e.g. manipulate temperature measurement of sensitive goods, remotely unlock cargo doors) |
| 16.3 | Interference with short range wireless systems or sensors |
M21 — Third-Party Software Security
Mitigation: Software shall be security assessed, authenticated and integrity protected. Security controls shall be applied to minimise the risk from third party software that is intended or foreseeable to be hosted on the vehicle
| Annex 5 Part A Ref | Threat |
|---|---|
| 17.1 | Corrupted applications, or those with poor software security, used as a method to attack vehicle systems |
M22 — External Interface Security Controls
Mitigation: Security controls shall be applied to external interfaces
| Annex 5 Part A Ref | Threat |
|---|---|
| 18.1 | External interfaces such as USB or other ports used as a point of attack, for example through code injection |
| 18.2 | Media infected with viruses connected to the vehicle |
| 18.3 | Diagnostic access (e.g. dongles in OBD port) used to facilitate an attack, e.g. manipulate vehicle parameters (directly or indirectly) |
M23 — Cybersecurity Best Practices for Development
Mitigation: Cybersecurity best practices for software and hardware development shall be followed
Note: For threats 28.1, 29.1, and 29.2, the standard adds: “Cybersecurity testing with adequate coverage.” For threat 29.2, it also adds: “Cybersecurity best practices for system design and system integration shall be followed.”
| Annex 5 Part A Ref | Threat |
|---|---|
| 26.1 | Combination of short encryption keys and long period of validity enables attacker to break encryption |
| 26.2 | Insufficient use of cryptographic algorithms to protect sensitive systems |
| 26.3 | Using deprecated cryptographic algorithms |
| 27.1 | Hardware or software, engineered to enable an attack or fail to meet design criteria to stop an attack |
| 28.1 | 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 is not present and reduce the risk of unknown bad code/bugs being present |
| 28.2 | Using remainders from development (e.g. debug ports, JTAG ports, microprocessors, development certificates, developer passwords, …) can permit an attacker to access ECUs or gain higher privileges |
| 29.1 | Superfluous internet ports left open, providing access to network systems |
| 29.2 | Circumvent network separation to gain control. Specific example is the use of unprotected gateways, or access points (such as truck-trailer gateways), to circumvent protections and gain access to other network segments to perform malicious acts, such as sending arbitrary CAN bus messages |
M24 — Personal Data Protection
Mitigation: Best practices for the protection of data integrity and confidentiality shall be followed for storing personal data
Note: The standard adds: “Example Security Controls can be found in ISO/SC27/WG5”
| Annex 5 Part A Ref | Threat |
|---|---|
| 30.1 | Damage caused by a third party. Sensitive data may be lost or compromised due to physical damages in cases of traffic accident or theft |
| 30.2 | Loss from DRM (digital right management) conflicts. User data may be deleted due to DRM issues |
| 30.3 | The (integrity of) sensitive data may be lost due to IT components wear and tear, causing potential cascading issues (in case of key alteration, for example) |
| 31.1 | Information breach. Personal data may be leaked when the car changes user (e.g. is sold or is used as hire vehicle with new hirers) |
Source: UN Regulation No. 155, Annex 5, Parts B & C (Supplement 3 to the original version — Date of entry into force: 10 January 2025)
All text reproduced verbatim from the regulation. No language has been altered.