System design device, system design method, and program

Abstract

The present invention acquires first configuration information including topology information that uses any one component of nodes in a computer system and edges indicating the relationship among the nodes. The topology configuration in the first configuration information is embodied. A determination is made as to whether an event could occur that would constitute a security threat at a node or an edge in the embodied topology configuration, and if an event that would constitute a threat could occur, configuration information is generated, the configuration information including the addition of information indicating the relationship between a component in which the given threat could occur and another component in which another threat contributing to the occurrence of the given threat could occur. For a path of a chain of threats based on the relationship between a given threat in the configuration information and other threats contributing to the occurrence of the given threat, the contents of each threat are determined to be concrete or abstract, and a determination is made as to whether the design is secure or not for a case in which the contents of the threat are concrete and for a case in which the contents of the threat are abstract.

Description

System design device, system design method, and storage medium

[0001] The present disclosure relates to a system design device, a system design method, and a storage medium.

[0002] Non-Patent Documents 1 and 2 disclose techniques for automatically designing a secure system configuration. This technique first generates multiple system configuration plans, evaluates the security of each system configuration plan, and extracts and outputs system configuration plans that are evaluated as secure. The generated system configuration plans are specific system configurations, and security evaluation is performed based on the specific system configurations.

[0003] Lukas Gressl, Christian Steger, and Ulrich Neffe. “Design Space Exploration for Secure IoT Devices and Cyber-Physical Systems.” ACM Transactions on Embedded Computing Systems (TECS) 20.4 (2021): 1-24.SE Ooi, R. Beuran, T. Kuroda, T. Kuwahara, R. Hotchi, N. Fujita, Y. Tan, “Intent-Driven Secure System “Design: Methodology and Implementation”, submitted to Elsevier Computers & Security, March 15 2002.

[0004] The automated system configuration design technology exemplified in Non-Patent Document 1 requires repeated generation and evaluation of system configuration plans to search for a system configuration plan that satisfies the conditions, which takes a long time to derive a solution. In addition, it is difficult to derive a secure system configuration by performing security evaluation using a method similar to that described in the document.

[0005] The secure system automated design technology exemplified in Non-Patent Document 2 is designed to subject a system configuration plan made up of only specific elements to a security assessment when the configuration plan is generated, and any configuration plan determined to be insecure is rejected and the search for another configuration plan is resumed, while any configuration plan determined to be not insecure is adopted as the final output result. As a result, security assessment cannot be performed until the automatic design of the system configuration plan is completed, which results in the generation of a large number of insecure configuration plans that are rejected, and it takes a long time to derive a secure system configuration.

[0006] The present disclosure aims to provide a system design device, a system design method, and a storage medium that improve upon the above-mentioned documents.

[0007] According to a first aspect of the present disclosure, a system design apparatus includes an acquisition means for acquiring first configuration information including at least information about a topology of a computer system using components in the computer system; a configuration instantiation means for generating second configuration information that instantiates a configuration of the topology in the first configuration information; and a threat instantiation means for determining whether or not an event that poses a security threat may occur in the components of the instantiated topology, and, if an event that poses a threat may occur, generating third configuration information by adding to the second configuration information an identifier of the threat, the component where the threat may occur, identifiers of other threats that contribute to the occurrence of the threat, and information indicating a relationship between the other component where the other threat may occur. and an analysis means for determining whether the content of each threat is concrete or abstract in a threat chain path based on the relationship between the threat in the third configuration information and other threats that contribute to the occurrence of the threat, and for determining whether the design of the computer system of the third configuration information is insecure when the content of the threat is concrete or abstract, wherein the analysis means determines that the design of the computer system of the third configuration information is insecure when the content of the threat is all concrete in the threat chain path, or when the content of the threat is abstract in any component of the threat chain path but it is determined that there is no means to prevent the abstract threat from being replaced with a concrete threat.

[0008] According to a second aspect of the present disclosure, a system design method includes acquiring first configuration information including at least information about a topology of a computer system using components in the computer system, generating second configuration information that embodies a configuration of the topology in the first configuration information, determining whether an event that poses a security threat may occur in the components of the embodied topology, and, if an event that poses a threat may occur, generating third configuration information by adding to the second configuration information an identifier of the threat, the components in which the threat may occur, identifiers of other threats that contribute to the occurrence of the threat, and information indicating a relationship between the other components in which the other threats may occur. Then, in the threat chain path based on the relationship between the threat in the third configuration information and other threats that contribute to the occurrence of the threat, it is determined whether the content of each threat is concrete or abstract, and in cases where the content of the threat is concrete or abstract, it is determined whether the design of the computer system of the third configuration information is insecure, and if the content of the threat is all concrete in the threat chain path, or if the content of the threat is abstract in any component of the threat chain path but it is determined that there is no way to prevent the abstract threat from being replaced with a concrete threat, it is determined that the design of the computer system of the third configuration information is insecure.

[0009] According to a second aspect of the present disclosure, a program or a recording medium storing the program includes: an acquisition unit for acquiring first configuration information including at least information about the topology of a computer system using components in the computer system; a configuration instantiation unit for generating second configuration information that instantiates the topology configuration in the first configuration information; and a determination unit for determining whether or not an event that poses a security threat may occur in the components of the instantiated topology, and, if an event that poses a threat may occur, adding to the second configuration information information indicating a relationship between the identifier of the threat, the component in which the threat may occur, the identifier of another threat that contributes to the occurrence of the threat, and the other component in which the other threat may occur. The third configuration information is made to function as a threat concretization means for generating third configuration information, and an analysis means for determining whether the content of each threat is concrete or abstract in a threat chain path based on the relationship between the threat in the third configuration information and other threats that contribute to the occurrence of the threat, and for cases where the content of the threat is concrete or abstract, determining whether the design of the computer system of the third configuration information is insecure, and the analysis means determines that the design of the computer system of the third configuration information is insecure if the content of the threat is all concrete in the threat chain path, or if the content of the threat is abstract in any component of the threat chain path but it is determined that there is no means to prevent the abstract threat from being replaced with a concrete threat.

[0010] According to the present invention, a system design device, a system design method, and a storage medium are provided that can efficiently output design results for system configurations that embody system requirements entered by a user in computer system design and that are not determined to be non-secure.

[0011] 1 is a schematic block diagram showing a functional configuration of a system design device according to the present embodiment. FIG. 2 is a diagram showing an example of system requirements according to the present embodiment. FIG. 3 is a diagram showing an overview of processing by the system design device according to the present embodiment. FIG. 4 is a diagram explaining nodes, edges, and threats displayed on a GUI according to the present embodiment. FIG. 5 is a diagram showing a specific example of first configuration information according to the present embodiment. FIG. 6 is a diagram showing a description example of topology concretization rules according to the present embodiment. FIG. 7 is a diagram showing a description example of threat concretization rules according to the present embodiment. FIG. 8 is a first diagram showing a processing flow of the system design device according to the present embodiment. FIG. 9 is a second diagram showing a processing flow of the system design device according to the present embodiment. FIG. 10 is a diagram showing a specific example of second configuration information according to the present embodiment. FIG. 11 is a first diagram showing a specific example of third configuration information according to the present embodiment. FIG. 12 is a second diagram showing a specific example of the third configuration information according to the present embodiment. FIG. 13 is a first diagram for explaining details of processing S3 of an analysis unit according to the present embodiment. FIG. 14 is a second diagram for explaining details of processing S3 of an analysis unit according to the present embodiment. FIG. 15 is a diagram for explaining details of processing S4 of an analysis unit according to the present embodiment. FIG. 16 is a hardware configuration diagram of a system design device according to the present embodiment. FIG. 17 is a diagram showing a minimum configuration of a system design device according to the present embodiment.

[0012] Fig. 1 is a schematic block diagram showing the functional configuration of a system design device according to this embodiment. The system design device 100 shown in Fig. 1 automatically designs a highly secure computer system. The system design device 100 has the functions of an input / output unit 11, a configuration instantiation unit 12, a threat instantiation unit 13, and an analysis unit 14. These functions are implemented in the computer of the system design device 100 by the system design device 100 executing a system design program.

[0013] The input / output unit 11 receives input of first configuration information including information on system requirements and information on threats to be avoided from a user, transmits this to the configuration instantiation unit 12, and outputs the received configuration information as a processing result from the configuration instantiation unit 12. The first configuration information includes at least information on the topology of the computer system using any of the components of nodes and edges that indicate relationships between the nodes in the computer system.

[0014] The configuration instantiation unit 12 divides the system requirements into multiple steps and instantiates them in stages, generating the resulting configuration information. For example, the configuration instantiation unit 12 generates second configuration information that instantiates the topology configuration of the computer system by adding nodes or edges of the computer system in the first configuration information. There are two forms of instantiation of the topology configuration by the configuration instantiation unit 12. The first form of instantiation involves adding elements that instantiate the configuration. The second form of instantiation involves selecting a specific type of configuration. The configuration instantiation unit 12 generates configuration information that instantiates the configuration of each topology included in the configuration information in accordance with predetermined rules.

