Secure system automated design device, secure system automated design method, and program

Abstract

To provide a technique for deriving a security evaluation value that can be compared with the security requirements of a user when automatically designing a system.SOLUTION: A secure system automated design device includes: means for receiving a design requirement of a system; means for generating a system configuration plan that satisfies the design requirement; means for deriving threats that are present in the system configuration plan, attack paths that are constituted by a chain of the threats, and countermeasures that are implemented with respect to the threats; and means for deriving a threat consideration priority indicating a priority with which the threats are to be considered, and an attack path consideration priority indicating a priority with which the attack paths are to be considered.SELECTED DRAWING: Figure 11

Description

[Technical Field]

[0001] The present disclosure relates to a secure system automatic design device, a secure system automatic design method, and a program. [Background technology]

[0002] Non-Patent Document 1 discloses a technology for automatically designing a secure system configuration (hereinafter referred to as "secure system automatic design technology"). This technology 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 generated specific system configurations.

[0003] The secure system automatic design technology described in Non-Patent Document 1 uses the concept of "threats" to represent attacks that a system designer wants to prevent during system automatic design and the means by which an attacker can execute those attacks. This technology comprehensively searches for the existence of "attack paths," which are chains of threats that indicate the steps an attacker could take to execute the attacks that the system designer wants to prevent, in a system configuration plan generated during system automatic design. This technology expresses security measures and functions implemented as countermeasures against threats using the concept of "countermeasures." This technology expresses countermeasures as being linked to threats. If a countermeasure is linked to one of the threats that make up the attack path, it is determined to be an "invalid attack path." If no countermeasure is linked to all of the threats that make up the attack path, it is determined to be a "valid attack path." This technology uses a security assessment method in which a system configuration plan with an effective attack path is determined to be "non-secure," and a system configuration plan with no effective attack path is determined to be "not non-secure."

[0004] The technology disclosed in Non-Patent Document 1 performs automated design by comprehensively considering all threats and attack paths that exist in the proposed configuration. As a result, there is a possibility that excessive countermeasures will be considered beyond the security measures expected by users who actually use the secure system automated design technology. In addition, because the technology is designed to consider all threats and attack paths that exist in the proposed system configuration and to consider the introduction of all possible countermeasures, the computational cost of secure automated design may increase.

[0005] Patent Document 1 discloses a vulnerability assessment device that assesses the threat level of security holes for each component of a computer device to be assessed and determines the priority of security measures. However, this device cannot automatically design a secure system configuration. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Japanese Patent Publication No. 2020-052686 [Non-patent literature]

[0007] [Non-Patent Document 1] Ryosuke Horichi, Takayuki Kuroda, "Automated Design Technology for Secure Systems Using Security Model Representation Based on Threats and Countermeasures," Institute of Electronics, Information and Communication Engineers, Network Virtualization (NV) Study Group, November 21, 2023, [Retrieved June 5, 2024], Internet<https: / / www.ieice.org / cs / nv / wp-content / uploads / 2023 / 11 / 20231121_NV_Hotchi_NEC.pdf> Summary of the Invention [Problem to be solved by the invention]

[0008] In order to automatically design a secure system based on the user's security requirements without introducing excessive security measures, it is necessary to derive information (referred to as a security evaluation value) that can be compared with the user's security requirements from a configuration plan, and if the derived security evaluation value satisfies the user's security requirements, it can be determined that no further security measures need to be introduced for the configuration plan.One of the objectives of this invention is to provide a technology that derives a security evaluation value that can be compared with the user's security requirements when automatically designing a secure system. [Means for solving the problem]

[0009] According to one aspect of the present disclosure, a secure system automatic design apparatus includes means for accepting system design requirements, means for generating a system configuration plan that satisfies the design requirements, means for deriving threats present in the system configuration plan, attack paths formed by a chain of the threats, and countermeasures taken against the threats, and means for deriving threat consideration priorities that indicate priorities for considering the threats, and attack path consideration priorities that indicate priorities for considering the attack paths.

[0010] According to one aspect of the present disclosure, a method for automatically designing a secure system accepts system design requirements, generates a system configuration plan that satisfies the design requirements, derives threats present in the system configuration plan, attack paths formed by chains of the threats, and countermeasures taken against the threats, and derives threat consideration priorities that indicate the priorities with which the threats should be considered, and attack path consideration priorities that indicate the priorities with which the attack paths should be considered.

[0011] According to one aspect of the present disclosure, the program causes a computer to function as a means for accepting system design requirements, a means for generating a system configuration plan that satisfies the design requirements, a means for deriving threats present in the system configuration plan, attack paths formed by a chain of the threats, and countermeasures taken against the threats, and a means for deriving a threat consideration priority that indicates the priority with which the threats should be considered, and an attack path consideration priority that indicates the priority with which the attack paths should be considered. [Effects of the Invention]

[0012] According to the present disclosure, it is possible to derive a security evaluation value that can be compared with the security requirements of a user. [Brief explanation of the drawings]

