Abnormality detection method, abnormality detection device, and program

Abstract

An abnormality detection method by an upper-level electronic control device in an onboard network having a hierarchical structure including an upper-level network in which one or more upper-level electronic control devices are disposed and a lower-level network in which one or more lower-level electronic control devices are disposed, wherein flow information, which is statistical information for each flow classified by header information of a message received at a predetermined observation location of the onboard network, is collected (S102); abnormality detection is performed on the basis of the flow information (S104); a DPI rule is generated, added, deleted, changed, enabled, and disabled on the basis of a result of the abnormality detection (S105); the DPI rule is used for monitoring a message in the one or more lower-level electronic control devices; and the DPI rule indicates conditions of header information and payload information included in the message and processing contents, when a message matching the condition is received.

Description

Anomaly detection method, anomaly detection device, and program

[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 automotive Ethernet, a communication standard that is faster than CAN, is becoming increasingly popular.

[0004] Furthermore, as an anomaly detection method for monitoring malicious attackers, for example, the method described in Non-Patent Document 1 is known.

[0005] 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>

[0006] In such anomaly detection, it is desirable to be able to appropriately balance the trade-off between detection accuracy and processing volume.

[0007] The present disclosure aims to provide an anomaly detection method, an anomaly detection device, and the like that can appropriately balance detection accuracy and processing volume.

[0008] In order to solve the above problem, an anomaly detection method according to one aspect of the present disclosure is a method for detecting an anomaly by a higher-level electronic control device in an in-vehicle network having a hierarchical structure including an upper level network in which one or more higher-level electronic control devices are arranged and a lower level network in which one or more lower-level electronic control devices are arranged, the method comprising: collecting 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; performing anomaly detection based on the flow information; and generating, adding, deleting, changing, enabling, or disabling a DPI (Deep Packet Inspection) rule based on the results of the anomaly detection; the DPI rule is used to monitor the messages in the one or more lower-level electronic control devices; and the DPI rule indicates conditions for header information and payload information included in the messages and processing content to be performed when a message that matches the conditions is received.

[0009] The present disclosure can provide an anomaly detection method, an anomaly detection device, and the like that can appropriately balance detection accuracy and processing volume.

[0010] FIG. 1 is a diagram illustrating an overall configuration of an in-vehicle network system according to a first embodiment. FIG. 2 is a block diagram of a zone ECU according to the first embodiment. FIG. 3 is a block diagram of an ADAS ECU 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 according to the first embodiment. FIG. 9 is a diagram illustrating an example of a list of all DPI rules 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 flowchart of a DPI rule generation process by a zone ECU according to the first embodiment. FIG. 13 is a flowchart of a reception process by a communication port unit according to the first embodiment. FIG. 14 is a flowchart showing an example of processing by the flow-based anomaly detection unit according to the first embodiment. FIG. 15 is a diagram showing an example of an anomaly alert according to the first embodiment. FIG. 16 is a flowchart of DPI rule generation processing according to the first embodiment. FIG. 17 is a flowchart of DPI rule transfer processing according to the first embodiment. FIG. 18 is a diagram showing an example of a DPI rule generated from an anomaly alert according to the first embodiment. FIG. 19 is a diagram showing a flowchart of DPI rule processing according to the first embodiment. FIG. 20 is a diagram showing an example of a DPI alert according to the first embodiment. FIG. 21 is a flowchart of DPI alert processing in a zone ECU according to the first embodiment. FIG. 22 is a diagram showing an example of a DPI rule for blocking an abnormal communication according to the first embodiment. FIG. 23 is an overall configuration diagram of an in-vehicle network system according to the second embodiment. FIG. 24 is an overall configuration diagram of a zone ECU according to the second embodiment. FIG. 25 is a diagram showing a sequence from flow information collection to anomaly detection and security response according to the second embodiment.FIG. 26 is a flowchart of DPI rule generation processing 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 abnormality 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 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 a 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.

[0011] [Findings that Form the Basis of the Present Disclosure] Control frames that instruct the vehicle to run, stop, turn, etc. are transmitted and received over an in-vehicle network. Therefore, if a malicious attacker masquerades as a legitimate ECU to transmit control frames, or if a DoS attack is carried out with the aim of preventing the vehicle from receiving specific control frames, this poses a risk to not only the driver of the vehicle but also pedestrians around the vehicle.

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

[0013] As a method for monitoring the entire network, there is a specification called IPFIX, which is described in Non-Patent Document 1. In IPFIX, an Ethernet switch classifies multiple frames flowing over an Ethernet based on information contained in the Ethernet or TCP / IP header, and generates statistical information called flow information. 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.

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

[0015] In this disclosure, flow information is generated by collecting statistical information from packet header information. An upper-level anomaly detection device then detects anomalies based on temporal changes in the flow information, and activates payload-based monitoring rules for packets predicted to be anomalous based on the detection results. This allows payload monitoring to be performed on only some packets, making it possible to detect anomalies while reducing false positives and the amount of computation required for monitoring. This allows for monitoring of anomalous communications on in-vehicle networks while securing the computational resources required for processing by autonomous driving or advanced driving systems.

[0016] In other words, 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 unit 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 safe autonomous driving or advanced driver assistance services can be provided.

[0017] In order to solve the above problem, an anomaly detection method according to one aspect of the present disclosure is a method for detecting an anomaly by a higher-level electronic control device in an in-vehicle network having a hierarchical structure including a higher-level network in which one or more higher-level electronic control devices are arranged and a lower-level network in which one or more lower-level electronic control devices are arranged, the method comprising: collecting 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; performing anomaly detection based on the flow information; and generating, adding, deleting, changing, enabling, or disabling a DPI (Deep Packet Inspection) rule based on the result of the anomaly detection; the DPI rule is used to monitor the messages in the one or more lower-level electronic control devices; and the DPI rule indicates conditions for header information and payload information included in the messages and processing content to be performed when a message that matches the conditions is received.

[0018] As a result, anomaly detection based on flow information reduces the processing load and enables monitoring of the entire network without monitoring the payload information of each message. Furthermore, by generating DPI rules that include monitoring payload information based on the results of anomaly detection, false positives can be reduced. Furthermore, by performing anomaly detection in two stages, namely, anomaly detection based on flow information and monitoring using DPI rules, it is possible to set anomaly detection rules that allow false positives in the anomaly detection using flow information that first detects anomalies, but reduces the chance of missing anomalous communications. In this way, the present disclosure can appropriately balance detection accuracy and processing volume.

[0019] Furthermore, by having the upper-level electronic control unit perform anomaly detection based on flow information and then enabling the DPI rules generated using the results for the necessary lower-level electronic control units, the number of messages monitored by each electronic control unit can be reduced. This reduces the processing load per electronic control unit. Furthermore, by having the lower-level electronic control unit monitor the network in accordance with the upper-level electronic control unit, the monitoring rules can be simplified. This reduces the computing resources allocated to network monitoring.

[0020] For example, the flow information may include information regarding the amount of messages received for each flow, and the anomaly detection method may further determine, based on the information, a processing priority indicating the order in which the messages are monitored for each of one or more DPI rules including the DPI rule.

[0021] This reduces the number of times that the lower-level electronic control unit checks the DPI rules against the header information of the message, thereby reducing the computational resources consumed by the lower-level electronic control unit for message monitoring.

[0022] For example, the anomaly detection method may further determine the time for which monitoring of messages according to the DPI rules is enabled or the upper limit number of messages for which monitoring of messages according to the DPI rules is performed, depending on the content of the anomaly detected by the anomaly detection and the number of messages per unit time of the messages to be monitored.

[0023] This prevents the number of DPI rules applied to the subordinate electronic control unit from increasing monotonically over time, thereby reducing the processing load on the subordinate electronic control 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.

[0024] For example, the DPI rule indicates service information or client information to be included in messages sent and received between the one or more lower-level electronic control devices, and in the monitoring of the messages, if the service information or client information of the message does not match the service information or client information indicated in the DPI rule, the message may be dropped.

[0025] This allows the lower-level electronic control unit to independently determine whether a packet is abnormal and drop the packet.

[0026] For example, the abnormality detection method may further include adding, changing, enabling or disabling the DPI rule based on the monitoring results output from the one or more lower-level electronic control units.

[0027] This allows DPI rules that reflect not only anomaly detection based on flow information but also monitoring results from the lower-level electronic control units to be applied to each lower-level electronic control unit. For example, by enabling a DPI rule that monitors identifier information such as service information or client information included in message payload information, the lower-level electronic control unit detects identifier information that is unusual. In this case, the upper-level electronic control unit can generate or enable a DPI rule that drops messages with abnormal identifier information based on the detection results. In this way, security rules based on the monitoring results from the lower-level electronic control units can be applied.

[0028] For example, the abnormality detection method may further add, change, enable or disable the DPI rule depending on the vehicle state including at least one of the shift lever state, automatic driving, automatic parking, cruise control, software update, vehicle diagnosis, and internet communication connection, and the result of the abnormality detection.

[0029] This allows the higher-level electronic control unit to determine messages with a high attack risk according to the current vehicle state and add or enable DPI rules that monitor or protect those communications. Also, if the number of DPI rules enabled in the lower-level electronic control 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 with priority.

[0030] For example, the abnormality detection method may further determine the processing content indicated by the DPI rule depending on the vehicle state of one of the lower-level electronic control devices included in the one or more lower-level electronic control devices that is the source or destination of the message that is determined to be abnormal in the abnormality detection.

[0031] This can prevent malicious attackers from seizing control of the vehicle when an abnormality is detected based on flow information. For example, when a host electronic control unit detects an abnormality from flow information of communication with the ADAS ECU that manages the autonomous driving system, if the autonomous driving system is in operation, the host electronic control unit instructs the ADAS ECU to stop the vehicle in an emergency while ensuring the safety of the vehicle. In this case, by enabling a DPI rule that prohibits unauthorized communication with the electronic control unit required to stop the vehicle in an emergency, attacks on the electronic control unit involved in stopping the vehicle can be suppressed until the vehicle stops.

[0032] For example, the abnormality detection method may further select, from the one or more lower-level electronic control devices, a first electronic control device that is the sender of the target message to be monitored according to the DPI rule and a second electronic control device that is the destination of the message, select, from the one or more higher-level electronic control devices, at least one third electronic control device that is located between the first electronic control device and the second electronic control device and through which the target message passes, and apply the DPI rule to the electronic control device that has the smallest processing load for message processing among the selected first electronic control device, the second electronic control device, and the at least one third electronic control device.

[0033] This makes it possible to prevent the number of DPI rules that are enabled for one electronic control unit from exceeding the message processing capacity, thereby realizing the prevention of processing slowdowns in each electronic control unit.

[0034] For example, the abnormality detection method may further calculate the communication volume of each of the first electronic control unit, the second electronic control unit, and the at least one third electronic control unit based on the flow information, and calculate the processing load volume from one or more DPI rules enabled in the one or more lower-level electronic control units and the communication volume.

[0035] As a result, by distributing and enabling the DPI rules among a plurality of electronic control units, it is possible to prevent processing slowdowns caused by the DPI rules being concentrated in one electronic control unit.

[0036] For example, the abnormality detection method may further apply the DPI rule to the third electronic control unit that is closest to the first electronic control unit among the at least one third electronic control unit if the abnormality detected by the abnormality detection is an abnormality that places a load on the in-vehicle network.

[0037] This allows for messages to be monitored by a higher-level electronic control unit close to the electronic control unit that sends the abnormal message, thereby reducing the load on the network.For example, when a flooding attack is detected using anomaly detection based on flow information, the higher-level electronic control unit close to the source electronic control unit can monitor payload information and immediately drop the abnormal message if an abnormality is confirmed.This prevents communications that strain the network from flowing outside the network between the source electronic control unit and the higher-level electronic control unit.

[0038] For example, the abnormality detection method may further include monitoring a message in the host electronic control unit using the DPI rule.

[0039] This allows messages to be monitored using the DPI rule not only in the lower-level electronic control unit but also in the higher-level electronic control unit, thereby improving the accuracy of abnormality detection.

[0040] Moreover, an anomaly detection device according to one aspect of the present disclosure is an anomaly detection device included in a higher-level electronic control device in an in-vehicle network having a hierarchical structure including an upper-level network in which one or more higher-level electronic control devices are arranged and a lower-level network in which one or more lower-level electronic control devices are arranged, and includes: a collection unit that collects flow information, which is statistical information for each flow classified by header information of messages received at a predetermined observation point in the in-vehicle network; an anomaly detection unit that performs anomaly detection based on the flow information; and a control unit that generates, adds, deletes, changes, enables, or disables a DPI (Deep Packet Inspection) rule based on the result of the anomaly detection, wherein the DPI rule is used to monitor the messages in the one or more lower-level electronic control devices, and the DPI rule indicates conditions for header information and payload information included in the message and processing content to be performed when a message that matches the conditions is received.

[0041] Furthermore, a program according to an aspect of the present disclosure causes a computer to execute an anomaly detection method.

[0042] 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.

[0043] 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.

[0044] [Overall Configuration Diagram of In-Vehicle Network System] Fig. 1 is an overall configuration diagram of an in-vehicle network system 10 according to a first embodiment. In Fig. 1, the in-vehicle network system 10 is mounted on a vehicle. The in-vehicle network system 10 includes zone ECUs (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.

[0045] 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.

[0046] 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. Each zone ECU is connected to its own zone and acquires information from and controls the ECUs in that zone.

[0047] 2 is a diagram showing the configuration of the zone ECU 100a. Note that the zone ECUs 100b and 100c have the same configuration as the zone ECU 100a, and therefore their description will be omitted.

[0048] In FIG. 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 memory unit 106, and an ECU management list storage unit 107.

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

[0050] The DPI unit 102 monitors the payload information of packets based on a monitoring rule specified by the DPI rule. For example, when communication between two or more ECUs, including broadcast communication, is performed via a zone ECU, the DPI rule applies, which performs processing such as dropping abnormal communication in the DPI unit 102 or recording a communication log.

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

[0052] 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.

[0053] The DPI control unit 105 controls the DPI rules that are enabled by the DPI unit 102. The DPI control unit 105 includes a DPI rule generation unit 105A, a DPI rule transfer unit 105B, and a DPI alert processing unit 105C.

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

[0055] 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 to that ECU.

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

[0057] The all-DPI rule storage unit 106 stores the DPI rules of the DPI units of all ECUs present in the in-vehicle network system 10. The ECU management list storage unit 107 stores a list that compiles the ECUs present in the in-vehicle network system 10, the service information handled by each ECU, and the zone ECUs that manage the zones to which the ECUs belong.

[0058] 3 is a block diagram of the ADAS ECU 200a. Note that 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 have the same configuration as the ADAS ECU 200a, and therefore descriptions thereof will be omitted.

[0059] 3, the ADAS ECU 200a includes a communication port unit 201, a DPI unit 202, and an application unit 203. The communication port unit 201 is an Ethernet communication interface, and transmits and receives frames.

[0060] The DPI unit 202 monitors packet payload information based on monitoring rules specified by DPI rules distributed from the zone ECU. If a received packet matches the check contents of a DPI rule, the DPI unit 202 sends an alert to the zone ECU to which the DPI rule was distributed, as necessary. The DPI unit 202 has the same functions as the DPI unit 102 of the zone ECU 100a. Therefore, for example, if the DPI unit 202 determines that a received packet is an abnormal packet, a DPI rule is applied that performs processing such as dropping the abnormal communication or recording a communication log. The application unit 203 executes an ECU-specific application according to the received communication frame.

[0061] [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.

[0062] FIG. 4 shows an example of a message format used in the SOME / IP SD. The message format in FIG. 4 is stored in the Ethernet payload section and communicated. Each line in the figure contains 32 bits of data, with the SOME / IP header stored in the first half and the SOME / IP SD payload stored in the second half. In the 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 field stores the combined value of the Client ID and Session ID. In the 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.

[0063] Fig. 5 shows an example of a SOME / IP SD message. Flags is set to 0x80, and the Reboot Flag is set. The Reserved area is set to 0. The Length of Entries Array in Bytes stores the number of bytes of the entry, which is set to 16 bytes in Fig. 5.

[0064] 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. Offer is used when a server ECU providing a service notifies that the service is available. In Figure 5, the Type is 0x01, indicating that the message is a message in which the server ECU notifies information about the services it can provide.

[0065] Index 1st options indicates the position of the first option. In Fig. 5, Index 1st options is 0, which indicates that the position of the first option is the beginning of the option area. Index 2nd options indicates the position of the second option, which is 0 in Fig. 5.

[0066] The number of option 1 is written in #of opt1, and in FIG. 5, 1 is stored. 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 that indicates the type of service, and in Fig. 5, 0x1000 is stored in the Service ID. The Instance ID is a field that stores an ID that indicates an instance of the service, and in Fig. 5, 0x0001 is set.

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

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

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

[0071] The byte length of the Option area is stored in the Length of Options Array in Bytes included in the Option area, and FIG. 5 shows that the byte length of the Option area is 12 bytes.

[0072] The value of Length is set according to the type of option. Fig. 5 shows an example of communication using IPv4, where Length is set to 9, Type is set to 0x04, and Reserved is set to 0x00. The IPv4 address is the IP address of the server, and in Fig. 5 it is set to 192.168.0.1.

[0073] The Reserved area stores 0. L4-Proto stores 0x11, indicating that User Datagram Protocol (UDP) is used. Finally, the port number is stored, and Figure 5 shows that port 35000 is used.

[0074] 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.

[0075] Fig. 7 is a diagram showing an example of a SOME / IP message. Service ID is a field that stores an ID that indicates the type of service, and in Fig. 7, 0x0001 is stored in the Service ID.

[0076] 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. In FIG. 7, 0x0301 is stored in the Method ID.

[0077] The Length field stores the message length from the Client ID to the Payload field. In Fig. 7, this field is set to 1408 bytes. The Client ID field is an identifier for identifying the calling client within the ECU, and is set to 0x01000 in Fig. 7.

[0078] The Session ID is an identifier that distinguishes messages sent from the same sender, and is set to 0x0011 in Fig. 7. The Protocol Version indicates the protocol version of SOME / IP, and is set to 0x01 in Fig. 7.

[0079] The Interface Version indicates the major version of the service I / F and is set to 0x01 in Fig. 7. The Message Type indicates the message type of SOME / IP. In Fig. 7, the Message Type is set to 0x02, which indicates that the message type is Notification.

[0080] Return Code represents a return value indicating whether the request has been processed normally, and is set to 0x00 in Fig. 7. Payload describes the information that the sender wants to send.

[0081] [Example of Flow Information Collected by Zone ECU] FIG. 8 shows an example of flow information collected by the flow information collection unit 103 of the zone ECU. Flow information is generated by calculating statistical information at regular intervals from packet header information and the like. In FIG. 8, the flow information is calculated at 30-second intervals. In the flow information, a combination of a 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) is assigned to a flow ID, which is identification information. Statistical information is also compiled for each flow ID. In FIG. 8, the number of packets communicated, the average packet arrival interval, and the average packet length are compiled for each flow ID.

[0082] [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) stored in the all DPI rule memory unit 106 that lists all DPI rules applied to ECUs on the in-vehicle network.

[0083] 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 that have already been monitored, and a processing priority.

[0084] The target ECU is an ECU equipped with a DPI unit that actually executes the generated DPI rule. In the list of all DPI rules in Figure 9, the DPI rules are listed based on the target ECU. Rule numbers are assigned to the DPI rules for DPI rule management.

[0085] The DPI rule name is determined according to the role of the DPI rule. For example, for a DPI rule 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."

[0086] The issuing ECU is set to the zone ECU that created the DPI rule and transferred the created DPI rule to the applicable ECUs. The issuing ECU is determined according to the ECU management list.

[0087] The header condition indicates 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. If all items in the header condition match, the payload is monitored and the check contents are confirmed.

[0088] The check content indicates the content to be checked when monitoring the payload of packets that satisfy the header conditions. For example, in the case of SOME / IP communication 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. Therefore, the source ECU of the abnormal packet is determined to be the attacking ECU, and it is checked whether the packets sent from the source ECU have only one type of Service ID. Furthermore, in the case of SOME / IP communication that may be the result of a spoofing attack, it is checked whether the communication is being performed using the correct Client ID.

[0089] The check operation indicates the operation when the monitored packet satisfies the check contents. For example, if a packet matches the check contents of the flooding monitor shown in Figure 9, the source ECU of the monitored communication is not an ECU that communicates using only one type of Service ID. In other words, the source ECU is determined to be a normal ECU, and this fact is notified to the zone ECU that issued the DPI rule. Also, if a packet matches the check contents of the spoofing monitor shown in Figure 9, it is determined that communication is being performed using a false IP address and port number, so the packet is blocked and the number of monitored packets is set to unlimited.

[0090] The number of monitored packets indicates the upper limit of the number of packets monitored by that DPI rule. The number of monitored packets indicates the number of packets that the DPI unit has already monitored by that DPI rule. When the number of monitored packets for a DPI rule reaches the specified number of monitored packets, the DPI units 102 and 202 discard that DPI rule. In addition, the zone ECU can grasp 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.

[0091] The processing priority is a parameter for determining the order in which a packet header is compared with the header conditions included in a DPI rule when two or more DPI rules are applied to the DPI unit 102 or 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 header of a received packet with the header conditions included in the DPI rule, starting with the DPI rule with the highest processing priority. The DPI units 102 and 202 of each ECU store the DPI rules in descending order of processing priority.

[0092] [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 (management zone ECU) present in the same zone as the ECU as the manager. A zone ECU transfers the DPI rules generated by the DPI rule generation unit 105A to an ECU under its own management only if the destination of the DPI rules is an ECU under its own management.

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

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

[0095] [Processing Sequence] Figure 11 is a processing sequence diagram when an attack occurs from the steering wheel control ECU 200c to the ADAS ECU 200a in Embodiment 1. In Figure 11, the zone ECUs 100b and 100c collect flow information using the flow information collection unit 103, perform anomaly detection using the flow-based anomaly detection unit 104, and generate DPI rules using the DPI rule generation unit 105A based on the results. The DPI units 102 and 202 of the ADAS ECU 200a apply the generated DPI rules, and security measures are taken based on the monitoring results of the DPI unit 202.

[0096] The steering wheel control ECU 200c performs a flooding attack on the ADAS ECU 200a (S101). The zone ECUs 100a and 100b, which are 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).

[0097] The zone ECUs 100a, 100b, and 100c share the collected flow information among themselves (S103). Note that the processing of the zone ECU 100c is not shown in FIG.

[0098] 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). Based on the results of the flow-based anomaly detection, the zone ECUs 100a, 100b, and 100c each generate a first DPI rule for monitoring communications (S105).

[0099] Since the zone ECU 100b determines from the ECU management list that the generated first DPI rule is not applied to an ECU that it manages, the zone ECU 100b stores the first DPI rule in the all DPI rule storage unit 106 (S106).

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

[0101] The ADAS ECU 200a receives the first DPI rule from the zone ECU 100a and applies the received first DPI rule to the DPI unit 202 (S108). The steering wheel control ECU 200c continues to perform a flooding attack on the ADAS ECU 200a (S109).

[0102] The ADAS ECU 200a monitors communication with the steering wheel control ECU 200c using the applied first DPI rule (S110). The ADAS ECU 200a generates a DPI alert in accordance with the monitoring result of the DPI unit 202, and transmits the generated DPI alert to the zone ECU 100a (S111).

[0103] Based on the DPI alert from the ADAS ECU 200a, the zone ECU 100a officially determines that the communication from the steering wheel control ECU 200c is abnormal (S112). The zone ECU 100a generates a second DPI rule for blocking the abnormal communication from the steering wheel control ECU 200c, and transfers the generated second DPI rule to the ADAS ECU 200a and the other zone ECUs 100b and 100c (S113).

[0104] The zone ECU 100b stores the second DPI rule newly created by the zone ECU 100a in the all DPI rule storage unit 106 (S114). The ADAS ECU 200a applies the second DPI rule transferred from the zone ECU 100a (S115).

[0105] The steering wheel control ECU 200c continues to perform a flooding attack on the ADAS ECU 200a (S116). The ADAS ECU 200a blocks the abnormal communication from the steering wheel control ECU 200c in accordance with the second DPI rule (S117).

[0106] 12 is a flowchart showing the overall process from when the zone ECU receives a packet to when the zone ECU generates a DPI rule and applies it to an appropriate ECU. The communication port unit 101 receives a packet communicated via itself (S201).

[0107] The communication port unit 101 mirrors the packets and transfers them according to the destination IP address of the packets (S202). The flow information collection unit 103 extracts header information from the mirrored packets and updates the flow information (S203).

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

[0109] The communication port unit 101 transfers the output flow information to other zone ECUs (S206). The communication port unit 101 also receives 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).