[0015] The threat concretization unit 13 determines whether an event posing a threat to the security of the computer system may occur at a node or edge indicated by the concretized topology configuration. When an event posing a threat may occur, the threat concretization unit 13 generates third configuration information by adding to the configuration information an identifier of the threat, a component in which the threat may occur, identifiers of other threats that contribute to the occurrence of the threat, and information indicating the relationship between the other components in which the other threats may occur. The threat concretization unit 13 performs the process of generating such third configuration information by dividing it into a threat concretization process S0, a threat abstraction level determination process S1, and a threat concretization relationship description process S2.

[0016] After performing the threat concretization process S0, the threat concretization unit 13 determines whether all threats present in the received configuration information are abstract or concrete in the threat abstraction determination process S1. Based on this determination, the threat concretization unit 13 labels each threat as abstract or concrete, and then performs the threat concretization relationship description process S2.

[0017] In the threat concretization relationship description process S2, the threat concretization unit 13 adds information (hereinafter referred to as "threat refinement relationship") to the received configuration information regarding which threats are concretized from which threats for all threats involved in the threat concretization rules applied by the threat concretization unit 13.

[0018] The analysis unit 14 determines whether the content of each threat is concrete or abstract in a threat chain path based on the relationship between a threat in the second configuration information and other threats that contribute to the occurrence of that threat. The analysis unit 14 determines whether the design of the computer system in the first configuration information is insecure when the content of the threat is concrete or abstract. The analysis unit 14 determines that the design of the computer system in the third configuration information is insecure when all the content of the threats in the threat chain path is concrete, or when the content of the threat is abstract in any component of the threat chain path but it is determined that there is no means of avoiding replacing the abstract threat with a concrete threat. In performing this processing, the analysis unit 14 performs a process S3 of investigating specific threat generation avoidance candidates, a process S4 of investigating attack path concretization avoidance means, and a security determination process S5.

[0019] When a threat that is the starting point of an attack is connected to a threat that is the end point of the attack by a chain route of threats, the analysis unit 14 determines that an "attack path" has been generated. After updating the information on the threat concreteization relationship of the threat in the configuration information, the analysis unit 14 performs a process S3 of investigating concrete threat generation and avoidance candidates.

[0020] In the specific threat generation avoidance candidate investigation process S3, the analysis unit 14 investigates whether all abstract threats in the received configuration information have the potential to become specific threats in the future. Then, using the configuration information and the results of this investigation, the analysis unit 14 performs the attack path concretization avoidance means investigation process S4.

[0021] In the process S4 of investigating means for avoiding concretization of attack paths, the analysis unit 14 determines whether there is an attack path in the received configuration information in which at least one abstract threat exists among the threats constituting a chained route (hereinafter referred to as "abstract attack path"), and if so, investigates whether there is a means for preventing the path from changing into an attack path that constitutes a chained route consisting only of concrete threats (hereinafter referred to as "concrete attack path") in the future (hereinafter referred to as "concrete attack path").The analysis unit 14 then performs the security assessment process S5 using the results of this investigation together with the configuration information.

[0022] In the security determination process S5, if the received configuration information contains a specific attack path or an abstract attack path whose realization cannot be avoided in the future, the analysis unit 14 determines the configuration draft to be "unsecure." Conversely, if there is no specific attack path and there is an abstract attack path but there is a means to avoid its realization, the analysis unit 14 determines the configuration draft to be "unsecure." If the analysis unit 14 determines that the configuration information "cannot be determined to be unsecure," it outputs the determination result together with the configuration information to the configuration instantiation unit 12. If the analysis unit 14 determines that the configuration information is "unsecure," it rejects the configuration information and outputs information indicating the rejection to the configuration instantiation unit 12.

[0023] FIG. 2 is a diagram showing an example of system requirements entered by a user. A user performing automated design of a computer system enters the system requirements using the interface of the system design device 100. As an example, the system design device 100 outputs a GUI (Graphical User Interface) screen to a display. This GUI screen displays options for selecting nodes and edges. The user uses an input device connected to the system design device 100 to select nodes and edges from the options displayed on the GUI screen. Note that the nodes and edges correspond to nodes and edges in graph theory, and the concepts of this graph theory are applied to the automated design of computer systems. In this embodiment, the nodes may represent hardware elements or software elements of a computer system. In this embodiment, the edges represent relationships (e.g., connection relationships) between nodes. In the topology configuration of a computer system represented by nodes and edges, events that pose security threats to system components such as nodes and edges may occur. The options on the GUI screen may include options for selecting components and selecting threats that may occur in the selected components. The user may use the options to select a component and a security threat that may occur in the component. The selection of security threats that may occur in a certain component may be automatically performed by the system design device 100. The system requirements in FIG. 2 select two nodes: a node on which a first application (App1) runs and a node on which a second application (App2) runs. These nodes are connected by an edge indicating that they are connected via HTTP communication. The system requirements in FIG. 2 also indicate that an eavesdropping threat (T_NetSni) may occur at the edge. When a user selects and registers a system requirement, the input / output unit 11 of the system design device 100 acquires configuration information (first configuration information) corresponding to the system requirement. This configuration information is the first configuration information input from outside at the start of processing.The example of system requirements shown in Figure 2 shows a simple computer system configuration in which two nodes are connected by an edge, but the user may input system requirements that show more complex computer system configurations. As shown in Figure 2, node n is represented by a circle (◯) on the GUI screen. Edge e is represented by an arrow connecting node n and node n on the GUI screen.

[0024] FIG. 3 illustrates an overview of the processing performed by the system design device. FIG. 3 shows search tree data generated by the configuration instantiation unit 12 of the system design device. The first configuration information 31 at the root of the search tree data in FIG. 3 is the first configuration information input from outside at the start of processing. The configuration instantiation unit 12 of the system design device 100 generates second configuration information by instantiating a certain grouping of specific components in the topology of the computer system represented by the first configuration information 31. The threat instantiation unit 13 generates third configuration information based on the second configuration information. The grouping of components is preset, and may be a single node, a node and an edge connected to that node, or multiple nodes and one or more edges connected to those nodes. The analysis unit 14 then outputs the third configuration information to the configuration instantiation unit 12 if it cannot determine that the third configuration information is insecure. The configuration concretization unit 12 adds the acquired third configuration information as new first configuration information 321 as information on a child node linked to the first configuration information 31 in the tree structure indicated by the search tree data. Similarly, the configuration concretization unit 12 generates second configuration information that concretizes other unconcretized groups of specified configuration elements in the topology of the computer system of the first configuration information 31, and the threat concretization unit 13 generates third configuration information based on the second configuration information. Then, if the analysis unit 14 cannot determine that the third configuration information is unsecure, it outputs the third configuration information to the configuration concretization unit 12. The configuration concretization unit 12 adds the acquired third configuration information as new first configuration information 322 as information on a child node linked to the first configuration information 31 in the tree structure indicated by the search tree data.

[0025] When all components of the first configuration information 31 have been instantiated, the configuration instantiation unit 12 selects, for example, one of the first configuration information 321 and 322, and generates second configuration information that instantiates the remaining uninstantiated groups of specific components in the topology of the computer system of the first configuration information 321. The threat instantiation unit 13 then generates third configuration information based on the second configuration information. If the analysis unit 14 cannot determine that the third configuration information is unsecure, it outputs the third configuration information to the configuration instantiation unit 12. The configuration instantiation unit 12 adds the acquired third configuration information as new first configuration information 331 as information on a child node connected to the first configuration information 321 in the tree structure indicated by the search tree data. If the analysis unit 14 determines that the generated third configuration information is unsecure, the analysis unit 14 may discard the third configuration information without outputting it to the configuration instantiation unit 12. Alternatively, the configuration instantiation unit 12 may discard the third configuration information. As a result, configuration information that is determined to be insecure is discarded, and as a result of the system design, it can be determined that the system design is inappropriate at an early stage of the series of processes of the system design device 100.

[0026] The system design device 100 generates search tree data through the above-described process, and outputs to the user, as a system design result, the configuration information that cannot be determined to be unsecure among the third configuration information that ultimately cannot be instantiated. The system design device 100 outputs the configuration information as a system result. The configuration information to be output may be one or more. For example, if there are multiple pieces of configuration information among the terminal nodes of the search tree data that cannot be further instantiated and that cannot be determined to be unsecure, these multiple pieces may be output as the design result. Note that the system design device 100 cannot determine that the configuration information is completely secure. For this reason, the system design device 100 determines that the terminal configuration information of the search tree data obtained through the configuration instantiation process and the threat instantiation process is unsecure, and outputs the configuration information that cannot be determined to be unsecure to the user as a system design result.

[0027] For ease of explanation, Fig. 3 shows only a portion of the first configuration information added as search tree data, and illustrates the network topology indicated by that configuration information. Although the search tree data shown in Fig. 3 shows only a portion of the search tree, in reality, the search tree is composed of nodes indicating a larger number of first configuration information.

