Attack Route Generation Method and Attack Route Generation Device

Abstract

To specify an aggression path even if a plurality of devices receives an aggression at the same time.SOLUTION: An aggression path generating method according to a present disclosure, is an aggression path generating method that is connected to a network containing at least any one of a branching and a jointing, and is executed by obtaining a log in a plurality of devices having an aggression detection function. The aggression path generating method contains steps of: generating a primary aggression path without having the branching and jointing on the basis of the acquired log; being branched from the primary aggression path on the basis of the log; or generating a secondary aggression path jointed to the primary aggression path; outputting the primary aggression path and the secondary aggression path generated to a device for performing an aggression determination. The secondary aggression path is an aggression path that is a device contained in the primary aggression path, and contains a device on an upstream side or a downstream side where there is an event assumed as an aggression within a constant time from an event assumed as an aggression to the device connected to a jointing point or a branching point of the network.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure relates to a method for generating an attack path and an attack path generation device.

Background Art

[0002] As a countermeasure against cyberattacks, a technique has been disclosed in which an attack pattern that is expected to occur in the future is defined in advance as an attack scenario, and an attack scenario that matches the log is specified as one.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, when there are a plurality of attack paths simultaneously present in the system, it is difficult to cope with the above-described technique of specifying one attack scenario.

[0005] An object of the present disclosure is to provide an attack path generation method and an attack path generation device capable of specifying an attack path even when a plurality of devices are attacked simultaneously.

Means for Solving the Problems

[0006] The attack path generation method according to the present disclosure is an attack path generation method executed by an information processing device that generates an attack path in a plurality of devices each having an attack detection function, by acquiring logs in the plurality of devices connected to a network including at least one of branching and merging. The method includes generating a primary attack path without branching and merging based on the acquired logs, generating a secondary attack path that branches from or merges into the primary attack path based on the logs, and outputting the generated primary attack path and the secondary attack path to a device that performs an attack determination. The secondary attack path is an attack path including devices on the upstream or downstream side where events assumed to be attacks have occurred within a certain time from an event assumed to be an attack on a device included in the primary attack path and connected to a merging point or a branching point of the network.

Advantages of the Invention

[0007] According to the attack path generation method and the attack path generation device according to the present disclosure, even when a plurality of devices are attacked simultaneously, the attack path can be specified.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Mode for Carrying Out the Invention

[0009] Hereinafter, embodiments of an attack path generation method and an attack path generation device according to the present disclosure will be described with reference to the drawings.

[0010] (Configuration Example of Attack Analysis System) FIG. 1 is a diagram showing an example of the configuration of an attack analysis system according to the embodiment. The attack analysis system of the embodiment includes an integrated log monitoring device (hereinafter, IDM (Integrated Detection log Manager) device) 10 mounted on the vehicle VH, and supports analysis and countermeasures for cyber attacks on the in-vehicle device group 100 monitored by the IDM device 10.

[0011] The in-vehicle device group 100 includes various in-vehicle devices such as, for example, CAN (Controller Area Network), in-vehicle Ethernet, in-vehicle electronic control units (ECUs: Electronic Control Unit), gateways, telematics control units (TCUs: Telematics Control Unit), advanced driver-assistance systems (ADADS: Advanced Driver-Assistance Systems), and on-board diagnostics (OBD: On-Board Diagnostics).

[0012] Each in-vehicle device included in the in-vehicle device group 100 is network-connected to each other. The network to which the in-vehicle devices are interconnected may include at least either branching or merging. Further, these in-vehicle devices are equipped with an attack detection function by being equipped with the intrusion detection system (IDS: Intrusion Detection System) sensors described below.

[0013] The IDS sensors mounted on the in-vehicle devices are network-based IDS (NIDS: Network-based IDS), host-based IDS (HIDS: Host-based IDS), firewalls, etc., and constitute the IDS sensor group 100a.

[0014] The IDM device 10 as an attack path generation device is mounted on the vehicle VH and acquires a log including the detection results of various events in the in-vehicle device group 100 from the IDS sensor group 100a. The various events recorded in the log include events assumed to be attacks on a predetermined in-vehicle device. The IDM device 10 monitors the in-vehicle device group 100 based on these logs.

[0015] Further, the IDM device 10 transmits the monitoring result of the in-vehicle device group 100 including the log from the IDS sensor group 100a to the data center 20 via an external network NTe by wireless such as the Internet.

[0016] The data center 20 is connected to the IDM device 10 via the external network NTe, and includes a Security Information and Event Management (SIEM) device 21 and a database 22. In the database 22, the monitoring results of the in-vehicle device group 100 and the logs of the IDS sensor group 100a from the IDM device 10 are accumulated. The SIEM device 21 centrally manages these pieces of information stored in the database 22 and identifies security incidents through correlation analysis and the like.

[0017] The monitoring center 30 is a specialized organization belonging to a Security Operation Center (SOC) that specializes in monitoring cyberattacks on the in-vehicle device group 100 and taking countermeasures. When the SIEM device 21 in the data center 20 detects an abnormality, it is notified to the operator 31 in the monitoring center 30. The manager 32 who has received a report from the operator 31 raises alert information to the analysis center 40.

[0018] The analysis center 40 is a specialized organization belonging to an SOC that specializes in analyzing cyberattacks on the in-vehicle device group 100 and taking countermeasures. When the analyst 41 in the analysis center 40 receives alert information from the monitoring center 30, the analyst 41 analyzes the abnormality detected by the SIEM device 21. The manager 42 in the analysis center 40 raises the alert information analyzed by the analyst 41 to the Security Incident Response Team (SIRT) 50.

[0019] The SIRT 50 is a specialized team established to respond to security incidents occurring in computers and networks. The alert information analyzed by the analysis center 40 is shared with the SIRT 50, and a more thorough response is further promoted.

[0020] As described above, the in-vehicle device group 100 is supported for monitoring, analyzing, and taking countermeasures against cyberattacks and the like by a hierarchical system including the IDM device 10. In such a hierarchical attack analysis system, it is important what form of data is transmitted from the IDM device 10 mounted on the vehicle VH to the data center 20.

[0021] By the way, on one network, in order to reach the final attack target, a cyberattack may be launched that scouts multiple attack targets simultaneously while tracing the network. In such a case, multiple attack paths may occur simultaneously on one network.

[0022] As will be described below, based on the logs collected from the IDS sensor group 100a, the IDM device 10 generates attack paths to a plurality of in-vehicle devices included in the in-vehicle device group 100, and uploads data including the generation results of the attack paths to the database 22 of the data center 20.

[0023] (Configuration example of IDM device) Next, with reference to FIGS. 2 and 3, examples of the hardware configuration and functional configuration of the IDM device 10 will be described.

[0024] FIG. 2 is a block diagram showing an example of the hardware configuration of the IDM device 10 according to the embodiment. As shown in FIG. 2, the IDM device 10 is configured as an information processing device such as a computer including, for example, a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, and a RAM (Random Access Memory) 13.

[0025] More specifically, the IDM device 10 includes a CPU 11, a ROM 12, a RAM 13, a communication interface (I / F) 14, an input / output I / F 15, and a storage device 16. These CPU 11, ROM 12, RAM 13, communication I / F 14, input / output I / F 15, and storage device 16 are connected to each other by an internal bus. Also, an IDS sensor group 100a is connected to the input / output I / F 15 via a network such as an in-vehicle CAN.

[0026] The CPU 11 controls the entire IDM device 10. The ROM 12 functions as a storage area in the IDM device 10. The information stored in the ROM 12 is retained even when the power of the IDM device 10 is turned off. The RAM 13 functions as a primary storage device and serves as the working area of the CPU 11.

