Monitoring device, monitoring method, and monitoring program

Abstract

This monitoring device uses a normal communication model for communication between vehicle ECUs to determine whether or not each packet transmitted / received to / from the ECUs is abnormal. When the monitoring device has determined that one of the packets transmitted / received to / from the ECUs is abnormal, the monitoring device determines that a series of packets transmitted from the same transmission source ECU that has transmitted the packet determined to be abnormal are abnormal on the basis of a session ID that indicates a communication order and is included in header information of the packet determined to be abnormal. Then, the monitoring device outputs information on the packet determined to be abnormal as an abnormality detection result.

Description

[Technical field]

[0001] The present invention relates to a monitoring device, a monitoring method, and a monitoring program. [Background technology]

[0002] Previously, vehicles have begun to wirelessly communicate with external networks, such as external servers, and the risk of cyber attacks has increased, just as with IT devices. Research on cyber attacks on vehicles has shown that attackers can exploit vulnerabilities in wireless communications to infiltrate the in-vehicle network, spoof normal control communications to send fraudulent communications, and drive the vehicle illegally, causing accidents.

[0003] Here, CAN, FlexRay, and the like have been used as communication standards for in-vehicle networks, but due to the need for increased communication speed and data volume, in-vehicle Ethernet (registered trademark) communication has been standardized.

[0004] There are several in-vehicle Ethernet communication standards depending on the application, including SOME / IP (Scalable service-Oriented MiddlewarE over IP) and SOME / IP-SD (Scalable service-Oriented MiddlewarE over IP-Service Discovery), which are substitutes for the general vehicle control communications commonly used in CAN, etc. Attack detection technologies related to SOME / IP and SOME / IP-SD are mainly methods that detect attacks based on predetermined signatures (for example, see Non-Patent Documents 1 and 2). [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] Nadine Herold, Stephan-APosselt, Oliver Hanka, et al., “Anomaly Detection for SOME / IP using Complex Event Processing,” IEEE / IFIP NOMS Workshop DISSECT 2016 [Non-Patent Document 2] Tobias Gehrmann, Paul Duplys, “Intrusion Detection for SOME / IP: Challenges and Opportunities,” IEEE EuromicroConference on Digital System Design (DSD) 2020 Summary of the Invention [Problem to be solved by the invention]

[0006] However, detection based on the above signatures may miss new attacks. In addition, existing technologies use packet information at lower layers than SOME / IP and SOME / IP-SD, such as IP addresses and MAC addresses (for example, packet information from layers 1 to 4). Here, the in-vehicle network is a static network in which the information of the communication partner does not change frequently. In addition, if an attacker obtains a vehicle of the same model as the vehicle being attacked and reverse engineers it, the IP address / MAC address in the control communication within the in-vehicle network may be spoofed, which may cause the attack detector to miss the attack.

[0007] In addition, if a repeater hub exists in the in-vehicle network, depending on the installation location of the attack detector, it may appear that there are multiple terminals with the same IP address / MAC address, and therefore the attack detector cannot detect attacks with high accuracy.

[0008] Therefore, an object of the present invention is to solve the above-mentioned problems and to accurately detect attacks in SOME / IP communication and SOME / IP-SD communication. [Means for solving the problem]

[0009] In order to solve the above-mentioned problems, the present invention is characterized by comprising a first judgment unit that uses a normal communication model of communication between ECUs of a vehicle to judge whether or not each packet transmitted and received by the ECU is abnormal; a second judgment unit that, when any packet is judged to be abnormal by the first judgment unit, judges a series of packets from the same service and the same source as the packet judged to be abnormal to be abnormal based on a Session ID representing a communication order contained in header information of the packet judged to be abnormal; and an output processing unit that outputs information on the packets judged to be abnormal by the first judgment unit and information on the packets judged to be abnormal by the second judgment unit. Effect of the Invention