[0110] 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 S210), the zone ECU ends the process.

[0111] The DPI rule generating unit 105A generates a DPI rule from the generated abnormality alert (S212), and stores the generated DPI rule in the all DPI rule storage unit 106 (S213).

[0112] The DPI rule transfer unit 105B determines whether the ECU to which the generated DPI rule is applied is its own management ECU based on the ECU management list (S214). If the application ECU 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 processing. If the application ECU is not its own management ECU (No in S214), the zone ECU ends the processing.

[0113] 13 is a flowchart of the reception process in 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.

[0114] The communication port unit 101 determines whether the packet being processed by the communication port unit 101 is a transmission packet whose source is the communication port unit 101 (S301). If the packet is a transmission packet (if S301 is Yes), the communication port unit 101 transmits the packet to the ECU with the destination IP address (S302).

[0115] If the 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).

[0116] The communication port unit 101 determines whether the received packet is addressed to itself (S304). If the packet is addressed to itself (Yes in S304), the communication port unit 101 determines whether the packet is a DPI rule transferred from another zone ECU (S305). If the packet is a DPI rule (Yes in S305), 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.

[0117] If the packet does not comply with the DPI rule (if S305 is No), the communication port unit 101 determines 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 to the DPI alert processing unit 105C (S308), and the zone ECU ends the processing.

