Anomaly detection system

Abstract

Provided an anomaly detection system in an in-vehicle network, said anomaly detection system comprising: a flow information collection unit (103) that collects flow information, which is statistical information for each of the flows classified according to the header information of messages received at a prescribed observation part in an in-vehicle network; a flow-based anomaly detection unit (104) that detects an anomaly on the basis of the flow information and outputs a flow anomaly detection result obtained by the detection; a DPI unit (102) that monitors the messages on the basis of a DPI rule which indicates a processing content when a condition of a header value or a payload value included in a message matches a condition of a header value or a payload value of the message; and a DPI control unit (105) that, on the basis of the flow anomaly detection result, performs control of the DPI rule which is the generation, addition, deletion, change, activation, or inactivation.

Description

Anomaly Detection System

[0001] The present disclosure relates to a device and a method for detecting a communication abnormality in an in-vehicle network system.

[0002] In recent years, systems inside automobiles have been equipped with a large number of devices called electronic control units (ECUs). The network connecting these ECUs is called an in-vehicle network. There are many standards for in-vehicle networks, and one of the most mainstream standards for in-vehicle networks is the Control Area Network (hereinafter referred to as CAN).

[0003] However, in recent years, with the spread of autonomous driving and connected cars, an increase in in-vehicle network traffic is expected, and in-vehicle Ethernet, a communication standard that is faster than CAN, is becoming increasingly popular.

[0004] Specification of the IP Flow Information Export (IPFIX) Protocol for Exchange of Flow Information (RFC7011), September 2013, <https: / / www. rfc-editor. org / rfc / pdfrfc / rfc7011. txt. pdf>

[0005] Control frames that instruct the vehicle to run, stop, turn, etc. are sent and received over the in-vehicle network. Therefore, if a malicious attacker masquerades as a legitimate ECU and sends control frames, or if a DoS attack is carried out with the aim of preventing specific control frames from being received, this could put not only the driver of the vehicle but also pedestrians around the vehicle at risk.

[0006] Furthermore, in an increasingly widespread in-vehicle Ethernet environment, communication speeds are becoming higher, making it difficult for Deep Packet Inspection (DPI), which monitors payloads, to monitor each packet.

[0007] As a method for monitoring the entire network, there is a specification called IPFIX, which is described in Non-Patent Document 1. In IPFIX, multiple frames flowing over the Ethernet are classified by an Ethernet switch based on information contained in the Ethernet or TCP / IP header, and statistical information called flow information is generated. An anomaly detection device located above the Ethernet switch then monitors the flow information, making it possible to monitor the entire network with low computational load and low communication volume.

[0008] However, anomaly detection methods that utilize flow information do not monitor packet payload information, so there is a risk of false positives.

[0009] This disclosure solves the conventional problem by generating flow information by collecting statistical information from packet header information. An upper-level anomaly detection device then detects anomalies based on time-varying flow information, and enables payload-based monitoring rules for packets predicted to be anomalous based on the detection results. Payload monitoring is then performed on only some packets, enabling anomaly detection while reducing false positives and the amount of computation required for monitoring. This makes it possible to monitor anomalous communications on in-vehicle networks while securing the computational resources necessary for autonomous driving and advanced driving systems.

[0010] In order to solve the above problem, an anomaly detection system for an in-vehicle network consisting of one or more sub-networks is provided, the system comprising: a flow information collection unit that collects flow information, which is statistical information for each flow classified by header information of messages received at predetermined observation points in the in-vehicle network; a flow-based anomaly detection unit that performs anomaly detection based on the flow information and outputs the detected flow anomaly detection results; a DPI unit that monitors the messages based on one or more DPI (Deep Packet Inspection) rules that indicate the processing content when the conditions of the header value and payload value included in the message match the conditions of the header value and the payload value of the message; and a DPI control unit that controls one of generating, adding, deleting, changing, enabling, and disabling DPI rules based on the flow anomaly detection results.

[0011] According to the in-vehicle network anomaly detection system disclosed herein, the anomaly detection device based on flow information is responsible for monitoring the entire in-vehicle network, and the DPI monitors abnormal communications detected based on the flow information, thereby reducing the load on the entire network and suppressing false detections by the anomaly detection system. As a result, even in an in-vehicle Ethernet environment where high-speed communications occur, it is possible to monitor the network while suppressing processing slowdowns, and it is possible to provide safe autonomous driving and advanced driving assistance services.

[0012] FIG. 1 is a diagram illustrating an overall configuration of an in-vehicle network system according to the first embodiment. FIG. 2 is a block diagram of a Zone ECU 100a according to the first embodiment. FIG. 3 is a block diagram of a steering wheel ECU 200a according to the first embodiment. FIG. 4 is a diagram illustrating a message format of a SOME / IP SD according to the first embodiment. FIG. 5 is a diagram illustrating an example of a SOME / IP SD message according to the first embodiment. FIG. 6 is a diagram illustrating a message format of a SOME / IP according to the first embodiment. FIG. 7 is a diagram illustrating an example of a SOME / IP message according to the first embodiment. FIG. 8 is a diagram illustrating an example of flow information collected by a Zone ECU 100b according to the first embodiment. FIG. 9 is a diagram illustrating an example of an all-DPI rule storage unit according to the first embodiment. FIG. 10 is a diagram illustrating an example of an ECU management list according to the first embodiment. FIG. 11 is a diagram illustrating a sequence from flow information collection to anomaly detection and security response according to the first embodiment. FIG. 12 is a diagram illustrating a flowchart of the overall process of generating DPI rules for a Zone ECU according to the first embodiment. FIG. 13 is a flowchart of reception processing by the communication unit in the first embodiment. FIG. 14 is a flowchart showing an example of processing by the flow-based anomaly detection unit in the first embodiment. FIG. 15 is a diagram showing an example of an anomaly alert in the first embodiment. FIG. 16 is a flowchart of DPI rule generation in the first embodiment. FIG. 17 is a flowchart of DPI rule transfer in the first embodiment. FIG. 18 is a diagram showing an example of a DPI rule generated from an anomaly alert in the first embodiment. FIG. 19 is a diagram showing a flowchart of DPI rule processing in the first embodiment. FIG. 20 is a diagram showing an example of a DPI alert in the first embodiment. FIG. 21 is a flowchart of DPI alert processing in the Zone ECU in the first embodiment. FIG. 22 is a diagram showing an example of a DPI rule for blocking an abnormal communication in the first embodiment. FIG. 23 is an overall configuration diagram of an in-vehicle network system in the second embodiment. FIG. 24 is an overall configuration diagram of the Zone ECU 1100a in the second embodiment.FIG. 25 is a diagram showing a sequence from flow information collection to anomaly detection and security response in the second embodiment. FIG. 26 is a flowchart of DPI rule generation in the second embodiment. FIG. 27 is a flowchart of processing by a DPI rule transfer unit in the second embodiment. FIG. 28 is a diagram showing an example of flow information requested to determine a DPI rule application destination in the second embodiment. FIG. 29 is a diagram showing an example of a DPI rule generated from an anomaly alert in the second embodiment. FIG. 30 is a diagram showing an overall configuration of an in-vehicle network in the third embodiment. FIG. 31 is a diagram showing a configuration of a Zone ECU 2100a in the third embodiment. FIG. 32 is a diagram showing an example of a DPI rule list for safety monitoring in the third embodiment. FIG. 33 is a diagram showing a sequence from flow information collection to application of a DPI rule for safety monitoring in the third embodiment. FIG. 34 is a flowchart of packet processing by the Zone ECU in the third embodiment. FIG. 35 is a flowchart of processing by a safety determination unit in the third embodiment. FIG. 36 is a flowchart of processing by a DPI rule generation unit based on safety determination in the third embodiment. FIG. 37 is a diagram showing an example of a safety monitoring DPI rule in the third embodiment.

[0013] In order to solve the above problem, an anomaly detection system according to one aspect of the present disclosure is an anomaly detection system for an in-vehicle network consisting of one or more sub-networks, and includes: a flow information collection unit that collects flow information, which is statistical information for each flow classified by header information of messages received at predetermined observation points in the in-vehicle network; a flow-based anomaly detection unit that performs anomaly detection based on the flow information and outputs the detected flow anomaly detection results; a DPI unit that monitors the messages based on one or more DPI (Deep Packet Inspection) rules that indicate the processing to be performed when the conditions of a header value or payload value included in the message match the conditions of the header value or the payload value of the message; and a DPI control unit that controls one of generating, adding, deleting, changing, enabling, and disabling DPI rules based on the flow anomaly detection results.

[0014] This allows the flow-based anomaly detection unit to monitor the entire network with reduced processing load without having to monitor the payload information of communication packets one by one, and erroneous detection can be suppressed by re-monitoring anomalous communication detected by the flow-based anomaly detection unit in the DPI unit, which is a packet-based anomaly detection unit, before officially determining it as an anomaly.Furthermore, by performing anomaly detection in two stages, by the flow-based anomaly detection unit and the DPI unit, it becomes possible to set anomaly detection rules in the flow-based anomaly detection unit, which performs anomaly detection first, that allow for erroneous detection but reduce the number of overlooked anomalous communications.

[0015] In addition, the anomaly detection system has a hierarchical structure in which the one or more sub-networks include an upper network and a lower network, one upper ECU is arranged in the upper network, one or more lower ECUs are arranged in the lower network, the one upper ECU is equipped with the DPI control unit, and each of the one or more lower ECUs is equipped with the DPI unit.

[0016] This allows only the upper ECU to perform flow-based anomaly detection, and the DPI rules generated using the results are enabled only in the DPI sections of the necessary ECUs, thereby reducing the number of packets monitored by each ECU and the processing load per ECU.Furthermore, by having the lower ECU monitor the network in accordance with the upper ECU, the monitoring rules can be simplified and the computational resources allocated to network monitoring can be reduced.

[0017] In addition, the flow information includes information regarding the amount of messages received for each flow, and the DPI control unit determines a processing priority indicating the order of processing for monitoring the messages for each of the one or more DPI rules based on the information, generates the one or more DPI rules, and the DPI unit monitors the messages using the one or more DPI rules in order of the processing priority.

[0018] This reduces the number of times the DPI unit checks the DPI rules against the header information of messages, thereby reducing the calculation resources consumed by the DPI unit for message monitoring.

[0019] In addition, the DPI control unit determines the time for which monitoring in accordance with the DPI rules is enabled in the DPI unit, or the upper limit number of messages for which monitoring in accordance with the DPI rules is performed in the DPI unit, depending on the content of the abnormality detected by the flow-based abnormality detection unit and the number of messages per unit time monitored by the DPI unit.

[0020] This prevents the number of DPI rules held by the DPI unit from increasing monotonically over time, thereby reducing the processing load on the DPI unit. For example, by specifying the number of packets to be monitored for each DPI rule, when the number of monitored packets reaches the specified value, the DPI rule is discarded.

[0021] In addition, one of the one or more DPI rules identifies service information or client information contained in messages sent and received between the one or more lower-level ECUs, the DPI control unit enables the one DPI rule, and if the service information or client information of the message being monitored does not match the one DPI rule, the DPI unit determines the message to be an unauthorized communication and drops it.

[0022] This allows the DPI unit to determine whether a packet is abnormal and drop the packet on its own.

[0023] In addition, the DPI unit outputs the monitoring results of monitoring the messages, and the DPI control unit adds, changes, enables, or disables the DPI rules for the DPI unit based on the output monitoring results.

[0024] This makes it possible to apply DPI rules that reflect not only the results of the flow-based anomaly detection unit but also the results of monitoring by the DPI unit to each DPI unit. For example, if a DPI rule that monitors identifier information such as service information or client information included in a message payload is enabled and the DPI unit detects identifier information that is different from normal, a DPI rule that drops messages with abnormal identifier information based on the detection result can be generated and enabled, and security rules based on the results of monitoring by the DPI unit can be applied.

[0025] The DPI control unit adds, changes, enables, or disables the DPI rules in response to one or more of the vehicle status, including at least one of a shift lever status, autonomous driving, autonomous parking, cruise control, software update, vehicle diagnosis, and internet connection, and the flow anomaly detection result of the flow-based anomaly detection unit. This allows messages with a high attack risk to be determined based on the current vehicle driving status, and DPI rules that monitor or protect such communications can be added or enabled. Furthermore, if the number of enabled DPI rules in the DPI unit exceeds its message processing capacity, older DPI rules can be temporarily disabled, allowing DPI rules with a higher level of urgency to be enabled first.