[0013] [Figure 1] 1 is a block diagram showing an example of a functional configuration of a secure system automatic design apparatus according to a first embodiment; [Figure 2] FIG. 2 is a diagram showing a legend for the representation methods used in the example of the system configuration plan according to the first embodiment. [Figure 3] FIG. 2 is a diagram illustrating an example of a security model according to the first embodiment. [Figure 4] FIG. 4 is a diagram showing an example of input requirement data according to the first embodiment. [Figure 5A] FIG. 1 is a first diagram showing an example of a system configuration plan in which no countermeasures are introduced, which is input to a consideration priority information update unit according to the first embodiment. [Figure 5B] FIG. 2 is a second diagram showing an example of a system configuration plan in which no countermeasures are introduced, which is input to the consideration priority information update unit according to the first embodiment. [Figure 6A] FIG. 1 is a first diagram showing an example of a system configuration plan in which countermeasures are introduced, which is input to a consideration priority information update unit according to the first embodiment. [Figure 6B] FIG. 2 is a second diagram showing an example of a system configuration plan in which countermeasures are introduced, which is input to the consideration priority information update unit according to the first embodiment. [Figure 7]FIG. 2 is a diagram showing an example of a system configuration plan immediately after deriving threat consideration priorities according to the first embodiment. [Figure 8] 4 is a flowchart showing the operation of the secure system automatic design apparatus according to the first embodiment. [Figure 9] FIG. 10 is a diagram illustrating an example of a security model according to the second embodiment. [Figure 10] FIG. 11 is a diagram showing an example of a system configuration plan immediately after deriving threat consideration priorities according to the second embodiment. [Figure 11] FIG. 11 is a block diagram showing an example of a functional configuration of a secure system automatic design apparatus according to a third embodiment. [Figure 12] 11 is a flowchart showing an example of an operation of the secure system automatic design apparatus according to the third embodiment. [Figure 13] FIG. 2 is a diagram illustrating an example of a hardware configuration of a secure system automatic design apparatus according to each embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0014] Hereinafter, a secure system automatic design device according to each embodiment of the present disclosure will be described with reference to the drawings. In the drawings used in the following description, the description of parts not related to the present disclosure may be omitted or not shown. The same or equivalent parts in all drawings will be assigned the same reference numerals, and common descriptions may be omitted.

[0015] First Embodiment (composition) A secure system automatic design device according to a first embodiment of the present disclosure will be described. Fig. 1 is a block diagram showing an example of a functional configuration of the secure system automatic design device according to the first embodiment. As shown in Fig. 1, the secure system automatic design device 100 includes an input / output unit 101, a configuration information instantiation unit 102, and a consideration priority information update unit 103. The input / output unit 101 receives as input the requirement data that is the subject of secure system design, and transmits it to the configuration information instantiation unit 102. It also receives a system configuration plan that has been instantiated from the configuration information instantiation unit 102, and outputs the system configuration plan to a display device, electronic file, or the like as the design result of the secure system design device.

[0016] The configuration information instantiation unit 102 creates a search tree based on the requirements data received from the input / output unit 101, applies a "configuration instantiation process" to the requirements data, and sends it to the consideration priority information update unit 103 to assign various consideration priority information to threats and attack paths present in the generated system configuration plan. The search tree is generated in the process of generating a concrete configuration from the input requirements data and is expressed as a tree-structured graph with the requirements data as the root node. Leaf nodes represent concrete configuration plans for the system, including configuration plans in the design stage. In the process of searching for a concrete configuration in the search tree, the configuration instantiation process is applied to leaf nodes representing concrete configuration plans in the process of being instantiated, generating concrete configuration plans in which abstract elements are partially instantiated as leaf nodes representing the next state. As disclosed in Non-Patent Document 1, in the process of generating a concrete configuration, the configuration information instantiation unit 102 derives threats present in the proposed system configuration based on a threat model (not shown), derives what other threats are necessary in the proposed system configuration to realize those threats based on a threat realization model (not shown), and adds these derived threats to the proposed system configuration. The configuration information instantiation unit 102 also generates attack paths that indicate how cyberattacks are realized by combining the added threats. The configuration information instantiation unit 102 also adds effective countermeasures to the proposed system configuration based on a countermeasure model (not shown), which defines what countermeasures can be implemented to prevent or mitigate the added threats. In this process, the configuration information instantiation unit 102 sends the concrete configuration plan to which the threats, attack paths, countermeasures, etc. have been added to the consideration priority information update unit 103. The system configuration plan with updated consideration priority information is then received from the consideration priority information update unit 103, and a determination is made as to whether the system configuration plan is non-secure. If the system configuration plan is not non-secure, and if it is a specific configuration, the system configuration plan is sent to the input / output unit 101 as a design result. If the system configuration plan is not a specific configuration, the system configuration plan is added to the search tree. Thereafter, a system configuration plan that is not a specific configuration is selected from the search tree, and the above process is repeated.The "configuration concretization process" is disclosed, for example, in International Publication No. 2019 / 216082 and is publicly known.

[0017] The consideration priority information update unit 103 receives the system configuration plan from the configuration information instantiation unit 102, sets threat consideration priorities for threats based on the security model (Figures 3 and 9) described below, and derives attack path consideration priorities for attack paths.

