Cybersecurity Regulations and Intrusion Detection Systems (IDS) as per UNECE regulation UN R155 versus Chinese GB/T (Guobiao Standards)

by Gilad Bandel and Dar Kahllon, CYMOTIVE Technologies | July 31, 2022

The Introduction of Cybersecurity Regulations in the Automotive Industry

Within the last few years, the automotive industry has witnessed the emergence of cybersecurity regulations. The two most prominent are the UNECE regulation UN R155 that applies to the UNECE member states and the GB/T that applies to China. 

As the automotive industry transforms into a digital software-based industry, the challenges and risks are significantly higher. Automotive cybersecurity is a set of practices, principles, technologies and solutions designed to protect today’s connected vehicles from being exploited by malicious hackers. 

The IDS (Intrusion Detection System) is a software component monitoring the network and hosts for indications of cyberattacks. Typically, the IDS alerts cyber events to a SIEM (Security Information and Event Management) in the VSOC (Vehicle Security Operations Center). In some cases, the functionality is extended to include the prevention of cyber events and then it is referred to as a IDPS (Intrusion Detection and Prevention System). The IDS is a cornerstone in vehicle cybersecurity protection.

The two regulations took different approaches to automotive cybersecurity challenges:

  • UN R155 provides guidelines for vehicle protection and principles. Even the implementation cookbook of the ISO/SAE 21434 standard does not dictate what and how an IDS should function.
  • GB/T 29246-2017, 28628-2020 specifies the explicit requirements for an IDS, its functionality, listing the attacks that must be monitored and how it should be tested.

Below is a review of the IDS generic functionality describing how those are reflected in both regulations. 

The GB/T is written and clearly explained for cybersecurity experts. It is very detailed, explaining exactly what the required functionality of the IDS is and how it should be tested. 

In contrast, the UN R155 speaks about concepts rather than prescribed functionality. As such, it leaves much more room for the imagination, leaving a gap of information on what it is required exactly from an IDS to perform and how auditors should verify its compliance. 

Intended audience

This article is primarily targeted at OEMs (Original Equipment Manufacturers) since they need to pass the cybersecurity certification required for regulatory vehicle type approval. Here we have two cases: Either they specify the IDS functionality for Tier 1 suppliers, or they choose to develop this functionality on their own. 

Having said that, tier 1 suppliers should find this article equally as important since they are the ones developing the gateway and other relevant ECUs. Here we have two similar cases: Either the Tier 1 writes specifications for IDS to be supplied by another vendor or they develop the IDS inhouse.

The article is also important for security software companies developing IDSs which are required to provide a solution that fits well with the standard’s requirements and the market’s needs.

Testing companies should read this from their perspective as a preparation of the STD (System Test Document) and the STP (System Testing Procedure).

Analysts, consultants, industry experts and similar will find this helpful as well.

GB/T Chinese Regulations 

