ALLPCB
01 Background
Intelligent connected vehicles are no longer isolated embedded systems, and information security has gained increasing attention. China and international bodies have issued multiple standards and regulations to govern automotive cybersecurity. Several of these regulations impose requirements on vehicle network security monitoring.
An intrusion detection system (IDS) monitors networks, systems, and their operational state according to defined security policies, attempting to detect attack attempts, attack behaviors, or attack consequences to protect confidentiality, integrity, and availability. When malicious software exists or the in-vehicle network is tampered with or injected, an automotive IDS can identify attacks by analyzing in-vehicle traffic or system state and generate security alerts.
In vehicles, IDS can be classified into two types based on the detection target: network intrusion detection systems and host intrusion detection systems.
Network IDS can monitor in-vehicle networks such as CAN bus, in-vehicle Ethernet, WiFi, and Bluetooth data. Many studies implement rule-based and AI-based methods. For example, some work proposes a hybrid multi-layer SOME/IP IDS where rule-based modules check SOME/IP headers, SOME/IP-SD messages, message intervals, and communication processes, while AI inspects SOME/IP payloads. Considering deployment cost, rule-based IDS are often implemented on vehicle controllers, using expert knowledge and in-vehicle network databases to build rule sets for detection.
Host-based IDS monitor the controller operating system. As vehicles become more connected and intelligent, controllers are no longer limited to MCUs; Linux, Android, and QNX increasingly appear in various domain controllers. While SoCs bring powerful features to vehicles, they also introduce attack vectors. Host-based IDS can monitor resources, files, and perform malware scanning on the operating system.
After detecting anomalous attack behavior in the vehicle, generating security logs and uploading them to a vehicle security operations center (VSOC) provides an effective means for attack tracing and monitoring the security status of connected vehicles.
02 AUTOSAR IDS Architecture
AUTOSAR (AUTomotive Open System Architecture) is an alliance that develops standards for automotive electronic software. AUTOSAR was established by global vehicle manufacturers, suppliers, semiconductor and software companies to create an open, standardized software architecture for the automotive industry. This architecture facilitates exchange and update of vehicle electronic software and provides a foundation for managing increasingly complex vehicle electronics and software systems.
The AUTOSAR architecture for automotive IDS is shown in Figure 1. The in-vehicle IDS mainly includes security probes, a management module (IdsM), security event storage (SEM), and a reporting module (IdsR).
(1) Security probes
Security probes detect potential network threats in network traffic and system events. When anomalies are detected, they send security events (SEv) to the management module. Common probes include CAN IDS, Ethernet IDS, and host IDS.
(2) Management module
When the management module receives SEv, it passes the events through a filter chain as shown in Figure 2: a blocking filter, a sampling filter, an aggregation filter, and a rate-limiting filter, producing Qualified Security Events (QSEv). The management module sends QSEv to the IDS reporting module and stores them in the Security Event Manager (SEM).
(3) Reporting module
IdsR sends QSEv to the VSOC. The security event message between IdsR and IdsM is shown in Figure 3. Its minimum length for an event frame is 8 bytes and includes protocol version, protocol header, IdsM instance ID, probe instance ID, event ID, event count, and reserved fields. The message also includes three optional fields: timestamp, context data, and signature.
03 IDS Testing Methods
Testing an IDS can be divided into two stages:
- Functional testing of the IDS software to verify that the software returns expected results for given inputs.
- Penetration testing to simulate common network attacks and verify the IDS detection capability.
Manual penetration testing is challenging: it requires significant cybersecurity expertise, and the process of generating attack data and evaluating test results is complex and time-consuming. To improve efficiency, penetration testing tools are used to build an automated IDS test environment, enabling automated functional testing of IDS. For network IDS penetration testing, the test flow is designed as follows:
- Generate attack packets.
- Send attack packets to the IDS under test and listen for QSEv.
- The IDS performs real-time detection; if an anomaly is detected, it sends QSEv to the test device.
- If the penetration testing tool receives the correct QSEv, the test passes; otherwise, it fails.
In this flow, generating attack packets is crucial. Some work summarizes packet generation tools and capabilities, as illustrated in Figure 5, but these tools typically lack automotive protocol support such as SOME/IP, UDS, and DoIP, and therefore cannot fully meet in-vehicle IDS testing needs.
BlitzFuzz is a penetration fuzzing tool specialized for industrial network protocols that supports emulation and parsing of messages for common automotive protocols such as CAN, UDS, SOME/IP, and DoIP. It provides penetration test case packages, compliance test case packages, and fuzzing capabilities, and allows users to create custom test cases to flexibly meet different penetration testing requirements. BlitzFuzz facilitates automated functional testing of IDS, as shown in Figure 6.
As shown in Figure 7, BlitzFuzz can be used to test an Ethernet IDS under test. The device under test is connected to BlitzFuzz via Ethernet. Test engineers write custom IDS test cases in the BlitzFuzz frontend, including invoking the tool's TCP port scan attack module to send port scan packets and implementing an Ethernet receive callback to verify whether the device under test sends QSEv. After selecting and running the test case, the test report can be viewed in the interface.
