Intrusion route analysis device and intrusion route analysis method

Abstract

The present invention provides an intrusion-path analyzing device that is communicatively connected to a control network system to which one or more electronic control devices and a communication device are connected. In the control network system, one or more security sensors are installed, said security sensors sending a security alert to the network when a symptom of security invasion has been detected on at least one of the network, the one or more electronic control devices, and the communication device, the security alert including the detection of the symptom of security invasion. The intrusion-path analyzing device is provided with: an alert acquisition unit that acquires a security alert from the one or more security sensors; an event acquisition unit that acquires an event history of events that have occurred in the control network system; and an intrusion-path analyzing unit that analyzes the intrusion path of an attack anticipated when the security alert has occurred, on the basis of the security alert, the event history, and an intrusion depth indicating the level of intrusion of the attack, and that outputs a result of the analysis.

Description

[Technical field]

[0001] The present disclosure relates to an intrusion path analysis device and an intrusion path analysis method for analyzing intrusion paths of attacks on a network (e.g., an in-vehicle network). [Background technology]

[0002] In recent years, systems inside automobiles have been equipped with numerous devices called electronic control units (ECUs). The network that connects these ECUs is called an in-vehicle network. There are many standards for in-vehicle networks, but one of the most mainstream standards is the Controller Area Network (CAN). In addition, with the spread of autonomous driving and connected cars, an increase in in-vehicle network traffic is expected, and in-vehicle Ethernet is becoming more widespread.

[0003] On the other hand, with the spread of connected cars, there is a growing threat that attackers could infiltrate the in-vehicle network from networks external to the vehicle and take unauthorized control of the vehicle, and security considerations are currently being considered.

[0004] Approaches proposed for improving the security of in-vehicle networks include methods used in conventional Internet Protocol (IP) communications to prevent communications by unauthorized nodes using encrypted communications, as in Non-Patent Document 1 or Non-Patent Document 2, or protection of the control network by domain separation. On the other hand, in a situation where new vulnerabilities are discovered or the attacker environment is constantly changing, it is considered difficult to continue protecting the long life span of an automobile with only security functions at the shipping stage, and therefore an approach that monitors whether security anomalies have occurred in the network and takes appropriate measures is also attracting attention (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Patent No. 6508631 [Non-patent literature]

[0006] [Non-Patent Document 1] RFC5406:Guidelines for Specifying the Use of IPsec Version2 [Non-Patent Document 2] IEEE 802.1AE:MAC Security Summary of the Invention [Problem to be solved by the invention]

[0007] Incidentally, understanding the intrusion path of an attack is useful for analyzing the attack and can lead to a quick response thereafter. Therefore, it is desirable to understand the intrusion path of an attack. However, the method such as that of Patent Document 1 can detect the occurrence of an attack on a control network, but cannot understand the intrusion path of the attack.

[0008] Therefore, the present disclosure provides an intrusion route analysis device and an intrusion route analysis method that output information on the intrusion route of an attack on a control network. [Means for solving the problem]

[0009] In order to achieve the above-mentioned object, an intrusion path analysis device according to one embodiment of the present disclosure is an intrusion path analysis device communicatively connected to a control network system to which one or more electronic control devices and communication devices are connected, wherein the control network system has one or more security sensors disposed on a network in at least one of the one or more electronic control devices and the communication devices, the security sensors transmitting a security alert including the detection of the sign of a security breach to the network when a sign of a security breach is detected, and the intrusion path analysis device includes an alert acquisition unit that acquires the security alert from the one or more security sensors, an event acquisition unit that acquires an event history of an event that has occurred in the control network system, and an intrusion path analysis unit that analyzes the intrusion path of the attack based on the security alert, the event history, and an intrusion depth that indicates the expected degree of intrusion of the attack when the security alert is generated, and outputs the analysis result.

[0010] In addition, in order to achieve the above-mentioned object, an intrusion path analysis method according to one embodiment of the present disclosure is an intrusion path analysis method in a control network system to which one or more electronic control devices and communication devices are connected, in which the control network system has one or more security sensors disposed on a network, in at least one of the one or more electronic control devices and the communication devices, and which transmit a security alert including the detection of the sign of a security breach to the network when a sign of a security breach is detected, and the intrusion path analysis method includes a step of acquiring the security alert from the one or more security sensors, a step of acquiring an event history of an event that has occurred in the control network system, and an intrusion path analysis step of analyzing the intrusion path of the attack based on the security alert, the event history, and an intrusion depth that indicates the degree of intrusion of the attack expected when the security alert occurs, and outputting the analysis result. Effect of the Invention

[0011] According to an intrusion route analysis device and the like according to one aspect of the present disclosure, it is possible to output information on the intrusion route of an attack on a control network. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram showing the overall configuration of an in-vehicle network monitoring system according to an embodiment. [Diagram 2] FIG. 2 is a configuration diagram of an in-vehicle network installed in a vehicle according to the embodiment. [Diagram 3] FIG. 3 is a configuration diagram of a TCU according to the embodiment. [Figure 4] FIG. 4 is a configuration diagram of the central ECU in the embodiment. [Diagram 5] FIG. 5 is a configuration diagram of an Ether switch according to an embodiment. [Figure 6] FIG. 6 is a configuration diagram of the ECU according to the embodiment. [Figure 7] FIG. 7 is a configuration diagram of a server according to the embodiment. [Figure 8] FIG. 8 is a diagram showing an example of a security alert output by the security sensor unit in the embodiment. [Figure 9] FIG. 9 is a diagram illustrating an example of history information included in an analysis report generated by the central ECU in the embodiment. [Figure 10] FIG. 10 is a diagram showing an example of a security alert history stored in a security alert history storage unit in the embodiment. [Figure 11] FIG. 11 is a diagram showing an example of a vehicle event history stored in a vehicle event history holding unit in the embodiment. [Figure 12] FIG. 12 is a diagram illustrating a first intrusion route analysis sequence in the central ECU according to the embodiment. [Figure 13] FIG. 13 is a diagram illustrating a second intrusion route analysis sequence in the central ECU according to the embodiment. [Figure 14]FIG. 14 is a flowchart showing a process up to notification of an analysis report in the central ECU according to the embodiment. [Figure 15] FIG. 15 is a flowchart showing details of step S204 shown in FIG. [Figure 16] FIG. 16 is a diagram showing an example of a security sensor location database in another modified example of the embodiment. [Figure 17] FIG. 17 is a flowchart for determining a response according to a result of an intrusion route analysis of the central ECU in another modified example of the embodiment. [Figure 18] FIG. 18 is a diagram showing an example of a relationship between a target ECU for issuing a warning and a response of each ECU according to the depth of a security alert in another modified example of the embodiment. [Figure 19] FIG. 19 is a diagram showing an example of an analysis report in another modified example of the embodiment. [Figure 20] FIG. 20 is a diagram illustrating an example of a threat database held by a central ECU in another modified example of the embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] (Knowledge that forms the basis of this disclosure) In the following, an in-vehicle network will be described as an example of a network.

[0014] As described in "Problems to be Solved by the Invention," understanding the intrusion path of an attack (e.g., a cyber attack) is useful in analyzing the attack and can lead to a quick response thereafter. For example, understanding the entry point (the point where an attack is first made) from which the attack was launched or the intrusion path by which the attack was carried out is useful in analyzing the attack.

[0015] After an attack is detected, it is important to analyze the cause of the attack, identify vulnerabilities, and repair them in order to maintain vehicle security. Attack analysis requires the presentation of information that makes it easy for security analysts to identify the cause of the attack, and information showing the intrusion route is also useful in this regard.

[0016] It is desirable to grasp the intrusion route of an attack by using these methods, but the techniques described in the prior art documents cannot grasp the intrusion route of an attack.

[0017] Therefore, the inventors of the present application have conducted extensive research into an intrusion route analysis device and the like that can grasp the intrusion route of an attack, and have devised the intrusion route analysis device and the like described below.

[0018] An intrusion path analysis device according to one embodiment of the present disclosure is an intrusion path analysis device that is communicatively connected to a control network system to which one or more electronic control devices and communication devices are connected, wherein the control network system has one or more security sensors disposed on a network in at least one of the one or more electronic control devices and the communication devices, and the security sensors transmit a security alert including the detection of the sign of a security breach to the network when a sign of a security breach is detected, and the intrusion path analysis device includes an alert acquisition unit that acquires the security alert from the one or more security sensors, an event acquisition unit that acquires an event history of an event that has occurred in the control network system, and an intrusion path analysis unit that analyzes the intrusion path of the attack based on the security alert, the event history, and an intrusion depth that indicates the expected degree of intrusion of the attack when the security alert is generated, and outputs the analysis result.

[0019] This allows the intrusion path analysis device to analyze the intrusion path of an attack on the control network based on the security alert, the event history, and the intrusion depth. By including the event history, for example, the intrusion path can be analyzed using the relationship between a normally completed event and the intrusion depth of the security alert, so the intrusion path analysis device can analyze the intrusion path more accurately than when the event history is not included. Therefore, the intrusion path analysis device can output an analysis result including information on the intrusion path of an attack on the control network.

[0020] For example, a security analyst analyzing attacks can obtain the results of an analysis of the intrusion route into a control network from the analysis results, which makes it easier to predict how to deal with an attack and where the next attack target will be, making it effective in responding to attacks.

[0021] Also, for example, the control network system may be composed of two or more subnetworks, the communication device may be placed on at least one of the two or more subnetworks, and may be a device for communicating with a network or device outside the control network system, and the penetration depth may be determined by the number of physical or logical routes through at least one of the one or more electronic control devices, the two or more subnetworks, and a gateway device connecting the two or more subnetworks, from the communication device to the target monitored by the security sensor.

[0022] As a result, the more difficult it is for an external attacker to reach a security alert output from a security sensor located in such a location, the greater the intrusion depth is set, and the analysis result can better reflect the intrusion status of the attack. Therefore, the intrusion route analysis device can output analysis results that make it easy to understand the intrusion status of the attack, which is effective in analyzing attacks.

[0023] Also, for example, when there are multiple security alerts, the intrusion route analysis unit may determine, as part of the analysis, whether or not the event is due to the attack based on the change in the intrusion depth of the multiple security alerts over time and the event that occurred during the time period when the multiple security alerts were detected.