[0028] Figure 4 is a diagram explaining the nodes, edges, and threats displayed on the GUI. As shown in Figure 4, if the background color of the circle representing node n is white, that node n indicates an abstract node n1. Here, an abstract node means a node whose information, such as its type and version, has not been determined. More specifically, an abstract node means the following nodes: (a1) If the node represents an OS (Operating System), the node means a node whose OS type and version have not been determined; (a2) If the node represents a machine, the node means a node whose machine type has not been determined; (a3) ​​If the node represents an application, the node means a node whose application type has not been determined.

[0029] Furthermore, if the background color of the circle indicating node n is gray, that node n indicates a specific node n2. Here, a specific node means a node for which information such as its type and version is determined. More specifically, a specific node means the following nodes: (b1) If the node indicates an OS, the node is one for which the type and version of the OS are determined; (b2) If the node indicates a machine, the node is one for which the type of the machine is determined; (b3) If the node indicates an application, the node is one for which the type of the application is determined.

[0030] Furthermore, if the arrow of an edge e is dotted, the edge e indicates an abstract edge e1, and if the arrow is solid, the edge e indicates a concrete edge e2. Abstract edge e1 means an edge whose type is not specific. Concrete edge e2 means an edge whose type is specific. For example, if the communication protocol at an edge e between two nodes included in the configuration information is not determined, it is shown as an abstract edge e1, and if it is determined, it is shown as a concrete edge e2. Threats are indicated by dedicated icons a; if the background of the icon a is white, it indicates an abstract threat a1, and if the background of the icon a is gray, it indicates a concrete threat a2. Threats that cannot be determined to be real, such as security holes or attacks that may occur at node n or edge e, are shown in the configuration information as abstract threats a1, and if they can be determined to be real, they are shown as concrete threats a2. Furthermore, based on the color of the border of the icon a, each icon a indicates one of the following threats: attack endpoint threats a11, attack origin threats a12, or other threats a13. The attack-originating threat a12 is a threat that ultimately influences the occurrence of the attack-endpoint threat a11. The other threats a13 are threats that arise as a result of the influence of the occurrence of the attack-originating threat a12 or threats that arise as a result of further influence from the occurrence of the other threat a13, and the occurrence of other threats a13 due to one or more chains of contributions ultimately influences the occurrence of the attack-endpoint threat a11. The user can confirm the system requirements they are entering by looking at the icons a representing nodes n, edges e, and threats displayed on the GUI screen based on the selection of options.

[0031] In this embodiment, the configuration information may include at least information on "nodes," "edges," and "threats." In the configuration of a computer system, all components must be specific. A threat represents an attack that a user does not want an attacker to accomplish, or the specific steps or operations that an attacker takes to execute that attack. As described above, there are "attack destination type threats," "attack source type threats," and "other threats." An attack destination type threat represents an attack that a user does not want an attacker to accomplish. An attack source type threat represents an attack step that an attacker can clearly perform. Other threats include all threats that are neither the aforementioned attack destination type threats nor attack source type threats.

[0032] Fig. 5 is a diagram showing a specific example of the first configuration information. The configuration information in Fig. 5 shows the first configuration information corresponding to the system requirements shown in Fig. 2. The first configuration information is expressed in text. The first configuration information can be expressed graphically as shown in Fig. 2.

[0033] The configuration information shown in Figure 5 is written in JSON format. The configuration information consists of a list of nodes, a list of edges, and a list of threats. An ID and a type are defined for each node. For each edge, the source node ID, the type of communication protocol connecting the source and destination nodes, and the destination node ID are defined. Whether a node and edge is concrete or abstract is uniquely determined by their type.

[0034] For each threat, the following are defined: the type of threat, the location where the threat can occur (component such as a node or edge), whether the threat is abstract or concrete, whether the threat is an attack destination, an attack origin, or other, the source of the threat, and the destination of the threat. The definitions of the source and destination of the threat will be explained later.

[0035] The location (component) where a threat exists expresses whether the location where the threat exists is a node or an edge, and in parentheses "()" the node ID is written if the location is a node, and the IDs of the source node and destination node are written if the location is an edge. This description method is merely an example and is not limited to this.

[0036] A status of whether a threat that may occur to a component included in the configuration information is concrete or abstract can be assigned. If the component in which a threat occurs and its adjacent components such as nodes or edges are all concrete and no element that can block the threat can be assigned to these components, the threat can be determined to be concrete (concrete threat); otherwise, the threat can be determined to be abstract (abstract threat). Information is added to the concretization source and concretization destination parts of the configuration information shown in Figure 5 in the threat concretization relationship description process S2 for components that are determined to pose a threat in the threat concretization process of the threat concretization unit 13.

[0037] FIG. 6 shows an example of a description of topology concretization rules. The topology concretization rules are defined by a data file. The topology concretization rules are used in the configuration (topology) concretization process in the configuration concretization unit 12. The configuration concretization unit 12 uses the topology concretization rules to concretize the topology configuration of the computer system by adding nodes or edges of the computer system included in the configuration information. The topology concretization rules define two elements: a "source configuration" and a "destination configuration." If the topology configuration of the computer system included in the configuration information can be concretized, the configuration before concretization described in the configuration information is called the source configuration. Furthermore, the configuration that can be added as a topology when the configuration before concretization (source configuration) described in the configuration information is concretized in detail is called the destination configuration.

[0038] The description of the source configuration included in a topology concretization rule defines the topological conditions that must be met in order for that topology concretization rule to be applied. Whether or not that topology concretization rule is actually applied is determined based on the description of the source configuration as well as conditions defined by the configuration concretization unit 12. For example, the configuration concretization unit 12 determines whether a topology concretization rule that has been applied in the past cannot be applied to the same source configuration, and based on this determination, determines whether or not the topology concretization rule is applicable. In the example shown in Figure 6, the condition for applying the rule is the existence of a node whose type is "APP."

[0039] The description of the destination configuration included in the topology concretization rules defines the topology information that will be generated by replacing the source configuration when the topology concretization rules are applied. The configuration indicated in the source configuration is replaced by the configuration indicated in the destination configuration according to the topology concretization rules. In this replacement, if a node ID or edge ID described in the source configuration is not described in the destination configuration, that node or edge will disappear during the configuration concretization process. In the example of the topology concretization rules shown in Figure 6, if the configuration information contains a component that satisfies the source configuration, the configuration concretization process is performed by additionally connecting an "OS" type node in the destination configuration to an "APP" type node existing in the configuration information using a "hosted_on" type edge. In this case, since "app_A" described in the source configuration is also described in the destination configuration, the "app_A" node will not disappear from the configuration information.

[0040] FIG. 7 shows an example of a description of threat concretization rules. Threat concretization rules are defined in a data file separate from the topology concretization rules. Threat concretization rules are used for threat concretization processing in the threat concretization unit 13. As shown in FIG. 7, multiple threat concretization rules can be written in list format, and each rule is established by defining three elements: "refinement source (refined from)," "topological assumption (topological assumption)," and "refinement destination (refined to)."

[0041] The "source" in a threat concretization rule refers to the threat to which the rule is applied, and the newly generated threat after applying the threat concretization rule to the source threat (threat concretization process) is further described in the threat concretization rule as the "destination." When a refined-from threat can occur based on the contribution of other threats, the relationship between the refined-from threat and the refined-to threat is defined in the threat concretization rule. For example, if the threat of eavesdropping at an edge occurs due to the establishment of an eavesdropping threat at the node that is the source of the edge, the threat concretization rule defines the threat indicating eavesdropping at the edge as the "source" (refined from) and the threat indicating eavesdropping at the source node of the edge as the "refined to." The threat concretization unit 13 performs threat concretization processing using threat concretization rules, thereby determining the continuity of the relationship between a threat that may occur in a component included in the configuration information and other threats that contribute to the occurrence of that threat (threat chain route). The format of the threat concretization rules defines the threats that must exist to apply the threat concretization rules and the location (component) where they occur. In the example of Figure 7, the application condition of the threat concretization rules is described as the occurrence of a threat of type "T_NetSni (eavesdropping)" at the "edge connecting app_A and app_B" in the configuration information. The "app_A" and "app_B" mentioned here are provisional node IDs, and if they can be matched with a specific threat described in the configuration information, they are replaced with the corresponding node ID described in the configuration information and the threat concretization processing is performed.

