Attack path estimation system, attack path estimation device, attack path estimation method and program

Abstract

One aspect of an attack path estimation system according to the present disclosure is an attack path estimation system that estimates attack paths in a target system, the attack path estimation system having: a configuration information creation unit configured to use at least either design information or an operational history log of the target system to create configuration information representing the configuration of the target system; a predicted path information creation unit configured to use the configuration information and attack patterns anticipated in the target system to create predicted path information representing predicted paths of attacks on the target system; a predicted path information creation unit configured to use a log acquired from the target system and prescribed weighting conditions to create weighted predicted path information in which weightings have been applied to the predicted path information when an attack has been detected on the target system; and a path search unit configured to estimate attack paths representing paths from the origin of the attack to an attack destination by using a path search on the weighted predicted path information.

Description

[Technical field]

[0001] The present disclosure relates to an attack path estimation system, an attack path estimation device, an attack path estimation method, and a program. [Background technology]

[0002] In recent years, vehicles equipped with a function for constant connection to external networks (so-called connected cars) are expected to become more widespread. Connected cars are expected to improve convenience by providing the latest traffic information, remote control of door locks and air conditioners, and software updates for electronic control units (ECUs).

[0003] On the other hand, there are concerns that by connecting vehicles and their electronic control devices to external networks, they may become targets of cyberattacks from malicious attackers, just like conventional IT devices. Research has been reported that has shown that it is possible to tamper with a controller installed in a vehicle by accessing it from an external network, and to take over vehicle control by sending false commands from the controller to the ECU. For this reason, in order to detect cyberattacks on vehicles, research is also being conducted on IDS (Intrusion Detection Systems) that detect anomalies in the vehicle's control information network, CAN (Controller Area Network).

[0004] Incidentally, when a cyber attack is detected, the attack is analyzed. One of the important purposes of the cyber attack analysis is to identify the device from which the attack originates and the malware process / program in the device, and to clarify the attack path. In an intranet or server system to which multiple devices are connected, a method of analyzing logs obtained by monitoring network devices, such as SIEM (Security Information Event Management), is often used. For example, Non-Patent Document 1 discloses a method of tracking the communication / process related to an attack communication or a malicious file / process detected by installing a monitor on a PC in an intranet that monitors the startup of a process and the communication sent and received by the process, and analyzing the log output by the monitor, thereby identifying the attack path and the source of the attack. In general, the starting point of the attack path is the source of the attack, so in the following, identifying the attack path includes identifying the source of the attack. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] Makoto Sato, Akihiko Sugimoto, Naoki Hayashi, Yoshiaki Isobe, Ryoichi Sasaki, "Development and Evaluation of an Infection Route Detection Tool for Targeted Attacks Using Malware Behavior in Networks," Transactions of Information Processing Society of Japan, Vol. 58, No. 2, 366-374 (Feb. 2017). Summary of the Invention [Problem to be solved by the invention]

[0006] Even in vehicle control systems where multiple ECUs are connected via CAN or Ethernet, log analysis seems to be effective in identifying attack paths. However, since ECUs are inexpensive and have low performance compared to PCs and servers, it can be difficult to introduce monitors to ECUs. In addition, the network bandwidth for collecting logs is also limited from a cost perspective, so the logs to be collected are often carefully selected. In addition, since CAN is a protocol that does not have source and destination addresses, it is difficult to identify the source and destination ECUs using CAN-IDS or CAN communication monitors that monitor the CAN bus. As such, the number and types of logs that can be obtained in vehicle control systems may be fewer than in general IT systems.

[0007] In addition, there may be gaps in the logs due to vehicle breakdowns or deterioration of communication conditions due to the driving environment (for example, deterioration of communication conditions due to driving through a tunnel), and some logs may become unavailable due to monitoring obstruction caused by attacks, etc. These gaps (including the inability to obtain logs) make log analysis even more difficult.

[0008] For example, in the method disclosed in Non-Patent Document 1, when an attack communication or a malicious file / process is detected, the attack path is identified by sequentially tracing the process of the communication partner, its parent process, or the communication immediately before that, etc. For this reason, a missing log makes tracing extremely difficult and is a major hindrance to identifying the attack path.

[0009] The above-mentioned issues are not limited to vehicle control systems, but are also common to various devices connected to networks. For example, it is difficult to introduce new monitors into existing IoT (Internet of Things) devices, so there is a risk that logs required for log analysis to identify attack routes cannot be obtained.

[0010] The present disclosure has been made in consideration of the above points, and provides a technology for estimating an attack path. [Means for solving the problem]

[0011] An attack path estimation system according to one aspect of the present disclosure is an attack path estimation system that estimates an attack path in a target system, and includes: a configuration information creation unit configured to create configuration information representing a configuration of the target system using at least one of design information and operation history logs of the target system; a predicted path information creation unit configured to create predicted path information representing a predicted path of an attack on the target system using the configuration information and an attack pattern assumed in the target system; a weighted predicted path information creation unit configured, when an attack on the target system is detected, to create weighted predicted path information by weighting the predicted path information using logs acquired from the target system and predetermined weighting conditions; and a path search unit configured to estimate an attack path representing a path from the source of the attack to the destination of the attack by path search on the weighted predicted path information. Effect of the Invention

[0012] Techniques are provided for estimating attack paths. [Brief description of the drawings]

[0013] [Figure 1] 2 is a diagram illustrating an example of a hardware configuration of an attack path estimation device according to the first embodiment; [Diagram 2] 1 is a diagram illustrating an example of a functional configuration of an attack path estimation device according to a first embodiment; [Diagram 3] 5 is a flowchart showing an example of a predicted route information creation process according to the first embodiment. [Figure 4] 11 is a flowchart illustrating an example of an attack path inference process according to the first embodiment. [Diagram 5] 1 is a diagram illustrating a vehicle control system according to a first embodiment. [Figure 6] FIG. 1 is a diagram illustrating an example of an attack in the first embodiment. [Figure 7] FIG. 2 is a diagram illustrating an example of attack detection in the first embodiment. [Figure 8] FIG. 4 is a diagram showing vehicle configuration information in the first embodiment. [Figure 9] FIG. 2 is a diagram showing a predicted route in the first embodiment. [Figure 10] FIG. 4 is a diagram showing predicted route information in the first embodiment. [Figure 11] FIG. 1 is a diagram showing observation information in the first embodiment. [Figure 12] FIG. 1 is a diagram showing a weighted predicted trajectory in the first embodiment. [Figure 13] FIG. 11 is a diagram showing weighted predicted route information in the first embodiment. [Figure 14] FIG. 1 is a diagram (part 1) showing an estimated attack path in the first embodiment. [Figure 15] FIG. 2 is a diagram (part 2) showing an estimated attack path in the first embodiment. [Figure 16] FIG. 13 is a diagram showing an estimated attack path and its score and cost in the first embodiment. [Figure 17] FIG. 13 is a diagram showing assumed attack patterns in the second embodiment. [Figure 18] FIG. 11 is a diagram showing a weighted predicted trajectory in the second embodiment. [Figure 19] FIG. 11 is a diagram showing weighted predicted route information in the second embodiment. [Figure 20] FIG. 13 is a diagram showing a weighted predicted trajectory in the third embodiment. [Figure 21] FIG. 13 is a diagram showing a predicted route in the fourth embodiment. [Figure 22] FIG. 13 is a diagram showing a weighted predicted trajectory in the fourth embodiment. [Figure 23] FIG. 13 is a diagram showing weighted predicted route information in the fourth embodiment. [Figure 24] FIG. 13 is a diagram (part 1) showing inferred attack paths and their scores and costs in the fourth embodiment. [Diagram 25] FIG. 23 is a diagram (part 2) showing inferred attack paths and their scores and costs in the fourth embodiment. [Figure 26] FIG. 13 is a diagram showing an example of a weighted predicted path. [Figure 27]FIG. 13 is a diagram showing an example of a prize money-weighted predicted path. [Figure 28] FIG. 11 is a diagram illustrating an example of a functional configuration of an attack path estimation device according to a second embodiment. [Figure 29] 13 is a flowchart illustrating an example of an attack path inference process according to the second embodiment. [Diagram 30] FIG. 13 is a diagram showing an example of a predicted route after observation information has been added or overwritten. [Diagram 31] This is a diagram (part 1) showing an example of prize money and weights. [Diagram 32] This is a diagram (part 2) showing an example of prize money and weights. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] An embodiment of the present invention will be described below. In each of the following embodiments, an attack path estimation device 10 will be described that can estimate an attack path even if there is a missing log (missing data) when an attack is detected, mainly targeting a vehicle control system. An attack path is a path from the source of the attack (e.g., a malicious process or a malicious ECU that is the source of the attack) to the target of the attack (destination of the attack). By estimating the attack path, for example, when an attack on a vehicle control system is detected, it becomes possible to efficiently analyze the scope of the impact, etc.