[0010] According to the present invention, attacks in SOME / IP communication and SOME / IP-SD communication can be detected with high accuracy. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram for explaining a retroactive determination executed by a monitoring device. [Diagram 2] FIG. 2 is a diagram for explaining feature amounts used when the monitoring device detects an anomaly. [Diagram 3] FIG. 3 is a diagram illustrating an example of the configuration of a system including a monitoring device. [Figure 4] FIG. 4 is a diagram showing header information of SOME / IP and SOME / IP-SD. [Diagram 5] FIG. 5 is a flowchart illustrating an example of a process executed by the monitoring device. [Figure 6] FIG. 6 is a flowchart illustrating an example of a procedure for re-evaluating an abnormal packet that has been overlooked in the on-demand determination process. [Figure 7] FIG. 7 is a flow chart illustrating an example of a procedure for statistical evaluation of an entire series based on anomalies in the number of sessions. [Figure 8] FIG. 8 is a diagram illustrating an example of the configuration of a system including a monitoring device. [Figure 9] FIG. 9 is a diagram illustrating an example of the configuration of a system including a monitoring device. [Figure 10] FIG. 10 is a diagram illustrating an example of the configuration of a system including a monitoring device. [Figure 11] FIG. 11 is a diagram illustrating an example of the configuration of a system including a monitoring device. [Figure 12] FIG. 12 is a diagram illustrating an example of the configuration of a system including a monitoring device. [Figure 13] FIG. 13 is a diagram illustrating an example of the configuration of a computer that executes a monitoring program. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Hereinafter, a mode (embodiment) for carrying out the present invention will be described with reference to the drawings, but the present invention is not limited to the present embodiment.

[0013] First, an overview of the monitoring device of this embodiment will be described with reference to Fig. 1. The monitoring device monitors control communications of an in-vehicle network. For example, the monitoring device monitors communication packets transmitted and received between ECUs (Engine Control Units) via the in-vehicle network within the vehicle. These communication packets between ECUs are, for example, SOME / IP or SOME / IP-SD packets. Also, the ECUs will be described taking as an example a case where they perform Publish / Subscribe type communication.

[0014] For example, the monitoring device uses a data set of normal communication between ECUs in advance to extract normal packet reception times and normal packet features from the packet headers and payloads, and builds a normal communication model between ECUs. The monitoring device then detects ECU communication that deviates from the normal communication model as an anomaly. Here, the header of a SOME / IP or SOME / IP-SD packet contains a Session ID that indicates the communication order. The monitoring device detects anomalies in ECU communication (hereinafter abbreviated as "communication" as appropriate) using the communication order indicated by the Session ID of the above packet.

[0015] The monitoring device detects communication anomalies by combining two anomaly detection logics. (1) On-demand judgment logic: The monitoring device judges whether each packet is normal or abnormal. (2) Retrospective judgment logic: The monitoring device judges whether a specific packet group (a packet group of the same service and the same source) is normal or abnormal based on the Session ID of the packet.

[0016] For example, consider a case where a monitoring device judges whether a series of packets, Request (Req.) and Response (Res.), shown in Figure 1, are normal or abnormal. Here, Req. is a normal packet, and Res. is an attack packet.

[0017] Here, consider a case where, for a series of packets consisting of Req. (normal) and Res. (attack), the monitoring device judges (overlooks) the Res. of Session ID=1 to be within the range of the normal communication model using (1) on-demand judgment logic, but judges the Res. of Session ID=2 to be outside the range of the normal communication model.

[0018] In this case, the monitoring device judges (2) that not only the Res. of Session ID=2 is abnormal, but also the Res. of Session ID=1 is abnormal (retroactive judgment).The monitoring device also infers that the response series of this session is abnormal, and judges the Res. of Session ID=3 and onward to be abnormal, regardless of whether they are within the range of the normal communication model or not.

[0019] In this way, the monitoring device can (1) determine that an abnormal packet that is overlooked by the on-demand determination logic is an abnormal packet by (2) using the retroactive determination logic.

[0020] As a result, for example, the monitoring device can accurately detect anomalies in SOME / IP communication or SOME / IP-SD communication even if header information in layers 1 to 4 of a packet is spoofed / tampered with.

[0021] The packets monitored by the monitoring device are assumed to be packets communicated in a static network where the information of the communication partner does not change frequently, for example. Also, the packets monitored by the monitoring device (for anomaly detection) are not limited to the above SOME / IP or SOME / IP-SD packets, so long as they contain information indicating the order, such as a Session ID.