[0042] The configuration conditions described in a threat concretization rule define the components that must be present in the configuration information (e.g., the second configuration information that has been concretized based on the first configuration information in FIG. 5 ) in order for the threat concretization rule to be applied. If the components described in the configuration conditions of a threat concretization rule are not included in the configuration information (e.g., the second configuration information that has been concretized based on the first configuration information in FIG. 5 ), the threat concretization rule cannot be applied. The node IDs described in the configuration conditions of a threat concretization rule are provisional node IDs. When checking whether the components that cause the threat to be concretized are included in the configuration information, if a node ID corresponding to the node ID indicated in the configuration conditions exists in the second configuration information that has been concretized based on the first configuration information, the node ID indicated in the configuration conditions of the threat concretization rule is replaced with the node ID in that configuration information, and threat concretization is performed. When checking whether the components corresponding to the provisional node IDs described in the configuration conditions of a threat concretization rule are included in the configuration information (second configuration information) as components that cause the threat to be concretized, if they are not included, the threat concretization rule is not applied.

[0043] The "concretization destination" in the configuration conditions of a threat concretization rule refers to the threat generated as a result of applying the rule, and refers to the threat that is connected to the original threat when forming a chain route that sequentially shows the relationships that contribute to the occurrence of that threat. The format for the "concretization destination" in the configuration conditions of a threat concretization rule is basically the same as the original format, but an "attack type" item has been added. The "attack type" item indicates whether the threat added to the configuration information as the concretization destination is an attack endpoint threat, an origin threat, or other.

[0044] A system design device 100 according to the present disclosure acquires first configuration information including at least information about the topology of a computer system using components that represent at least one of nodes in the computer system and edges that represent relationships between the nodes. The system design device 100 then generates second configuration information that concretizes the topology configuration of the computer system by adding nodes or edges of the computer system in the first configuration information based on topology concretization rules. In this process, the system design device 100 generates second configuration information that concretizes one of the units of a group of specified components in the topology of the computer system in the first configuration information input at the start of the process.

[0045] Furthermore, the system design device 100 determines whether or not an event that poses a threat to the security of the computer system may occur at a node or edge in the configuration of the specified topology, and if an event that poses a threat may occur, generates third configuration information by adding to the second configuration information an identifier of the threat, a component in which the threat may occur, identifiers of other threats that contribute to the occurrence of the threat, and information indicating the relationship between the other components in which the other threats may occur.

[0046] The system design device 100 determines whether the content of each threat is concrete or abstract in a threat chain path based on the relationship between a threat in the third configuration information and other threats that contribute to the occurrence of the threat, and determines whether the design of the computer system of the third configuration information is unsecure when the content of the threat is concrete or abstract. In this determination, the system design device 100 determines that the design of the computer system represented based on the third configuration information is unsecure if the content of the threat is all concrete in the threat chain path, or if the content of the threat is abstract in any component of the threat chain path but it is determined that there is no means to prevent the abstract threat from being replaced with a concrete threat.

[0047] The system design device 100 then sets, as new first configuration information, any third configuration information generated based on the second configuration information for which the computer system design has not been determined to be unsecure, and repeats the process of generating new second configuration information that instantiates one of the units of predetermined component elements in the topology of the computer system of the first configuration information. The system design device 100 also repeats the process of generating new third configuration information based on the second configuration information. If none of the units of predetermined component elements in the topology of the computer system of the new third configuration information can be further instantiated and the design of the computer system of the third configuration information is not determined to be unsecure, the system design device 100 outputs the third configuration information as the design result.

[0048] According to this process, third configuration information that specifies configurations and threats based on the first configuration information is added to the search tree data. If the third configuration information is determined to be unsecure at the time of adding the third configuration information to the search tree data, it is determined that a system that is not determined to be unsecure cannot be created with the system requirements included in the third configuration information, and the third configuration information is discarded without being added to the search tree data. This reduces the number of configuration information items added in generating the search tree data, ultimately adding the third configuration information to the end of the search tree data and preventing further configuration specification, thereby accelerating the detection of configuration information (third configuration information) that is not determined to be unsecure. Therefore, by performing this process, the system design device 100 can speed up the output of design results that are not determined to be unsecure for a computer system that specifies configurations and threats according to system requirements input by a user during system design, thereby shortening the time required to design a system with a configuration that is not determined to be unsecure. Details of the process performed by the system design device 100 are described below.

[0049] 8 is a first diagram showing the processing flow of the system design device 100. The processing flow of the system design device 100 will be described with reference to FIG.

[0050] First, the input / output unit 101 of the system design device 100 accepts input of first configuration information (FIG. 5) corresponding to the system requirements (FIG. 2) from a user (step S101). The input / output unit 101 outputs search tree data including the first configuration information to the configuration instantiation unit 12. At the start of processing, the search tree data contains only the first configuration information including the topology of the computer system specified by the user's input operation of the system requirements.

[0051] The configuration instantiation unit 12 selects configuration information from the search tree to which the application of the topology instantiation rules (FIG. 6) is to be considered (step S102). At the start of processing, the search tree contains no configuration information other than the input first configuration information shown in FIG. 5, so in this case, the configuration instantiation unit 12 selects the first configuration information shown in FIG. 5. Which configuration information in the search tree is selected depends on the system specifications of the system design device performing the search. As an example, configuration information corresponding to the node closest to the root node in the search tree that has not undergone configuration instantiation processing in the search tree may be selected.

[0052] The configuration concretization unit 12 then applies applicable topology concretization rules to the selected first configuration information (step S103) to generate second configuration information. At this time, if there are multiple applicable topology concretization rules, for example, three, the configuration concretization unit 12 will obtain three pieces of second configuration information by applying each of the applicable topology concretization rules. For example, if the topology concretization rules shown in Figure 6 are applied to the first configuration information of Figure 5, second configuration information that updates the first configuration information is generated, as shown in Figure 10.

[0053] The configuration concretization unit 12 determines whether one or more pieces of second configuration information have been generated by the topology concretization process (step S104). If any topology concretization rule has been applied to the first configuration information, one piece of second configuration information will always be newly generated. If the determination in step S104 is No, this means that no topology concretization rule could be applied to the target first configuration information. In this example, it is assumed that there is a topology concretization rule that can be applied to the first configuration information shown in FIG. 5, and at least the second configuration information shown in FIG. 10 has been newly generated. In this case, the configuration concretization unit 12 determines Yes in step S104.

[0054] If the configuration concretization unit 12 determines that one or more pieces of second configuration information have been generated by the topology concretization process (step S104: Yes), it passes all of the generated second configuration information one by one to the threat concretization unit 13 (step S105), and the threat concretization unit 13 performs the threat concretization process. The analysis unit 14 analyzes the third configuration information after the threat concretization process is completed. After the configuration concretization unit 12 passes one piece of second configuration information to the threat concretization unit 13, the threat concretization unit 13 generates third configuration information based on the second configuration information, and the analysis unit 14 processes the third configuration information. This process is repeated for each piece of generated second configuration information. The analysis unit 14 sequentially outputs the results of the security judgment process S5 for one or more pieces of third configuration information to the configuration concretization unit 12. If the generated third configuration information is determined to be insecure in the security judgment, the configuration concretization unit 12 discards the third configuration information. The configuration instantiation unit 12 adds the third configuration information that has not been determined to be non-secure in the security judgment as new first configuration information in the search tree as a node under the first configuration information used to generate the third configuration information (step S106). This generates search tree data such as that shown in Figure 3. By repeating the above process, the first configuration information that remains in the search tree as a candidate for application of the topology instantiation rules is sequentially limited to configuration information that is not determined to be non-secure.

[0055] If the configuration concretization unit 12 cannot generate one or more second configuration information through the topology concretization process using first configuration information added to the end of the search tree or first configuration information that has not yet been processed, it determines No in step S104 and determines whether the target first configuration information for which it has determined that the second configuration information cannot be generated is concrete (step S107). For example, the configuration concretization unit 12 uses the first configuration information at the end of the search tree selected as the target, and if there are no components that can be added to all the components included in the first configuration information and all the components included in the first configuration information are concrete, it determines that the first configuration information is concrete. In this process, if the configuration concretization unit 12 does not store topology concretization rules corresponding to the IDs and types of the components, it can determine that there are no components that can be added to the components included in the first configuration information.

[0056] If the determination in step S107 is No, i.e., the selected first configuration information is not specific, it means that abstract elements remain in the first configuration information even though the topology concretization rules cannot be applied to the first configuration information in step S103. In this case, the configuration concretization unit 12 determines that the first configuration information is inappropriate as a design result and determines whether other first configuration information remains in the search tree (step S109). If unprocessed first configuration information remains in the search tree (step S109: Yes), the configuration concretization unit 12 returns to step S102, reselects new first configuration information, and repeats the process. If the configuration concretization unit 12 determines that no unprocessed first configuration information remains in the search tree (step S109: No), it means that all first configuration information in the search tree has been determined to be insecure or inappropriate as a design result, and outputs information indicating a design failure to the input / output unit 11 (step S111).

[0057] On the other hand, if the determination in step S107 is Yes, the system configuration indicated by the target first configuration information is concrete and has been added to the search tree, and therefore has not been determined to be insecure, so the configuration instantiation unit 12 outputs the first configuration information to the input / output unit 11 (step S110). The input / output unit 11 outputs the first configuration information to an output device such as a monitor so that it can be visually confirmed by a user as a result of the system design.