[0026] In addition, when the flow-based anomaly detection unit detects an anomaly, the DPI control unit checks the vehicle state according to one of the one or more lower-level ECUs that is the sender or destination of the message determined to be abnormal, and if the vehicle state is a predetermined state, the DPI control unit determines the conditions of the header value and payload value included in the message included in the DPI rule according to the vehicle state and the processing content when the conditions are met.

[0027] This prevents malicious attackers from seizing control of the vehicle when an anomaly is detected in flow-based anomaly detection. For example, if an anomaly is detected in the flow information of communication with the ADAS ECU that manages the autonomous driving system, the system can instruct the ADAS ECU to immediately stop the vehicle while ensuring its safety if the vehicle is in autonomous driving mode. By enabling a DPI rule that prohibits unauthorized communication with the ECU required to stop the vehicle in an emergency, attacks on the ECUs involved in stopping the vehicle can be prevented until the vehicle is stopped.

[0028] Further, the upper network includes one or more upper networks, and the one upper ECU is equipped with the DPI unit, and the DPI control unit selects, from the one or more lower ECUs, an ECU that is the source and an ECU that are the destination of messages monitored by the DPI rule, and further selects at least one of the one upper ECUs through which messages between the source ECU and the destination ECU pass, and applies the DPI rule to the ECU among the selected ECUs that has a small processing load for message processing.

[0029] This makes it possible to prevent the number of DPI rules that are enabled for one ECU from exceeding the message processing capacity, which leads to prevention of processing slowdowns in each ECU.

[0030] The DPI control unit further includes a communication volume calculation unit that calculates the communication volume of the selected ECU based on the flow information, a DPI rule recording unit that records the DPI rules that are enabled in the one or more lower-level ECUs, and a processing load calculation unit that calculates the processing load required for message processing from the communication volume of the selected ECU and the DPI rules that it holds, and determines the application destination of the DPI rule based on the calculated processing load.

[0031] This allows the DPI rules to be distributed among a plurality of ECUs and enabled, thereby preventing processing slowdowns caused by the DPI rules being concentrated in one ECU.

[0032] Furthermore, if the abnormality detected by the flow-based abnormality detection unit is an abnormality that places a load on the in-vehicle network, the DPI control unit applies the DPI rule to the DPI unit of the one upper ECU that is closer to the ECU that sent the message monitored by the DPI rule.

[0033] This makes it possible to reduce the load on the network by having a host ECU that is close to the ECU that sends the abnormal message monitor the message.For example, when a flooding attack is detected by the flow-based anomaly detection unit, the DPI unit of a host ECU that is closer to the source ECU can monitor the payload, and if an abnormality is confirmed, the host ECU can activate a DPI rule that immediately drops the abnormal message, thereby preventing communications that put strain on the network from flowing outside the network between the source ECU and the host ECU.

[0034] An anomaly detection device according to an embodiment will be described below with reference to the drawings. Each embodiment shown here represents a specific example of the present disclosure. Therefore, the numerical values, components, component arrangement and connection configuration, and processing steps and step order shown in the following embodiments are merely examples and do not limit the present disclosure. Of the components in the following embodiments, components not recited in independent claims are optional components that can be added. Furthermore, each figure is a schematic diagram and is not necessarily an exact illustration.

[0035] First Embodiment Hereinafter, an abnormality detection device (an abnormality detection system) in a vehicle equipped with an in-vehicle network (an in-vehicle network system) in which a plurality of ECUs communicate via Ethernet will be described.

[0036] [Overall Configuration of In-Vehicle Network System] FIG. 1 is a diagram showing the overall configuration of an in-vehicle network system 10 according to the first embodiment.

[0037] 1, an in-vehicle network system 10 is mounted on a vehicle. The in-vehicle network system 10 includes Zone ECUs 100a, 100b, and 100c, an ADAS ECU 200a, an IVI ECU 200b, a steering control ECU 200c, a brake control ECU 200d, a shift lever ECU 200e, a camera ECU 200f, and a LiDAR ECU 200g. Although not shown in FIG. 1, the in-vehicle network system 10 may include many more ECUs.

[0038] The Zone ECU 100a, the ADAS ECU 200a, and the IVI ECU 200b are connected via Ethernet 1, which is a type of in-vehicle network. The Zone ECU 100a, the Zone ECU 100b, and the Zone ECU 100c are connected via Ethernet 2. The Zone ECU 100b, the steering wheel control ECU 200c, the brake control ECU 200d, and the shift lever ECU 200e are connected via Ethernet 3. The Zone ECU 100c, the camera ECU 200f, and the LiDAR ECU 200g are connected via Ethernet 4.

[0039] The Zone ECUs are connected to each other via Ethernet and communicate using SOME / IP, a communication protocol for in-vehicle Ethernet. A network (Ethernet 1, 3, 4) that is not connected to other Zone ECUs is called a zone, and each Zone ECU acquires information from and controls the ECUs connected to its respective zone.

[0040] 2 is a diagram showing the configuration of the Zone ECU 100a. Note that the Zone ECUs 100b and 100c have the same configuration, so a description thereof will be omitted.

[0041] 2, the Zone ECU 100a includes a communication port unit 101, a DPI unit 102, a flow information collection unit 103, a flow-based anomaly detection unit 104, a DPI control unit 105, a total DPI rule storage unit 106, and an ECU management list storage unit 107.

[0042] The communication port unit 101 is an Ethernet communication interface, which transmits and receives frames, and determines which function of the Zone ECU should process the received communication frame depending on the type of frame.

[0043] The DPI unit 102 monitors the payload information of packets based on a monitoring rule specified by the DPI rule. In addition, when communication between two or more ECUs, including broadcast communication, is performed via a Zone ECU, the DPI unit 102 can apply a DPI rule that performs processing such as dropping abnormal communication or recording a communication log.

[0044] The flow information collection unit 103 classifies packets received via Ethernet 1 and 2 based on header information, and generates flow information by tallying statistical information for each classified packet.

[0045] The flow-based anomaly detection unit 104 detects anomalies based on the flow information stored in the flow information collection unit 103, and outputs the detection result as an anomaly alert. The anomaly alert includes not only the detection result but also information necessary for the DPI control unit 105 to generate a DPI rule.

[0046] The DPI control unit 105 controls the DPI rules that are enabled in the DPI unit, and is composed of a DPI rule generation unit 105A, a DPI rule transfer unit 105B, and a DPI alert processing unit 105C.

[0047] The DPI rule generation unit 105A generates DPI rules based on alerts (hereinafter referred to as "abnormality alerts") output by the flow-based anomaly detection unit 104 or alerts (hereinafter referred to as "DPI alerts") output by the DPI units of each ECU. The DPI rules generated from abnormality alerts are primarily intended to monitor the contents of detected anomalies down to the packet payload. The DPI rules generated from DPI alerts are also intended to protect the network from abnormal communications, such as by blocking abnormal packets.

[0048] The DPI rule transfer unit 105B determines the ECU to which the DPI rule generated by the DPI rule generation unit 105A applies, and transfers the DPI rule.

[0049] The DPI alert processing unit 105C processes an alert output when the DPI unit of an ECU in a zone detects a packet that fails the check content of a DPI rule, and determines whether or not an additional DPI rule needs to be generated.

[0050] The all-DPI rule storage unit 106 stores the DPI rules held by the DPI units of all ECUs present in the in-vehicle network system 10 .

[0051] The ECU management list storage unit 107 stores a list of ECUs present on the in-vehicle network system 10, service information handled by each ECU, and Zone ECUs that manage the zones to which each ECU belongs.

[0052] 3 is a block diagram of the ADAS ECU 200a. The IVI ECU 200b, the steering control ECU 200c, the brake control ECU 200d, the shift lever ECU 200e, the camera ECU 200f, and the LiDAR ECU 200g also have the same configuration, so descriptions of these will be omitted.

[0053] In FIG. 3, the ADAS ECU 200 a includes a communication port unit 201 , a DPI unit 202 , and an application unit 203 .

[0054] The communication port unit 201 is an Ethernet communication interface, and transmits and receives frames.

[0055] The DPI unit 202 monitors packet payload information based on monitoring rules specified by the DPI rules distributed from the Zone ECU, and if a received packet matches the check contents of the DPI rules, it sends an alert to the Zone ECU that distributed the DPI rules as necessary. Since the DPI unit 202 has the same functions as the DPI unit 102 of the Zone ECU 100a, if it determines that a packet is abnormal, it can apply a DPI rule that performs processing such as dropping the abnormal communication or recording a communication log.

[0056] The application unit 203 executes an application specific to the ECU in accordance with the received communication frame.

[0057] [SOME / IP Message Format] SOME / IP is a type of service-oriented communication that achieves service-oriented communication by combining four communication methods: Request / Response, Fire / Forget, Events, and Get / Set / Notifier. SOME / IP also includes Service Discovery (SD) as a method for establishing a session with a communication partner.

[0058] FIG. 4 shows an example of a message format used in a SOME / IP SD. The message format in FIG. 4 is stored in the Ethernet payload section and communicated. Each line in the diagram is 32 bits, with the SOME / IP header stored in the first half and the SOME / IP SD payload stored in the second half. In a SOME / IP SD, the Message ID is 0xFFFF8100. The Length field stores the number of bytes of data following the Length field. The Request ID stores the combined value of the Client ID and Session ID. In a SOME / IP SD, the Protocol Version is set to 0x01, the Interface Version is set to 0x01, the Message Type is set to 0x02, and the Return Code is set to 0x00.

[0059] FIG. 5 is a diagram showing an example of a SOME / IP SD message.

[0060] Flags is set to 0x80, which means the Reboot Flag is set. The Reserved area is set to 0.

[0061] The Length of Entries Array Bytes stores the number of bytes of an Entry, which is set to 16 bytes in FIG.

[0062] The Type can be set to 0x00 or 0x01, where 0x00 means "Find" and 0x01 means "Offer." "Find" is used when a client ECU receiving a service requests the provision of a required service, and "Offer" is used when a server ECU providing a service notifies that it can provide the service. In Figure 5, the Type is set to 0x01, indicating that the message is a notification from the server ECU of information about the services it can provide.

[0063] The index 1st options indicates the position of the first option. In FIG. 5, it is 0, which indicates the beginning of the option area.

[0064] The index 2nd options indicates the position of the second option, which is 0 in FIG.

[0065] The number of option 1s is written in #of opt1, and in FIG. 5, 1 is stored.

[0066] The number of option 2 is written in #of opt2, and in FIG. 5, 0 is stored, indicating that option 2 is not used.

[0067] The Service ID is a field that stores an ID indicating the type of service, and in FIG. 5, 0x1000 is stored.

[0068] The Instance ID is a field that stores an ID that indicates an instance of a service, and is set to 0x0001 in FIG.

[0069] The Major Version is information used for managing the version of the service, and in FIG. 5, 0x01 is stored.

[0070] TTL is a field that sets the expiration date (seconds) of the service, and is set to 0xFFFF in Fig. 5. A TTL of 0xFFFF means that the service will be valid until the next startup timing of the ECU.

[0071] The Minor Version is information used for managing the version of the service, and is set to 0x00000002 in FIG.

[0072] In the Option area, the byte length of the Option area is stored in Length of Options Array in Bytes, which is shown to be 12 bytes in FIG.

[0073] The value set for Length is determined depending on the type of option. In Fig. 5, an example of communication using IPv4 is shown, and Length is set to 9, Type is set to 0x04, and Reserved is set to 0x00.

[0074] The IPv4 address is the IP address of the server, and in FIG. 5, 192.168.0.1 is set.

[0075] The Reserved area stores 0. The L4-Proto field stores 0x11, indicating that User Datagram Protocol (UDP) is used.

[0076] Finally, the port number is stored, and in FIG. 5, port 35000 is used.

[0077] 6 is a diagram showing an example of a message format used in SOME / IP. The SOME / IP header portion excluding the payload is the same as that shown in FIG.

[0078] FIG. 7 is a diagram showing an example of a SOME / IP message.

[0079] Service ID is a field that stores an ID that indicates the type of service, and in FIG. 7, 0x0001 is stored.