[0118] If the packet is not a DPI alert (if S307 returns No), the received packet is flow information shared by another zone ECU. Therefore, the communication port unit 101 notifies the flow information collection unit 103 that the packet is flow information generated by another ECU (S309), and the zone ECU terminates processing. The flow information collection unit 103 updates the flow information from the packet's header information and integrates the flow information of other zones described in the packet's payload information with the flow information it has collected.

[0119] If the packet is not addressed to 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.

[0120] 14 is a flowchart showing an example of processing performed by the flow-based anomaly detection unit 104. First, the flow-based anomaly detection unit 104 receives flow information output at regular intervals (S401).

[0121] The flow-based anomaly detection unit 104 selects one flow ID included in the received flow information and extracts statistical information (e.g., the number of packets N and the average arrival interval I) for the selected flow ID (S402). Note that the processes of steps S403 to S416 are executed for the selected flow ID. In other words, the processes of steps S402 to S416 are repeatedly executed for each flow ID included in the flow information. Furthermore, this series of processes is repeatedly executed, for example, every time flow information is received.

[0122] The flow-based anomaly detection unit 104 calculates a previous ratio ΔI, which is the ratio between the average arrival interval I included in the current received flow information and the average arrival interval I included in the flow information output immediately before (S403). For example, ΔI is calculated by dividing the current average arrival interval I by the previous average arrival interval I.