[0058] FIG. 9 is a second diagram showing the processing flow of the system design device 100. FIG. 10 is a diagram showing a specific example of the second configuration information. FIG. 11 is a first diagram showing a specific example of the third configuration information. FIG. 12 is a second diagram showing a specific example of the third configuration information. FIG. 13 is a third diagram showing a specific example of the third configuration information. Next, the processes of the threat concretization unit 13 and the analysis unit 14 will be described using FIGS. 9 to 13. The processes of the threat concretization unit 13 and the analysis unit 14 are specific examples of the processes of steps S105 and S106 described above. The threat concretization unit 13 receives the second configuration information generated by the configuration concretization unit 12 (step S201). The threat concretization unit 13 applies the threat concretization process S0 to the received second configuration information (step S202). The threat concretization process S0 performs the following process for all threat concretization rules, and ends when it is determined that no further threat concretization rules can be applied, and proceeds to a conditional branch (step S203).

[0059] Specifically, in the processing of step S202, it is checked whether the second configuration information being targeted contains information on the "type" or "location (component)" of a threat that matches the "type" or "location (component)" information of the threat described in the "source of concretization" of a certain threat concretization rule. For all threats described in the second configuration information that match the "type" or "location (component)" information of the threat described in the "source of concretization" of the threat concretization rule, a search is made to see whether the second configuration information contains a component that matches the information described in the "configuration condition" of the threat concretization rule.

[0060] As an example, consider a situation in which the threat materialization unit 13 applies the threat materialization rules of Fig. 7 to the second configuration information shown in Fig. 10. In this case, the threat materialization unit 13 determines whether the threat type "T_NetSni" and location "edge (app_A, app_B)" information written in the "Source of materialization" of the threat materialization rules (Fig. 7) match the threat type and location information included in the second configuration information of Fig. 10. If they match, the threat materialization unit 13 searches the second configuration information for a component matching the component indicated by the "Configuration Condition" in the threat materialization rules.

[0061] In this process, when comparing the threat information described as the "concretization source" of the threat concretization rules with the threat information described as the "concretization source" of the second configuration information, the threat concretization unit 13 performs processing by replacing the provisional node IDs (app_A, app_B) described as the "location" item of the threat description in the threat concretization rules with the actual node IDs (App1, App2) present in the description of the component in the second configuration information. The threat concretization unit 13 also confirms whether the description of the "edge" type "http" in the "configuration conditions" of the threat concretization rules matches the "http" type of the edge between the node IDs actually replaced as the "location" item of the threat in the second configuration information. The threat concretization unit 13 applies the threat concretization rules to the second configuration information only if the description of the "edge" type "http" in the "configuration conditions" of the threat concretization rules matches the "http" type of the edge between the node IDs actually replaced as the "location" item of the threat in the second configuration information.

[0062] Furthermore, if the threat concretization unit 13 successfully matches the description of the "http" type of the "edge" in the "configuration condition" of the threat concretization rule with the description of the "http" type of the edge between node IDs that has actually been replaced as the "location" item of the threat in the second configuration information, it adds the contents of the "concretization destination" in the threat concretization rule to the second configuration information. Figure 11 shows the third configuration information that is the result of applying the threat concretization rule of Figure 7 to the second configuration information of Figure 10.

[0063] The processing of the threat materialization unit 13 will be explained more simply. Assume that the threat materialization rules of FIG. 7 describe a rule R61 relating to a certain threat and a rule R62 of a configuration condition that defines a component (location) where the threat can occur. If the same relationship between the threat and the configuration condition as that between the rule R61 and the rule R62 is described in the second configuration information, a rule R63 relating to a threat in another component that contributes to the occurrence of the threat indicated by the rule R61 is defined in the threat materialization rules. Using the second configuration information ( FIG. 10 ), the threat materialization unit 13 detects that a description of a threat identical to the rule R61 relating to the threat in the threat materialization rules ( FIG. 7 ) exists in the second configuration information (threat a71 in FIG. 10 ) and that a description of a configuration corresponding to the rule R62 of the configuration condition linked to the rule R61 in the threat materialization rules exists in the second configuration information (configuration c91 in FIG. 10 ). In this case, the threat materialization unit 13 generates third configuration information (FIG. 11) by adding another threat a72 that contributes to the occurrence of threat a71 to the second configuration information (FIG. 10). As a result, the third configuration information (FIG. 11) describes information on threat a71, the components where threat a71 can occur, threat a72 that contributes to the occurrence of threat a71, and the components where threat a72 can occur (the "location" described in a72). If the threat materialization rules describe the existence of another threat that contributes to the occurrence of threat a72, information on that other threat and the components where that threat can occur is described in the third configuration information.

[0064] The processing of the threat materialization unit 13 described above determines whether an event that poses a threat to the security of the computer system may occur in a component such as a node or an edge in the topology configuration (second configuration information) of the materialized computer system. The processing of the threat materialization unit 13 is one aspect of processing for generating third configuration information in which, when an event that poses a threat to a certain component may occur, the second configuration information is added with information indicating the relationship between the identifier of the threat, the component in which the threat may occur, the identifiers of other threats that contribute to the occurrence of the threat, and the other component in which the other threat may occur.

[0065] Figure 11 shows a text representation of the third configuration information immediately after applying the threat concretization rules. A schematic diagram of the system configuration, which graphically represents the third configuration information, is shown on the right side of the arrow in the center of Figure 11. When generating the third configuration information, the threat concretization unit 13 adds the concretization destination information to the threat description in the second configuration information based on the concretization destination location and type information described in the threat concretization rules (rule R63 in Figure 7). In such cases, the threat concretization unit 13 checks whether the "concretization source" information of the existing threat in the second configuration information matches the "concretization source" information of the threat concretization rule to be applied (rule R61 in Figure 7). If there is a match, it means that the threat concretization process S0, which has been performed once before, has been applied to the same threat. Therefore, the threat concretization unit 13 invalidates the application of the threat concretization rule to the second configuration information and determines that the "threat concretization rule could not be applied." The threat concretization unit 13 attempts to apply the same process for all threat concretization rules to the second configuration information, and then determines whether any threat concretization rule has been applied (step S203). If the threat concretization unit 13 has applied any threat concretization rule to the second configuration information, it performs the threat abstraction level determination process S1 (step S204). If no threat concretization rule has been applied to the second configuration information, the threat concretization unit 13 outputs the second configuration information as third configuration information to the configuration concretization unit 12 without proceeding to the threat abstraction level determination process S1 (step S211). The configuration concretization unit 12 outputs the third configuration information to the input / output unit 11. The third configuration information output from the analysis unit 14 without any threat materialization rules being applied to the second configuration information is not determined to be insecure configuration information.

[0066] In the threat abstraction level determination process S1, the threat materialization unit 13 determines whether all threats present in the third configuration information are abstract or concrete. In this determination, the threat materialization unit 13 determines that a threat is concrete (a concrete threat) if the component in which the threat occurs and its adjacent components, such as nodes or edges, are all concrete and it is not possible to assign an element to block the threat to these components, and otherwise determines that the threat is abstract (an abstract threat).

[0067] To explain the threat abstraction level determination process S1 using an example of this embodiment, a threat (a72) newly added in the third configuration information shown in FIG. 11 exists on “App1,” and two adjacent edges (“hosted_on” and “http”) are both concrete edges. Regarding the components where the threat (a72) newly added in the third configuration information may occur and its adjacent components, in this embodiment, the type of the component “App” of “App1” and the types of the two edges adjacent to that component, “hosted_on” and “http,” are assumed to be the types of the components, and the system design device 100 has stored in advance in a database or the like information indicating that the components do not have a function to block the threat that may occur based on these components. If the threat concretization unit 13 determines, based on the information stored in the database, that the adjacent components do not have a function to block the threat, the threat abstraction level determination process S1 determines that the threat described in the third configuration information is concrete (a concrete threat). In this case, the threat concretization unit 13 adds information indicating "concrete" to the "abstraction level" in the description of the target threat in the third configuration information (d11 in FIG. 12). If the threat concretization unit 13 cannot obtain information from the database indicating that the newly added threat (a72) does not have a function to prevent the threat as information on the components or their adjacent components that may cause the threat (a72), the threat concretization unit 13 may determine the abstraction level of the threat as abstract (abstract threat). In this case, the threat concretization unit 13 adds information indicating "abstract" to the "abstraction level" in the description of the target threat (a72) in the third configuration information. FIG. 12 shows a text representation of the third configuration information corrected by the threat concretization unit 13, with a schematic diagram of the third configuration information depicted on the right side of the arrow in the center. The method of this threat abstraction level determination process S1 is not limited to this.

[0068] The threat materialization unit 13 performs the threat abstraction level determination process S1 for all threats described in the third configuration information, and then performs the threat materialization relationship description process S2 (step S205). The threat materialization relationship description process S2 is a process for generating third configuration information that adds information indicating the relationship between an identifier of the threat, the component in which the threat may occur, the identifiers of other threats that contribute to the occurrence of the threat, and other components in which the other threats may occur, when an event that poses a threat to the security of the computer system may occur at a node or edge in the configuration of the materialized topology.