[0080] The Method ID is a field that stores an ID that indicates the type of Method, which is a function on the server that is called from the client, and in FIG. 7, 0x0301 is stored.

[0081] The Length field stores the message length from the Client ID to the Payload. In FIG. 7, this field is set to 1408 bytes.

[0082] The Client ID is an identifier for identifying the calling client in the ECU, and is set to 0x01000 in FIG.

[0083] The Session ID is an identifier for distinguishing messages sent from the same sender, and is set to 0x0011 in FIG.

[0084] Protocol Version indicates the protocol version of SOME / IP, and is set to 0x01 in FIG.

[0085] The Interface Version indicates the major version of the service I / F, and is set to 0x02 in FIG.

[0086] Message Type indicates the message type of SOME / IP. In Fig. 7, 0x02 is set, which indicates that the message type is Notification.

[0087] The Return Code represents a return value indicating whether the request has been processed normally, and is set to 0x00 in FIG.

[0088] Payload describes the information that the sender wants to send.

[0089] [Example of Flow Information Collected by Zone ECU] Figure 8 is a diagram showing an example of flow information collected by the flow information collection unit 103 of the Zone ECU. The flow information is statistical information calculated at regular intervals from packet header information, etc. In Figure 8, the flow information is calculated at 30-second intervals. The flow information is assigned to a flow ID, which is identification information, which is a combination of the packet's source IP address (Src IP), source port number (Src Port), destination IP address (Dst IP), destination port number (Dst Port), and protocol number (Protocol), and statistical information is compiled for each flow ID. In Figure 8, the number of packets communicated for each flow ID, the average arrival interval of packets, and the average packet length are compiled.

[0090] [Example of a list of all DPI rules] Figure 9 is a diagram showing an example of a list (hereinafter referred to as the all DPI rule list) that lists all DPI rules applied to ECUs on the in-vehicle network and is stored in the all DPI rule storage unit 106.

[0091] A DPI rule includes the ECU to which it applies, a rule number, a DPI rule name, an issuing ECU, a header condition, check details, an operation to be performed when checking, the number of packets to be monitored, the number of packets already monitored, and a processing priority.

[0092] The application ECU is set to an ECU that actually executes the generated DPI rule in the DPI section. In the list of all DPI rules in Fig. 9, the DPI rules are listed based on the application ECU.

[0093] A rule number is assigned to each DPI rule for the purpose of DPI rule management.

[0094] The DPI rule name is determined according to the role of the DPI rule. For example, if a DPI rule is generated based on an anomaly alert, the DPI rule name is determined based on the detected anomaly, such as flooding monitoring, spoofing monitoring, or man-in-the-middle attack monitoring. Furthermore, a DPI rule generated based on a DPI alert is given the DPI rule name "Abnormal Communication."

[0095] The issuing ECU generates a DPI rule and transfers it to the destination ECU, which is designated as a Zone ECU. The issuing ECU is determined according to the ECU management list.

[0096] The header conditions indicate all or part of the source IP address, source port number, destination IP address, destination port number, and protocol number of the packet to be monitored. For packets that match all of the items listed in this header condition, the payload is monitored and the check contents are confirmed.

[0097] The check contents indicate the contents to be checked when monitoring the payload of packets that satisfy the header conditions. For example, for SOME / IP communications that may be the result of a flooding attack, it is assumed that the attacking ECU is sending a large number of packets using a single Service ID, and the source ECU of the abnormal packets is determined to be the attacking ECU, and it is confirmed that the packets sent from the source ECU have only one type of Service ID. In addition, for SOME / IP communications that may be the result of a spoofing attack, it is confirmed that the communication is being carried out using the correct Client ID.

[0098] The check operation indicates the operation when the monitored packet satisfies the check contents. For example, if a packet is caught by the check contents of the flooding monitor in Figure 9, it is determined that the ECU sending the monitored communication is not an ECU that communicates with only one type of Service ID, that is, a normal ECU, and a notification is sent to the Zone ECU that issued the DPI rule. Also, if the packet is caught by the check contents of the spoofing monitor in Figure 9, it is determined that the communication is being made using a false IP address and port number, the packet is blocked, and the number of monitored packets is set to unlimited.

[0099] The number of monitored packets indicates the upper limit of the number of packets to be monitored by that DPI rule, and the number of monitored packets indicates the number of packets already monitored by the DPI unit using that DPI rule. When the number of monitored packets for a DPI rule reaches a specified number of monitored packets, the DPI units 102 and 202 discard that DPI rule. The Zone ECU can also determine the number of packets communicated by each ECU for each flow ID from the flow information, and calculates the number of monitored packets for all DPI rules in the all-DPI rule storage unit 106.

[0100] The processing priority is a parameter that determines the order in which packet headers are compared with the header conditions of DPI rules when two or more DPI rules are applied to the DPI units 102 and 202. The processing priority is calculated based on flow information and is determined by the proportion of packets monitored by that DPI rule among all packets communicated by the ECU. The DPI units 102 and 202 compare the headers of received packets with the header conditions of DPI rules in descending order of processing priority. The DPI units 102 and 202 of each ECU store the DPI rules in descending order of processing priority.

[0101] [ECU Management List] Figure 10 shows the ECU management list stored in the ECU management list storage unit 107 of each Zone ECU. The ECU management list lists all ECUs present on the in-vehicle network, and each ECU is assigned a Zone ECU present in the same zone as the manager. A Zone ECU transfers a DPI rule generated by its DPI rule generation unit 105A to an ECU it manages only if the destination of the DPI rule is an ECU under its own management.

[0102] The ECU management list also lists the IP addresses and port numbers used by each ECU. For each port number, the protocol and service details used are also listed. If the protocol is SOME / IP, the client ID and service ID are also listed.

[0103] By checking this ECU management list, the Zone ECU can check the service information of the SOME / IP communication, such as the service ID and client ID, from the IP address and port number of the flow information, without checking the payload information.

[0104] [Processing Sequence] FIG. 11 is a diagram showing a processing sequence in which, when an attack from steering wheel control ECU 200c to ADAS ECU 200a occurs in the first embodiment, Zone ECUs 100b, 100c collect flow information using flow information collection unit 103, perform abnormality detection using flow-based anomaly detection unit 104, generate DPI rules using DPI rule generation unit 105A based on the results, apply the generated DPI rules to DPI units 102, 202 of ADAS ECU 200a, and take security measures based on the monitoring results of DPI unit 202.

[0105] The steering wheel control ECU 200c performs a flooding attack on the ADAS ECU 200a (S101).

[0106] The Zone ECUs 100a and 200c present on the communication path between the steering wheel control ECU 200c and the ADAS ECU 200a mirror the packets, receive the packets, and collect flow information (S102).

[0107] The collected flow information is shared among the Zone ECUs 100a, 100b, and 100c (S103).

[0108] The Zone ECUs 100a, 100b, and 100c each perform flow-based anomaly detection based on the shared flow information, and detect that the steering wheel control ECU 200c is attacking the ADAS ECU 200a (S104).

[0109] The Zone ECUs 100a, 100b, and 100c generate DPI rules based on the results of the flow-based anomaly detection (S105).

[0110] Since the Zone ECU 100b does not find, in the ECU management list, that the generated DPI rule is to be applied to an ECU that is not under its own management, the Zone ECU 100b stores the DPI rule in the all DPI rule storage unit 106 (S106).

[0111] Since the Zone ECU 100a determines from the ECU management list that the generated DPI rule is to be applied to its own management target, the Zone ECU 100a stores the DPI rule in the all DPI rule storage unit 106 and transfers it to the ADAS ECU 200a (S107).

[0112] The ADAS ECU 200a receives the DPI rules from the Zone ECU 100a and applies them to the DPI unit 202 (S108).

[0113] The steering wheel control ECU 200c continues to perform a flooding attack on the ADAS ECU 200a (S109).

[0114] The ADAS ECU 200a monitors communication with the steering wheel control ECU 200c according to the applied DPI rule (S110).

[0115] The ADAS ECU 200a generates a DPI alert based on the monitoring result of the DPI unit 202 and transmits it to the Zone ECU 100a (S111).

[0116] The Zone ECU 100a officially determines that the communication with the steering wheel control ECU 200c is abnormal based on the DPI alert from the ADAS ECU 200a (S112).

[0117] The Zone ECU 100a generates a DPI rule for blocking abnormal communication from the steering wheel control ECU 200c, and transfers the rule between the ADAS ECU 200a and the other Zone ECUs 100b and 100c (S113).

[0118] The Zone ECU 100b stores the DPI rule newly created in the Zone ECU 100a in the all DPI rule storage unit 106 (S114).

[0119] The ADAS ECU 200a transfers the new DPI rule transferred from the Zone ECU 100a (S115).

[0120] The steering wheel control ECU 200c continues to perform a flooding attack on the ADAS ECU 200a (S116).

[0121] In the ADAS ECU 200a, the abnormal communication from the steering wheel control ECU 200c is blocked in accordance with the DPI rule (S117).

[0122] [Flowchart of Processing in Zone ECU] FIG. 12 is a flowchart of the entire processing from when the Zone ECU receives a packet to when it generates a DPI rule and applies it to an appropriate ECU.

[0123] The communication port unit 101 receives a packet communicated via itself (S201).

[0124] The packets are mirrored in the communication port unit 101 and transferred according to the destination IP address of the packets (S202).

[0125] The flow information collection unit 103 extracts header information from the mirrored packets and updates the flow information (S203).

[0126] The flow information collection unit 103 checks whether the specified time for collecting flow information has not been exceeded (S204). If the specified time has been exceeded (Yes in S204), the flow information collection unit 103 outputs the flow information (S205). If the specified time has not been exceeded (No in S204), the process returns to the first step S201.

[0127] The output flow information is transferred to other Zone ECUs via the communication port unit 101 (S206), and the communication port unit 101 receives the flow information transferred from other Zone ECUs (S207).The flow information collection unit 103 then combines the flow information it has output with the flow information transferred from other Zone ECUs (S208).

[0128] The flow-based anomaly detection unit 104 performs flow-based anomaly detection based on the combined flow information (S209) and determines whether an anomaly exists (S210). If an anomaly exists (YES in S210), the flow-based anomaly detection unit 104 generates an anomaly alert that describes the anomaly (S211). If no anomaly exists (NO in S211), the Zone ECU ends the process.

[0129] The DPI rule generating unit 105A generates a DPI rule from the generated abnormality alert (S212).

[0130] The DPI rule generating unit 105A stores the generated DPI rule in the all DPI rule storage unit 106 (S213).

[0131] The DPI rule transfer unit 105B checks whether the ECU to which the DPI rule created from the ECU management list is applied is its own management ECU (S214). If it is its own management ECU (Yes in S214), the DPI rule transfer unit 105B transfers the DPI rule to the application ECU (S215), and the Zone ECU ends the process. If it is not its own management ECU (No in S214), the Zone ECU ends the process.

[0132] 13 is a flowchart of reception processing by the communication port unit 101 of the Zone ECU. The communication port unit 101 transfers packet information to an appropriate function within the Zone ECU depending on the type of packet received.

[0133] The communication port unit 101 checks whether the packet being processed is a transmission packet whose source is itself (S301). If it is a transmission packet (Yes in S301), the communication port unit 101 transmits the packet to the ECU with the destination IP address (S302).

[0134] If the received packet is not a transmission packet (No in S301), the communication port unit 101 mirrors the received packet and transfers the mirrored packet to the flow information collection unit 103 (S303).

[0135] The communication port unit 101 checks whether the received packet is addressed to itself (S304). If the packet is addressed to itself (Yes in S304), the communication port unit 101 checks whether the packet is a DPI rule transferred from another Zone ECU (S305). If the packet is a DPI rule (Yes in S303), the communication port unit 101 stores the transferred DPI rule in the all-DPI rule storage unit 106 (S306), and the Zone ECU ends the processing.

[0136] If the packet does not comply with the DPI rule (if S305 is No), the communication port unit 101 checks whether the packet is a DPI alert transferred from another ECU (S307). If the packet is a DPI alert (if S307 is Yes), the communication port unit 101 transfers the packet information to the DPI alert processing unit 105C (S308), and the Zone ECU ends the processing.