[0024] In this way, the analysis result includes information indicating whether or not an event is the result of an attack, so that the attack can be analyzed while taking the event into consideration. By using such analysis results, the accuracy of the attack analysis is improved.

[0025] Also, for example, the intrusion route analysis unit may determine, as part of the analysis, that the event is caused by an attack if the occurrence distribution of the intrusion depth changes before and after the occurrence time of the event included in the event history.

[0026] This allows the intrusion path analysis device to determine whether an event that was completed normally is an event caused by an attack activity from the occurrence status of a security alert, and to detect unauthorized behavior that cannot be detected by security sensors. Therefore, the intrusion path analysis device is more effective in analyzing attacks because it can output analysis results that include detection results of unauthorized behavior that cannot be detected by security sensors.

[0027] Furthermore, for example, the intrusion route analysis unit may, as part of the analysis, determine that the intrusion situation is an expanding intrusion if the intrusion depth of the security alert increases over time, determine that the intrusion situation is an attack by an unauthorized device if the intrusion depth of the security alert decreases over time, and determine that the intrusion situation is no change if the intrusion depth of the security alert does not change over time.

[0028] This allows the intrusion path analysis device to determine the current intrusion status from changes in the intrusion depth of multiple security alerts. The intrusion path analysis device outputs analysis results including the determination results, allowing security analysts to understand the current intrusion status, and can output information useful for considering how to respond to attacks.

[0029] Furthermore, for example, the intrusion route analysis unit may, as part of the analysis, further determine that the entry point of the attack is the area with the smallest intrusion depth if the intrusion situation is an expansion of the intrusion, determine that the entry point of the attack is the area with the largest intrusion depth if the intrusion situation is an attack by the unauthorized device, and determine that the entry point of the attack is the area with the same intrusion depth if the intrusion situation is unchanged.

[0030] This allows the intrusion path analysis device to determine the entry point of the attack. By outputting the analysis result including the entry point, the intrusion path analysis device allows security analysts to understand the current entry point, and can output information useful for considering how to respond to the attack.

[0031] Also, for example, the intrusion route analysis unit may determine as part of the analysis that if there is one security alert and the intrusion depth of the security alert is higher than a predetermined threshold, that the intrusion is due to physical access or is a false positive.

[0032] This allows the intrusion path analysis device to make a decision regarding the analysis of the intrusion path even if there is only one security alert. The intrusion path analysis device outputs the analysis result including the judgment result, so that the security analyst can understand the current intrusion situation, and can output information useful for considering how to deal with the attack.

[0033] Also, for example, when the analysis includes the event related to the security alert, the intrusion route analysis unit may further determine that the event is due to the attack.

[0034] This allows the intrusion path analysis device to determine whether an event is caused by an attack even if there is only one security alert. Therefore, the intrusion path analysis device is more effective in analyzing attacks because it can output analysis results including detection results of unauthorized behavior that cannot be detected by security sensors.

[0035] Also, for example, the intrusion route analysis unit may perform at least one of strengthening a monitoring function of at least one of the one or more electronic control devices and the communication device, and restricting a function of at least one of the one or more electronic control devices and the communication device, depending on the intrusion depth of the security alert.

[0036] This enables the intrusion path analysis device to mitigate the effects of attacks by taking measures according to the depth of intrusion, thereby improving the security of the control network system.

[0037] Also, for example, the intrusion route analysis unit may output a notification to disable some functions of the control network system when the intrusion situation is determined to be an expanding intrusion and the maximum intrusion depth among the intrusion depths of the detected security alerts is equal to or greater than a predetermined threshold value.

[0038] As a result, the intrusion route analysis device can mitigate the impact of an attack if the intrusion spreads, and can effectively improve the security of the control network system.

[0039] Also, for example, the analysis results may include at least one of an entry point of the attack, a penetration depth of the attack, and history information including one or more of the security alerts and the event history.

[0040] In this way, the intrusion path analysis device allows a security analyst to grasp at least one piece of information among the entry point of an attack, the intrusion depth of an attack, and history information. The intrusion path analysis device allows a security analyst to effectively analyze an attack by using the at least one piece of information to analyze the attack.

[0041] Also, for example, the events may include at least one of logging in to a device located within the control network system, completion of installation and update of an application or firmware installed on the device, completion of firmware transfer, system diagnosis, and communication of a fault code.

[0042] This allows the intrusion path analysis device to determine whether or not at least one of the events is an event resulting from an attack activity. By appropriately selecting events according to the purpose of the control system network, the intrusion path analysis device can output an analysis result suitable for the purpose.

[0043] Also, for example, the security sensor may include at least one of a network intrusion detection system that detects signs of intrusion from network traffic, a host intrusion detection system that detects signs of intrusion from unauthorized behavior on the one or more electronic control devices, a firewall unauthorized packet detection system disposed in the control network system, a login failure detection sensor, a signature verification failure detection sensor, a verification failure detection sensor for a message authentication code included in a message on a network, and a security access failure detection sensor.

[0044] This enables the intrusion route analysis device to detect signs of an attack using multiple types of security sensors, thereby improving the accuracy of the analysis report it generates.

[0045] Furthermore, for example, the control network system may be an in-vehicle network system.

[0046] This enables the intrusion path analysis device to analyze the intrusion path to the in-vehicle network system, which is effective in dealing with attacks on the in-vehicle network system, leading to, for example, improved safety during vehicle travel.

[0047] Moreover, an intrusion path analysis method according to one embodiment of the present disclosure is an intrusion path analysis method in a control network system to which one or more electronic control devices and communication devices are connected, in which the control network system has one or more security sensors disposed on a network, in at least one of the one or more electronic control devices, and the communication devices, and which transmit a security alert including the detection of the sign of a security breach to the network when a sign of a security breach is detected, and the intrusion path analysis method includes a step of acquiring the security alert from the one or more security sensors, a step of acquiring an event history of an event that has occurred in the control network system, and an intrusion path analysis step of analyzing the intrusion path of the attack based on the security alert, the event history, and an intrusion depth that indicates the expected degree of intrusion of the attack when the security alert occurs, and outputting the analysis result.

[0048] This provides the same effects as the intrusion route analysis device described above.

[0049] Furthermore, these comprehensive or specific aspects may be realized in a system, an apparatus, a method, an integrated circuit, a computer program, or a non-transitory recording medium such as a computer-readable CD-ROM, or may be realized in any combination of a system, an apparatus, a method, an integrated circuit, a computer program, and a recording medium.

[0050] Hereinafter, an intrusion path analysis device and the like according to the embodiments of the present disclosure will be described with reference to the drawings. Note that the embodiments described below each show a preferred specific example of the present disclosure. In other words, the numerical values, shapes, materials, components, arrangement and connection forms of the components, steps, order of steps, and the like shown in the following embodiments are examples of the present disclosure and are not intended to limit the present disclosure. The present disclosure is specified based on the description of the claims. Therefore, among the components in the following embodiments, components that are not described in the independent claims showing the highest concept of the present disclosure are not necessarily required to achieve the objectives of the present disclosure, but are described as components constituting a more preferred form.

[0051] (Embodiment) Hereinafter, an intrusion route analysis device will be described for a vehicle equipped with an in-vehicle network (in-vehicle network system 10a) in which multiple electronic control units (ECUs) communicate via a CAN bus and Ethernet (registered trademark). The in-vehicle network system 10a is an example of a control network system that is a target for the intrusion route analysis device to analyze intrusion routes.

[0052] [1.1 Overall configuration of in-vehicle network monitoring system 1] 1 is an overall configuration diagram of an in-vehicle network monitoring system 1 in this embodiment. The in-vehicle network monitoring system 1 includes a vehicle 10, a network 20, and a server 30. The vehicle 10 analyzes security alerts that occur within the vehicle, generates an analysis report, and notifies the server 30 of the analysis report via the network 20. The network 20 may include the Internet or a dedicated line. The server 30 receives the report from the vehicle 10, and presents the security state (intrusion status) of the vehicle 10 to a security analyst or the like based on the analysis report.

[0053] [1.2 Network configuration of vehicle 10] 2 is a configuration diagram of an in-vehicle network system 10a mounted on a vehicle 10 in this embodiment. The in-vehicle network system 10a includes a TCU (Telematics Control Unit) 100, a central ECU 101, Ether switches 102 and 103, ECUs 104 to 111 (also referred to as ECU 104, etc.), Ethernet (registered trademark, the same applies below) 11 and 12 that communicatively connect each device, and CANs 13 and 14. Each device is equipped with a security sensor (for example, security sensor units 1004, 1005, 1104, 1202, and 1303 (also referred to as security sensor unit 1004, etc.) described later) that notifies a security alert, and the security alert is notified to the central ECU 101 via a network to which each device is connected. For example, in the in-vehicle network system 10a, one or more security sensors for detecting signs of security infringement are arranged on a sub-network described later, in at least one of the ECU 104, etc., and the TCU 100, and when a security sensor detects a sign of security infringement, it can be said that the security sensor transmits a security alert including the detection of the sign of security infringement to the sub-network. The sign of security infringement is an operation (such as verification failure) or information (such as source IP address, signature ID) that may be under attack, and is set in advance.

[0054] Furthermore, the central ECU 101 aggregates and analyzes security alerts notified from each device to generate an analysis report. Although omitted in FIG. 2, the in-vehicle network may include many more ECUs. The ECU is a device including, for example, a processor (microprocessor), digital circuits such as memory, analog circuits, and communication circuits. The memory is a ROM or RAM, and can store a control program (computer program) executed by the processor. For example, the processor operates according to the control program, and the ECU realizes various functions. Note that the computer program is configured by combining multiple instruction codes for the processor in order to realize a predetermined function.

[0055] In the Ethernet 11 , the TCU 100 , the central ECU 101 , the ECU 104 , and the ECU 105 communicate with each other via an Ether switch 102 .

[0056] In the Ethernet 12 , the central ECU 101 , the ECU 106 , and the ECU 107 communicate with each other via an Ether switch 103 .

[0057] Through the CAN 13, the central ECU 101, the ECU 108, the ECU 109, and the ECU 110 communicate with each other.