[0069] Currently, information on threats a71 and a72 is described in the third configuration information ( FIG. 12 ). Threat a71 is a threat that may occur due to the contribution of threat a72, and the information on threat a72 in the third configuration information ( FIG. 12 ) is information added by applying the threat concretization rules ( FIG. 7 ). The threat concretization unit 13 adds, to the item for threat a71 in the third configuration information ( FIG. 12 ), information (type, location) c121 of other components (refined to) defined in rule R63 of the threat concretization rules ( FIG. 7 ) as information (type, location) of other components (refined to) that may occur as threat a72 contributes to the occurrence of threat a71 ( FIG. 13 ). In addition, the threat concretization unit 13 adds information (type, location) c122 of the component (refinement source) defined in rule R61 of the threat concretization rules (Figure 7) to the item of threat a72 in the third configuration information (Figure 12) as information (type, location) of the component (refinement source) from which threat a71 may occur (Figure 13).

[0070] By performing this threat concretization relationship description process S2, it becomes possible to trace from the third configuration information which threats may occur due to the influence of which threats that may occur in other components, thereby making it possible to output a list of threats that make up a threat chain path (attack path) based on the relationship between a threat and other threats that contribute to the occurrence of the threat in question.

[0071] After completing the threat concreteness relationship description process S2, the threat concreteness unit 13 determines, based on the generated third configuration information, whether or not there is a chain of threats (attack path) based on the relationship between a threat and other threats that contribute to the occurrence of the threat (step S206). The threat concreteness unit 13 acquires information about the descriptions of one or more threats described in the third configuration information (FIG. 13) and determines whether information about an attack-originated threat exists as information indicating an "attack type." If information about an attack-originated threat exists as information indicating an "attack type" among the acquired threat information, the threat concreteness unit 13 instructs the analysis unit 14 to start processing. Note that if information about an attack-originated threat does not exist, a threat indicating an attack-endpoint threat as an "attack type" will not occur. If information about an attack-originated threat does not exist as information indicating an "attack type" among the acquired threat information, the threat concreteness unit 13 instructs the analysis unit 14 to skip processing the third configuration information because the configuration of the computer system indicated in the third configuration information is not determined to be insecure. If the acquired information about threats does not include information about attack-origin threats that indicates an "attack type," the analysis unit 14 determines that the third configuration information is not judged to be insecure, and therefore skips the processing of the analysis unit 14 (process S3 for investigating specific threat generation avoidance candidates, process S4 for investigating attack path concretization avoidance means, and security judgment process S5) and outputs the third configuration information to the configuration concretization unit 12 (step S211).

[0072] The information indicating "attack type" is either automatically written as configuration information when the user sets a threat on the GUI screen, or is information assigned to the third configuration information by inheriting information previously written in rule R63 as information regarding the components (refined to) where other threats that contribute to the occurrence of the threat in the threat concretization rule may occur. When "attack type" indicates an attack-originating threat, it indicates that the threat is one that can occur without the contribution of other threats. When "attack type" indicates an attack-endpoint threat, it indicates that the threat ultimately occurs due to the contribution of other threats. When "attack type" indicates other, it indicates that the threat is neither an attack-originating threat nor an attack-endpoint threat.

[0073] If there is information about an attack-originated threat in the information indicating "attack type" among the information regarding the description of one or more threats described in the third configuration information (Figure 13), the analysis unit 14 performs an investigation process S3 of specific threat generation and avoidance candidates (step S207).

[0074] In the process S3 for investigating specific threat generation and avoidance candidates, the analysis unit 14 identifies threats that have been determined to be abstract threats in the threat abstraction level determination process S1. For all threats determined to be abstract threats, the analysis unit 14 investigates whether there is a method of concretizing components that can prevent the threat from being determined to be a specific threat.

[0075] Fig. 14 is a first diagram for explaining the details of the process S3 of the analysis unit. Fig. 15 is a second diagram for explaining the details of the process S3 of the analysis unit. The process S3 of investigating specific threat generation and avoidance candidates will be explained in more detail using Figs. 14 and 15.

[0076] Assume that the third configuration information shown in FIG. 14 has been generated by processing up to the threat instantiation unit 13. The third configuration information shown in FIG. 14 describes, based on the threat instantiation processing, that the OS1 node corresponding to the system configuration diagram shown to the right of the arrow in the center of FIG. 12 has been replaced with node n3 of an OS called OS1_ver.x.xx, that two threats (a73, a74) that constitute an attack path at node n3 may occur, and that another threat a75 that contributes to the occurrence of threat a74 that may occur at node n3 may occur at another node n4. The OS of node n4 is a node called Physical Server 1. Attack path P131 that can be identified by the third configuration information shown in FIG. 14 indicates a specific attack path.

[0077] In another example, assume that the third configuration information shown in FIG. 15 is generated by processing up to the threat materialization unit 13. The third configuration information shown in FIG. 15 describes, based on the threat materialization processing, that two threats (a73, a74) that constitute an attack path at node n3 may occur, while the network topology up to node n3 of OS1 corresponding to the schematic diagram of the system configuration represented to the right of the arrow in the center of FIG. 12 remains the same, and that another threat a75 that contributes to the occurrence of threat a74 that may occur at node n3 may occur at another node n4. The OS of node n4 is a node called Physical Server 1. The attack path P141 that can be identified by the third configuration information shown in FIG. 15 indicates an abstract attack path.

[0078] The schematic diagram of the system configuration based on the third configuration information shown in FIG. 14 and the schematic diagram of the system configuration based on the third configuration information shown in FIG. 15 differ in that node n3 between node n1 “App1” and node n4 “Physical Server1” is either the abstract node “OS1” or the concrete node “OS1 ver x.xx.” “OS1 ver x.xx” and “OS1” indicate the ID of the node. The storage unit of the system design device 100 stores information associated with the ID of the node indicating whether the node is a concrete node or an abstract node. The system design device 100 also stores information associated with an ID indicating an OS, such as “OS1 ver x.xx,” in the storage unit of the system design device 100, indicating whether the OS has characteristics that prevent threats. The characteristics that prevent threats may be, for example, characteristics in which OS defects have been improved or programs have been improved to prevent all known attack methods, such as eavesdropping on known computer systems. Note that ver x.xx indicates the version number of a specific OS. Also, it is assumed that the storage unit of the system design device 100 stores information "OS 1 ver x.xx" as the OS ID when this OS is instantiated, linked to the ID of "OS1."

[0079] In this case, it is assumed that the analysis unit 14 acquires third configuration information as shown in FIG. 15 from the threat materialization unit 13. Then, it is assumed that the analysis unit 14 is able to identify the attack path P141 shown in FIG. 15 from the third configuration information. The analysis unit P141 identifies information from the storage unit, such as node IDs and edge IDs, as to whether each node or edge at which a threat a71, a72, a73, a74, and a75 included in the attack path P141 may occur is abstract or concrete. If at least one component of the node or edge at which a threat may occur is abstract, the analysis unit 14 determines the attack path P141 to be an abstract attack path. If all components of the node or edge at which a threat may occur are concrete, the analysis unit 14 determines the attack path P141 to be a concrete attack path. In the example of Figure 15, the ID of node n3 indicates "OS1", and since the memory unit records that this ID is an abstract node, the analysis unit 14 determines that attack path P141 is an abstract attack path. An abstract node is a node where it is unclear whether a specific threat will occur. Therefore, for attack path P141 determined to be an abstract attack path, it is not clear whether a specific threat will occur at the node determined to be an abstract node.

[0080] If the attack path P141 in the acquired third configuration information is an abstract attack path, the analysis unit 14 identifies an abstract node in the attack path P141. The analysis unit 14 acquires the node ID "OS1" of the abstract node. The analysis unit 14 determines whether information indicating that this OS has characteristics that block threats is recorded in association with the node ID "OS1." If information indicating that this OS has characteristics that block threats is not recorded in association with the node ID "OS1," the analysis unit 14 determines whether another OS that is a candidate for instantiating the OS is recorded in the storage unit in association with the node ID "OS1." Assume that "OS 1 ver. x.xx" is recorded in association with the node ID "OS1" as another OS that is a candidate for instantiating the OS. The analysis unit 14 reads the information of "OS 1 ver. x.xx." The analysis unit 14 also acquires information on whether the OS has the characteristics to block threats, which is linked to the ID of "OS 1 ver. x.xx" and recorded in the storage unit. Assume that the information on whether the OS has the characteristics to block threats, which is linked to the ID of "OS 1 ver. x.xx" and recorded in the storage unit, indicates that the OS does not have the characteristics to block threats. In this case, the analysis unit 14 can replace the third configuration information shown in FIG. 15 acquired from the threat materialization unit 13 with the third configuration information shown in FIG. 14. Since it is clear at this point that threats a73 and a74, which may occur at the abstract node (node ​​n3; "OS1") included in the attack path P141 in this third configuration information, cannot be blocked, the analysis unit 14 determines that the attack path P141 is a specific attack path where a threat may occur. The analysis unit 14 performs the same process for all abstract nodes in the attack paths identified in the acquired third configuration information.