[0123] The flow-based anomaly detection unit 104 calculates a previous ratio ΔN, which is the ratio between the number of packets N included in the current received flow information and the number of packets N included in the flow information output immediately before (S404). For example, ΔN is calculated by dividing the number of packets N of the current time by the number of packets N of the previous time.

[0124] The flow-based anomaly detection unit 104 determines 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 selected flow ID is undergoing a "flooding attack" (S406). In other words, if the number of packets N is equal to or greater than a predetermined threshold, the flow-based anomaly detection unit 104 determines that a "flooding attack" has occurred.

[0125] If the number of packets N is less than 10,000 (if S405 is No), the flow-based anomaly detection unit 104 determines whether the difference ΔI between the average arrival interval and the previous time is less than 1 (S407). If the difference ΔI between the average arrival interval and the previous time is less than 1 (if S407 is Yes), the flow-based anomaly detection unit 104 further determines whether the difference ΔN between the average arrival interval and the previous time is 10 or more (S408). If the difference ΔN between the average arrival interval and the previous time is 10 or more (if S408 is Yes), the flow-based anomaly detection unit 104 determines that the communication having the selected flow ID is undergoing a "flooding attack" (S406). In other words, if the average arrival interval I is decreasing and the number of packets N is increasing (ΔN is equal to or greater than a first threshold value greater than 1), the flow-based anomaly detection unit 104 determines that a "flooding attack" has occurred.

[0126] If the change in the number of packets from the previous time ΔN is less than 10 (if S408 is No), the flow-based anomaly detection unit 104 determines whether the change in the number of packets from the previous time ΔN is 2 or greater (S409). If the change in the number of packets from the previous time ΔN is 2 or greater (if S409 is Yes), the flow-based anomaly detection unit 104 determines that the communication having the selected flow ID is undergoing a "spoofing attack" (S410). In other words, if the average arrival interval I is decreasing and the number of packets N is increasing (ΔN is greater than 1 and equal to or greater than a second threshold value that is smaller than the first threshold value), the flow-based anomaly detection unit 104 determines that a "flooding attack" is occurring.

[0127] If the difference ΔI between the average arrival interval and the previous time is 1 or more, or if 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 of other flow IDs that use the same destination IP address and destination port number as the selected flow ID (S411).

[0128] The flow-based anomaly detection unit 104 determines whether a change in the order of communication has occurred (S412). Specifically, the flow-based anomaly detection unit 104 determines that a change in the order of communication has occurred when one of the number of packets N of the selected flow ID and the number of packets N of the other extracted flow ID has increased and the other has decreased.

[0129] If a change in the order of communication has occurred (if S412 is Yes), the flow-based anomaly detection unit 104 further determines whether the change in the number of packets from the previous time, ΔN, is 1 or greater (S413). If the change in the number of packets from the previous time, ΔN, is 1 or greater (if S413 is Yes), the flow-based anomaly detection unit 104 determines that the communication having the selected flow ID is communication that has increased due to a man-in-the-middle attack, and determines the result as a "man-in-the-middle attack (increase)" (S414). In other words, if a change in the order of communication has occurred and the number of packets N has increased, the flow-based anomaly detection unit 104 determines the result as a "man-in-the-middle attack (increase)."

[0130] If the ratio ΔN of the number of packets to the previous time is less than 1 (if S413 is No), the flow-based anomaly detection unit 104 determines that the communication having the selected flow ID is communication that has decreased due to a man-in-the-middle attack, and determines the result as a "man-in-the-middle attack (decrease)" (S415). In other words, if a change in communication has occurred and the number of packets N has decreased, the flow-based anomaly detection unit 104 determines the result as a "man-in-the-middle attack (decrease)".

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

[0132] After determining that the communication having the selected flow ID is a "flooding attack," "spoofing attack," "man-in-the-middle attack (increase)," "man-in-the-middle attack (decrease)," or "no abnormality," the flow-based anomaly detection unit 104 determines 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 terminates 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.

[0133] In the anomaly detection process shown in Figure 14, several specific thresholds are used to determine anomalies, but in reality, the thresholds will vary depending on the assumed communication environment. Also, in Figure 14, anomaly detection is performed using only the parameters of the number of packets and the average arrival interval, but detection accuracy can be improved by using other parameters. Furthermore, attacks other than flooding attacks, spoofing attacks, and man-in-the-middle attacks can also be detected.

[0134] 15 is a diagram showing an example of an abnormality alert generated based on the results 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.

[0135] An alert number is issued for each flow ID of an abnormal communication. 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. The flow ID represents the header information of the communication packet, and an alert is generated when the communication identified by this flow ID is deemed to be abnormal.

[0136] The type of alert indicates the result determined by flow-based anomaly detection. Man-in-the-middle attacks are detected from the correlation between two types of communications: one with an increasing number of packets and one with a decreasing number of packets, so anomaly alerts are generated for two types of flow IDs. The protocol indicates the protocol of the communication with the corresponding flow ID and is used to determine whether the communication is encrypted.

[0137] 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 assigned to the flow ID. However, only when the alert type is "Mitt-in-the-Middle Attack (Decrease)", the packet occupancy is calculated by referencing the source IP address instead of the destination IP address assigned to the flow ID.

[0138] 16 is a flowchart of the DPI rule generation process. The DPI rule generation unit 105A acquires an abnormality alert generated by the flow-based abnormality detection unit 104 (S501).

[0139] 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.

[0140] The DPI rule generation unit 105A sets the ECU to which the DPI rule is to be applied that has a destination IP address assigned to the flow ID included in the abnormality alert (S503).The DPI rule generation unit 105A extracts the packet occupancy rate of the set destination ECU from the abnormality alert, and sets the extracted packet occupancy rate as the processing priority value included in the DPI rule (S504).

[0141] The DPI rule generation unit 105A determines whether the alert type included in the abnormality 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 assigned to the flow ID included in the abnormality alert in the header condition included in the DPI rule (S506).

[0142] The DPI rule generation unit 105A then references the ECU management list to confirm the valid service ID from the flow ID (S507), and sets the check details included in the DPI rule using the confirmed service ID (S508). The DPI rule generation unit 105A sets a process for issuing an alert to the zone ECU that issued the DPI rule as the check operation included in the DPI rule (S509). The DPI rule generation unit 105A sets the number of monitoring packets included in the DPI rule to a value required for monitoring flooding attacks (a value associated with monitoring flooding attacks) (S510). The DPI rule generation unit 105A then integrates the details set up to this point into a single DPI rule (S511).

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

[0144] If the alert type is not "flooding attack" (if S505 is No), the DPI rule generation unit 105A determines whether the alert type included in the abnormal alert is "spoofing attack" (S513). If the alert type is "spoofing attack" (if S513 is Yes), the DPI rule generation unit 105A sets the flow ID included in the abnormal alert as the header condition included in the DPI rule (S514). Then, the DPI rule generation unit 105A refers to the ECU management list to confirm the legitimate client ID from the flow ID (S515), and sets the check content included in the DPI rule using the confirmed client ID (S516).

[0145] The DPI rule generation unit 105A sets, as a check operation included in the DPI rule, a process of blocking the corresponding packet and resetting its own monitoring packet count to unlimited (∞) (S517). The DPI rule generation unit 105A sets the monitoring packet count included in the DPI rule to a value required for monitoring spoofing attacks (a value associated with monitoring spoofing attacks) (S518). The DPI rule generation unit 105A then integrates the contents set up to this point into a single DPI rule (S511), requests the transfer of the DPI rule (S512), and ends the DPI rule generation process.

[0146] If the alert type is not "spoofing attack" (if S513 is No), the DPI rule generation unit 105A determines whether the alert type included in the abnormality alert 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 assigned to the flow ID included in the abnormality alert in the header condition included in the DPI rule (S520).

[0147] The DPI rule generation unit 105A then references the ECU management list to confirm the valid service ID from the flow ID (S521) and sets the check details included in the DPI rule using the confirmed service ID (S522). The DPI rule generation unit 105A sets a process for issuing an alert to the zone ECU that issued the DPI rule as a check operation included in the DPI rule (S523). The DPI rule generation unit 105A sets the number of monitoring packets included in the DPI rule to a value required for monitoring man-in-the-middle attacks (a value associated with monitoring man-in-the-middle attacks) (S524). The DPI rule generation unit 105A then integrates the details set up to this point into a single DPI rule (S511), requests the transfer of the DPI rule (S512), and ends the DPI rule generation process.

[0148] 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 included in the abnormal alert is "man-in-the-middle attack (decrease)." The DPI rule generation unit 105A estimates that the source ECU assigned to the flow ID included in the abnormal alert that has the same alert number and whose alert type is "man-in-the-middle attack (increase)" is the attacking ECU (S525). The DPI rule generation unit 105A extracts the source ECU from the flow ID included in its own abnormal alert whose alert type is "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 a header condition included in the DPI rule (S526).