[0018] Next, the data handled in the first embodiment will be described. FIG. 2 shows a legend for the representation used in an example of a system configuration plan according to the first embodiment. FIG. 2(a) shows a legend for the diagram representation, and FIG. 2(b) shows a legend for the text representation. The system configuration plan is represented by nodes representing components constituting the system and edges showing the relationships between the two components. As shown in FIG. 2(a), in the diagram representation of the system configuration plan, nodes are represented by circles and edges are represented by solid arrows. An ID identifying each node is written inside the circle representing the node. Edges, particularly those of the "SendCredential" type, are represented by a curved arrow with a cylinder icon and a person icon on top. Also, as shown in FIG. 2(a), threats are represented by a virus icon, and countermeasures are represented by an icon of a padlock on a shield. The target relationship between which countermeasures prevent or mitigate which threats is indicated by dashed arrows, and the chain route of threats constituting the attack path (the concrete relationship between which threats are concreted) is indicated by dotted arrows.

[0019] The text description example of the proposed system configuration is created in YAML format. Figure 2(b) shows fields for describing information about the configuration and security of the proposed system configuration. The configuration information includes node and edge information, and the security information includes tolerances, threats, countermeasures, and attack paths. In Figure 2(b), the ID and type name of each node in the proposed system configuration are listed. The ID, type name, edge source node ID, and edge destination node ID are listed for each edge. The threat information includes the type name, location, and threat consideration priority. The countermeasure information includes the countermeasure type name, countermeasure location, target threat type name, and target threat location. The attack path information includes the type names, locations, and attack path consideration priorities of all threats that make up the attack path. The threat consideration priorities in the threat column and the attack path consideration priorities in the attack path column are provided by the consideration priority information update unit 103 based on the security model shown in Figure 3, which will be described next. In this disclosure, various consideration priorities are expressed by continuous quantitative values ​​from 0.0 to 1.0. The target threat in the countermeasure column refers to the threat that the countermeasure is intended to prevent or mitigate. In addition, as shown in Figure 2(b), in this disclosure, a tolerance can be defined as security information for a system configuration proposal. This tolerance value is a continuous quantitative value from 0.0 to 1.0 defined in the input requirements for secure system automated design technology, and when this value is defined, the attack path tolerance can be used to determine the security of the system configuration proposal.

[0020] FIG. 3 shows an example of a security model used in the first embodiment. The security model shown in FIG. 3 describes information about threats and countermeasures. FIG. 3 has fields for describing threat information and countermeasure information. The threat information describes the type name and consideration priority, and the countermeasure information describes the type name and target threat. The threat consideration priority has a continuous quantitative value ranging from 0.0 to 1.0, and is a parameter used when deriving the threat consideration priority of a threat that actually exists in a system configuration plan. The security model shown in FIG. 3 is stored so as to be referable by the configuration information instantiation unit 102 and the consideration priority information update unit 103.

[0021] 4 shows an example of requirement data input to the secure system automatic design device in the first embodiment. FIG. 4(a) is an example of the requirement data shown in a diagram, and FIG. 4(b) is an example of the requirement data shown in text. The requirement data shown in FIG. 4 has two APP type nodes, App1 and App2, which are SendCredential<APP, APP> The figure shows a structure in which the attack paths are connected by edges of a type. In addition, an attack path consideration threshold of 0.7 is input as security requirement information. The attack path consideration threshold is referenced by the configuration information instantiation unit 102 together with the attack path consideration priority. When the attack path consideration threshold is defined in the requirement data, an attack path having an attack path consideration priority lower than the threshold is deemed "not to be considered," and the introduction of countermeasures for that attack path is not considered. Even if the attack path is a "valid attack path," it is determined to be "not insecure."

[0022] 5A to 6B are examples of system configuration plans input to the consideration priority information update unit 103 in the first embodiment. Figures 5A and 5B show example system configuration plans in which countermeasures are not introduced, and Figures 6A and 6B show example system configuration plans in which countermeasures are introduced. Figures 5A and 6A are diagrammatic representations of the respective system configuration plans, and Figures 5B and 6B are textual representations of the respective system configuration plans. Figures 5A and 5B show a configuration in which two APP-type applications, App1 and App2, are hosted on PhysicalMachine1 and PhysicalMachine2, respectively, and these two physical machines are connected to a Router-type router (Router1), in order for the two APP-type applications to communicate. The diagram also shows that a CredentialAccess-type threat exists on the SendCredential-type edge connecting App1 and App2, a NetworkSniffing-type threat exists on the HTTP-type edge connecting App1 and App2, and a NetworkDeviceCLI-type threat exists on Router1. The diagram also shows that the CredentialAccess-type threat is embodied in the NetworkSniffing-type threat, and that the NetworkSniffing-type threat is embodied in the NetworkDeviceCLI-type threat. Furthermore, when the route connecting the CredentialAccess type threat, the NetworkSniffing type threat, and the NetworkDeviceCLI type threat, indicated by the dashed arrows, is established without any obstruction, a valid attack path is established and the system becomes insecure.