[0058] The CAN 14 allows communication between the ECU 107 and the ECU 111 .

[0059] The Ethernets 11 and 12 and the CANs 13 and 14 are examples of sub-networks. At least one of one or more ECUs and one or more TCUs 100 is communicatively connected to each of the sub-networks. The number of sub-networks constituting the in-vehicle network system 10a is not particularly limited as long as it is one or more, and may be, for example, two or more. In other words, the in-vehicle network system 10a may be composed of one or more sub-networks, and may be, for example, two or more sub-networks. The two or more sub-networks are connected to be communicative with each other (for example, capable of wired communication with each other).

[0060] The TCU 100 has a communication interface for communicating with a network (e.g., a network 20 outside the vehicle) or device outside the in-vehicle network monitoring system 1, and has a function of notifying the server 30 of an analysis report notified from the central ECU 101 via the network 20. The TCU 100 is disposed on at least one or more sub-networks out of the one or more sub-networks. The TCU 100 is an example of a communication device, and the communication interface is an example of an external connection interface.

[0061] The central ECU 101 is an ECU that plays a central role in the vehicle 10, and various applications run on it to realize the functions of the vehicle 10. The central ECU 101 also serves as a gateway for the Ethernet 11, the Ethernet 12, and the CAN 13. The central ECU 101 collects and analyzes security alerts from security sensors arranged in the vehicle 10, generates an analysis report on the occurrence of an attack in the vehicle 10 or an intrusion route, and notifies the TCU 100 of the report. Note that the analysis report may include, for example, information that can identify the intrusion route of the attack.

[0062] The Ether switch 102 realizes communication between the devices by receiving frames sent from devices connected to Ethernet 11 and transferring the frames to an appropriate port based on the contents of the frames. The Ether switch 103 similarly transfers frames connected to Ethernet 12.

[0063] The ECUs 104 to 111 realize control related to the running of the vehicle 10 by notifying sensor information in the vehicle 10 and controlling actuators in the vehicle 10. For example, the ECUs 104 and 105 connected to the Ethernet 11 are infotainment system ECUs that exchange data such as images and audio. The CAN 13 is a body system network, and the ECUs 108, 109, and 110 connected to the CAN 13 are ECUs that control the body systems such as doors, windows, and seats. The Ethernet 12 is a network through which sensor information such as cameras and radars outside the vehicle is exchanged, the ECU 106 is, for example, a radar ECU or a camera ECU, and the ECU 107 is an ECU that receives sensor information and realizes an automatic driving or driving assistance function. The CAN 14 is a network that communicates information on the powertrain or chassis system of the vehicle 10, and control information from the ECU 107 can be communicated. The ECU 111 is, for example, a steering ECU or an engine ECU.

[0064] [1.3 Configuration of TCU100] 3 is a configuration diagram of the TCU 100 according to the present embodiment. The TCU 100 includes an exterior communication unit 1001, an application unit 1002, an interior communication unit 1003, and security sensor units 1004 and 1005.

[0065] The vehicle exterior communication unit 1001 is a communication interface for wireless communication via the network 20, and communicates with the server 30 and transmits and receives information to and from the application unit 1002. The vehicle exterior communication unit 1001 also notifies the security sensor unit 1005, which monitors communication on the vehicle exterior network, of the communication contents.

[0066] The application unit 1002 runs an application for notifying the server 30 of information about the in-vehicle network, or an application for transmitting data to the in-vehicle network based on data received from the network 20. The application unit 1002 can run a plurality of applications.

[0067] The in-vehicle communication unit 1003 is connected to the Ethernet 11 and notifies the application unit 1002 of the received frame.

[0068] The security sensor unit 1004 is a host IDS (Intrusion Detection System) and monitors whether or not an application is performing unauthorized operations based on the behavior of the application unit 1002. The host IDS monitors, for example, the CPU, memory resource usage, communication volume, communication destination, access authority, etc. of the application, and monitors whether or not they are within standard values. If abnormal behavior is observed, the security sensor unit 1004 requests the application unit 1002 to send a security alert in order to notify the application unit 1002 of the security alert. The target monitored by the security sensor unit 1004 is, for example, the application unit 1002.

[0069] The security sensor unit 1005 is a network IDS, and monitors whether or not unauthorized communication is occurring based on the frames notified from the exterior communication unit 1001. The network IDS performs, for example, detection of abnormalities in packet communication volume, confirmation of suspicious communication destinations, detection of port scans, etc. If unauthorized communication is occurring, the security sensor unit 1005 makes a transmission request to the application unit 1002 to notify a security alert. The security sensor unit 1005 monitors the exterior communication unit 1001 and the application unit 1002, and, for example, information transmitted and received, such as frames.

[0070] [1.4 Configuration of Central ECU101] 4 is a configuration diagram of the central ECU 101 in this embodiment. The central ECU 101 has a communication unit 1101, an application unit 1102, an analysis engine unit 1103, a security sensor unit 1104, a security alert history storage unit 1105, and a vehicle event history storage unit 1106. The central ECU 101 functions as an intrusion route analysis device.

[0071] The communication unit 1101 is a communication interface for communicating via Ethernet 11, Ethernet 12, and CAN 13, and has a function of transferring received information to an appropriate network (sub-network) according to the communication content. The communication unit 1101 also transmits and receives information to and from the application unit 1102. The communication unit 1101 functions as an alert acquisition unit that acquires security alerts from each security sensor unit.

[0072] When the application unit 1102 receives a security alert, it operates a monitoring application for notifying the analysis engine unit 1103 of the security alert, and notifies (outputs) the security alert to the analysis engine unit 1103. The application unit 1102 also extracts a vehicle event, and notifies the analysis engine unit 1103 of the extracted vehicle event. A vehicle event in the ECU 104 or the like may be acquired, for example, from an application unit included in the ECU 104 or the like via the communication unit 1101. The vehicle event will be described later. Note that the vehicle event is one example of an event.

[0073] The analysis engine unit 1103 analyzes the intrusion path of the attack based on the security alert, the vehicle event history (an example of an event history), and the depth indicating the assumed degree of intrusion of the attack when the security alert is issued, and outputs an analysis report. For example, it can be said that the analysis engine unit 1103 analyzes the intrusion path based on the security alert, generates an analysis report, and notifies the application unit 1102. The analysis engine unit 1103 is an example of an intrusion path analysis unit, and the analysis report is an example of an analysis result.

[0074] The analysis engine unit 1103 also collects security alerts received from the in-vehicle network, and stores them in the security alert history storage unit 1105. The analysis engine unit 1103 also receives information related to vehicle events from the application unit 1102, and stores it in the vehicle event history storage unit 1106.

[0075] The security sensor unit 1104 is a host IDS that monitors the behavior of applications in the central ECU 101, or a network IDS that monitors the communication content of the in-vehicle network, and notifies the application unit 1102 of a security alert if unauthorized behavior or unauthorized communication is observed.

[0076] The security alert history storage unit 1105 stores (accumulates) previously received security alerts. The history of security alerts stored in the security alert history storage unit 1105 (see, for example, FIG. 10 described later) will be described later.

[0077] The vehicle event history storage unit 1106 stores (accumulates) the history of vehicle events notified from the application unit 1102. The vehicle event history stored in the vehicle event history storage unit 1106 (see, for example, FIG. 11 described later) will be described later.

[0078] [1.5 Ether Switch 102 Configuration Diagram] 5 is a configuration diagram of the Ether switch 102 in this embodiment. The Ether switch 103 has a similar configuration, so a description thereof will be omitted.

[0079] The Ether switch 102 includes a communication unit 1201 and a security sensor unit 1202 .

[0080] The communication unit 1201 has four physical ports, which are respectively connected to the TCU 100, the ECU 104, the ECU 105, and the central ECU 101, and transfers the frame according to the contents of the received frame. The communication unit 1201 also notifies the security sensor unit 1202 of the frame in order to monitor the received frame.

[0081] The security sensor unit 1202 is a network IDS that monitors frames notified from the communication unit 1201 and checks whether or not unauthorized communication is occurring. If the security sensor unit 1202 determines that unauthorized communication is occurring, it generates a security alert and requests the communication unit 1201 to transmit the security alert.

[0082] [1.6 ECU104 configuration diagram] 6 is a configuration diagram of the ECU 104 in this embodiment. Note that the ECUs 105 to 111 have the same configuration, so their explanations will be omitted.

[0083] The ECU 104 includes a communication unit 1301 , an application unit 1302 , and a security sensor unit 1303 .

[0084] The communication unit 1301 is a communication interface that is connected to the Ethernet 11 and transmits and receives frames.

[0085] An application unit 1302 executes applications such as reading sensor values ​​from sensors connected to the ECU 104 and controlling actuators.

[0086] The security sensor unit 1303 is a host IDS that monitors the behavior of the application unit 1302, and detects security-related events such as an access error of a diagnostic command, a failure to verify a message authentication code included in a frame, etc. When the security sensor unit 1303 detects an unauthorized security event, it generates a security alert and requests the communication unit 1301 to send the security alert.

[0087] [1.7 Server 30 configuration diagram] 7 is a configuration diagram of the server 30 in this embodiment. The server 30 includes a communication unit 3001, an application unit 3002, and a UI (User Interface) unit 3003.

[0088] The communication unit 3001 is a communication interface for wireless communication via the network 20 , receives an analysis report sent from the vehicle 10 , and sends the analysis report to the application unit 3002 .

[0089] The application unit 3002 is an application that performs secondary analysis of the received analysis report.

[0090] The UI unit 3003 is a user interface that presents the received analysis report to a security analyst. The security analyst confirms the occurrence of an attack on the vehicle 10 based on the presented analysis report and determines how to respond. The UI unit 3003 is realized by, for example, a display device, an audio output device, etc., but is not limited to these.

[0091] [1.8 Example of a security alert] Fig. 8 is a diagram showing an example of a security alert output by the security sensor unit 1004 etc. in this embodiment. The security alert includes at least one of the time when the security alert occurred, the location where the security alert occurred, and the depth determined based on the monitoring target of the security sensor, an alert No. which is the serial number of the alert, an alert ID for identifying the type of alert, and a field for notifying detailed information of the alert. Fig. 8 illustrates an example in which the location where the security alert occurred and the depth determined based on the monitoring target of the security sensor out of the depths determined based on the monitoring target of the security sensor are included.