[0081] The analysis unit 14 similarly determines whether all abstract nodes constituting the abstract attack path can be replaced with other concrete nodes, and if they can be replaced with concrete nodes, determines whether the OS of the concrete nodes can be given the properties to block threats (S3), and then starts the investigation process S4 of attack path concretization avoidance means. Note that, in an abstract attack path, if an abstract node constituting the path can be replaced with another concrete node, but the OS of the concrete node cannot be given the properties to block threats, the abstract attack path is an attack path for which there is no means to avoid replacement with a concrete threat. In other words, if an abstract node constituting the abstract attack path can be replaced with a concrete node, but the OS of the concrete node cannot be given the properties to block threats, the analysis unit 14 presumes that the generation of a concrete threat cannot be avoided at that abstract node. If the abstract nodes that make up the abstract attack path can be replaced with concrete nodes and the OS of those concrete nodes cannot be given the characteristics to block threats, the analysis unit 14 also uses that information in the investigation process S4 of the attack path concretization avoidance means.

[0082] FIG. 16 is a diagram illustrating the details of the analysis unit's process S4. The process S4 of investigating the attack path concretization avoidance means will be described in more detail using FIG. 16. In the attack path concretization avoidance means investigation process S4, the analysis unit 14 investigates whether there is a means to avoid the generation of a concrete attack path that can be identified by the third configuration information (step S208). In this process, the analysis unit 14 determines whether a concrete attack path exists among one or more attack paths that can be identified based on the third configuration information. If the analysis unit 14 determines that no concrete attack path exists, all attack paths that can be identified from the third configuration information are abstract attack paths. Since the threats that constitute an abstract attack path include at least one abstract threat, the analysis unit 14 determines whether there is a means to avoid replacing all abstract threats in each abstract attack path with concrete threats based on the results of the concrete threat generation avoidance candidate investigation process S3.

[0083] The analysis unit 14 determines that an abstract attack path can be "concretized and avoided" if it determines that there is a means to replace even one of the abstract threats present in the abstract attack path with a concrete threat. The analysis unit 14 determines that an abstract attack path cannot be "concretized and avoided" if it determines that there is no means to replace all of the abstract threats present in the abstract attack path with concrete threats.

[0084] For example, assume that the only concretization candidate for "OS1" is "OS 1 ver x.xx" as shown in FIG. 14 . In this case, the information on whether or not "OS 1 ver. x.xx" has the characteristics to block threats and is stored in the storage unit in association with the ID of "OS 1 ver. x.xx" indicates that the characteristics to block threats are not present. In this case, the analysis unit 14 determines that this abstract attack path is "unconcretizable" because there is no way to prevent it from being replaced with a concrete threat. Even if the abstract node in the abstract attack path is replaced with a concrete node, the possibility of a threat occurring at that concrete node cannot be prevented, and the threat becomes concrete at that node. Therefore, it can be determined that it is impossible to prevent the concretization of the threat.

[0085] FIG. 16 is a schematic diagram of configuration information in which topology instantiation is performed to avoid the instantiation of attack path P141, which is the abstract attack path in FIG. 15. Meanwhile, as shown in FIG. 16, suppose another OS, "OS 1 ver y.yy," is recorded in the storage unit as an instantiation candidate for "OS1," and that nodes of this type of OS are equipped with a threat-blocking function. In this case, the analysis unit 14 identifies "OS 1 ver y.yy," a concatenation candidate for "OS1," from the storage unit and acquires information associated with the ID of "OS 1 ver y.yy" and recorded in the storage unit regarding whether or not it has the characteristics to block threats. Assume that this information indicates that it has the characteristics to block threats. In this case, the analysis unit 14 determines that this abstract attack path is not "unavoidable from being concatenated" because there is a means to prevent it from being replaced with a concrete threat. By replacing an abstract node in an abstract attack path with a concrete node, the possibility of a threat occurring at that concrete node can be prevented, so that it can be determined that the threat does not become concrete at that node and that it is not impossible to prevent the threat from becoming concrete.

[0086] After the above processing is performed, the security judgment process S5 is performed (step S209).

[0087] In the security determination process S5, the analysis unit 14 performs a security determination process to determine whether the third configuration information is non-secure based on the investigation results in the investigation process S4 of the attack path concretization avoidance means. If, in the security determination process S5, it is determined that no concrete attack path exists among the attack paths that can be identified from the third configuration information and that all abstract attack paths cannot be concretized, the analysis unit 14 determines that the system configuration indicated by the third configuration information is "non-secure."

[0088] In this embodiment, if an attack path P131 as shown in FIG. 14 can be identified based on the third configuration information, the analysis unit 14 determines that the attack path is a specific attack path and therefore is insecure.

[0089] If an attack path P141 such as that shown in Figure 15 can be identified based on the third configuration information, the analysis unit 14 determines that the attack path is an abstract attack path, but that the only concatenation candidate for the abstract node "OS1" in the abstract attack path is "OS 1 ver x.xx", and that the concatenation of the abstract attack path cannot be avoided, so that the attack path is insecure.

[0090] If an attack path P151 such as that shown in Figure 16 can be identified based on the third configuration information, the analysis unit 14 does not determine that the attack path is insecure because, although it is an abstract attack path, "OS 1 ver y.yy" exists as a candidate for concatenation of the abstract node "OS1" in the abstract attack path, and there is a means to avoid concatenation of the abstract attack path.

[0091] If the analysis unit 14 cannot determine that the system configuration indicated by the third configuration information is non-secure, it outputs the third configuration information to the configuration instantiation unit 12 to add it to the search tree, and returns to the processing of step S105 (step S211). If the analysis unit 14 determines that the system configuration indicated by the third configuration information is non-secure, it discards the third configuration information and returns to the processing of step S105 without outputting the third configuration information to the configuration instantiation unit 12 (step S210). The configuration instantiation unit 12 adds the third configuration information that cannot be determined to be non-secure to the search tree data as new first configuration information as a node subordinate to the first configuration information used to generate the third configuration information. When the analysis unit 14 finishes processing all configuration information in step S105, the configuration instantiation unit 12 repeats the processing from step S102.

[0092] The system design device 100 repeats the above-described processing of the configuration concretization unit 12, the threat concretization unit 13, and the analysis unit 14 to generate search tree data as shown in FIG. 3, and if the determination in step S104 is No, performs the processing of the above-described step S107.

[0093] According to the processing of the above-described system design device 100, not only configuration information in which a specific attack path is established, but also configuration information in which an abstract attack path exists that is determined to have no means of avoiding being replaced with a specific attack path in the future, the system configuration based on that configuration information can be immediately determined to be insecure and can be discarded from the processing results as a system design. Therefore, it is possible to omit the process of determining whether all patterns that embody configuration information as system requirements set by the user are insecure, and it is expected that a system that is not determined to be insecure can be efficiently derived.

[0094] 17 is a hardware configuration diagram of a system design device 100. As shown in this diagram, the system design device 100 may be a computer equipped with various pieces of hardware such as a CPU (Central Processing Unit) 101, a ROM (Read Only Memory) 102, a RAM (Random Access Memory) 103, a database 104, and a communication module 105. The functions of the system design device 100 according to each of the above-described embodiments may be realized by an information processing system in which a plurality of information processing devices are provided with one or more of the above-described functions and are configured to work together to perform overall processing.

[0095] FIG. 18 is a diagram showing the minimum configuration of the system design device 100. As shown in this figure, the system design device 100 has at least the functions of an acquisition means 181, a configuration instantiation means 182, a threat instantiation means 183, and an analysis means 184. The acquisition means 181 acquires first configuration information including at least information about the topology of a computer system using any of the components of nodes and edges that indicate relationships between the nodes in the computer system. The configuration instantiation means 182 generates second configuration information by adding nodes or edges of the computer system in the first configuration information to instantiate the topology configuration of the computer system. The threat instantiation means 183 determines whether an event that poses a threat to the security of the computer system could occur at a node or edge in the instantiated topology configuration. If an event that poses a threat could occur, the threat instantiation means generates third configuration information by adding to the second configuration information an identifier of the threat, a component that could cause the threat, identifiers of other threats that contribute to the occurrence of the threat, and information indicating the relationship between the other components that could cause the other threats. The analysis means 184 determines whether the content of each threat is concrete or abstract in a threat chain path based on the relationship between a threat in the third configuration information and other threats that contribute to the occurrence of the threat. The analysis means 184 determines whether the design of the computer system of the third configuration information is insecure when the content of the threat is concrete or abstract. In this process, the analysis means 184 determines that the design of the computer system of the third configuration information is insecure if the content of the threat is all concrete in the threat chain path, or if the content of the threat is abstract in any component of the threat chain path but it is determined that there is no means to prevent the abstract threat from being replaced with a concrete threat.

