[go: up one dir, main page]

WO2025028500A1 - 異常検知方法、異常検知装置及びプログラム - Google Patents

異常検知方法、異常検知装置及びプログラム Download PDF

Info

Publication number
WO2025028500A1
WO2025028500A1 PCT/JP2024/027060 JP2024027060W WO2025028500A1 WO 2025028500 A1 WO2025028500 A1 WO 2025028500A1 JP 2024027060 W JP2024027060 W JP 2024027060W WO 2025028500 A1 WO2025028500 A1 WO 2025028500A1
Authority
WO
WIPO (PCT)
Prior art keywords
dpi
ecu
rule
electronic control
dpi rule
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/JP2024/027060
Other languages
English (en)
French (fr)
Inventor
有貴 加賀
剛 岸川
良浩 氏家
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Management Co Ltd
Original Assignee
Panasonic Intellectual Property Management Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Management Co Ltd filed Critical Panasonic Intellectual Property Management Co Ltd
Publication of WO2025028500A1 publication Critical patent/WO2025028500A1/ja
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/026—Capturing of monitoring data using flow identification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation

Definitions

  • This disclosure relates to a device for detecting communication anomalies and a method for detecting communication anomalies in an in-vehicle network system.
  • ECUs Electronic Control Units
  • CAN Control Area Network
  • Non-Patent Document 1 As an anomaly detection method for monitoring malicious attackers, for example, the method described in Non-Patent Document 1 is known.
  • IPFIX IP Flow Information Export Protocol for Exchange of Flow Information
  • the purpose of this disclosure is to provide an anomaly detection method and an anomaly detection device that can appropriately balance detection accuracy and processing volume.
  • an anomaly detection method 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, and the method includes: collecting 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; detecting an anomaly 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 message 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 when a message matching the conditions is received.
  • DPI Deep Packet Inspection
  • This disclosure provides an anomaly detection method and an anomaly detection device that can appropriately balance detection accuracy and processing volume.
  • FIG. 1 is an overall configuration diagram of an in-vehicle network system according to the first embodiment.
  • FIG. 2 is a block diagram of the zone ECU in the first embodiment.
  • FIG. 3 is a block diagram of the ADAS ECU in embodiment 1.
  • Figure 4 is a diagram showing the message format of SOME/IP SD in embodiment 1.
  • Figure 5 is a diagram showing an example of a SOME/IP SD message in embodiment 1.
  • FIG. 6 is a diagram showing a message format of SOME/IP in the first embodiment.
  • FIG. 7 is a diagram showing an example of a SOME/IP message in the first embodiment.
  • FIG. 8 is a diagram showing an example of flow information collected by the zone ECU in the first embodiment.
  • FIG. 9 is a diagram showing an example of a list of all DPI rules according to the first embodiment.
  • FIG. 10 is a diagram showing an example of a management list of an ECU in the first embodiment.
  • FIG. 11 is a diagram showing a sequence from flow information collection to anomaly detection and security response in the first embodiment.
  • FIG. 12 is a flowchart of a DPI rule generation process performed by the zone ECU in the first embodiment.
  • FIG. 13 is a flowchart of a receiving process by the communication port unit in the first embodiment.
  • FIG. 14 is a flowchart illustrating an example of a process performed by the flow-based anomaly detection unit according to the first embodiment.
  • FIG. 15 is a diagram showing an example of an abnormality alert in the first embodiment.
  • FIG. 16 is a flowchart of the DPI rule generation process in the first embodiment.
  • FIG. 17 is a flowchart of the DPI rule transfer process in the first embodiment.
  • FIG. 18 is a diagram showing an example of a DPI rule generated from an abnormality alert in the first embodiment.
  • FIG. 19 is a flowchart of the DPI rule process in 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 the DPI alert process in the zone ECU in the first embodiment.
  • FIG. 22 is a diagram showing an example of a DPI rule for blocking abnormal communication in the first embodiment.
  • FIG. 23 is a diagram showing the overall configuration of an in-vehicle network system according to the second embodiment.
  • FIG. 23 is a diagram showing the overall configuration of an in-vehicle network system according to the second embodiment.
  • FIG. 24 is an overall configuration diagram of a zone ECU in the second embodiment.
  • FIG. 25 is a diagram showing a sequence from flow information collection to anomaly detection and security response in the second embodiment.
  • FIG. 26 is a flowchart of a DPI rule generation process in the second embodiment.
  • FIG. 27 is a flowchart of a process performed by the DPI rule transfer unit in the second embodiment.
  • FIG. 28 is a diagram showing an example of flow information requested to determine a destination to which a DPI rule is applied 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 the overall configuration of an in-vehicle network in the third embodiment.
  • FIG. 30 is a diagram showing the overall configuration of an in-vehicle network in the third embodiment.
  • FIG. 31 is a diagram showing the 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 the zone ECU in the third embodiment.
  • FIG. 35 is a flowchart of a process performed by the safety determining unit in the third embodiment.
  • FIG. 36 is a flowchart of a process performed by a DPI rule generating 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.
  • control frames are transmitted and received to instruct the vehicle to run, stop, turn, etc. 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 a specific control frame from being received, there is a problem that not only the driver of the vehicle but also pedestrians around the vehicle are put at risk.
  • DPI Deep Packet Inspection
  • IPFIX As a method for monitoring the entire network, for example, there is a specification called IPFIX, which is described in Non-Patent Document 1.
  • IPFIX multiple frames flowing over an Ethernet are classified by an Ethernet switch based on information contained in the Ethernet or TCP/IP header, and statistical information called flow information is generated. Then, an anomaly detection device higher up than the Ethernet switch monitors the flow information, making it possible to monitor the entire network with low amounts of calculation and communication.
  • anomaly detection methods that use flow information do not monitor packet payload information, so there is a risk of false positives.
  • flow information is generated by collecting statistical information from packet header information. Anomalies are then detected from time changes in the flow information in a higher-level anomaly detection device, and payload-based monitoring rules are enabled for packets predicted to be anomalous based on the detection results. This allows payload monitoring to be performed only on some packets, making it possible to detect anomalies while reducing false positives and the amount of calculations required for monitoring. This makes it possible to monitor anomalous communications in in-vehicle networks while securing the computational resources required for processing by autonomous driving or advanced driving systems.
  • 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 while suppressing false detections by the anomaly detection system.
  • 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 while suppressing false detections by the anomaly detection system.
  • an anomaly detection method 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, and the method includes: collecting 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; detecting an anomaly 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 message 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 contents when a message matching the conditions is received.
  • DPI Deep Packet Inspection
  • anomaly detection based on flow information makes it possible to monitor the entire network with reduced processing load, without having to monitor the payload information of each message. Also, by generating DPI rules that include monitoring of payload information based on the results of anomaly detection, it is possible to suppress false positives. Furthermore, by performing anomaly detection in two stages, that is, 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 performs anomaly detection first, but reduces the chance of overlooking anomalous communications. In this way, the present disclosure can appropriately balance detection accuracy and processing volume.
  • the higher-level electronic control unit detects anomalies based on flow information, and the DPI rules generated using the results are enabled for the necessary lower-level electronic control units, thereby reducing the number of messages monitored by each electronic control unit. This reduces the processing load per electronic control unit.
  • the lower-level electronic control unit can simplify the monitoring rules by monitoring the network in accordance with the higher-level electronic control unit. This reduces the computational resources allocated to network monitoring.
  • 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 of processing for monitoring the messages for each of one or more DPI rules including the DPI rule.
  • 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 in the anomaly detection and the number of messages to be monitored per unit time.
  • the DPI rule indicates service information or client information contained in a message transmitted 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 may be dropped.
  • the abnormality detection method may further include adding, modifying, enabling or disabling the DPI rules based on the monitoring results output from the one or more lower-level electronic control devices.
  • DPI rules that not only detect anomalies based on flow information but also reflect the monitoring results of the lower-level electronic control devices to be applied to each lower-level electronic control device.
  • a DPI rule that monitors identifier information such as service information or client information contained in the payload information of a message is enabled, allowing the lower-level electronic control device to detect identifier information that is different from normal.
  • the higher-level electronic control device 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 of the lower-level electronic control devices can be applied.
  • the abnormality detection method may further add, change, enable, or disable the DPI rules 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 connection, and the result of the abnormality detection.
  • the higher-level electronic control unit can determine which messages pose a high risk of attack depending on the current vehicle state, and add or enable DPI rules that monitor or protect those communications. Also, if a number of DPI rules that exceed the message processing capacity of the lower-level electronic control unit are enabled, older DPI rules can be temporarily disabled, allowing DPI rules with a higher level of urgency to be enabled with priority.
  • the abnormality detection method may further determine the processing content indicated by the DPI rule according to the vehicle state of one of the lower-level electronic control devices, which is the source or destination of the message determined to be abnormal in the abnormality detection, and which is included in the one or more lower-level electronic control devices.
  • the abnormality detection method may further include 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 according to 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 to be processed passes, and applying 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.
  • the abnormality detection method may further calculate the communication volume of each of the first electronic control device, the second electronic control device, and the at least one third electronic control device based on the flow information, and calculate the processing load volume from the communication volume and one or more DPI rules enabled in the one or more lower-level electronic control devices.
  • the abnormality detection method may further include monitoring messages in the higher-level electronic control device using the DPI rules.
  • An anomaly detection device is 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, 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, and the DPI rule is used to monitor the message 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 contents when a message matching the conditions is received.
  • a DPI Deep Packe
  • a program according to one aspect of the present disclosure causes a computer to execute an anomaly detection method.
  • an abnormality detection device an abnormality detection system
  • an in-vehicle network in-vehicle network system
  • a plurality of ECUs communicate via Ethernet will be described.
  • Fig. 1 is an overall configuration diagram of an in-vehicle network system 10 in the first embodiment.
  • 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 wheel control ECU 200c, a brake control ECU 200d, a shift lever ECU 200e, a camera ECU 200f, and a LiDAR ECU 200g.
  • the in-vehicle network system 10 may include more ECUs.
  • 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.
  • Each zone ECU is connected to each other via Ethernet and communicates using SOME/IP, a communications protocol for in-vehicle Ethernet.
  • a network that is not connected to a different zone ECU (Ethernet 1, 3, 4) is called a zone.
  • Each zone ECU is connected to its own zone and acquires information about and controls the ECU.
  • Zone ECU 100a 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, so a description thereof will be omitted.
  • 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.
  • the communication port unit 101 is an Ethernet communication interface that transmits and receives frames. Depending on the type of communication frame received, the communication port unit 101 determines which function of the zone ECU should process the communication frame.
  • the DPI unit 102 monitors the payload information of packets based on the monitoring rules specified by the DPI rules. For example, when communication between two or more ECUs, including broadcast communication, is carried out via a zone ECU, a DPI rule is applied that performs processing such as dropping abnormal communication in the DPI unit 102 or taking a communication log.
  • the flow information collection unit 103 classifies packets received via Ethernet 1 or 2 based on header information, and generates flow information by aggregating statistical information for each classified packet.
  • 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.
  • the DPI control unit 105 controls the DPI rules that are enabled in 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.
  • the DPI rule generation unit 105A generates DPI rules based on the alerts (hereinafter, abnormality alerts) output by the flow-based anomaly detection unit 104 or the alerts (hereinafter, DPI alerts) output by the DPI unit of each ECU.
  • the DPI rules generated from abnormality alerts are intended to mainly monitor the packet payload for the detected abnormality.
  • the DPI rules generated from DPI alerts are intended to protect the network from abnormal communications, such as by blocking abnormal packets.
  • 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.
  • the DPI alert processing unit 105C processes the alerts 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 additional DPI rules need to be generated.
  • the all-DPI rule storage unit 106 stores the DPI rules held by the DPI sections of all ECUs present in the in-vehicle network system 10.
  • the ECU management list storage unit 107 stores a list of ECUs present on the in-vehicle network system 10, the service information handled by each ECU, and the zone ECUs that manage the zones to which they belong.
  • [Configuration of ADAS ECU 200a] 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.
  • 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.
  • the DPI unit 202 monitors the payload information of packets based on monitoring rules specified by the DPI rule distributed from the zone ECU. When the received packet matches the check contents of the 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, when the DPI unit 202 determines that the received packet is an abnormal packet, a DPI rule is applied that performs processing such as dropping the abnormal communication or recording the communication log.
  • the application unit 203 executes an ECU-specific application according to the received communication frame.
  • SOME/IP Message Format is a type of service-oriented communication, and realizes service-oriented communication by combining four types of 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.
  • SD Service Discovery
  • Figure 4 shows an example of a message format used in SOME/IP SD.
  • the message format in Figure 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.
  • the Message ID is 0xFFFF8100.
  • the number of bytes of data following the Length field is stored in Length.
  • the Request ID stores the combined value of the Client ID and Session ID.
  • the Protocol Version is set to 0x01
  • the Interface Version is set to 0x01
  • the Message Type is set to 0x02
  • the Return Code is set to 0x00.
  • Figure 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 Figure 5.
  • Type can be set to 0x00 or 0x01, with 0x00 meaning Find and 0x01 meaning 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.
  • Type is 0x01, indicating that the message is a message in which the server ECU notifies information about the services it can provide.
  • Index 1st options indicates the position of the first option. In Figure 5, Index 1st options is 0, indicating 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 Figure 5.
  • #of opt1 contains the number of option 1s, and in Figure 5, a value of 1 is stored.
  • #of opt2 contains the number of option 2s, and in Figure 5, a value of 0 is stored, indicating that option 2 is not used.
  • Service ID is a field that stores an ID that indicates the type of service, and in Figure 5, 0x1000 is stored in the Service ID.
  • Instance ID is a field that stores an ID that indicates an instance of the service, and in Figure 5, it is set to 0x0001.
  • the Major Version is information used for version management of the service.
  • 0x01 is stored in the Major Version.
  • TTL is a field that sets the expiration time (in seconds) of the service, and in Figure 5, TTL is set to 0xFFFF.
  • a TTL of 0xFFFF means that the service will be valid until the next startup timing of the ECU.
  • the Minor Version is information used for version management of the service, and is set to 0x00000002 in Figure 5.
  • the Length of Options Array in Bytes included in the Options area stores the byte length of the Options area, and Figure 5 shows that the byte length of the Options area is 12 bytes.
  • the Length value is set according to the type of option.
  • Figure 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 Figure 5, it is set to 192.168.0.1.
  • the reserved area stores 0.
  • L4-Proto stores 0x11, indicating that User Datagram Protocol (UDP) is used.
  • UDP User Datagram Protocol
  • Figure 6 shows an example of a message format used in SOME/IP.
  • the SOME/IP header portion excluding the payload is the same as in Figure 4.
  • Figure 7 shows an example of a SOME/IP message.
  • Service ID is a field that stores an ID that indicates the type of service, and in Figure 7, 0x0001 is stored in Service ID.
  • 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 Figure 7, 0x0301 is stored in the Method ID.
  • Length stores the message length from the Client ID to the Payload. In Figure 7, it is set to 1408 bytes.
  • the Client ID is an identifier that identifies the calling client within the ECU, and is set to 0x01000 in Figure 7.
  • the Session ID is an identifier that distinguishes messages sent from the same sender, and is set to 0x0011 in Figure 7.
  • the Protocol Version indicates the protocol version of SOME/IP, and is set to 0x01 in Figure 7.
  • Interface Version indicates the major version of the service I/F, and is set to 0x01 in Figure 7.
  • Message Type indicates the message type of SOME/IP. In Figure 7, Message Type is set to 0x02, which indicates that the message type is Notification.
  • Return Code represents the return value indicating whether the request was processed normally or not, and is set to 0x00 in Figure 7.
  • Payload describes the information that the sender wants to send.
  • FIG. 8 is a diagram showing an example of flow information collected by the flow information collecting unit 103 of the zone ECU.
  • the flow information is generated by calculating statistical information at regular intervals from packet header information and the like, and in FIG. 8, the flow information is calculated at 30-second intervals.
  • a combination of a source IP address (Src IP), a source port number (Src Port), a destination IP address (Dst IP), a destination port number (Dst Port), and a protocol number (Protocol) of a packet is assigned to a flow ID, which is identification information.
  • a protocol number Protocol
  • statistical information is collected for each flow ID.
  • the number of packets communicated for each flow ID, the average arrival interval of packets, and the average packet length are collected.
  • FIG. 9 is a diagram showing an example of a list (hereinafter, referred to as a total DPI rule list) that is stored in the total DPI rule storage unit 106 and that lists all the DPI rules that are applied to the ECUs on the in-vehicle network.
  • a total DPI rule list a list that is stored in the total DPI rule storage unit 106 and that lists all the DPI rules that are applied to the ECUs on the in-vehicle network.
  • a DPI rule has the following settings: the ECU to which it applies, the rule number, the DPI rule name, the issuing ECU, the header conditions, the check contents, the action taken when checking, the number of packets to be monitored, the number of packets already monitored, and the processing priority.
  • the ECU that has a DPI unit that actually executes the generated DPI rule is set as the target ECU.
  • the DPI rules are listed based on the target ECU.
  • the rule number is assigned to the DPI rule for DPI rule management.
  • 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. In addition, a DPI rule generated based on a DPI alert is given the DPI rule name "Abnormal Communication.”
  • the issuing ECU is set to the zone ECU that generated the DPI rule and transferred the generated DPI rule to the destination ECU.
  • the issuing ECU is determined according to the ECU management list.
  • 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. For packets that match all of the items listed in this header condition, the payload is monitored and the check contents are confirmed.
  • the check contents indicate the contents to be checked when monitoring the payload of packets that satisfy the header conditions. For example, for SOME/IP communications that may be the result of a flooding attack, it is assumed that the attacking ECU is sending a large number of packets using one type of 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. In addition, for SOME/IP communications that may be the result of a spoofing attack, it is checked whether the communication is being carried out using the correct Client ID.
  • the check operation indicates the operation to be performed when the monitored packet satisfies the check contents. For example, if a packet meets the check contents of the flooding monitor shown in Figure 9, the source ECU of the monitored communication is not an ECU that communicates with 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 meets the check contents of the spoofing monitor shown in Figure 9, it is determined that communication is being performed with a false IP address and port number, the packet is blocked, and the number of monitored packets is set to unlimited.
  • the number of monitored packets indicates the upper limit of the number of packets to be 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.
  • DPI units 102 and 202 when the number of monitored packets for a DPI rule reaches a specified number of monitored packets, that DPI rule is discarded.
  • 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 memory unit 106.
  • the processing priority is a parameter that determines the order in which the header of a packet is compared against the header conditions contained in the DPI rules when two or more DPI rules are applied to the DPI unit 102 or 202.
  • the processing priority is calculated based on the 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 against the header conditions contained in the DPI rules in order of the DPI rule with the highest processing priority.
  • the DPI units 102 and 202 of each ECU store the DPI rules in order of highest processing priority.
  • [ECU management list] 10 is a diagram showing 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 manager.
  • the zone ECU transfers the DPI rules at the DPI rule transfer unit 105B only when the distribution destination of the DPI rules generated by the DPI rule generation unit 105A is an ECU that the zone ECU manages.
  • 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.
  • 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.
  • Fig. 11 is a processing sequence diagram when an attack occurs from the steering wheel control ECU 200c to the ADAS ECU 200a in the first embodiment.
  • the zone ECUs 100b and 100c collect flow information with the flow information collection unit 103, perform anomaly detection with the flow-based anomaly detection unit 104, and generate DPI rules with 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.
  • the steering wheel control ECU 200c performs a flooding attack on the ADAS ECU 200a (S101).
  • the zone ECUs 100a and 100b that exist 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).
  • Zone ECUs 100a, 100b, and 100c share the collected flow information among themselves (S103). Note that the processing of zone ECU 100c is not shown in FIG. 11.
  • 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).
  • the zone ECUs 100a, 100b, and 100c each generate a first DPI rule for monitoring communications based on the results of the flow-based anomaly detection (S105).
  • the zone ECU 100b Since the ECU management list indicates that the target of the generated first DPI rule is not one that the zone ECU 100b manages, the zone ECU 100b stores the first DPI rule in the all DPI rule memory unit 106 (S106).
  • the zone ECU 100a Since the ECU management list indicates that the generated first DPI rule applies 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).
  • the ADAS ECU 200a receives the first DPI rule from the zone ECU 100a and applies the received first DPI rule to the DPI section 202 (S108).
  • the steering wheel control ECU 200c continues to perform a flooding attack on the ADAS ECU 200a (S109).
  • 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 according to the monitoring results in the DPI section 202, and transmits the generated DPI alert to the zone ECU 100a (S111).
  • the zone ECU 100a officially determines that the communication with the steering wheel control ECU 200c is abnormal based on the DPI alert from the ADAS ECU 200a (S112).
  • the zone ECU 100a generates a second DPI rule that blocks 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).
  • the zone ECU 100b stores the second DPI rule newly generated 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).
  • 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).
  • Flowchart of processing in zone ECU] 12 is a flowchart showing the entire process from when a zone ECU receives a packet to when a DPI rule is generated and applied to an appropriate ECU.
  • the communication port unit 101 receives a packet communicated via itself (S201).
  • the communication port unit 101 mirrors the packets and forwards 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).
  • the flow information collection unit 103 determines whether the specified time for collecting flow information has been exceeded (S204). If the specified time has been exceeded (Yes in S204), the flow information collection unit 103 outputs the flow information (S205). If the specified time has not been exceeded (No in S204), the process returns to the first step S201.
  • the communication port unit 101 transfers the output flow information to the other zone ECUs (S206).
  • the communication port unit 101 also receives flow information transferred from the other zone ECUs (S207).
  • the flow information collection unit 103 then combines the flow information it has output with the flow information transferred from the other zone ECUs (S208).
  • the flow-based anomaly detection unit 104 performs flow-based anomaly detection based on the combined flow information (S209) and determines whether or not an anomaly exists (S210). If an anomaly exists (if S210 is Yes), the flow-based anomaly detection unit 104 generates an anomaly alert that describes the details of the anomaly (S211). If no anomaly exists (if S210 is No), the zone ECU ends the process.
  • the DPI rule generation unit 105A generates a DPI rule from the generated abnormality alert (S212).
  • the DPI rule generation unit 105A stores the generated DPI rule in the all-DPI rule storage unit 106 (S213).
  • the DPI rule transfer unit 105B determines whether the ECU to which the generated DPI rule is applied is its own managed ECU based on the ECU management list (S214). If the ECU is its own managed ECU (Yes in S214), the DPI rule transfer unit 105B transfers the DPI rule to the ECU to which the rule is applied (S215), and the zone ECU ends processing. If the ECU is not its own managed ECU (No in S214), the zone ECU ends processing.
  • FIG. 13 is a flow chart of the reception process in the communication port unit 101 of the zone ECU.
  • the communication port unit 101 transfers the packet information to an appropriate function in the zone ECU depending on the type of the received packet.
  • the communication port unit 101 determines whether the packet being processed by the communication port unit 101 is a transmission packet whose source is itself (S301). If the packet is a transmission packet (Yes in S301), the communication port unit 101 transmits the packet to the ECU with the destination IP address (S302).
  • the communication port unit 101 mirrors the received packet and transfers the mirrored packet to the flow information collection unit 103 (S303).
  • the communication port unit 101 determines whether the received packet is addressed to itself (S304). If the packet is addressed to itself (if S304 is Yes), 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 (if S305 is Yes), 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.
  • the communication port unit 101 determines whether the packet is a DPI alert forwarded from another ECU (S307). If the packet is a DPI alert (if S307 is Yes), the communication port unit 101 forwards the packet to the DPI alert processing unit 105C (S308), and the zone ECU ends the processing.
  • the packet is not a DPI alert (if S307 is 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 ends the processing.
  • the flow information collection unit 103 updates the flow information from the header information of the packet, and integrates the flow information of other zones described in the payload information of the packet with the flow information it has collected.
  • the communication port unit 101 transfers the packet to the ECU with the destination IP address (S310), and the zone ECU ends the process.
  • FIG. 14 is a flowchart showing an example of a process performed by the flow-based anomaly detection unit 104.
  • the flow-based anomaly detection unit 104 receives flow information that is output at regular intervals (S401).
  • 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, the average arrival interval I) for the selected flow ID (S402).
  • statistical information e.g., the number of packets N, the average arrival interval I
  • steps S403 to S416 are executed for the selected flow ID.
  • steps S402 to S416 are repeatedly executed for each flow ID included in the flow information.
  • this series of processes is repeatedly executed, for example, each time flow information is received.
  • 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 flow information received 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.
  • the flow-based anomaly detection unit 104 calculates a previous ratio ⁇ N, which is the ratio between the number of packets N contained in the current flow information received and the number of packets N contained in the flow information output immediately before (S404). For example, ⁇ N is calculated by dividing the number of packets N of the current flow by the number of packets N of the previous flow.
  • 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 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.
  • the flow-based anomaly detection unit 104 determines whether the average arrival interval to the previous ratio ⁇ I is less than 1 (S407). If the average arrival interval to the previous ratio ⁇ I is less than 1 (if S407 is Yes), the flow-based anomaly detection unit 104 further determines whether the previous ratio ⁇ N of the number of packets is 10 or more (S408). If the previous ratio ⁇ N of the number of packets 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 a "flooding attack" (S406).
  • the flow-based anomaly detection unit 104 determines that a "flooding attack" has occurred.
  • the flow-based anomaly detection unit 104 determines whether the packet count ratio ⁇ N is 2 or more (S409). If the packet count ratio ⁇ N is 2 or more (if S409 is Yes), the flow-based anomaly detection unit 104 determines that the communication with the selected flow ID is a "spoofing attack" (S410). In other words, if the average arrival interval I is decreasing and the packet count N is increasing ( ⁇ N is greater than 1 and is greater than or equal to a second threshold value that is smaller than the first threshold value), the flow-based anomaly detection unit 104 determines that a "flooding attack" has occurred.
  • 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).
  • the flow-based anomaly detection unit 104 determines whether a switch in communication has occurred (S412). Specifically, the flow-based anomaly detection unit 104 determines that a switch in 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 IDs has increased and the other has decreased.
  • the flow-based anomaly detection unit 104 determines whether the previous change in the number of packets, ⁇ N, is 1 or greater (S413). If the previous change in the number of packets, ⁇ 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 it as a "man-in-the-middle attack (increase)" (S414). In other words, if a switch in communication has occurred and the number of packets N has increased, the flow-based anomaly detection unit 104 determines it as a "man-in-the-middle attack (increase)".
  • 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 it 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 it as a "man-in-the-middle attack (decrease)".
  • the flow-based anomaly detection unit 104 determines that the communication having the selected flow ID that did not match any attack judgment is "normal" (S416).
  • the flow-based anomaly detection unit 104 After the flow-based anomaly detection unit 104 has determined that the communication with the selected flow ID is a "flooding attack", “spoofing attack”, “man-in-the-middle attack (increase)”, “man-in-the-middle attack (decrease)", or "no anomaly”, it 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 ends processing. If processing has not been completed for all flow IDs (if S417 is No), the flow-based anomaly detection unit 104 returns to step S402 and performs the same processing for flow IDs that have not yet been subjected to anomaly detection processing.
  • anomaly detection In the anomaly detection process in Figure 14, several specific thresholds are used to determine anomalies, but in reality the thresholds change 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 the detection accuracy can be improved by using other parameters. Also, it is possible to detect attacks other than flooding attacks, spoofing attacks, and man-in-the-middle attacks.
  • [An example of an abnormality alert that is generated] 15 is a diagram showing an example of an anomaly alert generated based on the result of flow-based anomaly detection.
  • the generated anomaly alert includes information required for generating a DPI rule in the DPI rule generating unit 105A.
  • the anomaly alert includes an alert number, a flow ID of the communication determined to be anomaly, an alert type, a protocol, and a packet occupancy rate at the destination ECU.
  • 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 if the communication identified by this flow ID is abnormal.
  • the type of alert indicates the result determined by flow-based anomaly detection.
  • Man-in-the-middle attacks are detected from the interrelationship between two 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.
  • 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 "man-in-the-middle attack (decreased)", the packet occupancy is calculated by referencing the source IP address, not the destination IP address assigned to the flow ID.
  • [DPI rule generation flowchart] 16 is a flowchart of the DPI rule generation process.
  • the DPI rule generation unit 105A acquires an anomaly alert generated by the flow-based anomaly detection unit 104 (S501).
  • 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 man-in-the-middle attacks, the DPI rule generation unit 105A provisionally issues the same rule number. The rule number is then formally reissued by the DPI rule transfer unit 105B.
  • 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 at 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).
  • 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).
  • the DPI rule generation unit 105A refers to the ECU management list, confirms the legitimate service ID from the flow ID (S507), and sets the check contents included in the DPI rule using the confirmed service ID (S508).
  • the DPI rule generation unit 105A sets a process to notify an alert to the zone ECU that issued the DPI rule as a 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 contents set up to this point into one DPI rule (S511).
  • the DPI rule generation unit 105A requests the DPI rule transfer unit 105B to transfer the generated DPI rule to the set destination ECU (S512), and ends the DPI rule generation process.
  • 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 to 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).
  • the DPI rule generation unit 105A sets the process of blocking the relevant packet and resetting its own monitoring packet count to unlimited ( ⁇ ) as the check action included in the DPI rule (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 one DPI rule (S511), requests the transfer of the DPI rule (S512), and ends the DPI rule generation process.
  • 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).
  • the DPI rule generation unit 105A refers to the ECU management list to confirm the legitimate service ID from the flow ID (S521), and sets the check contents included in the DPI rule using the confirmed service ID (S522).
  • the DPI rule generation unit 105A sets a process of notifying 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 contents set up to this point into one DPI rule (S511), requests the transfer of the DPI rule (S512), and ends the DPI rule generation process.
  • the DPI rule generation unit 105A determines that the alert type included in the abnormality 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 abnormality alert with the same alert number and with the alert type "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 abnormality alert with the alert type "man-in-the-middle attack (decrease)", and sets the pair of the source ECU and the IP address of the estimated attacking ECU (the attacking ECU is the destination side) to the header condition included in the DPI rule (S526).
  • the DPI rule generation unit 105A resets the ECU to which the DPI rule is applied to the ECU with the source IP address assigned to the flow ID (S527).
  • the DPI rule generation unit 105A sets the check content, check operation, and number of monitored packets included in the DPI rule to the same content as the paired DPI rule, that is, the DPI rule generated from the abnormal alert that has the same alert number and the alert type "man-in-the-middle attack (increased)" (S528).
  • the DPI rule generation unit 105A then integrates the content set up to this point into one DPI rule (S511), requests the transfer of the DPI rule (S512), and ends the DPI rule generation process.
  • [DPI rule transfer flow chart] 17 is a flowchart of the 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).
  • 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 all DPI rule storage unit 106 (S604). DPI rule transfer unit 105B then transfers the DPI rule to the destination ECU (S605), and ends the DPI rule transfer process.
  • [An example of a generated DPI rule] 18 is a diagram showing an example of a DPI rule generated from an abnormality alert. In FIG. 18, the DPI rule generated from the abnormality alert of FIG. 15 is shown.
  • the rule number is set so that the target ECU knows which zone ECU issued the DPI rule.
  • the rule number is associated with the zone ECU that issued the DPI rule. For example, if zone ECU 100b is the issuer, a number such as "B-1" combined with an alphabet will be issued. However, for the "man-in-the-middle attack monitoring" DPI rule set, the same number is issued to match the zone ECU that notifies the DPI alert.
  • the check contents and actions taken during the check vary depending on the attack detected by flow-based anomaly detection.
  • the monitoring rule for flooding attacks is to check whether only one service ID is being used.
  • the target ECU obtains from the ECU management list the service ID of the communication that was found to be abnormal in flow-based anomaly detection as the check content, and monitors whether communication is being performed using any service ID other than that.
  • the target ECU confirms communication other than the corresponding service ID, it notifies the zone ECU that issued the DPI rule of a DPI alert as a check action. If there are no DPI alert notifications in a certain amount by the time the monitoring of the specified number of monitored packets for flooding monitoring is completed, the zone ECU determines that the communication is abnormal.
  • the target ECU monitors whether any communication other than that using a legitimate client ID is taking place.
  • the target ECU detects communication using a client ID other than that used legitimately, it determines that the communication is abnormal, blocks the packet in question as a check action, and changes the number of packets monitored by the DPI rule to unlimited ( ⁇ ).
  • the target ECU checks whether an ECU suspected to be an attacker is communicating with two ECUs simultaneously using the same service ID.
  • the target ECU confirms that two ECUs to which the DPI rule is applied use a specified service ID in communication, it notifies the same zone ECU of a DPI alert.
  • the zone ECU determines that the communication is abnormal.
  • FIG. 19 is a flowchart of DPI rule processing in the DPI units 102 and 202.
  • the processing shown in Fig. 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).
  • the DPI units 102 and 202 store the DPI rules in advance in order of processing priority.
  • the DPI units 102 and 202 determine whether the header of the received packet satisfies the header conditions contained in the selected DPI rule (S703).
  • the DPI units 102 and 202 determine whether the packet satisfies the check contents included in the DPI rule (S704).
  • 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 processing of step S705.
  • the DPI units 102 and 202 increment the count of the number of monitored packets by 1 (S706).
  • 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.
  • 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.
  • [An example of a DPI alert] 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 rule in the DPI units 102 and 202 reaches a specified number of packets monitored, or is notified as an operation at the time of checking some of the DPI rules.
  • a DPI alert includes a rule number, a DPI rule name, the ECU to which it applies, and the 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.
  • the DPI rule name indicates the name of the DPI rule that corresponds to the DPI alert.
  • the applicable ECU indicates the ECU to which the DPI rule that corresponds to the DPI alert applies, and is used to determine which ECU notified the DPI alert.
  • the alert content indicates “rule ended” or "check met.”
  • a DPI alert with "rule ended” as the alert content indicates that the number of monitored packets for the DPI rule has met the specified number of monitored packets.
  • a DPI alert that includes "Check Applicable” in the alert content indicates that the check content included in the DPI rules has been met.
  • rule numbers "B-1" and "C-1" shown in Figure 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.
  • rule number "B-2" shown in FIG. 20 indicates that the ECU to which it 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," since communication using the same service ID has been confirmed from two ECUs, it can be determined that the communication being monitored is abnormal.
  • [DPI Alert Processing Flowchart] 21 is a flowchart of the DPI alert process in the zone ECUs 100a, 100b, and 100c.
  • the DPI alert process unit 105C receives a DPI alert (S801).
  • the DPI alert processing unit 105C determines whether the DPI rule name included in the DPI alert is "flooding monitoring" (S802). If the DPI rule name is "flooding monitoring" (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).
  • 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, since 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). At this point, the DPI alert processing unit 105C notifies zone ECUs other than itself to discard the rule.
  • the DPI alert processing unit 105C determines that the communication monitored by the DPI rule is an abnormal communication using a single service ID (S807). The DPI alert processing unit 105C then discards the existing DPI rules from all DPI rule storage unit 106, reissues a DPI rule that blocks the abnormal communication (S808), and terminates the DPI alert processing.
  • the DPI alert processing unit 105C ends the DPI alert processing and waits until a DPI alert with the alert content "end of rule” is notified.
  • the DPI alert processing unit 105C determines whether a "check hit" with the same rule number and a different DPI rule name has already been received (S812). If a "check hit" with the same rule number and a different DPI rule name has already been received (if S812 is Yes), it has been confirmed that the attacker ECU is communicating using the same service ID, and so the DPI alert processing unit 105C determines that the communication monitored by the DPI rule is abnormal (S813). The DPI alert processing unit 105C then discards all existing DPI rules from the DPI rule storage unit 106, reissues a DPI rule that blocks abnormal communication (S814), and terminates the DPI alert processing.
  • the DPI alert processing unit 105C ends the DPI alert processing and waits until the next DPI alert is notified.
  • [An example of a DPI rule that blocks abnormal communications] 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.
  • Header information of the abnormal communication is specified as the header condition
  • the check content is specified as confirmation of the service ID or client ID used in the abnormal communication. Then, the process of blocking packets of the communication that matches the specified content is specified as the check action.
  • 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 preferable to recalculate the processing priority for the corresponding packet, but the processing priority of the original DPI rule may be used.
  • an anomaly detection device 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 given the same numbers and will not be described.
  • Fig. 23 is an overall configuration diagram of the in-vehicle network system 20.
  • the in-vehicle network system 20 includes an ADAS ECU 200a, an IVI ECU 200b, a steering wheel 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.
  • Zone ECU 1100a 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, so a description thereof will be omitted.
  • 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.
  • 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.
  • the DPI rule generation unit 1105A generates DPI rules based on the abnormality alerts output by the flow-based anomaly detection unit 104 or the DPI alerts output by the DPI units of each ECU.
  • the DPI rule generation unit 1105A determines the header conditions, check contents, check operations, and number of monitored packets included in the DPI rules.
  • the DPI rule transfer unit 1105B determines the application destination of the DPI rule generated by the DPI rule generation unit 1105A according to the processing load status of each ECU, and transfers the DPI rule to the determined ECU to which it is to be applied. 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 zone ECU 1100b instead of the ADAS ECU 200a.
  • the DPI rule transfer unit 1105B receives the number of communication packets of the ECUs that are candidates for application and the number of monitored packets in the DPI unit from the flow information collection unit 103. The DPI rule transfer unit 1105B determines where to apply the DPI rule based on this information and also calculates the processing priority.
  • Fig. 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 the embodiment 2.
  • the zone ECUs 1100b and 1100c collect flow information in the flow information collection unit 103, perform anomaly detection in the flow-based anomaly detection unit 104, generate DPI rules in the DPI rule generation unit 1105A based on the results, determine the application destination of the DPI rules according to the processing load status of each ECU, and perform security measures based on the monitoring results of the applied DPI rules.
  • the steering wheel control ECU 200c performs a flooding attack on the ADAS ECU 200a (S901).
  • the zone ECUs 1100a and 1100b which exist on the communication path between the steering wheel control ECU 200c and the ADAS ECU 200a, mirror and receive the packets, and collect flow information (S902).
  • Zone ECUs 1100a, 1100b, and 1100c share the collected flow information among themselves (S903). Note that the processing of zone ECU 1100c is not shown in FIG. 25.
  • 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).
  • the zone ECUs 1100a, 1100b, and 1100c generate a first DPI rule for monitoring communications based on the results of the flow-based anomaly detection (S905).
  • 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 based on the check results, determines itself as the application of the DPI rule, and applies the first DPI rule (S906).
  • the zone ECU 1100a determines from the flow information that the generated first DPI rule should be applied to the zone ECU 1100b (S907). Note that the method of this determination is the same as in S906.
  • the steering wheel control ECU 200c continues to perform a flooding attack on the ADAS ECU 200a (S908).
  • the zone ECU 1100b monitors the packet payload according to the first DPI rule applied to the DPI unit 102 (S909).
  • the zone ECU 1100b generates a DPI alert based on the monitoring results 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).
  • 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).
  • [DPI rule generation flowchart] 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).
  • 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 abnormality alert in the header condition included in the DPI rule (S1004).
  • the DPI rule generation unit 1105A refers to the ECU management list to confirm the legitimate service ID from the flow ID (S1005), and sets the check contents included in the DPI rule using the confirmed service ID (S1006).
  • the DPI rule generation unit 1105A sets a process to notify an alert to the zone ECU that issued the DPI rule as a 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 contents set up to this point into one DPI rule (S1009).
  • the DPI rule generation unit 1105A requests the DPI rule transfer unit 1105B to determine the application destination of the generated DPI rule, determine the processing priority, and transfer the rule (S1010), and ends the DPI rule generation process.
  • 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 to the header condition included in the DPI rule (S1012). The DPI rule generation unit 1105A then refers to 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).
  • the DPI rule generation unit 1105A sets the process of blocking the relevant packet and resetting its own monitoring packet count to unlimited ( ⁇ ) as the check action 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 one DPI rule (S1009), requests the transfer of the DPI rule (S1010), and ends the DPI rule generation process.
  • 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).
  • the DPI rule generation unit 1105A refers to the ECU management list to confirm the legitimate service ID from the flow ID (S1019), and sets the check contents included in the DPI rule using the confirmed service ID (S1020).
  • the DPI rule generation unit 1105A sets a process to notify 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 contents set up to this point into one DPI rule (S1009), requests the transfer of the DPI rule (S1010), and ends the DPI rule generation process.
  • 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 with the same alert number and with 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 with the alert type "man-in-the-middle attack (decrease)", and sets the pair of the source ECU and the IP address of the estimated attacking ECU (the attacking ECU is the destination side) as the header condition of the DPI rule (S1024).
  • the DPI rule generation unit 1105A sets the check contents, 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 "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.
  • Flowchart of DPI rule forwarding process 27 is a flowchart of the DPI rule transfer process.
  • the DPI rule transfer section 1105B receives the DPI rule generated by the DPI rule generating section 1105A (S1101).
  • the DPI rule transfer unit 1105B selects an ECU on the path through which the packet to be monitored for the DPI rule passes (S1102).
  • the ECUs on the path include the source ECU and destination ECU of the packet to be monitored, and the zone ECUs on the communication path between the source ECU and destination ECU.
  • zone ECUs 100a and 100b are selected as the zone ECUs on the path. It is also assumed that zone ECU 100b is the zone ECU that manages the source ECU.
  • the DPI rule transfer unit 1105B requests flow information from 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).
  • the DPI rule transfer unit 1105B determines whether the packet to be monitored for the DPI rule is encrypted communication (S1104). If the packet to be monitored is 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 number of DPI processed packets of the destination ECU is greater than that of the source ECU (S1105).
  • the DPI rule transfer unit 1105B sets the source ECU as the application destination of the DPI rule, sets the packet occupancy rate of that ECU as the processing priority, and transfers the DPI rule to the ECU to which it is applied (S1106). After that, the DPI rule transfer unit 1105B ends the DPI rule transfer process.
  • the DPI rule transfer unit 1105B sets the destination ECU to which the DPI rule is to be applied, sets the packet occupancy rate in that ECU as the processing priority, and transfers the DPI rule to the ECU to which it is to be applied (S1107). The DPI rule transfer unit 1105B then ends the DPI rule transfer process.
  • the zone ECU can also monitor the packet without decrypting it, 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 zone ECU candidate, 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 is difficult on the zone ECU side, so the DPI rule transfer unit 1105B performs step S1105.
  • the DPI rule transfer unit 1105B sets the application destination of the DPI rule to the zone ECU 1100a, sets the packet occupancy rate in that ECU as the processing priority, and transfers the DPI rule to the ECU to which it is applied (S1110).
  • the DPI rule transfer unit 1105B then ends the DPI rule transfer process.
  • DPI rule transfer unit 1105B sets zone ECU 1100b as the application destination of the DPI rule, sets the packet occupancy rate in that ECU as the processing priority, and transfers the DPI rule to the ECU to which it is applied (S1111). After that, DPI rule transfer unit 1105B ends the DPI rule transfer process.
  • FIG. 28 is a diagram showing an example of flow information that the DPI rule transfer part 1105B requests from the flow information collection part 103 in order to determine the application destination and processing priority of the DPI rule.
  • the DPI rule transfer unit 1105B When determining where to apply the DPI rule, notifies the flow information collection unit 103 of the header conditions of the 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 where to apply 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.
  • the flow information requested from the flow information collection unit 103 is linked to the rule number provisionally issued when the DPI rule was generated.
  • the flow information includes whether encryption is performed, the communication volume of the packets to be monitored, the candidate ECUs to which the DPI rule is applied, the communication volume of all the candidate ECUs, the packet occupancy rate of the packets to be monitored, and the number of DPI processed packets in the candidate ECUs.
  • the presence or absence of encryption indicates whether the communication that meets the target header conditions has been encrypted.
  • the presence or absence of encryption is determined by the combination of the source ECU and the destination ECU.
  • the communication volume of the monitored packets indicates the communication volume of packets that meet the header conditions communicated on the in-vehicle network system 20.
  • the candidate ECUs indicate the ECUs through which the packets to be monitored communicate.
  • 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 to be applied. In other words, the packet occupancy rate indicates the proportion of the number of packets to be monitored out of the total number of packets communicated across all candidate ECUs to be applied.
  • 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 is, the greater the processing load on the DPI unit of each ECU. Furthermore, this 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 that the DPI units 102 and 202 perform a header check on the DPI rules and received packets.
  • Fig. 29 is a diagram showing an example of a DPI rule whose application destination has been dynamically changed.
  • 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
  • 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.
  • an anomaly detection device 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 given the same numbers and will not be described.
  • Fig. 30 is an overall configuration diagram of the in-vehicle network system 30.
  • the in-vehicle network system 30 includes an ADAS ECU 200a, an IVI ECU 200b, a steering wheel 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.
  • Zone ECU 2100a 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, so a description thereof will be omitted.
  • the zone ECU 2100a includes a communication port unit 101, a DPI unit 102, a flow information collection unit 103, a flow-based anomaly detection unit 104, a DPI control unit 2105, an all-DPI rule memory unit 106, an ECU management list storage unit 107, a safety determination unit 2108, and a safety monitoring DPI rule list storage unit 2109.
  • the DPI control unit 2105 includes a DPI rule generation unit 2105A, a DPI rule transfer unit 2105B, and a DPI alert processing unit 105C.
  • the DPI rule generation unit 2105A generates DPI rules from the 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.
  • 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 anomaly detection unit 104 and the vehicle status received from the ADAS ECU 200a and the shift lever ECU 200e, and issues commands to each ECU to ensure the safety of the driver as necessary. In addition, 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 the communication of the ECU that has that function.
  • the safety monitoring DPI rule list storage unit 2109 stores in advance templates of DPI rules generated in response to instructions from the safety judgment unit 2108.
  • the DPI rule generation unit 2105A receives an instruction to generate a DPI rule from the safety judgment 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 that template.
  • [DPI rule list for safety monitoring] 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, a check content, an operation at the time of checking, and a number of monitored packets.
  • the DPI rule generation unit 2105A requests the safety monitoring DPI rule list storage unit 2109 for necessary DPI rules in accordance with an instruction from the safety judgment unit 2108.
  • the DPI rule for emergency stop system monitoring is a DPI rule that is generated when the safety judgment unit 2108 judges 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 performing malicious communication through a spoofing attack on the control system ECU or sensor ECU used when bringing 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.
  • the DPI rule for monitoring the rearview monitor is generated when an abnormal alert occurs in communication with the IVI while the shift lever is in reverse (R). This DPI rule monitors whether communications other than those with valid client IDs are being made on the rearview monitor that the driver looks at to check behind him while parking, and communication packets with invalid client IDs are blocked by DPI units 102 and 202.
  • Fig. 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 the embodiment 3.
  • a DPI rule that monitors the operation of the emergency stop system and the communication of the function is applied, and a security response is performed based on the monitoring result of the DPI unit.
  • 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. 33.
  • the steering wheel control ECU 200c performs an attack by masquerading as the ADAS ECU 200a (S1203).
  • the zone ECUs 2100a and 2100b which exist 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).
  • the zone ECUs 2100a, 2100b, and 2100c share the collected flow information between them (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).
  • the zone ECUs 2100a, 2100b, and 2100c perform a safety judgment to determine whether the contents of the abnormality alert generated by the flow-based abnormality detection are a threat to the safety of the vehicle (S1207). Specifically, the zone ECUs 2100a, 2100b, and 2100c perform the safety judgment by comparing the contents of the abnormality alert with the vehicle status reported by the ADAS ECU 200a and the shift lever ECU 200e.
  • the zone ECU 2100a determines based on the safety assessment result 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).
  • the ADAS ECU 200a operates the emergency stop system according to instructions from the zone ECU 2100a that manages it (S1209). To safely operate the emergency stop system, the zone ECU 2100a distributes DPI rules to the ECUs involved in the emergency stop to monitor whether unauthorized communication is taking place (S1210).
  • 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 section 202 (S1211).
  • the steering wheel control ECU 200c continues to perform spoofing attacks on the ADAS ECU 200a (S1212).
  • the ADAS ECU 200a blocks abnormal communications from the steering wheel control ECU 200c in accordance with the DPI rules (S1213).
  • [Zone ECU Packet Processing] 34 is a flowchart of a process performed when a zone ECU receives a packet in the third embodiment.
  • 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).
  • the flow information collection unit 103 determines whether the specified time for collecting flow information has been exceeded (S1303). If the specified time has been exceeded (Yes in S1303), the flow information collection unit 103 outputs the flow information (S1304). If the specified time has not been exceeded (No in S1303), the flow information collection unit 103 returns to the first step S1301.
  • 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 the other zone ECUs (S1307).
  • the flow-based anomaly detection unit 104 performs flow-based anomaly detection based on the combined flow information (S1308) and determines whether or not an anomaly exists (S1309). If an anomaly exists (if S1309 is Yes), the flow-based anomaly detection unit 104 generates an anomaly alert that describes the details of the anomaly (S1310). If no anomaly exists (if S1309 is No), the zone ECU ends the process.
  • the DPI rule generation unit 2105A compares the content of the generated abnormality alert with the vehicle state to determine whether the content of the abnormality alert poses a threat to the safety of the vehicle (S1311).
  • the DPI rule generation unit 2105A determines whether the vehicle is in a dangerous state based on the safety judgment result (S1312).
  • the DPI rule generation unit 2105A instructs the ECU to take 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 processing of steps S1313 and S1314.
  • the DPI rule generation unit 2105A generates a DPI rule from the generated abnormality alert (S1315).
  • the DPI rule generation unit 2105A stores the generated DPI rule in the total DPI rule storage unit 106 (S1316).
  • the DPI rule transfer unit 2105B determines whether the ECU to which the generated DPI rule is applied is its own managed ECU based on the ECU management list (S1317). If the ECU is its own managed ECU (Yes in S1317), the DPI rule transfer unit 2105B transfers the DPI rule to the ECU to which the rule is applied (S1318), and the zone ECU ends processing. If the ECU is not its own managed ECU (No in S1317), the zone ECU ends processing.
  • [Safety Determination Processing Flowchart] 35 is a processing flowchart of safety determination.
  • 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).
  • the safety judgment unit 2108 judges whether the vehicle is in autonomous driving mode (S1403). If the vehicle is in autonomous driving mode (if S1403 is Yes), the safety judgment unit 2108 instructs the ADAS ECU 200a to activate the emergency stop system and notifies the driver accordingly (S1404). The safety judgment unit 2108 then instructs the DPI rule generation unit 2105A to generate a DPI rule for monitoring the emergency stop system (S1405).
  • the safety determination unit 2108 determines whether the shift lever is in drive (D) shift (S1406). If the shift lever is in D shift (if S1406 is Yes), the safety determination unit 2108 instructs the ADAS ECU 200a to stop drive assist and notifies the driver accordingly (S1407).
  • the safety judgment 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 judgment 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 judgment unit 2108 ends the safety judgment process.
  • 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 S1410 is Yes), 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 S1411 is Yes), the safety determination unit 2108 instructs the DPI rule generation unit 2105A to generate a DPI rule for monitoring the rearview monitor (S1412).
  • the safety judgment unit 2108 ends the safety judgment process. If there is no abnormality alert from the flow-based abnormality detection unit 104 (if S1401 is No), the safety judgment unit 2108 ends the safety judgment process.
  • Flowchart of DPI rule generation process for safety monitoring] 36 is a flowchart of the process by the DPI rule generating unit 2105A in embodiment 3.
  • the DPI rule generating unit 2105A receives an instruction to generate a DPI rule from the safety determining unit 2108 (S1501).
  • 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 stop system (S1502). If the instruction from the safety determination unit 2108 is to generate a DPI rule for monitoring the emergency stop system (if S1502 is Yes), the DPI rule generation unit 2105A requests the DPI rule for monitoring the emergency stop system from the safety monitoring DPI rule list storage unit 2109, and acquires the DPI rule for monitoring the emergency stop system (S1503).
  • the DPI rule generation unit 2105A requests the DPI rule transfer unit 2105B to determine the application destination of the DPI rule for emergency stop system monitoring, to determine the processing priority, and to transfer the DPI rule to the application destination (S1504), and then ends the processing.
  • the DPI rule generation unit 2105A requests a DPI rule for monitoring the rear monitor from the safety monitoring DPI rule list storage unit 2109, and acquires the DPI rule for monitoring the rear monitor (S1505).
  • the DPI rule generation unit 2105A requests the DPI rule transfer unit 2105B to determine the application destination of the DPI rule for safety monitoring, to determine the processing priority, and to transfer the DPI rule to the application destination (S1504), and ends the process.
  • Fig. 37 is a diagram showing an example of a generated safety monitoring DPI rule.
  • the DPI rule shown in Fig. 37 is a DPI rule for monitoring an emergency stop system 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.
  • the DPI rule is transferred by the DPI rule transfer unit 2105B.
  • Ethernet is used for the in-vehicle network
  • this is not limiting.
  • CAN CAN-FD (Flexible-Data), Ethernet, LIN, or FlexRay (registered trademark)
  • FlexRay registered trademark
  • the flow information is collected by the zone ECU, but it may be collected by something other than the zone ECU.
  • the flow information may be collected by a head unit, a central ECU, an Ethernet switch, or the like.
  • a set of source IP address, destination IP address, source port number, destination port number, and protocol number was used as information for identifying a flow, but information for identifying a flow is not limited to these.
  • a V-LAN ID used in a Virtual LAN may be used as information for identifying a flow.
  • a CAN ID which is an identifier for communication data, may be used as information for identifying a flow. This makes the definition of a flow more flexible, and makes it possible to collect flow information suitable for the network.
  • the number of packets and the average arrival interval are used as the flow information used for flow-based anomaly detection, but the flow information used for flow-based anomaly detection is not limited to this.
  • the average packet length or a timestamp may be used.
  • a payload-based anomaly detection function DPI
  • a function other than DPI may be used.
  • an AI-based anomaly detection function may be used.
  • each ECU discards the DPI rules as appropriate based on the monitoring results of the DPI unit, but the zone ECU may command each ECU to discard the DPI rules depending on the situation.
  • the DPI rule is discarded when a specified number of packets have been monitored, but the conditions for discarding the DPI rule are not limited to this.
  • the DPI rule may be discarded when a certain amount of time has passed since the DPI rule was applied, or the DPI rule with the lowest monitoring priority may be discarded when the number of DPI rules applied to the DPI section exceeds a specified number.
  • the DPI rules are applied to the source ECU and the destination ECU.
  • the DPI rules may also be applied to other ECUs, including the zone ECU.
  • the shift lever state and whether or not the vehicle is in automatic driving are referenced as the vehicle state, but the referenced vehicle state is not limited to this.
  • the referenced vehicle state may include at least one of automatic parking, cruise control, software update, vehicle diagnosis, and internet connection.
  • at least one of generating, adding, changing, enabling, and disabling DPI rules may be performed by referring to such vehicle states.
  • the application destination of the DPI rule is set based on the number of packets processed by the DPI unit, but the method of setting the application destination of the DPI rule is not limited to this.
  • the application destination of the DPI rule 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 the zone ECU that is close to the source ECU. This allows the zone ECU to perform drop processing of the abnormal packet when an abnormality is detected in the DPI unit.
  • a system LSI is an ultra-multifunctional LSI manufactured by integrating multiple components on one chip, and specifically, a computer system including a microprocessor, ROM, RAM, etc. A computer program is recorded in the RAM. The system LSI achieves its function by the microprocessor operating according to the computer program.
  • each part of the components constituting each device may be individually integrated into one chip, or may be integrated into one chip to include some or all of them.
  • system LSI is used here, it may be called IC, LSI, super LSI, or ultra LSI depending on the degree of integration.
  • the method of integration is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor. It is also possible to use a field programmable gate array (FPGA) that can be programmed after LSI manufacturing, or a reconfigurable processor that can reconfigure the connections and settings of the circuit cells inside the LSI.
  • FPGA field programmable gate array
  • a reconfigurable processor that can reconfigure the connections and settings of the circuit cells inside the LSI.
  • each of the above devices may be composed of 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-multifunction 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.
  • One aspect of the present disclosure may be a program (computer program) that realizes the method of anomaly detection by a computer, or a digital signal consisting of a computer program.
  • Another 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 (Blue-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 a memory.
  • the memory may record the computer program, and the microprocessor may operate according to the computer program.
  • 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 the program or digital signal, or by transferring the program or digital signal via a network or the like.
  • the present disclosure is useful for a device that detects communication anomalies and a method for detecting communication anomalies in an in-vehicle network system.
  • Vehicle-mounted 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 section 2108 Safety determination section 2109 Safety monitoring DPI rule list storage section

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Small-Scale Networks (AREA)

Abstract

１以上の上位電子制御装置が配置された上位ネットワークと、１以上の下位電子制御装置が配置された下位ネットワークとを含む階層構造を有する車載ネットワークにおける上位電子制御装置による異常検知方法であって、車載ネットワークの所定の観測箇所において受信されるメッセージのヘッダ情報によって分類されるフローごとの統計情報であるフロー情報を収集し（Ｓ１０２）、フロー情報に基づいて異常検知を行い（Ｓ１０４）、異常検知の結果に基づいて、ＤＰＩルールの生成、追加、削除、変更、有効化及び無効化のいずれかを行い（Ｓ１０５）、ＤＰＩルールは、１以上の下位電子制御装置におけるメッセージの監視に用いられ、ＤＰＩルールは、メッセージに含まれるヘッダ情報及びペイロード情報の条件と、条件に合致するメッセージを受信した場合の処理内容とを示す。

Description

異常検知方法、異常検知装置及びプログラム
　本開示は、車載ネットワークシステムにおいて、通信の異常を検知する装置及び通信の異常を検知する方法に関する。
　近年、自動車の中のシステムには、電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークの中には多数の規格が存在し、その中で最も主流な車載ネットワーク規格の一つに、Ｃｏｎｔｒｏｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ（以降、ＣＡＮ）という規格が存在する。
　しかし近年では、自動運転及びコネクテッド化の普及に伴い、車載ネットワークトラフィックの増大が予想され、ＣＡＮよりも高速な通信規格である車載イーサネット（Ｅｔｈｅｒｎｅｔ）の普及が進んでいる。
　また、悪意のある攻撃者を監視する異常検知方法として、例えば、非特許文献１に記載されている方法が知られている。
Ｓｐｅｃｉｆｉｃａｔｉｏｎ　ｏｆ　ｔｈｅ　ＩＰ　Ｆｌｏｗ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｅｘｐｏｒｔ（ＩＰＦＩＸ）Ｐｒｏｔｏｃｏｌ　ｆｏｒ　Ｅｘｃｈａｎｇｅ　ｏｆ　Ｆｌｏｗ　Ｉｎｆｏｒｍａｔｉｏｎ　（ＲＦＣ７０１１）、Ｓｅｐｔｅｍｂｅｒ　２０１３、＜ｈｔｔｐｓ：／／ｗｗｗ．ｒｆｃ－ｅｄｉｔｏｒ．ｏｒｇ／ｒｆｃ／ｐｄｆｒｆｃ／ｒｆｃ７０１１．ｔｘｔ．ｐｄｆ＞
　このような異常検知では、トレードオフの関係にある検知精度と処理量とを適切に両立できることが望まれている。
　本開示は、検知精度と処理量とを適切に両立できる異常検知方法及び異常検知装置等を提供することを目的とする。
　上記課題を解決するために、本開示の一態様に係る異常検知方法は、１以上の上位電子制御装置が配置された上位ネットワークと、１以上の下位電子制御装置が配置された下位ネットワークとを含む階層構造を有する車載ネットワークにおける上位電子制御装置による異常検知方法であって、前記車載ネットワークの所定の観測箇所において受信されるメッセージのヘッダ情報によって分類されるフローごとの統計情報であるフロー情報を収集し、前記フロー情報に基づいて異常検知を行い、前記異常検知の結果に基づいて、ＤＰＩ（Ｄｅｅｐ　Ｐａｃｋｅｔ　Ｉｎｓｐｅｃｔｉｏｎ）ルールの生成、追加、削除、変更、有効化及び無効化のいずれかを行い、前記ＤＰＩルールは、前記１以上の下位電子制御装置における前記メッセージの監視に用いられ、前記ＤＰＩルールは、前記メッセージに含まれるヘッダ情報及びペイロード情報の条件と、前記条件に合致するメッセージを受信した場合の処理内容とを示す。
　本開示は、検知精度と処理量とを適切に両立できる異常検知方法及び異常検知装置等を提供できる。
図１は、実施の形態１における車載ネットワークシステムの全体構成図である。 図２は、実施の形態１におけるゾーンＥＣＵのブロック図である。 図３は、実施の形態１におけるＡＤＡＳ　ＥＣＵのブロック図である。 図４は、実施の形態１におけるＳＯＭＥ／ＩＰ　ＳＤのメッセージフォーマットを示す図である。 図５は、実施の形態１におけるＳＯＭＥ／ＩＰ　ＳＤのメッセージの一例を示す図である。 図６は、実施の形態１におけるＳＯＭＥ／ＩＰのメッセージフォーマットを示す図である。 図７は、実施の形態１におけるＳＯＭＥ／ＩＰのメッセージの一例を示す図である。 図８は、実施の形態１におけるゾーンＥＣＵにて収集するフロー情報の一例を示す図である。 図９は、実施の形態１における全ＤＰＩルールリストの一例を示す図である。 図１０は、実施の形態１におけるＥＣＵの管理リストの一例を示す図である。 図１１は、実施の形態１におけるフロー情報収集から異常検知及びセキュリティ対応までのシーケンスを示す図である。 図１２は、実施の形態１におけるゾーンＥＣＵによるＤＰＩルール生成処理のフローチャートである。 図１３は、実施の形態１における通信ポート部による受信処理のフローチャートである。 図１４は、実施の形態１におけるフローベース異常検知部による処理の一例を示すフローチャートである。 図１５は、実施の形態１における異常アラートの一例を示す図である。 図１６は、実施の形態１におけるＤＰＩルール生成処理のフローチャートである。 図１７は、実施の形態１におけるＤＰＩルール転送処理のフローチャートである。 図１８は、実施の形態１における異常アラートから生成されるＤＰＩルールの一例を示す図である。 図１９は、実施の形態１におけるＤＰＩルール処理のフローチャートを示した図である。 図２０は、実施の形態１におけるＤＰＩアラートの一例を示す図である。 図２１は、実施の形態１におけるゾーンＥＣＵでのＤＰＩアラート処理のフローチャートである。 図２２は、実施の形態１における異常通信を遮断するＤＰＩルールの一例を示す図である。 図２３は、実施の形態２における車載ネットワークシステムの全体構成図である。 図２４は、実施の形態２におけるゾーンＥＣＵの全体構成図である。 図２５は、実施の形態２におけるフロー情報収集から異常検知及びセキュリティ対応までのシーケンスを示す図である。 図２６は、実施の形態２におけるＤＰＩルール生成処理のフローチャートである。 図２７は、実施の形態２におけるＤＰＩルール転送部による処理のフローチャートである。 図２８は、実施の形態２におけるＤＰＩルール適用先を決定するために要求するフロー情報の一例を示す図である。 図２９は、実施の形態２における異常アラートから生成されるＤＰＩルールの一例を示す図である。 図３０は、実施の形態３における車載ネットワークの全体構成図である。 図３１は、実施の形態３におけるゾーンＥＣＵの構成図を示す図である。 図３２は、実施の形態３における安全監視用のＤＰＩルールリストの一例を示す図である。 図３３は、実施の形態３におけるフロー情報収集から安全監視用のＤＰＩルール適用までのシーケンスを示す図である。 図３４は、実施の形態３におけるゾーンＥＣＵによるパケット処理のフローチャートである。 図３５は、実施の形態３における安全性判断部による処理のフローチャートである。 図３６は、実施の形態３における安全性判断によるＤＰＩルール生成部による処理のフローチャートである。 図３７は、実施の形態３における安全監視用ＤＰＩルールの一例を示す図である。
　［本開示の基礎となった知見］
　車載ネットワーク上では、車両の走る、止まる又は曲がるなどの制御を指示する制御フレームが送受信される。そのため、悪意のある攻撃者が正規のＥＣＵになりすまして制御フレームを送信する攻撃、又は特定の制御フレームを受信させないことを目的としたＤｏＳ攻撃が実行された場合、車両の運転手だけでなく、車両周囲の歩行者も危険に晒してしまう問題がある。
　また普及の進む車載イーサネット環境では、通信がより高速になるため、ペイロードベースの監視を行うＤｅｅｐ　Ｐａｃｋｅｔ　Ｉｎｓｐｅｃｔｉｏｎ（ＤＰＩ）ではパケット一つ一つの監視が困難となる。
　そこでネットワーク全体を監視する方法として、例えば、非特許文献１に記載されているＩＰＦＩＸという仕様が存在する。ＩＰＦＩＸではイーサネット又はＴＣＰ／ＩＰヘッダに含まれる情報に基づいて、イーサネット上を流れる複数フレームをイーサネットスイッチにて分類し、フロー情報と呼ばれる統計情報を生成する。そしてイーサネットスイッチよりも上位の異常検知装置がフロー情報を監視することで、低演算量かつ低通信量でネットワーク全体を監視することができる。
　しかしながらフロー情報を活用した異常検知手法は、パケットのペイロード情報の監視までは行わないため、誤検知などの恐れが存在する。
　本開示では、パケットのヘッダ情報から統計情報が収集されることで、フロー情報が生成される。そして、上位の異常検知装置にてフロー情報の時間変化から異常を検出し、その検出結果から異常と予測されるパケットを対象にペイロードベースの監視ルールを有効化する。これにより、一部のパケットに対してのみペイロード監視が実施され、誤検知及び監視に必要な計算量を抑制しながら異常を検知できる。これにより自動運転又は先進運転システムの処理に必要な計算リソースを確保しながら、車載ネットワークでの異常通信を監視できる。
　つまり、本開示の車載ネットワーク異常検知システムによれば、車載ネットワーク全体の監視はフロー情報に基づいた異常検知装置が担当し、ＤＰＩ部がフロー情報に基づいて検出された異常な通信を監視することで、ネットワーク全体の負荷を低減しながら、異常検知システムの誤検知を抑制できる。その結果、高速な通信が発生する車載イーサネット環境においても、処理落ちを抑制しつつネットワークの監視が可能となり、安全な自動運転又は先進運転支援サービスを提供できる。
　上記課題を解決するために、本開示の一態様に関わる異常検知方法は、１以上の上位電子制御装置が配置された上位ネットワークと、１以上の下位電子制御装置が配置された下位ネットワークとを含む階層構造を有する車載ネットワークにおける上位電子制御装置による異常検知方法であって、前記車載ネットワークの所定の観測箇所において受信されるメッセージのヘッダ情報によって分類されるフローごとの統計情報であるフロー情報を収集し、前記フロー情報に基づいて異常検知を行い、前記異常検知の結果に基づいて、ＤＰＩ（Ｄｅｅｐ　Ｐａｃｋｅｔ　Ｉｎｓｐｅｃｔｉｏｎ）ルールの生成、追加、削除、変更、有効化及び無効化のいずれかを行い、前記ＤＰＩルールは、前記１以上の下位電子制御装置における前記メッセージの監視に用いられ、前記ＤＰＩルールは、前記メッセージに含まれるヘッダ情報及びペイロード情報の条件と、前記条件に合致するメッセージを受信した場合の処理内容とを示す。
　これにより、フロー情報に基づく異常検知によって、メッセージのペイロード情報を一つ一つ監視することなく、処理負荷を低減してネットワーク全体の監視が可能となる。また、異常検知の結果に基づき、ペイロード情報の監視を含むＤＰＩルールを生成することで、誤検知を抑制することができる。さらに、フロー情報に基づく異常検知と、ＤＰＩルールを用いた監視との二段階で異常検知をすることにより、最初に異常検知を行うフロー情報を用いた異常検知において、誤検知を許容する代わりに異常通信の見逃しを少なくするような異常検知ルールの設定が可能となる。このように、本開示は、検知精度と処理量とを適切に両立できる。
　さらに、上位電子制御装置がフロー情報に基づく異常検知を行い、その結果を用いて生成したＤＰＩルールを必要な下位電子制御装置に対して有効化することで、各電子制御装置が監視するメッセージ数が減少する。これにより、電子制御装置単位の処理負荷を低減できる。さらに、下位電子制御装置は上位電子制御装置に従ってネットワークの監視をすることで、監視ルールを単純化できる。よって、ネットワーク監視に割く計算リソースを削減できる。
　例えば、前記フロー情報は、フローごとのメッセージの受信量に関する情報を含み、前記異常検知方法は、さらに、前記情報に基づいて、前記ＤＰＩルールを含む１以上のＤＰＩルールのそれぞれについて、前記メッセージの監視の処理の順番を示す処理優先度を決定してもよい。
　これにより、下位電子制御装置でのＤＰＩルールとメッセージのヘッダ情報との照合の回数を減らすことができる。よって、下位電子制御装置がメッセージ監視のために消費する計算リソースを削減できる。
　例えば、前記異常検知方法は、さらに、前記異常検知で検知された異常の内容と、監視する前記メッセージの単位時間あたりのメッセージ数とに応じて、前記ＤＰＩルールに従ったメッセージの監視を有効化する時間、又は前記ＤＰＩルールに従った前記メッセージの前記監視を実施するメッセージ上限数を決定してもよい。
　これにより、下位電子制御装置に適用されるＤＰＩルールの数が時間経過とともに単調に増加していくことを防ぐことができる。よって、下位電子制御装置の処理負荷を低減できる。例えば、ＤＰＩルールごとに監視するパケット数を指定することで、監視したパケット数が指定した値を満たしたとき、そのＤＰＩルールは破棄される。
　例えば、前記ＤＰＩルールは、前記１以上の下位電子制御装置の間で送受信されるメッセージに含まれるサービス情報又はクライアント情報を示し、前記メッセージの前記監視では、メッセージのサービス情報又はクライアント情報が前記ＤＰＩルールで示される前記サービス情報又は前記クライアント情報と一致しない場合、当該メッセージはドロップされてもよい。
　これにより、下位電子制御装置は単独で異常パケットを判断し、異常パケットをドロップできる。
　例えば、前記異常検知方法は、さらに、前記１以上の下位電子制御装置から出力された前記監視の結果に基づいて前記ＤＰＩルールを追加、変更、有効化又は無効化してもよい。
　これにより、フロー情報に基づく異常検知だけでなく、下位電子制御装置での監視結果も反映したＤＰＩルールを各下位電子制御装置に適用できる。例えば、メッセージのペイロード情報に含まれるサービス情報又はクライアント情報などの識別子情報を監視するＤＰＩルールが有効化されることで、通常とは異なる識別子情報を下位電子制御装置が検知する。この場合、上位電子制御装置は、その検知結果に基づいて異常な識別子情報を持つメッセージをドロップするＤＰＩルールを生成又は有効化する、などを行うことができる。このように、下位電子制御装置の監視結果に基づいたセキュリティルールを適用できる。
　例えば、前記異常検知方法は、さらに、シフトレバー状態、自動運転中、自動駐車中、クルーズコントロール中、ソフトウェア更新中、車両診断中、及びインターネット通信接続中の少なくとも一つを含む車両状態と、前記異常検知の結果とに応じて、前記ＤＰＩルールを追加、変更、有効化又は無効化してもよい。
　これにより、上位電子制御装置は、現在の車両状態に応じて、攻撃リスクの高いメッセージを判断し、その通信を監視又は保護するようなＤＰＩルールを追加又は有効化することができる。また、下位電子制御装置において、メッセージ処理能力を超える数量のＤＰＩルールが有効化されている場合、古いＤＰＩルールを一時的に無効化することで、緊急度の高いＤＰＩルールを優先して有効化できる。
　例えば、前記異常検知方法は、さらに、前記１以上の下位電子制御装置に含まれる、前記異常検知において異常と判定された前記メッセージの送信元又は宛先である１つの下位電子制御装置の前記車両状態に応じてＤＰＩルールで示される前記処理内容を決定してもよい。
　これにより、例えば、フロー情報に基づく異常検知で異常が発生した時点で、悪意のある攻撃者から車両の制御を奪われることから防御できる。例えば、上位電子制御装置は、自動運転システムを管理するＡＤＡＳ　ＥＣＵとの通信のフロー情報から異常を検知した際に、自動運転中であれば車両の安全を確保しながら緊急で車両を停止させることをＡＤＡＳ　ＥＣＵに指示する。その際に、緊急で車両を停止させるために必要な電子制御装置に対し、不正な通信を禁止するＤＰＩルールを有効化することで、車両が停止するまでの間、車両の停止にかかわる電子制御装置への攻撃を抑制できる。
　例えば、前記異常検知方法は、さらに、前記１以上の下位電子制御装置から、前記ＤＰＩルールに従い監視される対象のメッセージの送信元の第１電子制御装置と、当該メッセージの宛先の第２電子制御装置とを選択し、前記１以上の上位電子制御装置から、前記第１電子制御装置と前記第２電子制御装置との間に配置されており、前記対象のメッセージが経由する少なくとも１つの第３電子制御装置を選択し、選択された前記第１電子制御装置、前記第２電子制御装置及び前記少なくとも１つの第３電子制御装置のうち、メッセージ処理にかかる処理負荷量が最も小さい電子制御装置に対し、前記ＤＰＩルールを適用してもよい。
　これにより、一つの電子制御装置に対し、メッセージの処理能力を超えるＤＰＩルール数が有効化されることを抑制できる。よって、各電子制御装置の処理落ちの抑制を実現できる。
　例えば、前記異常検知方法は、さらに、前記フロー情報に基づいて、前記第１電子制御装置、前記第２電子制御装置及び前記少なくとも１つの第３電子制御装置の各々の通信量を算出し、前記１以上の下位電子制御装置で有効化されている１以上のＤＰＩルールと、前記通信量とから前記処理負荷量を算出してもよい。
　これにより、ＤＰＩルールを複数の電子制御装置に分散して有効化することで、一つの電子制御装置にＤＰＩルールが集中することによる処理落ちを抑制できる。
　例えば、前記異常検知方法は、さらに、前記異常検知で検知された異常内容が前記車載ネットワークに負荷がかかる異常である場合、前記少なくとも１つの第３電子制御装置のうち、前記第１電子制御装置に最も近い第３電子制御装置に前記ＤＰＩルールを適用してもよい。
　これにより、異常メッセージを送信する電子制御装置に近い上位電子制御装置でメッセージを監視することでネットワークへの負荷を抑えた対応が可能となる。例えば、フラッディング攻撃をフロー情報に基づく異常検知にて検知した際に、送信元の電子制御装置に近い上位電子制御装置でペイロード情報を監視し、異常が確認できた際はすぐに異常メッセージをドロップできる。これにより、ネットワークを圧迫する通信が送信元の電子制御装置と上位電子制御装置との間のネットワーク以外に流れるのを抑制できる。
　例えば、前記異常検知方法は、さらに、前記上位電子制御装置において前記ＤＰＩルールを用いてメッセージを監視してもよい。
　これにより、下位電子制御装置に加えて、上位電子制御装置においてもＤＰＩルールを用いてメッセージを監視できるので、異常検知の精度を向上できる。
　また、本開示の一態様に係る異常検知装置は、１以上の上位電子制御装置が配置された上位ネットワークと、１以上の下位電子制御装置が配置された下位ネットワークとを含む階層構造を有する車載ネットワークにおける上位電子制御装置に含まれる異常検知装置であって、前記車載ネットワークの所定の観測箇所において受信されるメッセージのヘッダ情報によって分類されるフローごとの統計情報であるフロー情報を収集する収集部と、前記フロー情報に基づいて異常検知を行う異常検知部と、前記異常検知の結果に基づいて、ＤＰＩ（Ｄｅｅｐ　Ｐａｃｋｅｔ　Ｉｎｓｐｅｃｔｉｏｎ）ルールの生成、追加、削除、変更、有効化及び無効化のいずれかを行う制御部と、を備え、前記ＤＰＩルールは、前記１以上の下位電子制御装置における前記メッセージの監視に用いられ、前記ＤＰＩルールは、前記メッセージに含まれるヘッダ情報及びペイロード情報の条件と、前記条件に合致するメッセージを受信した場合の処理内容とを示す。
　また、本開示の一態様に係るプログラムは、異常検知方法をコンピュータに実行させる。
　以下、実施の形態に係る異常検知装置について図面を参照しながら説明する。ここで示す実施の形態はいずれも本開示の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、処理の要素としてのステップ及びステップの順序等は、一例であって本開示を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
　（実施の形態１）
　以下、複数のＥＣＵがイーサネットを介して通信する車載ネットワーク（車載ネットワークシステム）を搭載した車両における、異常検知装置（異常検知システム）について説明する。
　［車載ネットワークシステムの全体構成図］
　図１は、実施の形態１における車載ネットワークシステム１０の全体構成図である。図１において、車載ネットワークシステム１０は車両に搭載される。車載ネットワークシステム１０は、ゾーンＥＣＵ（ゾーンＥＣＵ）１００ａ、１００ｂ及び１００ｃと、ＡＤＡＳ　ＥＣＵ２００ａと、ＩＶＩ　ＥＣＵ２００ｂと、ハンドル制御ＥＣＵ２００ｃと、ブレーキ制御ＥＣＵ２００ｄと、シフトレバーＥＣＵ２００ｅと、カメラＥＣＵ２００ｆと、ＬｉＤＡＲ　ＥＣＵ２００ｇとを含む。なお、図１では省略されているが、車載ネットワークシステム１０にはさらに多くのＥＣＵが含まれうる。
　ゾーンＥＣＵ１００ａと、ＡＤＡＳ　ＥＣＵ２００ａと、ＩＶＩ　ＥＣＵ２００ｂとは、車載ネットワークの一種であるイーサネット１を介して接続される。ゾーンＥＣＵ１００ａと、ゾーンＥＣＵ１００ｂと、ゾーンＥＣＵ１００ｃとは、イーサネット２を介して接続される。ゾーンＥＣＵ１００ｂと、ハンドル制御ＥＣＵ２００ｃと、ブレーキ制御ＥＣＵ２００ｄと、シフトレバーＥＣＵ２００ｅとは、イーサネット３を介して接続される。ゾーンＥＣＵ１００ｃと、カメラＥＣＵ２００ｆと、ＬｉＤＡＲ　ＥＣＵ２００ｇとは、イーサネット４を介して接続される。
　各ゾーンＥＣＵは、互いにイーサネットで接続されており、車載イーサネット向けの通信プロトコルであるＳＯＭＥ／ＩＰを用いて通信を行う。異なるゾーンＥＣＵと接続されていないネットワーク（イーサネット１、３、４）をゾーンと呼ぶ。各ゾーンＥＣＵは、それぞれのゾーンに接続され、ＥＣＵの情報取得及び制御を行う。
　［ゾーンＥＣＵ１００ａの構成]
　図２は、ゾーンＥＣＵ１００ａの構成を示す図である。なお、ゾーンＥＣＵ１００ｂ、１００ｃは、ゾーンＥＣＵ１００ａと同様の構成であるため、これらの説明を省略する。
　図２において、ゾーンＥＣＵ１００ａは、通信ポート部１０１と、ＤＰＩ部１０２と、フロー情報収集部１０３と、フローベース異常検知部１０４と、ＤＰＩ制御部１０５と、全ＤＰＩルール記憶部１０６と、ＥＣＵ管理リスト保存部１０７とを備える。
　通信ポート部１０１は、イーサネットの通信インターフェイスであり、フレームの送受信を行う。通信ポート部１０１は、受信された通信フレームの種類に応じて当該通信フレームをゾーンＥＣＵのどの機能で処理するかを判断する。
　ＤＰＩ部１０２は、ＤＰＩルールによって指定された監視ルールに基づいてパケットのペイロード情報を監視する。例えば、ブロードキャスト通信を含む２つ以上のＥＣＵ間の通信がゾーンＥＣＵを経由して実施される際に、異常な通信をＤＰＩ部１０２にてドロップさせる、又は通信ログをとる、といった処理を行うＤＰＩルールが適用される。
　フロー情報収集部１０３は、イーサネット１又は２を介して受信されたパケットをヘッダ情報に基づいて分類し、分類されたパケットごとに統計情報を集計することでフロー情報を生成する。
　フローベース異常検知部１０４は、フロー情報収集部１０３が記憶するフロー情報に基づいて、異常検知を行い、検知結果を異常アラートとして出力する。異常アラートには、検知結果だけでなく、ＤＰＩ制御部１０５にてＤＰＩルールを生成するために必要な情報が含まれる。
　ＤＰＩ制御部１０５は、ＤＰＩ部１０２にて有効化されるＤＰＩルールの制御を行う。ＤＰＩ制御部１０５は、ＤＰＩルール生成部１０５Ａと、ＤＰＩルール転送部１０５Ｂと、ＤＰＩアラート処理部１０５Ｃとを含む。
　ＤＰＩルール生成部１０５Ａは、フローベース異常検知部１０４にて出力されるアラート（以降、異常アラート）又は各ＥＣＵのＤＰＩ部から出力されるアラート（以降、ＤＰＩアラート）に基づいて、ＤＰＩルールの生成を行う。異常アラートから生成されるＤＰＩルールは、主に検知された異常内容についてパケットのペイロードまでを監視することを目的とする。また、ＤＰＩアラートから生成されるＤＰＩルールは、異常パケットの遮断など、異常な通信からネットワークを保護することを目的とする。
　ＤＰＩルール転送部１０５Ｂは、ＤＰＩルール生成部１０５Ａにて生成されたＤＰＩルールを適用するＥＣＵを判断し、当該ＥＣＵにＤＰＩルールを転送する。
　ＤＰＩアラート処理部１０５Ｃは、ゾーン内のＥＣＵのＤＰＩ部がＤＰＩルールのチェック内容に該当するパケットを検出した際に出力するアラートを処理し、追加でＤＰＩルールの生成が必要かを判断する。
　全ＤＰＩルール記憶部１０６は、車載ネットワークシステム１０に存在する全ＥＣＵのＤＰＩ部が持つＤＰＩルールを記憶する。ＥＣＵ管理リスト保存部１０７は、車載ネットワークシステム１０上に存在するＥＣＵと、各ＥＣＵが取り扱うサービス情報と、所属するゾーンを管理するゾーンＥＣＵとをまとめたリストを記憶する。
　［ＡＤＡＳ　ＥＣＵ２００ａの構成]
　図３は、ＡＤＡＳ　ＥＣＵ２００ａのブロック図である。なお、ＩＶＩ　ＥＣＵ２００ｂ、ハンドル制御ＥＣＵ２００ｃ、ブレーキ制御ＥＣＵ２００ｄ、シフトレバーＥＣＵ２００ｅ、カメラＥＣＵ２００ｆ、及びＬｉＤＡＲ　ＥＣＵ２００ｇは、ＡＤＡＳ　ＥＣＵ２００ａと同様の構成であるため、これらの説明は省略する。
　図３において、ＡＤＡＳ　ＥＣＵ２００ａは、通信ポート部２０１と、ＤＰＩ部２０２と、アプリ部２０３とを備える。通信ポート部２０１は、イーサネットの通信インターフェイスであり、フレームの送受信を行う。
　ＤＰＩ部２０２は、ゾーンＥＣＵから配布されたＤＰＩルールによって指定された監視ルールに基づいてパケットのペイロード情報を監視する。ＤＰＩ部２０２は、ＤＰＩルールのチェック内容に受信されたパケットが該当した際は、必要に応じてそのＤＰＩルールが配布されたゾーンＥＣＵにアラートを送信する。ＤＰＩ部２０２は、ゾーンＥＣＵ１００ａのＤＰＩ部１０２と同様の機能を持つ。よって、例えば、ＤＰＩ部２０２が、受信されたパケットを異常パケットと判断した場合は、異常通信をドロップさせる、又は通信ログをとる、といった処理を行うＤＰＩルールが適用される。アプリ部２０３は、受信された通信フレームに従って、ＥＣＵ固有のアプリケーションを実行する。
　［ＳＯＭＥ／ＩＰメッセージフォーマット］
　ＳＯＭＥ／ＩＰは、サービス指向通信の一種であり、Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ、Ｆｉｒｅ／Ｆｏｒｇｅｔ、Ｅｖｅｎｔｓ、Ｇｅｔ／Ｓｅｔ／Ｎｏｔｉｆｉｅｒの４種類の通信方法を組み合わせることでサービス指向通信を実現する。またＳＯＭＥ／ＩＰは、通信相手とセッションを確立する手法としてＳｅｒｖｉｅｃｅ　Ｄｉｓｃｏｖｅｒｙ（ＳＤ）を備える。
　図４はＳＯＭＥ／ＩＰ　ＳＤに用いられるメッセージフォーマットの一例を示す図である。図４におけるメッセージフォーマットはイーサネットのペイロード部に格納され、通信される。図の一行あたりのデータは３２ビットであり、前半部分にＳＯＭＥ／ＩＰヘッダが、後半部分にＳＯＭＥ／ＩＰ　ＳＤのペイロードが格納される。ＳＯＭＥ／ＩＰ　ＳＤにおいて、Ｍｅｓｓａｇｅ　ＩＤは０ｘＦＦＦＦ８１００である。Ｌｅｎｇｔｈには、Ｌｅｎｇｔｈフィールドより後ろのデータのバイト数が格納される。Ｒｅｑｕｅｓｔ　ＩＤには、Ｃｌｉｅｎｔ　ＩＤとＳｅｓｓｉｏｎ　ＩＤを合わせた値が格納される。ＳＯＭＥ／ＩＰ　ＳＤにおいて、Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎは０ｘ０１、Ｉｎｔｅｒｆａｃｅ　Ｖｅｒｓｉｏｎは０ｘ０１、Ｍｅｓｓａｇｅ　Ｔｙｐｅは０ｘ０２、Ｒｅｔｕｒｎ　Ｃｏｄｅは０ｘ００と設定される。
　図５は、ＳＯＭＥ／ＩＰ　ＳＤメッセージの一例を示す図である。Ｆｌａｇｓには０ｘ８０が設定されており、Ｒｅｂｏｏｔ　Ｆｌａｇが設定されている。Ｒｅｓｅｒｖｅｄ領域は０と設定されている。Ｌｅｎｇｔｈ　ｏｆ　Ｅｎｔｒｉｅｓ　Ａｒｒａｙ　ｉｎ　ＢｙｔｅｓにはＥｎｔｒｙのバイト数が格納されており、図５では１６バイトに設定されている。
　Ｔｙｐｅは０ｘ００又は０ｘ０１に設定が可能であり、０ｘ００は、Ｆｉｎｄを意味し、０ｘ０１はＯｆｆｅｒを意味する。Ｆｉｎｄは、サービスの提供を受けるクライアントＥＣＵが、必要なサービスの提供を要求する際に使用される。Ｏｆｆｅｒは、サービスの提供を行うサーバＥＣＵが、サービスの提供が可能であることを通知する際に使用される。図５では、Ｔｙｐｅが０ｘ０１であり、当該メッセージが、サーバＥＣＵが自身の提供可能なサービスに関する情報を通知するメッセージであることが示されている。
　Ｉｎｄｅｘ　１ｓｔ　ｏｐｔｉｏｎｓは、最初のオプションの位置を示す。図５ではＩｎｄｅｘ　１ｓｔ　ｏｐｔｉｏｎｓは、０であり、最初のオプションの位置がオプション領域の最初であることを示す。Ｉｎｄｅｘ　２ｎｄ　ｏｐｔｉｏｎｓは、２つ目のオプションの位置を示し、図５では０である。
　＃ｏｆ　ｏｐｔ１にはオプション１の個数が記載されており、図５では１が格納されている。＃ｏｆ　ｏｐｔ２にはオプション２の個数が記載されており、図５では０が格納されており、オプション２を用いないことが示されている。
　Ｓｅｒｖｉｃｅ　ＩＤは、サービスの種類を示すＩＤを格納するフィールドであり、図５ではＳｅｒｖｉｃｅ　ＩＤに０ｘ１０００が格納されている。Ｉｎｓｔａｎｃｅ　ＩＤは、サービスのインスタンスを示すＩＤを格納するフィールドであり、図５では０ｘ０００１に設定されている。
　Ｍａｊｏｒ　Ｖｅｒｓｉｏｎは、サービスのバージョン管理に用いる情報であり、図５ではＭａｊｏｒ　Ｖｅｒｓｉｏｎに０ｘ０１が格納されている。
　ＴＴＬは、サービスの有効期限（秒）を設定するフィールドであり、図５ではＴＴＬに０ｘＦＦＦＦが設定されている。ＴＴＬが０ｘＦＦＦＦであるとは、ＥＣＵの次の起動タイミングまでサービスが有効であることを意味する。
　Ｍｉｎｏｒ　Ｖｅｒｓｉｏｎは、サービスのバージョン管理に用いられる情報であり、図５では０ｘ０００００００２に設定されている。
　Ｏｐｔｉｏｎ領域に含まれるＬｅｎｇｔｈ　ｏｆ　Ｏｐｔｉｏｎｓ　Ａｒｒａｙ　ｉｎ　ＢｙｔｅｓにＯｐｔｉｏｎ領域のバイト長が格納され、図５ではＯｐｔｉｏｎ領域のバイト長が１２バイトであることが示されている。
　Ｌｅｎｇｔｈの値はオプションの種類に応じて設定される。図５では、ＩＰｖ４を用いた通信例を示しており、Ｌｅｎｇｔｈは９、Ｔｙｐｅは０ｘ０４、Ｒｅｓｅｒｖｅｄは０ｘ００と設定される。ＩＰｖ４アドレスは、サーバのＩＰアドレスであり、図５では、１９２．１６８．０．１に設定されている。
　Ｒｅｓｅｒｖｅｄ領域は０が格納される。Ｌ４－Ｐｒｏｔｏには０ｘ１１が格納されており、Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ（ＵＤＰ）を用いることが示されている。最後にポート番号が格納されており、図５では３５０００番ポートが使用されていることが示されている。
　図６は、ＳＯＭＥ／ＩＰで用いられるメッセージフォーマットの一例を示す図である。Ｐａｙｌｏａｄを除くＳＯＭＥ／ＩＰヘッダ部分は図４と同様である。
　図７は、ＳＯＭＥ／ＩＰメッセージの一例を示す図である。Ｓｅｒｖｉｃｅ　ＩＤはサービスの種類を表すＩＤを格納するフィールドであり、図７ではＳｅｒｖｉｃｅ　ＩＤに０ｘ０００１が格納されている。
　Ｍｅｔｈｏｄ　ＩＤはクライアントから呼び出されるサーバ上の関数であるＭｅｔｈｏｄの種類を表すＩＤを格納するフィールドであり、図７ではＭｅｔｈｏｄ　ＩＤに０ｘ０３０１が格納されている。
　Ｌｅｎｇｔｈは、Ｃｌｉｅｎｔ　ＩＤからＰａｙｌｏａｄまでのメッセージ長が格納される。図７では、１４０８バイトに設定されている。Ｃｌｉｅｎｔ　ＩＤは、ＥＣＵ内の呼び出し元クライアントを識別する識別子であり、図７では０ｘ０１０００に設定されている。
　Ｓｅｓｓｉｏｎ　ＩＤは、同じ送信者から発信されたメッセージを区別する識別子であり、図７では０ｘ００１１に設定されている。Ｐｒｏｔｏｃｏｌ　Ｖｅｒｓｉｏｎは、ＳＯＭＥ／ＩＰのプロトコルバージョンを表し、図７では０ｘ０１に設定されている。
　Ｉｎｔｅｒｆａｃｅ　Ｖｅｒｓｉｏｎは、サービスＩ／Ｆのメジャーバージョンを表し、図７では０ｘ０１に設定されている。Ｍｅｓｓａｇｅ　Ｔｙｐｅは、ＳＯＭＥ／ＩＰのメッセージタイプを表す。図７では、Ｍｅｓｓａｇｅ　Ｔｙｐｅは０ｘ０２に設定されており、これはメッセージタイプがＮｏｔｉｆｉｃａｔｉｏｎであることを示す。
　Ｒｅｔｕｒｎ　Ｃｏｄｅは、リクエストが正常に処理されたかどうかを示す戻り値を表し、図７では０ｘ００に設定されている。Ｐａｙｌｏａｄには、送信者が送りたい情報が記述される。
　［ゾーンＥＣＵで収集するフロー情報の一例］
　図８はゾーンＥＣＵのフロー情報収集部１０３にて収集されるフロー情報の一例を示す図である。フロー情報はパケットのヘッダ情報などから一定時間ごとに統計情報を算出することで生成され、図８では３０秒間隔でフロー情報が算出される。フロー情報では、パケットの送信元ＩＰアドレス（Ｓｒｃ　ＩＰ）、送信元ポート番号（Ｓｒｃ　Ｐｏｒｔ）、宛先ＩＰアドレス（Ｄｓｔ　ＩＰ）、宛先ポート番号（Ｄｓｔ　Ｐｏｒｔ）、及びプロトコル番号（Ｐｒｏｔｏｃｏｌ）の組合せが、識別情報であるフローＩＤに割り当てられる。また、同一のフローＩＤごとに統計情報の集計が行われる。図８ではフローＩＤごとに通信されたパケット数と、パケットの平均到着間隔と、平均パケット長とが集計されている。
　［全ＤＰＩルールリストの一例］
　図９は、全ＤＰＩルール記憶部１０６に保存される、車載ネットワーク上のＥＣＵに適用されている全ＤＰＩルールが記載されたリスト（以降、全ＤＰＩルールリスト）の一例を示す図である。
　ＤＰＩルールには適用先ＥＣＵと、ルール番号と、ＤＰＩルール名と、発行元ＥＣＵと、ヘッダ条件と、チェック内容と、チェック時動作と、監視パケット数と、監視済みパケット数と、処理優先度とが設定される。
　適用先ＥＣＵには、生成されたＤＰＩルールを実際に実行するＤＰＩ部を備えるＥＣＵが設定される。図９の全ＤＰＩルールリストでは、適用先ＥＣＵを基準にＤＰＩルールが記載されている。ルール番号には、ＤＰＩルール管理のためにＤＰＩルールに付与される。
　ＤＰＩルール名はＤＰＩルールの役割に応じて決定される。例えば、異常アラートに基づいて生成されたＤＰＩルールに対して、フラッディング（Ｆｌｏｏｄｉｎｇ）監視、なりすまし監視、又は中間者攻撃監視など、検知された異常内容に基づいてＤＰＩルール名が決定される。また、ＤＰＩアラートに基づいて生成されるＤＰＩルールには異常通信というＤＰＩルール名が付与される。
　発行元ＥＣＵには、ＤＰＩルールを生成し、生成されたＤＰＩルールを適用先ＥＣＵに転送を行ったゾーンＥＣＵが設定される。発行元ＥＣＵはＥＣＵ管理リストに従って決定される。
　ヘッダ条件は、監視対象となるパケットの送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、宛先ポート番号、及びプロトコル番号の全部又は一部を示す。このヘッダ条件に記載される項目が全一致するパケットに対し、ペイロードの監視が行われ、チェック内容が確認される。
　チェック内容は、ヘッダ条件を満たすパケットのペイロードを監視する際に、チェックする内容を示す。例えば、フラッディング攻撃の可能性のあるＳＯＭＥ／ＩＰ通信については、攻撃ＥＣＵが１種類のＳｅｒｖｉｃｅ　ＩＤを使って大量のパケットを送信していることが想定される。よって、異常パケットの送信元ＥＣＵを攻撃ＥＣＵと判断され、送信元ＥＣＵから送信されるパケットが持つＳｅｒｖｉｃｅ　ＩＤの種類が１種類のみでないかが確認される。また、なりすまし攻撃されている可能性があるＳＯＭＥ／ＩＰ通信については正しいＣｌｉｅｎｔ　ＩＤで通信を行っているかが確認される。
　チェック時動作は、監視されたパケットがチェック内容を満たす場合の動作を示す。例えば、図９に示すフラッディング監視のチェック内容にパケットが該当する場合、監視されている通信の送信元ＥＣＵは１種類のＳｅｒｖｉｃｅ　ＩＤだけの通信をするＥＣＵではない。つまり、当該送信元ＥＣＵは正常なＥＣＵであると判断され、その旨がＤＰＩルールの発行元であるゾーンＥＣＵに通知される。また、図９に示すなりすまし監視のチェック内容にパケットが該当する場合、ＩＰアドレス及びポート番号を偽って通信が行われていると判断され、該当パケットの遮断が行われ、監視パケット数が無制限に設定される。
　監視パケット数は、そのＤＰＩルールにて監視するパケット数の上限値を示す。監視済みパケット数は、ＤＰＩ部がＤＰＩルールで既に監視したパケット数を示す。ＤＰＩ部１０２及び２０２ではＤＰＩルールの監視済みパケット数が規定の監視パケット数に到達した場合、そのＤＰＩルールを破棄する。またゾーンＥＣＵは、フロー情報から各ＥＣＵが通信したパケット数をフローＩＤごとに把握でき、全ＤＰＩルール記憶部１０６において全てのＤＰＩルールの監視済みパケット数を算出する。
　処理優先度は、ＤＰＩ部１０２又は２０２に２以上のＤＰＩルールが適用されている際に、パケットのヘッダとＤＰＩルールに含まれるヘッダ条件との照合を行う順番を決定するためのパラメータである。処理優先度はフロー情報を基に算出され、ＥＣＵで通信される全パケットの中で、そのＤＰＩルールが監視するパケットが占める割合によって決定される。ＤＰＩ部１０２及び２０２では処理優先度が高いＤＰＩルールから順番に、受信されたパケットのヘッダとＤＰＩルールに含まれるヘッダ条件との照合を行う。各ＥＣＵのＤＰＩ部１０２及び２０２は、この処理優先度が高い順となるようにＤＰＩルールを保存する。
　［ＥＣＵ管理リスト］
　図１０は、各ゾーンＥＣＵのＥＣＵ管理リスト保存部１０７に保存されるＥＣＵ管理リストを示す図である。ＥＣＵ管理リストには車載ネットワーク上に存在する全ＥＣＵがリストとして記載されており、各ＥＣＵには管理者として同一ゾーン内に存在するゾーンＥＣＵ（管理ゾーンＥＣＵ）が割り当てられる。ゾーンＥＣＵはＤＰＩルール生成部１０５Ａが生成したＤＰＩルールの配布先が自身の管理するＥＣＵである場合のみ、ＤＰＩルール転送部１０５ＢにてＤＰＩルールの転送を行う。
　またＥＣＵ管理リストには、各ＥＣＵが使用するＩＰアドレス及びポート番号が記載されている。そしてポート番号ごとに、使用するプロトコル及びサービス内容も記載される。プロトコルがＳＯＭＥ／ＩＰの場合はさらにクライアントＩＤ及びサービスＩＤが記載される。
　ゾーンＥＣＵはこのＥＣＵ管理リストを確認することで、フロー情報のＩＰアドレスとポート番号から、ペイロード情報を確認することなく、サービスＩＤ又はクライアントＩＤなどのＳＯＭＥ／ＩＰ通信のサービス情報を確認することができる。
　［処理のシーケンス］
　図１１は、実施の形態１におけるハンドル制御ＥＣＵ２００ｃからＡＤＡＳ　ＥＣＵ２００ａへの攻撃が発生した際の処理シーケンス図である。図１１では、ゾーンＥＣＵ１００ｂ及び１００ｃは、フロー情報収集部１０３にてフロー情報を収集し、フローベース異常検知部１０４にて異常検知を行い、その結果を基にＤＰＩルール生成部１０５ＡにてＤＰＩルールを生成する。ＡＤＡＳ　ＥＣＵ２００ａのＤＰＩ部１０２及び２０２は、生成されたＤＰＩルールを適用し、ＤＰＩ部２０２の監視結果に基づいたセキュリティ対応が行われる。
　ハンドル制御ＥＣＵ２００ｃはＡＤＡＳ　ＥＣＵ２００ａにフラッディング攻撃を行う（Ｓ１０１）。ハンドル制御ＥＣＵ２００ｃとＡＤＡＳ　ＥＣＵ２００ａとの通信経路上に存在するゾーンＥＣＵ１００ａ及び１００ｂはパケットをミラーリングしてパケットを受信し、フロー情報を収集する（Ｓ１０２）。
　ゾーンＥＣＵ１００ａ、１００ｂ及び１００ｃは、ゾーンＥＣＵ１００ａ、１００ｂ及び１００ｃの間で収集されたフロー情報を共有する（Ｓ１０３）。なお、ゾーンＥＣＵ１００ｃの処理は図１１には図示していない。
　ゾーンＥＣＵ１００ａ、１００ｂ及び１００ｃはそれぞれ共有されたフロー情報を基にフローベース異常検知を行い、ハンドル制御ＥＣＵ２００ｃがＡＤＡＳ　ＥＣＵ２００ａに攻撃していることを検知する。（Ｓ１０４）。ゾーンＥＣＵ１００ａ、１００ｂ及び１００ｃはそれぞれフローベース異常検知の結果に基づいて、通信を監視するための第１ＤＰＩルールを生成する（Ｓ１０５）。
　ゾーンＥＣＵ１００ｂは、生成された第１ＤＰＩルールの適用先がＥＣＵ管理リストより自身の管理対象ではないため、第１ＤＰＩルールを全ＤＰＩルール記憶部１０６に保存する（Ｓ１０６）。
　ゾーンＥＣＵ１００ａは、生成された第１ＤＰＩルールの適用先がＥＣＵ管理リストより自身の管理対象のため、第１ＤＰＩルールを全ＤＰＩルール記憶部１０６に保存するとともに、ＡＤＡＳ　ＥＣＵ２００ａに転送する（Ｓ１０７）。
　ＡＤＡＳ　ＥＣＵ２００ａはゾーンＥＣＵ１００ａから第１ＤＰＩルールを受信し、受信された第１ＤＰＩルールをＤＰＩ部２０２に適用する（Ｓ１０８）。ハンドル制御ＥＣＵ２００ｃはＡＤＡＳ　ＥＣＵ２００ａに対して継続してフラッディング攻撃を行う（Ｓ１０９）。
　ＡＤＡＳ　ＥＣＵ２００ａは適用された第１ＤＰＩルールを用いてハンドル制御ＥＣＵ２００ｃとの通信を監視する（Ｓ１１０）。ＡＤＡＳ　ＥＣＵ２００ａはＤＰＩ部２０２での監視結果に応じてＤＰＩアラートを生成し、生成されたＤＰＩアラートをゾーンＥＣＵ１００ａに送信する（Ｓ１１１）。
　ゾーンＥＣＵ１００ａはＡＤＡＳ　ＥＣＵ２００ａからのＤＰＩアラートに基づきハンドル制御ＥＣＵ２００ｃの通信は異常な通信と正式に判定する（Ｓ１１２）。ゾーンＥＣＵ１００ａはハンドル制御ＥＣＵ２００ｃからの異常な通信を遮断する第２ＤＰＩルールを生成し、生成された第２ＤＰＩルールをＡＤＡＳ　ＥＣＵ２００ａと、他のゾーンＥＣＵ１００ｂ及び１００ｃとに転送する（Ｓ１１３）。
　ゾーンＥＣＵ１００ｂはゾーンＥＣＵ１００ａにて新たに生成された第２ＤＰＩルールを全ＤＰＩルール記憶部１０６に保存する（Ｓ１１４）。ＡＤＡＳ　ＥＣＵ２００ａはゾーンＥＣＵ１００ａから転送された第２ＤＰＩルールを適用する（Ｓ１１５）。
　ハンドル制御ＥＣＵ２００ｃはＡＤＡＳ　ＥＣＵ２００ａに対して継続してフラッディング攻撃を行う（Ｓ１１６）。ＡＤＡＳ　ＥＣＵ２００ａは、ハンドル制御ＥＣＵ２００ｃからの異常通信を第２ＤＰＩルールに従って遮断する（Ｓ１１７）。
　［ゾーンＥＣＵにおける処理のフローチャート］
　図１２はゾーンＥＣＵがパケットを受信してからＤＰＩルールを生成し、適切なＥＣＵに適用するまでの処理全体のフローチャートである。通信ポート部１０１は、自身を経由して通信されるパケットを受信する（Ｓ２０１）。
　通信ポート部１０１は、パケットをミラーリングしつつ、パケットの宛先ＩＰアドレスに従い、パケットを転送する（Ｓ２０２）。フロー情報収集部１０３は、ミラーリングされたパケットからヘッダ情報を抽出してフロー情報を更新する（Ｓ２０３）。
　フロー情報収集部１０３はフロー情報を収集する規定の時間を超過していないかを判定する（Ｓ２０４）。規定時間を超えている場合（Ｓ２０４がＹｅｓの場合）、フロー情報収集部１０３は、フロー情報を出力する（Ｓ２０５）。規定時間を超えていない場合（Ｓ２０４がＮｏの場合）、最初のステップＳ２０１に戻る。
　通信ポート部１０１は、出力されたフロー情報を、他のゾーンＥＣＵに転送する（Ｓ２０６）。また、通信ポート部１０１は、他のゾーンＥＣＵから転送されたフロー情報を受信する（Ｓ２０７）。そしてフロー情報収集部１０３は、自身で出力したフロー情報と他のゾーンＥＣＵから転送されたフロー情報とを合成する（Ｓ２０８）。
　フローベース異常検知部１０４は、合成されたフロー情報を基にフローベース異常検知を行い（Ｓ２０９）、異常があるかどうか判定する（Ｓ２１０）。異常がある場合（Ｓ２１０がＹｅｓの場合）、フローベース異常検知部１０４は、異常の内容を記載した異常アラートを生成する（Ｓ２１１）。異常がない場合（Ｓ２１０がＮｏの場合）、ゾーンＥＣＵは処理を終了する。
　ＤＰＩルール生成部１０５Ａは、生成された異常アラートからＤＰＩルールを生成する（Ｓ２１２）。ＤＰＩルール生成部１０５Ａは、生成されたＤＰＩルールを全ＤＰＩルール記憶部１０６に保存する（Ｓ２１３）。
　ＤＰＩルール転送部１０５Ｂは、生成されたＤＰＩルールの適用先ＥＣＵが自身の管理ＥＣＵであるかをＥＣＵ管理リストに基づき判定する（Ｓ２１４）。適用先ＥＣＵが自身の管理ＥＣＵである場合（Ｓ２１４がＹｅｓの場合）、ＤＰＩルール転送部１０５Ｂは、ＤＰＩルールを適用先ＥＣＵに転送し（Ｓ２１５）、ゾーンＥＣＵは処理を終了する。適用先ＥＣＵが自身の管理ＥＣＵでない場合（Ｓ２１４がＮｏの場合）、ゾーンＥＣＵは処理を終了する。
　［ＺｏｎｅＥＣＵの通信ポート部の受信処理フローチャート］
　図１３は、ゾーンＥＣＵの通信ポート部１０１における受信処理のフローチャートである。通信ポート部１０１は受信されたパケットの種類によって、ゾーンＥＣＵ内の適切な機能にパケット情報を転送する。
　通信ポート部１０１は、通信ポート部１０１にて処理するパケットが自身を送信元とする送信パケットであるかを判定する（Ｓ３０１）。パケットが送信パケットである場合（Ｓ３０１がＹｅｓの場合）、通信ポート部１０１は、宛先ＩＰアドレスのＥＣＵにパケットを送信する（Ｓ３０２）。
　パケットが送信パケットでない場合（Ｓ３０１がＮｏの場合）、通信ポート部１０１は、受信されたパケットをミラーリングして、ミラーリングしたパケットをフロー情報収集部１０３に転送する（Ｓ３０３）。
　通信ポート部１０１は、受信したパケットが自身宛のパケットであるかを判定する（Ｓ３０４）。パケットが自身宛のパケットである場合（Ｓ３０４がＹｅｓの場合）、通信ポート部１０１は、そのパケットが他のゾーンＥＣＵから転送されたＤＰＩルールであるかを判定する（Ｓ３０５）。パケットがＤＰＩルールである場合（Ｓ３０５がＹｅｓの場合）、通信ポート部１０１は、全ＤＰＩルール記憶部１０６に、転送されたＤＰＩルールを保存し（Ｓ３０６）、ゾーンＥＣＵは処理を終了する。
　パケットがＤＰＩルールでない場合（Ｓ３０５がＮｏの場合）、通信ポート部１０１は、そのパケットが他のＥＣＵから転送されたＤＰＩアラートであるかを判定する（Ｓ３０７）。パケットがＤＰＩアラートである場合（Ｓ３０７がＹｅｓの場合）、通信ポート部１０１は、ＤＰＩアラート処理部１０５Ｃにパケットを転送し（Ｓ３０８）、ゾーンＥＣＵは処理を終了する。
　パケットがＤＰＩアラートでない場合（Ｓ３０７がＮｏの場合）、受信されたパケットは他のゾーンＥＣＵから共有されたフロー情報である。よって、通信ポート部１０１は、パケットが、他のＥＣＵで生成されたフロー情報であることをフロー情報収集部１０３に通知し（Ｓ３０９）、ゾーンＥＣＵは処理を終了する。フロー情報収集部１０３は、パケットのヘッダ情報からフロー情報を更新し、パケットのペイロード情報に記載される他ゾーンのフロー情報と自身が収集したフロー情報とを統合する。
　パケットが自身宛のパケットでない場合（Ｓ３０４がＮｏの場合）、通信ポート部１０１は、宛先ＩＰアドレスのＥＣＵにパケットを転送し（Ｓ３１０）、ゾーンＥＣＵは処理を終了する。
　［フローベース異常検知の実施の一例］
　図１４は、フローベース異常検知部１０４による処理の一例を示すフローチャートである。まず、フローベース異常検知部１０４は、一定時間ごとに出力されるフロー情報を受信する（Ｓ４０１）。
　フローベース異常検知部１０４は、受信されたフロー情報に含まれる、一つのフローＩＤを選択し、選択されたフローＩＤについて統計情報（例えば、パケット数Ｎ、平均到着間隔Ｉ）を抽出する（Ｓ４０２）。なお、ステップＳ４０３～Ｓ４１６の処理は、選択されたフローＩＤに対して実行される。つまり、ステップＳ４０２～Ｓ４１６の処理は、フロー情報に含まれるフローＩＤ毎に繰り返し実行される。さらに、この一連の処理は、例えば、フロー情報が受信される毎に繰り返し実行される。
　フローベース異常検知部１０４は、受信された今回のフロー情報に含まれる平均到着間隔Ｉと、一つ前に出力されたフロー情報に含まれる平均到着間隔Ｉとの比である前回比ΔＩを算出する（Ｓ４０３）。例えば、ΔＩは、今回の平均到着間隔Ｉを前回の平均到着間隔Ｉで除算することで算出される。
　フローベース異常検知部１０４は、受信された今回のフロー情報に含まれるパケット数Ｎと、一つ前に出力されたフロー情報に含まれるパケット数Ｎとの比である前回比ΔＮを算出する（Ｓ４０４）。例えば、ΔＮは、今回のパケット数Ｎを前回のパケット数Ｎで除算することで算出される。
　フローベース異常検知部１０４は、パケット数Ｎが１００００以上であるかを判定する（Ｓ４０５）。パケット数Ｎが１００００以上である場合（Ｓ４０５がＹｅｓの場合）、フローベース異常検知部１０４は、選択されたフローＩＤを持つ通信が“フラッディング攻撃”されていると判定する（Ｓ４０６）。つまり、フローベース異常検知部１０４は、パケット数Ｎが予め定められた閾値以上である場合、“フラッディング攻撃”と判定する。
　パケット数Ｎが１００００未満の場合（Ｓ４０５がＮｏの場合）、フローベース異常検知部１０４は、平均到着間隔の前回比ΔＩが１未満であるかを判定する（Ｓ４０７）。平均到着間隔の前回比ΔＩが１未満である場合（Ｓ４０７がＹｅｓの場合）、フローベース異常検知部１０４は、さらにパケット数の前回比ΔＮが１０以上であるかを判定する（Ｓ４０８）。パケット数の前回比ΔＮが１０以上である場合（Ｓ４０８がＹｅｓの場合）、フローベース異常検知部１０４は、選択されたフローＩＤを持つ通信が“フラッディング攻撃”されていると判定する（Ｓ４０６）。つまり、フローベース異常検知部１０４は、平均到着間隔Ｉが減少しており、かつ、パケット数Ｎが増加している（ΔＮが１より大きい第１閾値以上である）場合、“フラッディング攻撃”と判定する。
　パケット数の前回比ΔＮが１０未満である場合（Ｓ４０８がＮｏの場合）、フローベース異常検知部１０４は、パケット数の前回比ΔＮが２以上であるかを判定する（Ｓ４０９）。パケット数の前回比ΔＮが２以上である場合（Ｓ４０９がＹｅｓの場合）、フローベース異常検知部１０４は、選択されたフローＩＤを持つ通信が“なりすまし攻撃”されていると判定する（Ｓ４１０）。つまり、フローベース異常検知部１０４は、平均到着間隔Ｉが減少しており、かつ、パケット数Ｎが増加している（ΔＮが１より大きく、かつ第１閾値より小さい第２閾値以上である）場合、“フラッディング攻撃”と判定する。
　平均到着間隔の前回比ΔＩが１以上か、パケット数の前回比ΔＮが２未満である場合（Ｓ４０７がＮｏである場合、又はＳ４０９がＮｏである場合）、フローベース異常検知部１０４は、選択されたフローＩＤと同一の宛先ＩＰアドレス及び宛先ポート番号を使用している他のフローＩＤの通信を抽出する（Ｓ４１１）。
　フローベース異常検知部１０４は、通信の入れ替わりが発生しているかを判定する（Ｓ４１２）。具体的には、フローベース異常検知部１０４は、選択されたフローＩＤのパケット数Ｎと、抽出された他のフローＩＤのパケット数Ｎとの一方が増加し、他方が減少している場合に、通信の入れ替わりが発生していると判定する。
　通信の入れ替わりが発生している場合（Ｓ４１２がＹｅｓの場合）、フローベース異常検知部１０４は、さらにパケット数の前回比ΔＮが１以上であるかを判定する（Ｓ４１３）。パケット数の前回比ΔＮが１以上である場合（Ｓ４１３がＹｅｓの場合）、フローベース異常検知部１０４は、選択されたフローＩＤを持つ通信が中間者攻撃によって増加している通信と判定して“中間者攻撃（増加）”と判定する（Ｓ４１４）。つまり、フローベース異常検知部１０４は、通信の入れ替わりが発生しており、かつパケット数Ｎが増加している場合、“中間者攻撃（増加）”と判定する。
　パケット数の前回比ΔＮが１未満である場合（Ｓ４１３がＮｏの場合）、フローベース異常検知部１０４は、選択されたフローＩＤを持つ通信が中間者攻撃によって減少している通信と判定して“中間者攻撃（減少）”と判定する（Ｓ４１５）。つまり、フローベース異常検知部１０４は、通信の入れ替わりが発生しており、かつパケット数Ｎが減少している場合、“中間者攻撃（減少）”と判定する。
　通信の入れ替わりが発生していない場合（Ｓ４１２がＮｏの場合）、フローベース異常検知部１０４は、どの攻撃の判定にも該当しなかったとして選択されたフローＩＤを持つ通信は“異常なし”と判定する（Ｓ４１６）。
　フローベース異常検知部１０４は、選択されたフローＩＤを持つ通信が“フラッディング攻撃”、“なりすまし攻撃”、“中間者攻撃（増加）”、“中間者攻撃（減少）”、“異常なし”のいずれかに判定された後、全てのフローＩＤに対し、異常検知の処理を行ったかを判定する（Ｓ４１７）。全てのフローＩＤに対し処理が終了している場合（Ｓ４１７がＹｅｓの場合）、ゾーンＥＣＵは処理を終了する。全てのフローＩＤに対し処理が終了していない場合（Ｓ４１７がＮｏの場合）、フローベース異常検知部１０４は、ステップＳ４０２まで戻り、まだ異常検知の処理をしていないフローＩＤについて同様の処理を行う。
　図１４での異常検知の処理では、異常の判定のためにいくつか具体的な閾値がでてきたが、実際は想定する通信環境に応じて閾値は変化する。また図１４ではパケット数と平均到着間隔というパラメータのみを用いて異常検知を行っているが、他のパラメータを使用して、より検知精度を向上できる。また、フラッディング攻撃、なりすまし攻撃、及び中間者攻撃以外の攻撃も検知が可能である。
　［生成される異常アラートの一例］
　図１５はフローベース異常検知の結果に基づき生成される異常アラートの一例を示す図である。生成される異常アラートには、ＤＰＩルール生成部１０５ＡにてＤＰＩルールを生成するために必要な情報が含まれる。異常アラートは、アラート番号と、異常と判定された通信のフローＩＤと、アラート種類と、プロトコルと、宛先ＥＣＵでのパケット占有率とを含む。
　アラート番号は、異常のあった通信のフローＩＤごとに発行される。なお、中間者攻撃など２以上の通信を合わせて１つの攻撃と考えられる場合は、その２以上の通信に対して同一のアラート番号が割り振られる。フローＩＤは通信パケットのヘッダ情報を表しており、このフローＩＤで識別される通信が異常であるとしてアラートが生成される。
　アラートの種類は、フローベース異常検知によって判定された結果を表している。中間者攻撃は、パケット数が増加する通信とパケット数が減少する通信の２つの通信の相互関係から検知されるため、２種類のフローＩＤに対して異常アラートが生成される。プロトコルは該当のフローＩＤを持つ通信のプロトコルを表し、暗号化通信であるかを判断するために用いられる。
　パケット占有率はＤＰＩルールの処理優先度を設定するためのパラメータであり、該当のフローＩＤを持つパケットがフローＩＤに割り当てられた宛先ＩＰアドレスを持つＥＣＵで通信される全パケットの中でどれだけの割合を占めているかを表している。ただし、アラート種類が“中間者攻撃（減少）”の場合のみ、フローＩＤに割り当てられた宛先ＩＰアドレスではなく、送信元ＩＰアドレスを参照してパケット占有率が計算される。
　［ＤＰＩルール生成フローチャート］
　図１６は、ＤＰＩルール生成処理のフローチャートである。ＤＰＩルール生成部１０５Ａは、フローベース異常検知部１０４にて生成された異常アラートを取得する（Ｓ５０１）。
　ＤＰＩルール生成部１０５Ａは、ＤＰＩルールのルール番号を仮発行する（Ｓ５０２）。例えば、中間者攻撃など同一のアラート番号を持つ異常アラートが複数ある場合は、ＤＰＩルール生成部１０５Ａは、同一のルール番号を仮発行する。またルール番号はＤＰＩルール転送部１０５Ｂにて正式に再発行される。
　ＤＰＩルール生成部１０５Ａは、ＤＰＩルールの適用先を異常アラートに含まれるフローＩＤに割り当てられた宛先ＩＰアドレスを持つＥＣＵに設定する（Ｓ５０３）。ＤＰＩルール生成部１０５Ａは、設定された適用先ＥＣＵでのパケット占有率を異常アラートから抽出し、抽出されたパケット占有率をＤＰＩルールに含まれる処理優先度の値として設定する（Ｓ５０４）。
　ＤＰＩルール生成部１０５Ａは、異常アラートに含まれるアラート種類が“フラッディング攻撃”であるかを判定する（Ｓ５０５）。アラート種類が“フラッディング攻撃”である場合（Ｓ５０５がＹｅｓの場合）、ＤＰＩルール生成部１０５Ａは、ＤＰＩルールに含まれるヘッダ条件に、異常アラートに含まれるフローＩＤに割り当てられた送信元ＩＰアドレス及び宛先ＩＰアドレスを設定する（Ｓ５０６）。
　そして、ＤＰＩルール生成部１０５Ａは、ＥＣＵ管理リストを参照し、フローＩＤから正規のサービスＩＤを確認し（Ｓ５０７）、確認されたサービスＩＤを用いてＤＰＩルールに含まれるチェック内容を設定する（Ｓ５０８）。ＤＰＩルール生成部１０５Ａは、ＤＰＩルールに含まれるチェック時動作として、ＤＰＩルールを発行したゾーンＥＣＵに対し、アラートを通知する処理を設定する（Ｓ５０９）。ＤＰＩルール生成部１０５Ａは、ＤＰＩルールに含まれる監視パケット数をフラッディング攻撃の監視に必要な値（フラッディング攻撃の監視に対応付けられた値）に設定する（Ｓ５１０）。そして、ＤＰＩルール生成部１０５Ａは、ここまでで設定された内容を一つのＤＰＩルールとして統合する（Ｓ５１１）。
　ＤＰＩルール生成部１０５Ａは、生成されたＤＰＩルールを設定された適用先ＥＣＵに転送するようＤＰＩルール転送部１０５Ｂに依頼し（Ｓ５１２）、ＤＰＩルール生成処理を終了する。
　アラート種類が“フラッディング攻撃”でない場合（Ｓ５０５がＮｏの場合）、ＤＰＩルール生成部１０５Ａは、異常アラートに含まれるアラート種類が“なりすまし攻撃”であるかを判定する（Ｓ５１３）。アラート種類が“なりすまし攻撃”である場合（Ｓ５１３がＹｅｓの場合）、ＤＰＩルール生成部１０５Ａは、ＤＰＩルールに含まれるヘッダ条件に異常アラートに含まれるフローＩＤを設定する（Ｓ５１４）。そして、ＤＰＩルール生成部１０５Ａは、ＥＣＵ管理リストを参照してフローＩＤから正規のクライアントＩＤを確認し（Ｓ５１５）、確認されたクライアントＩＤを用いてＤＰＩルールに含まれるチェック内容を設定する（Ｓ５１６）。
　ＤＰＩルール生成部１０５Ａは、ＤＰＩルールに含まれるチェック時動作として、該当のパケットを遮断し、自身の監視パケット数を無制限（∞）と再設定する処理を設定する（Ｓ５１７）。ＤＰＩルール生成部１０５Ａは、ＤＰＩルールに含まれる監視パケット数をなりすまし攻撃の監視に必要な値（なりすまし攻撃の監視に対応付けられた値）に設定する（Ｓ５１８）。そして、ＤＰＩルール生成部１０５Ａは、ここまでで設定された内容を一つのＤＰＩルールとして統合し（Ｓ５１１）、ＤＰＩルールの転送依頼を行い（Ｓ５１２）、ＤＰＩルール生成の処理を終了する。
　アラート種類が“なりすまし攻撃”でない場合（Ｓ５１３がＮｏの場合）、ＤＰＩルール生成部１０５Ａは、異常アラートに含まれるアラート種類が“中間者攻撃（増加）”であるかを判定する（Ｓ５１９）。アラート種類が“中間者攻撃（増加）”である場合（Ｓ５１９がＹｅｓの場合）、ＤＰＩルール生成部１０５Ａは、ＤＰＩルールに含まれるヘッダ条件に、異常アラートに含まれるフローＩＤに割り当てられた送信元ＩＰアドレス及び宛先ＩＰアドレスを設定する（Ｓ５２０）。
　そして、ＤＰＩルール生成部１０５Ａは、ＥＣＵ管理リストを参照しフローＩＤから正規のサービスＩＤを確認し（Ｓ５２１）、確認されたサービスＩＤを用いてＤＰＩルールに含まれるチェック内容を設定する（Ｓ５２２）。ＤＰＩルール生成部１０５Ａは、ＤＰＩルールに含まれるチェック時動作として、ＤＰＩルールを発行したゾーンＥＣＵに対し、アラートを通知する処理を設定する（Ｓ５２３）。ＤＰＩルール生成部１０５Ａは、ＤＰＩルールに含まれる監視パケット数を中間者攻撃の監視に必要な値（中間者攻撃の監視に対応付けられた値）に設定する（Ｓ５２４）。そして、ＤＰＩルール生成部１０５Ａは、ここまでで設定された内容を一つのＤＰＩルールとして統合し（Ｓ５１１）、ＤＰＩルールの転送依頼を行い（Ｓ５１２）、ＤＰＩルール生成の処理を終了する。
　アラート種類が“中間者攻撃（増加）”でない場合（Ｓ５１９がＮｏの場合）、ＤＰＩルール生成部１０５Ａは、異常アラートに含まれるアラート種類が“中間者攻撃（減少）”であると判断する。ＤＰＩルール生成部１０５Ａは、同一のアラート番号を持ち、アラート種類が“中間者攻撃（増加）”である異常アラートに含まれるフローＩＤに割り当てられた送信元のＥＣＵを攻撃ＥＣＵと推定する（Ｓ５２５）。ＤＰＩルール生成部１０５Ａは、アラート種類が“中間者攻撃（減少）”である自身の異常アラートに含まれるフローＩＤから送信元ＥＣＵを抽出し、その送信元ＥＣＵと推定された攻撃ＥＣＵのＩＰアドレスとの組（攻撃ＥＣＵは宛先側とする）をＤＰＩルールに含まれるヘッダ条件に設定する（Ｓ５２６）。
　ＤＰＩルール生成部１０５Ａは、ＤＰＩルールに含まれる適用先ＥＣＵをフローＩＤに割り当てられた送信元ＩＰアドレスのＥＣＵに再設定する（Ｓ５２７）。ＤＰＩルール生成部１０５Ａは、ＤＰＩルールに含まれるチェック内容、チェック時動作及び監視パケット数を、対となるＤＰＩルール、つまり同一のアラート番号を持ち、アラート種類が“中間者攻撃（増加）”である異常アラートから生成されたＤＰＩルールと同じ内容に設定する（Ｓ５２８）。そして、ＤＰＩルール生成部１０５Ａは、ここまでで設定された内容を一つのＤＰＩルールとして統合し（Ｓ５１１）、ＤＰＩルールの転送依頼を行い（Ｓ５１２）、ＤＰＩルール生成の処理を終了する。
　［ＤＰＩルール転送のフローチャート］
　図１７は、ＤＰＩルール転送のフローチャートである。ＤＰＩルール転送部１０５Ｂは、ＥＣＵ管理リストを参照して生成されたＤＰＩルールに含まれる適用先ＥＣＵが自身の管理下のＥＣＵであるかを判定する（Ｓ６０１）。
　適用先ＥＣＵが自身の管理下のＥＣＵである場合（Ｓ６０１がＹｅｓの場合）、ＤＰＩルール転送部１０５Ｂは、ＤＰＩルールに含まれる発行元ＥＣＵを自身に設定し（Ｓ６０２）、発行元のゾーンＥＣＵがわかるようにＤＰＩルール番号を修正し（Ｓ６０３）、全ＤＰＩルール記憶部１０６にＤＰＩルールを保存する（Ｓ６０４）。そしてＤＰＩルール転送部１０５Ｂは、適用先ＥＣＵにＤＰＩルールを転送し（Ｓ６０５）、ＤＰＩルール転送の処理を終了する。
　適用先ＥＣＵが自身の管理下のＥＣＵでない場合（Ｓ６０１がＮｏの場合）、ＤＰＩルール転送部１０５Ｂは、ＥＣＵ管理リストを参照し、ＤＰＩルールに含まれる発行元ＥＣＵを、適用先ＥＣＵを管理する管理ゾーンＥＣＵに設定する（Ｓ６０６）。そしてＤＰＩルール転送部１０５Ｂは、発行元のゾーンＥＣＵがわかるようにＤＰＩルール番号を修正し（Ｓ６０７）、全ＤＰＩルール記憶部１０６にＤＰＩルールを保存し（Ｓ６０８）、ＤＰＩルール転送の処理を終了する。
　［生成されるＤＰＩルールの一例］
　図１８は、異常アラートから生成されるＤＰＩルールの一例を示す図である。図１８では、図１５の異常アラートから生成されたＤＰＩルールを示している。
　ルール番号は適用先ＥＣＵにＤＰＩルールを発行したゾーンＥＣＵがわかるように設定される。つまり、ルール番号は、ＤＰＩルールを発行したゾーンＥＣＵと対応付けられている。例えば、ゾーンＥＣＵ１００ｂが発行元であれば“Ｂ－１”といったアルファベットなどと組み合わせた番号などを発行する。ただし、“中間者攻撃監視”のＤＰＩルールの組に関しては、ＤＰＩアラートを通知するゾーンＥＣＵに合わせた同一の番号が発行される。
　チェック内容及びチェック時動作はフローベース異常検知にて検知された攻撃内容に応じて異なる。
　例えば、フラッディング攻撃では、攻撃ＥＣＵが特定のサービスＩＤのみを使って大量の通信パケットを送り付けていると考えられる。よって、フラッディング攻撃の監視ルール（フラッディング監視）として、１つのサービスＩＤのみを使用しているかの確認が行われる。具体的には、適用先ＥＣＵは、チェック内容として、フローベース異常検知で異常のあった通信のサービスＩＤをＥＣＵ管理リストから取得し、そのサービスＩＤ以外で通信が行われていないか監視する。適用先ＥＣＵは、該当のサービスＩＤ以外の通信を確認した際は、チェック時動作としてＤＰＩルールの発行元のゾーンＥＣＵにＤＰＩアラートを通知する。ゾーンＥＣＵは、フラッディング監視の規定の監視パケット数の監視が終了するまでにＤＰＩアラートの通知が一定量なければその通信を異常な通信と判定する。
　また、例えば、なりすまし攻撃の監視ルール（なりすまし監視）として、適用先ＥＣＵは、正規のクライアントＩＤ以外の通信が行われていないかを監視する。適用先ＥＣＵは、正規以外のクライアントＩＤを用いた通信が確認された際は、その通信を異常と判定し、チェック時動作として該当パケットの遮断を行い、ＤＰＩルールの監視パケット数を無制限（∞）に変更する。
　また、例えば、中間者攻撃の監視ルール（中間者攻撃監視）として、適用先ＥＣＵは、攻撃者と推定されるＥＣＵが同一のサービスＩＤを使用して２つのＥＣＵと同時に通信を行っていないかを確認する。適用先ＥＣＵは、ＤＰＩルールを適用する２つのＥＣＵは指定のサービスＩＤが用いられた通信を確認した際は、同じゾーンＥＣＵにＤＰＩアラートを通知する。ゾーンＥＣＵは２つのＥＣＵからアラートが報告された際に、その通信を異常な通信と判定する。
　また、監視パケット数は監視する攻撃の内容に応じて決定される。例えば、フラッディング監視においては、監視するパケットの通信間隔が短く、処理負荷が大きくなることが見込まれる。よって、処理負荷を低減するために、フラッディング監視では監視パケット数が他のＤＰＩルールと比べて小さく設定される。
　［ＤＰＩルール処理のフローチャート］
　図１９は、ＤＰＩ部１０２及び２０２におけるＤＰＩルール処理のフローチャートである。なお、図１９に示す処理は、例えばバケットが受信される毎に実施される。ＤＰＩ部１０２及び２０２は、パケットを受信し（Ｓ７０１）、自身に適用されているＤＰＩルールの中で最も処理優先度が高いＤＰＩルールを選択する（Ｓ７０２）。ここで、ＤＰＩ部１０２及び２０２では事前にＤＰＩルールを処理優先度が高い順に並べて記憶している。
　ＤＰＩ部１０２及び２０２は、選択されたＤＰＩルールに含まれるヘッダ条件を、受信されたパケットのヘッダが満たすかを判定する（Ｓ７０３）。
　受信されたパケットがＤＰＩルールに含まれるヘッダ条件を満たす場合（Ｓ７０３がＹｅｓの場合）、ＤＰＩ部１０２及び２０２は、パケットがＤＰＩルールに含まれるチェック内容を満たすかを判定する（Ｓ７０４）。
　パケットがＤＰＩルールに含まれるチェック内容を満たす場合（Ｓ７０４がＹｅｓの場合）、ＤＰＩ部１０２及び２０２は、ＤＰＩルールに含まれるチェック時動作を実行する（Ｓ７０５）。パケットがＤＰＩルールに含まれるチェック内容を満たさない場合（Ｓ７０４がＮｏの場合）、ＤＰＩ部１０２及び２０２は、ステップＳ７０５の処理をスキップする。
　その後、ＤＰＩ部１０２及び２０２は、監視済みパケット数のカウントを１増やす（Ｓ７０６）。
　ＤＰＩ部１０２及び２０２は、監視済みパケット数が監視パケット数に到達しているかを判定する（Ｓ７０７）。監視済みパケット数が監視パケット数に到達している場合（Ｓ７０７がＹｅｓの場合）、ＤＰＩ部１０２及び２０２は、ＤＰＩルールを破棄し（Ｓ７０８）、ＤＰＩルールの発行元のゾーンＥＣＵにルールの終了を通知し（Ｓ７０９）、ＤＰＩルール処理を終了する。監視済みパケット数が監視パケット数に到達していない（Ｓ７０７がＮｏの場合）、ＤＰＩ部１０２及び２０２は、ＤＰＩルール処理を終了する。
　受信されたパケットがＤＰＩルールに含まれるヘッダ条件を満さない場合（Ｓ７０３がＮｏの場合）、ＤＰＩ部１０２及び２０２は、他に未処理のＤＰＩルールが存在するかを判定する（Ｓ７１０）。他に未処理のＤＰＩルールが存在する場合（Ｓ７１０がＹｅｓの場合）、ＤＰＩ部１０２及び２０２は、未処理のＤＰＩルールのうち次に処理優先度が高いＤＰＩルールを選択し（Ｓ７１１）、ステップＳ７０３に戻る。他に未処理のＤＰＩルールが存在しない場合（Ｓ７１０がＮｏの場合）、ＤＰＩ部１０２及び２０２は、そのままＤＰＩルール処理を終了する。
　［ＤＰＩアラートの一例］
　図２０は、ＤＰＩアラートの一例を示す図である。ＤＰＩアラートは主に、ＤＰＩ部１０２及び２０２でＤＰＩルールの監視済みパケット数が規定の監視済みパケット数を満たしたときに通知される、もしくは一部のＤＰＩルールのチェック時動作として通知される。
　ＤＰＩアラートはルール番号、ＤＰＩルール名、適用先ＥＣＵ、及びアラート内容を含む。ルール番号は対応するＤＰＩルールのルール番号を示す。したがって、ＥＣＵは、ルール番号を確認することで、ＤＰＩアラートがどのＤＰＩルールに関するアラートなのかを判断することができる。
　ＤＰＩルール名は、ＤＰＩアラートに対応するＤＰＩルールのＤＰＩルール名を示す。適用先ＥＣＵは、ＤＰＩアラートに対応するＤＰＩルールの適用先ＥＣＵを示し、ＤＰＩアラートがどのＥＣＵから通知されたＤＰＩアラートなのかを把握するために用いられる。
　アラート内容は、“ルール終了”又は“チェック該当”を示す。アラート内容として“ルール終了”を含むＤＰＩアラートは、ＤＰＩルールの監視済みパケット数が規定の監視済みパケット数を満たしたことを示す。
　アラート内容として“チェック該当”を含むＤＰＩアラートは、ＤＰＩルールに含まれるチェック内容を満たしたことを示す。
　例えば、図２０に示すルール番号“Ｂ－１”及び“Ｃ－１”は、ＤＰＩルールによる監視が終了し、ルール番号に該当するＤＰＩルールが適用先ＥＣＵにおいて破棄されたことを示す。
　また、例えば、図２０に示すルール番号“Ｂ－２”は、適用先ＥＣＵがＤＰＩルールに含まれるチェック内容を満たすパケットを受信したことを示す。ルール番号“Ｂ－２”のＤＰＩルールは“中間者攻撃監視”であるため、２つのＥＣＵから同一のサービスＩＤを使う通信が確認されたことから、監視対象の通信が異常な通信であると判定できる。
　［ＤＰＩアラート処理のフローチャート］
　図２１は、ゾーンＥＣＵ１００ａ、１００ｂ及び１００ｃでのＤＰＩアラート処理のフローチャートである。ＤＰＩアラート処理部１０５Ｃは、ＤＰＩアラートを受信する（Ｓ８０１）。
　ＤＰＩアラート処理部１０５Ｃは、ＤＰＩアラートに含まれるＤＰＩルール名が“フラッディング監視”であるかを判定する（Ｓ８０２）。ＤＰＩルール名が“フラッディング監視”である場合（Ｓ８０２がＹｅｓの場合）、ＤＰＩアラート処理部１０５Ｃは、アラート内容が“ルール終了”であるかを判定する（Ｓ８０３）。アラート内容が“ルール終了”である場合（Ｓ８０３がＹｅｓの場合）、ＤＰＩアラート処理部１０５Ｃは、同一のルール番号でアラート内容が“チェック該当”のＤＰＩアラートを１００以上受信済みであるかを判定する（Ｓ８０４）。
　“チェック該当”のＤＰＩアラートを１００以上受信済みである場合（Ｓ８０４がＹｅｓの場合）、ＤＰＩアラート処理部１０５Ｃは、単一のサービスＩＤだけの通信でないことが確認できるため、ＤＰＩルールの監視対象の通信を正常と判定する（Ｓ８０５）。そして、ＤＰＩルールの適用先ＥＣＵにて既に該当のＤＰＩルールが破棄されているため、ＤＰＩアラート処理部１０５Ｃは、ゾーンＥＣＵ内の全ＤＰＩルール記憶部１０６から該当のＤＰＩルールを破棄する（Ｓ８０６）。ここでＤＰＩアラート処理部１０５Ｃは、自分以外のゾーンＥＣＵに対してもルールを破棄するよう通知を行う。
　“チェック該当”のＤＰＩアラートを１００以上受信済みでない場合（Ｓ８０４がＮｏの場合）、ＤＰＩアラート処理部１０５Ｃは、ＤＰＩルールの監視対象の通信を単一のサービスＩＤを用いた異常な通信であると判定する（Ｓ８０７）。そしてＤＰＩアラート処理部１０５Ｃは、既存のＤＰＩルールを全ＤＰＩルール記憶部１０６から破棄し、異常な通信を遮断するＤＰＩルールを再発行し（Ｓ８０８）、ＤＰＩアラート処理を終了する。
　アラート内容が“ルール終了”でない場合（Ｓ８０３がＮｏの場合）、つまりアラート内容が“チェック該当”の場合、ＤＰＩアラート処理部１０５Ｃは、ＤＰＩアラート処理を終了し、アラート内容が“ルール終了”であるＤＰＩアラートが通知されるまで待機する。
　ＤＰＩルール名が“フラッディング監視”でない場合（Ｓ８０２がＮｏの場合）、ＤＰＩアラート処理部１０５Ｃは、アラート内容が“ルール終了”であるかを判定する（Ｓ８０９）。アラート内容が“ルール終了”である場合（Ｓ８０９がＹｅｓの場合）、ＤＰＩアラート処理部１０５Ｃは、特に異常と判断する要素が報告されなかったことからＤＰＩルールの監視対象の通信を正常な通信と判定する（Ｓ８１０）。そしてＤＰＩアラート処理部１０５Ｃは、ゾーンＥＣＵ内の全ＤＰＩルール記憶部１０６から該当のＤＰＩルールを破棄する（Ｓ８１１）。
　アラート内容が“ルール終了”でない場合（Ｓ８０９がＮｏの場合）、ＤＰＩルール名が“中間者攻撃監視”かつアラート種類が“チェック該当”のＤＰＩアラートであることがわかる。
　ＤＰＩアラート処理部１０５Ｃは、同一のルール番号かつ異なるＤＰＩルール名の“チェック該当”を受信済みであるかを判定する（Ｓ８１２）。同一のルール番号かつ異なるＤＰＩルール名の“チェック該当”を受信済みである場合（Ｓ８１２がＹｅｓの場合）、攻撃者ＥＣＵが同一のサービスＩＤを用いて通信していることが確認できたため、ＤＰＩアラート処理部１０５Ｃは、ＤＰＩルールの監視対象の通信は異常な通信と判定する（Ｓ８１３）。そしてＤＰＩアラート処理部１０５Ｃは、既存のＤＰＩルールを全ＤＰＩルール記憶部１０６から破棄し、異常な通信を遮断するＤＰＩルールを再発行し（Ｓ８１４）、ＤＰＩアラート処理を終了する。
　同一のルール番号かつ異なるＤＰＩルール名の“チェック該当”を受信済みでない場合（Ｓ８１２がＮｏの場合）、ＤＰＩアラート処理部１０５Ｃは、ＤＰＩアラート処理を終了し、次のＤＰＩアラートが通知されるまで待機する。
　［異常な通信を遮断するＤＰＩルールの一例］
　図２２は、異常な通信を遮断するＤＰＩルールの一例を示す図である。図２２ではＤＰＩルール名として“異常通信”が示される。
　ヘッダ条件には異常な通信のヘッダ情報が指定され、チェック内容は異常な通信に用いられるサービスＩＤ又はクライアントＩＤの確認などが指定される。そして、指定された内容に該当する通信のパケットを遮断する処理がチェック時動作として指定される。
　監視パケット数は無制限（∞）に設定される。これにより、ＥＣＵのＤＰＩ部は勝手にＤＰＩルールを破棄できない。処理優先度は該当のパケットについて再計算するのが望ましいが、元のＤＰＩルールの処理優先度が流用されてもよい。
　（実施の形態２）
　以下、複数のＥＣＵがイーサネットを介して通信する車載ネットワーク（車載ネットワークシステム）を搭載した車両における、異常検知装置（異常検知システム）について説明する。なお、実施の形態１と同様の機能を有する構成要素は、同様の番号を付与して説明を省略する。
　［車載ネットワークシステムの全体構成図］
　図２３は、車載ネットワークシステム２０の全体構成図である。図２３において、車載ネットワークシステム２０は、ＡＤＡＳ　ＥＣＵ２００ａと、ＩＶＩ　ＥＣＵ２００ｂと、ハンドル制御ＥＣＵ２００ｃと、ブレーキ制御ＥＣＵ２００ｄと、シフトレバーＥＣＵ２００ｅと、カメラＥＣＵ２００ｆと、ＬｉＤＡＲ　ＥＣＵ２００ｇと、ゾーンＥＣＵ１１００ａ、１１００ｂ及び１１００ｃとを含む。
　［ゾーンＥＣＵ１１００ａの構成図］
　図２４は、ゾーンＥＣＵ１１００ａの構成図である。なお、ゾーンＥＣＵ１１００ｂ及び１１００ｃもゾーンＥＣＵ１１００ａと同様の構成であるため、これらの説明を省略する。
　図２４において、ゾーンＥＣＵ１１００ａは、通信ポート部１０１と、ＤＰＩ部１０２と、フロー情報収集部１０３と、フローベース異常検知部１０４と、ＤＰＩ制御部１１０５と、全ＤＰＩルール記憶部１０６と、ＥＣＵ管理リスト保存部１０７とを備える。
　ＤＰＩ制御部１１０５は、ＤＰＩルール生成部１１０５Ａと、ＤＰＩルール転送部１１０５Ｂと、ＤＰＩアラート処理部１０５Ｃとを含む。
　ＤＰＩルール生成部１１０５Ａは、フローベース異常検知部１０４にて出力される異常アラート又は各ＥＣＵのＤＰＩ部から出力されるＤＰＩアラートに基づいて、ＤＰＩルールの生成を行う。ＤＰＩルール生成部１１０５Ａは、ＤＰＩルールに含まれるヘッダ条件、チェック内容、チェック時動作、及び監視パケット数を決定する。
　ＤＰＩルール転送部１１０５Ｂは、ＤＰＩルール生成部１１０５Ａにて生成されたＤＰＩルールの適用先を各ＥＣＵの処理負荷状況に応じて決定し、決定された適用先のＥＣＵにＤＰＩルールを転送する。例えば、ＡＤＡＳ　ＥＣＵ２００ａとハンドル制御ＥＣＵ２００ｃとの間の通信を監視する場合において、ＡＤＡＳ　ＥＣＵ２００ａのＤＰＩ部２０２が監視しているパケット数が規定値を超えている場合、ＡＤＡＳ　ＥＣＵ２００ａの代わりにゾーンＥＣＵ１１００ａ又はゾーンＥＣＵ１１００ｂに生成されたＤＰＩルールが転送される。
　またＤＰＩルール転送部１１０５Ｂは、ＤＰＩルールの適用先を決定する際に、適用先の候補となるＥＣＵの通信パケット数とＤＰＩ部での監視パケット数とをフロー情報収集部１０３から受け取る。ＤＰＩルール転送部１１０５Ｂは、それらの情報に基づいてＤＰＩルールの適用先を決定し、処理優先度の算出も行う。
　［処理のシーケンス］
　図２５は、実施の形態２におけるハンドル制御ＥＣＵ２００ｃからＡＤＡＳ　ＥＣＵ２００ａへの攻撃が発生した際の処理シーケンスを示す図である。図２５では、ゾーンＥＣＵ１１００ｂ及び１１００ｃは、フロー情報収集部１０３にてフロー情報を収集し、フローベース異常検知部１０４にて異常検知を行い、その結果を基にＤＰＩルール生成部１１０５ＡにてＤＰＩルールを生成し、各ＥＣＵの処理負荷の状況に応じてＤＰＩルールの適用先を決定し、適用されたＤＰＩルールの監視結果に基づいたセキュリティ対応が行われる。
　ハンドル制御ＥＣＵ２００ｃはＡＤＡＳ　ＥＣＵ２００ａにフラッディング攻撃を行う（Ｓ９０１）。ハンドル制御ＥＣＵ２００ｃとＡＤＡＳ　ＥＣＵ２００ａとの通信経路上に存在するゾーンＥＣＵ１１００ａ及び１１００ｂがパケットをミラーリングして受信し、フロー情報を収集する（Ｓ９０２）。
　ゾーンＥＣＵ１１００ａ、１１００ｂ及び１１００ｃは、ゾーンＥＣＵ１１００ａ、１１００ｂ及び１１００ｃの間で収集されたフロー情報を共有する（Ｓ９０３）。なお、ゾーンＥＣＵ１１００ｃの処理は図２５には図示していない。
　ゾーンＥＣＵ１１００ａ、１１００ｂ及び１１００ｃはそれぞれ共有されたフロー情報を基にフローベース異常検知を行い、ハンドル制御ＥＣＵ２００ｃがＡＤＡＳ　ＥＣＵ２００ａに攻撃していることを検知する。（Ｓ９０４）。ゾーンＥＣＵ１１００ａ、１１００ｂ及び１１００ｃはフローベース異常検知の結果に基づいて、通信を監視するための第１ＤＰＩルールを生成する（Ｓ９０５）。
　ゾーンＥＣＵ１１００ｂは生成された第１ＤＰＩルールの適用先の候補としてＡＤＡＳ　ＥＣＵ２００ａ、ハンドル制御ＥＣＵ２００ｃ、ゾーンＥＣＵ１１００ａ、及びゾーンＥＣＵ１１００ｂを選定し、フロー情報から各ＥＣＵの処理負荷を確認し、確認結果に基づき自身をＤＰＩルールの適用先として判断し、第１ＤＰＩルールを適用する（Ｓ９０６）。
　ゾーンＥＣＵ１１００ａは生成された第１ＤＰＩルールの適用先をフロー情報からゾーンＥＣＵ１１００ｂと判断する（Ｓ９０７）。なお、この判断の方法はＳ９０６と同様である。
　ハンドル制御ＥＣＵ２００ｃはＡＤＡＳ　ＥＣＵ２００ａに対して継続してフラッディング攻撃を行う（Ｓ９０８）。ゾーンＥＣＵ１１００ｂはＤＰＩ部１０２に適用された第１ＤＰＩルールに従ってパケットのペイロード監視を行う（Ｓ９０９）。
　ゾーンＥＣＵ１１００ｂはＤＰＩ部１０２での監視結果に応じてＤＰＩアラートを生成する（Ｓ９１０）。ゾーンＥＣＵ１１００ｂは生成されたＤＰＩアラートに基づき、ハンドル制御ＥＣＵ２００ｃの通信は異常な通信と正式に判定し、異常な通信を遮断する第２ＤＰＩルールを自身のＤＰＩ部１０２に適用する（Ｓ９１１）。
　ハンドル制御ＥＣＵ２００ｃはＡＤＡＳ　ＥＣＵ２００ａに対して継続してフラッディング攻撃を行う（Ｓ９１２）。ゾーンＥＣＵ１１００ｂのＤＰＩ部１０２は、ハンドル制御ＥＣＵ２００ｃからＡＤＡＳ　ＥＣＵ２００ａへの異常な通信を第２ＤＰＩルールに従って遮断する（Ｓ９１３）。
　［ＤＰＩルール生成フローチャート］
　図２６は、ＤＰＩルール生成のフローチャートである。ＤＰＩルール生成部１１０５Ａは、フローベース異常検知部１０４にて生成された異常アラートを取得する（Ｓ１００１）。ＤＰＩルール生成部１１０５Ａは、ＤＰＩルールのルール番号を仮発行する（Ｓ１００２）。
　ＤＰＩルール生成部１１０５Ａは、ＤＰＩアラートに含まれるアラート種類が“フラッディング攻撃”であるかを判定する（Ｓ１００３）。アラート種類が“フラッディング攻撃”である場合（Ｓ１００３がＹｅｓの場合）、ＤＰＩルール生成部１１０５Ａは、ＤＰＩルールに含まれるヘッダ条件に、異常アラートに含まれるフローＩＤに割り当てられた送信元及び宛先ＩＰアドレスを設定する（Ｓ１００４）。
　そして、ＤＰＩルール生成部１１０５Ａは、ＥＣＵ管理リストを参照しフローＩＤから正規のサービスＩＤを確認し（Ｓ１００５）、確認されたサービスＩＤを用いてＤＰＩルールに含まれるチェック内容を設定する（Ｓ１００６）。ＤＰＩルール生成部１１０５Ａは、ＤＰＩルールに含まれるチェック時動作として、ＤＰＩルールを発行したゾーンＥＣＵに対し、アラートを通知する処理を設定する（Ｓ１００７）。ＤＰＩルール生成部１１０５Ａは、ＤＰＩルールに含まれる監視パケット数をフラッディング攻撃の監視に必要な値に設定する（Ｓ１００８）。そして、ＤＰＩルール生成部１１０５Ａは、ここまでで設定された内容を一つのＤＰＩルールとして統合する（Ｓ１００９）。
　ＤＰＩルール生成部１１０５Ａは、生成されたＤＰＩルールに対する適用先の決定、処理優先度の決定、及び転送をＤＰＩルール転送部１１０５Ｂに依頼し（Ｓ１０１０）、ＤＰＩルール生成処理を終了する。
　アラート種類が“フラッディング攻撃”でない場合（Ｓ１００３がＮｏの場合）、ＤＰＩルール生成部１１０５Ａは、異常アラートに含まれるアラート種類が“なりすまし攻撃”であるかを判定する（Ｓ１０１１）。アラート種類が“なりすまし攻撃”である場合（Ｓ１０１１がＹｅｓの場合）、ＤＰＩルール生成部１１０５Ａは、ＤＰＩルールに含まれるヘッダ条件に異常アラートに含まれるフローＩＤを設定する（Ｓ１０１２）。そして、ＤＰＩルール生成部１１０５Ａは、ＥＣＵ管理リストを参照しフローＩＤから正規のクライアントＩＤを確認し（Ｓ１０１３）、確認されたクライアントＩＤを用いてＤＰＩルールに含まれるチェック内容を設定する（Ｓ１０１４）。
　ＤＰＩルール生成部１１０５Ａは、ＤＰＩルールに含まれるチェック時動作として、該当のパケットを遮断し、自身の監視パケット数を無制限（∞）と再設定する処理を設定する（Ｓ１０１５）。ＤＰＩルール生成部１１０５Ａは、ＤＰＩルールに含まれる監視パケット数をなりすまし攻撃の監視に必要な値に設定する（Ｓ１０１６）。そして、ＤＰＩルール生成部１１０５Ａは、ここまでで設定された内容を一つのＤＰＩルールとして統合し（Ｓ１００９）、ＤＰＩルールの転送依頼を行い（Ｓ１０１０）、ＤＰＩルール生成処理を終了する。
　アラート種類が“なりすまし攻撃”でない場合（Ｓ１０１１がＮｏの場合）、ＤＰＩルール生成部１１０５Ａは、異常アラートに含まれるアラート種類が“中間者攻撃（増加）”であるかを判定する（Ｓ１０１７）。アラート種類が“中間者攻撃（増加）”である場合（Ｓ１０１７がＹｅｓの場合）、ＤＰＩルール生成部１１０５Ａは、ＤＰＩルールに含まれるヘッダ条件に異常アラートに含まれるフローＩＤに割り当てられた送信元及び宛先ＩＰアドレスを設定する（Ｓ１０１８）。
　そして、ＤＰＩルール生成部１１０５Ａは、ＥＣＵ管理リストを参照しフローＩＤから正規のサービスＩＤを確認し（Ｓ１０１９）、確認されたサービスＩＤを用いてＤＰＩルールに含まれるチェック内容を設定する（Ｓ１０２０）。ＤＰＩルール生成部１１０５Ａは、ＤＰＩルールに含まれるチェック時動作として、ＤＰＩルールを発行したゾーンＥＣＵに対し、アラートを通知する処理を設定する（Ｓ１０２１）。ＤＰＩルール生成部１１０５Ａは、ＤＰＩルールに含まれる監視パケット数を中間者攻撃の監視に必要な値に設定する（Ｓ１０２２）。そして、ＤＰＩルール生成部１１０５Ａは、ここまでで設定された内容を一つのＤＰＩルールとして統合し（Ｓ１００９）、ＤＰＩルールの転送依頼を行い（Ｓ１０１０）、ＤＰＩルール生成処理を終了する。
　アラート種類が“中間者攻撃（増加）”でない場合（Ｓ１０１７がＮｏの場合）、ＤＰＩルール生成部１１０５Ａは、ＤＰＩルールに含まれるアラート種類が“中間者攻撃（減少）”であると判断する。ＤＰＩルール生成部１１０５Ａは、同一のアラート番号を持ち、アラート種類が“中間者攻撃（増加）”である異常アラートに含まれるフローＩＤに割り当てられた送信元のＥＣＵを攻撃ＥＣＵと推定する（Ｓ１０２３）。ＤＰＩルール生成部１１０５Ａは、アラート種類が“中間者攻撃（減少）”である自身の異常アラートに含まれるフローＩＤから送信元ＥＣＵを抽出し、その送信元ＥＣＵと推定された攻撃ＥＣＵのＩＰアドレスとの組（攻撃ＥＣＵは宛先側とする）をＤＰＩルールのヘッダ条件に設定する（Ｓ１０２４）。ＤＰＩルール生成部１１０５Ａは、ＤＰＩルールに含まれるチェック内容、チェック時動作及び監視パケット数を、対となるＤＰＩルール、つまり同一のアラート番号を持ち、アラート種類が“中間者攻撃（増加）”である異常アラートから生成されたＤＰＩルールと同じ内容に設定する（Ｓ１０２５）。そして、ＤＰＩルール生成部１１０５Ａは、ここまでで設定された内容を一つのＤＰＩルールとして統合し（Ｓ１００９）、ＤＰＩルール転送部１１０５ＢにＤＰＩルールの転送依頼を行い（Ｓ１０１０）、ＤＰＩルール生成処理を終了する。
　［ＤＰＩルール転送処理のフローチャート］
　図２７は、ＤＰＩルール転送処理のフローチャートである。ＤＰＩルール転送部１１０５Ｂは、ＤＰＩルール生成部１１０５Ａにて生成されたＤＰＩルールを受け取る（Ｓ１１０１）。
　ＤＰＩルール転送部１１０５Ｂは、ＤＰＩルールの監視対象パケットが通過する経路上のＥＣＵを選定する（Ｓ１１０２）。経路上に存在するＥＣＵは、監視対象パケットの送信元ＥＣＵ及び宛先ＥＣＵと、送信元ＥＣＵと宛先ＥＣＵとの間の通信経路に存在するゾーンＥＣＵとを含む。図２７では経路上のゾーンＥＣＵとしてゾーンＥＣＵ１００ａ及び１００ｂが選定されている。またゾーンＥＣＵ１００ｂが送信元ＥＣＵを管理するゾーンＥＣＵであることを想定している。
　ＤＰＩルール転送部１１０５Ｂは、選定されたＥＣＵそれぞれのフロー情報を要求し、各ＥＣＵについて、パケット占有率と、ＤＰＩ部でペイロード監視処理が行われる１分あたりのパケット数であるＤＰＩ処理パケット数とを算出する（Ｓ１１０３）。
　ＤＰＩルール転送部１１０５Ｂは、ＤＰＩルールの監視対象パケットが暗号化通信であるかを判定する（Ｓ１１０４）。監視対象パケットが暗号化通信である場合（Ｓ１１０４がＹｅｓの場合）、ＤＰＩルール転送部１１０５Ｂは、暗号化通信の復号が可能である送信元ＥＣＵと宛先ＥＣＵとに候補を絞り、送信元ＥＣＵより宛先ＥＣＵのＤＰＩ処理パケット数が多いかを判定する（Ｓ１１０５）。送信元ＥＣＵより宛先ＥＣＵのＤＰＩ処理パケット数が多い場合（Ｓ１１０５がＹｅｓの場合）、ＤＰＩルール転送部１１０５Ｂは、ＤＰＩルールの適用先を送信元ＥＣＵに設定し、そのＥＣＵでのパケット占有率を処理優先度として設定し、ＤＰＩルールを適用先のＥＣＵに転送する（Ｓ１１０６）。その後、ＤＰＩルール転送部１１０５Ｂは、ＤＰＩルール転送処理を終了する。
　送信元ＥＣＵより宛先ＥＣＵのＤＰＩ処理パケット数が少ない場合（Ｓ１１０５がＮｏの場合）、ＤＰＩルール転送部１１０５Ｂは、ＤＰＩルールの適用先を宛先ＥＣＵに設定し、そのＥＣＵでのパケット占有率を処理優先度として設定し、ＤＰＩルールを適用先のＥＣＵに転送する（Ｓ１１０７）。その後、ＤＰＩルール転送部１１０５Ｂは、ＤＰＩルール転送処理を終了する。
　監視対象パケットが暗号化通信でない場合（Ｓ１１０４がＮｏの場合）、ゾーンＥＣＵでもパケットを復号せず監視可能であるため、ＤＰＩルール転送部１１０５Ｂは、送信元ＥＣＵを管理するゾーンＥＣＵ１１００ｂのＤＰＩ処理パケット数が１００００以上であるかを判定する（Ｓ１１０８）。ゾーンＥＣＵ１１００ｂのＤＰＩ処理パケット数が１００００以上である場合（Ｓ１１０８がＹｅｓの場合）、ＤＰＩルール転送部１１０５Ｂは、もう一つのゾーンＥＣＵでの候補であるゾーンＥＣＵ１１００ａのＤＰＩ処理パケット数が１００００以上であるかを判定する（Ｓ１１０９）。ゾーンＥＣＵ１１００ａのＤＰＩ処理パケット数が１００００以上の場合（Ｓ１１０９がＹｅｓの場合）、ゾーンＥＣＵ側では監視が難しいため、ＤＰＩルール転送部１１０５Ｂは、ステップＳ１１０５を行う。
　ゾーンＥＣＵ１１００ａのＤＰＩ処理パケット数が１００００未満の場合（Ｓ１１０９がＮｏの場合）、ゾーンＥＣＵ１１００ａで監視可能なため、ＤＰＩルール転送部１１０５Ｂは、ＤＰＩルールの適用先をゾーンＥＣＵ１１００ａに設定し、そのＥＣＵでのパケット占有率を処理優先度として設定し、ＤＰＩルールを適用先のＥＣＵに転送する（Ｓ１１１０）。その後、ＤＰＩルール転送部１１０５Ｂは、ＤＰＩルール転送処理を終了する。
　ゾーンＥＣＵ１１００ｂのＤＰＩ処理パケット数が１００００未満である場合（Ｓ１１０８がＮｏの場合）、ゾーンＥＣＵ１１００ｂで監視可能なため、ＤＰＩルール転送部１１０５Ｂは、ＤＰＩルールの適用先をゾーンＥＣＵ１１００ｂに設定し、そのＥＣＵでのパケット占有率を処理優先度として設定し、ＤＰＩルールを適用先のＥＣＵに転送する（Ｓ１１１１）。その後、ＤＰＩルール転送部１１０５Ｂは、ＤＰＩルール転送処理を終了する。
　［適用先・処理優先度を決定するために要求するフロー情報の一例］
　図２８は、ＤＰＩルール転送部１１０５ＢがＤＰＩルールの適用先及び処理優先度を決定するためにフロー情報収集部１０３に要求するフロー情報の一例を示す図である。
　ＤＰＩルール転送部１１０５Ｂは、ＤＰＩルールの適用先を決定する際、フロー情報収集部１０３にＤＰＩルールで監視するパケットのヘッダ条件を通知する。フロー情報収集部１０３は通知されたヘッダ条件のパケットを監視可能なＥＣＵを選定し、ＤＰＩルールの適用先を決定するための比較条件として用いられるフロー情報と、処理優先度を決定するためのフロー情報とを、収集されたフロー情報から抽出し、抽出されたフロー情報をＤＰＩルール転送部１１０５Ｂに転送する。
　図２８ではフロー情報収集部１０３に要求したフロー情報はＤＰＩルール生成時に仮発行したルール番号と紐づけられる。
　図２８では、フロー情報は、暗号化の有無、監視対象パケットの通信量、ＤＰＩルールの適用先候補ＥＣＵ、候補ＥＣＵ全体の通信量、監視対象パケットのパケット占有率、及び候補ＥＣＵでのＤＰＩ処理パケット数を含む。
　暗号化の有無は、対象のヘッダ条件に該当する通信が暗号化を施されているかを示す。暗号化の有無は送信元ＥＣＵと宛先ＥＣＵとの組合せによって判断される。監視対象パケットの通信量は、車載ネットワークシステム２０上で通信されるヘッダ条件に該当するパケットの通信量を示す。
　適用先候補ＥＣＵは、監視対象パケットが通信する際に経由するＥＣＵを示す。パケット占有率は、監視対象パケットのパケット数と適用先候補ＥＣＵ全体で通信されるパケット数との比（％）を示す。つまり、パケット占有率は、適用先候補ＥＣＵ全体で通信されるパケットのパケット数うち、監視対象パケットのパケット数が占める割合を示す。適用先が決定された際は、この値がＤＰＩルールの処理優先度として設定される。
　ＤＰＩ処理パケット数は、適用先候補ＥＣＵのＤＰＩ部が現在、ＤＰＩルールに従ってペイロードの監視処理をしているパケット数を示す。フロー情報収集部１０３は、全ＤＰＩルール記憶部１０６から各ＥＣＵに適用されているＤＰＩルールの情報を入手することで、ＤＰＩ処理パケット数を算出する。この値が大きいほど、各ＥＣＵのＤＰＩ部の処理負荷が大きいことを表す。また、このＤＰＩ処理パケット数は、以上の定義に限定されない。例えば、ＤＰＩ処理パケット数は、ＤＰＩ部１０２及び２０２にてＤＰＩルールと受信パケットとでヘッダチェックを行う回数であってもよい。
　［適用先が動的に変更されたＤＰＩルールの一例］
　図２９は、適用先を動的に変更したＤＰＩルールの一例を示す図である。例えば、図２９に示すルール番号“Ｂ－１１”では、ＤＰＩルールの発行元であるゾーンＥＣＵ１１００ｂにＤＰＩルールが適用される。ルール番号“Ｂ－１２”は中間者攻撃監視のＤＰＩルールであるため、ルール番号“Ｂ－１２”の２つのＤＰＩルールが生成される。一つはゾーンＥＣＵ１１００ｃに適用され、もう片方はブレーキ制御ＥＣＵ２００ｄに適用される。
　（実施の形態３）
　以下、複数のＥＣＵがイーサネットを介して通信する車載ネットワーク（車載ネットワークシステム）を搭載した車両における、異常検知装置（異常検知システム）について説明する。なお、実施の形態１と同様の機能を有する構成要素は、同様の番号を付与して説明を省略する。
　［車載ネットワークシステムの全体構成図］
　図３０は、車載ネットワークシステム３０の全体構成図である。図３０において、車載ネットワークシステム３０は、ＡＤＡＳ　ＥＣＵ２００ａと、ＩＶＩ　ＥＣＵ２００ｂと、ハンドル制御ＥＣＵ２００ｃと、ブレーキ制御ＥＣＵ２００ｄと、シフトレバーＥＣＵ２００ｅと、カメラＥＣＵ２００ｆと、ＬｉＤＡＲ　ＥＣＵ２００ｇと、ゾーンＥＣＵ２１００ａ、２１００ｂ及び２１００ｃとを含む。
　［ゾーンＥＣＵ２１００ａの構成図］
　図３１は、ゾーンＥＣＵ２１００ａの構成図である。なお、ゾーンＥＣＵ２１００ｂ及び２１００ｃもゾーンＥＣＵ２１００ａと同様の構成であるため、これらの説明を省略する。
　図３１において、ゾーンＥＣＵ２１００ａは、通信ポート部１０１と、ＤＰＩ部１０２と、フロー情報収集部１０３と、フローベース異常検知部１０４と、ＤＰＩ制御部２１０５と、全ＤＰＩルール記憶部１０６と、ＥＣＵ管理リスト保存部１０７と、安全性判断部２１０８と、安全監視用ＤＰＩルールリスト保存部２１０９とを備える。
　ＤＰＩ制御部２１０５は、ＤＰＩルール生成部２１０５Ａと、ＤＰＩルール転送部２１０５Ｂと、ＤＰＩアラート処理部１０５Ｃとを含む。
　ＤＰＩルール生成部２１０５Ａは、フローベース異常検知部１０４で生成される異常アラートからＤＰＩルールを生成する。また、ＤＰＩルール生成部２１０５Ａは、安全性判断部２１０８からの指示に応じてＤＰＩルールを生成する。
　安全性判断部２１０８は、フローベース異常検知部１０４からの異常アラートと、ＡＤＡＳ　ＥＣＵ２００ａ及びシフトレバーＥＣＵ２００ｅから受信する車両状態とから、運転者の生命に関わるリスクがあるかを判断し、必要に応じて各ＥＣＵに運転者の安全を確保する命令を行う。また、安全性判断部２１０８は、運転者の安全に関わる機能に攻撃のリスクがある場合、その機能を持つＥＣＵの通信を監視するＤＰＩルールを生成するようにＤＰＩルール生成部２１０５Ａに指示を出す。
　安全監視用ＤＰＩルールリスト保存部２１０９には、安全性判断部２１０８の指示によって生成されるＤＰＩルールの雛型が予め保存されている。ＤＰＩルール生成部２１０５Ａは、安全性判断部２１０８からＤＰＩルール生成の指示を受けた際に、一からＤＰＩルールを作成するのではなく、安全監視用ＤＰＩルールリスト保存部２１０９から対応するＤＰＩルールの雛型を呼び出し、当該雛型を用いてＤＰＩルールを生成する。
　［安全監視用ＤＰＩルールリスト］
　図３２は、安全監視用ＤＰＩルールリスト保存部２１０９に保存される安全監視用ＤＰＩルールリストの一例を示す図である。安全監視用ＤＰＩルールリストに保存されるＤＰＩルールは、ＤＰＩルール名と、ヘッダ条件と、チェック内容と、チェック時動作と、監視パケット数とを含む。ＤＰＩルール生成部２１０５Ａは、安全性判断部２１０８からの指示に従って、必要なＤＰＩルールを安全監視用ＤＰＩルールリスト保存部２１０９に要求する。
　図３２に示す例では、ＤＰＩルール名が緊急停止システム監視とバックモニター監視との２種類のＤＰＩルールが保存されている。緊急停止システム監視のＤＰＩルールは、安全性判断部２１０８がフローベース異常検知部１０４から出力された異常アラートから、車両を緊急停止させるシステムを起動する判断をした際に生成されるＤＰＩルールである。このＤＰＩルールは、車両を緊急停止させる際に使用する制御系ＥＣＵ又はセンサＥＣＵなどに悪意のあるＥＣＵがなりすまし攻撃にて悪意のある通信を行っていないかを判定するために用いられる。そのため正規なクライアントＩＤを用いた通信でなければ、パケットが遮断され、車両の機能が保護される。
　バックモニター監視のＤＰＩルールは、シフトレバーがリバース（Ｒ）シフトの時にＩＶＩとの通信に対する異常アラートが発生した際に生成される。このＤＰＩルールでは、運転者が駐車時に後方確認のため見ているバックモニターに正規なクライアントＩＤを持つ通信以外が行われていないかが監視され、不正なクライアントＩＤを持つ通信パケットはＤＰＩ部１０２及び２０２で遮断される。
　［処理のシーケンス］
　図３３は、実施の形態３におけるハンドル制御ＥＣＵ２００ｃからＡＤＡＳ　ＥＣＵ２００ａへの攻撃が発生した際の処理シーケンスを示す図である。図３３では、緊急停止システムの作動及びその機能の通信を監視するＤＰＩルールが適用され、ＤＰＩ部の監視結果に基づいたセキュリティ対応が行われる。
　ＡＤＡＳ　ＥＣＵ２００ａは自動運転を開始し、そのことをゾーンＥＣＵ２１００ａ、２１００ｂ及び２１００ｃに報告する（Ｓ１２０１）。シフトレバーＥＣＵ２００ｅは定期的にシフトレバーの状態をゾーンＥＣＵ２１００ａ、２１００ｂ及び２１００ｃに報告する（Ｓ１２０２）。なお、ゾーンＥＣＵ２１００ｃの処理は図３３には図示していない。
　ハンドル制御ＥＣＵ２００ｃはＡＤＡＳ　ＥＣＵ２００ａになりすまし攻撃を行う（Ｓ１２０３）。ハンドル制御ＥＣＵ２００ｃとＡＤＡＳ　ＥＣＵ２００ａとの通信経路上に存在するゾーンＥＣＵ２１００ａ及び２１００ｂがパケットをミラーリングしてパケットを受信し、フロー情報を収集する（Ｓ１２０４）。
　ゾーンＥＣＵ２１００ａ、２１００ｂ及び２１００ｃは、ゾーンＥＣＵ２１００ａ、２１００ｂ及び２１００ｃの間で収集されたフロー情報を共有する（Ｓ１２０５）。ゾーンＥＣＵ２１００ａ、２１００ｂ及び２１００ｃはそれぞれ共有されたフロー情報を基にフローベース異常検知を行い、ハンドル制御ＥＣＵ２００ｃがＡＤＡＳ　ＥＣＵ２００ａに攻撃していることを検知する。（Ｓ１２０６）。
　ゾーンＥＣＵ２１００ａ、２１００ｂ及び２１００ｃは、フローベース異常検知によって生成された異常アラートの内容が、車両の安全を脅かすものではないかを判断する安全性判断を行う（Ｓ１２０７）。具体的には、ゾーンＥＣＵ２１００ａ、２１００ｂ及び２１００ｃは、当該異常アラートの内容と、ＡＤＡＳ　ＥＣＵ２００ａ及びシフトレバーＥＣＵ２００ｅから報告されている車両状態とを照らし合わせることで、安全性判断が行われる。
　ゾーンＥＣＵ２１００ａは、安全性判断の結果、自動運転を続けることにリスクがあると判断し、緊急停止を行った後、自動運転システムを停止させる命令を、ＡＤＡＳ　ＥＣＵ２００ａに通知する（Ｓ１２０８）。
　ＡＤＡＳ　ＥＣＵ２００ａは自身を管理するゾーンＥＣＵ２１００ａの指示に従い、緊急停止システムを作動する（Ｓ１２０９）。ゾーンＥＣＵ２１００ａは、緊急停止システムを安全に作動させるため、緊急停止に関わるＥＣＵに、不正な通信が行われていないか監視するＤＰＩルールを配布する（Ｓ１２１０）。
　ＡＤＡＳ　ＥＣＵ２００ａとカメラＥＣＵ２００ｆはゾーンＥＣＵ２１００ａからＤＰＩルールを受信し、受信されたＤＰＩルールをＤＰＩ部２０２に適用する（Ｓ１２１１）。
　ハンドル制御ＥＣＵ２００ｃはＡＤＡＳ　ＥＣＵ２００ａに対して継続してなりすまし攻撃を行う（Ｓ１２１２）。ＡＤＡＳ　ＥＣＵ２００ａは、ＤＰＩルールに従って、ハンドル制御ＥＣＵ２００ｃからの異常な通信を遮断する（Ｓ１２１３）。
　［ゾーンＥＣＵのパケット処理］
　図３４は、実施の形態３におけるゾーンＥＣＵがパケットを受信した際の処理のフローチャートである。通信ポート部１０１は、自身を経由して通信されるパケットをミラーリングして受信する（Ｓ１３０１）。フロー情報収集部１０３は、受信されたパケットからヘッダ情報を抽出してフロー情報を更新する（Ｓ１３０２）。
　フロー情報収集部１０３は、フロー情報を収集する規定の時間を超過していないかを判定する（Ｓ１３０３）。規定時間を超えている場合（Ｓ１３０３がＹｅｓの場合）、フロー情報収集部１０３は、フロー情報を出力する（Ｓ１３０４）。規定時間を超えていない場合（Ｓ１３０３がＮｏの場合）、フロー情報収集部１０３は、最初のステップＳ１３０１に戻る。
　通信ポート部１０１は、出力されたフロー情報を、他のゾーンＥＣＵに転送する（Ｓ１３０５）。また、通信ポート部１０１は、他のゾーンＥＣＵから転送されたフロー情報を受信する（Ｓ１３０６）。そしてフロー情報収集部１０３は、自身で出力したフロー情報と他のゾーンＥＣＵから転送されたフロー情報とを合成する（Ｓ１３０７）。
　フローベース異常検知部１０４は、合成されたフロー情報を基にフローベース異常検知を行い（Ｓ１３０８）、異常があるかどうか判定する（Ｓ１３０９）。異常がある場合（Ｓ１３０９がＹｅｓの場合）、フローベース異常検知部１０４は、異常の内容が記載された異常アラートを生成する（Ｓ１３１０）。異常がない場合（Ｓ１３０９がＮｏの場合）、ゾーンＥＣＵは処理を終了する。
　ＤＰＩルール生成部２１０５Ａは、生成された異常アラートの内容が車両の安全を脅かすものかを、異常アラートの内容を車両状態と照らし合わせて判断する（Ｓ１３１１）。
　ＤＰＩルール生成部２１０５Ａは、安全性の判断結果、車両が危険な状態であるかを判定する（Ｓ１３１２）。
　車両が危険な状態であると判断された場合（Ｓ１３１２がＹｅｓの場合）、ＤＰＩルール生成部２１０５Ａは、安全を確保する行動をＥＣＵに指示し（Ｓ１３１３）、車両の安全を確保するためのＤＰＩルールを生成する（Ｓ１３１４）。車両が危険な状態でないと判断された場合（Ｓ１３１２がＮｏの場合）、ＤＰＩルール生成部２１０５Ａは、ステップＳ１３１３及びＳ１３１４の処理をスキップする。
　ＤＰＩルール生成部２１０５Ａは、生成された異常アラートからＤＰＩルールを生成する（Ｓ１３１５）。ＤＰＩルール生成部２１０５Ａは、生成されたＤＰＩルールを全ＤＰＩルール記憶部１０６に保存する（Ｓ１３１６）。
　ＤＰＩルール転送部２１０５Ｂは、生成されたＤＰＩルールの適用先ＥＣＵが自身の管理ＥＣＵであるかをＥＣＵ管理リストに基づき判定する（Ｓ１３１７）。適用先ＥＣＵが自身の管理ＥＣＵである場合（Ｓ１３１７がＹｅｓの場合）、ＤＰＩルール転送部２１０５Ｂは、ＤＰＩルールを適用先ＥＣＵに転送し（Ｓ１３１８）、ゾーンＥＣＵは、処理を終了する。適用先ＥＣＵが自身の管理ＥＣＵでない場合（Ｓ１３１７がＮｏの場合）、ゾーンＥＣＵは、処理を終了する。
　［安全性判断の処理フローチャート］
　図３５は、安全性判断の処理フローチャートである。安全性判断部２１０８は、フローベース異常検知部１０４からの異常アラートがあるかを判定する（Ｓ１４０１）。異常アラートがある場合（Ｓ１４０１がＹｅｓの場合）、安全性判断部２１０８は、異常アラートの対象の通信がＡＤＡＳ　ＥＣＵ２００ａとの通信であるかを判定する（Ｓ１４０２）。
　異常アラートの対象の通信がＡＤＡＳ　ＥＣＵ２００ａとの通信である場合（Ｓ１４０２がＹｅｓの場合）、安全性判断部２１０８は、自動運転中であるかを判定する（Ｓ１４０３）。自動運転中である場合（Ｓ１４０３がＹｅｓの場合）、安全性判断部２１０８は、緊急停止システムの作動をＡＤＡＳ　ＥＣＵ２００ａに指示し、そのことを運転者にも通知する（Ｓ１４０４）。そして、安全性判断部２１０８は、緊急停止システム監視用のＤＰＩルールの生成をＤＰＩルール生成部２１０５Ａに指示する（Ｓ１４０５）。
　自動運転中でない場合（Ｓ１４０３がＮｏの場合）、安全性判断部２１０８は、シフトレバーがドライブ（Ｄ）シフトであるかを判定する（Ｓ１４０６）。シフトレバーがＤシフトである場合（Ｓ１４０６がＹｅｓの場合）、安全性判断部２１０８は、ドライブアシストの停止をＡＤＡＳ　ＥＣＵ２００ａに指示し、そのことを運転者にも通知する（Ｓ１４０７）。
　シフトレバーがＤシフトでない場合（Ｓ１４０６がＮｏの場合）、安全性判断部２１０８は、シフトレバーがリバース（Ｒ）シフトであるかを判定する（Ｓ１４０８）。シフトレバーがＲシフトである場合（Ｓ１４０８がＹｅｓの場合）、安全性判断部２１０８は、パーキングアシストの停止をＡＤＡＳ　ＥＣＵ２００ａに指示し、そのことを運転者にも通知する（Ｓ１４０９）。シフトレバーがＲシフトでない場合（Ｓ１４０８がＮｏの場合）、安全性判断部２１０８は、安全性判断の処理を終了する。
　異常アラートの対象の通信がＡＤＡＳ　ＥＣＵ２００ａとの通信でない場合（Ｓ１４０２がＮｏの場合）、安全性判断部２１０８は、異常アラートの対象の通信がＩＶＩ　ＥＣＵ２００ｂとの通信であるかを判定する（Ｓ１４１０）。異常アラートの対象の通信がＩＶＩ　ＥＣＵ２００ｂとの通信である場合（Ｓ１４１０がＹｅｓの場合）、安全性判断部２１０８は、シフトレバーがリバース（Ｒ）シフトであるかを判定する（Ｓ１４１１）。シフトレバーがＲシフトである場合（Ｓ１４１１がＹｅｓの場合）、安全性判断部２１０８は、バックモニター監視用のＤＰＩルールの生成をＤＰＩルール生成部２１０５Ａに指示する（Ｓ１４１２）。
　異常アラートがでている通信がＩＶＩ　ＥＣＵ２００ｂとの通信でない場合（Ｓ１４１０がＮｏの場合）、又はシフトレバーがＲシフトでない場合（Ｓ１４１１がＮｏの場合）、安全性判断部２１０８は、安全性判断の処理を終了する。フローベース異常検知部１０４からの異常アラートがない場合（Ｓ１４０１がＮｏの場合）、安全性判断部２１０８は、安全性判断の処理を終了する。
　［安全監視用のＤＰＩルール生成処理のフローチャート］
　図３６は、実施の形態３におけるＤＰＩルール生成部２１０５Ａによる処理のフローチャートである。ＤＰＩルール生成部２１０５Ａは、安全性判断部２１０８からＤＰＩルール生成の指示を受ける（Ｓ１５０１）。
　ＤＰＩルール生成部２１０５Ａは、安全性判断部２１０８からの指示が緊急停止システム監視用のＤＰＩルールの生成かを判定する（Ｓ１５０２）。安全性判断部２１０８からの指示が緊急停止システム監視用のＤＰＩルールの生成である場合（Ｓ１５０２がＹｅｓの場合）、ＤＰＩルール生成部２１０５Ａは、緊急停止システム監視用のＤＰＩルールを安全監視用ＤＰＩルールリスト保存部２１０９に要求し、緊急停止システム監視用のＤＰＩルールを取得する（Ｓ１５０３）。
　ＤＰＩルール生成部２１０５Ａは、ＤＰＩルール転送部２１０５Ｂに、緊急停止システム監視用のＤＰＩルールの適用先決定、処理優先度の決定、及び適用先へのＤＰＩルールの転送を依頼し（Ｓ１５０４）、処理を終了する。
　安全性判断部２１０８からの指示が緊急停止システム監視用のＤＰＩルールの生成でない場合（Ｓ１５０２がＮｏの場合）、ＤＰＩルール生成部２１０５Ａは、バックモニター監視用のＤＰＩルールを安全監視用ＤＰＩルールリスト保存部２１０９に要求し、バックモニター監視用のＤＰＩルールを取得する（Ｓ１５０５）。そしてＤＰＩルール生成部２１０５Ａは、ＤＰＩルール転送部２１０５Ｂに、安全監視用のＤＰＩルールの適用先決定、処理優先度の決定、及び適用先へのＤＰＩルールの転送を依頼し（Ｓ１５０４）、処理を終了する。
　［安全監視用ＤＰＩルールの一例］
　図３７は、生成された安全監視用ＤＰＩルールの一例を示す図である。図３７に示すＤＰＩルールは自動運転時にＡＤＡＳ　ＥＣＵ２００ａで異常が発生した際に生成された緊急停止システム監視用のＤＰＩルールである。そのため、ＤＰＩルールの発行元は、ＡＤＡＳ　ＥＣＵ２００ａを管理するゾーンＥＣＵ２１００ａである。ＤＰＩルールの各処理優先度はＤＰＩルール転送部２１０５Ｂで算出される。また、ＤＰＩルールはＤＰＩルール転送部２１０５Ｂにより転送される。
　［その他変形例］
　なお、本開示を上記各実施の形態に基づいて説明してきたが、本開示は、上記各実施の形態に限定されないのはもちろんである。
　（１）上記の実施の形態では、車載ネットワークにイーサネットが使用される例を示したが、これに限定されない。例えば、車載ネットワークに、ＣＡＮ、ＣＡＮ－ＦＤ（Ｆｌｅｘｉｂｌｅ－Ｄａｔａｒａｔｅ）、イーサネット、ＬＩＮ、又はＦｌｅｘＲａｙ（登録商標）が用いられてもよいし、これらの２以上の組み合わせて用いられてもよい。
　（２）上記実施の形態では、フロー情報の収集をゾーンＥＣＵが行っているが、ゾーンＥＣＵ以外が行わず、ゾーンＥＣＵ以外が行ってもよい。例えば、ヘッドユニット、セントラルＥＣＵ、又はイーサネットスイッチなどがフロー情報の収集を行ってもよい。
　（３）上記の実施の形態では、フローを特定するための情報として、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、及びプロトコル番号の組が用いられたが、フローを特定するための情報は、これらに限定されない。例えば、フローを特定するための情報として、これらに加え、又はこれらの少なくとも一部の代わりに、Ｖｉｒｔｕａｌ　ＬＡＮに用いられるＶ－ＬＡＮ　ＩＤが用いられてもよい。また、ＣＡＮ通信などが用いられる場合に、フローを特定するための情報として、通信データの識別子であるＣＡＮ　ＩＤが用いられてもよい。これによりフローの定義がより柔軟となり、ネットワークに適したフロー情報の収集が可能となる。
　（４）上記の実施の形態では、フローベース異常検知に用いるフロー情報として、パケット数と平均到着間隔とが用いられたが、フローベース異常検知に用いるフロー情報はこれに限定されない。例えば、平均パケット長又はタイムスタンプなどが用いられてもよい。
　（５）上記の実施の形態では、フローベース異常検知後に、ペイロードベースの異常検知機能であるＤＰＩが用いられたが、ＤＰＩ以外が用いられてもよい。例えば、ＡＩベースの異常検知機能が用いられてもよい。
　（６）上記の実施の形態では、各ＥＣＵは、ＤＰＩ部による監視結果に基づいてＤＰＩルールの破棄を適宜行っているが、ゾーンＥＣＵが状況に応じて各ＥＣＵにＤＰＩルールの破棄を命令してもよい。
　（７）上記の実施の形態では、規定のパケット数の監視を行った際にＤＰＩルールの破棄が行われているが、ＤＰＩルールを破棄する条件はこれに限定されない。例えば、ＤＰＩルールを適用してから一定の時間が経過した際にＤＰＩルールが破棄されてもよいし、ＤＰＩ部に適用されたＤＰＩルール数が規定の数を超えた際に監視の優先度が低いＤＰＩルールから破棄されてもよい。
　（８）上記の実施の形態では、通信パケットが暗号化されている際は送信元ＥＣＵと宛先ＥＣＵとにＤＰＩルールが適用されたが、ゾーンＥＣＵを含めた他のＥＣＵが暗号化されたパケットを復号可能であれば、ゾーンＥＣＵを含めた他のＥＣＵにＤＰＩルールが適用されてもよい。
　（９）上記の実施の形態では、ＡＤＡＳ　ＥＣＵとＩＶＩ　ＥＣＵとに関わる通信に対し、フローベース異常検知部が異常を検知した場合に、安全監視用のＤＰＩルールが適用される例を示しているが、異常を検知する対象の通信はこれに限定されない。例えば、任意の制御系ＥＣＵ又はセンサ系ＥＣＵと、他の任意の制御系ＥＣＵ又はセンサ系ＥＣＵとに関わる通信で異常を検知した場合に同様の処理が適用されてもよい。また、これらを組み合わせた２以上の異常を検知した場合に同様の処理が適用されてもよい。
　（１０）上記の実施の形態では、車両状態として、シフトレバー状態と自動運転中かとを参照しているが、参照される車両状態はこれに限定されない。例えば、参照される車両状態は、自動駐車中、クルーズコントロール中、ソフトウェア更新中、車両診断中、及びインターネット接続中の少なくとも一つを含んでもよい。また、このような車両状態を参照してＤＰＩルールの生成、追加、変更、有効化、及び無効化の少なくとも一つが行われてもよい。
　（１１）上記の実施の形態では、 ＤＰＩ部での処理パケット数に基づいて、ＤＰＩルールの適用先を設定しているが、ＤＰＩルールの適用先を設定する方法はこれに限らない。例えば、フローベース異常検知部による異常検知結果に基づいてＤＰＩルールの適用先が決定されてもよい。例えば、フローベース異常検知部がフラッディング攻撃を検知した場合、送信元ＥＣＵに近いゾーンＥＣＵに対するＤＰＩルールの適用が優先される。これにより、ＤＰＩ部にて異常を検知した際に異常パケットのドロップ処理をゾーンＥＣＵで行うことができる。
　（１２）上記の実施の形態における各装置を構成する構成要素の一部又は全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ　Ｓｃａｌｅ　Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されても良い。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ及びＲＡＭ等を含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又は全部を含むように１チップ化されても良い。また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ又はウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現されても良い。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）、又はＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。更には、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。
　（１３）上記各装置を構成する構成要素の一部又は全部は、各装置に脱着可能なＩＣカード又は単体のモジュールから構成されても良い。ＩＣカード又はモジュールは、マイクロプロセッサ、ＲＯＭ及びＲＡＭ等から構成されるコンピュータシステムである。ＩＣカード又はモジュールは、上記の超多機能ＬＳＩを含んでも良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、ＩＣカード又はモジュールは、その機能を達成する。このＩＣカード又はこのモジュールは、耐タンパ性を有してもよい。
　（１４）本開示の一態様は、異常検知の方法をコンピュータにより実現するプログラム（コンピュータプログラム）であっても良いし、コンピュータプログラムからなるデジタル信号であっても良い。また、本開示の一態様は、コンピュータプログラム又はデジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕｅ―ｒａｙ（登録商標）　Ｄｉｓｃ）、又は半導体メモリ等であっても良い。また、本開示の一態様は、これらの記録媒体に記録されているデジタル信号であっても良い。また、本開示の一態様は、コンピュータプログラム又はデジタル信号を、電気通信回線、無線或いは有線通信回線、インターネットを代表とするネットワーク、又は、データ放送等を経由して伝送するものとしても良い。また、本開示の一態様は、マイクロプロセッサとメモリを備えたコンピュータシステムであっても良い。メモリは、上記コンピュータプログラムを記録しており、マイクロプロセッサは、コンピュータプログラムに従って動作しても良い。また、本開示の一態様は、プログラム若しくはデジタル信号を記録媒体に記録して移送することにより、又は、プログラム若しくはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施されてもよい。
　（１５）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本開示の範囲に含まれる。
　本開示は、車載ネットワークシステムにおいて、通信の異常を検知する装置及び通信の異常を検知する方法に有用である。
　１０、２０、３０　車載ネットワークシステム
　１００ａ、１００ｂ、１００ｃ、１１００ａ、１１００ｂ、１１００ｃ、２１００ａ、２１００ｂ、２１００ｃ　ゾーンＥＣＵ
　１０１、２０１　通信ポート部
　１０２、２０２　ＤＰＩ部
　１０３　フロー情報収集部
　１０４　フローベース異常検知部
　１０５、１１０５、２１０５　ＤＰＩ制御部
　１０５Ａ、１１０５Ａ、２１０５Ａ　ＤＰＩルール生成部
　１０５Ｂ、１１０５Ｂ、２１０５Ｂ　ＤＰＩルール転送部
　１０５Ｃ　ＤＰＩアラート処理部
　１０６　全ＤＰＩルール記憶部
　１０７　ＥＣＵ管理リスト保存部
　２００ａ　ＡＤＡＳ　ＥＣＵ
　２００ｂ　ＩＶＩ　ＥＣＵ
　２００ｃ　ハンドル制御ＥＣＵ
　２００ｄ　ブレーキ制御ＥＣＵ
　２００ｅ　シフトレバーＥＣＵ
　２００ｆ　カメラＥＣＵ
　２００ｇ　ＬｉＤＡＲ　ＥＣＵ
　２０３　アプリ部
　２１０８　安全性判断部
　２１０９　安全監視用ＤＰＩルールリスト保存部