[0092] Figure 8 shows an example of a security alert in which a security alert occurred at 11:50:20, the depth is 5, the alert No. is 10001, the alert ID is 0001, and the alert details indicate that verification of the message authentication code with ID 100 has failed.

[0093] The depth is set to 1 when the security sensor monitors an external network, 2 when the security sensor monitors a first device having an external device interface such as a Universal Serial Bus (USB) port, an On-Board Diagnostics (OBD) 2 port, or Bluetooth (registered trademark, same below), 3 when the security sensor monitors a first in-vehicle network connected to the first device, 4 when the security sensor monitors a second device connected to the first in-vehicle network other than the first device, or 5 when the security sensor monitors a second in-vehicle network other than the first in-vehicle network connected to the second device.The depth is set to a larger value as the external network and the number of devices or networks passed through before accessing from an external device increase.

[0094] For example, the TCU 100 shown in FIG. 2 may be set to a depth of 1, the Ether switch 102 may be set to a depth greater than that of the TCU 100 (e.g., a depth of 2), the central ECU 101 may be set to a depth greater than that of the Ether switch 102 (e.g., a depth of 3), the Ether switch 103 may be set to a depth greater than that of the central ECU 101 (e.g., a depth of 4), and the ECUs 106 and 107 may be set to a depth greater than that of the Ether switch 103 (e.g., a depth of 5). In this manner, the depth may be set for each device, for example. Also, when the number of devices passing through the TCU 100 is the same, such as the ECUs 106 and 107, the depth may be set to the same value. The depth may be set in advance, and each security sensor unit may store information regarding the depth. The depth is an example of an intrusion depth.

[0095] The depth of the monitored object may be determined by at least one of the physical and logical number of hops through at least one of the sub-networks, such as ECU 104, and the gateway device (in this embodiment, central ECU 101) that connects the sub-networks, from a device that is expected to be attacked first, such as an externally connected device (e.g., TCU 100), to a monitored object of the security sensor unit (e.g., a device to be monitored). In this embodiment, the depth of the monitored object is set to be larger as the number of devices or networks physically hopped through increases. The depth may be determined by only the logical number of hops, out of the physical number of hops and the logical number of hops, rather than the physical number of hops.

[0096] For example, when the in-vehicle network is configured as a virtual network, even if the device or network is physically adjacent, if it is logically separated, the depth may be determined as being non-routable. Also, it does not have to be the number of routes from an external connection device to a monitoring target. For example, the depth may be determined according to the security strength of each monitoring target, the risk of an attack, etc. The depth may be set to be large for a monitoring target that is difficult for an attacker to access or that would lead to a serious security risk if attacked. A large depth indicates a state in which an attack is progressing deeper into the in-vehicle network system 10a.

[0097] The time when the security alert is generated may be a timer count from when the vehicle ignition is turned on. The security alert may be encrypted before being transmitted, and may include a message authentication code.

[0098] [1.9 Example of analysis report] 9 is a diagram showing an example of history information included in an analysis report generated by the central ECU 101 in this embodiment. The history information includes, for each depth, the occurrence time of a security alert or vehicle event, an alert ID or vehicle event, and an indicator that indicates the content of the attack. In this embodiment, the history information includes the history of security alerts as well as the history of vehicle events. Note that it is not essential that the history information includes vehicle events.

[0099] FIG. 9 shows that at 11:45:10, a security alert with a depth of 1 and an alert ID of 0011 (port scan detected) occurred, and the source IP address, which is an indicator of an attack, is aaa.bbb.ccc.ddd. At depth 2, neither a security alert nor a vehicle event was observed. At 11:47:15, a security alert with a depth of 3 and an alert ID of 0010 (network IDS alert) occurred, and the indicator of the attack was the network IDS signature ID, which matched 0x12345. At 11:48:30, a vehicle event with a depth of 4 occurred, in which one of the apps in the central ECU 101 was updated, and the indicator was the hash value of the app, which was 0x56ab78cd90ef. Also, at 11:50:20, a security alert with alert ID 0001 (message authentication code verification failed) occurred at depth 5, and the indicator shows that the CAN ID is 0x100. Also, for depths 6 to 8, it shows that neither a security alert nor a vehicle event occurred.

[0100] The central ECU 101 may generate the history information shown in Fig. 9 by, for example, reading one or more security alerts (security alert history) from the security alert history storage unit 1105, reading one or more vehicle events (vehicle event history) from the vehicle event history storage unit 1106, and arranging the one or more read security alerts and one or more vehicle events in order of occurrence. The central ECU 101 may generate the history information shown in Fig. 9 by using the start of a process of analyzing the intrusion route of an attack as a trigger.

[0101] The example in Figure 9 shows history information in which the depth increases over time, but it is also possible that the depth decreases over time, or that a security alert of the same depth occurs even after time has passed.

[0102] It should be noted that no security alert is generated at depth 2, but this is assumed to be because the security sensor unit of the device corresponding to depth 2 (for example, the security sensor unit 1202 of the Ether switch 102) has missed the abnormal behavior. In this embodiment, since the history information is transmitted to the server 30, a security analyst can verify whether or not the abnormal behavior has been overlooked. The history information is an example of information that can identify the intrusion route of an attack.

[0103] The depth for the vehicle event is set in advance. The depth for the vehicle event may be set according to the device that executes the vehicle event (for example, set according to the number of devices physically connected from the TCU 100), and may be the same as the depth when the security sensor unit of the device detects abnormal behavior. The depth for the vehicle event may be set according to the content of the vehicle event. The depth for the vehicle event may be stored in the central ECU 101, for example, but is not limited to this.

[0104] In this embodiment, the analysis report including the history information is notified in plain text, but it may be notified in encrypted form and may include a message authentication code.

[0105] The analysis report may also include information on the device or domain (network) that was the entry point of the attack, information showing the route by which the intrusion is progressing (whether the intrusion is expanding with an increase in depth or whether it is limited to a localized attack, etc.), and information on a warning depending on the current depth of the attack. An example of the information included in the analysis report will be described later (see FIG. 19).

[0106] [1.10 Example of security alert history] 10 is a diagram showing an example of a security alert history stored in security alert history storage unit 1105 in this embodiment. Security alert history storage unit 1105 stores a security alert reception history such as that shown in FIG.

[0107] Figure 10 shows the history of three security alerts received. The first security alert occurred at 11:45:10, has a depth of 1, an alert number of 23042, an alert ID of 0011, and the alert details show that the source IP address is aaa.bbb.ccc.ddd. The second security alert occurred at 11:47:15, has a depth of 3, an alert number of 5000, an alert ID of 0010, and the alert details show that the signature ID is 0x12345. The third alert occurred at 11:50:20, has a depth of 5, an alert number of 10001, an alert ID of 0001, and the alert details show that the verification of the message authentication code with ID 100 failed.

[0108] It should be noted that the security alert history shown in FIG. 10 may also include other types of alerts.

[0109] [1.11 Example of vehicle event history] 11 is a diagram showing an example of a vehicle event history stored in the vehicle event history storage unit 1106 in this embodiment. Unlike security alerts, the vehicle event history storage unit 1106 stores a history of events (vehicle events) indicating state changes within the vehicle 10. A vehicle event can be acquired from a frame flowing through the in-vehicle network or a state change within the ECU 104 or the like. For example, a vehicle event may be acquired by the application unit 1102 based on a frame flowing through the in-vehicle network or a state change within the ECU 104 or the like. The application unit 1102 functions as an event acquisition unit that acquires a vehicle event that has occurred within the in-vehicle network, for example.

[0110] Examples of vehicle events include, but are not limited to, login to a device located in the vehicle network, installation and update completion of an application or firmware mounted on the device, firmware transfer completion, system diagnosis, and communication of a fault code. Vehicle events may be the open / close state of the vehicle door key, a change in the ON / OFF state of the ignition switch, the start of driving, activation / deactivation of a driving assistance function, transition to an autonomous driving mode, completion of firmware update of an ECU in the vehicle, completion of an application update or new installation, start of diagnostic communication, system login notification, etc.

[0111] Even if these vehicle events are performed normally, there is a possibility that they are performed as a result of an attacker disabling the security functions. Therefore, the vehicle event history storage unit 1106 stores vehicle events even if they are completed normally. The stored vehicle events are used in combination with other security alerts to determine whether they have been exploited by an attacker. The stored vehicle events are also used for the purpose of analyzing the occurrence status of security alerts.

[0112] For example, a security alert may occur due to a false positive detection by the security sensor unit 1004 or a partial failure of the vehicle system. Therefore, the analysis engine unit 1103 can improve the accuracy of the analysis report by analyzing vehicle events and the occurrence status of security alerts together, thereby filtering out security alerts in the occurrence status of vehicle events that are prone to false positive detection, or filtering out security alerts caused by failures.

[0113] FIG. 11 shows vehicle events in which the vehicle ignition is turned on at 11:24:00, the vehicle starts driving at 11:26:06, the autonomous driving mode is started at 11:31:35, and the application update of central ECU 101 is completed at 11:48:30.

[0114] The vehicle event history storage unit 1106 may store the vehicle event history shown in FIG. 11 in association with the depth of each vehicle event.

[0115] [1.12 Intrusion path analysis sequence in central ECU 101] 12 is a diagram showing a first intrusion path analysis sequence in the central ECU 101 of this embodiment. The first intrusion path analysis sequence shown in FIG.

[0116] (S101) The TCU 100 notifies a security alert (depth 1).

[0117] (S102) The central ECU 101 receives the security alert and stores (preserves) it in the security alert history storage unit 1105.

[0118] (S103) The Ether switch 102 issues a security alert (depth 3).

[0119] (S 104 ) The central ECU 101 receives the security alert and stores it in the security alert history storage unit 1105 .

[0120] (S105) The central ECU 101 updates the application, and stores information indicating that the update has been completed in the vehicle event history storage unit 1106.

[0121] (S106) ECU 110 issues a security alert (depth 5).

[0122] (S 107 ) The central ECU 101 receives the security alert and stores it in the security alert history storage unit 1105 .