[0149] The DPI rule generation unit 105A resets the target ECU included in the DPI rule to the ECU with the source IP address assigned to the flow ID (S527).The DPI rule generation unit 105A sets the check details, check operation, and number of monitored packets included in the DPI rule to the same details as the paired DPI rule, that is, the DPI rule generated from the abnormal alert with the same alert number and the alert type "man-in-the-middle attack (increase)" (S528).The DPI rule generation unit 105A then integrates the details set up to this point into a single DPI rule (S511), requests the transfer of the DPI rule (S512), and ends the DPI rule generation process.

[0150] 17 is a flowchart of DPI rule transfer. The DPI rule transfer unit 105B refers to the ECU management list and determines whether the ECU to which the DPI rule is to be applied, which is included in the generated DPI rule, is an ECU under its own control (S601).

[0151] If the destination ECU is an ECU under its own control (if S601 is Yes), the DPI rule transfer unit 105B sets the issuing ECU included in the DPI rule to itself (S602), corrects the DPI rule number so that the issuing 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.

[0152] If the target ECU is not an ECU under its own control (if S601 is No), the DPI rule transfer unit 105B refers to the ECU management list and sets the issuing ECU included in the DPI rule as the management zone ECU that manages the target ECU (S606).The DPI rule transfer unit 105B then corrects the DPI rule number so that the issuing zone ECU can be identified (S607), saves the DPI rule in the all-DPI rule storage unit 106 (S608), and ends the DPI rule transfer process.

[0153] [Example of Generated DPI Rule] Fig. 18 is a diagram showing an example of a DPI rule generated from an abnormality alert. Fig. 18 shows the DPI rule generated from the abnormality alert of Fig. 15.

[0154] The rule number is set so that the target ECU can identify the zone ECU that issued the DPI rule. In other words, the rule number is associated with the zone ECU that issued the DPI rule. For example, if the zone ECU 100b is the issuer, a number such as "B-1" combined with an alphabetic character is issued. However, for the DPI rule set for "man-in-the-middle attack monitoring," the same number is issued to the zone ECU that notifies the DPI alert.

[0155] The check contents and the actions taken during the check differ depending on the type of attack detected by flow-based anomaly detection.

[0156] For example, in a flooding attack, an attacking ECU is thought to send a large number of communication packets using only a specific service ID. Therefore, a monitoring rule for a flooding attack (flooding monitoring) checks whether only one service ID is being used. Specifically, the target ECU obtains the service ID of the communication that was found to be abnormal in flow-based anomaly detection from the ECU management list and monitors whether communication is occurring using any service ID other than that service ID. When the target ECU confirms communication using any service ID other than the corresponding service ID, it sends a DPI alert to the zone ECU that issued the DPI rule as a check operation. 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.

[0157] Furthermore, for example, as a monitoring rule for spoofing attacks (spoofing monitoring), the ECU to which the rule is applied monitors whether any communication other than that using a legitimate client ID is being performed. When the ECU to which the rule is applied detects communication using a client ID other than that used legitimate, the ECU determines that the communication is abnormal, blocks the corresponding packet as a check operation, and changes the number of packets to be monitored in the DPI rule to unlimited (∞).

[0158] Furthermore, for example, as a monitoring rule for man-in-the-middle attacks (man-in-the-middle attack monitoring), the target ECU checks whether an ECU suspected of being an attacker is simultaneously communicating with two ECUs using the same service ID. When the target ECU confirms that two ECUs to which the DPI rule is applied are communicating using a specified service ID, it notifies 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.

[0159] The number of monitored packets is determined depending on the type of 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. Therefore, in order to reduce the processing load, the number of monitored packets is set smaller for flooding monitoring than for other DPI rules.

[0160] [DPI Rule Processing Flowchart] Figure 19 is a flowchart of DPI rule processing in the DPI units 102 and 202. The processing shown in Figure 19 is performed, for example, every time a packet is received. The DPI units 102 and 202 receive a packet (S701) and select the DPI rule with the highest processing priority among the DPI rules applied to the DPI units 102 and 202 (S702). Here, the DPI units 102 and 202 previously store the DPI rules in descending order of processing priority.

[0161] The DPI units 102 and 202 determine whether the header of the received packet satisfies the header condition included in the selected DPI rule (S703).

[0162] If the received packet satisfies the header conditions included in the DPI rule (Yes in S703), the DPI units 102 and 202 determine whether the packet satisfies the check contents included in the DPI rule (S704).

[0163] If the packet satisfies the check contents included in the DPI rule (if S704 is Yes), the DPI units 102 and 202 execute the check operation included in the DPI rule (S705). If the packet does not satisfy the check contents included in the DPI rule (if S704 is No), the DPI units 102 and 202 skip the process of step S705.

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

[0165] The DPI units 102 and 202 determine 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 (if S707 is Yes), the DPI units 102 and 202 discard the DPI rule (S708), notify the zone ECU that issued the DPI rule of the end of the rule (S709), and end the DPI rule processing. If the number of monitored packets has not reached the number of monitored packets (if S707 is No), the DPI units 102 and 202 end the DPI rule processing.

[0166] If the received packet does not satisfy the header condition included in the DPI rule (if S703 is No), the DPI units 102 and 202 determine whether there are any other unprocessed DPI rules (S710). If there are any other unprocessed DPI rules (if S710 is Yes), the DPI units 102 and 202 select the DPI rule with the next highest processing priority from among the unprocessed DPI rules (S711) and return to step S703. If there are no other unprocessed DPI rules (if S710 is No), the DPI units 102 and 202 simply end the DPI rule processing.

[0167] 20 is a diagram showing an example of a DPI alert. A DPI alert is mainly notified when the number of packets monitored by the DPI rules 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.

[0168] A DPI alert includes a rule number, a DPI rule name, an ECU to which the alert applies, and alert content. The rule number indicates the rule number of the corresponding DPI rule. Therefore, by checking the rule number, the ECU can determine which DPI rule the DPI alert relates to.

[0169] The DPI rule name indicates the name of the DPI rule corresponding to the DPI alert. The applied ECU indicates the ECU to which the DPI rule corresponding to the DPI alert applies, and is used to understand which ECU notified the DPI alert.

[0170] The alert content indicates "rule end" or "check matched." A DPI alert with "rule end" as the alert content indicates that the number of packets monitored for the DPI rule has met the specified number of packets monitored.

[0171] A DPI alert containing "check met" as the alert content indicates that the check content included in the DPI rule has been met.

[0172] For example, the rule numbers "B-1" and "C-1" shown 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.

[0173] 20 indicates that the ECU to which the rule is applied has received a packet that satisfies the check contents included in the DPI rule. 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.

[0174] 21 is a flowchart of the DPI alert process in the zone ECUs 100a, 100b, and 100c. The DPI alert processor 105C receives a DPI alert (S801).

[0175] The DPI alert processing unit 105C determines whether the DPI rule name included in 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 determines 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 determines whether 100 or more DPI alerts with the same rule number and alert content "check applicable" have been received (S804).

[0176] If 100 or more "checked" DPI alerts have been received (if S804 is Yes), the DPI alert processing unit 105C can confirm that the communication is not limited to a single service ID, and therefore determines that the communication monitored by the DPI rule is normal (S805). Then, because the corresponding DPI rule has already been discarded in the ECU to which the DPI rule applies, 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 their rules.

[0177] 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.

[0178] 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.

[0179] If the DPI rule name is not "flooding monitoring" (if S802 is No), the DPI alert processing unit 105C determines 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 (S810). The DPI alert processing unit 105C then discards the corresponding DPI rule from all DPI rule storage units 106 in the zone ECU (S811).

[0180] 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."