The following are details about the requirements of the GB/T. Note they are formulated at a detailed level drilling down into specific requirements.

  • Gateway types
    • CANbus (CAN, CAN/FD)
    • Automotive Ethernet
    • Hybrid gateway including in addition other interfaces such LIN, FlexRay, MOST, etc. 
  • Backdoors, hidden interfaces – inexistence 
  • Root of trust
  • CANbus
  • CAN communication matrix and access control policy enforcement 
    • DoS (Denial of Service) detection
    • Frame format validity
    • Signal validity and sanity
    • Timing anomality detection
    • Periodic messages verification
    • Specific attack scenarios (CAN data frame flooding attack, CAN ID forgery, CAN data replay attack, CAN network scanning, ECU authentication crack
    • UDS
  • Automotive Ethernet
    • Network segregation
    • Access control enforcement
    • Protocol state 
    • Specific attack scenarios (Ping of Death, ICMP flooding attack, UDP flooding attack, TCP SYN attack, Teardrop attack, ARP spoofing attack, IP spoofing attack, ICMP Smurf attack, IP address scan, port scan)
    • Authentication and validation 
  • Firmware
    • Secure boot
    • Security log (syslog)
  • Data storage security
    • File encryption 
    • Data at rest
  • Firewall
    • Detect TCP Syn Flood
      • Receiving the “Possible SYN flooding on port “xy”. Sending cookies.” Kernel message
      • Receiving invalid (Syn Cookie Mismatch) TCP messages with flags SYN-ACK
    • Detect port probing
      • Receiving requests to non-whitelisted ports
    • Detect ICMP endpoint alive probing
      • Receiving non-whitelisted ICMP messages
    • Detect TCP endpoint alive probing
      • Receiving requests to non-whitelisted ports
    • Detect UDP endpoint alive probing
      • Receiving requests to non-whitelisted ports
    • Detect TCP connect port probing
      • Receiving requests to non-whitelisted ports
    • Detect TCP FIN Port Scanning
      • Receiving initial TCP FIN packets
    • Detect TCP NULL Port Scanning
      • Receiving TCP packets with all flag bits empty
    • Detect TCP SYN Port Scanning
      • Receiving TCP SYN packets to non-whitelisted ports
    • Detect TCP ACK Port Scanning
      • Receiving initial TCP ACK packets
    • Detect TCP Xmas Port Scanning
      • Receiving TCP packets with all flag bits set
    • Detect UDP port scanning
      • Receiving UDP requests to non-whitelisted ports
    • Detect TCP Ping of Death
      • Receiving packets bigger than MTU (1500 Bytes)
    • Detect Large Ping
      • Receiving packets bigger than MTU (1500 Bytes)
    • Detect invalid ACK/FIN Flag bit Setting
      • Receiving TCP packets with ACK & FIN Flag bits set
    • Detect invalid ACK/RST Flag bit Setting
      • Receiving TCP packets with ACK & RST Flag bits set
    • Detect invalid FIN/SYN Flag bit Setting
      • Receiving TCP packets with FIN & SYN Flag bits set
    • Detect invalid FIN/RST Flag bit Setting
      • Receiving TCP packets with FIN & RST Flag bits set
    • Detect ICMP Echo flooding
      • Receiving ICMP echo requests exceeding the burst rate limit
    • Detect ICMP Flooding
      • Receiving ICMP requests exceeding the burst rate limit
    • Detect Fraggle Attack
      • Receiving messages on UDP ports 7 or 19
    • Detect ICMP Smurf Attack
      • Receiving ICMP reply messages exceeding the burst rate limit
    • Detect ICMP and IGMP Flooding
      • Receiving IGMP requests
    • Detect TCP Connecting Attack
      • Receiving more than 300 connections on a specific port
    • Detect UDP Flooding
      • Receiving UDP requests exceeding the burst rate limit
    • Detect TCP ACK Flooding
      • Receiving TCP requests with ACK bit always set after TCP link is established.
    • Detect Non-Spoofed UDP Flooding
      • Receiving UDP requests exceeding the burst rate limit
    • Detect TCP SYN Flooding
      • Receiving the “Possible SYN flooding on port xy. Sending cookies.” kernel message
      • Receiving invalid (Syn Cookie Mismatch) TCP messages with flags SYN-ACK
    • Detect TCP SYN-ACK Flooding
      • Receiving unexpected SYN-ACK messages
    • Detect Data Ack and Push Flooding
      • Receiving TCP packets where PUSH or ACK is set exceeding the burst rate limit
    • Detect Fake Source ICMP
    • Detect Fragmented ACK
    • Detect TCP SYN-ACK Flooding
      • Receiving TCP packets with FIN & SYN Flag bits set simultaneously
    • Detect TCP-Land Attack
      • Receiving TCP packet where SYN is set and source IP = destination IP
    • Detect TCP 0 Source Port Messages
      • Receiving TCP requests with source port 0
    • Detect UDP 0 Source Port Messages
      • Receiving UDP requests with source port 0
    • Detect unclassified anomalies
      • Receiving unallowed IP packets not handled by any other firewall rule

 

The United Nations (UN) No. 155 Regulation 

Following are details about the requirements of the UN R155. Note they are formulated at a high level without going into specific requirements.

  • General
    • The IDS should collect multiple and different logs from different entities for attack vector identification
    • The IDS should have online and offline detection and prevention capabilities against vehicles cyber-attacks
    • Security logs should include a sufficient number of details (related to security incidents), for the required vehicle manufacturer’s annual security report. Incident information should include, at minimum, but not limited to:
      1. Timestamp
      2. User ID
      3. Function/service ID
      4. Involved/impacted component (ECU, function etc.)
      5. Vehicle unique identification
      6. Geographic/ region identifier
      7. Event ID
      8. Event’s source and destination
    • IDS should include reporting capabilities of monitoring results and security incidents
  • Monitoring
    • Security monitoring must detect at minimum, but not limited to the following scenarios:
      1. Safe operation of vehicle affected
      2. Vehicle functions stop working
      3. Software modified; performance altered
      4. Software altered but no operational effects
      5. Data integrity breach
      6. Data confidentiality breach
      7. Loss of data availability
      8. Other, including criminality
    • The IDS should monitor unauthorized manipulation, deletion or other amendments to vehicle held code/data via communication channels
    • The IDS should monitor acceptance of unreliable messages or session hijacking/replay attacks
    • The IDS should monitor gaining unauthorized access to files or data (sensitive files or folders)
    • The IDS should monitor Denial of service attacks via communication channels to disrupt vehicle functions
    • The IDS should monitor unprivileged users gaining unauthorized access to vehicle systems (or privilege escalation)
    • The IDS should monitor virus attacks and impact on vehicle systems (from a local source or from communication channels)
    • The IDS should monitor messages received by the vehicle (for example V2X or diagnostic messages), or transmitted within it, for malicious content
    • The IDS should monitor misuse, manipulation or compromise of update procedures, update software or packages (OTA or local), at minimum, but not limited to:
      1. Unsuccess update
      2. Unsigned image or container
      3. Signature check failure
    • The IDS should monitor manipulation of functions or unauthorized access to functions designed to remotely operate systems, such as, but not limited to:
      1. Remote keys
      2. Immobilizers
      3. Electric charging
      4. V2X 
      5. eCall
      6. Remote start
      7. TCU/OCU
      8. And others 
    • The IDS should monitor hosted 3rd party software to detect attacks against vehicles systems  (for example: software signature, behavior etc.)
    • The IDS should monitor devices connected to external interfaces e.g., USB ports, OBD port, used as a means to attack vehicle systems
    • The IDS should monitor unauthorized access to the owner’s private information such as personal identity, payment account details, address book information, location information, vehicle’s electronic ID, etc.
    • The IDS should monitor extraction of cryptographic keys
    • The IDS should monitor extraction of copyright or proprietary software from vehicle systems (product piracy / stolen software)
    • The IDS should monitor Illegal/unauthorized changes to vehicle’s electronic ID
    • The IDS should monitor Identity fraud. For example, if a user wants to display another identity when communicating with toll systems, manufacturer backend
    • The IDS should monitor action to circumvent monitoring systems (e.g., hacking/ tampering/ blocking of messages such as ODR Tracker data, or number of runs)
    • The IDS should monitor data manipulation to falsify vehicle’s driving data (e.g., mileage, driving speed, driving directions, etc.)
    • The IDS should monitor unauthorized changes to system diagnostic data
    • The IDS should monitor unauthorized deletion/manipulation of system event logs
    • The IDS should monitor the introduction of malicious software or malicious software activity
    • The IDS should monitor Disruption of systems or operations (Ethernet and CAN)-for example:  flooding a CAN bus, or provoking faults on an ECU via a high rate of messaging
    • The IDS should monitor unauthorized access aimed at falsifying the configuration parameters of vehicle’s key functions, such as brake data, airbag deployed threshold, etc.
    • The IDS should monitor unauthorized access aimed at falsifying the charging parameters, such as charging voltage, charging power, battery temperature, etc.
    • The IDS should monitor unauthorized access to open diagnostic ports: JTAGs, debug ports
    • The IDS should monitor violations or attempts to violate gateways rules, ACLs or network separations
    • The IDS should monitor unauthorized hardware, component replacement or unauthorized hardware connections to vehicle’s ECU
    • The IDS should monitor unauthorized access to critical files and information (non-confidential) – at minimum, but not limited to: 
      1. Overwrite of vehicle data.
      2. Creation, modification and deletion of vehicle data.
      3. Unauthorized writing of data/code to vehicle systems.
    • The IDS should monitor attempts of access confidential data or secure zones (TZ, HSM) 
    • The IDS should monitor authentication and integrity check of messages (success and failure)
    • The IDS should monitor message content and protocols
    • The IDS should monitor failures of storing cryptographic keys
    • The IDS should monitor (and prevent*) unauthorized access or gaining privileged access by unprivileged user. (*according to UNECE – Prevention not required specifically by IDS)
    • The IDS should monitor (and prevent*) embedded viruses/malware impact. (*according to UNECE – Prevention not required specifically by IDS)
    • Anomalies detection should be based on machine learning or statistical analysis of the data
    • The IDS should include systems to detect and respond to sensor spoofing
    • The IDS should include session management policies to avoid session hijacking
  • System 
    • The IDS system should protect sensors from manipulation or attack
      • Extraction of vehicle data/code
      • Manipulation of vehicle data/code
      • Erasure of data/code
      • Introduction of malware
      • Introduction of new software or overwrite existing software
      • Disruption of systems or operations
      • Manipulation of vehicle parameters
      • Software or hardware development permits vulnerabilities
    • The IDS system should authenticate the sensor, to avoid using manipulated or non-authorized sensor (by the attacker)
      • Manipulation of vehicle data/code
      • Manipulation of vehicle parameters
      • Parts or supplies that are compromised, permitting vehicles to be attacked
      • Software or hardware development permits vulnerabilities
      • Unintended transfer of data can occur
      • Physical manipulation of systems which can enable an attack
    • The IDS system should protect log files to avoid deletion or modification by the attacker (remove attack traces). Log files should be protected from creation point until received in the backend side. Protection should be, at minimum:
      • Signing or encryption
      • RBAC
      • Store in secured storage
      • Monitoring rules for accessing the log files
        • Extraction of vehicle data/code
        • Manipulation of vehicle data/code
        • Erasure of data/code
        • Introduction of malware
        • Introduction of new software or overwrite existing software
        • Disruption of systems or operations
        • Manipulation of vehicle parameters
        • Software or hardware development permits vulnerabilities
    • The IDS system should store log files in a secure storage (locally)
      • Information can be readily disclosed. For example, through eavesdropping on communications or through allowing unauthorized access to sensitive files or folders
      • An unprivileged user is able to gain privileged access to vehicle systems
      • Manipulation of vehicle parameters
      • Software or hardware development permits vulnerabilities
    • The IDS implementation should avoid the lack of logs storage capacity (by allocating the required storage capacity or maintaining log files size)
    • The IDS should monitor unauthorized access to its log files
      • Information can be readily disclosed. For example, through eavesdropping on communications or through allowing unauthorized access to sensitive files or folders
      • An unprivileged user is able to gain privileged access to vehicle systems
      • Manipulation of vehicle parameters
      • Parts or supplies could be compromised to permit vehicles to be attacked
    • The IDS should have active prevention capabilities for incident detections
    • IDS detection and prevention capabilities must not impact vehicle’s functionality
    • The IDS management system should be protected from unauthorized remote and local access
      • An unprivileged user is able to gain privileged access to vehicle systems
    • IDS logs must not include confidential or private information
      • Interception of information / interfering radiations / monitoring communications
      • Extraction of vehicle data/code
    • The IDS management environment should be separated from IDS core environment. Accessing each IDS environment should be based on different authentication methods, credentials and separation of permissions.
      • Security controls: Access controls
    • The IDS system must fail to a secure state if system initialization fails, shutdown fails, or aborts fail (to ensure that in the event of an operational failure, the system does not enter into an unsecure state where intended security properties no longer hold).

 

Conclusions

The Chinese Market

The Chinese market requires an IDS as a mandatory functionality, and this isn’t open to interpretation. This mandate applies both to Chinese OEMs and any foreign OEM that seeks to sell its vehicles in the Chinese market.  The trend in China is for minimal implementation that meets the standard. This is an excellent opportunity for companies offering an IDS to the market.

 

The UNECE market

The UN R155 is less specific, particularly regarding the IDS. This regulation applies both to the UNECE states and to any OEM seeking to sell its vehicles in the UNECE market. There are notable differences between the auditing methods employed by various auditors in the UNECE member states. There is no one golden standard in the field, a clear, uniform audit process has yet to emerge.

It seems that auditors are more concerned about verifying that the OEM follows its own procedures for the CSMS (Cyber Security Management System), by following the ISO/SAE 21434 standard for example, and that the process is coherent and complete. They tend to restrict the professional drill down and are refraining from verifying the actual controls and the methods of their implementations, at least for now. 

Therefore, they will not check the precise functionality of the IDS and how it will perform in case of the attack. Furthermore, the regulation itself does not prescribe which attack scenarios should be detected. It is very vague about the requirements and leaves the specification of the IDS functionality to the OEM. 

OEMs within the UNECE tend to have extremely different approaches to vehicle security in general, and specifically to the IDS. One can find a wide diversity of OEMs that employ different levels of strictness in their approach to vehicle protection. Some claim there is no need for an IDS at all since they take a secure-by-design approach and implement numerous security mechanisms along the way, such as network segregation. Others see the IDS as the one single independent, dedicated, and objective cybersecurity protection element in the vehicle. However, the defence in depth philosophy dictates that the IDS is one (last) component in a multi-layer vehicle protection architecture. 

It should be noted that an OEM that successfully passed the more rigorous Chinese audit is very likely to pass the UN R155 audit. 

More News

Show More