[0137] If the packet is not a DPI alert (if S305 is No), the received packet is flow information shared by another Zone ECU, so the communication port unit 101 not only updates the flow information from the header information of the transferred packet, but also notifies the Zone ECU to integrate the collected flow information with the flow information of other zones described in the payload information of the packet (S309), and the Zone ECU then ends the processing.

[0138] If the packet is not addressed to the Zone ECU itself (No in S304), the communication port unit 101 transfers the packet to the ECU with the destination IP address (S310), and the Zone ECU ends the process.

[0139] [Example of Implementation of Flow-Based Anomaly Detection] FIG. 14 is a flowchart showing an example of processing by the flow-based anomaly detection unit 104.

[0140] The flow-based anomaly detection unit 104 receives flow information that is output at regular intervals (S401).

[0141] The flow-based anomaly detection unit 104 extracts statistical information for one flow ID from the received flow information (S402).

[0142] The flow-based anomaly detection unit 104 calculates a previous ratio ΔI, which is the ratio of the average arrival interval I of one flow ID to the average arrival interval in the flow information output immediately before (S403).

[0143] The flow-based anomaly detection unit 104 also calculates a change ΔN from the previous time for the number of packets N (S404).

[0144] The flow-based anomaly detection unit 104 checks whether the number of packets N is 10,000 or more (S405). If the number of packets N is 10,000 or more (Yes in S405), the flow-based anomaly detection unit 104 determines that the communication having the extracted flow ID is undergoing a "flooding attack" (S406).

[0145] If the number of packets N is less than 10,000 (if S405 is No), the flow-based anomaly detection unit 104 checks whether the average arrival interval change from the previous time ΔI is less than 1 (S407). If the average arrival interval change from the previous time ΔI is less than 1 (if S407 is Yes), the flow-based anomaly detection unit 104 further checks whether the number of packets change from the previous time ΔN is 10 or more (S408). If the number of packets change from the previous time ΔN is 10 or more (if S408 is Yes), the flow-based anomaly detection unit 104 determines that the communication having the extracted flow ID is undergoing a "flooding attack" (S406).

[0146] If the packet count change ΔN relative to the previous count is less than 10 (if S408 is No), the flow-based anomaly detection unit 104 checks whether the packet count change ΔN relative to the previous count is 2 or greater (S409). If the packet count change ΔN relative to the previous count is 2 or greater (if S409 is Yes), the flow-based anomaly detection unit 104 determines that the communication having the extracted flow ID is the subject of a "spoofing attack" (S410).

[0147] If the difference ΔI between the average arrival interval and the previous time is 1 or more, or the difference ΔN between the number of packets and the previous time is less than 2 (if S407 is No or if S409 is No), the flow-based anomaly detection unit 104 extracts communications using the same destination IP address and destination port number in other flow IDs (S411) and checks whether a change in communication order has occurred, such as an increase in one value of the number of packets N and a decrease in the other value (S412). If a change in communication order has occurred (if S412 is Yes), the flow-based anomaly detection unit 104 further checks whether the difference ΔN between the number of packets and the previous time is 1 or more (S413). If the difference ΔN between the number of packets and the previous time is 1 or more (if S413 is Yes), the flow-based anomaly detection unit 104 determines that the communication having the extracted flow ID is communication that has increased due to a man-in-the-middle attack, and determines that the communication is a "man-in-the-middle attack (increase)" (S414). If the difference ΔN between the number of packets and the previous time is less than 1 (if S413 is No), the flow-based anomaly detection unit 104 determines that the communication having the extracted flow ID is communication that has decreased due to a man-in-the-middle attack and determines that it is a "man-in-the-middle attack (decrease)" (S415).

[0148] If no communication switching has occurred (if S412 is No), the flow-based anomaly detection unit 104 determines that the communication having the extracted flow ID is "normal" because it did not match any attack judgment (S416).

[0149] After the flow-based anomaly detection unit 104 determines that the communication having the extracted flow ID is a "flooding attack," "spoofing attack," "man-in-the-middle attack (increase)," "man-in-the-middle attack (decrease)," or "no anomaly," it checks whether anomaly detection processing has been performed for all flow IDs (S417). If processing has been completed for all flow IDs (if S417 is Yes), the Zone ECU ends processing. If processing has not been completed for all flow IDs (if S417 is No), the flow-based anomaly detection unit 104 returns to step S402 and performs the same processing for flow IDs that have not yet been subjected to anomaly detection processing.

[0150] In the anomaly detection process in FIG. 14, several specific thresholds are used to determine anomalies, but in reality, the thresholds change depending on the assumed communication environment.

[0151] In addition, in Figure 14, anomaly detection is performed using only the parameters of the number of packets and the average arrival interval, but by using other parameters, it is possible to further improve detection accuracy and detect attacks other than flooding attacks, spoofing attacks, and man-in-the-middle attacks.

[0152] 15 is a diagram showing an example of an abnormality alert generated as a result of flow-based anomaly detection. The generated abnormality alert includes information necessary for the DPI rule generation unit 105A to generate a DPI rule. The abnormality alert includes an alert number, the flow ID of the communication determined to be abnormal, the alert type, the protocol, and the packet occupancy rate at the destination ECU.

[0153] An alert number is issued for each flow ID of an abnormal communication, but if two or more communications are considered to be a single attack, such as a man-in-the-middle attack, the same alert number is assigned to those two or more communications.

[0154] The flow ID represents the header information of a communication packet, and an alert is generated when the communication identified by this flow ID is abnormal.

[0155] The types of alerts represent the results determined by flow-based anomaly detection. Since man-in-the-middle attacks are detected from the correlation between two communications: one with an increasing number of packets and the other with a decreasing number of packets, anomaly alerts are generated for two types of flow IDs.

[0156] The protocol indicates the protocol of the communication having the corresponding flow ID, and is used to determine whether the communication is encrypted.

[0157] Packet occupancy is a parameter for setting the processing priority of a DPI rule, and indicates the percentage of packets with the corresponding flow ID among all packets communicated by the ECU with the destination IP address of the flow ID. However, only when the alert type is "man-in-the-middle attack (decreased)", the packet occupancy is calculated by referring to the source IP address of the flow ID, not the destination IP address.

[0158] [DPI Rule Generation Flowchart] FIG. 16 is a flowchart of DPI rule generation.

[0159] The DPI rule generation unit 105A receives an abnormality alert generated by the flow-based abnormality detection unit (S501).

[0160] The DPI rule generation unit 105A provisionally issues a rule number for the DPI rule (S502). For example, if there are multiple abnormal alerts with the same alert number, such as for a man-in-the-middle attack, the DPI rule generation unit 105A provisionally issues the same rule number. The rule number is then officially reissued by the DPI rule transfer unit 105B.

[0161] The DPI rule generation unit 105A sets the ECU having the destination IP address of the flow ID of the abnormality alert as the application destination of the DPI rule (S503).

[0162] The DPI rule generating unit 105A extracts the packet occupancy rate of the set application destination ECU from the abnormality alert and sets it as a processing priority value (S504).

[0163] The DPI rule generation unit 105A checks whether the alert type of the DPI alert is a "flooding attack" (S505). If the alert type is a "flooding attack" (if S505 is Yes), the DPI rule generation unit 105A sets the source IP address and destination IP address of the flow ID of the abnormal alert in the header condition of the DPI rule (S506). The DPI rule generation unit 105A then references the ECU management list, confirms the legitimate service ID from the flow ID (S507), and sets the check content of the DPI rule using the confirmed service ID (S508). As a check operation, the DPI rule generation unit 105A sets a process to notify the Zone ECU that issued the DPI rule of an alert (S509). The number of monitored packets is set to a value required for monitoring flooding attacks (S510). Then, the DPI rule generating unit 105A integrates the contents set up to this point into one DPI rule (S511).

[0164] The DPI rule generation unit 105A requests the DPI rule transfer unit 105B to transfer the generated DPI rule to the set application destination ECU (S512), and ends the DPI rule generation process.

[0165] If the alert type is not a "flooding attack" (if S505 is No), the DPI rule generation unit 105A checks whether the alert type is a "spoofing attack" (S513). If the alert type is a "spoofing attack" (if S513 is Yes), the DPI rule generation unit 105A sets the flow ID of the abnormal alert in the header condition of the DPI rule (S514). The DPI rule generation unit 105A then references the ECU management list to confirm the legitimate client ID from the flow ID (S515) and sets the check content of the DPI rule using the confirmed client ID (S516). As a check operation, the DPI rule generation unit 105A blocks the packet and resets its own monitoring packet count to unlimited (∞) (S517). The DPI rule generation unit 105A sets the monitoring packet count to a value required for monitoring a spoofing attack (S518). Then, the DPI rule generating unit 105A integrates the contents set up to this point into one DPI rule (S511), requests the transfer of the DPI rule (S512), and ends the DPI rule generation process.

[0166] If the alert type is not "spoofing attack" (if S513 is No), the DPI rule generation unit 105A checks whether the alert type is "man-in-the-middle attack (increase)" (S519). If the alert type is "man-in-the-middle attack (increase)" (if S519 is Yes), the DPI rule generation unit 105A sets the source IP address and destination IP address of the flow ID of the abnormal alert in the header condition of the DPI rule (S520). Then, the DPI rule generation unit 105A references the ECU management list to confirm the legitimate service ID from the flow ID (S521), and sets the check content of the DPI rule using the confirmed service ID (S522). As a check operation, the DPI rule generation unit 105A sets a process to notify the Zone ECU that issued the DPI rule of an alert (S523). The DPI rule generation unit 105A sets the number of monitored packets to a value required for monitoring man-in-the-middle attacks (S524). Then, the DPI rule generating unit 105A integrates the contents set up to this point into one DPI rule (S511), requests the transfer of the DPI rule (S512), and ends the DPI rule generation process.

[0167] If the alert type is not "man-in-the-middle attack (increase)" (if S519 is No), the DPI rule generation unit 105A determines that the alert type is "man-in-the-middle attack (decrease)." The DPI rule generation unit 105A estimates the ECU that is the source of the flow ID of the abnormal alert with the same alert number and the alert type "man-in-the-middle attack (increase)" as the attacking ECU (S525). The DPI rule generation unit 105A extracts the source ECU from the flow ID of its own abnormal alert with the alert type "man-in-the-middle attack (decrease)," and sets the pair of the source ECU and the IP address of the estimated attacking ECU (the attacking ECU is the destination) as the header condition of the DPI rule (S526). The DPI rule generation unit 105A resets the ECU to which the DPI rule is applied to the ECU with the source IP address of the flow ID (S527). The DPI rule generation unit 105A sets the check details, check operation, and number of monitored packets of the DPI rule to the same contents as those of the paired DPI rule, that is, the DPI rule generated from the abnormal alert having the same alert number and the alert type of "man-in-the-middle attack (increase)" (S528).The DPI rule generation unit 105A then integrates the contents set up to this point into one DPI rule (S511), requests the transfer of the DPI rule (S512), and ends the DPI rule generation process.

[0168] [DPI Rule Transfer Flowchart] FIG. 17 is a flowchart of DPI rule transfer.

[0169] The DPI rule transfer unit 105B refers to the ECU management list and checks whether the created DPI rule is to be applied to an ECU under its own management (S601).

[0170] If the ECU is under its own control (if S601 is Yes), the DPI rule transfer unit 105B sets itself as the issuer of the DPI rule (S602), modifies the DPI rule number so that the issuer's Zone ECU can be identified (S603), and saves the DPI rule in the all-DPI rule storage unit 106 (S604).The DPI rule transfer unit 105B then transfers the DPI rule to the destination ECU (S605), and ends the DPI rule transfer process.

[0171] If the ECU is not under its own control (if S601 is No), the DPI rule transfer unit 105B refers to the ECU management list and sets the issuer of the DPI rule to the management Zone ECU of the ECU to which the rule is applied (S606).The DPI rule transfer unit 105B then modifies the DPI rule number to one that identifies the issuer's Zone ECU (S607), saves the DPI rule in the all-DPI rule storage unit 106 (S608), and ends the DPI rule transfer process.

[0172] [Example of Generated DPI Rule] FIG. 18 is a diagram showing an example of a DPI rule generated from an abnormality alert.

[0173] FIG. 18 shows the DPI rules generated from the abnormal alerts of FIG.