[0015] A vehicle control system is a system that is configured with an electronic control unit (ECU), CAN, etc., and controls various functions of a vehicle (e.g., automobile, special vehicle, motorcycle, bicycle, etc.). However, the following embodiments are not limited to vehicle control systems, and can be similarly applied to machine control systems that are mounted on machines (e.g., machine tools, construction machines, agricultural machines, industrial machines, etc.) and configured with an electronic control unit (ECU), CAN, etc. Furthermore, they can be similarly applied to IoT systems configured with IoT devices and any communication network.

[0016] [First embodiment] The first embodiment will be described below.

[0017] <Hardware Configuration of Attack Path Estimation Device 10> An example of a hardware configuration of an attack path estimation device 10 according to the first embodiment is shown in Fig. 1. As shown in Fig. 1, the attack path estimation device 10 according to the first embodiment includes an input device 101, a display device 102, an external I / F 103, a communication I / F 104, a RAM (Random Access Memory) 105, a ROM (Read Only Memory) 106, an auxiliary storage device 107, and a processor 108. Each of these hardware components is connected to each other via a bus 109 so as to be able to communicate with each other.

[0018] The input device 101 is, for example, a keyboard, a mouse, a touch panel, a physical button, etc. The display device 102 is, for example, a display, a display panel, etc. Note that the attack path estimation device 10 does not necessarily have to include at least one of the input device 101 and the display device 102, for example.

[0019] The external I / F 103 is an interface with an external device such as a recording medium 103a. The attack path estimation device 10 can read and write data from and to the recording medium 103a via the external I / F 103. Examples of the recording medium 103a include a flexible disk, a CD (Compact Disc), a DVD (Digital Versatile Disk), a SD memory card (Secure Digital memory card), and a USB (Universal Serial Bus) memory card.

[0020] The communication I / F 104 is an interface for connecting the attack path estimation device 10 to a communication network. The RAM 105 is a volatile semiconductor memory (storage device) that temporarily stores programs and data. The ROM 106 is a non-volatile semiconductor memory (storage device) that can store programs and data even when the power is turned off. The auxiliary storage device 107 is a storage device (storage device) such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), or a flash memory. The processor 108 is an arithmetic device such as a CPU (Central Processing Unit).

[0021] The attack path estimation device 10 according to the first embodiment has the hardware configuration shown in Fig. 1, and can thereby realize predicted path information creation processing and attack path estimation processing, which will be described later. Note that the hardware configuration shown in Fig. 1 is merely an example, and the hardware configuration of the attack path estimation device 10 is not limited thereto. For example, the attack path estimation device 10 may have multiple auxiliary storage devices 107 and multiple processors 108, may not have some of the hardware shown in the figure, or may have various hardware other than the hardware shown in the figure.

[0022] <Functional configuration of the attack path estimation device 10> FIG. 2 shows an example of a functional configuration of the attack path estimation device 10 according to the first embodiment. As shown in FIG. 2, the attack path estimation device 10 according to the first embodiment includes a predicted path configuration unit 110 and an attack path estimation unit 120. These units are realized, for example, by a process in which one or more programs installed in the attack path estimation device 10 are executed by the processor 108. The attack path estimation device 10 according to the first embodiment also includes a predicted path information storage unit 130. The predicted path information storage unit 130 is realized, for example, by the auxiliary storage device 107. Note that the predicted path information storage unit 130 may be realized, for example, by a storage device such as a database connected to the attack path estimation device 10 via a communication network.

[0023] The predicted path constructing unit 110 creates predicted path information that indicates a predicted path of an attack using information obtained in advance. As a result, even if there is missing data in a log when an attack is detected (hereinafter also referred to as an attack detection log), the missing part can be complemented by the predicted path to estimate the attack path. Hereinafter, in this embodiment, the information obtained in advance is assumed to be design information such as ECUs mounted on a vehicle and processes, communications, and network connections executed by these ECUs, operation history logs that indicate logs of processes and communications of each EUC obtained in advance, and assumed attack patterns that indicate attack paths of malicious EUCs and malicious processes that are assumed in advance.

[0024] Here, the predicted route composition unit 110 includes a vehicle configuration information composition unit 111 and a predicted route information composition unit 112 .

[0025] The vehicle configuration information creation unit 111 creates vehicle configuration information using design information and operation history logs. The vehicle configuration information is information represented in a graph structure in which the processes executed by the EUC, the ECU itself, the communications and network connections they transmit and receive, and objects (e.g., data, files, etc.) related to those processes and ECUs are represented as nodes, and the associations between the nodes are represented as edges.

[0026] The predicted route information creation unit 112 creates predicted route information using the vehicle configuration information and the predicted attack pattern. The predicted route information creation unit 112 also stores the created predicted route information in the predicted route information storage unit 130. The predicted attack pattern is information expressed in a graph structure in which nodes are assumed to be malicious processes and malicious ECUs, the malicious communications and network connections they transmit and receive, and objects (e.g., data, files, etc.) related to the malicious processes and malicious ECUs, and edges are associations between the nodes. The predicted route information is a graph in which a graph represented by a predicted attack pattern is added to a graph represented by vehicle configuration information. In other words, the predicted route information is information expressed in a graph structure in which nodes and edges of a predicted attack pattern are added to nodes and edges of vehicle configuration information.