[0027] The functions of the IDM device 10 are realized by the CPU 11 expanding and executing the attack path generation program stored in the ROM 12 etc. in the RAM 13.

[0028] The communication I / F 14 is configured to be connectable to an external wireless network NTe such as the Internet. By means of the communication I / F 14, various information from the IDM device 10 can be uploaded to the database 22 of the above-described data center 20.

[0029] The input / output I / F 15 is connected to external devices such as the IDS sensor group 100a via a network such as an in-vehicle CAN. By means of the input / output I / F 15, various information including logs is collected from external devices such as the IDS sensor group 100a.

[0030] The storage device 16 is an HDD (Hard Disk Drive), an SDD (Solid State Drive), etc., and functions as an auxiliary storage device of the CPU 11.

[0031] As described above, the IDS sensor group 100a includes a plurality of IDS sensors such as NIDS, HIDS, and a firewall. These plurality of IDS sensors are respectively mounted on corresponding in-vehicle devices among the in-vehicle device group 100, and monitor these in-vehicle devices to generate logs.

[0032] FIG. 3 is a block diagram showing an example of the functional configuration of the IDM device 10 and the SIEM device 21 according to the embodiment.

[0033] As shown in FIG. 3, the IDM device 10 includes, for example, an acquisition unit 101, an aggregation unit 102, a primary generation unit 103, a secondary generation unit 104, an estimation unit 105, an output unit 106, and a storage unit 107.

[0034] The acquisition unit 101 receives various information including logs from external devices such as the IDS sensor group 100a via a network NTc such as an in-vehicle CAN. The acquisition unit 101 is realized by, for example, an input / output I / F 15 that operates under the control of a CPU 11 during execution of an attack path generation program.

[0035] The aggregation unit 102 aggregates the logs collected from the IDS sensor group 100a. Further, the aggregation unit 102 performs fitting to apply the aggregated logs to the in-vehicle device group 100 on the network with reference to the network configuration database 107a stored in the storage unit 107. The aggregation unit 102 is realized by, for example, a CPU 11 during execution of an attack path generation program.

[0036] The primary generation unit 103 generates a primary attack path without confluence and bifurcation from the logs subjected to the fitting process. The primary generation unit 103 is realized by, for example, a CPU 11 during execution of an attack path generation program.

[0037] The secondary generation unit 104 generates a secondary attack path that branches from or merges into the primary attack path generated by the primary generation unit 103. The secondary generation unit 104 is realized by, for example, a CPU 11 during execution of an attack path generation program.

[0038] The estimation unit 105 refers to the known attack database 107b stored in the storage unit 107, and estimates an attack scenario in an event assumed to be an attack on the in-vehicle device group 100 extracted by the aggregation unit 102 from attack patterns that match or are similar to the attack paths generated by the primary generation unit 103 and the secondary generation unit 104. The estimation unit 105 is realized, for example, by the CPU 11 during execution of the attack path generation program.

[0039] The output unit 106 outputs information such as the attack paths generated by the primary generation unit 103 and the secondary generation unit 104, and the attack scenario estimated by the estimation unit 105 to the database 22 of the data center 20 via an external network NTe such as the Internet. The output unit 106 is realized, for example, by the communication I / F 14 operating under the control of the CPU 11 during execution of the attack path generation program.

[0040] The storage unit 107 stores various parameters necessary for the processing performed by the IDM device 10, and the attack path generation program and the like executed by the IDM device 10. The storage unit 107 also stores a network configuration database 107a and a known attack database 107b. The storage unit 107 is realized, for example, by the ROM 12, the RAM 13, and the storage device 16 that operate under the control of the CPU 11 during execution of the information providing program.

[0041] The network configuration database 107a holds information on the network configuration of the interconnected in-vehicle device group 100. The known attack database 107b holds information on known attack patterns whose future occurrence is expected.

[0042] The SIEM device 21 includes, for example, an attack determination unit 201 and an attack countermeasure unit 202. The attack determination unit 201 performs an attack determination on an event assumed to be an attack on the in-vehicle device group 100 detected by the IDS sensor group 100a based on the primary or secondary attack path received from the IDM device 10 and the estimated attack scenario. When the attack determination unit 201 makes an attack determination, the attack countermeasure unit 202 formulates countermeasures against the attack on the in-vehicle device group 100.

[0043] (Example of log aggregation) Next, with reference to FIGS. 4 to 6, the aggregation performed by the aggregation unit 102 of the IDM device 10 on the logs will be described. FIG. 4 is a diagram showing an example of a log LG acquired by the IDM device 10 according to the embodiment from the IDS sensor group 100a.

[0044] As shown in FIG. 4, the logs acquired by the IDM device 10 from the IDS sensor group 100a include information such as the date and time when an abnormality occurred in the in-vehicle device group 100, the in-vehicle device type, the IDS sensor type, and the abnormality type for each data A, B, C, ···. Here, the abnormality type is an event assumed to be an attack on the in-vehicle device group 100.

[0045] More specifically, data A indicates that an authentication error was detected in the firewall installed in the TCU at a predetermined date and time. Data E indicates that a reprogramming error was detected in the HIDS installed in the gateway at a predetermined date and time. Data H indicates that an address error was detected in the NIDS installed in the in-vehicle Ethernet at a predetermined date and time. Data L indicates that a message authentication code (MAC) error was detected in the firewall installed in the ADAS.

[0046] The aggregation unit 102 of the IDM device 10 groups these logs by in-vehicle device type, IDS sensor type, and abnormality type and arranges them in chronological order. FIG. 5 shows an example of the data after grouping by the aggregation unit 102.

[0047] FIG. 5 is a diagram showing an example of data LGg after subjecting the log LG acquired by the IDM device 10 according to the embodiment to a grouping process from the IDS sensor group 100a.

[0048] As shown in FIG. 5, in the data LGg after the processing by the aggregating unit 102, the logs LG for each data A, B, C... are grouped separately for each step 1, 2, 3... according to the in-vehicle device type, the IDS sensor type, and the abnormality type. In the attack path generation process described later, each of these steps 1, 2, 3... is treated as one attack step in the assumed attack.

[0049] The aggregating unit 102 fits the grouped data LGg to the network configuration of the in-vehicle device group 100. That is, the aggregating unit 102 refers to the network configuration database 107a stored in the storage unit 107 and applies the data LGg to the network configuration provided by the in-vehicle device group 100. The data after the fitting process is shown in FIG. 6.

[0050] FIG. 6 is a diagram showing an example of data obtained by subjecting the log LG acquired by the IDM device 10 according to the embodiment to a fitting process. In the drawings from FIG. 6 to FIG. 11, for convenience of explanation, the in-vehicle devices are shown as in-vehicle devices 110, 111, 112... without specifying each in-vehicle device. In the example of FIG. 6, the in-vehicle device group 100 mounted on the vehicle VH includes in-vehicle devices 110 to 119.

[0051] As shown in FIG. 6, in the data after the fitting process, in-vehicle devices 110 to 119 that are network-connected to each other are shown based on the known network configuration. Among these in-vehicle devices 110 to 119, the in-vehicle device 110 side is the upstream side of the network, and the in-vehicle device 117 side is the downstream side.

[0052] In the example of FIG. 6, it is also assumed that the network configurations of in-vehicle devices 110 to 119 include branches and merges.

[0053] That is, for example, the in-vehicle device 114 is connected to a merge point of the network, and a plurality of upstream in-vehicle devices 111 and 112 are connected to the in-vehicle device 114. Also, for example, the in-vehicle device 116 is connected to a branch point of the network, and a plurality of downstream in-vehicle devices 118 and 119 that are the destinations of the network branch are connected to the in-vehicle device 116.