[0174] The rule number issued is one that allows the target ECU to identify the Zone ECU that issued the DPI rule. For example, if Zone ECU 100b is the issuer, a number combining alphabets, such as "B-1," is issued. However, for the DPI rule set for "man-in-the-middle attack monitoring," the same number is issued to match the Zone ECU that notifies the DPI alert.

[0175] The check contents and actions taken at the time of check vary depending on the attack contents detected by flow-based anomaly detection.

[0176] For example, in the case of a flooding attack monitoring rule (flooding monitoring), it is assumed that the attacking ECU is sending a large number of communication packets using only a specific service ID, and it checks whether only one service ID is being used. The check involves obtaining the service ID of the communication that was found to be abnormal in flow-based anomaly detection from the ECU management list, and monitoring whether communication is being performed using any service ID other than that service ID. When communication other than the corresponding service ID is confirmed, the check action is to notify a DPI alert to the Zone ECU that issued the DPI rule. If the Zone ECU does not receive a certain number of DPI alert notifications before the specified number of monitored packets for flooding monitoring is completed, it determines that communication is abnormal.

[0177] Furthermore, for example, in the case of a spoofing attack monitoring rule (spoofing monitoring), monitoring is performed to check whether communications other than those using legitimate client IDs are being performed. When communications using a non-legitimate client ID are confirmed, the communications are determined to be abnormal, and the corresponding packets are blocked as a check operation, and the number of monitored packets in the DPI rule is changed to unlimited (∞).

[0178] Furthermore, in the case of a man-in-the-middle attack, for example, the system checks whether an ECU suspected to be the attacker is simultaneously communicating with two ECUs using the same service ID. When two ECUs that apply the DPI rule confirm communication using a specified service ID, they notify the same Zone ECU of a DPI alert. When the Zone ECU receives an alert from the two ECUs, it determines that the communication is abnormal.

[0179] In addition, the number of monitored packets is determined according to the content of the attack being monitored. For example, in flooding monitoring, the communication interval of the monitored packets is short and the processing load is expected to be large, so the number of monitored packets is set smaller than for other DPI rules to reduce the processing load.

[0180] [Flowchart of DPI Rule Processing] FIG. 19 is a flowchart of DPI rule processing in the DPI units 102 and 202. As shown in FIG.

[0181] The DPI unit 102, 202 receives a packet (S701) and selects the DPI rule with the highest processing priority among the DPI rules applied to itself (S702). Here, the DPI unit 102, 202 stores the DPI rules in advance in descending order of processing priority.

[0182] The DPI unit 102, 202 checks whether the header of the received packet satisfies the header conditions of the searched DPI rule (S703).

[0183] If the received packet satisfies the header conditions of the DPI rule (Yes in S703), the DPI unit 102, 202 checks whether the packet satisfies the check contents of the DPI rule (S704).

[0184] If the packet satisfies the check contents of the DPI rule (if S704 is Yes), the DPI unit 102, 202 executes the DPI rule check operation (S705), and if the packet does not satisfy the check contents of the DPI rule (if S704 is No), the DPI unit 102, 202 skips the processing of step S705.

[0185] Thereafter, the DPI units 102 and 202 increment the count of the number of monitored packets by 1 (S706).

[0186] The DPI unit 102, 202 checks whether the number of monitored packets has reached the number of monitored packets (S707). If the number of monitored packets has reached the number of monitored packets (Yes in S707), the DPI unit 102, 202 discards the DPI rule (S708), notifies the Zone ECU that issued the DPI rule of the rule termination (S709), and terminates the DPI rule processing.

[0187] If the received packet does not satisfy the header condition of the DPI rule (if S703 is No), the DPI unit 102, 202 checks whether there are any other unprocessed DPI rules (S710). If there are any other unprocessed DPI rules (if S710 is Yes), the DPI unit 102, 202 selects the DPI rule with the next highest processing priority (S711) and returns to step S703.

[0188] If there are no other unprocessed DPI rules (No in S710), the DPI units 102 and 202 terminate the DPI rule processing.

[0189] [Example of DPI Alert] FIG. 20 is a diagram showing an example of a DPI alert.

[0190] A DPI alert is mainly notified when the number of packets monitored by the DPI rule in the DPI units 102 and 202 reaches a specified number of monitored packets, or is notified as an operation when some DPI rules are checked.

[0191] The DPI alert has a rule number, a DPI rule name, an ECU to which it applies, and alert content.

[0192] The rule number indicates the rule number of the corresponding DPI rule, so by checking the rule number, it is possible to determine which DPI rule the alert relates to.

[0193] The DPI rule name indicates the name of the corresponding DPI rule.

[0194] The application ECU indicates the ECU to which the corresponding DPI rule applies, and is used to understand which ECU notified the DPI alert.

[0195] The alert content is divided into "rule completed" and "check met."

[0196] A DPI alert with the alert content "rule ended" indicates that the number of packets monitored for the DPI rule has reached the specified number of packets monitored.

[0197] A DPI alert with the alert content "Check met" indicates that the check content of the DPI rule has been met.

[0198] For example, rule numbers "B-1" and "C-1" in FIG. 20 indicate that monitoring by the DPI rule has ended and the DPI rule corresponding to the rule number has been discarded in the ECU to which it is applied.

[0199] 20 indicates that a packet that satisfies the check contents of the DPI rule has been received at the target ECU. Since the DPI rule with rule number "B-2" is "man-in-the-middle attack monitoring," it can be determined that the communication being monitored is abnormal because communications using the same service ID have been confirmed from two ECUs.

[0200] [Flowchart of DPI Alert Processing] FIG. 21 is a flowchart of the DPI alert processing in the Zone ECUs 100a, 100b, and 100c.

[0201] The DPI alert processing unit 105C receives a DPI alert (S801).

[0202] The DPI alert processing unit 105C checks whether the DPI rule name of the DPI alert is "Flooding monitor" (S802). If the DPI rule name is "Flooding monitor" (if S802 is Yes), the DPI alert processing unit 105C checks whether the alert content is "rule end" (S803). If the alert content is "rule end" (if S803 is Yes), the DPI alert processing unit 105C checks whether 100 or more DPI alerts with the same rule number and alert content "check applicable" have been received (S804). If 100 or more DPI alerts with "check applicable" have been received (if S804 is Yes), the DPI alert processing unit 105C can confirm that communication is not limited to a single service ID, and therefore determines that the communication monitored by the DPI rule is normal (S805). Since the corresponding DPI rule has already been discarded in the ECU to which the DPI rule is applied, the DPI alert processing unit 105C discards the corresponding DPI rule from all DPI rule storage units 106 in the Zone ECU (S806). Here, the DPI alert processing unit 105C notifies the Zone ECUs other than itself to discard the rule.

[0203] If 100 or more "checked" DPI alerts have not been received (if S804 is No), the DPI alert processing unit 105C determines that the communication monitored by the DPI rule is abnormal communication using a single service ID (S807).The DPI alert processing unit 105C then discards all existing DPI rules from the DPI rule storage unit 106, reissues a DPI rule that blocks the abnormal communication (S808), and terminates the DPI alert processing.

[0204] If the alert content is not "end of rule" (if S803 is No), that is, if the alert content is "check applicable", the DPI alert processing unit 105C terminates the DPI alert processing and waits until a DPI alert with the alert content "end of rule" is notified.

[0205] If the DPI rule name is not "Flooding monitoring" (if S802 is No), the DPI alert processing unit 105C checks whether the alert content is "rule end" (S809). If the alert content is "rule end" (if S809 is Yes), the DPI alert processing unit 105C determines that the communication monitored by the DPI rule is normal because no particular element that is judged to be abnormal has been reported. The DPI alert processing unit 105C then discards the corresponding DPI rule from all DPI rule storage units 106 in the Zone ECU (S811).

[0206] If the alert content is not "rule end" (No in S809), it is determined that the DPI alert has a DPI rule name of "man-in-the-middle attack monitoring" and an alert type of "checked."

[0207] The DPI alert processing unit 105C checks whether a "check hit" message with the same rule number but a different DPI rule name has already been received (S812). If a "check hit" message with the same rule number but a different DPI rule name has already been received (if S812 is Yes), the DPI alert processing unit 105C has confirmed that the attacker ECU is communicating using the same service ID, and therefore determines that the communication monitored by the DPI rule is abnormal (S813). The DPI alert processing unit 105C then discards all existing DPI rules from the DPI rule storage unit 106, reissues a DPI rule that blocks the abnormal communication (S814), and terminates the DPI alert processing.

[0208] If a "check matched" with the same rule number but a different DPI rule name has not been received (if S812 is No), the DPI alert process ends, and the DPI alert processing unit 105C waits until the next DPI alert is notified.

[0209] [Example of DPI Rule for Blocking Abnormal Communication] FIG. 22 is a diagram showing an example of DPI rule for blocking abnormal communication.

[0210] In FIG. 22, the DPI rule name is "abnormal communication."

[0211] The header condition specifies the header information of the abnormal communication, and the check content specifies confirmation of the service ID or client ID used in the abnormal communication, etc. Then, for communications that match the specified content, the check action is specified to block the packets.

[0212] The number of monitored packets is set to unlimited (∞), so that the DPI unit of the ECU cannot arbitrarily discard the DPI rule. It is desirable to recalculate the processing priority for the relevant packet, but the processing priority of the original DPI rule may also be used.

[0213] (Embodiment 2) Hereinafter, an anomaly detection device (anomaly detection system) for a vehicle equipped with an in-vehicle network (an in-vehicle network system) in which multiple ECUs communicate via Ethernet will be described. Note that components having the same functions as those in Embodiment 1 will be assigned the same numbers and descriptions thereof will be omitted.

[0214] [Overall Configuration of In-Vehicle Network System] FIG. 23 is a diagram showing the overall configuration of an in-vehicle network system 20. As shown in FIG.

[0215] In FIG. 23, the in-vehicle network system 20 includes an ADAS ECU 200a, an IVI ECU 200b, a steering control ECU 200c, a brake control ECU 200d, a shift lever ECU 200e, a camera ECU 200f, a LiDAR ECU 200g, and Zone ECUs 1100a, 1100b, and 1100c.

[0216] 24 is a diagram showing the configuration of the Zone ECU 1100a. Note that the Zone ECUs 1100b and 1100c have the same configuration, and therefore their description will be omitted.

[0217] 24, the Zone ECU 1100a includes a communication port unit 101, a DPI unit 102, a flow information collection unit 103, a flow-based anomaly detection unit 104, a DPI control unit 1105, a total DPI rule storage unit 106, and an ECU management list storage unit 107.

[0218] The DPI control unit 1105 is made up of a DPI rule generation unit 1105A, a DPI rule transfer unit 1105B, and a DPI alert processing unit 1105C.

[0219] The DPI rule generation unit 1105A generates DPI rules based on the abnormality alert output by the flow-based anomaly detection unit 104 and the DPI alert output from the DPI unit of each ECU. The DPI rule generation unit 1105A determines the header conditions, check contents, check operation, and number of packets to be monitored for the DPI rule.

[0220] The DPI rule transfer unit 1105B determines the application destination of the DPI rule generated by the DPI rule generation unit 1105A according to the processing load status of each ECU, and transfers the DPI rule. For example, if the number of monitored packets in the DPI unit 202 that monitors communication between the ADAS ECU 200a and the steering wheel control ECU 200c exceeds a specified value, the DPI rule transfer unit 1105B transfers the generated DPI rule to the Zone ECU 1100a or the Zone ECU 1100b instead.

[0221] In addition, when determining where to apply the DPI rule, the DPI rule transfer unit 1105B receives the number of communication packets of the ECUs that are candidates for application and the number of monitored packets in the DPI unit from the flow information collection unit 103, and determines where to apply the DPI rule based on that information and also calculates the processing priority.

[0222] [Processing Sequence] FIG. 25 is a diagram showing a processing sequence in which, when an attack occurs from the steering wheel control ECU 200c to the ADAS ECU 200a in the second embodiment, the Zone ECUs 1100b and 1100c collect flow information using the flow information collection unit 103, perform anomaly detection using the flow-based anomaly detection unit, generate DPI rules using the DPI rule generation unit 1105A based on the results, determine where the DPI rules should be applied depending on the processing load status of each ECU, and take security measures based on the monitoring results of the applied DPI rules.