[0027] In this way, predicted path information is created by adding the graph represented by the assumed attack pattern to the graph represented by the vehicle configuration information. This is because, in general, an attack path first passes through a normal path, that is, a path in the graph represented by the vehicle configuration information, and then, at the time of the attack, nodes that are not in the graph represented by the vehicle configuration information (malicious processes, malicious communications, malicious objects such as malicious files, etc.) appear, and the path passes through such malicious nodes.

[0028] The attack path estimation unit 120 estimates an attack path using expected path information, an attack detection log, and a weighting rule, and creates attack path information representing the attack path. The attack detection log is a log collected when an IDS or the like of a vehicle control system detects an attack. When an IDS or the like of the vehicle control system detects an attack, the attack detection log may be collected by the vehicle control system and transmitted to the attack path estimation device 10, or the attack path estimation device 10 may collect the attack detection log from the vehicle control system. The weighting rule is information representing weighting conditions (rules) used when creating weighted expected path information described later.

[0029] Here, the attack path estimation unit 120 includes a weighted predicted path information creation unit 121 and a path search unit 122.

[0030] The weighted predicted path information creation unit 121 acquires attack detection logs and creates observation information of attacks using the attack detection logs, and then adds or overwrites the observation information to the predicted path information. The weighted predicted path information creation unit 121 also uses a weighting rule to weight the edges of the predicted path information after addition or overwriting, and creates weighted predicted path information. The observation information is information expressed in a graph structure in which processes and ECUs (including malicious processes and malicious ECUs) that appear in the attack detection logs, communications and network connections that they transmit and receive, and objects related to those processes and ECUs (e.g., data, files, etc.) are nodes, and associations between nodes are edges. In other words, the observation information is information on a graph that shows the path of an attack observed as an attack detection log.

[0031] As a result, even if there is missing data in the attack detection log and the graph represented by the observation information obtained from the attack detection log is incomplete, the missing part can be supplemented with the predicted route information. On the other hand, although multiple attack routes can be estimated in the supplemented part, it is possible to estimate a more likely route as the attack route by weighting the edges. The weight represents the strength of the association between the nodes. The weight may be, for example, a cost that is assigned a smaller value the stronger the association between the nodes, or a transition probability that represents the probability that the edge can be used. Also, for example, part of the weight may be assigned in advance by the predicted route configuration unit 110 (particularly, the vehicle configuration information creation unit 111).

[0032] The route search unit 122 uses a node (hereinafter also referred to as a detection node) representing a malicious process or malicious communication detected by an IDS or the like of the vehicle control system as a starting point, searches for a route backward from the detection node using weighted predicted route information, and estimates an attack route (including the source of the attack). In addition, the route search unit 122 outputs attack route information representing the estimated attack route to a predetermined output destination (for example, the display device 102 such as a display, the auxiliary storage device 107, another terminal connected via a communication network, etc.). For example, a shortest route search method represented by Dijkstra's algorithm can be used as the route search method.

[0033] The attack paths estimated by the path search unit 122 may be multiple paths that pass through the same detection node from different attack source nodes. For this reason, the path search unit 122 may output the most likely attack path information among the multiple attack path information to a predetermined output destination, for example, using a predetermined score. Alternatively, the path search unit 122 may output multiple attack path information and their scores to a predetermined output destination. Here, the score may be, for example, the sum of costs assigned to edges on the attack path, the sum divided by the number of nodes on the attack path, the transition probability from the start point to the end point (detection node) of the attack path, or the like.

[0034] The predicted route information storage unit 130 stores predicted route information. The predicted route information storage unit 130 may store predicted route information corresponding to each type or category of vehicle, for example. In this case, the attack route estimation unit 120 uses predicted route information corresponding to the type or category of vehicle in which the attack was detected.

[0035] <Predicted route information creation process> The predicted path information creation process according to the first embodiment will be described with reference to Fig. 3. Note that the predicted path information creation process is executed before the attack path estimation process, which will be described later, is executed.

[0036] The vehicle configuration information creation unit 111 of the predicted route configuration unit 110 creates vehicle configuration information by using the design information and the operation history log (step S101). Note that the vehicle configuration information creation unit 111 may use both the design information and the operation history log, or may use only one of them.

[0037] The predicted route information creation unit 112 of the predicted route configuration unit 110 creates predicted route information using the vehicle configuration information and the assumed attack pattern, and stores this predicted route information in the predicted route information storage unit 130 (step S102).

[0038] <Attack route estimation process> The attack path estimation process according to the first embodiment will be described with reference to Fig. 4. Note that the attack path estimation process is executed every time an attack is detected in the vehicle control system.

[0039] The weighted predicted path information creation unit 121 of the attack path estimation unit 120 acquires attack detection logs and creates attack observation information using the attack detection logs, adds or overwrites the observation information to the predicted path information, and creates weighted predicted path information using weighting rules (step S201).

[0040] The path search unit 122 of the attack path estimation unit 120 estimates an attack path by searching for a path using the weighted predicted path information from the detection node, and outputs the attack path information representing the estimated attack path to a predetermined output destination (step S202). At this time, the path search unit 122 may output the most likely attack path information among the multiple attack path information using a predetermined score, or may output the multiple attack path information and their scores.

[0041] <Example> An example of the first embodiment will now be described.

[0042] Example 1 Hereinafter, a first embodiment will be described. This embodiment is a case where an attack path is estimated using comprehensive assumed attack patterns. That is, this embodiment describes a case where a specific attack is not assumed, but various attacks are assumed comprehensively, and attack paths can be estimated even for unknown attacks.

[0043] The configuration of the vehicle control system in this embodiment is shown in FIG. 5. The vehicle control system in this embodiment uses a smartphone or the like to remotely control the door lock / unlock and air conditioning on / off of the target vehicle. For example, an OEM site receives a command from a smartphone. The TCUctrl process on the TCU, which is a telematics control unit, periodically accesses the OEM site via HTTPS (URLOEM) to receive the command. The command is communicated via Ethernet (IPCGW) and converted to CAN communication (CAN6AA) by the CGW, which is a central gateway, and the command is executed by the ECU1 corresponding to the CAN communication. The OEM site and the TCU are connected by NWEXT, which is an external wireless IP network, and the TCU and the CGW are connected by NWINT, which is an in-vehicle Ethernet network. The CGW and each ECU are also connected by CANBUS, which is an in-vehicle CAN network. Furthermore, the TCU and each ECU are also connected by CANBUS for the purpose of remote diagnosis, measurement, and the like.

[0044] In addition, NWEXT may include devices such as routers and HTTPS proxies, but the description thereof will be omitted. Similarly, NWINT may include devices such as Ethernet switches, but the description thereof will be omitted. Similarly, CANBUS may include devices such as CAN gateways, but the description thereof will be omitted. In the following, the ECU1 of each ECU will be mainly described, and the description of the other ECUs will be omitted.

[0045] In the vehicle control system of this embodiment, monitors and detectors are installed in NWEXT, TCU, NWINT, and CANBUS, and each outputs a log. NWEXT outputs a URL access log, TCU outputs a process startup log (the startup process and its parent process), NWINT outputs an attack communication detection alert log by Ethernet-IDS, and CANBUS outputs an attack communication detection alert log by CAN-IDS.