[0023] The system configuration examples shown in Figures 6A and 6B are almost the same as the configurations in Figures 5A and 5B, but differ in that instead of an HTTP-type edge connecting App1 and App2, an HTTPS-type edge exists, and a NetworkSniffing-type threat and an EncryptedCommunication-type countermeasure exist on the HTTPS-type edge, and the countermeasures are shown to be targeting the mitigation of the threats. As shown in Figure 6A, if countermeasures are taken against the NetworkSniffing-type threat and the routes connecting the CredentialAccess-type threat, NetworkSniffing-type threat, and NetworkDeviceCLI-type threats indicated by the dashed arrows are blocked, it becomes an invalid attack path, and the system is no longer necessarily insecure.

[0024] The information on security threats and countermeasures described in Figures 5A to 6B may be provided as system requirements (requirements data). Alternatively, for example, the configuration information instantiation unit 102 may have a function for generating threat and countermeasure information by referencing the security model illustrated in Figure 3 during the instantiation process, and the information may be generated from the requirements data of Figures 4(a) and 4(b) using this function. The generation of threat information is disclosed in, for example, embodiment 2 (paragraphs 0041 and following) of International Publication No. 2023 / 042257, in addition to Non-Patent Document 1. The threat information is defined in a threat model (not shown) so that it is automatically generated when specific components or relationships (nodes or edges) are present in the proposed system configuration. The threat information may be generated by referring to this threat model. Furthermore, the generation of countermeasure information is disclosed in, for example, Japanese Patent Application No. 2023-098467, in addition to Non-Patent Document 1, and may be generated based on the "countermeasure information" described in the countermeasure model (Figure 5B of Japanese Patent Application No. 2023-098467). For example, the "countermeasure information" includes at least the information on "type" and "target threat," and if a "target threat" exists in a certain system configuration proposal, countermeasures for the type specified in the "type" may be generated in a manner linked to the "target threat."

[0025] Figure 7 shows the results of the first embodiment in which the threat consideration priorities and attack path consideration priorities are derived and reflected by the consideration priority information update unit 103 for the system configuration example shown in Figures 5A to 6B. Figure 7(a) shows the results of updating various consideration priority information for the system configuration example in Figure 5, and Figure 7(b) shows the results of updating various consideration priority information for the system configuration example in Figure 6. In FIG. 7(a), the threat consideration priority values ​​of the threat information listed in the security model example shown in FIG. 3 are transcribed as they are for the three threats listed in the threat column. In the example of this embodiment, the attack path consideration priority is derived by multiplying the threat consideration priorities of all threats that make up the attack path. In the example shown in FIG. 7(a), the only existing attack path consists of three threats: a "CredentialAccess type threat existing on $App1SendCredentialToApp2," a "NetworkSniffing type threat existing on $App1ConnToApp2," and a "NetworkDeviceCLI type threat existing on $Router1." Therefore, the threat consideration priorities of the threats that make up the attack path are "1.0," "0.9," and "0.8," respectively. Therefore, the attack path consideration priority of the attack path is "1.0 x 0.9 x 0.8 = 0.72," and therefore, in the example shown in FIG. 7(a), the value 0.72 is assigned to the consideration priority column of the attack path. Note that the attack path consideration threshold shown in Figure 7(a) is 0.7, and the attack path consideration priority of the attack path in question, 0.72, is not lower than the attack path threshold, so the attack path in question is not "not considered."

[0026] The example of FIG. 7(b) differs from the example of FIG. 7(a) in that an EncryptedCommunication-type countermeasure targeting the "NetworkSniffing-type threat present on $App1ConnToApp2" is included. In this embodiment, the threat consideration priority in the proposed system configuration is the same as the value defined in the security model if no countermeasure is associated with it, and is 0.0 if a countermeasure is associated with it, which is interpreted as "the countermeasure has prevented the threat from occurring." Therefore, the threat consideration priorities of the two threats, the "CredentialAccess-type threat present on $App1SendCredentialToApp2" and the "NetworkDeviceCLI-type threat present on $Router1," which are not associated with a countermeasure, are "1.0" and "0.8," respectively, the same as in the example of FIG. 7(a). The threat consideration priority of the "NetworkSniffing-type threat present on $App1ConnToApp2," which is associated with a countermeasure, is "0.0." Furthermore, in the example of this embodiment, the attack path consideration priority is derived from the product of the threat consideration priorities of all threats that constitute the attack path. Therefore, in the example of FIG. 7(b), the consideration priority of the attack path is "1.0 x 0.0 x 0.8 = 0.0," and the value 0.0 is assigned to the consideration priority column of the attack path. Furthermore, the attack path consideration threshold shown in FIG. 7(b) is 0.7, and the attack path consideration priority of the attack path, 0.0, is a value lower than the attack path threshold, so the attack path is "not considered." Therefore, in the configuration plan generated by applying the configuration instantiation process to the example configuration plan of FIG. 7(b), the introduction of countermeasures for the three threats that constitute the attack path is not further considered.