Claims (13)

  1. 　１以上の上位電子制御装置が配置された上位ネットワークと、１以上の下位電子制御装置が配置された下位ネットワークとを含む階層構造を有する車載ネットワークにおける上位電子制御装置による異常検知方法であって、
    　前記車載ネットワークの所定の観測箇所において受信されるメッセージのヘッダ情報によって分類されるフローごとの統計情報であるフロー情報を収集し、
    　前記フロー情報に基づいて異常検知を行い、
    　前記異常検知の結果に基づいて、ＤＰＩ（Ｄｅｅｐ　Ｐａｃｋｅｔ　Ｉｎｓｐｅｃｔｉｏｎ）ルールの生成、追加、削除、変更、有効化及び無効化のいずれかを行い、
    　前記ＤＰＩルールは、前記１以上の下位電子制御装置における前記メッセージの監視に用いられ、
    　前記ＤＰＩルールは、前記メッセージに含まれるヘッダ情報及びペイロード情報の条件と、前記条件に合致するメッセージを受信した場合の処理内容とを示す
    　異常検知方法。
  2. 　前記フロー情報は、フローごとのメッセージの受信量に関する情報を含み、
    　前記異常検知方法は、さらに、
    　前記情報に基づいて、前記ＤＰＩルールを含む１以上のＤＰＩルールのそれぞれについて、前記メッセージの監視の処理の順番を示す処理優先度を決定する、
    　請求項１記載の異常検知方法。
  3. 　前記異常検知方法は、さらに、
    　前記異常検知で検知された異常の内容と、監視する前記メッセージの単位時間あたりのメッセージ数とに応じて、前記ＤＰＩルールに従ったメッセージの監視を有効化する時間、又は前記ＤＰＩルールに従った前記メッセージの前記監視を実施するメッセージ上限数を決定する、
    　請求項２記載の異常検知方法。
  4. 　前記ＤＰＩルールは、前記１以上の下位電子制御装置の間で送受信されるメッセージに含まれるサービス情報又はクライアント情報を示し、
    　前記メッセージの前記監視では、メッセージのサービス情報又はクライアント情報が前記ＤＰＩルールで示される前記サービス情報又は前記クライアント情報と一致しない場合、当該メッセージはドロップされる、
    　請求項１記載の異常検知方法。
  5. 　前記異常検知方法は、さらに、
    　前記１以上の下位電子制御装置から出力された前記監視の結果に基づいて前記ＤＰＩルールを追加、変更、有効化又は無効化する、
    　請求項１記載の異常検知方法。
  6. 　前記異常検知方法は、さらに、
    　シフトレバー状態、自動運転中、自動駐車中、クルーズコントロール中、ソフトウェア更新中、車両診断中、及びインターネット通信接続中の少なくとも一つを含む車両状態と、前記異常検知の結果とに応じて、前記ＤＰＩルールを追加、変更、有効化又は無効化する、
    　請求項１記載の異常検知方法。
  7. 　前記異常検知方法は、さらに、
    　前記１以上の下位電子制御装置に含まれる、前記異常検知において異常と判定された前記メッセージの送信元又は宛先である１つの下位電子制御装置の前記車両状態に応じてＤＰＩルールで示される前記処理内容を決定する、
    　請求項６記載の異常検知方法。
  8. 　前記異常検知方法は、さらに、
    　前記１以上の下位電子制御装置から、前記ＤＰＩルールに従い監視される対象のメッセージの送信元の第１電子制御装置と、当該メッセージの宛先の第２電子制御装置とを選択し、
    　前記１以上の上位電子制御装置から、前記第１電子制御装置と前記第２電子制御装置との間に配置されており、前記対象のメッセージが経由する少なくとも１つの第３電子制御装置を選択し、
    　選択された前記第１電子制御装置、前記第２電子制御装置及び前記少なくとも１つの第３電子制御装置のうち、メッセージ処理にかかる処理負荷量が最も小さい電子制御装置に対し、前記ＤＰＩルールを適用する、
    　請求項１記載の異常検知方法。
  9. 　前記異常検知方法は、さらに、
    　前記フロー情報に基づいて、前記第１電子制御装置、前記第２電子制御装置及び前記少なくとも１つの第３電子制御装置の各々の通信量を算出し、
    　前記１以上の下位電子制御装置で有効化されている１以上のＤＰＩルールと、前記通信量とから前記処理負荷量を算出する、
    　請求項８記載の異常検知方法。
  10. 　前記異常検知方法は、さらに、
    　前記異常検知で検知された異常内容が前記車載ネットワークに負荷がかかる異常である場合、前記少なくとも１つの第３電子制御装置のうち、前記第１電子制御装置に最も近い第３電子制御装置に前記ＤＰＩルールを適用する、
    　請求項８記載の異常検知方法。
  11. 　前記異常検知方法は、さらに、
    　前記上位電子制御装置において前記ＤＰＩルールを用いてメッセージを監視する
    　請求項１記載の異常検知方法。
  12. 　１以上の上位電子制御装置が配置された上位ネットワークと、１以上の下位電子制御装置が配置された下位ネットワークとを含む階層構造を有する車載ネットワークにおける上位電子制御装置に含まれる異常検知装置であって、
    　前記車載ネットワークの所定の観測箇所において受信されるメッセージのヘッダ情報によって分類されるフローごとの統計情報であるフロー情報を収集する収集部と、
    　前記フロー情報に基づいて異常検知を行う異常検知部と、
    　前記異常検知の結果に基づいて、ＤＰＩ（Ｄｅｅｐ　Ｐａｃｋｅｔ　Ｉｎｓｐｅｃｔｉｏｎ）ルールの生成、追加、削除、変更、有効化及び無効化のいずれかを行う制御部と、を備え、
    　前記ＤＰＩルールは、前記１以上の下位電子制御装置における前記メッセージの監視に用いられ、
    　前記ＤＰＩルールは、前記メッセージに含まれるヘッダ情報及びペイロード情報の条件と、前記条件に合致するメッセージを受信した場合の処理内容とを示す
    　異常検知装置。
  13. 　請求項１記載の異常検知方法をコンピュータに実行させる
    　プログラム。