[0022] The monitoring device is installed at a location where it can monitor all communications between the target ECUs, for example, at a location on the vehicle network through which all packets to be monitored pass.

[0023] [Overview of on-demand judgment processing] The monitoring device uses a data set of normal communications between ECUs in a monitored vehicle to learn normal communication patterns between ECUs for each service (details described later) and builds a normal communication model.The monitoring device then detects any communication that deviates from the normal communication model as an anomaly.

[0024] Here, the monitoring device constructs a normal communication model using, for example, the following feature amounts, and detects anomalies in the communications to be monitored using the following feature amounts.

[0025] (1) Service Structure - Packet communication order (e.g., Req. packet is followed by Res. packet, etc.) - Order of packet Session ID (counter) If the packet is a Publish / Subscribe type communication packet, the number of simultaneous subscriptions to the service (2) Packet communication interval ΔT Entire session: Average packet interval Each communication: A value discretized based on the minimum and maximum communication intervals of each packet (3) Packet payload transition P, ΔP Sensor value: Difference ΔP (bitwise exclusive OR) is 0 or non-zero Category values: Differences ΔP and P Fixed value: known value P or not

[0026] As the feature amount of the sensor value, the difference ΔP itself may be used, or a value obtained by discretizing ΔP within a certain range may be used.

[0027] For example, in the case of Publish / Subscribe type communication between ECUs in a vehicle, the feature quantity when focusing on the second Req. packet in the communication sequence of a certain service is as shown in FIG.

[0028] [Retroactive assessment process overview] (1) Reevaluation of abnormal packets that were missed during on-demand judgment processing As long as the specifications of SOME / IP or SOME / IP-SD are followed, the monitoring device can identify a series of packets from the same sender by the Session ID. In other words, even if the IP address / MAC address is spoofed, the monitoring device can identify packets with spoofed IP address / MAC address based on the sequence of the packet Session ID. It is assumed that the attacker also sends packets in accordance with the SOME / IP or SOME / IP-SD specifications. Therefore, when the monitoring device detects an abnormal packet using its on-demand judgment logic, it also regards the packets before and after the abnormal packet from the same source as the abnormal packet as abnormal packets using its retroactive judgment logic (see Figure 1).

[0029] (2) Statistical evaluation of the entire series based on anomalies in the number of sessions The monitoring device can model the number of subscribed ECUs (clients) of a certain service from the learning data. For example, if an attacker who spoofs information appears, the number of subscribed ECUs increases. Therefore, if the number of subscribed ECUs deviates from the above model, the monitoring device can detect that one of the session (subscription session) series is abnormal. If no abnormality is found in the on-demand judgment for any of the multiple session sequences, the monitoring device performs a retroactive judgment at a predetermined retroactive judgment timing (for example, at the end of any session). For example, the monitoring device obtains statistics such as the average communication interval for each session, and based on these statistics, if there is a session that deviates from the normal communication model, it performs a retroactive judgment on the entire session to detect the abnormality.

[0030] [Configuration example] Next, a configuration example of a system including the monitoring device 100 will be described with reference to Fig. 3. For example, the system includes a vehicle 10 and an external device 20. The vehicle 10 and the external device 20 are communicatively connected via an external network such as the Internet. The external device 20 includes a vehicle-to-vehicle communication unit 21. The external device 20 receives and accumulates anomaly detection results of communication transmitted from the vehicle 10 via the vehicle-to-vehicle communication unit 21. The numbers of vehicles 10, ECUs 11, and external devices 20 are not limited to those shown in Fig. 3.

[0031] The vehicle 10 includes a plurality of ECUs 11, an external device communication unit 12, and an on-board computer 13. The ECU 11 is a unit that controls each part (e.g., an engine, indicators, etc.) that constitutes the vehicle 10. The ECU 11 performs control communication with other ECUs 11 via a switch 14 to obtain information for operating the own ECU 11.

[0032] The external device communication unit 12 communicates with the external device 20 via an external network. For example, the external device communication unit 12 transmits data (e.g., anomaly detection results) output from the in-vehicle computer 13 to the external device 20 via the external network.