[0027] (operation) Next, the operation of the first embodiment of the secure system automatic design apparatus will be described. FIG. 8 is a flowchart showing the operation of the secure system automatic design apparatus according to the first embodiment. First, the input / output unit 101 receives requirement data input from a user or another system, defining the requirements that a system to be automatically designed must have, and adds the data to a search tree (S101). For example, the requirement data illustrated in FIG. 4 is input. The input / output unit 101 then transmits the search tree information to the configuration information instantiation unit 102. Next, the configuration information instantiation unit 102 selects one system configuration plan to be instantiated from the search tree (S102). The system configuration plan to be instantiated is arbitrary. The attack path consideration priority in the system configuration plan is used as a selection criterion for determining which system configuration plan to target. (The attack path consideration priority is not initially set, but is derived and set by the consideration priority information update unit 103 during the instantiation process. For example, the system configuration plan with the highest or lowest attack path consideration priority, or the first system configuration plan found with an attack path consideration priority greater than a predetermined value, can be selected.) Once the system configuration plan to be targeted is selected, a configuration plan instantiation process is performed on the system configuration plan (S103). The configuration proposal instantiation process generates information on countermeasures against threats. The instantiated system configuration proposals are shown in Figures 5A to 6B. As a result, it is determined whether one or more system configuration proposals have been generated (S104). If one or more instantiated configuration proposals have been generated, the process proceeds to S105. If no system configuration proposals have been generated, the process proceeds to the determination in S114.

[0028] When one or more system configuration plans are generated in the configuration information instantiation process, all of the system configuration plans are sent to the consideration priority information update unit 103, and a threat consideration priority information update process and an attack path consideration priority information update process are executed for all of the system configuration plans in order (S105). First, a threat consideration priority information update process is executed for the instantiated configuration plans (S106). The consideration priority information update unit 103 sets a consideration priority for each threat in the system configuration plan by referring to the security model illustrated in FIG. 3. At this time, as described in FIG. 7, if countermeasures have been formulated against a threat, the consideration priority information update unit 103 sets the consideration priority for the threat to "0.0". Next, an attack path consideration priority information update process is executed for the system configuration plan (S107). The consideration priority information update unit 103 calculates the consideration priority of the attack path by multiplying the consideration priority set for each threat, and updates the item with the calculated value. Once the update of the attack path consideration priority information for the system configuration plan is complete, the result is sent to the configuration information instantiation unit 102, which determines whether the system configuration plan is non-secure (S108). For example, the configuration information instantiation unit 102 compares the consideration priorities of all attack paths updated by the consideration priority information update unit 103 with the attack path consideration threshold. If the consideration priorities of any attack path are equal to or greater than the attack path consideration threshold, the configuration information instantiation unit 102 determines the system configuration plan to be "non-secure." If the consideration priorities of all attack paths are lower than the attack path consideration threshold, the configuration information instantiation unit 102 determines the system configuration plan to be "not non-secure." In addition, the configuration information instantiation unit 102 also determines the system configuration plan to be "not non-secure" if no attack path exists in the system configuration plan. If the determination result is "non-secure," the system configuration plan is rejected (S109). If the determination result is "not non-secure," the system configuration plan is investigated to determine whether it is a concrete configuration plan (S110). Note that "non-secure" here means that there are no valid attack paths, or that all valid attack paths that exist are determined to be "not to be considered."Furthermore, the term "concrete configuration plan" here refers to a configuration plan in which all of the components that make up the system are configured with concrete nodes and edges, while satisfying all of the requirements indicated by the requirement data initially input to the input / output unit 101. If the system configuration plan is concrete, the configuration information instantiation unit 102 sends the system configuration plan to the input / output unit 101 and outputs it as the design result of the secure system automatic design device (S113). On the other hand, if the system configuration plan is not concrete, the configuration information instantiation unit 102 adds the system configuration plan to the search tree (S111).

[0029] After performing the process of S109 or S111, it is checked whether the series of processes from the threat consideration priority information update process (S106) to the security judgment (S109 or S111) have been performed on all system configuration plans generated in the configuration information instantiation process (S112). If there is a system configuration plan to which the series of processes has not been applied, the process returns to S105 and repeats. If there is no system configuration plan to which the series of processes has not been applied, it is checked whether there are any system configuration plans remaining in the search tree that have not been selected as targets for the configuration instantiation process (S114). If there are no unselected system configuration plans remaining in the search tree, it means that there is no method remaining in the secure system automatic design device to instantiate the requirements data while satisfying the security requirements, and a design failure is output from the input / output unit 101 (S116). If there are any unselected system configuration plans remaining in the search tree, a new system configuration plan to be instantiated is selected from the search tree (S115), and the process returns to S103 and repeats the configuration information instantiation process. As in S102, the configuration information instantiation unit 102 can select a system configuration plan from the search tree using the attack path consideration priority.

[0030] (effect) As described above, according to the first embodiment, a tolerance (threshold for considering attack paths) is set in the requirements data as security information for the proposed system configuration, and the system is then instantiated and determined to be secure. In the secure determination, if the effectiveness of the attack path (the priority for considering the attack path) is within the tolerance, the system is determined to be not insecure, and is determined to be a valid system configuration that meets the user's requirements. In other words, a secure system can be automatically designed by limiting the threats and attack paths that need to be addressed based on the user's security requirements. This makes it possible to prevent the search for systems that have excessive security measures implemented.

[0031] Second Embodiment The second embodiment differs from the first embodiment in that the "threat materialization relationship consideration priority" is also used to derive the attack path consideration priority.