[0046] An example of an attack on the vehicle control system in this embodiment is shown in FIG. 6. In the example of the attack shown in FIG. 6, an unauthorized command is executed by a Drive by Download attack. First, unauthorized information that attacks the vulnerability of the TCUctrl is embedded in the OEM site. When the TCUctrl accesses the unauthorized information in the TCU (URLOEM), the vulnerability causes an unauthorized process, mal1 process, to be generated and started on the TCU. The mal1 process accesses the attacker site (URLmal), downloads an attack program to the TCU, and generates and starts an unauthorized process, mal2 process, by the attack program. The mal2 process sends an unauthorized CAN message CAN6AA' to the CANBUS (CAN message insertion attack) and causes the ECU1 to execute an unauthorized command.

[0047] Figure 7 shows a graphical representation of the logs that are output during the above attack. NWEXT outputs URL access logs for URLOEM and URLmal, TCU outputs the TCUctrl mal1 startup log and mal1 mal2 startup log, and CANBUS outputs an attack communication detection alert log for CAN6AA'. However, although the NWEXT URL access log shows that access was made from the TCU, it is not possible to identify which TCU process the access was made from. Furthermore, the CANBUS attack communication detection alert log shows that CAN6AA' was used in the attack, but it is not possible to identify the device or process that originated the attack. Note that no logs are output for NWINT as there is no attack communication.

[0048] Under the above circumstances, we trace back from CAN6AA' of CANBUS where the attack was detected and estimate the attack path.

[0049] First, predicted route information is created in advance by the predicted route configuration unit 110. In this embodiment, vehicle configuration information shown in FIG. 8 is created by the vehicle configuration information creation unit 111, and then predicted route information is created from the vehicle configuration information and the expected attack pattern by the predicted route information creation unit 112. The vehicle configuration information shown in FIG. 8 is an adjacency matrix representation of a graph structure relating to each device or process and communication in the vehicle control system shown in FIG. 5. Source (Src.) nodes are assigned to rows, and destination (Dst.) nodes are assigned to columns, and elements between nodes with a relationship (edge) are represented by 1, and elements between nodes with no relationship are represented by 0. Hereinafter, nodes representing processes are also referred to as process nodes, and nodes representing communication are also referred to as communication nodes.

[0050] The assumed attack patterns in this embodiment are set as follows, making it possible to comprehensively assume attack paths. First, in each device and network (i.e., NWEXT, TCU, NWINT, CANBUS) that is the target of log output, a wildcard node is set, which is a node representing a process and communication that is not assumed in the vehicle configuration information (i.e., suspected to be used in an attack). Next, edges to the wildcard node are set along the connection of each device and network. The wildcard node of a process has edges indicating a start relationship with all other process nodes in the device in which the process is executed, and in addition, has edges indicating a communication relationship with all communication nodes on the network connected to the device. The wildcard node of a communication has edges indicating a communication relationship with all process nodes on the device connected to the network in which the communication is performed. A graph showing a predicted path incorporating such comprehensive assumed attack patterns is shown in FIG. 9. Also, information (predicted path information) expressing the graph structure in an adjacency matrix is ​​shown in FIG. 10. The nodes NWEXT, NWEXT, NWINT, and CANBUS are added to each of them. * , T.C.U. * , NWINT * , CANBUS * is a wildcard node. For example, the wildcard node TCU *has a bidirectional edge that indicates a start relationship with the process TCUctrl on the TCU. Furthermore, the TCU is connected to NWEXT, NWINT, and CANBUS, so the communication nodes URLOEM and NWEXT * , IPCGW, NWINT * , CAN6AA, CANBUS * Both are set to have a bidirectional edge that represents a communication relationship.

[0051] Depending on the characteristics of the system, it is possible to omit the wildcard node of a certain device or network, add a wildcard node, or reduce or increase the number of edges connected to the wildcard node. For example, in a device that has very strict mandatory access control and where unauthorized process startup is certainly not possible, it is not necessary to set a wildcard node for the process. Also, if network communications are restricted or controlled by a robust security firewall, it is possible to reduce the number of edges connected to the wildcard node or make them one-way edges in accordance with the restriction or control.

[0052] By using the above method, it is possible to create predicted route information that assumes comprehensive attack patterns.

[0053] Next, the attack path estimation unit 120 estimates an attack path using the predicted path information.

[0054] The weighted predicted route information creation unit 121 acquires attack detection logs and creates observation information from those attack detection logs, adds or overwrites the observation information to the predicted route information, and creates weighted predicted route information using weighting rules. Figure 11 shows the observation information created from the attack detection log when the attack example shown in Figure 6 was detected. URLmal, mal1, mal2, and CAN6AA' are nodes that are not included in the vehicle configuration information, and are respectively the wildcard node NWEXT * , T.C.U. * , CANBUS * The two TCUs mal1 and mal2 are replaced by the TCU *Therefore, the process startup relationship TCUctrl → mal1 → mal2 is replaced by TCUctrl → TCU * is replaced by.

[0055] The following rules 1 to 5 are used as weighting rules for edges of predicted route information.

[0056] Rule 1: Edges that exist in the observation information (startup relationships, communication relationships, etc.) have low cost. Rule 2: Edges with unobserved wildcard nodes are deleted. Rule 3: Edges that exist in the vehicle configuration information are in the middle of the cost Rule 4: Edges between wildcard nodes are medium cost Rule 5: Other edges are more expensive A graph in which predicted route information has been weighted using the above weighting rules is shown in Fig. 12. Information (weighted predicted route information) representing this graph as an adjacency matrix is ​​shown in Fig. 13. In Fig. 12, high cost edges are shown with dashed lines, medium cost edges with solid lines, and low cost edges with thick solid lines. In Fig. 13, high cost is set to 100, medium cost is set to 10, and low cost is set to 1.

[0057] The weighting rules may be changed, added, or deleted according to the characteristics of the system. For example, rules may be added such that the cost of all edges connected to nodes present in the observation information is uniformly reduced, and that the cost of edges with wildcard nodes is reduced for process nodes that perform communication that is susceptible to threats. In addition, when there are multiple CAN buses and attack detection can be performed for each CAN bus, a rule may be added that particularly reduces the cost of edges connected to the CAN bus in which an attack is detected. In addition, in a system where there is a high possibility of failing to detect an attack, the above rule 2 may be deleted. Furthermore, an appropriate value may be set as appropriate for the actual value of the cost. In addition, part of the weighting may be performed in advance by the predicted path configuration unit 110. For example, the weighting according to the above rules 3 to 5 may be performed in advance by the predicted path configuration unit 110, and only the above rules 1 to 2 may be performed by the attack path estimation unit 120 (the weighted predicted path information creation unit 121).

[0058] Next, the route search unit 122 uses the weighted predicted route information to estimate an attack route by tracing back from the CANBUS network in which the CAN-IDS attack communication detection alert occurred. * is set as a target, and the route from other nodes to the target and the score of the route are obtained. The score is calculated by dividing the sum of the costs of the edges in the route by the number of edges in the route. For route search, a shortest route search method such as Dijkstra's algorithm can be used. An example of the route searched in this embodiment is shown in Figs. 14 and 15. In the example shown in Fig. 14, URLOEM→TCLctrl→TCU * →CANBUS * On the other hand, in the example shown in Figure 15, NWEXT * →TCU * →CANBUS * The following attack vectors are being explored. These are the inferred attack vectors.