[0033] The on-board computer 13 executes various processes related to the vehicle 10. For example, the on-board computer 13 includes a switch 14 and a monitoring device 100. The switch 14 relays and switches communications between the ECUs 11. The monitoring device 100 monitors the communications between the ECUs 11 via the switch 14.

[0034] The monitoring device 100 includes, for example, a normal communication model, a regular analysis unit (first determination unit) 16, a retrospective analysis unit (second determination unit) 17, and an output processing unit .

[0035] The normal communication model is a model for outputting whether or not a communication of a monitored object is normal when the input of the communication of the monitored object is received. For example, the normal communication model is constructed by the monitoring device 100 learning a normal communication pattern for each service using a data set of normal communication of the ECU 11 of the monitored vehicle 10. The parameters of the normal communication model are stored in a predetermined area of ​​a storage device provided in the on-board computer 13.

[0036] The features used in learning the normal communication model are, for example, (1) the service structure, (2) the packet communication interval ΔT, (3) the packet payload transitions P and ΔP, etc. The details of the features will be described later.

[0037] The regular analysis unit 16 judges whether or not each packet transmitted between the ECUs 11 is abnormal by using the normal communication model based on the regular judgment logic described above.

[0038] In addition, the retrospective analysis unit 17 judges whether an entire series of packets from the same service and the same sender is normal or abnormal based on the Session ID of the packets, based on the retrospective judgment logic, using the processing result by the on-demand analysis unit 16. The details of the processing by the on-demand analysis unit 16 and the retrospective analysis unit 17 will be described later.

[0039] The output processing unit 18 outputs the processing result by the real-time analysis unit 16 and the processing result by the retrospective analysis unit 17. For example, the output processing unit 18 outputs the processing result by the real-time analysis unit 16 (anomaly detection result) and the processing result by the retrospective analysis unit 17 (anomaly detection result) to the unit for communicating with external device 12.

[0040] [Features] Next, an example of a feature amount used by the monitoring device 100 for packet anomaly detection will be described with reference to Fig. 4. In the following description, "server" refers to the ECU 11 that plays the role of a server in a series of communications, and "client" refers to the ECU 11 that plays the role of a client in a series of communications.

[0041] ·service The monitoring device 100 identifies which service the packet belongs to based on the Service ID and Method ID in the SOME / IP header information, and the Service ID and Instance ID in the SOME / IP-SD Entry Array header. The monitoring device 100 also identifies the sender of the packet of the service based on the Client ID in the SOME / IP header information and the type of the transmitted packet (e.g., Request / Response). For example, a client sends a Request but does not send a Response, so if the transmitted packet is a Request, the monitoring device 100 identifies the sender of the packet as a client (not a server).

[0042] Also, if the sender is normal, the Session ID (a header that acts as a counter) associated with the Client ID is incremented every time a packet is sent. Therefore, the monitoring device 100 can identify the sender of a series of packets of the same service based on the continuity of the Session IDs of the packets.

[0043] Based on the normal communication data set, the monitoring device 100 learns how many types of services are handled in the SOME / IP or SOME / IP-SD communication of the ECU 11 of the monitored vehicle 10 and what their values ​​are. Then, the monitoring device 100 constructs a normal communication model for each service.

[0044] Packet transmission order (1) In the case of SOME / IP Based on the data set of normal communication, the monitoring device 100 uses the server's response to the client's request as a feature quantity related to the packet communication order. If a request is sent multiple times in the data set, the monitoring device 100 also uses the next request in response to the response as a feature quantity related to the packet communication order. The monitoring device 100 also uses successive event transmissions by the server (the nth and n+1th event transmissions) as a feature quantity related to the packet communication order.

[0045] (2) In the case of SOME / IP-SD The monitoring device 100 uses the server's Publish in response to the client's Subscribe as a feature related to the packet communication order. For example, the server's OfferService in response to the client's FindService is used as a feature related to the packet communication order. Note that there are cases where FindService is transmitted multiple times in succession. In this case, the monitoring device 100 also uses the transmission order of FindService as a feature.

[0046] The monitoring device 100 uses, for example, the SubscribeEventgroup of the client in response to the OfferService of the server as a feature related to the packet communication order. Also, there are cases where the OfferService is transmitted multiple times in succession. In such cases, the monitoring device 100 also uses the transmission order of the OfferService as a feature. Furthermore, the monitoring device 100 uses, for example, the SubscribeEventgroupAck (or SubscribeEventNack) of the server in response to the SubscribeEventgroup of the client as a feature related to the packet communication order.