[0054] The aggregation unit 102 regards the events EV that occurred within a certain time among the plurality of events EV that occurred in the plurality of in-vehicle devices 110 to 119 as continuously occurring events EV, and generates the data shown in FIG. 6. This is because if an event EV that occurred in any of the in-vehicle devices 110 to 119 is significantly deviated from the timing when other events EV occurred, it is unlikely to be considered as part of a series of attacks by the same attacker.

[0055] In the example of FIG. 6, among these in-vehicle devices 110 to 119, it is assumed that events EV that are assumed to be a series of attacks by the same attacker have occurred in the in-vehicle devices 111 to 116, 118, and 119.

[0056] Note that in the above network configuration, the in-vehicle devices 110 to 112 at the most upstream of the network serve as the entrance, that is, the entry point, when accessing the network. That is, the in-vehicle devices 110 to 112 can be the first targets of cyberattacks.

[0057] (Example of primary generation of attack path) Next, with reference to FIG. 7, the generation of a primary attack path performed by the primary generation unit 103 of the IDM device 10 on the data after the fitting process of FIG. 6 will be described.

[0058] As described above, the primary generation unit 103 generates a primary attack path based on the data after the fitting process of FIG. 6. The primary attack path is a linear attack path without branches and merges.

[0059] At this time, the primary generation unit 103 selects an attack path including in-vehicle devices among the in-vehicle devices 111 to 116, 118, and 119 in which the event EV has occurred, and which are connected to a point where there is no branching or merging on the network, or a point where there is as little branching and merging as possible. FIG. 7 shows an example of a primary attack path generated by the primary generation unit 103.

[0060] FIG. 7 is a diagram showing an example of a primary attack path generated by the IDM device 10 according to the embodiment. The primary generation unit 103 generates as many primary attack paths as possible based on the data in FIG. 6 described above. In the example of FIG. 7, the primary generation unit 103 has generated two attack paths.

[0061] One of these attack paths starts from the in-vehicle device 111, passes through the in-vehicle devices 113 and 115, and reaches the in-vehicle device 118.

[0062] Here, the in-vehicle device 111 is connected to a branch point of the network, and the event EV has occurred in both of the downstream in-vehicle devices 113 and 114 connected to the in-vehicle device 111. Therefore, it is possible that the event EV that occurred in the in-vehicle device 111 reached both the in-vehicle device 113 and the in-vehicle device 114 along the network.

[0063] However, among the in-vehicle devices 111 and 112 where the event EV is considered to have occurred first, the in-vehicle device 113 is connected only to one of the in-vehicle devices 111. On the other hand, among the in-vehicle devices 111 and 112 where the event EV occurred first, the in-vehicle device 114 is connected to both of the in-vehicle devices 111 and 112. Therefore, it can be said that among the in-vehicle devices 113 and 114, the in-vehicle device 113 is connected to a point where there is less branching and merging than the in-vehicle device 114.

[0064] In this case, the primary generation unit 103 generates, as a primary attack path, a path leading to the in-vehicle device 113 connected to a point where there is less branching and merging.

[0065] Of the two attack paths, the other attack path reaches in-vehicle device 119 from in-vehicle device 112 via in-vehicle devices 114 and 116.

[0066] Here, in-vehicle device 116 is connected to a network branch point, and event EV has occurred in both of the downstream in-vehicle devices 118 and 119 connected to in-vehicle device 116. Therefore, it is possible that event EV that occurred in in-vehicle device 116 reached in-vehicle device 118 and also possible that it reached in-vehicle device 119 by traversing the network.

[0067] However, among in-vehicle devices 115 and 116 where event EV occurred upstream of these in-vehicle devices 118 and 119, in-vehicle device 119 is connected only to one of the in-vehicle devices 116. On the other hand, among the upstream in-vehicle devices 115 and 116, in-vehicle device 118 is connected to both in-vehicle devices 115 and 116. Therefore, it can be said that among in-vehicle devices 118 and 119, in-vehicle device 119 is connected to a point with fewer branch and merge points compared to in-vehicle device 118.

[0068] In this case, the primary generation unit 103 generates, as a primary attack path, a path leading to in-vehicle device 119 connected to a point with fewer branch and merge points.

[0069] (Example of secondary generation of attack path) Next, with reference to FIGS. 8 to 11, generation of a secondary attack path performed by the secondary generation unit 104 of the IDM device 10 will be described.

[0070] The secondary generation unit 104 generates a secondary attack path for the data after the primary attack path generation in FIG. 7. The secondary attack path is an attack path that branches from the primary attack path generated by the primary generation unit 103 or an attack path that merges into the primary attack path.

[0071] At this time, the secondary generation unit 104 preferentially proceeds with processing from in-vehicle devices among the in-vehicle devices 111 to 116, 118, and 119 in which the event EV has occurred and that are not included in the primary attack path generated by the primary generation unit 103.

[0072] Also at this time, the secondary generation unit 104 also selects an attack path including an in-vehicle device connected to a point where there is no branching or merging on the network, or a point where there is as little branching and merging as possible.

[0073] FIG. 8 is a diagram showing candidates in the case of generating a secondary attack path of the IDM device 10 according to the embodiment. In the example of FIG. 8, when generating a secondary attack path, two candidates can be considered.

[0074] One of the two candidates is the possibility of the attack path from the in-vehicle device 111 merging into the primary attack path from the in-vehicle device 112 via the in-vehicle device 114.

[0075] The other of the two candidates is the possibility of an attack path branching to the in-vehicle device 118 from the primary attack path leading from the in-vehicle device 116 to the in-vehicle device 119.

[0076] As described above, when generating the primary attack path by the above-described primary generation unit 103, a point where the attack path that can be traced is not determined to be one, that is, the in-vehicle device 114 where there are enough merging points of the attack path, and the in-vehicle device 116 where there are enough branching points of the attack path, etc. can be candidates when generating the secondary attack path. In generating the secondary attack path, such a point where the attack path is not determined to be one is focused on and considered.

[0077] Specifically, the secondary generation unit 104 examines the possibility of these mergings and branchings based on the occurrence timing of the event EV between the in-vehicle devices 111 and 114 and the occurrence timing of the event EV between the in-vehicle devices 116 and 118.

[0078] FIG. 9 is a diagram showing the occurrence timing of an event EV between in-vehicle devices 111 and 114 considered in the IDM device 10 according to the embodiment. Note that FIG. 9 also shows the occurrence timing of the event EV in the in-vehicle device 112 for reference.

[0079] As shown in FIG. 9, the events EV in the in-vehicle devices 111, 112, and 114 occur in this order. Whether there is a confluence of the attack paths from the in-vehicle device 111 to the in-vehicle device 114 is determined based on whether the event EV has occurred in the in-vehicle device 114 within a certain period of time PRa as the second period after the event EV has occurred in the in-vehicle device 111.

[0080] In the example of FIG. 9, the event EV has not occurred in the in-vehicle device 114 within the certain period of time PRa from the occurrence of the event EV in the in-vehicle device 111. Therefore, the secondary generation unit 104 determines that there is no confluence of the attack paths from the in-vehicle device 111 to the in-vehicle device 114.

[0081] Note that in the example of FIG. 9, the event EV has occurred in the in-vehicle device 114 within a certain period of time PRb from the occurrence of the event EV in the in-vehicle device 112. From this point as well, it is presumed that there is an attack path from the in-vehicle device 112 to the in-vehicle device 114 as generated by the primary generation unit 103.