[0123] (S108) The central ECU 101 starts analyzing the intrusion route. The central ECU 101 may start analyzing the intrusion route, for example, when it receives a security alert whose depth is higher than a predetermined threshold (for example, Yes in step S203 shown in FIG. 14) or when it is a periodic notification timing (Yes in S208).

[0124] The trigger for the central ECU 101 to start analyzing an intrusion route will be described later. In steps S101, S103, and S105, the central ECU 101 is not notified of a security alert indicator (information that serves as an index of an attack).

[0125] It should be noted that security alerts and vehicle events continue to be collected until the operation shown in FIG. 13, which will be described later, is executed.

[0126] Fig. 13 is a diagram showing a second intrusion path analysis sequence in the central ECU 101 of the present embodiment. The second intrusion path analysis sequence shown in Fig. 13 is a diagram showing a latter half of the intrusion path analysis sequence in the central ECU 101. The operation shown in Fig. 13 is executed after the operation shown in Fig. 12.

[0127] (S109) The central ECU 101 requests an indicator for a security alert (depth 1).

[0128] (S110) In response to the indicator request, the TCU 100 notifies (transmits) information on the source IP address, which is an indicator of a security alert (depth 1).

[0129] (S111) The central ECU 101 requests an indicator for a security alert (depth 3).

[0130] (S112) In response to the indicator request, the Ether switch 102 notifies (transmits) a signature ID that serves as an indicator of a security alert (depth 3).

[0131] (S113) The central ECU 101 requests an indicator for a security alert (depth 5).

[0132] (S114) In response to the indicator request, the ECU 110 notifies the CAN ID that serves as an indicator of a security alert (depth 5).

[0133] (S115) The central ECU 101 generates an analysis report based on the obtained information and notifies (transmits) the TCU 100 of the analysis report.

[0134] (S116) The TCU 100 notifies (transmits) the analysis report notified by the central ECU 101 to the server 30.

[0135] It should be noted that the order in which the central ECU 101 requests the security alert indicators is not limited to the order in which the security alerts are received.

[0136] In this embodiment, the central ECU 101 requests an indicator for a security alert when analyzing an intrusion route, but the indicator collection process does not necessarily have to be performed, and the indicator may be included in the security alert notification (S101, S103, and S106 shown in FIG. 12).

[0137] [1.13 Analysis report notification flow chart in central ECU] Fig. 14 is a flowchart up to notification of an analysis report in the central ECU 101 of this embodiment. Fig. 14 can also be said to be a flowchart in which the central ECU 101 generates an analysis report. Note that the following processing is executed by, for example, the analysis engine unit 1103 of the central ECU 101. Also, although an example in which a vehicle event is used to generate the analysis report will be described below, the use of a vehicle event is not essential.

[0138] The central ECU 101 determines whether or not a security alert has been received (S201). If a security alert has been received (Yes in S201), the central ECU 101 executes step S202, and if a security alert has not been received (No in S201), the central ECU 101 executes step S206.

[0139] Next, when the central ECU 101 receives a security alert, it updates the security alert history in the security alert history holding unit 1105 (S202). The central ECU 101 adds the security alert received in step S201 to the security alert history.

[0140] Next, the central ECU 101 determines whether the depth of the received security alert is greater than a predetermined threshold (S203). The central ECU 101 performs the determination of step S203 every time it receives a security alert. If the depth of the received security alert is equal to or less than the predetermined threshold (No in S203), the central ECU 101 ends the process of generating an analysis report. If the depth of the received security alert is greater than the predetermined threshold (Yes in S203), the central ECU 101 executes step S204.

[0141] Next, the central ECU 101 analyzes the intrusion path of the attack (S204). The analysis of the intrusion path will be described later.

[0142] Next, the central ECU 101 generates an analysis report based on the analysis result, notifies the server 30 of the generated analysis report (S205), and ends the process of generating the analysis report.

[0143] Furthermore, if the central ECU 101 has not received a security alert, it determines whether or not there has been an update to the vehicle event (S206). The central ECU 101 checks whether or not a frame related to an update to the vehicle event has been received, or an update to an application of the central ECU 101 has occurred. If there has been an update to the vehicle event (Yes in S206), the central ECU 101 updates the vehicle event history stored in the vehicle event history holding unit 1106 (S207) and ends the process of generating the analysis report. In other words, if the answer is Yes in step S206, the vehicle event is simply added to the vehicle event history, and no analysis report is generated.

[0144] Furthermore, when there is no update of the vehicle event (No in S206), the central ECU 101 judges whether or not it is time for a periodic notification of the analysis report (S208). When it is not time for a periodic notification (No in S208), the central ECU 101 ends the process of generating the analysis report. When it is time for a periodic notification (Yes in S208), the central ECU 101 collects indicators corresponding to the security alert stored in the security alert history holding unit 1105 (S209). Note that when there is no security alert history, the indicators may not be collected in step S209. Note that the process of step S209 corresponds to, for example, steps S109 to S114 shown in FIG. 13.

[0145] The central ECU 101 generates an analysis report based on the collected information (S210), notifies the server 30 of the generated analysis report (S211), and ends the process of generating the analysis report.

[0146] [1.14 Flowchart of intrusion route analysis in central ECU 101] Fig. 15 is a flowchart showing details of step S204 in Fig. 14. The flowchart shown in Fig. 15 is executed when the depth of the security alert received in step S201 is greater than a predetermined threshold.

[0147] The central ECU 101 checks (determines) whether or not another type of security alert is stored in the security alert history storage unit 1105 (S1201). The central ECU 101 may perform the check in step S1201, for example, based on whether or not a security alert received within a predetermined period based on the time at which the security alert was received in step S201 is stored in the security alert history storage unit 1105. Note that another type of security alert refers to a security alert in which at least one of the depth and the alert ID included in the security alert is different.

[0148] If there is no other type of security alert (No in S1201), the central ECU 101 executes step S1210.

[0149] Furthermore, if there is another type of security alert (Yes in S1201), the central ECU 101 checks whether or not a vehicle event has occurred during the time period in which the security alert occurred (for example, from the occurrence time of the oldest security alert included in the security alert history to the present) (S1202). If the answer is Yes in step S1201, the other types of security alert include two or more alerts of different types.

[0150] If a vehicle event has not occurred (No in S1202), the central ECU 101 executes step S1205.

[0151] Furthermore, when a vehicle event occurs (Yes in S1202), the central ECU 101 checks whether the depth of the security alert has changed (for example, an unobserved depth becomes observed) before and after the occurrence of the vehicle event (S1203). For example, the central ECU 101 determines that the depth has changed when the depth of the security alert has increased or decreased before and after the occurrence of the vehicle event. Note that in step S1203, the central ECU 101 may determine that the depth of the security alert has changed when the change in the depth of the security alert has changed by a predetermined amount or more before and after the occurrence of the vehicle event.

[0152] In this way, when there are multiple security alerts of different types, the central ECU 101 determines whether the vehicle event is caused by an attack based on the time change in the depth of the multiple security alerts and the vehicle event that occurred during the time period when the multiple security alerts were detected. For example, when the occurrence distribution (time distribution) of the depth changes before and after the occurrence time of the vehicle event included in the vehicle event history, the central ECU 101 determines that the vehicle event is caused by an attack.

[0153] If the depth of the security alert has not changed (No in S1203), the central ECU 101 executes step S1209.

[0154] Furthermore, if the depth of the security alert has changed (Yes in S1203), the central ECU 101 determines that the corresponding vehicle event is an unauthorized vehicle event caused by an attack (S1204). Note that the vehicle event is also considered to be a vehicle event related to security alerts before and after the occurrence of the vehicle event.

[0155] Next, the central ECU 101 checks whether the depth of the security alert increases as the occurrence time of the security alert stored in the security alert history storage unit 1105 becomes later (S1205). That is, the central ECU 101 judges whether the depth of the security alert increases from the past to the present. At this time, the depth of the security alert does not necessarily increase monotonically. For example, the central ECU 101 may judge that the depth of the security alert is increasing if the occurrence order of the security alerts observed for the first time at each depth shows an increasing trend. For example, if the depths of the security alert history are arranged in order of the occurrence time of the security alerts as 1, 2, 1, 2, 3, 2, 1, 3, 1, 4, the occurrence order of the security alerts observed for the first time at each depth is 1, 2, 3, 4, so the central ECU 101 judges that the depth is increasing as time passes.

[0156] If the depth of the security alert increases over time (for example, is showing an increasing trend) (Yes in S1205), the central ECU 101 determines that the intrusion is expanding (S1206) and executes step S1213.

[0157] Furthermore, if the depth of the security alert has not increased over time (No in S1205), the central ECU 101 executes step S1207.

[0158] Next, the central ECU 101 checks whether the depth of the security alert is decreasing over time (S1207). If the depth of the security alert is decreasing over time (Yes in S1207), the central ECU 101 determines that the impact of an attack from a location with a large depth is spreading, such as when an unauthorized device is connected inside the vehicle 10 (S1208), and executes step S1213. For example, if no abnormality is detected in devices with a low security alert depth, such as the TCU 100 and the Ether switch 102, and an abnormality is suddenly detected in a device with a high security alert depth, such as the ECU 111, the central ECU 101 determines that an attack is progressing with the EUC 111 as the starting point, such as when an unauthorized device is connected to the ECU 111.

[0159] In addition, if the depth of the security alert does not decrease over time (No in S1207), that is, if the depth of the security alert remains constant, the central ECU 101 determines that there is no change in the attack occurrence situation (S1209) and executes step S1213.

[0160] Furthermore, if there is no other type of security alert, for example, if there is only one security alert, the central ECU 101 checks the vehicle event history storage unit 1106 to see whether or not a vehicle event has occurred immediately prior to the reception of the security alert (S1210). The determination in step S1210 is to determine whether or not there is a vehicle event related to the received security alert.

[0161] In this case, if a vehicle event occurs immediately before the reception of the security alert, it is determined that the received security alert and the vehicle event are related to each other. Note that the term "immediately" is set in advance and may be, for example, several minutes, tens of minutes, or the like, but is not limited to this.