[0181] The DPI alert processing unit 105C determines 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 determines that the communication monitored by the DPI rule is abnormal because it has been confirmed that the attacker ECU is communicating using the same service ID (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.

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

[0183] [Example of DPI rule for blocking abnormal communication] Fig. 22 is a diagram showing an example of a DPI rule for blocking abnormal communication. In Fig. 22, "abnormal communication" is shown as the name of the DPI rule.

[0184] 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, the check action specifies a process to block packets of the communication that match the specified content.

[0185] The number of monitored packets is set to unlimited (∞). This prevents the DPI unit of the ECU from arbitrarily discarding 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 be used instead.

[0186] (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.

[0187] [Overall Configuration Diagram of In-Vehicle Network System] Fig. 23 is an overall configuration diagram of the in-vehicle network system 20. 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.

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

[0189] In FIG. 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 memory unit 106, and an ECU management list storage unit 107.

[0190] The DPI control unit 1105 includes a DPI rule generation unit 1105A, a DPI rule transfer unit 1105B, and a DPI alert processing unit 1105C.

[0191] The DPI rule generation unit 1105A generates DPI rules based on the abnormality alert output by the flow-based anomaly detection unit 104 or 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 monitored packets included in the DPI rule.

[0192] The DPI rule transfer unit 1105B determines the application destination of the DPI rule generated by the DPI rule generation unit 1105A in accordance with the processing load status of each ECU, and transfers the DPI rule to the determined application destination ECU. For example, when monitoring communication between the ADAS ECU 200a and the steering wheel control ECU 200c, if the number of packets monitored by the DPI unit 202 of the ADAS ECU 200a exceeds a specified value, the generated DPI rule is transferred to the zone ECU 1100a or the zone ECU 1100b instead of the ADAS ECU 200a.

[0193] Furthermore, when determining the application destination of a DPI rule, the DPI rule transfer unit 1105B receives the number of communication packets of the ECUs that are candidates for the application destination and the number of packets monitored by the DPI unit from the flow information collection unit 103. The DPI rule transfer unit 1105B determines the application destination of the DPI rule based on this information and also calculates the processing priority.

[0194] [Processing Sequence] Figure 25 is a diagram showing a processing sequence when an attack occurs from the steering wheel control ECU 200c to the ADAS ECU 200a in Embodiment 2. In Figure 25, 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 104, 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 of each ECU, and take security measures based on the monitoring results of the applied DPI rules.

[0195] The steering wheel control ECU 200c performs a flooding attack on the ADAS ECU 200a (S901). The zone ECUs 1100a and 1100b, which are present on the communication path between the steering wheel control ECU 200c and the ADAS ECU 200a, mirror and receive packets and collect flow information (S902).

[0196] The zone ECUs 1100a, 1100b, and 1100c share the collected flow information among themselves (S903). Note that the processing of the zone ECU 1100c is not shown in FIG.

[0197] 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). Based on the results of the flow-based anomaly detection, the zone ECUs 1100a, 1100b, and 1100c generate a first DPI rule for monitoring communications (S905).

[0198] 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 the application of the generated first DPI rule, checks the processing load of each ECU from the flow information, and determines itself as the application of the DPI rule based on the confirmation results, and applies the first DPI rule (S906).

[0199] The zone ECU 1100a determines from the flow information that the generated first DPI rule is to be applied to the zone ECU 1100b (S907). Note that the method of this determination is the same as that of S906.

[0200] The steering wheel control ECU 200c continues to perform a flooding attack on the ADAS ECU 200a (S908). The zone ECU 1100b monitors the payload of packets in accordance with the first DPI rule applied to the DPI unit 102 (S909).

[0201] The zone ECU 1100b generates a DPI alert in accordance with the monitoring result of the DPI unit 102 (S910). Based on the generated DPI alert, the zone ECU 1100b officially determines that the communication of the steering wheel control ECU 200c is abnormal, and applies the second DPI rule that blocks abnormal communication to its own DPI unit 102 (S911).

[0202] The steering wheel control ECU 200c continues to perform a flooding attack on the ADAS ECU 200a (S912). The DPI unit 102 of the zone ECU 1100b blocks the abnormal communication from the steering wheel control ECU 200c to the ADAS ECU 200a in accordance with the second DPI rule (S913).

[0203] 26 is a flowchart of DPI rule generation. The DPI rule generation unit 1105A acquires an abnormality alert generated by the flow-based anomaly detection unit 104 (S1001). The DPI rule generation unit 1105A provisionally issues a rule number for the DPI rule (S1002).

[0204] The DPI rule generation unit 1105A determines whether the alert type included in the DPI alert is a "flooding attack" (S1003). If the alert type is a "flooding attack" (if S1003 is Yes), the DPI rule generation unit 1105A sets the source and destination IP addresses assigned to the flow ID included in the abnormal alert in the header condition included in the DPI rule (S1004).

[0205] The DPI rule generation unit 1105A then references the ECU management list to confirm the valid service ID from the flow ID (S1005), and sets the check details included in the DPI rule using the confirmed service ID (S1006). The DPI rule generation unit 1105A sets a process to send an alert to the zone ECU that issued the DPI rule as the check operation included in the DPI rule (S1007). The DPI rule generation unit 1105A sets the number of monitoring packets included in the DPI rule to a value required for monitoring flooding attacks (S1008). The DPI rule generation unit 1105A then integrates the details set up to this point into a single DPI rule (S1009).

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

[0207] If the alert type is not "flooding attack" (if S1003 is No), the DPI rule generation unit 1105A determines whether the alert type included in the abnormal alert is "spoofing attack" (S1011). If the alert type is "spoofing attack" (if S1011 is Yes), the DPI rule generation unit 1105A sets the flow ID included in the abnormal alert in the header condition included in 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 included in the DPI rule using the confirmed client ID (S1014).

[0208] The DPI rule generation unit 1105A sets a process to block the relevant packet and reset its own monitoring packet count to unlimited (∞) as a check operation included in the DPI rule (S1015). The DPI rule generation unit 1105A sets the monitoring packet count included in the DPI rule to a value required for monitoring spoofing attacks (S1016). The DPI rule generation unit 1105A then integrates the contents set up to this point into a single DPI rule (S1009), requests the transfer of the DPI rule (S1010), and ends the DPI rule generation process.

[0209] If the alert type is not "spoofing attack" (if S1011 is No), the DPI rule generation unit 1105A determines whether the alert type included in the abnormality alert 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 assigned to the flow ID included in the abnormality alert in the header condition included in the DPI rule (S1018).

[0210] The DPI rule generation unit 1105A then references the ECU management list to confirm the valid service ID from the flow ID (S1019) and sets the check details included in the DPI rule using the confirmed service ID (S1020). The DPI rule generation unit 1105A sets a process for notifying an alert to the zone ECU that issued the DPI rule as a check operation included in the DPI rule (S1021). The DPI rule generation unit 1105A sets the number of monitoring packets included in the DPI rule to a value required for monitoring man-in-the-middle attacks (S1022). The DPI rule generation unit 1105A then integrates the details set up to this point into a single DPI rule (S1009), requests the transfer of the DPI rule (S1010), and terminates the DPI rule generation process.

[0211] 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 included in the DPI rule is "man-in-the-middle attack (decrease)." The DPI rule generation unit 1105A estimates that the source ECU assigned to the flow ID included in the abnormal alert having the same alert number and the alert type "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 included in its own abnormal alert having 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 included in the DPI rule to the same contents as 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.

[0212] [Flowchart of DPI Rule Transfer Processing] Fig. 27 is a flowchart of the DPI rule transfer processing. The DPI rule transfer unit 1105B receives the DPI rule generated by the DPI rule generation unit 1105A (S1101).

[0213] The DPI rule transfer 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 and destination ECU of the packet to be monitored, and 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 also assumed that zone ECU 100b is the zone ECU that manages the source ECU.

[0214] The DPI rule transfer unit 1105B requests flow information for each selected ECU and calculates, for each ECU, the packet occupancy rate and the number of DPI processed packets, which is the number of packets per minute at which payload monitoring processing is performed in the DPI unit (S1103).

[0215] The DPI rule transfer unit 1105B determines whether the packet to be monitored under the DPI rule is an encrypted communication (S1104). If the packet to be monitored is an encrypted communication (if S1104 is Yes), the DPI rule transfer unit 1105B narrows down the candidates to the source ECU and destination ECU that can decrypt the encrypted communication, and determines whether the destination ECU has a greater number of DPI-processed packets than the source ECU (S1105). If the destination ECU has a greater number of DPI-processed packets than the source ECU (if S1105 is Yes), 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 DPI rule to the ECU to which the DPI rule applies (S1106). Then, the DPI rule transfer unit 1105B terminates the DPI rule transfer process.

[0216] If the number of DPI processed packets of the destination ECU is smaller than that of 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 of that ECU as the processing priority, and transfers the DPI rule to the destination ECU (S1107).The DPI rule transfer unit 1105B then terminates the DPI rule transfer process.

[0217] If the packets to be monitored are not encrypted (if S1104 is No), the zone ECU can also monitor the packets without decrypting them, so the DPI rule transfer unit 1105B determines whether the number of DPI-processed packets of the zone ECU 1100b that manages the source ECU is 10,000 or more (S1108). If the number of DPI-processed packets of the zone ECU 1100b is 10,000 or more (if S1108 is Yes), the DPI rule transfer unit 1105B determines whether the number of DPI-processed packets of the other candidate zone ECU, zone ECU 1100a, is 10,000 or more (S1109). If the number of DPI-processed packets of the zone ECU 1100a is 10,000 or more (if S1109 is Yes), monitoring on the zone ECU side is difficult, so the DPI rule transfer unit 1105B performs step S1105.

[0218] If the number of DPI processed packets in the zone ECU 1100a is less than 10,000 (if S1109 is No), monitoring is possible in the zone ECU 1100a, so the DPI rule transfer unit 1105B sets the zone ECU 1100a as the application destination of the DPI rule, sets the packet occupancy rate in that ECU as the processing priority, and transfers the DPI rule to the application destination ECU (S1110). Thereafter, the DPI rule transfer unit 1105B ends the DPI rule transfer process.

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

[0220] [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.

[0221] 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 flow information used 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 extracted flow information to the DPI rule transfer unit 1105B.

[0222] 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.

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

[0224] The presence or absence of encryption indicates whether the communication that matches the target header condition is encrypted. The presence or absence of encryption is determined based on the combination of the source ECU and the destination ECU. The communication volume of the monitored packets indicates the communication volume of packets that match the header condition communicated on the in-vehicle network system 20.

[0225] The candidate ECU indicates an ECU through which a packet to be monitored passes when communicating. The packet occupancy rate indicates the ratio (%) of the number of packets to be monitored to the number of packets communicated across all candidate ECUs. In other words, the packet occupancy rate indicates the proportion of packets to be monitored among the total number of packets communicated across all candidate ECUs. When the candidate ECU is determined, this value is set as the processing priority of the DPI rule.

[0226] The number of DPI processed packets indicates the number of packets whose payloads are currently being monitored by the DPI unit of the candidate ECU according to the DPI rules. 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. For example, the number of DPI processed packets may be the number of times the DPI units 102 and 202 perform a header check on the received packets against the DPI rules.

[0227] [Example of DPI rule whose application destination is dynamically changed] Figure 29 is a diagram showing an example of a DPI rule whose application destination is dynamically changed. For example, in the case of rule number "B-11" shown in Figure 29, the DPI rule is applied to the 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 with rule number "B-12" are generated. One is applied to the zone ECU 1100c, and the other is applied to the brake control ECU 200d.

[0228] Third Embodiment Hereinafter, an anomaly detection device (anomaly detection system) for a vehicle equipped with an in-vehicle network (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.

[0229] [Overall Configuration Diagram of In-Vehicle Network System] Fig. 30 is an overall configuration diagram of the in-vehicle network system 30. In Fig. 30, the in-vehicle network system 30 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 2100a, 2100b, and 2100c.

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

[0231] In Figure 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, a total DPI rule memory unit 106, an ECU management list storage unit 107, a safety judgment unit 2108, and a safety monitoring DPI rule list storage unit 2109.

[0232] The DPI control unit 2105 includes a DPI rule generation unit 2105A, a DPI rule transfer unit 2105B, and a DPI alert processing unit 2105C.

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

[0234] 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, the safety determination unit 2108 instructs the DPI rule generation unit 2105A to generate a DPI rule that monitors communication of the ECU having that function.

[0235] 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 and generates a DPI rule using the template.

[0236] [Safety Monitoring DPI Rule List] Figure 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. A DPI rule stored in the safety monitoring DPI rule list includes a DPI rule name, a header condition, check details, an operation at the time of checking, and the number of packets to be monitored. The DPI rule generation unit 2105A requests the safety monitoring DPI rule list storage unit 2109 for the necessary DPI rules in accordance with an instruction from the safety determination unit 2108.

[0237] In the example shown in Figure 32, two types of DPI rules, with the DPI rule names emergency stop system monitoring and rear monitor monitoring, are stored. The DPI rule for emergency stop system monitoring 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. This DPI rule is used to determine whether a malicious ECU is conducting malicious communication through a spoofing attack on a control system ECU or sensor ECU that is used to bring the vehicle to an emergency stop. Therefore, if the communication does not use a legitimate client ID, the packet is blocked, and the vehicle's functions are protected.

[0238] 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). This DPI rule monitors whether any communication other than that with a legitimate client ID is being performed on the rearview monitor that the driver looks at to check behind them while parking, and communication packets with an invalid client ID are blocked by the DPI units 102 and 202.

[0239] [Processing Sequence] Figure 33 is a diagram showing a processing sequence when an attack occurs from the steering wheel control ECU 200c to the ADAS ECU 200a in embodiment 3. In Figure 33, a DPI rule is applied that monitors the operation of the emergency stop system and communication of its functions, and security measures are taken based on the monitoring results of the DPI unit.

[0240] The ADAS ECU 200a starts automatic driving and reports this to the zone ECUs 2100a, 2100b, and 2100c (S1201). The shift lever ECU 200e periodically reports the state of the shift lever to the zone ECUs 2100a, 2100b, and 2100c (S1202). Note that the processing of the zone ECU 2100c is not shown in FIG.

[0241] The steering wheel control ECU 200c spoofs the ADAS ECU 200a and attacks the ADAS ECU 200a (S1203). The zone ECUs 2100a and 2100b, which are 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).

[0242] The zone ECUs 2100a, 2100b, and 2100c share the collected flow information among themselves (S1205). 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).