[0223] The steering wheel control ECU 200c performs a flooding attack on the ADAS ECU 200a (S901).

[0224] The Zone ECUs 1100a and 1100c present on the communication path between the steering wheel control ECU 200c and the ADAS ECU 200a mirror and receive the packets, and collect flow information (S902).

[0225] The collected flow information is shared among the Zone ECUs 1100a, 1100b, and 1100c (S903).

[0226] The Zone ECUs 1100a, 1100b, and 1100c each perform flow-based anomaly detection based on the shared flow information, and detect that the steering wheel control ECU 200c is attacking the ADAS ECU 200a (S904).

[0227] The Zone ECUs 1100a, 1100b, and 1100c generate DPI rules based on the results of the flow-based anomaly detection (S905).

[0228] The Zone ECU 1100b selects the ADAS ECU 200a, the steering wheel control ECU 200c, the Zone ECU 1100a, and the Zone ECU 1100b as candidates for application of the generated DPI rule, checks the processing load of each ECU from the flow information, determines itself as the application of the DPI rule, and applies the DPI rule (S906).

[0229] The Zone ECU 1100c determines from the flow information that the created DPI rule is to be applied to the Zone ECU 1100b (S907).

[0230] The steering wheel control ECU 200c continues to perform the flooding attack on the ADAS ECU 200a (S908).

[0231] The Zone ECU 1100b monitors the payload of the packet in accordance with the DPI rule applied to the DPI unit 102 (S909).

[0232] The Zone ECU 1100b generates a DPI alert in accordance with the monitoring result of the DPI unit 102 (S910).

[0233] The Zone ECU 1100b officially determines that an abnormality has occurred based on the generated DPI alert, and applies the DPI rule for blocking abnormal communication to its own DPI unit 102 (S911).

[0234] The steering wheel control ECU 200c continues to perform a flooding attack on the ADAS ECU 200a (S911).

[0235] In the DPI unit 102 of the Zone ECU 1100b, abnormal communication from the steering wheel control ECU 200c to the ADAS ECU 200a is blocked in accordance with the DPI rules (S912).

[0236] [DPI Rule Generation Flowchart] FIG. 26 is a flowchart showing the process of generating DPI rules.

[0237] The DPI rule generation unit 1105A receives an abnormality alert generated by the flow-based abnormality detection unit (S1001).

[0238] The DPI rule generating unit 1105A provisionally issues a rule number for the DPI rule (S1002).

[0239] The DPI rule generation unit 1105A checks whether the alert type of the DPI alert is "flooding attack" (S1003). If the alert type is "flooding attack" (if S1003 is Yes), the DPI rule generation unit 1105A sets the source and destination IP addresses of the flow ID of the abnormal alert in the header condition of the DPI rule (S1004). The DPI rule generation unit 1105A then references the ECU management list to confirm the legitimate service ID from the flow ID (S1005), and sets the check content of the DPI rule using the confirmed service ID (S1006). As a check operation, the DPI rule generation unit 1105A sets a process to notify the Zone ECU that issued the DPI rule of an alert (S1007). The DPI rule generation unit 1105A sets a value required for monitoring flooding attacks as the number of packets to be monitored (S1008).The DPI rule generation unit 1105A then integrates the contents set up to this point into one DPI rule (S1009).

[0240] The DPI rule generating unit 1105A requests the DPI rule transferring unit 1105B to transfer the generated DPI rule together with the determination of the application destination and the processing priority (S1010), and ends the DPI rule generating process.

[0241] If the alert type is not a "flooding attack" (if S1003 is No), the DPI rule generation unit 1105A checks whether the alert type is a "spoofing attack" (S1011). If the alert type is a "spoofing attack" (if S1011 is Yes), the DPI rule generation unit 1105A sets the flow ID of the abnormal alert in the header condition of the DPI rule (S1012). Then, the DPI rule generation unit 1105A references the ECU management list to confirm the legitimate client ID from the flow ID (S1013), and sets the check content of the DPI rule using the confirmed client ID (S1014). As a check operation, the DPI rule generation unit 1105A blocks the packet in question and resets its own monitoring packet count to unlimited (∞) (S1015). The DPI rule generation unit 1105A sets a value required for monitoring spoofing attacks as the number of packets to be monitored (S1016).The DPI rule generation unit 1105A then integrates the contents set up to this point into one DPI rule (S1009), requests the transfer of the DPI rule (S1012), and ends the DPI rule generation process.

[0242] If the alert type is not "spoofing attack" (if S1011 is No), the DPI rule generation unit 1105A checks whether the alert type is "man-in-the-middle attack (increase)" (S1017). If the alert type is "man-in-the-middle attack (increase)" (if S1017 is Yes), the DPI rule generation unit 1105A sets the source and destination IP addresses of the flow ID of the abnormal alert in the header condition of the DPI rule (S1018). Then, the DPI rule generation unit 1105A references the ECU management list to confirm the legitimate service ID from the flow ID (S1019), and sets the check content of the DPI rule using the confirmed service ID (S1020). As a check operation, the DPI rule generation unit 1105A sets a process to notify the Zone ECU that issued the DPI rule of an alert (S1021). The DPI rule generation unit 1105A sets the number of monitored packets to a value required for monitoring man-in-the-middle attacks (S1022).The DPI rule generation unit 1105A then integrates the settings made up to this point into one DPI rule (S1009), requests the transfer of the DPI rule (S1010), and ends the DPI rule generation process.

[0243] If the alert type is not "man-in-the-middle attack (increase)" (if S1017 is No), the DPI rule generation unit 1105A determines that the alert type is "man-in-the-middle attack (decrease)." The DPI rule generation unit 1105A estimates that the ECU that is the source of the flow ID of an abnormal alert that has the same alert number and whose alert type is "man-in-the-middle attack (increase)" is the attacking ECU (S1023). The DPI rule generation unit 1105A extracts the source ECU from the flow ID of its own abnormal alert that has the alert type "man-in-the-middle attack (decrease)," and sets the pair of the source ECU and the IP address of the estimated attacking ECU (the attacking ECU is considered to be the destination) as the header condition of the DPI rule (S1024). The DPI rule generation unit 1105A sets the check details, check operation, and number of monitored packets of the DPI rule to the same contents as those of the paired DPI rule, that is, the DPI rule generated from the abnormal alert having the same alert number and the alert type of "man-in-the-middle attack (increase)" (S1025).The DPI rule generation unit 1105A then integrates the contents set up to this point into one DPI rule (S1009), requests the DPI rule transfer unit 1105B to transfer the DPI rule (S1010), and ends the DPI rule generation process.

[0244] [Flowchart of DPI Rule Transfer Processing] FIG. 27 is a flowchart of DPI rule transfer processing.

[0245] The DPI rule transfer unit 1105B receives the DPI rule generated by the DPI rule generation unit 1105A (S1101).

[0246] The DPI rule forwarding unit 1105B selects ECUs on the path through which the packet to be monitored by the DPI rule passes (S1102). The ECUs on the path include the source ECU of the packet to be monitored, the destination ECU, and the Zone ECUs on the communication path between the source ECU and the destination ECU. In FIG. 27, Zone ECUs 100a and 100b are selected as Zone ECUs on the path. It is assumed that Zone ECU 100b is the Zone ECU that manages the source ECU.

[0247] The DPI rule transfer unit 1105B requests flow information from each selected ECU and calculates the packet occupancy rate and the number of packets per minute that are subjected to payload monitoring processing in the DPI unit (hereinafter referred to as the number of DPI processed packets) for each ECU (S1103).

[0248] The DPI rule transfer unit 1105B checks whether the packet to be monitored by the DPI rule is an encrypted communication (S1104). If the packet to be monitored is an encrypted communication (Yes in S1104), the DPI rule transfer unit 1105B narrows down the candidates to the source ECU and destination ECU that can decrypt the encrypted communication, and checks whether the destination ECU has more DPI-processed packets than the source ECU (S1105). If the destination ECU has more DPI-processed packets than the source ECU (Yes in S1105), the DPI rule transfer unit 1105B sets the source ECU to which the DPI rule applies, sets the packet occupancy rate of that ECU as the processing priority, and transfers the packets (S1106). Then, the DPI rule transfer process ends.

[0249] If the number of DPI processed packets in the destination ECU is smaller than that in the source ECU (if S1105 is No), the DPI rule transfer unit 1105B sets the destination ECU to which the DPI rule is applied, sets the packet occupancy rate in that ECU as the processing priority, and transfers the packets (S1105).Then, the DPI rule transfer process ends.

[0250] If the packets to be monitored are not encrypted (No in S1104), the Zone ECU can also monitor the packets without decrypting them, so the DPI rule forwarding unit 1105B checks whether the number of DPI processed packets of Zone ECU 1100b that manages the source ECU is 10,000 or more (S1108).If the number of DPI processed packets of Zone ECU 1100b is 10,000 or more (Yes in S1108), the DPI rule forwarding unit 1105B checks whether the number of DPI processed packets of Zone ECU 1100a, which is another candidate Zone ECU, is 10,000 or more (S1109). If the number of DPI processed packets in Zone ECU 1100a is 10,000 or more (if S1109 is Yes), monitoring on the Zone ECU side is difficult, so DPI rule transfer unit 1105B performs step S1105. If the number of DPI processed packets in Zone ECU 1100a is less than 10,000 (if S1109 is No), monitoring is possible on the Zone ECU 1100a, so DPI rule transfer unit 1105B sets Zone ECU 1100a as the application destination of the DPI rule, sets the packet occupancy rate in that ECU as the processing priority, and performs transfer (S1110). Then, the DPI rule transfer process ends.

[0251] If the number of DPI processed packets in Zone ECU 1100b is less than 10,000 (No in S1108), monitoring is possible in Zone ECU 1100b, so the DPI rule transfer unit 1105B sets Zone ECU 1100b as the application destination of the DPI rule, sets the packet occupancy rate in that ECU as the processing priority, and performs transfer (S1111). Thereafter, the DPI rule transfer process ends.

[0252] [An example of flow information requested to determine the application destination and processing priority] Figure 28 is a diagram showing an example of flow information that the DPI rule transfer unit 1105B requests from the flow information collection unit 103 to determine the application destination and processing priority of the DPI rule.

[0253] When determining the application destination of the DPI rule, the DPI rule transfer unit 1105B notifies the flow information collection unit 103 of the header conditions of packets to be monitored by the DPI rule. The flow information collection unit 103 selects an ECU that can monitor packets with the notified header conditions, extracts and organizes flow information that serves as a comparison condition for determining the application destination of the DPI rule and flow information for determining processing priority from the collected flow information, and transfers the flow information to the DPI rule transfer unit 1105B.

[0254] In FIG. 28, the flow information requested from the flow information collection unit 103 is associated with the rule number provisionally issued when the DPI rule is generated.

[0255] In Figure 28, the flow information includes whether encryption is performed, the communication volume of packets to be monitored, candidate ECUs to which the DPI rule is applied, the overall communication volume of each candidate ECU, the packet occupancy rate of packets to be monitored, and the number of DPI processed packets at each candidate ECU.

[0256] The presence or absence of encryption indicates whether the communication that meets the target header condition is encrypted or not. The presence or absence of encryption is determined by the combination of the source ECU and the destination ECU.

[0257] The traffic volume of packets to be monitored indicates the traffic volume of packets that meet the header conditions communicated on the in-vehicle network system 20 .

[0258] The candidate ECUs indicate ECUs through which packets to be monitored pass when communicating.

[0259] The packet occupancy rate is calculated as the ratio (%) of the number of packets to be monitored to the number of packets communicated by all ECUs that are candidates for application. When the ECUs to which the DPI rule is applied are determined, this value is set as the processing priority of the DPI rule.

[0260] The number of DPI-processed packets indicates the number of packets whose payloads are currently being monitored by the DPI unit of each candidate ECU according to the DPI rule. The flow information collection unit 103 calculates the number of DPI-processed packets by obtaining information on the DPI rules applied to each ECU from the all-DPI rule storage unit 106. The larger this value, the greater the processing load on the DPI unit of each ECU. The number of DPI-processed packets is not limited to the above definition, and may be the number of times the DPI units 102, 202 perform a header check on the DPI rule and received packets.

[0261] [Example of DPI Rule with Dynamically Changed Application Destination] FIG. 29 is a diagram showing an example of a DPI rule with dynamically changed application destination.