[0162] Next, when a vehicle event is present (Yes in S1210), the central ECU 101 determines that the corresponding vehicle event is an unauthorized vehicle event caused by an attacker (S1211), and executes step S1213. In other words, when a vehicle event related to a security alert is present as an analysis of an intrusion route, the central ECU 101 may determine that the vehicle event is caused by an attack.

[0163] Furthermore, if there is no vehicle event (No in S1210), the central ECU 101 determines that the security alert is either an intrusion by physical access, a malfunction, or a false positive (for example, a false positive caused by a malfunction, etc.) (S1212), and executes step S1213. Note that, if No in step S1210, the central ECU 101 may end the process of analyzing the intrusion route.

[0164] Next, the central ECU 101 collects indicators corresponding to each security alert stored in the security alert history storage unit 1105 (S1213), generates an analysis report after the collection (S1214), and ends the process of analyzing the intrusion route. The process of generating the analysis report will be described later (see FIG. 17 described later). Note that the process of step S1213 corresponds to, for example, steps S109 to S114 shown in FIG. 13.

[0165] As described above, the central ECU 101 may, for example, in analyzing an intrusion route, determine that the intrusion situation is an escalating intrusion when the depth of the security alert increases over time, determine that the intrusion situation is an attack by an unauthorized device when the depth of the security alert decreases over time, and determine that the intrusion situation is unchanged when the depth of the security alert does not change over time. The central ECU 101 may also output the determination result by including it in an analysis report.

[0166] This makes it possible to inform security analysts of the current intrusion status, and thus allows the security analysts to utilize the intrusion status in their analysis of attacks.

[0167] The determination in step S1210 does not have to be performed. In this case, the central ECU 101 may determine that the intrusion is due to physical access or that the detection is false if there are no other types of security alerts, that is, if there is only one security alert and the depth of the security alert is higher than a predetermined threshold, as the analysis of the intrusion route.

[0168] [1.15 Effect of the embodiment] The central ECU 101 (an example of an intrusion path analysis device) according to this embodiment collects security alerts notified from the security sensor unit 1004 etc. arranged in the vehicle 10, and generates and notifies an analysis report that determines the intrusion path of the attack using the depth determined based on the monitoring target of the security sensor unit 1004 etc. and included in the collected security alert, and the time of occurrence of the security alert. As a result, by presenting a detailed analysis report to a security analyst in the server 30, it becomes possible to quickly grasp and respond to the occurrence status and entry point of the attack.

[0169] Furthermore, by analyzing vehicle events and security alerts together, the analysis engine unit 1103 can determine whether or not a vehicle event that was completed normally was exploited by an attacker. This makes it possible to grasp the impact of attacks that cannot be detected by the security sensor unit 1004, etc., and allows security analysts to better grasp the overall picture of the attack and respond accordingly.

[0170] [Other variations] Although the present disclosure has been described based on the above-mentioned embodiments, the present disclosure is not limited to the above-mentioned embodiments. The following cases are also included in the present disclosure.

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

[0172] (2) In the above embodiment, the analysis of the intrusion route is performed on the central ECU 101, but it does not have to be performed on the central ECU 101. For example, it may be performed on the head unit or the TCU 100, or the intrusion route analysis may be performed on the server 30 by notifying the server 30 of a security alert. In other words, the functions of the analysis engine unit 1103 may be allocated in any manner between the server 30 and the vehicle 10. Also, for example, when the analysis engine unit 1103 is provided in the server 30, the analysis engine unit 1103 and the in-vehicle network are connected to be able to communicate with each other (for example, be able to communicate wirelessly).

[0173] (3) In the above embodiment, the security sensor unit 1004 etc. detects network IDS, host IDS, and message authentication code verification failures, etc., but the abnormalities detected by the security sensor unit are not limited to these. For example, security access failures during diagnosis, ssh login failures, firewall filtering results, update verification failures, etc. may also be used as detection results of the security sensor unit 1004 etc. Furthermore, the method of arranging the security sensor units is not limited to this embodiment, and they may be arranged freely.

[0174] (4) In the above embodiment, the security alert includes the depth, but the depth does not necessarily have to be included. The security alert only needs to include information that enables the analysis engine unit 1103 to grasp the monitoring target of the security sensor unit 1004 and the like and to calculate the depth.

[0175] Fig. 16 is a diagram showing an example of a security sensor placement database in this modified example. For example, as shown in Fig. 16, the analysis engine unit 1103 holds the security sensor placement database, and the analysis engine unit 1103 may be configured to grasp (e.g., calculate) the depth from the alert ID, sender information, etc. included in the security alert.

[0176] In the example of FIG. 16, the security alert output from the network IDS arranged in the TCU 100 has a depth of 1, and the security alert output from the host IDS also arranged in the TCU 100 has a depth of 2. In this way, even if the security sensor units are provided in the same device, different depths may be set according to the monitoring target of the security sensor units. Furthermore, the security alert output from the network IDS arranged in the Ether switch 102 has a depth of 3, and the security alert output from the host IDS arranged in the central ECU 101 has a depth of 4. Furthermore, the security alert output based on the verification result of the message authentication code arranged in the central ECU 101, ECUs 108, 109, and 110 has a depth of 5, and the security alert output from the network IDS arranged in the Ether switch 103 has a depth of 6. Furthermore, the security alert output from the host IDS arranged in the ECU 107 has a depth of 7, and the security alert output from the network IDS arranged in the ECU 107 has a depth of 8.

[0177] (5) In the above embodiment, an example was given in which the external connection device was the TCU 100, but the number of external connection devices is not limited to one, and there may be, for example, a head unit having a Bluetooth or USB connection interface, an OBD port, etc. In this case, the depth of a monitoring target such as the security sensor unit 1004 changes in the number of passes depending on which external connection device it is viewed from, but after calculating the depth in each external connection device, the minimum value may be used as the depth.

[0178] (6) In the above embodiment, the analysis report is notified from the TCU 100 to the server 30, but the method of notifying the server 30 is not limited to via the TCU 100. For example, the central ECU 101 may have a communication interface for wireless communication via a mobile phone network and may notify the server 30 of the analysis report directly. Also, the central ECU 101 may not notify the server 30 of the analysis report, but may instead retain it internally as a log and make it readable by a diagnostic command or the like.

[0179] (7) In the above embodiment, the central ECU 101 notifies the analysis report at regular intervals. However, the analysis report does not have to be notified at regular intervals. This is effective in reducing the amount of communication to the server 30.

[0180] (8) In the above embodiment, the central ECU 101 analyzes the intrusion route and sends an analysis report when it receives a security alert whose depth exceeds a predetermined threshold, but if the same type of security alert exists in the security alert history, the intrusion route has already been analyzed and the analysis report has already been sent, so these processes may be omitted. This is effective in reducing the resources consumed by the central ECU and the amount of communication to the server 30.

[0181] (9) In the above embodiment, the security alert history storage unit 1105 and the vehicle event history storage unit 1106 store the history of received security alerts and vehicle events, but the history of security alerts and vehicle events may be deleted after a predetermined period of time has elapsed. This makes it possible to remove the influence of security alerts or vehicle events that are unrelated to recent attack activities in the analysis of intrusion routes, which is effective in improving the accuracy of the analysis report.

[0182] (10) In the above embodiment, the central ECU 101 only notifies the user of the analysis report and does not take any action within the vehicle 10. However, the central ECU 101 may issue a warning depending on the intrusion situation and take a provisional action within the vehicle 10 in response to the warning. This makes it possible to prevent the attack from spreading further, which is effective in improving security.

[0183] Fig. 17 shows a flowchart for determining a response according to the intrusion route analysis result of the central ECU 101 in this modified example. In the flowchart shown in Fig. 17, the entry point of the attack and a response are determined using the determination results of steps S1206, S1208, and S1209 shown in Fig. 15. Note that the processes of steps S1301 to S1307 shown in Fig. 17 are processes for determining the entry point of the attack.

[0184] The central ECU 101 checks (determines) whether or not the intrusion path analysis in Fig. 15 has determined that the intrusion is expanding (S1301). If the determination in step S1206 has been performed, the central ECU 101 determines Yes in step S1301, and if the determination in step S1206 has not been performed, the central ECU 101 determines No in step S1301.

[0185] When it is determined that the intrusion is expanding (Yes in S1301), the central ECU 101 determines that the entry point of the attack is the area with the smallest depth among the security alerts stored in the security alert history storage unit 1105 (for example, the periphery of the monitored area of ​​the security sensor unit 1104, etc.) (S1302), and executes step S1308. Note that in step S1302, the central ECU 101 may determine that the maximum depth among the security alerts stored in the security alert history storage unit 1105 is the intrusion depth of the current attack. In this case, the depth of the entry point of the attack and the intrusion depth of the attack are different from each other.

[0186] If the intrusion is not spreading (No in S1301), the central ECU 101 checks whether the attack is spreading due to an unauthorized internal device connection (S1303). If the determination in step S1208 has been made, the central ECU 101 determines Yes in step S1303, and if the determination in step S1208 has not been made, the central ECU 101 determines No in step S1303.

[0187] If the attack influence is spreading due to an unauthorized internal device connection (Yes in S1303), the central ECU 101 determines that the entry point of the attack is the area with the greatest depth among the security alerts stored in the security alert history storage unit 1105 (S1304), and executes step S1308. Note that in step S1304, the central ECU 101 may determine that the greatest depth among the security alerts stored in the security alert history storage unit 1105 is the intrusion depth of the attack. In this case, the depth of the entry point of the attack and the intrusion depth of the attack match.

[0188] If the attack is not caused by an unauthorized internal device connection (No in S1303), the central ECU 101 checks whether the attack situation has not changed (S1305). If the determination in step S1209 has been made, the central ECU 101 determines Yes in step S1305, and if the determination in step S1209 has not been made, the central ECU 101 determines No in step S1305.

[0189] If there is no change in the attack situation (Yes in S1305), the central ECU 101 determines that the entry point of the attack is an area of ​​each depth of the security alert stored in the security alert history storage unit 1105 (S1306), and executes step S1308. Note that in step S1306, since the depths of the security alerts stored in the security alert history storage unit 1105 are the same, the central ECU 101 may determine that each depth (the same depth) is the intrusion depth of the attack. In this case, the entry point of the attack and the intrusion depth of the attack match.