[0082] FIG. 10 is a diagram showing the occurrence timing of an event EV between in-vehicle devices 116 and 118 considered in the IDM device 10 according to the embodiment. Note that FIG. 10 also shows the occurrence timing of the event EV in the in-vehicle device 119 for reference.

[0083] As shown in FIG. 10, the events EV in the in-vehicle devices 116, 118, and 119 occur in this order. Whether there is a branch of the attack path from the in-vehicle device 116 to the in-vehicle device 118 is determined based on whether the event EV has occurred in the in-vehicle device 118 within a certain period of time PRc as the first period after the event EV has occurred in the in-vehicle device 116.

[0084] In the example of FIG. 10, an event EV has occurred in in-vehicle device 118 within a certain time PRc from the occurrence of the event EV in in-vehicle device 116. Therefore, the secondary generation unit 104 determines that there is a branch in the attack path from in-vehicle device 116 to in-vehicle device 118.

[0085] Note that in the example of FIG. 10, an event EV has also occurred in in-vehicle device 119 within a certain time PRc from the occurrence of the event EV in in-vehicle device 116. From this point as well, it is presumed that there is an attack path from in-vehicle device 116 to in-vehicle device 119 as generated by the primary generation unit 103.

[0086] Based on the above determination results, when there are branches or merges in the primary attack paths generated by the primary generation unit 103, the secondary generation unit 104 assigns those attack paths. FIG. 11 shows an example of data to which secondary attack paths are assigned by the secondary generation unit 104.

[0087] FIG. 11 is a diagram showing an example of the attack paths generated by the IDM device 10 according to the embodiment. In the example of FIG. 11, secondary attack paths generated by the secondary generation unit 104 are assigned to the primary attack paths generated by the primary generation unit 103.

[0088] In the example of FIG. 9 described above, it is determined that there is no merge in the attack path from in-vehicle device 111 to in-vehicle device 114. Therefore, no secondary attack path from in-vehicle device 111 to in-vehicle device 114 is assigned.

[0089] In the example of FIG. 10 described above, it is determined that there is a branch in the attack path leading from in-vehicle device 116 to in-vehicle device 118. Therefore, a secondary attack path branching from in-vehicle device 116 to in-vehicle device 118 is assigned to the primary attack path from in-vehicle device 112 via in-vehicle devices 114 and 116 to in-vehicle device 119 described above.

[0090] As described above, the attack paths are generated by the primary generation unit 103 and the secondary generation unit 104. The attack paths after the processing by the primary generation unit 103 and the secondary generation unit 104 can be secondary attack paths including at least one of branching and merging, for example, as in the example of FIG. 11 described above. Alternatively, the attack paths after the processing by the primary generation unit 103 and the secondary generation unit 104 can be primary attack paths that do not include either branching or merging.

[0091] Note that the attack path generation process by the primary generation unit 103 and the secondary generation unit 104 is performed when an event EV occurs in an in-vehicle device inside the network from the network entry point.

[0092] That is, the attack path generation process is not performed only when the event EV occurs in one or more in-vehicle devices 110 to 112 which are the entry points. In addition to one or more in-vehicle devices 110 to 112, the attack path generation process is performed when the event EV occurs in at least one or more in-vehicle devices 113, 114 inside the network from them.

[0093] This is because when the event EV occurs only at the entry point, there is no need to assume an attack path in the first place, and it does not match the processing load of the IDM device 10. Also, in a cyber attack, many attack attempts are mainly made, and it is difficult to assume an attack only on the entry point.

[0094] Also, the attack path generation process by the primary generation unit 103 and the secondary generation unit 104 depends on the acquisition timing of the logs from the IDS sensor group 100a. For this reason, the attack path generation process can be either during a series of events EV occurring in real time or after a series of events EV have ended.

[0095] Also, when the attack path generation process is performed in real time, if an event EV occurs in a downstream in-vehicle device connected to the generated attack path, the generated attack path is treated as an extended one.

[0096] In addition, even if the attack route generation process is performed after the occurrence of a series of events EV, if there remains an in-vehicle device that has detected the occurrence of the event EV but does not belong to any of the generated attack routes among the in-vehicle devices in which the occurrence of the event EV has been detected, it is treated as including a false detection regarding that in-vehicle device.

[0097] (Estimation example of attack scenario) Next, with reference to FIG. 12, the estimation of the attack scenario performed by the estimation unit 105 of the IDM device 10 will be described. FIG. 12 is a diagram showing an example of a known attack database 107b used by the IDM device 10 according to the embodiment for estimating an attack scenario.

[0098] As shown in FIG. 12, the known attack database 107b holds information on a plurality of attack scenarios representing known attack patterns. The attack pattern defines, in the in-vehicle device group 100, the order in which an attack is launched and events EV that can occur in the in-vehicle device targeted by the attack. As described above, the known attack database 107b is stored, for example, in the storage unit 107 of the IDM device 10.

[0099] The estimation unit 105 reads the known attack database 107b from the storage unit 107. Further, the estimation unit 105 extracts an attack pattern similar to the attack route generated by the primary generation unit 103 and the secondary generation unit 104 from among the plurality of attack patterns held by the read known attack database 107b. Further, the estimation unit 105 estimates the attack scenario of the event EV included in the log acquired from the IDS sensor group 100a based on the extracted attack pattern.

[0100] In the example of FIG. 12, the estimation unit 105 estimates that the attack scenario with scenario ID3 is the attack scenario in the above-described series of events EV from among the plurality of attack scenarios.

[0101] (Method for generating attack route of IDM device) Next, an example of the attack path generation method by the IDM device 10 of the embodiment will be described with reference to FIGS. 13 and 14. FIG. 13 is a flowchart showing an example of the procedure of the attack path generation process by the IDM device 10 according to the embodiment.

[0102] As shown in FIG. 13, the primary generation unit 103 of the IDM device 10 generates a primary attack path, which is an attack path that is the path through which an event EV assumed to be an attack has invaded the network based on the logs acquired from the IDS sensor group 100a (step S101).

[0103] More specifically, the data used by the primary generation unit 103 is the data after the aggregation unit 102 has aggregated and performed fitting processing.

[0104] After generating one primary attack path, the primary generation unit 103 determines whether the generation of the attack path is completed with just that one primary attack path, i.e., whether there are no other attack paths other than that one primary attack path (step S102). The completion of the generation of the attack path means that all in-vehicle devices where an event EV assumed to be an attack has occurred are included in the generated attack path and there are no remaining in-vehicle devices. If it is completed with just one primary attack path (step S102: Yes), the IDM device 10 ends the process.

[0105] If the generation of the attack path is not completed with just one primary attack path (step S102: No), the primary generation unit 103 determines whether it is possible to generate another primary attack path (step S103). If another primary path cannot be generated (step S103: No), the process proceeds to the process of step S106.

[0106] If it is possible to generate another primary path (step S103: Yes), the primary generation unit 103 further generates a primary attack path (step S104). Also, the primary generation unit 103 determines whether it is possible to complete the generation of the attack path with these multiple primary attack paths (step S105). If the generation is completed with these primary attack paths (step S105: Yes), the IDM device 10 ends the process.

[0107] If the generation is not completed with the multiple primary attack paths (step S105: No), the secondary generation unit 104 determines whether there is a branch or a merge at the connection point on the network of at least any one of the in-vehicle devices included in these primary attack paths (step S106).

[0108] If there is no branch or merge at the connection point of any in-vehicle device (step S106: No), the IDM device 10 ends the process. In this case, the generation of the attack path ends with in-vehicle devices remaining that are not included in the generated attack path. The remaining in-vehicle devices are treated as including false detections.

[0109] If there is a branch or a merge at the connection point of any in-vehicle device (step S106: Yes), the secondary generation unit 104 generates a secondary attack path including at least one of a branch and a merge according to the known network configuration of the in-vehicle device group 100 (step S107).