[0243] The zone ECUs 2100a, 2100b, and 2100c perform a safety determination to determine whether the content of the abnormality alert generated by the flow-based abnormality detection threatens the safety of the vehicle (S1207). Specifically, the zone ECUs 2100a, 2100b, and 2100c perform the safety determination by comparing the content of the abnormality alert with the vehicle status reported from the ADAS ECU 200a and the shift lever ECU 200e.

[0244] As a result of the safety assessment, the zone ECU 2100a determines that there is a risk in continuing the autonomous driving, and after performing an emergency stop, sends a command to the ADAS ECU 200a to stop the autonomous driving system (S1208).

[0245] 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). To safely operate the emergency stop system, the zone ECU 2100a distributes DPI rules for monitoring whether unauthorized communication is occurring to the ECUs involved in the emergency stop (S1210).

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

[0247] The steering wheel control ECU 200c continues to perform the spoofing attack on the ADAS ECU 200a (S1212). The ADAS ECU 200a blocks the abnormal communication from the steering wheel control ECU 200c in accordance with the DPI rules (S1213).

[0248] 34 is a flowchart of the processing performed when a zone ECU receives a packet in embodiment 3. The communication port unit 101 mirrors and receives packets communicated through itself (S1301). The flow information collection unit 103 extracts header information from the received packets and updates the flow information (S1302).

[0249] The flow information collection unit 103 determines whether the specified time for collecting flow information has passed (S1303). If the specified time has passed (Yes in S1303), the flow information collection unit 103 outputs the flow information (S1304). If the specified time has not passed (No in S1303), the flow information collection unit 103 returns to the first step S1301.

[0250] The communication port unit 101 transfers the output flow information to other zone ECUs (S1305). The communication port unit 101 also receives 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).

[0251] 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 S1309), the zone ECU ends the process.

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

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

[0254] 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 an action to ensure safety (S1313) and 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.

[0255] The DPI rule generating unit 2105A generates a DPI rule from the generated abnormality alert (S1315), and stores the generated DPI rule in the all DPI rule storage unit 106 (S1316).

[0256] The DPI rule transfer unit 2105B determines whether the ECU to which the generated DPI rule is applied is its own management ECU based on the ECU management list (S1317). If the application ECU 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 processing. If the application ECU is not its own management ECU (No in S1317), the zone ECU ends the processing.

[0257] 35 is a flowchart of the safety determination process. The safety determination unit 2108 determines whether there is an abnormality alert from the flow-based anomaly detection unit 104 (S1401). If there is an abnormality alert (Yes in S1401), the safety determination unit 2108 determines whether the communication that is the subject of the abnormality alert is communication with the ADAS ECU 200a (S1402).

[0258] If the communication for which the abnormality alert is issued is with the ADAS ECU 200a (if S1402 is Yes), the safety determination unit 2108 determines 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).

[0259] If the vehicle is not in autonomous driving mode (if S1403 is No), the safety determination unit 2108 determines 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).

[0260] If the shift lever is not in D shift (if S1406 is No), the safety determination unit 2108 determines 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.

[0261] If the communication for which the abnormality alert is issued is not with the ADAS ECU 200a (if No in S1402), the safety determination unit 2108 determines whether the communication for which the abnormality alert is issued is with the IVI ECU 200b (S1410). If the communication for which the abnormality alert is issued is with the IVI ECU 200b (if Yes in S1410), the safety determination unit 2108 determines 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).

[0262] If the communication for which the abnormality alert is issued is not communication with the IVI ECU 200b (if No in S1410) or if the shift lever is not in the reverse shift position (if No in S1411), the safety determination unit 2108 ends the safety determination process. If there is no abnormality alert from the flow-based abnormality detection unit 104 (if No in S1401), the safety determination unit 2108 ends the safety determination process.

[0263] [Flowchart of DPI rule generation process for safety monitoring] Fig. 36 is a flowchart of the process by the DPI rule generation unit 2105A in embodiment 3. The DPI rule generation unit 2105A receives an instruction to generate a DPI rule from the safety determination unit 2108 (S1501).

[0264] The DPI rule generation unit 2105A determines 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 the safety monitoring DPI rule list storage unit 2109 for a DPI rule for monitoring the emergency shutdown system, and acquires the DPI rule for monitoring the emergency shutdown system (S1503).

[0265] The DPI rule generation unit 2105A requests the DPI rule transfer unit 2105B to determine the application destination of the DPI rule for emergency shutdown system monitoring, determine the processing priority, and transfer the DPI rule to the application destination (S1504), and then ends the processing.

[0266] 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 and acquires the DPI rule for monitoring the rearview monitor (S1505).The DPI rule generation unit 2105A then requests the DPI rule transfer unit 2105B to determine an application destination of the DPI rule for safety monitoring, determine a processing priority, and transfer the DPI rule to the application destination (S1504), and ends the processing.