[0059] A list of attack paths estimated in this embodiment and their scores and costs are shown in Fig. 16. The path search unit 122, for example, selects an appropriate attack path from these attack paths, and outputs attack path information representing the selected attack path to a predetermined output destination. There are various possible methods for selecting an appropriate attack path, and examples of such methods include attack paths with scores within a certain range, and attack paths with scores equal to or above a certain threshold.

[0060] Note that an appropriate score is used depending on the characteristics of the system, etc. For example, the score may be the sum of the costs of the edges in the path divided by the number of nodes in the path, or the transition probability from the start point of the attack path to the end point (detection node, target) may be used as the score.

[0061] In this way, in this embodiment, vehicle configuration information and comprehensive assumed attack patterns are prepared as predicted route information in advance, and weighted predicted route information is then prepared from this predicted route information, the attack detection log, and the weighting rules. This makes it possible to estimate the attack route even if the attack detection log is incomplete.

[0062] In this embodiment, the processes and communications that are the targets of log output are regarded as nodes, but if the target of log output changes, the nodes and edges may be changed accordingly. Examples of nodes include files, system calls, and signals. The graph representation is not limited to an adjacency matrix, and may be expressed in other formats such as a connection matrix, a Laplacian matrix, or a list representation. The graph may also be expressed as a bipartite graph instead of a unipartite graph.

[0063] Example 2 Hereinafter, a description will be given of Example 2. In this example, an attack path is estimated using a known assumed attack pattern.

[0064] In this embodiment, the configuration of the vehicle control system, the monitor / detector and its output log, and the attack example are assumed to be the same as those in the first embodiment.

[0065] As in the first embodiment, vehicle configuration information is created by the vehicle configuration information creation unit 111. Next, predicted route information is created from the vehicle configuration information and the predicted attack pattern by the predicted route information creation unit 112. The predicted attack pattern may be given, for example, as a graph model representing the relationship between threats and vulnerabilities (also called an attack graph), or as indicators of compromise (IoC). The following describes the case where the predicted attack pattern is given as an IoC.

[0066] FIG. 17 shows an example of an IoC and an attack graph representation of the IoC. In the example shown in FIG. 17, the attack graph is represented by an adjacency matrix, and all processes and communications that appear in the IoC are described as nodes, and edges between the associated nodes are set. The IoC and the attack graph are stored in the predicted route information storage unit 130 as predicted route information together with vehicle configuration information. In the IoC in this embodiment, an example is given in which TCUctrl, whose vulnerability is exploited by URLOEM, is not described. This is because, for example, if a library has a vulnerability, all programs that use the library are affected, so the program / process name may not be described in the IoC.

[0067] Next, the attack path estimation unit 120 estimates an attack path using the predicted path information.

[0068] The weighted predicted route information creation unit 121 acquires attack detection logs and creates observation information from the attack detection logs. The weighted predicted route information creation unit 121 also acquires an attack graph that expresses an IoC that best matches the attack detection logs from the predicted route information storage unit 130. The weighted predicted route information creation unit 121 then adds or overwrites the observation information and the attack graph to the vehicle configuration information, and creates weighted predicted route information using weighting rules. Here, the following rules 1 to 4 are used as weighting rules for edges of the predicted route information. Note that, as in the first embodiment, the weighting rules may be changed, added, or deleted depending on the characteristics of the system, etc.

[0069] Rule 1: Edges that exist in the observation information (startup relationships, communication relationships, etc.) have low cost. Rule 2: Edges in the attack graph that are not observed have a cost of Rule 3: Edges that exist in the vehicle configuration information are in the middle of the cost Rule 4: Other edges are expensive Fig. 18 shows a graph in which predicted route information has been weighted using the above weighting rules. Fig. 19 shows information (weighted predicted route information) expressing this graph as an adjacency matrix. In Fig. 18, high cost edges are shown with dashed lines, medium cost edges with solid lines, and low cost edges with thick solid lines. In Fig. 19, high cost is set as 100, medium cost as 10, and low cost as 1. Note that there are no high cost edges in Figs. 18 and 19.

[0070] Thereafter, similarly to the first embodiment, the route search unit 122 may use this weighted predicted route information to estimate an attack route by tracing back from the CANBUS network where the CAN-IDS attack communication detection alert occurred.

[0071] Example 3 Hereinafter, a third embodiment will be described. As the third embodiment, the comprehensive assumed attack pattern of the first embodiment may be combined with the known assumed attack pattern of the second embodiment. For example, in the second embodiment, when mal2 and CAN6AA' are not included in the known assumed attack pattern (when the IoC matches No. 2 in FIG. 17), they are instead included in the wildcard node TCU * and CANBUS * An example of a graph represented by weighted predicted path information when a comprehensive predicted attack pattern and a known predicted attack pattern are used is shown in Fig. 20. Thereafter, similarly to the first and second embodiments, the path search unit 122 can estimate an attack path using this weighted predicted path information.

[0072] Example 4 A fourth embodiment will be described below. In this embodiment, a case where an attack path is estimated only by network monitoring without process monitoring will be described. The configuration of the vehicle control system, examples of attacks, and conditions for attack detection are assumed to be the same as those in the first embodiment.

[0073] 21 shows a graph of the predicted route information created by the predicted route information creation unit 112. Unlike the first embodiment, since process monitoring is not performed, the processes TCUctrl and TCU * There is no node, instead the TCU itself is the node, and the node TCU is the node URLOEM, NWEXT * , IPCGW, NWINT * , CAN6AA, CANBUS * and has an edge.

[0074] FIG. 22 shows a graph in which the predicted route information is weighted according to the same weighting rule as in the first embodiment when an attack is detected. FIG. 23 shows information (weighted predicted route information) in which this graph is expressed as an adjacency matrix. Furthermore, the shortest route search method is used to find the detected node CANBUS * Figure 24 shows the routes (estimated attack routes) searched backwards from the attack origin, along with their scores and costs.

[0075] Here, since process monitoring is not performed, it is possible that the attack path may not be estimated. * When searching (estimating) a route by tracing back from the target node, a multiple route search method that applies the shortest route search method is used. The attack routes (estimated attack routes) searched for by the multiple route search method, along with their scores and costs, are shown in FIG. 25. In the multiple route search method of this embodiment, a shortest route search is performed from each node one edge back from the target node. In FIG. 22, the target node is the detection node CANBUS * Then, the shortest path search is performed from the nodes TCU and CGW, which are one edge back from the node.

[0076] In Figure 25, among the routes with the same start and end points, the route via the CGW has a smaller score, but the route via the TCU has a smaller cost. In such a case, both routes are considered as attack route candidates, and the route is confirmed by conducting additional investigations, such as digital forensics. This allows the investigation and estimation of attack routes to be performed without omission.

[0077] Example 5 A fifth embodiment will be described below. A log observed for a long period of time may contain multiple attack communication detection alerts. For this reason, when such a log is acquired as an attack detection log, it may be difficult to estimate the attack route. Therefore, when a log observed for a long period of time is acquired as an attack detection log, the attack detection log may be appropriately divided, and the present embodiment may be applied to each of the divided logs.