[0110] As described above, the attack path generation process by the IDM device 10 of the embodiment ends.

[0111] FIG. 14 is a flowchart showing an example of the procedure of the secondary attack path generation process by the IDM device 10 according to the embodiment. The process shown in FIG. 14 is the detail of the process of step S107 in FIG. 13 described above.

[0112] As shown in FIG. 14, the secondary generation unit 104 selects, from among the primary attack paths generated by the processing of the above-described primary generation unit 103, paths in which secondary paths have not been generated, and which have no branches or merges, or few branches or merges (step S111).

[0113] The secondary generation unit 104 determines whether there is a branch or merge on the selected path where a secondary attack path can be generated (step S112). If there is no branch or merge (step S112: No), the secondary generation unit 104 skips the processing of steps S113 to S117 and proceeds to the processing of step S118.

[0114] If there is a branch on the selected path where a secondary attack path can be generated (step S112: Yes (branch)), it is determined whether an event EV assumed to be an attack between in-vehicle devices connected to the branch point and its downstream side has occurred within a certain period of time (step S113).

[0115] If the event EV has occurred within a certain period of time (step S113: Yes), the secondary generation unit 104 sets a branch path between those in-vehicle devices (step S114). If the event EV has not occurred within a certain period of time (step S113: No), the secondary generation unit 104 skips the processing of steps S114 and S117 and proceeds to the processing of step S118.

[0116] If there is a merge on the selected path where a secondary attack path can be generated (step S112: Yes (merge)), it is determined whether an event EV assumed to be an attack between in-vehicle devices connected to the merge point and its upstream side has occurred within a certain period of time (step S115).

[0117] When an event EV has occurred within a certain period of time (step S115: Yes), the secondary generation unit 104 sets a merging route between those in-vehicle devices (step S116). When the event EV has not occurred within a certain period of time (step S115: No), the secondary generation unit 104 skips the processes of steps S116 and S117 and proceeds to the process of step S118.

[0118] When there is a branching route set between a branch point and the in-vehicle devices connected to the downstream side thereof, the secondary generation unit 104 generates a secondary attack route including that branch, and when there is a merging route set between a merging point and the in-vehicle devices connected to the upstream side thereof, the secondary generation unit 104 generates a secondary attack route including that merging (step S117).

[0119] Also, the secondary generation unit 104 determines whether or not the generation of the attack route has been completed by the processes up to steps S111 to S117 (step S118). When it has not been completed with the attack route generated so far (step S118: No), the secondary generation unit 104 determines whether or not another attack route can be generated (step S119).

[0120] When another primary route cannot be generated (step S119: No), the IDM device 10 ends the process. In this case, the generation of the attack route ends with in-vehicle devices remaining that are not included in the generated attack route. The remaining in-vehicle devices are treated as including false detections.

[0121] If another primary route can be generated (step S119: Yes), the processes from steps S111 to S119 within loop L1(S) to L1(E) are repeated until the generation of the attack route is completed. When the generation of the attack route is completed (step S118: Yes), the process of loop L1(S) to L1(E) ends.

[0122] Thus, the process of generating the secondary attack route by the IDM device 10 of the embodiment ends.

[0123] After that, the output unit 106 outputs the generation result of the attack path generated by the primary generation unit 103 and the secondary generation unit 104, together with the estimation result of the attack scenario by the estimation unit 105, to the SIEM device 21.

[0124] Based on the generation result of the attack path and the estimation result of the attack scenario, the attack determination unit 201 and the attack countermeasure unit 202 of the SIEM device 21 perform an attack determination and a countermeasure formulation for the event EV detected by the IDS sensor group 100a. Examples of countermeasures for the event EV include, for example, cutting off communication or a network in a specific in-vehicle device, software update, stopping the system including the in-vehicle device group 100, etc.

[0125] (Comparative Example) Due to the sophistication of cyberattacks, it is becoming difficult to completely defend against cyberattacks, and countermeasures after the occurrence of cyberattacks are becoming important. Also, in a control system such as an in-vehicle device group, security measures may not be perfect, and there is a possibility that malfunctions or destruction of devices may occur within a very short time from the occurrence of an attack.

[0126] For example, in the above-mentioned Patent Document 1, when a plurality of attack scenarios match the logs, a table associating the attack path and the number of countermeasures is referred to, and even when a plurality of estimated attacks are found, one attack path is specified based on the priority according to the number of countermeasures. A technique is disclosed.

[0127] However, in the case where a plurality of nodes are attacked simultaneously and a plurality of attack paths are generated, such as in the reconnaissance action in a cyberattack, it is difficult to take sufficient countermeasures with the above technique assuming one attack path for one attack.

[0128] On the other hand, even when a plurality of attack paths are generated, if they are primary attack paths that have no branches or merges, it seems that the above technique can be repeatedly implemented to identify a plurality of attack paths. However, when a plurality of attack paths are generated and the attack paths include branches or merges, the above technique is still insufficient.

[0129] According to the IDM device 10 of the embodiment, based on the logs in the in-vehicle device group 100 having an attack detection function, a primary attack path without branches and merges is generated, and a secondary attack path that branches from or merges into the primary attack path is generated. Thereby, even when a plurality of devices are attacked simultaneously, the attack path can be specified.

[0130] According to the IDM device 10 of the embodiment, the secondary attack path includes in-vehicle devices included in the primary attack path and in-vehicle devices on the upstream or downstream side where an event EV assumed to be an attack has occurred within a certain time from an event EV assumed to be an attack on an in-vehicle device connected to a network convergence point or branch point. Thereby, the presence or absence of a secondary attack path associated with the primary attack path can be determined, and an attack path including the secondary attack path can be appropriately generated.

[0131] According to the IDM device 10 of the embodiment, among the in-vehicle device group 100, when an event EV for an in-vehicle device 116 that is included in the primary attack path and is connected to a branch point of the network and an event EV for an in-vehicle device 118 that is not included in the primary attack path to which the in-vehicle device 116 belongs among two or more in-vehicle devices 118 and 119 connected to the branch destination of the network occur within a certain time, a path that branches from the primary attack path to the in-vehicle device 118 is generated. Thereby, the presence or absence of an attack path that branches from the primary attack path can be determined, and an attack path including the branch can be appropriately generated.

[0132] According to the IDM device 10 of the embodiment, among the in-vehicle device group 100, for the in-vehicle device 114 that is included in the primary attack path and is connected to the confluence point of the network, and for the event EV for the in-vehicle device 112 that is not included in the primary attack path to which the in-vehicle device 114 belongs among two or more in-vehicle devices 111, 112 that are connected to the confluence point upstream of the in-vehicle device 114, when the events EV occur within a certain period of time, a path for merging into the primary attack path is generated from the upstream in-vehicle device 111. Thereby, it is possible to determine the presence or absence of an attack path that merges into the primary attack path, and it is possible to appropriately generate an attack path including the merge.

[0133] According to the IDM device 10 of the embodiment, based on a known attack scenario, an attack scenario in the event EV assumed to be an attack is estimated. Thereby, the added value of the information output to the SIEM device 21 can be further enhanced.

[0134] Note that in the above-described embodiment, the IDM device 10 includes the estimation unit 105, and the estimation unit 105 is configured to estimate an attack scenario in the event EV assumed to be an attack. However, the estimation of the attack scenario may be performed, for example, in the SIEM device 21.

[0135] (Modification Example 1) Next, with reference to FIGS. 15 to 19, the IDM device 210 of Modification Example 1 of the embodiment will be described. The IDM device 210 of the modification example is different from the above-described embodiment in that when generating a secondary attack path, a plurality of in-vehicle devices included in the generated attack path are treated as a group.