[0047] Furthermore, the monitoring apparatus 100 uses, for example, a StopSubscribeEventgroup by a client after a series of Unsubscribe communications by the client as a feature quantity related to the packet communication order.

[0048] Session ID sequence The Session-IDs of SOME / IP and SOME / IP-SD are counted up independently for each communication type (e.g., Request, Response, Event, FindService, OfferService, etc.). Therefore, the monitoring device 100 uses the order of the Session IDs in the headers of SOME / IP and SOME / IP-SD as a feature. For example, when a client receives an Event packet with Session ID=0x0001, it is expected to receive an Event packet with Session ID=0x0002 next. Therefore, by using the above Session IDs as a feature, the monitoring device 100 can determine that an Event packet with Session ID=n is abnormal if, for example, the Session ID of the Event packet received immediately before the Event packet with Session ID=n is not n-1.

[0049] -Supplementary information on packet payload transition P, ΔP While there is no payload in SOME / IP-SD, there is a payload in SOME / IP. Therefore, for a SOME / IP packet, the monitoring device 100 models the payload P and its transition ΔP as follows:

[0050] For example, the monitoring device 100 uses the communication specifications of the service or any existing reverse engineering technique (e.g., a technique for estimating the meaning within the payload, etc.) to divide the payload based on the degree of change in the sensor value, category value, fixed value, etc. contained in the payload.

[0051] Sensor values ​​are characterized by their steady changes and by their changing values ​​over the entire range of the bit length, categorical values ​​are characterized by their relatively infrequent changes and a small number of possible values ​​for the bit length, and fixed values ​​are characterized by bits that do not change in a data set of normal communication.

[0052] Then, the monitoring device 100 learns, for example, the following values ​​as the payload transition pattern for each divided payload, and constructs a normal communication model. For example, the monitoring device 100 learns the payload transition pattern and constructs a normal communication model using, as features, for sensor values, whether the difference ΔP (bitwise exclusive OR) is 0 or not, for category values, the difference ΔP and the value P, and for fixed values, whether the value P is a known value. Note that, as features of the above sensor values, the difference ΔP itself may be used, or a value obtained by discretizing ΔP within a certain range may be used.

[0053] [On-the-spot judgment processing] Based on the normal communication model for each service, the on-demand analysis unit 16 of the monitoring device 100 judges each time it receives a SOME / IP or SOME / IP-SD packet whether or not the packet has a pattern that can occur in the normal communication model of the service. If the packet has a pattern that can occur in the normal communication model of the service, the on-demand analysis unit 16 judges the packet to be normal, and if the packet does not have a pattern that can occur in the normal communication model of the service, it judges the packet to be abnormal.

[0054] In this embodiment, it is assumed that the attacker ECU 11 communicates with a normal ECU 11. In other words, in this embodiment, it is not assumed that attacker ECUs 11 communicate with each other. Therefore, when the analysis unit 16 determines that packets from different senders (ECUs 11) are abnormal in the same service and the same session, for example, the analysis unit 16 determines that the sender (ECU 11) that was first determined to be abnormal is abnormal, and determines the other sender (ECU 11) to be normal.

[0055] [Retroactive Judgment Processing] In addition, the retrospective analysis unit 17 of the monitoring device 100 performs (1) re-evaluation of packets that were overlooked in the on-demand judgment process, and (2) statistical evaluation of the entire series based on anomalies in the number of sessions. (1) has already been explained in the overview of the retrospective judgment process, so (2) will be explained in detail with specific examples.

[0056] For example, suppose that when the monitoring device 100 constructs a normal communication model for a certain service A (Request & Response), it learns that the number of simultaneous subscriptions is n (n clients, 1 server).

[0057] In this case, if an attacker's ECU 11 masquerades as a client and subscribes to a certain service, the number of simultaneous subscriptions becomes n+1, and the retrospective analysis unit 17 detects an abnormality in the number of simultaneous subscriptions based on the above normal communication model. However, the monitoring device 100 reserves the decision on normal / abnormal on a packet-by-packet basis at this point.