[0078] Methods for dividing attack detection logs include, for example, extracting a specific period before and after an attack communication detection alert, dividing using a clustering method, etc. In addition, when the same alert occurs consecutively, in order to improve the accuracy of estimating the attack path, for example, the same alerts may be combined into one representative, or alerts other than the start and end of the period in which the same alert occurs consecutively may be deleted before dividing.

[0079] [Second embodiment] The second embodiment will be described below. Note that in the second embodiment, differences from the first embodiment will be mainly described, and descriptions of components that may be the same as those in the first embodiment will be omitted.

[0080] <Prize money and weighted predicted route> In the first embodiment described above, for example, if an attack path is estimated using a shortest path search method for a path that passes through a gateway or a proxy process, a path that does not pass through that gateway or proxy process (i.e., a shortcut path) may be estimated, which may reduce the accuracy of the attack path estimation.

[0081] As an example, consider the weighted predicted path shown in Fig. 26. The weighted predicted path shown in Fig. 26 is obtained by adding / overwriting the observed information created from the attack detection log to the predicted path information of the ECU having the "Proxy process", and then weighting it using the weighting rule. In the example shown in Fig. 26, "1" to "4" represent the node numbers, and "a" to "c" represent the weights (positive values).

[0082] Here, it is assumed that "2: Proxy process" can detect malicious communication with "1: Malware NW" (i.e., malicious communication of edge 1-2 between node numbers "1" and "2"), and that a security audit function (e.g., IDS, etc.) can detect the start of "4: Malware process." In this case, there are two possible communication routes between "4: Malware process" and "1: Malware NW": "node number "1" → node number "2" → node number "3" → node number "4"" via "2: Proxy process," and "node number "1" → node number "4"" which is a direct communication route.

[0083] When malicious communication occurs via the "2:Proxy process", consider whether the attack path "Node number "1" → Node number "2" → Node number "3" → Node number "4"" is the shortest path (i.e., the sum of the weights of the path is the smallest). As shown in Figure 26, the weights are three types of positive values. Let the weight of edge 1-2 where the attack communication detection alert occurred be a, the weight of edge 2-3 where the communication was observed be b, and the weights of the other edges be c.

[0084] For the attack path "Node number "1" → Node number "2" → Node number "3" → Node number "4"" to be the shortest path, the sum of the weights of this path a + b + c must be smaller than the sum of the weights of the direct communication path "Node number "1" → Node number "4"", which is c. That is, it is necessary to satisfy a + b + c < c. However, since a, b, and c are all positive values, a + b + c < c cannot be satisfied. In this case, the direct communication path "Node number "1" → Node number "4"" (i.e., the shortcut path) will be estimated as the attack path.

[0085] Thus, for example, when estimating the attack path by the shortest path search method for a path passing through a gateway or proxy process, the shortcut path may be estimated, and the estimation accuracy of the attack path may decrease.

[0086] Therefore, in the second embodiment, in addition to the weights for the edges, a value called a prize is assigned to the nodes, and the Prize Collecting Traveling Salesman Problem (PCTSP) is applied to the non-cyclic path search problem to estimate the attack path. For the details of PCTSP, for example, refer to Reference 1 etc.

[0087] As an example, consider the bounty and weighted predicted path shown in Fig. 27. The bounty and weighted predicted path shown in Fig. 27 are obtained by assigning bounties to nodes in the weighted predicted path shown in Fig. 26 in response to an attack traffic detection alert. In the example shown in Fig. 27, bounty "A" has been assigned to nodes with node numbers "1," "2," and "4," and bounty "B" has been assigned to node with node number "3."

[0088] At this time, by searching for a route that minimizes the score calculated from the weight and the prize money, it is possible to estimate a route that is not a shortcut as an attack route.

[0089] For example, the score is defined as follows:

[0090] Score: = (sum of weights (costs) of all edges in the path) - (sum of bounties of all nodes in the path) For example, in the prize money-weighted predicted path shown in Figure 27, in order for "node number "1" → node number "2" → node number "3" → node number "4"" to be estimated as an attack path, the score of the path "node number "1" → node number "2" → node number "3" → node number "4"" must be smaller than the score of the path "node number "1" → node number "4". Therefore, the condition for "node number "1" → node number "2" → node number "3" → node number "4"" to be estimated as an attack path is a+b+c-3A-B <c-2A、すなわちa+b-A-B<0となる。

[0091] Therefore, by setting the bounties A and B appropriately, it is possible to estimate the route “Node number “1” → Node number “2” → Node number “3” → Node number “4”” as the attack route.

[0092] In the examples shown in Figures 26 and 27, a case is described in which a proxy exists, but this is just one example, and the same applies to cases in which an aggregation point such as a gateway, firewall, tunnel, etc. exists.

[0093] <Application of PCTSP to the problem of searching non-circular routes> The problem of searching for a route that can maximize the total prize money of nodes while keeping the total cost of edges as low as possible is known as the Prize-Catching Traveling Salesman Problem (PCTSP). Although this problem is NP-hard, several methods for solving it have been proposed, and a commonly used method is to convert the problem into a mixed integer linear programming problem (MIP: Mixed Integer Programming) and solve it. Examples of software that can solve MIP include MATLAB (registered trademark), Mathematica, and Gurobi.

[0094] Although PCTSP searches for circular routes, the attack route to be estimated in this embodiment is not a circular route, but a one-way route (non-circular route) with a start point and an end point. Therefore, PCTSP is applied to the problem of searching for non-circular routes. For example, it can be used to estimate an attack route by converting it into the following MIP.

[0095] Objective function The objective function is the score of a path graph, i.e., score = (sum of weights of all edges included in the path) - (sum of bounties of all nodes included in the path). The path that minimizes this objective function is the estimated attack path.

[0096] ·Restrictions The following four constraints are used to travel from a starting point to a destination point while visiting a city only once.

[0097] 1. Move from one city to another (OUT) 2. Moving to one city from one of the other cities (IN) 3. The start point and end point exist (end point) 4. Eliminate routes (subtours) that are not start or end points Here, a city represents a node in the prize-weighted predicted path.

[0098] The above MIP will now be specifically formulated.

[0099] <Formulation of one-way PCTSP into MIP> We explain how to formulate a PCTSP in which both the start point and the end point are specified (we will call this a "one-way PCTSP") into an MIP.

[0100] Let i denote the node number of a node included in the prize money and weighted predicted route, and let the node (city) with node number i be called "city i". For simplicity, let i=1 be the node number of the starting city, and i=n be the node number of the ending city. Furthermore, let each variable be defined as follows:

[0101] X ij : A variable that takes the value 1 if there is movement from city i to city j, and 0 if there is no movement Y i : A variable that takes the value 1 if the city i is passed through and 0 if it is not passed through. U i : The order in which city i was passed on the route However, the order of the starting points is U 1 =0, end point order U n =n-1.

[0102] In this case, the objective function is defined as follows:

[0103]

number

[0104] In addition, the constraints are defined as follows:

[0105]

number