[0190] Furthermore, if the attack situation is not unchanged (No in S1305), that is, if the attack situation has changed, the central ECU 101 determines that the depth of the security alert stored in the security alert history storage unit 1105 is the entry point of the attack and the intrusion depth (S1307), and executes step S1308. In step S1307, the central ECU 101 determines that the entry point of the attack is the area of ​​the alert depth. Note that, if the result is No in step S1305, the central ECU 101 does not need to perform the process of determining the entry point of the attack. In other words, if the result is No in step S1305, a warning does not need to be issued.

[0191] In this way, for example, in analyzing an intrusion path, the central ECU 101 may determine that the entry point of the attack is the area with the smallest depth when the intrusion situation is an expanding intrusion, determine that the entry point of the attack is the area with the largest depth when the intrusion situation is an attack by an unauthorized device, and determine that the entry point of the attack is the area with the same depth when the intrusion situation remains unchanged. The central ECU 101 may also output the determination result by including it in an analysis report.

[0192] In this way, the central ECU 101 allows a security analyst to grasp the entry point of an attack. The security analyst can grasp the intrusion path and intrusion method of the attack from the analysis report, and can obtain information that is useful for considering how to respond to the attack.

[0193] Next, the central ECU 101 issues a warning to the target ECU 104 etc. according to the intrusion depth (S1308). For example, the central ECU 101 may execute at least one of strengthening a monitoring function for at least one of the one or more ECUs 104 etc. and the TCU 100 and restricting a function of at least one of the one or more ECUs 104 etc. and the TCU 100 according to the depth of the security alert. The decision and execution of the warning are executed before receiving information indicating a response from the server 30. For example, the decision and execution of the warning may be executed before transmitting an analysis report to the server 30. An example of the warning will be described with reference to FIG. 18.

[0194] Next, the central ECU 101 generates an analysis report including the entry point of the attack and intrusion route information (intrusion expansion, spread of the attack effect due to the connection of an internal unauthorized device, no change in the attack situation, physical access or false detection) (S1309). An example of the analysis report will be described with reference to FIG. 19.

[0195] FIG. 18 is a diagram showing an example of the relationship between the ECUs that are the targets of a warning and the responses of each ECU according to the depth of a security alert in this modification.

[0196] 18, when the depth (penetration depth) is 1 or 2, the target ECU that receives the warning is the TCU 100, and the TCU 100 takes measures to strengthen the monitoring function. For example, the monitoring function of the network IDS can be strengthened by monitoring payload information in addition to the header information of received packets, instead of only the header information of received packets.

[0197] When the intrusion depth is 3 or 4, the target ECUs that receive a warning are the TCU 100, the Ether switch 102, the ECU 104, the ECU 105, and the central ECU 101, and measures are taken to restrict firmware and application updates in these ECUs to prevent further expansion of the attack. This is an example of disabling some of the functions of the in-vehicle network system 10a.

[0198] When the penetration depth is 5 or 6, the target ECUs that receive the warning are ECU 106, ECU 107, ECU 108, ECU 109, ECU 110, Ether switch 103, and central ECU 101, and the response is to strengthen the monitoring function.

[0199] Furthermore, when the intrusion depth is 7 or 8, the target ECUs that receive the warning are ECU 107 and ECU 111, and the response is to restrict the automatic driving function. When the intrusion depth is 7 or 8, the intrusion depth is already large and there is a high risk of affecting the control of the vehicle, so a response to suppress damage is implemented by restricting the automatic driving function that is likely to be misused for unauthorized control of the vehicle. This is an example of disabling some functions of the in-vehicle network system 10a.

[0200] In this way, the central ECU 101 may disable some functions of the in-vehicle network system 10a when it is determined that the intrusion has expanded and the maximum depth among the depths of the detected security alerts is equal to or greater than a predetermined threshold. Also, the central ECU 101 may strengthen the monitoring function for some devices of the in-vehicle network system 10a when it is determined that the intrusion has expanded and the maximum depth among the depths of the detected security alerts is equal to or greater than a predetermined threshold. Also, the central ECU 101 may output a notification indicating that some functions of the in-vehicle network system 10a will be disabled or that the monitoring function for some devices of the in-vehicle network system 10a will be strengthened.

[0201] FIG. 19 is a diagram showing an example of an analysis report in this modification.

[0202] The analysis report includes, for example, the history information shown in FIG. 9 and the entry point of the attack. FIG. 19 shows an example in which a device corresponding to depth 1 is the entry point. The analysis report may include at least one of the entry point of the attack, the penetration depth of the attack, and the history information. The analysis report may also include information on the determined response (information indicating any one of strengthening the monitoring function, limiting updates, strengthening the monitoring function and limiting the automatic driving function). The analysis report may also include information indicating an estimation result of an ECU in which a security alert may occur next. The information indicating the estimation result may be, for example, information indicating an ECU directly connected to a device in which a security alert has occurred most recently in the history information. The analysis report may also include the depth of the most recent security alert as information indicating how far the attack has progressed, and may also include information indicating which of the seven phases in the cyber kill chain the current situation is. The analysis report including such information is generated by the central ECU 101.

[0203] (11) The analysis report in the above embodiment may be output as threat intelligence. For example, the analysis report may be output in STIX (Structured Threat Information eXpression) format. This makes it possible to use the analysis report as a common format, which is effective in enabling highly compatible information to be exchanged.

[0204] (12) In the above embodiment, the central ECU 101 outputs an analysis report that determines the intrusion path of the attack, but the central ECU 101 may output the result of matching with threat intelligence. For example, the central ECU 101 may hold a threat database and identify the content of the attack when the number of matches of indicators included in the threat intelligence held in the threat database exceeds a predetermined threshold. FIG. 20 shows an example of the threat database held by the central ECU 101 in this modification.

[0205] In FIG. 20, three pieces of threat information are stored, along with their respective threat indicators. The indicators for threat A indicate that the source IP address is aaa.bbb.ccc.ddd, the firmware hash value is 0x56ab78cd90ef, and the CAN IDs are 0x100, 0x110, and 0x200. The indicators for threat B indicate that the source IP address is www.xxx.yyy.zzz, the firmware hash value is 0x1234567890ab, and the CAN IDs are 0x50 and 0x70. The indicators for threat C indicate that the source IP address is iii.jjj.kkk.lll, and the Ethernet frame value is 0xabcdef112233445566778899.

[0206] (13) Each device in the above embodiments is specifically a computer system consisting of a microprocessor, ROM, RAM, a hard disk unit, a display unit, a keyboard, a mouse, etc. A computer program is recorded in the RAM or the hard disk unit. Each device achieves its function by the microprocessor operating in accordance with the computer program. Here, the computer program is composed of a combination of multiple instruction codes that indicate commands for a computer to achieve a specified function.

[0207] (14) In each of the above embodiments, some or all of the constituent elements may be configured from a single system LSI (Large Scale Integration). The system LSI is an ultra-multifunctional LSI manufactured by integrating multiple components on a single chip, and specifically, is a computer system including a microprocessor, ROM, RAM, etc. A computer program is recorded in the RAM. The system LSI achieves its functions by the microprocessor operating in accordance with the computer program.

[0208] Furthermore, each of the components constituting each of the above devices may be individually implemented as a single chip, or some or all of them may be included in a single chip.

[0209] In addition, although we have referred to it as a system LSI here, it may also be called an IC, LSI, super LSI, or ultra LSI depending on the degree of integration. Also, the method of integration is not limited to LSI, but may be realized by a dedicated circuit or a general-purpose processor. It is also possible to use an FPGA (Field Programmable Gate Array) that can be programmed after the LSI is manufactured, or a reconfigurable processor that can reconfigure the connections and settings of the circuit cells inside the LSI.

[0210] Furthermore, if a new integrated circuit technology that can replace LSI appears due to the progress of semiconductor technology or a derivative technology, it is possible to integrate the functional blocks using that technology. The application of biotechnology is also a possibility.

[0211] (15) Some or all of the components constituting 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.

[0212] (16) The present disclosure may be embodied as any of the methods described above. It may also be embodied as a computer program for implementing these methods by a computer, or as a digital signal comprising a computer program.

[0213] The present disclosure may also be a computer program or a digital signal recorded on a computer-readable recording medium, such as a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, a BD (Blu-ray (registered trademark) Disc), a semiconductor memory, etc. The present disclosure may also be the digital signal recorded on such a recording medium.

[0214] The present disclosure may also involve transmitting a computer program or a digital signal via a telecommunications line, a wireless or wired communication line, a network such as the Internet, data broadcasting, or the like.

[0215] The present disclosure may also be directed to a computer system having a microprocessor and a memory, the memory storing the computer program, and the microprocessor operating in accordance with the computer program.

[0216] Furthermore, the program or digital signal may be recorded on a recording medium and transferred, or the program or digital signal may be transferred via a network or the like, so that the program or digital signal may be implemented by another independent computer system.

[0217] (17) In the above embodiment, the control network system is the in-vehicle network system 10a, but the present invention is not limited to this. The control network system that is the target of the intrusion path analysis device to analyze the intrusion path may be a network system built in a home, a network system built in a factory or a company, or a mobile network system mounted on a mobile object such as an aircraft (e.g., an airplane, a drone, etc.) or a train.

[0218] (18) Furthermore, the division of functional blocks in the configuration diagram is one example, and multiple functional blocks may be realized as one functional block, one functional block may be divided into multiple blocks, or some functions may be transferred to other functional blocks. Furthermore, the functions of multiple functional blocks having similar functions may be processed in parallel or in a time-sharing manner by a single piece of hardware or software.

[0219] (19) The order of the processes described in the above embodiment is merely an example. The order of the processes may be changed, the processes may be executed in parallel, or some of the processes may not be executed.

[0220] (20) Furthermore, the security sensor unit 1004 etc. in the above embodiments may be realized by any one of, but not limited to, a network intrusion detection system that detects signs of intrusion from network traffic, a host intrusion detection system that detects signs of intrusion from unauthorized behavior on one or more ECUs 104 etc., a firewall unauthorized packet detection system arranged in the in-vehicle network system 10a, a login failure detection sensor, a signature verification failure detection sensor, a verification failure detection sensor for a message authentication code included in a message on the network, and a security access failure detection sensor.