[0136] FIG. 15 is a block diagram showing an example of the functional configuration of the IDM device 210 and the SIEM device 21 according to Modification Example 1 of the embodiment. In FIG. 15, the same components as those in the above-described embodiment are denoted by the same reference numerals, and the description thereof is omitted.

[0137] As shown in FIG. 15, in addition to the configuration of the IDM device 10 of the above-described embodiment, the IDM device 210 of Modification 1 includes a group generation unit 218. The group generation unit 218 groups some in-vehicle devices included in the generated attack path. The group generation unit 218 is realized, for example, by the CPU of the IDM device 210 during execution of an attack path generation program.

[0138] FIG. 16 is a diagram showing an example of data obtained by performing fitting processing on the log acquired by the IDM device 210 according to Modification 1 of the embodiment.

[0139] In the example of FIG. 16, the in-vehicle device group 100 mounted on the vehicle includes in-vehicle devices 120 to 129. Assume that the network configuration of these in-vehicle devices 120 to 129 is different from the network configuration of the in-vehicle devices 110 to 119 of the above-described embodiment.

[0140] Also, in the example of FIG. 16, among these in-vehicle devices 120 to 129, it is assumed that an event EV assumed to be an attack on these in-vehicle devices has occurred in the in-vehicle devices 120, 123 to 126, 128, and 129.

[0141] The primary generation unit 103 first generates a primary attack path from the in-vehicle device 120 to the in-vehicle device 123. The group generation unit 218 generates a group GP in which these in-vehicle devices 120 and 123 are grouped.

[0142] When the secondary generation unit 104 examines the presence or absence of a branch or a merge in the primary attack path to which the in-vehicle devices 120 and 123 belong, the primary attack path to which the in-vehicle devices 120 and 123 belong is handled in group units. In the example of FIG. 16, for example, it can be seen that the in-vehicle device 125 is connected to the downstream side of the group GP in the group GP. Also, for example, it can be seen that the in-vehicle device 124 branches from the group GP.

[0143] The secondary generation unit 104 examines the possibility of branching of the attack path from the group GP to the in-vehicle device 124 on the downstream side of the group GP. At this time, the secondary generation unit 104 determines the presence or absence of branching from the group GP to the in-vehicle device 124 based on the occurrence timing of the event EV in the in-vehicle device 124 that branches from the group GP and the in-vehicle device 125 that is connected to the downstream side of the group GP.

[0144] FIG. 17 is a diagram showing the occurrence timing of the event EV between the in-vehicle devices 124 and 125 considered in the IDM device 210 according to Modification 1 of the embodiment.

[0145] As shown in FIG. 17, the events EV in the in-vehicle devices 124 and 125 occur in this order. Whether or not there is a branch in the attack path from the group GP to the in-vehicle device 124 is determined based on whether or not both the event EV in the in-vehicle device 124 and the event EV in the in-vehicle device 125 occur within a certain time PRd as the fourth period.

[0146] In the example of FIG. 17, both the event EV in the in-vehicle device 124 and the event EV in the in-vehicle device 125 occur within the certain time PRd. Therefore, the secondary generation unit 104 determines that there is a branch in the attack path from the group GP to the in-vehicle device 124.

[0147] Also when the secondary generation unit 104 examines the confluence into the primary attack path generated by the primary generation unit 103, the plurality of in-vehicle devices included in the primary attack path are handled in units of groups in the same manner as described above.

[0148] FIG. 18 shows an example of an attack path generated by the IDM device 210 of Modification 1. FIG. 18 is a diagram showing an example of an attack path generated by the IDM device 210 according to Modification 1 of the embodiment. In the example of FIG. 18, an attack path branching from the primary attack path generated by the primary generation unit 103 is provided by the secondary generation unit 104.

[0149] That is, in the example of FIG. 18, the primary generation unit 103 generates a primary attack path from the in-vehicle device 120 via the in-vehicle device 123 to the in-vehicle device 125. Further, the secondary generation unit 104 generates a secondary attack path that branches from the in-vehicle device 120 to the in-vehicle device 124.

[0150] In this secondary attack path, the primary generation unit 103 further generates a primary attack path from the in-vehicle device 124 via the in-vehicle device 126 to either the in-vehicle devices 128 or 129. The secondary attack path that branches from either the in-vehicle device 128 or 129 to the other is further provided by the secondary generation unit 104.

[0151] Next, an example of a method for generating a secondary attack path by the IDM device 210 of Modification 1 will be described with reference to FIG. 19. FIG. 19 is a flowchart showing an example of the procedure of the secondary attack path generation process by the IDM device 210 according to Modification 1 of the embodiment.

[0152] In the secondary attack path generation process of the above-described embodiment, the branching or merging between individual in-vehicle devices was considered, whereas in the secondary attack path generation process of Modification 1, the branching or merging of a predetermined in-vehicle device with respect to a plurality of grouped in-vehicle devices is considered. In other words, the processes of steps S122 to S126 shown in FIG. 19 correspond to the processes of steps S112 to S116 shown in FIG. 13 of the above-described embodiment.

[0153] As shown in FIG. 19, the secondary generation unit 104 determines whether there is a generated attack path adjacent to a predetermined in-vehicle device in which an event EV assumed to be an attack has occurred (step S121). If there is no adjacent attack path (step S121: No), the secondary generation unit 104 skips the processes of steps S122 to S127 and proceeds to the process of step S128.

[0154] If there is an adjacent attack path (step S121: Yes), the secondary generation unit 104 treats the attack path in units of groups and determines whether there is a branch or a confluence that can generate a secondary attack path between the attack path and the above-described in-vehicle device adjacent thereto (step S122).

[0155] If there is no branch or confluence (step S122: No), the secondary generation unit 104 skips the processes of steps S123 to S127 and proceeds to the process of step S128.

[0156] If there is a branch that can generate a secondary attack path between the attack path and the above-described in-vehicle device adjacent thereto (step S122: Yes (branch)), the secondary generation unit 104 determines whether an event EV assumed to be an attack in the in-vehicle device connected downstream to the attack path and the above-described in-vehicle device adjacent to the attack path has occurred within a certain period of time (step S123).

[0157] If the event EV has occurred within a certain period of time (step S123: Yes), the secondary generation unit 104 sets a branch path between the attack path and the in-vehicle device (step S124). If the event EV has not occurred within a certain period of time (step S123: No), the secondary generation unit 104 skips the processes of steps S124 and S127 and proceeds to the process of step S128.

[0158] If there is a confluence that can generate a secondary attack path between the attack path and the above-described in-vehicle device adjacent thereto (step S122: Yes (confluence)), the secondary generation unit 104 determines whether an event EV assumed to be an attack in the in-vehicle device connected upstream to the attack path and the above-described in-vehicle device adjacent to the attack path has occurred within a certain period of time (step S125).

[0159] When an event EV occurs within a certain period of time (step S125: Yes), the secondary generation unit 104 sets a confluence path between the attack path and the in-vehicle device (step S126). When the event EV has not occurred within a certain period of time (step S125: No), the secondary generation unit 104 skips the processes of steps S126 and S127 and proceeds to the process of step S128.

[0160] When there is a branch path set between the attack path and the adjacent in-vehicle device described above, the secondary generation unit 104 generates a secondary attack path including the branch, and when there is a confluence path set between the attack path and the adjacent in-vehicle device described above, the secondary generation unit 104 generates a secondary attack path including the confluence (step S127).