[0096] The program may be a program for realizing some of the functions described above, or may be a so-called differential file (differential program) that can realize the functions described above in combination with a program already recorded in the computer system.

[0097] Some or all of the above embodiments can be described as, but are not limited to, the following supplementary notes.

[0098] (Supplementary Note 1) An apparatus comprising: an acquisition means for acquiring first configuration information including at least information about the topology of a computer system using components in the computer system; a configuration instantiation means for generating second configuration information that instantiates the configuration of the topology in the first configuration information; a threat instantiation means for determining whether an event that constitutes a threat to security may occur in the components of the instantiated topology, and, if an event that constitutes a threat may occur, generating third configuration information by adding to the second configuration information an identifier of the threat, the component where the threat may occur, identifiers of other threats that contribute to the occurrence of the threat, and information indicating relationships with the other components where the other threats may occur; and an analysis means for determining whether the content of each threat is concrete or abstract in a threat chain path based on the relationship between the threat in the third configuration information and other threats that contribute to the occurrence of the threat, and for determining whether the design of the computer system in the third configuration information is insecure when the content of the threat is concrete or abstract, The analysis means determines that the design of the computer system of the third configuration information is insecure if the content of the threat is concrete in all of the paths in the chain of threats, or if the content of the threat is abstract in any component of the path of the chain of threats but there is no way to avoid replacing the abstract threat with a concrete threat.

[0099] (Supplementary Note 2) The system design device according to Supplementary Note 1, wherein the configuration instantiation means generates the second configuration information by instantiating one of the predetermined units of grouping of components in the topology of the computer system of the first configuration information input at the start of processing, repeats a process of generating new second configuration information by instantiating one of the predetermined units of grouping of components in the topology of the computer system of the first configuration information, using third configuration information generated based on the second configuration information for which the design of the computer system has not been determined to be insecure as new first configuration information, repeats the process of generating the third configuration information based on the second configuration information, and when none of the predetermined units of grouping of components in the topology of the computer system of the third configuration information can be further instantiated and the design of the computer system of the third configuration information has not been determined to be insecure, outputs the third configuration information as a design result.

[0100] (Supplementary Note 3) The threat materialization means assigns to the third configuration information information indicating whether the threat information to be added to the second configuration information is concrete or abstract based on threat materialization rules that indicate threats defined according to the topology, and the analysis means determines, based on the information assigned to the third configuration information, that the design of the computer system in the third configuration information is insecure if it determines that the content of the threat is all concrete in the path of the threat chain, or that the content of the threat is abstract in any component of the path of the threat chain but there is no means to prevent the abstract threat from being replaced with a concrete threat. This is the system design device described in Supplementary Note 1 or Supplementary Note 2.

[0101] (Supplementary Note 4) The system design device described in any one of Supplementary Note 1 to Supplementary Note 3, wherein the analysis means, when the abstract threat is included in the path of the chain of threats, identifies the path as an abstract attack path indicating the path of the chain of threats from which a security attack may occur based on the threat included in the path, and when the abstract threat is not included in the path of the chain of threats, identifies the path as a concrete attack path indicating the path of the chain of threats from which a security attack may occur based on the threat included in the path.

[0102] (Supplementary Note 5) The system design device according to Supplementary Note 4, wherein the analysis means determines that there is no way to prevent the abstract threat from being replaced with a concrete threat when the content of the threat is such that any component of the abstract attack path is abstract and all components in which the abstract threat may occur cannot be given the characteristics to block the threat, and determines that the design of the computer system of the third configuration information is insecure.

[0103] 100... System design device 11... Input / output unit (acquisition means 181) 12... Configuration concrete unit (configuration concrete unit 182) 13... Threat concrete unit (threat concrete unit 183) 14... Analysis unit (analysis means 184)

Claims

1. An acquisition means for acquiring first configuration information including at least information on a topology of the computer system using components in the computer system; a configuration instantiation means for generating second configuration information that instantiates a configuration of the topology in the first configuration information; a threat materialization means for determining whether or not a security threatening event may occur in the components of the materialized topology, and generating third configuration information by adding, when a threatening event may occur, an identifier of the threat, the components in which the threat may occur, identifiers of other threats contributing to the occurrence of the threat, and information indicating a relationship with other components in which the other threats may occur to the second configuration information; an analysis means for determining whether the content of each threat is concrete or abstract in a path of a chain of threats based on a relationship between the threat in the third configuration information and other threats that contribute to the occurrence of the threat, and for determining whether the design of the computer system in the third configuration information is insecure when the content of the threat is concrete or abstract; Equipped with The analysis means determines that the design of the computer system of the third configuration information is insecure when the contents of the threats are all concrete in the path of the threat chain, or when the contents of the threats are abstract in any component of the path of the threat chain but there is no means of avoiding replacement of the abstract threat with a concrete threat. System design equipment.

2. The configuration embodiment means includes: generating the second configuration information by specifying one of the units of a grouping of the predetermined components in the topology of the computer system of the first configuration information input at the start of processing; repeating a process of generating new second configuration information that embodies one of the predetermined units of grouping of the components in the topology of the computer system of the first configuration information, using the third configuration information generated based on the second configuration information as new first configuration information, which is not determined to be insecure in terms of the design of the computer system; Repeating a process of generating the third configuration information based on the second configuration information; When none of the units of the predetermined grouping of components in the topology of the computer system of the third configuration information can be further instantiated and the design of the computer system of the third configuration information is not determined to be insecure, the third configuration information is output as a design result. The system design apparatus according to claim 1 .

3. the threat materialization means adds information indicating whether the information on the threat to be added to the second configuration information is concrete or abstract based on a threat materialization rule indicating a threat defined according to the topology, to the third configuration information; The analysis means determines that the design of the computer system of the third configuration information is insecure when it is determined based on the information added to the third configuration information that the contents of the threats are all concrete in the path of the threat chain, or that the contents of the threats are abstract in any component of the path of the threat chain but there is no means of preventing the abstract threat from being replaced with a concrete threat.

3. The system design device according to claim 1 or 2.

4. the analysis means, when the abstract threat is included in the path of the chain of threats, identifies the path as an abstract attack path indicating a path of the chain of threats along which a security attack may occur based on the threat included in the path; When the abstract threat is not included in the path of the chain of threats, the analysis means identifies the path as a concrete attack path indicating a path of the chain of threats that may cause a security attack based on the threat included in the path. The system design apparatus according to claim 3.

5. When the content of the threat is such that any component of the abstract attack path is abstract and all components in which the abstract threat may occur cannot be given the property of blocking the threat, the analysis means determines that there is no means of preventing the abstract threat from being replaced with a concrete threat, and determines that the design of the computer system of the third configuration information is insecure. The system design apparatus according to claim 4.

6. obtaining first configuration information including at least information on a topology of the computer system using components in the computer system; generating second configuration information that embodies a configuration of the topology in the first configuration information; determining whether or not a security threatening event may occur in the components of the embodied topology, and generating third configuration information by adding, to the second configuration information, information indicating a relationship between an identifier of the threat, the components in which the threat may occur, identifiers of other threats contributing to the occurrence of the threat, and other components in which the other threats may occur, if the security threatening event may occur; determining whether the content of each threat is concrete or abstract in a path of a chain of threats based on a relationship between the threat in the third configuration information and other threats that contribute to the occurrence of the threat, and determining whether the design of the computer system of the third configuration information is insecure when the content of the threat is concrete or abstract; A system design method which determines that the design of the computer system of the third configuration information is insecure if the content of the threat is all concrete in the path of the threat chain, or if the content of the threat is abstract in any component of the path of the threat chain but there is no way to avoid replacing the abstract threat with a concrete threat.

7. The computer of the system design equipment, An acquisition means for acquiring first configuration information including at least information on the topology of the computer system using components in the computer system; a configuration instantiation means for generating second configuration information that instantiates a configuration of the topology in the first configuration information; a threat materialization means for determining whether or not a security threatening event may occur in the components of the materialized topology, and generating third configuration information by adding, when a threatening event may occur, an identifier of the threat, the components in which the threat may occur, identifiers of other threats contributing to the occurrence of the threat, and information indicating a relationship with other components in which the other threats may occur to the second configuration information; an analysis means for determining whether the content of each threat is concrete or abstract in a path of a chain of threats based on a relationship between the threat in the third configuration information and other threats that contribute to the occurrence of the threat, and for determining whether the design of the computer system in the third configuration information is insecure when the content of the threat is concrete or abstract; Function as a The analysis means determines that the design of the computer system of the third configuration information is insecure when the contents of the threats are all concrete in the path of the threat chain, or when the contents of the threats are abstract in any component of the path of the threat chain but there is no means of avoiding replacement of the abstract threat with a concrete threat. program.