[0106] <Formulation of one-way PCTSP without starting point into MIP> Instead of a "single-way PCTSP" where both the start and end points are specified, a PCTSP where only the end point is specified (which will be called a "single-way PCTSP without a start point"). Below, we explain how to formulate a single-way PCTSP without a start point into an MIP.

[0107] In the one-way PCTSP without a starting point, the objective function is the same as in the one-way PCTSP, but the constraints are defined as follows:

[0108]

number

[0109] Using the one-way PCTSP without a starting point, for example, it is possible to simultaneously estimate the source of an attack in addition to the attack path.

[0110] <Formulation of unspecified one-way PCTSP into MIP> Instead of a "single-way PCTSP" in which both the start and end points are specified, a PCTSP in which neither the start nor end point is specified (which will be called an "unspecified single-way PCTSP" in this section) may be used. Below, we explain how to formulate an unspecified single-way PCTSP into an MIP.

[0111] In unspecified one-way PCTSP, the objective function is the same as in one-way PCTSP, but the constraints are defined as follows:

[0112]

number

[0113] With unspecified one-way PCTSP, for example, in addition to the attack path, it is possible to simultaneously estimate the source and target of the attack.

[0114] <Other> In the above "one-way PCTSP", "one-way PCTSP without starting point" and "one-way PCTSP without designation", if there is a city (node) that you want to include in the route, Y i For Y i A constraint of =1 may be added.

[0115] Hereinafter, as an attack path estimation device 10 according to the second embodiment, we will explain the attack path estimation device 10 that creates a bounty-weighted predicted path and then estimates an attack path using "one-way PCTSP", "one-way PCTSP without a starting point", or "one-way PCTSP without a designation".

[0116] <Hardware Configuration of Attack Path Estimation Device 10> An example of the hardware configuration of the attack path estimation device 10 according to the second embodiment may be similar to that of the first embodiment, and therefore a description thereof will be omitted.

[0117] <Functional configuration of the attack path estimation device 10> An example of a functional configuration of the attack path estimation device 10 according to the second embodiment is shown in Fig. 28. As shown in Fig. 28, the attack path estimation unit 120 of the attack path estimation device 10 according to the second embodiment includes a prize money / weighted predicted path information creation unit 123 instead of the weighted predicted path information creation unit 121.

[0118] The prize money / weighted predicted route information creating unit 123 acquires attack detection logs and creates attack observation information using the attack detection logs, and then adds or overwrites the observation information to the predicted route information. The prize money / weighted predicted route information creating unit 123 also weights the edges of the predicted route information after addition or overwriting using prize money / weighting rules, and gives prize money to the nodes to create the prize money / weighted predicted route information.

[0119] As a result, multiple attack paths can be estimated in the complementation portion as in the first embodiment, but by weighting edges and awarding prizes to nodes, it becomes possible to estimate a more likely attack path than in the first embodiment. Note that the prize value is increased as the association with an attack communication detection alert becomes stronger. Also, for example, part of the weight and part of the prize may be awarded in advance by the predicted route configuration unit 110 (particularly the vehicle configuration information creation unit 111).

[0120] Furthermore, the route search unit 122 estimates an attack route by performing route search using "single road PCTSP", "single road PCTSP without a starting point" or "unspecified single road PCTSP" using bounty and weighted predicted route information. At this time, when performing route search using "single road PCTSP" or "single road PCTSP without a starting point", the route search unit 122 performs route search backwards from the detection node with the detection node as the end point. Note that, similar to the first embodiment, attack route information indicating the estimated attack route is output to a specified output destination.

[0121] <Predicted route information creation process> The predicted route information generating process according to the second embodiment is similar to that of the first embodiment, and therefore a description thereof will be omitted.

[0122] <Attack route estimation process> The attack path estimation process according to the second embodiment will be described with reference to Fig. 29. Note that the attack path estimation process is executed every time an attack is detected in the vehicle control system.

[0123] The prize money and weighted predicted path information creation unit 123 of the attack path estimation unit 120 acquires attack detection logs and creates attack observation information using the attack detection logs, adds or overwrites the observation information to the predicted path information, and creates prize money and weighted predicted path information using the prize money and weighting rules (step S301).

[0124] The path search unit 122 of the attack path estimation unit 120 performs a path search using the prize money / weighted predicted path information with "one-way PCTSP", "one-way PCTSP without starting point" or "one-way PCTSP without designation" to estimate an attack path, and outputs the attack path information representing the estimated attack path to a predetermined output destination (step S302). At this time, the path search unit 122 may output the most likely attack path information from among the multiple attack path information based on the score, or may output the multiple attack path information and their scores.

[0125] <Prize money and weighting rules> Here we explain an example of the prize and weighting rules for determining the prize and weighting values ​​of the prize and weighted predicted path information. For example, the prize and weighting values ​​are determined as follows for three types of locations: locations where an attack traffic detection alert occurred, locations where an attack traffic detection alert did not occur but where process startup or communication was observed, and other locations.

[0126] - Location where attack traffic detection alert occurred A bounty of "A" is assigned to the node, and a weight of "a" is assigned to the edge. - Locations where no attack traffic detection alerts were issued but where process startup or communications were observed A bounty of "B" is assigned to the node, and a weight of "b" is assigned to the edge. Other areas No bounty is assigned to nodes (i.e., “0”), and weight “c” is assigned to edges. Here, c≧b≧a>0, A>0, and B>0.

[0127] Here, an example of a method for setting the values ​​of the prizes A and B when a, b, and c are determined will be described below.

[0128] As an example, consider the predicted route shown in Fig. 30. The predicted route shown in Fig. 30 is the predicted route after observation information has been added and overwritten.

[0129] Here, assume that "2:Proxy process" can detect malicious communication with "2:Marlware NW" (i.e., malicious communication on the edge 1-2 between node numbers "1" and "2"), and a security audit function (e.g., IDS, etc.) can detect the activation of "4:Malware process". At this time, the communication path between "4:Malware process" and "1:Malware NW" can be of two types: the path "node number "1" → node number "2" → node number "3" → node number "4"" via "2:Proxy process" (hereinafter referred to as attack path 1), and the path of direct communication "node number "1" → node number "4"" (hereinafter referred to as attack path 2).

[0130] When an attack is carried out on attack path 1, the bounty / weight is assigned as shown in Figure 31. Therefore, in this case, since the score of attack path 1 < the score of attack path 2 is required, it is necessary that a + b + c - 3A - B < c - 2A. Thus, the following (Equation 1) is obtained.

[0131] a + b - A - B < 0 (Equation 1) On the other hand, when an attack is carried out on attack path 2, the bounty / weight is assigned as shown in Figure 32. Therefore, in this case, since the score of attack path 1 > the score of attack path 2 is required, it is necessary that b + 2c - 2A - 2B > c - 2A. Thus, the following (Equation 2) is obtained.

[0132] b + c - 2B > 0 (Equation 2) When the above (Equation 1) and (Equation 2) are sorted out, the following (Equation 1') and (Equation 2') are obtained.

[0133] B < (b + c) / 2 (Equation 2') A > a + b - B (Equation 1') From the above, it can be seen that the bounties A and B may be set to satisfy the above (Equation 1') and (Equation 2'). In this way, in a 4-node graph, the setting range of the bounty can be derived from the score inequalities of each of the two paths.