[0161] Also, the secondary generation unit 104 determines whether the generation of the attack path is completed by the processes from step S121 to S127 (step S128). If it is not completed with the attack path generated so far (step S128: No), the secondary generation unit 104 determines whether another attack path can be generated (step S129).

[0162] When another primary path cannot be generated (step S129: No), the IDM device 210 ends the process. In this case, the generation of the attack path ends with in-vehicle devices remaining that are not included in the generated attack path. The remaining in-vehicle devices are treated as including false detections.

[0163] If another primary path can be generated (step S129: Yes), the processes from step S121 to S129 within loop L2(S) to L2(E) are repeated until the generation of the attack path is completed. When the generation of the attack path is completed (step S128: Yes), the process of loop L2(S) to L2(E) ends.

[0164] Thus, the process of generating the secondary attack path by the IDM device 210 of Modification 1 ends.

[0165] According to the IDM device 210 of Modification Example 1, when attacks on in-vehicle device 124 on the branch path associated with group GP and attacks on in-vehicle device 125 connected downstream of group GP occur within a certain period of time among the in-vehicle device group 100, a path branching from group GP to in-vehicle device 124 is generated. Thereby, the possibility of the target of attack can be considered more widely.

[0166] (Modification Example 2) Next, the IDM device 310 of Modification Example 2 of the embodiment will be described with reference to FIGS. 20 to 23. The IDM device 310 of Modification Example 2 is different from the above-described embodiment in that it counts the number of occurrences of event EV.

[0167] FIG. 20 is a block diagram showing an example of the functional configuration of the IDM device 310 and the SIEM device 21 according to Modification Example 2 of the embodiment. In FIG. 20, the same components as those in the above-described embodiment are denoted by the same reference numerals, and the description thereof is omitted.

[0168] As shown in FIG. 20, the IDM device 310 of Modification Example 2 includes a target estimation unit 318 in addition to the configuration of the IDM device 10 of the above-described embodiment.

[0169] The target estimation unit 318 counts the number of occurrences of event EV within a certain period of time in the data obtained by performing fitting processing on the logs acquired from the IDS sensor group. Further, the target estimation unit 318 estimates that one or more in-vehicle devices connected downstream of the in-vehicle device at the branch destination where the number of occurrences of event EV is the largest among the plurality of branch destinations in the attack path are the attack targets. The target estimation unit 318 is realized, for example, by the CPU of the IDM device 310 during execution of the attack path generation program.

[0170] FIG. 21 is a diagram showing an example of the attack path generated by the IDM device 310 according to Modification Example 2 of the embodiment.

[0171] In the example of FIG. 21, the in-vehicle device group 100 mounted on the vehicle includes in-vehicle devices 130 to 139. It is assumed that the network configuration of these in-vehicle devices 130 to 139 is different from the network configuration of the in-vehicle devices 110 to 119 in the above-described embodiment.

[0172] Also, in the example of FIG. 21, it is assumed that an event EV assumed to be an attack on these in-vehicle devices has occurred in the in-vehicle devices 130 to 133, 135 to 139 among these in-vehicle devices.

[0173] The primary generation unit 103 generates an attack path based on the data after the fitting. As a result, a primary attack path from the in-vehicle device 130, via the in-vehicle device 131, to the in-vehicle device 133 is generated. Also, a primary attack path from the in-vehicle device 130, via the in-vehicle devices 132 and 135, to the in-vehicle device 137 is generated.

[0174] Also, a secondary generation unit 104 generates a secondary attack path that branches from the in-vehicle device 135 to the in-vehicle device 138. Also, a secondary attack path that branches from the in-vehicle device 132, to the in-vehicle device 136 and then to the in-vehicle device 139 is generated.

[0175] On the other hand, the target estimation unit 318 counts, for the in-vehicle devices 130 to 139, the number of times the event EV has occurred within a certain time as the third period as the number of attack occurrences.

[0176] In the example of FIG. 21, it is assumed that the event EV has occurred in the in-vehicle devices 131 and 132 within a certain time. In this case, the target estimation unit 318 counts, for example, the number of attack occurrences in the in-vehicle device 131 as the first time out of 2 times, that is, 1 / 2. Also, the target estimation unit 318 counts, for example, the number of attack occurrences in the in-vehicle device 132 as the second time out of 2 times, that is, 2 / 2.

[0177] In the example of FIG. 21, it is also assumed that no other in-vehicle device in which the event EV has occurred within a certain time after the event EV has occurred in the in-vehicle device 133. In this case, the target estimation unit 318 counts, for example, the number of attacks occurring in the in-vehicle device 133 as 1 time.

[0178] In the example of FIG. 21, it is also assumed that the event EV has occurred in the in-vehicle devices 135 and 136 within a certain time. In this case, the target estimation unit 318 counts, for example, the number of attacks occurring in the in-vehicle device 135 as the first time out of 2 times, that is, 1 / 2. Also, the target estimation unit 318 counts, for example, the number of attacks occurring in the in-vehicle device 136 as the second time out of 2 times, that is, 2 / 2.

[0179] In the example of FIG. 21, it is also assumed that the event EV has occurred in the in-vehicle devices 137 and 138 within a certain time. In this case, the target estimation unit 318 counts, for example, the number of attacks occurring in the in-vehicle device 137 as the first time out of 2 times, that is, 1 / 2. Also, the target estimation unit 318 counts, for example, the number of attacks occurring in the in-vehicle device 138 as the second time out of 2 times, that is, 2 / 2.

[0180] In the example of FIG. 21, it is also assumed that no other in-vehicle device in which the event EV has occurred within a certain time after the event EV has occurred in the in-vehicle device 139. In this case, the target estimation unit 318 counts, for example, the number of attacks occurring in the in-vehicle device 139 as 1 time.

[0181] After counting the number of attacks occurring in each of the in-vehicle devices 130 to 139, the target estimation unit 318 identifies the in-vehicle device that is the attack target based on the count of the number of attacks.

[0182] Specifically, in the attack path starting from the in-vehicle device 130, a branch can be seen between the path leading to the in-vehicle devices 131 and 133 and the path leading to the in-vehicle devices 132, 135, and 136. In this case, the target estimation unit 318 compares the number of attacks occurring in the branch destinations including the in-vehicle devices 131 and 133 and the branch destinations including the in-vehicle devices 132, 135, and 136 among the plurality of branch destinations from the in-vehicle device 130.

[0183] In the example of FIG. 21, at the branch destination including in-vehicle devices 131 and 133, the number of attacks occurring in in-vehicle device 133 is one. Also, at the branch destination including in-vehicle devices 132, 135, and 136, the number of attacks occurring in in-vehicle devices 135 and 136 is two. Therefore, the target estimation unit 318 estimates that at least one of in-vehicle devices 137 to 139 connected to the downstream side of the branch destination including in-vehicle devices 132, 135, and 136 is an attack target.

[0184] Also, in the attack path starting from in-vehicle device 132, a branch is seen between the path leading to in-vehicle devices 135, 137, and 138 and the path leading to in-vehicle devices 136 and 139. In this case, the target estimation unit 318 compares the number of attacks occurring at the branch destinations including in-vehicle devices 135, 137, and 138 and the branch destinations including in-vehicle devices 136 and 139 among the plurality of branch destinations from in-vehicle device 132.

[0185] In the example of FIG. 21, at the branch destination including in-vehicle devices 135, 137, and 138, the number of attacks occurring in in-vehicle devices 137 and 138 is two. Also, at the branch destination including in-vehicle devices 136 and 139, the number of attacks occurring in in-vehicle device 139 is one. Therefore, the target estimation unit 318 estimates that at least one of in-vehicle devices 137 and 138 connected to the most downstream point of the branch destination including in-vehicle devices 135, 137, and 138 is an attack target.