[0032] (composition) The configuration of the secure system automatic design apparatus 100 according to the second embodiment is similar to that of the first embodiment illustrated in FIG. 1. Next, the data handled in the second embodiment will be described. The legend for the representation used in the example of the system configuration plan handled in the second embodiment is the same as that in the first embodiment and is shown in FIG. 2. FIG. 9 shows an example of a security model used in the second embodiment. The security model example shown in FIG. 9 differs from FIG. 3 in that it includes a field for describing threat instantiation relationship information. The example shown in FIG. 9 indicates that when a NetworkSniffing type threat is instantiated from a CredentialAccess type threat, the threat instantiation relationship consideration priority assigned to the threat instantiation relationship is 1.0, and when a NetworkDeviceCLI type threat is instantiated from a NetworkSniffing type threat, the threat instantiation relationship consideration priority assigned to the threat instantiation relationship is 0.95. For example, the threat consideration priority of the threat information can be set to the probability that the threat itself will be executed, and the threat instantiation relationship consideration priority can be set to the probability that an attacker will execute the original threat after executing the original threat. The threat concretization relationship consideration priority is a parameter that reflects the difference in the occurrence rate of each type of threat concretization relationship, for example, when there are two types of threat concretization relationships, such as threat A → threat X and threat B → threat X, in the consideration priority of the attack path. For example, if the threat concretization from threat A → threat X is likely to occur in reality, but threat B → threat X is a rare case that is not seen very often, a lower threat concretization relationship consideration priority can be set for the latter than for the former. In other words, the threat concretization relationship consideration priority is a parameter that reflects the variability in the probability that the original threat will be executed after the concretization target threat is executed, which can vary depending on various factors such as the type of the original or target threat and its location in the topology. Introducing the threat concretization relationship consideration priority enables more realistic evaluation and scoring of threats.

[0033] FIG. 10 is a text representation of the result of deriving and reflecting threat consideration priorities and attack path consideration priorities in the consideration priority information update unit 103 for the system configuration example shown in FIG. 5. The example shown in FIG. 10 is basically the same as the content shown in FIG. 7(a), except that the attack path consideration priority value is 0.684. In the example of this embodiment, the attack path consideration priority is derived by multiplying the threat consideration priorities of all threats that make up the attack path by the product of the threat instantiation relationship consideration priorities of all threat instantiation relationships connecting the threats. In the example shown in FIG. 10, the only existing attack path consists of three threats: a "CredentialAccess type threat existing on $App1SendCredentialToApp2," a "NetworkSniffing type threat existing on $App1ConnToApp2," and a "NetworkDeviceCLI type threat existing on $Router1." The threat consideration priorities of the threats that make up this attack path are "1.0," "0.9," and "0.8," respectively, and the product of these threat consideration priorities is "1.0 x 0.9 x 0.8 = 0.72." Furthermore, there are two threat instantiation relationships connecting the threats that make up this attack path: "From the CredentialAccess type threat on $App1SendCredentialToApp2 to the NetworkSniffing type threat on $App1ConnToApp2," and "From the NetworkSniffing type threat on $App1ConnToApp2 to the NetworkDeviceCLI type threat on $Router1." The consideration priorities of these threat instantiation relationships are "1.0" and "0.95," as shown in Figure 9, and therefore the product of the threat instantiation relationship consideration priorities is "1.0 x 0.95 = 0.95." Therefore, the product of the threat consideration priorities of all threats that make up the attack path and the product of the threat instantiation relationship consideration priorities of all threat instantiation relationships connecting the threats is "0.72 x 0.95 = 0.684", and in the example shown in Figure 10, the value 0.72 is assigned to the consideration priority column of the attack path.The attack path consideration threshold shown in FIG. 10 is 0.7, and the attack path consideration priority of the attack path, 0.684, is a value lower than the attack path threshold, so the attack path is "not considered."

[0034] (operation) Next, the operation of the second embodiment will be described. The operation of the second embodiment is basically the same as that of the first embodiment, and the flowchart showing the operation of the second embodiment is the same as that shown in FIG. 8. The difference from the operation of the first embodiment is the method of updating the attack path consideration priority information (S107). In the second embodiment, the attack path consideration priority is derived by the consideration priority information update unit 103 as the product of the threat consideration priorities of all threats constituting the attack path and the product of the threat concrete relationship consideration priorities of all threat concrete relationships connecting the threats. At this time, as in the first embodiment, if countermeasures have been formulated against a threat, the consideration priority for the threat is set to "0.0". All other operations (S101 to S106, S108 to S116) are the same as those described in the first embodiment.

[0035] (effect) As described above, according to the second embodiment, similar to the first embodiment, by deriving a security evaluation value (attack path consideration priority) comparable to the user's security requirements (tolerance value), it is possible to automatically design a secure system based on the user's security requirements without introducing excessive security measures. Furthermore, by introducing threat specificity related information and calculating the attack path consideration priority, it is possible to perform a more realistic evaluation of the threats in the system configuration guide and determine whether or not it is "unsecure."