PCT/JP2024/027060 2023-08-03 2024-07-30 異常検知方法、異常検知装置及びプログラム Pending WO2025028500A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
PCT/JP2023/028483 WO2025027863A1 (ja) 2023-08-03 2023-08-03 異常検知システム
JPPCT/JP2023/028483 2023-08-03

Publications (1)

Publication Number Publication Date
WO2025028500A1 true WO2025028500A1 (ja) 2025-02-06

Family

ID=94394776

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/JP2023/028483 Pending WO2025027863A1 (ja) 2023-08-03 2023-08-03 異常検知システム
PCT/JP2024/027060 Pending WO2025028500A1 (ja) 2023-08-03 2024-07-30 異常検知方法、異常検知装置及びプログラム

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/028483 Pending WO2025027863A1 (ja) 2023-08-03 2023-08-03 異常検知システム

Country Status (1)

Country Link
WO (2) WO2025027863A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008060763A (ja) * 2006-08-30 2008-03-13 Alaxala Networks Corp ネットワークノード
CN113055388A (zh) * 2021-03-16 2021-06-29 烽火通信科技股份有限公司 一种基于生成对抗网络的深度包检测方法与系统
WO2021241354A1 (ja) * 2020-05-26 2021-12-02 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 異常検知装置、異常検知システムおよび異常検知方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021002010A1 (ja) * 2019-07-04 2021-01-07 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 不正フレーム検知装置および不正フレーム検知方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008060763A (ja) * 2006-08-30 2008-03-13 Alaxala Networks Corp ネットワークノード
WO2021241354A1 (ja) * 2020-05-26 2021-12-02 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 異常検知装置、異常検知システムおよび異常検知方法
CN113055388A (zh) * 2021-03-16 2021-06-29 烽火通信科技股份有限公司 一种基于生成对抗网络的深度包检测方法与系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TSUYOSHI KISHIKAWA, TAKAHIRO ADACHI, RYO HIRANO, YOSHIHIRO UJIIE, TOMOYUKI HAGA, HIDEKI MATSUSHIMA: "1F1-4 Flow-based IDS for Automotive Ethernet: Flow Analysis of Attacks on SOME/IP", PREPRINTS OF THE 38TH SYMPOSIUM ON CRYPTOGRAPHY AND INFORMATION SECURITY; SCIS 2021; JANUARY 19-22, 2021, vol. 38, 22 January 2021 (2021-01-22) - 22 January 2021 (2021-01-22), pages 1 - 8, XP009560744 *