[0186] In the network configuration of in-vehicle device group 100, when the estimation of the attack target is performed up to in-vehicle devices 137 to 139 connected to the most downstream point, the target estimation unit 318 generates an attack path leading to in-vehicle devices 137 and 138 that are estimated to be attack targets among in-vehicle devices 137 to 139 connected to the most downstream point. An example of the attack path generated by the target estimation unit 318 is shown in FIG. 22.

[0187] FIG. 22 is a diagram showing an example of an attack path generated by the IDM device 310 according to Modification Example 2 of the embodiment based on the count of attack targets. As shown in FIG. 22, the target estimation unit 318 generates an attack path from the in-vehicle device 130 via the in-vehicle devices 132 and 135 to the in-vehicle device 137 and an attack path to the in-vehicle device 138.

[0188] In this way, even when the attack paths generated by the primary generation unit 103 and the secondary generation unit 104 branch in multiple directions on the downstream side of the network, the in-vehicle devices that are the attack targets are narrowed down by the target estimation unit 318.

[0189] Next, an example of a method for generating an attack path by the IDM device 310 of Modification Example 2 will be described with reference to FIG. 23.

[0190] FIG. 23 is a flowchart showing an example of a procedure for generating an attack path based on the number of attacks generated by the IDM device 310 according to Modification Example 2 of the embodiment. The process of FIG. 23 is performed after the process of generating the attack path by the primary generation unit 103 and the secondary generation unit 104.

[0191] As shown in FIG. 23, the target estimation unit 318 determines whether there is a branch on the attack path generated by the primary generation unit 103 and the secondary generation unit 104 (step S201). If there is no branch on the attack path (step S201: No), the target estimation unit 318 skips the process of step S202 and proceeds to the process of step S203.

[0192] If there is a branch on the attack path (step S201: Yes), the target estimation unit 318 selects an attack path with a large number of attack occurrences on the downstream side of a predetermined branch (step S202).

[0193] Further, the target prediction unit 318 determines whether the processes of steps S201 and S202 have been completed for the entire attack path generated by the primary generation unit 103 and the secondary generation unit 104 (step S203). If there is an unprocessed part in the attack path (step S203: No), the target prediction unit 318 repeats the processes from steps S201 to S203 within loop L3(S) to L3(E) until the processing is completed for the entire attack path. When the processing is completed for the entire attack path (step S203: Yes), the processing of loop L3(S) to L3(E) is terminated.

[0194] Thus, the generation process of the attack path based on the number of attacks by the IDM device 310 of Modification 2 is completed.

[0195] According to the IDM device 310 of Modification 2, the number of events EV occurring within a certain period is counted as the number of attack occurrences, and when a secondary attack path branches, an attack path leading to one or more in-vehicle devices 137, 138 connected to the downstream side of the in-vehicle device 135 at the branch destination where the number of attack occurrences is larger than that of other branch destinations among the plurality of branch destinations is generated.

[0196] Thereby, even when there are a large number of branches in the attack path on the downstream side of the network, for example, the in-vehicle device that is the attack target can be narrowed down. Therefore, the destination of the attack path can be visualized, and it becomes possible to macroscopically determine where the attacker is interested.

[0197] As described above, the embodiments of the present invention have been described. However, the above-described embodiments are presented as examples and are not intended to limit the scope of the present invention. This novel embodiment can be implemented in various other forms. Also, various omissions, replacements, and changes can be made without departing from the gist of the invention. Further, this embodiment is included in the scope and gist of the invention and is included in the invention described in the claims and the equivalent scope thereof.

Description of Reference Numerals

[0198] 10,210,310 IDM device 20 Data center 21 SIEM device 22 Database 100 In-vehicle device group 100a IDS sensor group 101 Acquisition unit 102 Aggregation unit 103 Primary generation unit 104 Secondary generation unit 105 Estimation unit 106 Output unit 107 Storage unit 107a Network configuration database 107b Known attack database 218 Group generation unit 318 Target prediction unit NTc Network NTe External network VH Vehicle

Claims

1. An attack path generation method executed by an information processing apparatus that generates an attack path in a plurality of devices connected to a network including at least one of branching and merging, each having an attack detection function, by acquiring logs in the plurality of devices, comprising: generating a primary attack path without branching and merging based on the acquired logs; generating a secondary attack path that branches from or merges into the primary attack path based on the logs; outputting the generated primary attack path and the secondary attack path to a device that performs an attack determination; wherein the secondary attack path is an attack path including a device that is included in the primary attack path and is connected to a merging point or a branching point of the network, and devices on the upstream side or the downstream side where events assumed to be attacks have occurred within a certain time from an event assumed to be an attack on the device; Attack path generation method.

2. When generating the secondary attack path, among the plurality of devices, if the event for a first device that is included in the primary attack path and is connected to a branching point of the network and the event for a second device that is not included in the primary attack path among two or more devices connected to the branch destination of the network occur within a first period, generate a path that branches from the primary attack path to the second device. The attack path generation method according to claim 1.

3. generating a first attack path and a second attack path as the primary attack paths; When generating the secondary attack path, among the plurality of devices, if the event for a third device that is included in the first attack path and is connected to a branching point of the network and the event for a fourth device that is not included in the first attack path among two or more devices connected to the branch destination of the network occur within the first period, generate a path that branches from the first attack path to the fourth device. The attack path generation method according to claim 2.

4. When generating the secondary attack path, When, among the plurality of devices, an event occurs for a fifth device that is included in the primary attack path and is connected to the confluence point of the network, and an event occurs for a sixth device that is not included in the primary attack path among two or more devices connected to the confluence point upstream of the fifth device within a second period, a path that merges from the sixth device into the primary attack path is generated. The attack path generation method according to claim 1 or claim 2.

5. Generate a first attack path and a second attack path as the primary attack paths, When generating the secondary attack path, When, among the plurality of devices, an event occurs for a seventh device that is included in the first attack path and is connected to the confluence point of the network, and an event occurs for an eighth device that is not included in the first attack path among two or more devices connected to the confluence point upstream of the seventh device within the second period, a path that merges from the eighth device into the second attack path is generated. The attack path generation method according to claim 4.

6. Count the number of occurrences of the event within a third period as the number of attack occurrences, and when the secondary attack path branches, generate an attack path leading to one or more devices connected downstream of the device at the branch destination where the number of attack occurrences is greater than that of other branch destinations among the plurality of branch destinations. The attack path generation method according to any one of claims 1 to 5.

7. Generate a group of the primary attack paths including two or more devices among the plurality of devices, When generating the secondary attack path, When, among the plurality of devices, an attack on a ninth device on a branch path associated with the group and an attack on a tenth device connected downstream of the group occur within a fourth period, generate a path that branches from the group to the ninth device. The attack path generation method according to any one of claims 1 to 4.

8. Estimate the attack scenario in the event based on a known attack scenario. The attack path generation method according to any one of claims 1 to 7.

9. An in-vehicle attack path generation device that generates an attack path in a plurality of devices configured as in-vehicle electronic control units each having an attack detection function and connected to a network including at least one of divergence and convergence, by acquiring logs in the plurality of devices, a primary generation unit that generates a primary attack path without divergence and convergence based on the acquired logs; a secondary generation unit that generates a secondary attack path that diverges from or converges to the primary attack path based on the logs; an output unit that outputs the generated primary attack path and the secondary attack path to an external device that performs an attack determination, and the secondary generation unit generates a secondary attack path including upstream or downstream devices in which events assumed to be attacks have occurred within a certain time from an event assumed to be an attack on a device included in the primary attack path and connected to a convergence point or divergence point of the network, attack path generation device.

Images