[0036] <Third embodiment> FIG. 11 is a block diagram showing an example of a functional configuration of a secure system automatic design apparatus according to the third embodiment. The secure system automatic design device 800 comprises a receiving means 801 that receives design requirements for the system, including tolerances for security requirements that the system must satisfy; a generating means 802 that generates a system configuration plan that satisfies the design requirements; a threat etc. deriving means 803 that derives threats that exist in the system configuration plan, attack paths formed by chains of the threats, and countermeasures taken against the threats; and an evaluation value deriving means 804 that derives threat consideration priorities that indicate the priorities at which the threats should be considered, and attack path consideration priorities that indicate the priorities at which the attack paths should be considered. The attack path tolerance is an example of a tolerance of a security requirement that a system must satisfy. The input / output unit 101 is an example of a receiving means 801. The configuration information instantiating unit 102 is an example of a generating means 802 and a threat etc. deriving means 803. The consideration priority information updating unit 103 is an example of an evaluation value deriving means 804.

[0037] FIG. 12 is a flowchart showing an example of the operation of the secure system automatic design apparatus according to the third embodiment. A receiving means 801 receives design requirements for the system including tolerances for security requirements that the system must satisfy (S801), a generating means 802 generates a system configuration plan that satisfies the design requirements (S802), a threat etc. deriving means 803 derives threats present in the system configuration plan, attack paths formed by chains of the threats, and countermeasures taken against the threats (S803), and an evaluation value deriving means 804 derives threat consideration priorities that indicate the priorities at which the threats should be considered and attack path consideration priorities that indicate the priorities at which the attack paths should be considered (S804).

[0038] 13 is a diagram showing an example of the hardware configuration of a secure system automatic design apparatus according to each embodiment. A computer 900 includes a CPU 901, a main storage device 902, an auxiliary storage device 903, an input / output interface 904, and a communication interface 905. The above-described secure system automatic design apparatuses 100 and 800 are implemented in the computer 900. The above-described functions are stored in the auxiliary storage device 903 in the form of a program. The CPU 901 reads the program from the auxiliary storage device 903, loads it into the main storage device 902, and executes the above-described processing in accordance with the program. The CPU 901 also allocates a storage area in the main storage device 902 in accordance with the program. The CPU 901 also allocates a storage area in the auxiliary storage device 903 for storing data being processed in accordance with the program.

[0039] A program for implementing all or part of the functions of the secure system automatic design devices 100 and 800 may be recorded on a computer-readable recording medium, and the program may be loaded into a computer system and executed to perform processing by each functional unit. The term "computer system" as used herein includes hardware such as an OS and peripheral devices. Furthermore, if a WWW system is used, the term "computer system" also includes a homepage providing environment (or display environment). Furthermore, the term "computer-readable recording medium" refers to portable media such as CDs, DVDs, and USBs, as well as storage devices such as hard disks built into the computer system. Furthermore, if the program is distributed to the computer 900 via a communication line, the computer 900 may load the program into the main storage device 902 and execute the above-described processing. Furthermore, the program may be for implementing part of the above-described functions, or may be capable of implementing the above-described functions in combination with a program already stored in the computer system.

[0040] Although one embodiment of the present disclosure has been described in detail above with reference to the drawings, the specific configuration is not limited to the above, and various design modifications are possible within the scope of the gist of the present invention. Furthermore, one aspect of the present disclosure may be modified in various ways within the scope of the claims, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present disclosure. Furthermore, configurations in which elements described in the above embodiments and variations are substituted with elements that achieve the same effect are also included. Furthermore, each embodiment may be combined with other embodiments as appropriate.

[0041] A part or all of the above-described embodiments can be described as, but not limited to, the following supplementary notes.

[0042] (Appendix 1) The secure system automatic design device includes: means for accepting system design requirements; means for generating a system configuration plan that satisfies the design requirements; means for deriving threats present in the system configuration plan, attack paths formed by a chain of the threats, and countermeasures taken against the threats; and means for deriving threat consideration priorities that indicate priorities for considering the threats, and attack path consideration priorities that indicate priorities for considering the attack paths.

[0043] (Appendix 2) The means for deriving the attack path consideration priorities is the secure system automatic design device described in Appendix 1, which derives the threat consideration priorities for all threats present in the system configuration guide by referring to security model information, and derives the attack path consideration priorities for all attack paths based on information on threats and countermeasures present in the system configuration guide.

[0044] (Appendix 3) The means for deriving the attack path consideration priorities is a secure system automatic design device as set forth in Supplementary Note 1 to Supplementary Note 2, which derives the threat consideration priorities for all the threats present in the system configuration guide by referring to security model information, derives threat materialization relationship consideration priorities that indicate the priorities that should be considered for relationships between the threats, and derives the attack path consideration priorities for all the attack paths based on information on the threats, the countermeasures, and the relationships between the threats that are present in the system configuration guide.

[0045] (Appendix 4) The secure system automatic design device according to any one of appendices 1 to 3, wherein the receiving means receives an acceptable value for the security of the system, and the generating means compares the attack path consideration priority for each attack path with the acceptable value, and determines that the system configuration plan is not insecure if all the attack path consideration priorities are less than the acceptable value.

[0046] (Appendix 5) The secure system automatic design device according to any one of claims 1 to 4, wherein the receiving means receives an allowable value for the security of the system, and the means for deriving countermeasures compares the attack path consideration priority for each attack path with the allowable value, and does not derive the countermeasure for any attack path for which the attack path consideration priority is less than the allowable value.