[0058] Here, if the on-demand analysis unit 16 detects an abnormality in a packet of any subscription session, the retrospective analysis unit 17 determines that all packets from the source (client) of the packet in which the abnormality was detected in the subscription session in which the abnormality was detected by the on-demand analysis unit 16 are abnormal.

[0059] On the other hand, if no abnormality is detected by the time analysis unit 16 in any subscription session (remains normal) until the end of all subscription sessions, the retrospective analysis unit 17 identifies the subscription session that deviates most from the normal communication model based on the feature amount of the communication interval of the packets of each subscription session. Then, the retrospective analysis unit 17 regards the client of the subscription session that deviates most from the normal communication model as abnormal, and determines all packets whose source is that client as abnormal.

[0060] According to the monitoring device 100, in detecting communication anomalies in SOME / IP communication and SOME / IP-SD communication, even if a communication anomaly is overlooked by an on-demand judgment, the monitoring device 100 can detect the communication anomaly by retroactive judgment. Therefore, the monitoring device 100 can detect communication anomalies with high accuracy.

[0061] [Example of processing procedure] Next, an example of a processing procedure of the monitoring device 100 will be described with reference to Fig. 5. The monitoring device 100 first performs an on-demand determination process for each packet to be monitored (S1), and then performs a retroactive determination process based on the result of the on-demand determination process for each packet in S1 (S2). The monitoring device 100 then outputs the result of anomaly detection by the on-demand determination process and the result of anomaly detection by the retroactive determination process (S3).

[0062] As described above, the on-demand analysis unit 16 and the retrospective analysis unit 17 of the monitoring device 100 (1) reevaluate abnormal packets missed in the on-demand judgment process, and (2) perform a statistical evaluation of the entire series based on abnormalities in the number of sessions.

[0063] (1) Reevaluation of abnormal packets that were missed during on-demand judgment processing For example, the monitoring device 100 re-evaluates an abnormal packet that was overlooked in the on-demand determination process by the processing procedure shown in Fig. 6. First, the on-demand analysis unit 16 of the monitoring device 100 performs on-demand determination processing for each packet to be monitored (S11). Here, if the on-demand analysis unit 16 does not detect an abnormality in the packet by the on-demand determination processing (No in S12), the on-demand determination processing of S11 is performed on the next packet (S11).

[0064] On the other hand, if an anomaly is detected in the packet in the on-demand determination process of S11 (Yes in S12), the retrospective analysis unit 17 detects the packet with the previous Session ID and the packet with the next or subsequent Session ID as an anomaly based on the Session ID of the packet in which the anomaly was detected (S13).Then, the output processing unit 18 outputs the anomaly detection result by the on-demand determination process and the anomaly detection result by the retrospective determination process (S14).

[0065] (2) Statistical evaluation of the entire series based on anomalies in the number of sessions For example, the monitoring device 100 performs a statistical evaluation of the entire sequence based on an anomaly in the number of sessions (subscription sessions) in Publish / Subscribe type communication, using the processing procedure shown in Fig. 7. Note that, although a detailed explanation is omitted here, the monitoring device 100 is also assumed to perform an on-demand determination process for each packet by the on-demand analysis unit 16 in parallel with the processing described below.

[0066] First, the retrospective analysis unit 17 of the monitoring device 100 monitors the number of simultaneous subscription sessions (the number of simultaneous subscriptions) of the communication to be monitored (S21), and determines whether the number of simultaneous subscriptions exceeds the normal range based on the normal communication model (S22). Here, if the retrospective analysis unit 17 determines that the number of simultaneous subscriptions exceeds the normal range (Yes in S22), it proceeds to S23. On the other hand, if the retrospective analysis unit 17 determines that the number of simultaneous subscriptions of the monitoring target is within the normal range (No in S22), it returns to S21.

[0067] In S23, if the retrospective analysis unit 17 determines that an abnormality has been detected in a packet of any subscription session through the on-demand determination by the on-demand analysis unit 16 (Yes in S23), it determines that all packets of the client in that subscription session are abnormal (S24).