[0262] For example, in the case of rule number "B-11" in Fig. 29, the DPI rule is applied to Zone ECU 1100b, which is the issuer of the DPI rule. Rule number "B-12" is a DPI rule for man-in-the-middle attack monitoring, so two DPI rules are generated, one of which is applied to Zone ECU 1100c and the other to ECU 200d.

[0263] Third Embodiment Hereinafter, an anomaly detection device (anomaly detection system) for a vehicle equipped with an in-vehicle network (an in-vehicle network system) in which multiple ECUs communicate via Ethernet will be described. Note that components having the same functions as those in the first embodiment will be assigned the same numbers and will not be described again.

[0264] [Overall Configuration of In-Vehicle Network System] FIG. 30 is a diagram showing the overall configuration of an in-vehicle network system 30. As shown in FIG.

[0265] In FIG. 30, the in-vehicle network system 30 is composed of an ADAS ECU 200a, an IVI ECU 200b, a steering control ECU 200c, a brake control ECU 200d, a shift lever ECU 200e, a camera ECU 200f, a LiDAR ECU 200g, and Zone ECUs 2100a, 2100b, and 2100c.

[0266] 31 is a diagram showing the configuration of the Zone ECU 2100a. Note that the Zone ECUs 2100b and 2100c have the same configuration, and therefore their description will be omitted.

[0267] In FIG. 31 , the Zone ECU 2100a includes a communication port unit 101, a DPI unit 102, a flow information collection unit 103, a flow-based anomaly detection unit 104, a DPI control unit 2105, an all-DPI rule memory unit 106, an ECU management list storage unit 107, a safety determination unit 2108, and a safety monitoring DPI rule list storage unit 2109.

[0268] The DPI control unit 2105 is made up of a DPI rule generation unit 2105A, a DPI rule transfer unit 2105B, and a DPI alert processing unit 2105C.

[0269] The DPI rule generation unit 2105A not only generates DPI rules from abnormality alerts generated by the flow-based anomaly detection unit 104, but also generates DPI rules in response to instructions from the safety determination unit 2108.

[0270] The safety determination unit 2108 determines whether there is a risk to the driver's life based on the abnormality alert from the flow-based abnormality detection unit 104 and the vehicle status received from the ADAS ECU 200a and the shift lever ECU 200e, and issues a command to each ECU to ensure the driver's safety as necessary. Also, if there is a risk of attack on a function related to the driver's safety, it instructs the DPI rule generation unit 2105A to generate a DPI rule to monitor the communication of the ECU having that function.

[0271] The safety monitoring DPI rule list storage unit 2109 stores in advance templates of DPI rules to be generated in response to instructions from the safety determination unit 2108. When the DPI rule generation unit 2105A receives an instruction to generate a DPI rule from the safety determination unit 2108, it does not create a DPI rule from scratch, but instead calls up the template of the corresponding DPI rule from the safety monitoring DPI rule list storage unit 2109 to generate the DPI rule.

[0272] [Safety Monitoring DPI Rule List] FIG. 32 is a diagram showing an example of a safety monitoring DPI rule list stored in the safety monitoring DPI rule list storage unit 2109. As shown in FIG.

[0273] The DPI rule name, header condition, check content, check operation, and number of packets to be monitored are set for the DPI rules stored in the safety monitoring DPI rule list. The DPI rule generation unit 2105A requests the safety monitoring DPI rule list storage unit 2109 for the necessary DPI rules in accordance with instructions from the safety determination unit 2108.

[0274] In FIG. 32, two types of DPI rules are stored, with the DPI rule names being "emergency stop system monitoring" and "back monitor monitoring."

[0275] The DPI rule for monitoring the emergency stop system is a DPI rule that is generated when the safety determination unit 2108 determines to activate a system that brings the vehicle to an emergency stop based on an abnormality alert output from the flow-based anomaly detection unit 104. It checks whether a malicious ECU is performing a spoofing attack and conducting malicious communication on the control system ECU, sensor ECU, etc. that are used to bring the vehicle to an emergency stop. Therefore, if the communication does not use a legitimate client ID, the packet is blocked to protect the vehicle's functions.

[0276] The DPI rule for monitoring the rearview monitor is generated when an abnormality alert occurs in communication with the IVI when the shift lever is in reverse (R). The rearview monitor, which the driver looks at to check behind the vehicle while parking, is monitored to see if any communications other than those with a legitimate client ID are occurring, and communication packets with an invalid client ID are blocked by the DPI units 102 and 202.

[0277] [Processing Sequence] FIG. 33 is a diagram showing a processing sequence in which, when an attack occurs from the steering wheel control ECU 200c to the ADAS ECU 200a in the third embodiment, a DPI rule is applied to monitor the operation of the emergency stop system and communication of that function, and security measures are taken based on the monitoring results of the DPI unit.

[0278] The ADAS ECU 200a starts the automatic driving and reports this to the Zone ECUs 2100a, 2100b, and 2100c (S1201).

[0279] The shift lever ECU 200e periodically reports the state of the shift lever to the Zone ECUs 2100a, 2100b, and 2100c (S1202).

[0280] The steering wheel control ECU 200c masquerades as the ADAS ECU 200a and launches an attack (S1203).

[0281] The Zone ECUs 2100a and 2100c present on the communication path between the steering wheel control ECU 200c and the ADAS ECU 200a mirror the packets, receive the packets, and collect flow information (S1204).

[0282] The collected flow information is shared among the Zone ECUs 2100a, 2100b, and 2100c (S1205).

[0283] The Zone ECUs 2100a, 2100b, and 2100c each perform flow-based anomaly detection based on the shared flow information, and detect that the steering wheel control ECU 200c is attacking the ADAS ECU 200a (S1206).

[0284] The Zone ECUs 2100a, 2100b, and 2100c compare the content of the abnormality alert generated by flow-based abnormality detection with the vehicle status reported from the ADAS ECU 200a and the shift lever ECU 200e, and determine whether the content poses a threat to the safety of the vehicle (S1207).

[0285] As a result of the safety judgment, it is determined that there is a risk in continuing the autonomous driving, and after performing an emergency stop, a command to stop the autonomous driving system is sent to the ADAS ECU 200a (S1208).

[0286] The ADAS ECU 200a operates the emergency stop system in accordance with instructions from the Zone ECU 2100a that manages the ADAS ECU 200a (S1209).

[0287] In order to operate the emergency stop system safely, the Zone ECU 2100a distributes a DPI rule for monitoring whether unauthorized communication is being performed to the ECUs involved in the emergency stop (S1210).

[0288] The ADAS ECU 200a and the camera ECU 200f receive the DPI rules from the Zone ECU 2100a and apply them to the DPI unit 202 (S1211).

[0289] The steering wheel control ECU 200c continues to perform spoofing attacks on the ADAS ECU 200a (S1212).

[0290] The ADAS ECU 200a cuts off the abnormal communication from the steering wheel control ECU 200c in accordance with the DPI rules (S1213).

[0291] [Packet Processing by Zone ECU] FIG. 34 is a flowchart of processing when the Zone ECU receives a packet in the third embodiment.

[0292] The communication port unit 101 mirrors and receives packets communicated via itself (S1301).

[0293] The flow information collection unit 103 extracts header information from the received packet and updates the flow information (S1302).

[0294] The flow information collection unit 103 checks whether the specified time for collecting flow information has not been exceeded (S1303). If the specified time has been exceeded (Yes in S1303), the flow information collection unit 103 outputs the flow information (S1304). If the specified time has not been exceeded (No in S1303), the flow information collection unit 103 returns to the first step.

[0295] The output flow information is transferred to other Zone ECUs via the communication port unit 101 (S1305), and the communication port unit 101 receives the flow information transferred from other Zone ECUs (S1306).The flow information collection unit 103 then combines the flow information it has output with the flow information transferred from other Zone ECUs (S1307).

[0296] The flow-based anomaly detection unit 104 performs flow-based anomaly detection based on the combined flow information (S1308) and determines whether an anomaly exists (S1309). If an anomaly exists (YES in S1309), the flow-based anomaly detection unit 104 generates an anomaly alert that describes the anomaly (S1310). If no anomaly exists (NO in S1310), the Zone ECU ends the process.

[0297] The DPI rule generating unit 2105A checks the vehicle state to determine whether the content of the generated abnormality alert threatens the safety of the vehicle (S1311).

[0298] The DPI rule generating unit 2105A checks whether the vehicle is in a dangerous state based on the safety determination result (S1312).

[0299] If it is determined that the vehicle is in a dangerous state (if S1312 is Yes), the DPI rule generation unit 2105A instructs the ECU to take action to ensure safety (S1313), and further generates a DPI rule for ensuring the safety of the vehicle (S1314).If it is determined that the vehicle is not in a dangerous state (if S1312 is No), the DPI rule generation unit 2105A skips the processes of steps S1313 and S1314.

[0300] The DPI rule generating unit 2105A generates a DPI rule from the generated abnormality alert (S1315).

[0301] The DPI rule generating unit 2105A stores the generated DPI rule in the total DPI rule storage unit 106 (S1316).

[0302] The DPI rule transfer unit 2105B checks whether the ECU to which the DPI rule created from the ECU management list is applied is its own management ECU (S1317). If it is its own management ECU (Yes in S1317), the DPI rule transfer unit 2105B transfers the DPI rule to the application ECU (S1318), and the Zone ECU ends the process. If it is not its own management ECU (No in S1317), the Zone ECU ends the process.

[0303] [Safety Determination Processing Flowchart] FIG. 35 is a safety determination processing flowchart.

[0304] The safety determination unit 2108 checks whether there is an abnormality alert from the flow-based IDS (S1401). If there is an abnormality alert (Yes in S1401), the safety determination unit 2108 checks whether the communication from which the abnormality alert is issued is communication with the ADAS ECU 200a (S1402).

[0305] If the communication for which the abnormality alert is issued is communication with the ADAS ECU 200a (if S1402 is Yes), the safety determination unit 2108 checks whether the vehicle is in autonomous driving mode (S1403). If the vehicle is in autonomous driving mode (if S1403 is Yes), the safety determination unit 2108 instructs the ADAS ECU 200a to activate the emergency stop system and notifies the driver of this (S1404). Then, the safety determination unit 2108 instructs the DPI rule generation unit 2105A to generate a DPI rule for monitoring the emergency stop system (S1405).

[0306] If the vehicle is not in autonomous driving mode (if S1403 is No), the safety determination unit 2108 checks whether the shift lever is in drive (D) mode (S1406). If the shift lever is in D mode (if S1406 is Yes), the safety determination unit 2108 instructs the ADAS ECU 200a to stop drive assist and notifies the driver of this (S1407).

[0307] If the shift lever is not in D shift (if S1406 is No), the safety determination unit 2108 checks whether the shift lever is in reverse (R) shift (S1408). If the shift lever is in R shift (if S1408 is Yes), the safety determination unit 2108 instructs the ADAS ECU 200a to stop parking assist and notifies the driver of this (S1409). If the shift lever is not in R shift (if S1408 is No), the safety determination unit 2108 ends the safety determination process.

[0308] If the communication for which the abnormality alert has been issued is not communication with the ADAS ECU 200a (if No in S1402), the safety determination unit 2108 checks whether the communication for which the abnormality alert has been issued is communication with the IVI ECU 200b (S1410). If the communication for which the abnormality alert has been issued is communication with the IVI ECU 200b (if Yes in S1410), the safety determination unit 2108 checks whether the shift lever is in reverse (R) shift (S1411). If the shift lever is in R shift (if Yes in S1411), the safety determination unit 2108 instructs the DPI rule generation unit 2105A to generate a DPI rule for monitoring the rearview monitor (S1412).

[0309] If the communication for which the abnormality alert is issued is not communication with the IVI ECU 200b (if No in S1410) and if the shift lever is not in the R shift position (if No in S1411), the safety determination unit 2108 ends the safety determination process.

[0310] If there is no abnormality alert from the flow-based IDS (No in S1401), the safety determination unit 2108 ends the safety determination process.

[0311] [Flowchart of Generating DPI Rules for Safety Monitoring] FIG. 36 is a flowchart of the processing of the DPI rule generating unit 2105A in the third embodiment.

[0312] The DPI rule generation unit 2105A receives an instruction to generate a DPI rule from the safety determination unit 2108 (S1501).