[0267] [Example of Safety Monitoring DPI Rule] Figure 37 is a diagram showing an example of a generated safety monitoring DPI rule. The DPI rule shown in Figure 37 is a DPI rule for monitoring an emergency stop system that is generated when an abnormality occurs in the ADAS ECU 200a during autonomous driving. Therefore, the issuer of the DPI rule is the zone ECU 2100a that manages the ADAS ECU 200a. The processing priority of each DPI rule is calculated by the DPI rule transfer unit 2105B. Furthermore, the DPI rule is transferred by the DPI rule transfer unit 2105B.

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

[0269] (1) In the above embodiment, an example in which Ethernet is used for the in-vehicle network is shown, but this is not limiting. For example, the in-vehicle network may use CAN, CAN-FD (Flexible-Data), Ethernet, LIN, or FlexRay (registered trademark), or a combination of two or more of these.

[0270] (2) In the above embodiment, the flow information is collected by the zone ECU, but the flow information may be collected by a device other than the zone ECU. For example, the flow information may be collected by a head unit, a central ECU, an Ethernet switch, or the like.

[0271] (3) In the above embodiment, a set of a source IP address, a destination IP address, a source port number, a destination port number, and a protocol number was used as information for identifying a flow, but the information for identifying a flow is not limited to these. For example, a V-LAN ID used in a virtual LAN may be used as information for identifying a flow in addition to these, or in place of at least a part of these. Furthermore, when CAN communication or the like is used, a CAN ID, which is an identifier for communication data, may be used as information for identifying a flow. This makes flow definition more flexible and enables the collection of flow information appropriate for the network.

[0272] (4) In the above embodiment, the number of packets and the average arrival interval are used as flow information for flow-based anomaly detection, but the flow information for flow-based anomaly detection is not limited to these. For example, the average packet length or a timestamp may be used.

[0273] (5) In the above embodiment, the DPI, which is a payload-based anomaly detection function, is used after the flow-based anomaly detection. However, a function other than the DPI may be used. For example, an AI-based anomaly detection function may be used.

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

[0275] (7) In the above embodiment, a DPI rule is discarded when a specified number of packets have been monitored, but the condition for discarding a DPI rule is not limited to this. For example, a DPI rule may be discarded when a certain time has elapsed since the DPI rule was applied, or a DPI rule with a lower monitoring priority may be discarded when the number of DPI rules applied to the DPI unit exceeds a specified number.

[0276] (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, can decrypt the encrypted packet, the DPI rules may also be applied to other ECUs, including the zone ECU.

[0277] (9) In the above embodiment, an example is shown in which the safety monitoring DPI rule is applied when the flow-based anomaly detection unit detects an anomaly in communication between the ADAS ECU and the IVI ECU. However, the communication for which an anomaly is detected is not limited to this. For example, a similar process may be applied when an anomaly is detected in communication between any control system ECU or sensor system ECU and another any control system ECU or sensor system ECU. Furthermore, a similar process may be applied when two or more anomalies are detected in a combination of these.

[0278] (10) In the above embodiment, the shift lever state and whether the vehicle is in automatic driving mode are referenced as the vehicle state, but the referenced vehicle state is not limited to this. For example, the referenced vehicle state may include at least one of automatic parking, cruise control, software update, vehicle diagnosis, and internet connection. Furthermore, at least one of creating, adding, changing, enabling, and disabling a DPI rule may be performed by referring to such a vehicle state.

[0279] (11) In the above embodiment, the destination to which the DPI rule is applied is determined based on the number of packets processed by the DPI unit. However, the method of determining the destination to which the DPI rule is applied is not limited to this. For example, the destination to which the DPI rule is applied may be determined based on the anomaly detection result by the flow-based anomaly detection unit. For example, if the flow-based anomaly detection unit detects a flooding attack, priority is given to applying the DPI rule to zone ECUs that are closer to the source ECU. This allows the zone ECU to drop abnormal packets when the DPI unit detects an anomaly.

[0280] (12) Some or all of the components constituting each device in the above embodiments 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. 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 within 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.

[0281] (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.

[0282] (14) One aspect of the present disclosure may be a program (computer program) that implements the anomaly detection method on a computer, or a digital signal comprising the computer program. Furthermore, one aspect of the present disclosure may be a computer-readable recording medium for the computer program or digital signal, such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray (registered trademark) Disc), or semiconductor memory. Another aspect of the present disclosure may be a digital signal recorded on such a recording medium. Another aspect of the present disclosure may be a computer program or digital signal transmitted via a telecommunications line, a wireless or wired communication line, a network such as the Internet, or data broadcasting. Another aspect of the present disclosure may be a computer system including a microprocessor and memory. The memory may store the computer program, and the microprocessor may operate according to the computer program. Furthermore, one aspect of the present disclosure may be implemented by another independent computer system by recording a program or digital signal on a recording medium and transferring it, or by transferring the program or digital signal via a network or the like.

[0283] (15) The scope of the present disclosure also includes configurations that are realized by arbitrarily combining the components and functions shown in the above embodiments and modifications.

[0284] 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.

[0285] 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 wheel control ECU 200d Brake control ECU 200e Shift lever ECU 200f Camera ECU 200g LiDAR ECU 203 Application unit 2108 Safety determination unit 2109 Safety monitoring DPI rule list storage unit

Claims

1. A method for detecting an anomaly by a higher-level electronic control device in an in-vehicle network having a hierarchical structure including a higher-level network in which one or more higher-level electronic control devices are arranged and a lower-level network in which one or more lower-level electronic control devices are arranged, comprising: collecting flow information, which is statistical information for each flow classified by header information of messages received at specified observation points in the in-vehicle network; detecting an anomaly based on the flow information; and generating, adding, deleting, changing, enabling or disabling a DPI (Deep Packet Inspection) rule based on a result of the anomaly detection; the DPI rule is used to monitor the messages in the one or more lower-level electronic control devices; and the DPI rule indicates conditions for header information and payload information included in the messages and processing contents when a message matching the conditions is received.

2. The anomaly detection method according to claim 1, wherein the flow information includes information regarding the amount of messages received for each flow, and the anomaly detection method further includes determining, based on the information, a processing priority indicating the order of processing for monitoring the messages for each of one or more DPI rules including the DPI rule.

3. The anomaly detection method according to claim 2, further comprising determining a time for enabling monitoring of messages according to the DPI rule or an upper limit number of messages for which the monitoring of messages according to the DPI rule is performed, depending on the content of the anomaly detected by the anomaly detection and the number of messages per unit time of the messages to be monitored.

4. The anomaly detection method according to claim 1, wherein the DPI rule indicates service information or client information contained in a message transmitted and received between the one or more lower-level electronic control devices, and in the monitoring of the message, if the service information or client information of the message does not match the service information or client information indicated in the DPI rule, the message is dropped.

5. The anomaly detection method according to claim 1, further comprising the steps of: adding, modifying, enabling or disabling the DPI rules based on the monitoring results output from the one or more lower-level electronic control devices.

6. The abnormality detection method according to claim 1, further comprising the steps of: adding, changing, enabling or disabling the DPI rule depending on 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 a result of the abnormality detection.

7. The abnormality detection method according to claim 6, further comprising determining the processing content indicated by the DPI rule in accordance with the vehicle state of one of the lower-level electronic control devices included in the one or more lower-level electronic control devices that is the source or destination of the message determined to be abnormal in the abnormality detection.

8. The anomaly detection method according to claim 1, further comprising the steps of: selecting, from the one or more lower-level electronic control devices, a first electronic control device that is the sender of a message to be monitored in accordance with the DPI rule and a second electronic control device that is the destination of the message; selecting, from the one or more higher-level electronic control devices, at least one third electronic control device that is disposed between the first electronic control device and the second electronic control device and through which the message of interest passes; and applying the DPI rule to an electronic control device that has the smallest processing load for message processing among the selected first electronic control device, second electronic control device and at least one third electronic control device.

9. The anomaly detection method according to claim 8, further comprising the steps of: calculating the communication volume of each of the first electronic control unit, the second electronic control unit and the at least one third electronic control unit based on the flow information; and calculating the processing load volume from one or more DPI rules enabled in the one or more lower-level electronic control units and the communication volume.

10. The anomaly detection method according to claim 8, further comprising the steps of: if the anomaly detected in the anomaly detection is an anomaly that places a load on the in-vehicle network, applying the DPI rule to a third electronic control unit, among the at least one third electronic control unit, that is closest to the first electronic control unit.

11. The anomaly detection method according to claim 1, further comprising: monitoring a message in the host electronic control device using the DPI rule.

12. An anomaly detection device included in a higher-level electronic control device in an in-vehicle network having a hierarchical structure including a higher-level network in which one or more higher-level electronic control devices are arranged and a lower-level network in which one or more lower-level electronic control devices are arranged, comprising: a collection unit that collects flow information, which is statistical information for each flow classified by header information of messages received at a specified observation point of the in-vehicle network; an anomaly detection unit that performs anomaly detection based on the flow information; and a control unit that generates, adds, deletes, changes, enables, or disables a DPI (Deep Packet Inspection) rule based on a result of the anomaly detection, wherein the DPI rule is used to monitor the messages in the one or more lower-level electronic control devices, and the DPI rule indicates conditions for header information and payload information included in the messages and processing contents when a message matching the conditions is received.

13. A program for causing a computer to execute the anomaly detection method according to claim 1.

Images