[0068] On the other hand, in S23, if the retrospective analysis unit 17 determines that no packet abnormality has been detected in any subscription session in the occasional determination by the occasional analysis unit 16 (No in S23), the retrospective analysis unit 17 identifies the subscription session that most deviates from the normal communication model based on the feature amount of the communication interval of each packet of each subscription session (S25).Then, the retrospective analysis unit 17 determines that all packets whose source is the client of the subscription session identified in S25 are abnormal (S26).

[0069] Then, the output processing unit 18 outputs the result of the anomaly detection by the real-time analysis unit 16 and the result of the anomaly detection by the retrospective analysis unit 17 (S27).

[0070] By performing the above-mentioned processing, the monitoring device 100 can accurately detect new attacks and attacks using spoofed IP addresses / MAC addresses.

[0071] [Other embodiments] In the above description, the communication monitored by the monitoring device 100 is Publish / Subscribe type communication, but the communication is not limited to this as long as a Session ID is assigned to the communication packet. In this case, the monitoring device 100 performs the reevaluation of the abnormal packets overlooked in the (1) on-demand judgment process out of the above-mentioned (1) reevaluation of the abnormal packets overlooked in the on-demand judgment process and (2) statistical evaluation of the entire series based on the abnormality of the number of sessions.

[0072] The monitoring device 100 may further include a learning unit that learns a normal communication model based on normal communication between the ECUs 11.

[0073] Furthermore, the system configuration including the monitoring device 100 is not limited to the system configuration shown in Fig. 3. For example, as shown in Fig. 8, the result of the abnormality detection by the monitoring device 100 (abnormality detection result) may be accumulated in the vehicle-mounted computer 13.

[0074] 9, the on-demand analysis unit 16 may be provided in the monitoring device 100a in the in-vehicle computer 13, and the retrospective analysis unit 17 may be provided in the monitoring device 100b in the external device 20. In this case, the monitoring device 100a transmits the result of the on-demand judgment by the on-demand analysis unit 16 (anomaly detection result) to the external device 20. Then, the monitoring device 100b of the external device 20 performs retrospective judgment using the result of the on-demand judgment by the retrospective analysis unit 17. Then, the retrospective analysis unit 17 accumulates the result of the retrospective judgment (anomaly detection result).

[0075] 10, the monitoring device 100 of the external device 20 may obtain communication packets between the ECU 11 from the in-vehicle computer 13 and perform anomaly detection on the obtained communication packets. In this case, for example, the in-vehicle computer 13 includes an external transmission data compression unit 19 that compresses and transmits SOME / IP or SOME / IP-SD communication. The in-vehicle computer 13 compresses the SOME / IP or SOME / IP-SD communication in the external transmission data compression unit 19 and transmits it to the external device 20.

[0076] The monitoring device 100 may also monitor communication for each device (e.g., switch, hub, etc.) that bundles subnets of the in-vehicle Ethernet, and perform anomaly detection. For example, as shown in Fig. 11, the monitoring device 100 may obtain SOME / IP or SOME / IP-SD communication from each switch 14 that houses the ECU 11, and perform anomaly detection.

[0077] The monitoring device 100 may also be provided in a switch or hub in a vehicle. For example, as shown in Fig. 12, a monitoring device 100 may be provided in each switch 14 in a vehicle 10, and the monitoring device 100 in a switch 14 may acquire communication of SOME / IP or SOME / IP-SD in a subnetwork bound by the switch 14, and detect anomalies.

[0078] [System configuration, etc.] In addition, each component of each unit shown in the figure is a functional concept, and does not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or a part of it can be functionally or physically distributed and integrated in any unit according to various loads, usage conditions, etc. Furthermore, each processing function performed by each device can be realized in whole or in part by a CPU and a program executed by the CPU, or can be realized as hardware using wired logic.

[0079] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by a known method. In addition, the information including the processing procedures, control procedures, specific names, various data and parameters shown in the above documents and drawings can be changed arbitrarily unless otherwise specified.

[0080] [program] The monitoring device 100 can be implemented by installing a program (monitoring program) as package software or online software in a desired computer (for example, the in-vehicle computer 13). For example, the above program can be executed by an information processing device, causing the information processing device to function as the monitoring device 100. The information processing device referred to here includes mobile communication terminals such as smartphones, mobile phones, and PHS (Personal Handyphone Systems), as well as terminals such as PDAs (Personal Digital Assistants).