Also Published As

Publication number Publication date
WO2025027863A1 (ja) 2025-02-06

Similar Documents

Publication Publication Date Title
EP3995978B1 (en) Abnormality detection device and abnormality detection method
JP7182564B2 (ja) 不正検知装置、車載ネットワークシステム、および、不正検知方法
CN103609070B (zh) 网络流量检测方法、系统、设备及控制器
CN108141416B (zh) 一种报文处理方法、计算设备以及报文处理装置
CN112889259B (zh) 不正常帧检测装置以及不正常帧检测方法
JP6495050B2 (ja) コンピュータ実装システム、及び、ネットワーク評価を利用したセキュアパスの選択方法
US10680893B2 (en) Communication device, system, and method
CN108092934A (zh) 安全服务系统及方法
KR101966345B1 (ko) Can 통신 기반 우회 공격 탐지 방법 및 시스템
EP3534571B1 (en) Service packet transmission method, and node apparatus
CN109412850B (zh) 消息订阅控制方法及装置
JP7620014B2 (ja) 異常検知装置、異常検知システムおよび異常検知方法
US11330017B2 (en) Method and device for providing a security service
US9298175B2 (en) Method for detecting abnormal traffic on control system protocol
CN118511489A (zh) 异常检测装置以及异常检测方法
US12021658B2 (en) Switch device, in-vehicle communication system, and communication method
KR101881061B1 (ko) 모드 변경이 가능한 양방향 통신 장치 및 방법
CN112738120A (zh) 基于蜜罐的数据处理方法、装置、系统以及电子设备
KR102067186B1 (ko) 분리된 망 사이의 데이터 통신을 지원하는 장치 및 그 방법
WO2025028500A1 (ja) 異常検知方法、異常検知装置及びプログラム
CN107210969B (zh) 一种基于软件定义网络的数据处理方法及相关设备
KR20200007060A (ko) 분리된 망 사이의 데이터 통신을 지원하는 장치 및 그 방법
US20220038431A1 (en) A Secure Multi-Layered Infrastructure Monitoring and Remote Connectivity System and Method
JP6877278B2 (ja) 中継装置
US10616094B2 (en) Redirecting flow control packets

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24849151

Country of ref document: EP

Kind code of ref document: A1