[0047] (Appendix 6) The means for deriving the attack path consideration priority is the secure system automatic design device described in Appendix 2, which derives the attack path consideration priority by multiplying the threat consideration priorities derived for all the threats that constitute the attack path, and at that time, sets the threat consideration priority of the threat for which the countermeasure has been derived to 0.

[0048] (Appendix 7) The means for deriving the attack path consideration priority is the secure system automatic design device described in Appendix 3, which derives the attack path consideration priority by multiplying the threat consideration priority derived for all the threats that constitute the attack path by the threat materialization relationship consideration priority derived for the relationships between all the threats that constitute the attack path, and at that time, sets the threat consideration priority of the threat for which the countermeasure has been derived to 0.

[0049] (Appendix 8) A secure system automatic design method in which an automatic secure system design device accepts system design requirements, generates a system configuration plan that satisfies the design requirements, derives threats present in the system configuration plan, attack paths formed by chains of the threats, and countermeasures taken against the threats, and derives threat consideration priorities that indicate the priorities with which the threats should be considered, and attack path consideration priorities that indicate the priorities with which the attack paths should be considered.

[0050] (Appendix 9) This program causes a computer to function as a means for accepting system design requirements, a means for generating a system configuration plan that satisfies the design requirements, a means for deriving threats present in the system configuration plan, attack paths formed by a chain of the threats, and countermeasures taken against the threats, and a means for deriving threat consideration priorities that indicate the priorities at which the threats should be considered, and attack path consideration priorities that indicate the priorities at which the attack paths should be considered. [Explanation of symbols]

[0051] 100 Secure System Automated Design Equipment 101...Input / output section 102 Configuration information instantiation unit 103...Consideration priority information update section 800 Secure System Automated Design Equipment 801... Reception method 802...Generation means 803···Threat Derivation Method 804... Evaluation value derivation means 900···Computer 901 CPU 902...Main memory 903...Auxiliary storage device 904 Input / Output Interface 905···Communication Interface

Claims

1. a means for accepting design requirements for the system; means for generating a system configuration plan that satisfies the design requirements; a means for deriving threats present in the proposed system configuration, attack paths formed by a chain of the threats, and countermeasures taken against the threats; a means for deriving a threat consideration priority indicating a priority to be considered for the threat and an attack path consideration priority indicating a priority to be considered for the attack path; A secure system automatic design device comprising:

2. The means for deriving the attack path consideration priority includes: deriving the threat consideration priorities for all threats present in the system configuration guide by referring to security model information; Deriving the attack path consideration priorities for all attack paths based on information on threats and countermeasures present in the system configuration guide; 2. The secure system automatic design device according to claim 1.

3. The means for deriving the attack path consideration priority includes: By referring to security model information, the threat consideration priority is derived for all of the threats present in the system configuration guide, and a threat materialization relationship consideration priority indicating a priority for consideration of relationships between the threats is derived; deriving the attack path consideration priorities for all the attack paths based on information on the threats, the countermeasures, and the relationships between the threats present in the system configuration guide; 2. The secure system automatic design device according to claim 1.

4. the accepting means accepts a security tolerance value for the system; the means for generating the system configuration plan compares the attack path consideration priority for each attack path with the tolerance value, and determines that the system configuration plan is not insecure if all the attack path consideration priorities are less than the tolerance value.

3. The secure system automatic design device according to claim 1.

5. The means for deriving the countermeasures includes: comparing the attack path consideration priority for each attack path with the tolerance value, and not deriving the countermeasure for the attack path whose attack path consideration priority is less than the tolerance value; 5. The secure system automatic design device according to claim 4.

6. The means for deriving the attack path consideration priority includes: deriving the attack path consideration priority by multiplying the threat consideration priorities derived for all the threats constituting the attack path; At this time, the threat consideration priority of the threat for which the countermeasure has been derived is set to 0.

3. The secure system automatic design device according to claim 2.

7. The means for deriving the attack path consideration priority includes: deriving the attack path consideration priority by multiplying the threat consideration priority derived for all the threats constituting the attack path by the threat materialization relationship consideration priority derived for the relationships between all the threats constituting the attack path; At this time, the threat consideration priority of the threat for which the countermeasure has been derived is set to 0.

4. The secure system automatic design device according to claim 3.

8. Secure system automatic design equipment Accepting system design requirements, generating a system configuration plan that satisfies the design requirements; Deriving threats present in the proposed system configuration, attack paths formed by a chain of the threats, and countermeasures taken against the threats; deriving a threat consideration priority indicating a priority to be considered for the threat and an attack path consideration priority indicating a priority to be considered for the attack path; A method for automated secure system design.

9. Computer, a means for accepting design requirements for the system; means for generating a system configuration plan that satisfies the design requirements; a means for deriving threats present in the proposed system configuration, attack paths formed by a chain of the threats, and countermeasures taken against the threats; a means for deriving a threat consideration priority indicating a priority to be considered for the threat and an attack path consideration priority indicating a priority to be considered for the attack path; A program to function as a

Images