[0221] (21) The above-described embodiments and modifications may be combined with each other. [Industrial Applicability]

[0222] The present disclosure makes it possible to determine an attacker's intrusion route by analyzing security alerts notified from multiple security sensors placed in an in-vehicle network, and is effective in understanding the status of attack activities against an in-vehicle network system. [Explanation of symbols]

[0223] 1. In-vehicle network monitoring system 10 Vehicles 10a In-vehicle network system (control network system) 11, 12 Ethernet 13, 14 CAN 20 Network 30 Servers 100 TCU 101 Central ECU (intrusion path analysis device) 102, 103 Ether Switch 104, 105, 106, 107, 108, 109, 110, 111 ECU 1001 External communication unit 1002, 1102, 1302, 3002 Application Department 1003 In-vehicle communication unit 1004, 1005, 1104, 1202, 1303 Security sensor unit (security sensor) 1101, 1201, 1301, 3001 Communications Department 1103 Analysis Engine Department 1105 Security alert history storage unit 1106 Vehicle event history storage unit 3003 UI section

Claims

1. An intrusion path analysis device communicably connected to a control network system to which one or more electronic control devices and communication devices are connected, In the control network system, one or more security sensors are arranged on the network, on the one or more electronic control devices, and on at least one of the communication devices, and when a sign of a security intrusion is detected, the security sensors transmit a security alert including the detection of the sign of the security intrusion to the network; The intrusion route analysis device includes: an alert acquisition unit that acquires the security alert from the one or more security sensors; an event acquisition unit that acquires an event history of an event that has occurred in the control network system; an intrusion path analysis unit that performs an analysis of an intrusion path of the attack based on the security alert, the event history, and an intrusion depth that indicates a degree of intrusion of the attack that is assumed when the security alert is generated, and outputs an analysis result; the intrusion path analysis unit, in the analysis, when there are a plurality of the security alerts, determines whether or not the event is due to the attack based on a time change in the intrusion depth of the plurality of the security alerts and the event that occurred during a time period in which the plurality of the security alerts were detected; Intrusion path analysis device.

2. An intrusion path analysis device communicatively connected to a control network system to which one or more electronic control devices and communication devices are connected, In the control network system, one or more security sensors are arranged on the network, on the one or more electronic control devices, and on at least one of the communication devices, and when a sign of a security intrusion is detected, the security sensors transmit a security alert including the detection of the sign of the security intrusion to the network; The intrusion route analysis device includes: an alert acquisition unit that acquires the security alert from the one or more security sensors; an event acquisition unit that acquires an event history of an event that has occurred in the control network system; an intrusion path analysis unit that performs an analysis of an intrusion path of the attack based on the security alert, the event history, and an intrusion depth that indicates a degree of intrusion of the attack that is assumed when the security alert is generated, and outputs an analysis result; the intrusion route analysis unit, in the analysis, determines that the event is caused by an attack when an occurrence distribution of the intrusion depth changes before and after an occurrence time of the event included in the event history; Intrusion path analysis device.

3. The control network system is composed of two or more sub-networks, the communication device is a device that is arranged on at least one of the two or more subnetworks and is used to communicate with a network or device outside the control network system; The penetration depth is determined by the number of physical or logical passes through at least one of the one or more electronic control devices, the two or more sub-networks, and a gateway device connecting the two or more sub-networks to each other, from the communication device to the monitoring target of the security sensor. The intrusion route analysis device according to claim 1 or 2.

4. The intrusion route analysis unit, as part of the analysis, determines that the intrusion situation is an expanding intrusion if the intrusion depth of the security alert increases over time, determines that the intrusion situation is an attack by an unauthorized device if the intrusion depth of the security alert decreases over time, and determines that the intrusion situation is unchanged if the intrusion depth of the security alert does not change over time. The intrusion route analysis device according to any one of claims 1 to 3.

5. An intrusion path analysis device communicatively connected to a control network system to which one or more electronic control devices and communication devices are connected, comprising: In the control network system, one or more security sensors are arranged on the network, on the one or more electronic control devices, and on at least one of the communication devices, and when a sign of a security intrusion is detected, the security sensors transmit a security alert including the detection of the sign of the security intrusion to the network; The intrusion route analysis device includes: an alert acquisition unit that acquires the security alert from the one or more security sensors; an event acquisition unit that acquires an event history of an event that has occurred in the control network system; an intrusion path analysis unit that performs an analysis of an intrusion path of the attack based on the security alert, the event history, and an intrusion depth that indicates a degree of intrusion of the attack that is assumed when the security alert is generated, and outputs an analysis result; The intrusion route analysis unit, as part of the analysis, determines that the intrusion situation is an expanding intrusion if the intrusion depth of the security alert increases over time, determines that the intrusion situation is an attack by an unauthorized device if the intrusion depth of the security alert decreases over time, and determines that the intrusion situation is unchanged if the intrusion depth of the security alert does not change over time. Intrusion path analysis device.

6. The intrusion route analysis unit further performs the analysis by determining, when the intrusion situation is the intrusion expansion, that the entry point of the attack is an area with the smallest intrusion depth, when the intrusion situation is an attack by the unauthorized device, that the entry point of the attack is an area with the largest intrusion depth, and when the intrusion situation is the no-change in the intrusion situation, that the entry point of the attack is an area with the same intrusion depth. The intrusion route analysis device according to claim 4 or 5.

7. the intrusion route analysis unit further determines, as part of the analysis, that the security alert is one and that the intrusion depth of the security alert is higher than a predetermined threshold, that the intrusion is due to physical access or is a false positive; The intrusion route analysis device according to any one of claims 1 to 3 and 5.

8. the intrusion path analysis unit, when the analysis includes the event related to the security alert, further determines that the event is caused by the attack; The intrusion route analysis device according to claim 7 .

9. The intrusion route analysis unit executes at least one of strengthening a monitoring function for at least one of the one or more electronic control devices and the communication device and restricting a function of at least one of the one or more electronic control devices and the communication device according to the intrusion depth of the security alert. The intrusion route analysis device according to any one of claims 1 to 8.

10. the intrusion route analysis unit outputs a notification to disable a part of functions of the control network system when the intrusion situation is determined to be an intrusion expansion and the maximum intrusion depth among the intrusion depths of the detected security alerts is equal to or greater than a predetermined threshold value. The intrusion route analysis device according to claim 9 .

11. the analysis results include at least one of an entry point of the attack, a penetration depth of the attack, and history information including one or more of the security alerts and the event history; The intrusion route analysis device according to any one of claims 1 to 10.

12. The event includes at least one of a login to a device disposed in the control network system, a completion of installation and update of an application or firmware mounted on the device, a completion of firmware transfer, a system diagnosis, and a communication of a fault code. The intrusion route analysis device according to any one of claims 1 to 11.

13. The security sensor includes at least one of a network intrusion detection system that detects signs of intrusion from network traffic, a host intrusion detection system that detects signs of intrusion from unauthorized behavior on the one or more electronic control devices, an unauthorized packet detection system of a firewall disposed in the control network system, a sensor that detects login failure, a sensor that detects signature verification failure, a sensor that detects verification failure of a message authentication code included in a message on a network, and a sensor that detects security access failure. The intrusion route analysis device according to any one of claims 1 to 12.

14. The control network system is an in-vehicle network system. The intrusion route analysis device according to any one of claims 1 to 13.

15. 1. A method for analyzing an intrusion route in a control network system to which one or more electronic control devices and communication devices are connected, comprising: In the control network system, one or more security sensors are arranged on the network, on the one or more electronic control devices, and on at least one of the communication devices, and when a sign of a security intrusion is detected, the security sensors transmit a security alert including the detection of the sign of the security intrusion to the network; The method for analyzing an intrusion route includes: obtaining the security alert from the one or more security sensors; acquiring an event history of an event that has occurred in the control network system; an intrusion path analysis step of analyzing an intrusion path of the attack based on the security alert, the event history, and an intrusion depth indicating a degree of intrusion of the attack expected when the security alert is generated, and outputting an analysis result; In the intrusion path analysis step, when there are a plurality of security alerts, the analysis includes determining whether or not the event is caused by the attack based on a time change in the intrusion depth of the plurality of security alerts and the event that occurred during a time period in which the plurality of security alerts were detected. Intrusion route analysis method.

16. A method for analyzing an intrusion path in a control network system to which one or more electronic control devices and communication devices are connected, comprising: In the control network system, one or more security sensors are arranged on the network, on the one or more electronic control devices, and on at least one of the communication devices, and when a sign of a security intrusion is detected, the security sensors transmit a security alert including the detection of the sign of the security intrusion to the network; The method for analyzing an intrusion route includes: obtaining the security alert from the one or more security sensors; acquiring an event history of an event that has occurred in the control network system; an intrusion path analysis step of analyzing an intrusion path of the attack based on the security alert, the event history, and an intrusion depth indicating a degree of intrusion of the attack expected when the security alert is generated, and outputting an analysis result; the intrusion route analysis step includes, as the analysis, determining that an event included in the event history is caused by an attack when an occurrence distribution of the intrusion depth changes before and after the occurrence time of the event; Intrusion route analysis method.

17. A method for analyzing an intrusion path in a control network system to which one or more electronic control devices and communication devices are connected, comprising: In the control network system, one or more security sensors are arranged on the network, on the one or more electronic control devices, and on at least one of the communication devices, and when a sign of a security intrusion is detected, the security sensors transmit a security alert including the detection of the sign of the security intrusion to the network; The method for analyzing an intrusion route includes: obtaining the security alert from the one or more security sensors; acquiring an event history of an event that has occurred in the control network system; an intrusion path analysis step of analyzing an intrusion path of the attack based on the security alert, the event history, and an intrusion depth indicating a degree of intrusion of the attack expected when the security alert is generated, and outputting an analysis result; The intrusion path analysis step includes, as the analysis, judging that the intrusion situation is an expanding intrusion if the intrusion depth of the security alert increases over time, judging that the intrusion situation is an attack by an unauthorized device if the intrusion depth of the security alert decreases over time, and judging that the intrusion situation is unchanged if the intrusion depth of the security alert does not change over time. Intrusion route analysis method.

Images