[0313] The DPI rule generation unit 2105A checks whether the instruction from the safety determination unit 2108 is to generate a DPI rule for monitoring the emergency shutdown system (S1502). If the instruction from the safety determination unit 2108 is to generate a DPI rule for monitoring the emergency shutdown system (Yes in S1502), the DPI rule generation unit 2105A requests a DPI rule for monitoring the emergency shutdown system from the safety monitoring DPI rule list storage unit 2109 (S1503).

[0314] The DPI rule generation unit 2105A requests the DPI rule transfer unit 1105B to determine the application destination of the DPI rule, determine the processing priority, and transfer the rule to the application destination (S1504), and then ends the process.

[0315] If the instruction from the safety determination unit 2108 is not to generate a DPI rule for monitoring the emergency stop system (if S1502 is No), the DPI rule generation unit 2105A requests a DPI rule for monitoring the rearview monitor from the safety monitoring DPI rule list storage unit 2109 (S1503).The DPI rule generation unit 2105A then performs step S1504 and ends the process.

[0316] [Example of Safety Monitoring DPI Rule] FIG. 37 is a diagram showing an example of the generated safety monitoring DPI rule.

[0317] 37 is a DPI rule for monitoring the emergency stop system that was generated when an abnormality occurred in the ADAS ECU 200a during autonomous driving. Therefore, the Zone ECU 2100a that manages the ADAS ECU 200a is the issuer of the DPI rule, and the DPI rule transfer unit 1105B calculates and transfers the processing priority of each DPI rule.

[0318] [Other Modifications] Although the present disclosure has been described based on the above-described embodiments, it goes without saying that the present invention is not limited to the above-described embodiments.

[0319] (1) In the above embodiment, an example was shown in which Ethernet was used for the in-vehicle network, but this is not limited to this, and the in-vehicle network may be CAN, CAN-FD (Flexible-Data), Ethernet, LIN, FlexRay (registered trademark), or a combination of these.

[0320] (2) In the above embodiment, flow information is collected on the Zone ECU, but it does not have to be collected on the Zone ECU. For example, flow information may be collected on the head unit, central ECU, Ethernet switch, or the like.

[0321] (3) In the above embodiment, a set of source IP address, destination IP address, source port number, destination port number, and protocol number was used as information for identifying a flow, but this is not limited to the above. The V-LAN ID used in a virtual LAN may also be used as additional information. Furthermore, for example, in the case of CAN communication, a CAN ID, which is an identifier for communication data, may also be used. This makes flow definitions more flexible, enabling the collection of flow information appropriate for the network.

[0322] (4) In the above embodiment, the number of packets and the average arrival interval are used as flow information for flow-based anomaly detection. However, this is not limited to this, and the average packet length, timestamp, etc. may also be used.

[0323] (5) In the above embodiment, after flow-based anomaly detection, DPI, which is a payload-based anomaly detection function, is used. However, this is not limited to this, and for example, an AI-based anomaly detection function may also be used.

[0324] (6) In the above embodiment, each ECU discards the DPI rule as appropriate based on the monitoring results of the DPI unit. However, the Zone ECU may instruct each ECU to discard the DPI rule depending on the situation.

[0325] (7) In the above embodiment, the DPI rule is discarded when a specified number of packets have been monitored, but this is not limited to this. The DPI rule may be discarded when a certain amount of time has passed since it was applied, or when the number of DPI rules applied to the DPI unit exceeds a specified number, the DPI rule with the lowest monitoring priority may be discarded first.

[0326] (8) In the above embodiment, when a communication packet is encrypted, the DPI rules are applied to the source ECU and the destination ECU. However, if other ECUs, including the Zone ECU, are capable of decrypting encrypted packets, the DPI rules may also be applied to other ECUs, including the Zone ECU.

[0327] (9) In the above embodiment, an example is shown in which the DPI rules for safety monitoring are applied when the flow-based anomaly detection unit detects an anomaly in communication related to the ADAS ECU and the IVI ECU. However, the present invention is not limited to this. For example, the DPI rules may be applied when an anomaly is detected in communication related to a control system ECU or a sensor system ECU, or when two or more anomalies that combine these are detected.

[0328] (10) In the above embodiment, the vehicle state is determined by referring to the shift lever state and whether the vehicle is in automatic driving mode. However, this is not limited to this. For example, DPI rules may be generated, added, changed, enabled, or disabled by referring to vehicle states such as automatic parking, cruise control, software update, vehicle diagnosis, and internet connection.

[0329] (11) In the above embodiment, the application destination of the DPI rule is determined based on the number of packets processed by the DPI unit. However, this is not limited to this, and the application destination of the DPI rule may be determined based on the flow anomaly detection result by the flow-based anomaly detection unit. For example, when the flow-based anomaly detection unit detects a flooding attack, priority is given to applying the DPI rule to a Zone ECU that is close to the source ECU. When an anomaly is detected by the DPI unit, the Zone ECU drops the abnormal packet.

[0330] (12) In the above embodiments, some or all of the components constituting each device may be configured as a single system LSI (Large Scale Integration). A system LSI is an ultra-multifunctional LSI manufactured by integrating multiple components on a single chip. Specifically, it is a computer system including a microprocessor, ROM, RAM, etc. A computer program is stored in the RAM. The system LSI achieves its functions when the microprocessor operates in accordance with the computer program. Furthermore, each component constituting each device may be individually integrated into a single chip, or a single chip may include some or all of the components. Furthermore, although the term system LSI is used here, it may also be referred to as an IC, LSI, super LSI, or ultra LSI depending on the level of integration. Furthermore, the method of integration is not limited to LSI, and may be realized using a dedicated circuit or a general-purpose processor. It is also possible to use a field programmable gate array (FPGA), which can be programmed after LSI manufacturing, or a reconfigurable processor, which allows the connections and settings of circuit cells inside the LSI to be reconfigured. Furthermore, if an integrated circuit technology that can replace LSI emerges due to advances in semiconductor technology or a derivative technology, that technology may naturally be used to integrate functional blocks. The application of biotechnology, etc., is also a possibility.

[0331] (13) Some or all of the components constituting each of the above devices may be configured as an IC card or a standalone module that can be attached to each device. The IC card or module is a computer system composed of a microprocessor, ROM, RAM, etc. The IC card or module may include the above-mentioned ultra-multifunctional LSI. The IC card or module achieves its functions when the microprocessor operates according to a computer program. This IC card or module may be tamper-resistant.

[0332] (14) In one aspect of the present invention, the anomaly detection method may be a program (computer program) that is implemented by a computer, or a digital signal comprising the computer program. In another aspect of the present invention, the computer program or digital signal may be recorded on a computer-readable recording medium, such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray (registered trademark) Disc), semiconductor memory, etc. Alternatively, the method may be a digital signal recorded on such a recording medium. In another aspect of the present invention, the computer program or digital signal may be transmitted via a telecommunications line, a wireless or wired communication line, a network such as the Internet, data broadcasting, etc. In another aspect of the present invention, the computer system may include a microprocessor and a memory, in which the computer program is recorded, and the microprocessor operates according to the computer program. The program or digital signal may be recorded on a recording medium and transferred, or the program or digital signal may be transferred via a network, etc., to be implemented by another independent computer system.

[0333] (15) The scope of the present invention also includes configurations that are realized by arbitrarily combining the components and functions shown in the above-described embodiment and modified examples.

[0334] The present disclosure is useful for a device for detecting a communication abnormality and a method for detecting a communication abnormality in an in-vehicle network system.

[0335] 10, 20, 30 In-vehicle network system 100a, 100b, 100c, 1100a, 1100b, 1100c, 2100a, 2100b, 2100c Zone ECU 101, 201 Communication port unit 102, 202 DPI unit 103 Flow information collection unit 104 Flow-based anomaly detection unit 105, 1105, 2105 DPI control unit 105A, 1105A, 2105A DPI rule generation unit 105B, 1105B, 2105B DPI rule transfer unit 105C DPI alert processing unit 106 All DPI rule storage unit 107 ECU management list storage unit 200a ADAS ECU 200b IVI ECU 200c Steering control ECU 200d Brake control ECU 200e Shift lever ECU 200f Camera ECU 200g LiDAR ECU 203 Application section

Claims

1. An anomaly detection system for an in-vehicle network consisting of one or more sub-networks, comprising: a flow information collection unit that collects flow information, which is statistical information for each flow classified by header information of messages received at specified observation points of the in-vehicle network; a flow-based anomaly detection unit that performs anomaly detection based on the flow information and outputs detected flow anomaly detection results; a DPI unit that monitors the messages based on one or more DPI (Deep Packet Inspection) rules that indicate processing contents when a header value or payload value condition included in the message matches a condition of the header value or payload value of the message; and a DPI control unit that controls one of generating, adding, deleting, changing, enabling, or disabling a DPI rule based on the flow anomaly detection result.

2. The anomaly detection system of claim 1, wherein the one or more sub-networks are a hierarchical structure including an upper network and a lower network, one upper ECU is arranged in the upper network and one or more lower ECUs are arranged in the lower network, the one upper ECU is equipped with the DPI control unit, and each of the one or more lower ECUs is equipped with the DPI unit.

3. The anomaly detection system of claim 1, wherein the flow information includes information regarding the amount of messages received for each flow, the DPI control unit determines a processing priority indicating the order of processing for monitoring the messages for each of the one or more DPI rules based on the information, and generates the one or more DPI rules, and the DPI unit monitors the messages using the one or more DPI rules in order of the processing priority.

4. The anomaly detection system described in claim 3, wherein the DPI control unit determines the time for which monitoring in accordance with the DPI rules is enabled in the DPI unit, or the upper limit number of messages for which monitoring in accordance with the DPI rules is performed in the DPI unit, depending on the content of the anomaly detected by the flow-based anomaly detection unit and the number of messages monitored by the DPI unit per unit time.

5. The anomaly detection system described in claim 2, wherein one of the one or more DPI rules identifies service information or client information contained in a message transmitted and received between the one or more lower-level ECUs, the DPI control unit enables the one DPI rule, and if the service information or client information of the message being monitored does not match the one DPI rule, the DPI unit determines the message to be an unauthorized communication and drops it.

6. The anomaly detection system of claim 1, wherein the DPI unit outputs a monitoring result of monitoring the message, and the DPI control unit adds, changes, enables, or disables the DPI rules for the DPI unit based on the output monitoring result.

7. The anomaly detection system described in claim 2, wherein the DPI control unit adds, changes, enables, or disables the DPI rule depending on one or more of a vehicle state including at least one of a shift lever state, automatic driving, automatic parking, cruise control, software update, vehicle diagnosis, and Internet communication connection, and the flow anomaly detection result of the flow-based anomaly detection unit.

8. The anomaly detection system described in claim 7, wherein when the flow-based anomaly detection unit detects an anomaly, the DPI control unit checks the vehicle state depending on one of the one or more lower ECUs that is the source or destination of the message determined to be abnormal, and if the vehicle state is a predetermined state, the DPI control unit determines the conditions of the header value and payload value included in the message, which are included in the DPI rule, depending on the vehicle state, and the processing content when the conditions are met.

9. The anomaly detection system described in claim 2, wherein the upper network includes one or more upper networks, the one upper ECU is equipped with the DPI unit, and the DPI control unit selects, from the one or more lower ECUs, a source ECU and a destination ECU of a message to be monitored by the DPI rule, and further selects at least one of the one upper ECUs through which a message between the source ECU and the destination ECU passes, and applies the DPI rule to an ECU among the selected ECUs that has a small processing load for message processing.

10. The anomaly detection system of claim 9, further comprising: a communication volume calculation unit that calculates the communication volume of the selected ECU based on the flow information; a DPI rule recording unit that records the DPI rules enabled in the one or more lower-level ECUs; and a processing load calculation unit that calculates the processing load required for message processing from the communication volume of the selected ECU and the DPI rules held by the unit; and determining where to apply the DPI rule based on the calculated processing load.

11. The anomaly detection system described in claim 9, wherein the DPI control unit further applies the DPI rule to the DPI unit of the one upper ECU that is closer to the ECU that sent the message monitored by the DPI rule when the anomaly detected by the flow-based anomaly detection unit is an anomaly that places a load on the in-vehicle network.

Images