[0081] Fig. 13 is a diagram showing an example of a computer that executes a monitoring program. The computer 1000 has, for example, a memory 1010 and a CPU 1020. The computer 1000 also has a hard disk drive interface 1030, a disk drive interface 1040, and a network interface 1070. The computer 1000 also has a switch 14 (not shown in Fig. 13). These components are connected by a bus 1080.

[0082] The memory 1010 includes a read only memory (ROM) 1011 and a random access memory (RAM) 1012. The ROM 1011 stores a boot program such as a basic input output system (BIOS). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100.

[0083] The hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the programs that define the processes executed by the monitoring device 100 are implemented as program modules 1093 in which computer-executable codes are written. The program modules 1093 are stored, for example, in the hard disk drive 1090. For example, the program modules 1093 for executing processes similar to those of the functional configuration of the monitoring device 100 are stored in the hard disk drive 1090. The hard disk drive 1090 may be replaced by an SSD (Solid State Drive).

[0084] Data used in the processing of the above-described embodiment is stored as program data 1094 in, for example, the memory 1010 or the hard disk drive 1090. Then, the CPU 1020 reads out the program module 1093 or the program data 1094 stored in the memory 1010 or the hard disk drive 1090 into the RAM 1012 as necessary and executes them.

[0085] Note that the program module 1093 and the program data 1094 are not limited to being stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and the program data 1094 may be stored in another computer connected via a network (such as a local area network (LAN) or wide area network (WAN)). The program module 1093 and the program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070. [Explanation of symbols]

[0086] 10 Vehicles 11 ECU 12 External device communication section 13 Vehicle-mounted computer 14 Switch 16 On-demand Analysis Department 17 Retrospective Analysis Section 18 Output Processing Section 19 Data compression section for external transmission 20 External device 21 Vehicle Communication Unit 100,100a,100b monitoring device

Claims

1. a first determination unit that determines whether or not each packet transmitted and received by the ECU is abnormal by using a normal communication model of communication between ECUs of a vehicle; a second determination unit that, when any packet is determined to be abnormal by the first determination unit, determines a series of packets having consecutive Session IDs from a packet preceding the packet determined to be abnormal to be abnormal based on a Session ID indicating a communication order included in header information of the packet determined to be abnormal; an output processing unit that outputs information on packets determined to be abnormal by the first determination unit and information on packets determined to be abnormal by the second determination unit; A monitoring device comprising:

2. The communication between the ECUs is a Publish / Subscribe type communication, The second determination unit is When it is determined that the number of simultaneous subscribing clients in the Publish / Subscribe type communication exceeds a normal range, and when the first determination unit determines that a packet of any of the subscribing sessions is abnormal, the packet of the subscribing client in the subscribing session determined to be abnormal is determined to be abnormal.

2. The monitoring device according to claim 1.

3. The second determination unit is When it is determined that the number of simultaneous subscribing clients in the Publish / Subscribe type communication exceeds a normal range, and when the first determination unit has not determined that packets of any of the subscribing sessions are abnormal until the end of all the subscribing sessions, the subscribing session in which the feature value of the communication interval of each packet is the most deviated from a normal communication model is identified, and packets of the subscribing client in the identified subscribing session are determined to be abnormal.

3. The monitoring device according to claim 2.

4. The packet is a packet of the SOME / IP protocol or the SOME / IP-SD protocol.

2. The monitoring device according to claim 1.

5. A monitoring method performed by a monitoring device, comprising: a first determination step of determining whether or not each packet transmitted / received by the ECU is abnormal by using a normal communication model of communication between ECUs of a vehicle; a second determination step of determining, when any packet is determined to be abnormal by the first determination step, that a series of packets having consecutive Session IDs following the packet preceding the packet determined to be abnormal are abnormal based on a Session ID indicating a communication order included in header information of the packet determined to be abnormal; an output step of outputting information on packets determined to be abnormal in the first determination step and information on packets determined to be abnormal in the second determination step; A monitoring method comprising:

6. A monitoring program for causing a computer to function as the monitoring device according to any one of claims 1 to 4.

Images