[0134] <Summary> As described above, the attack path estimation device 10 according to the first and second embodiments creates predicted path information expressed in a discrete graph from vehicle configuration information and assumed attack patterns in advance, creates weighted predicted path information (or prize money / weighted predicted path information) from the attack detection log and weighting rule (or prize money / weighting rule) obtained at the time of attack detection, and performs a route search for the weighted predicted path information (or prize money / weighted predicted path information) by tracing back from the attack detection node, thereby estimating the attack path. This makes it possible to estimate the attack path even if there is data loss in the log (attack detection log) obtained at the time of attack detection. Therefore, for example, when an attack on a vehicle control system is detected, it becomes possible to efficiently analyze the scope of the impact, etc.

[0135] In the above-mentioned embodiments, a vehicle control system has been described as an example, but the present invention is not limited thereto, and the above-mentioned embodiments may be applied to other communication systems having a communication function, such as a machine control system, etc. For example, the above-mentioned embodiments may be applied to a communication system configured with industrial control devices such as robots in a factory, sensors arranged in various locations, audio devices, home appliances, information processing terminals (smartphones, tablet terminals, etc.), devices generally referred to as IoT devices, etc.

[0136] In addition, examples of attack detection logs that can be used include alert logs from network attack detection functions such as CAN-IDS and in-vehicle Ethernet IDS, communication rejection logs and communication statistics logs from CAN communication gateways and IP firewalls, system logs from OS (Operating System) security audits on ECUs and terminals, and application logs such as malware scan reports from anti-virus software and proxy server access logs.

[0137] The present invention is not limited to the above-described embodiments specifically disclosed, and various modifications, changes, combinations with known technologies, etc. are possible without departing from the scope of the claims.

[0138] This application is based on the basic application PCT / JP2022 / 020883 filed in Japan on May 19, 2022, the entire contents of which are incorporated herein by reference.

[0139] [References] Reference 1: E. Balas, "The prize collecting traveling salesman problem," Networks vol. 19, pp. 621-636, 1989. Reference 2: CE Miller, AW Tucker, and RA Zemlin, "Integer Programming Formulation of Traveling Salesman Problems.", J. ACM, Vol. 7, issue 4, pp. 326-329, 1960. [Explanation of symbols]

[0140] 10. Attack Path Estimation Device 101 Input Device 102 Display device 103 External I / F 103a Recording media 104 Communication I / F 105 RAM 106 ROM 107 Auxiliary storage 108 processors 109 Bus 110 Predicted route configuration section 111 Vehicle Configuration Information Creation Department 112 Predicted Route Information Creation Department 120 Attack Path Estimation Department 121 Weighted predicted route information creation unit 122 Route Search Unit 130 Predicted route information storage unit

Claims

1. An attack path estimation system for estimating an attack path in a target system, comprising: a configuration information creation unit configured to create configuration information representing a configuration of the target system using at least one of design information and an operation history log of the target system; a predicted path information creation unit configured to create predicted path information representing a predicted path of an attack against the target system by using the configuration information and an attack pattern assumed in the target system; a weighted predicted route information creation unit configured to create weighted predicted route information by weighting the predicted route information using a log acquired from the target system and a predetermined weighting condition when an attack on the target system is detected; a route search unit configured to estimate an attack route representing a route from a source of the attack to a destination of the attack by route search on the weighted predicted route information; An attack path estimation system having the above configuration.

2. The weighted predicted route information generating unit When an attack on the target system is detected, generating observation information indicating an observation path of the attack using a log acquired from the target system; 2. The attack path estimation system according to claim 1, configured to add and overwrite the observed information to the predicted path information, and then create weighted predicted path information by weighting the predicted path information after the addition and overwriting using the weighting conditions.

3. The configuration information creation unit a configuration information generating unit configured to generate the configuration information representing a configuration of the target system in a graph structure by using at least one of the design information and the operation history log; The predicted route information creation unit the attack pattern represented in a graph structure is added to the configuration information to generate the predicted path information represented in a graph structure, The weighted predicted route information generating unit 3. The attack path estimation system according to claim 1 or 2, configured to create the weighted predicted path information by applying weights to edges of a graph represented by the predicted path information using the log and the weighting conditions.

4. The route search unit is The attack path estimation system according to claim 3, configured to estimate the attack path by performing the path search backwards from the attack destination, the path being determined as the attack destination, the node representing the process, device, or communication where the attack was detected.

5. The route search unit is Calculating a score for the attack path using weights assigned to edges included in the attack path; The attack path estimation system according to claim 4 , wherein when a plurality of attack paths are estimated, one or more attack paths are output from among the plurality of attack paths to a predetermined output destination using the score.

6. The predicted route information creation unit a predetermined prize awarding condition is further used to assign weights to edges of a graph represented by the predicted route information, and prize / weighted predicted route information is created by assigning prizes to nodes of the graph, The route search unit is 6. The attack path estimation system according to claim 5, configured to estimate the attack path by performing a route search on the bounty / weighted predicted route information using weights assigned to edges included in the attack path and bounties assigned to nodes included in the attack path.

7. The route search unit is 7. The attack path estimation system according to claim 6, which is configured to estimate the attack path by solving a problem obtained by applying a bounty-winning traveling salesman problem to a non-circular route.

8. An attack path estimation device that estimates an attack path in a target system, a configuration information creation unit configured to create configuration information representing a configuration of the target system using at least one of design information and an operation history log of the target system; a predicted path information creation unit configured to create predicted path information representing a predicted path of an attack against the target system by using the configuration information and an attack pattern assumed in the target system; a weighted predicted route information creation unit configured to create weighted predicted route information by weighting the predicted route information using a log acquired from the target system and a predetermined weighting condition when an attack on the target system is detected; a route search unit configured to estimate an attack route representing a route from a source of the attack to a destination of the attack by route search on the weighted predicted route information; An attack path estimation device having the above configuration.

9. An attack path estimation method for estimating an attack path in a target system, comprising: a configuration information creation step of creating configuration information representing a configuration of the target system by using at least one of design information and an operation history log of the target system; a predicted path information creating step of creating predicted path information representing a predicted path of an attack against the target system by using the configuration information and an attack pattern assumed in the target system; a weighted predicted route information creating step of creating weighted predicted route information by weighting the predicted route information using a log acquired from the target system and a predetermined weighting condition when an attack on the target system is detected; a route search step of estimating an attack route representing a route from the source of the attack to the destination of the attack by route search on the weighted predicted route information; A method for estimating an attack path performed by a computer.

10. A program for estimating an attack path in a target system, a configuration information creation step of creating configuration information representing a configuration of the target system by using at least one of design information and an operation history log of the target system; a predicted path information creating step of creating predicted path information representing a predicted path of an attack against the target system by using the configuration information and an attack pattern assumed in the target system; a weighted predicted route information creating step of creating weighted predicted route information by weighting the predicted route information using a log acquired from the target system and a predetermined weighting condition when an attack on the target system is detected; a route search step of estimating an attack route representing a route from the source of the attack to the destination of the attack by route search on the weighted predicted route information; A program that causes a computer to execute the following.

Images