Security design support device, security design support method, and security design support program

Abstract

To provide a security design support device, a method and a program which suppress a generation amount of a threat scenario of multi-hop with low feasibility.SOLUTION: A security design support device 100 includes: an input unit 101 which inputs system information; a threat scenario generation unit 105 which generates a first threat scenario which indicates a threat on security which may occurs; a risk level evaluation unit 108 which finds a risk level of the first threat scenario; a takeover possibility evaluation unit 112 which estimates possibility in which a subsystem is taken over, by using second feasibility which is feasibility of the first threat scenario when taking a countermeasure required for the first threat scenario in which the risk level is equal to or more than a predetermined level; an addition threat scenario generation unit 113 which generates a second threat scenario indicating the threat on the security which may happen in the subsystem having the takeover possibility as an initial point, when the takeover possibility is equal to or more than the predetermined level; and an output unit 115 which outputs the second threat scenario.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present invention relates to an apparatus, a method, and a program for supporting efficient threat analysis and risk assessment for a system. [Background technology]

[0002] In recent years, technologies for driving assistance and autonomous driving control, including V2X (vehicle-to-vehicle communication and vehicle-to-infrastructure communication), have been attracting attention. As a result, vehicles are being equipped with communication functions, and so-called connected vehicles are becoming more common. As a result, the possibility of vehicles being subject to cyber attacks such as unauthorized access is increasing. For this reason, it is necessary to identify, analyze, and evaluate the risks assumed for vehicles, and reduce the assumed risks based on the results. Such risk assessment activities are summarized and recommended in ISO / SAE21434 as Threat Analysis and Risk Assessment (TARA).

[0003] For example, Patent Document 1 discloses a configuration for efficiently extracting threats that may occur in the vast assets of a large-scale system, in which a database storing knowledge about threats is used to identify groups of similar threats by comparing the characteristics of the threats in the target system with a database, and from among a group of countermeasure policies associated with similar threats contained in the group of similar threats, those that appear more frequently than a predetermined frequency among similar threats are identified.

[0004] Patent document 2 also discloses a configuration in which 5W information is input, elements that make up the 5W information are combined to generate a 5W record list representing threat events, preconditions that define events that are clearly not a threat are input, and 5W records that represent threat events that correspond to the preconditions are excluded from the 5W record list. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2016-45736 A [Patent Document 2] Patent Publication No. 2022-101716 Summary of the Invention [Problem to be solved by the invention]

[0006] Here, the present inventors have found the following problem. In threat analysis, the more the number of protected assets, system components, and communication paths increases, the more variations there are in the elements that make up the threat scenario, and the number of combinations of elements that make up the threat scenario increases explosively, resulting in a huge amount of analysis volume in the threat analysis. In particular, if all threat scenarios are created that include threats that involve hijacking, such as those caused through the hijacked subsystems that make up the system, the number of scenarios increases. If multiple hijacks are considered, the number increases even more. However, if the evaluation of threats involving hijacking is omitted, there is a possibility that sufficient risk reduction cannot be achieved. Note that threats involving hijacking include those involving multiple hijacks, and hereafter the terms "multi-hop threats" and "multi-hop threat scenarios" will be used.

[0007] Therefore, an object of the present invention is to realize a security design support device, etc. that covers significant threat scenarios including multi-hop threat scenarios while reducing the amount of analysis by reducing the amount of multi-hop threat scenarios that are unlikely to be realized. [Means for solving the problem]

[0008] The security design support device (100, 200, 300) disclosed herein is an input unit (101, 201) for inputting system information including information indicating components of a system (1) and subsystems (2, 3, 4) constituting the system as the components of the system; a threat scenario generation unit (105, 205) that generates a first threat scenario indicating a possible security threat from the system information and protected asset information indicating a protected asset of the system, using predetermined elements of a threat scenario; a risk level assessment unit (108, 208) for determining a risk level of the first threat scenario using a first feasibility that is the feasibility of the first threat scenario; a takeover possibility assessment unit (112, 212) for estimating a takeover possibility, which is the possibility that the subsystem will be taken over, by using a second feasibility, which is the feasibility of the first threat scenario when necessary measures are taken against the first threat scenario having a risk level equal to or higher than a predetermined level; an additional threat scenario generating unit (113, 213) for generating a second threat scenario indicating a security threat that may occur originating from the subsystem that may be hijacked if the hijacking possibility is equal to or higher than a predetermined level; an output unit (115, 215) that outputs the second threat scenario; Equipped with.

[0009] In addition, the claims and the numbers in parentheses attached to the constituent elements of the invention described in this section indicate the correspondence between the present invention and the embodiments described below, and are not intended to limit the present invention. Effect of the Invention

[0010] With the above-described configuration, the security design support device, etc. disclosed herein can reduce the amount of analysis while covering significant threat scenarios including multi-hop threat scenarios by reducing the amount of multi-hop threat scenarios that are unlikely to be realized. [Brief description of the drawings]

[0011] [Figure 1] A diagram illustrating the subsystems and communication paths that make up the system. [Diagram 2]Diagram illustrating an example multi-hop threat scenario [Diagram 3] FIG. 1 is a block diagram showing a configuration example of a security design support device according to a first embodiment. [Figure 4] FIG. 1 is an explanatory diagram illustrating an example of system information, protected asset information, and impact level. [Diagram 5] An explanatory diagram explaining an example of a template [Figure 6] Diagram illustrating an example of a first threat scenario [Figure 7] An explanatory diagram illustrating an example of a first feasibility, a risk level, and a necessary security measure for each first threat scenario. [Figure 8] FIG. 1 is an explanatory diagram illustrating an example of a table for determining a first feasibility and a risk level. [Figure 9] An explanatory diagram illustrating an example of the second feasibility and hijacking possibility for each first threat scenario. [Figure 10] Diagram illustrating an example of the second threat scenario [Figure 11] 1 is a flowchart for explaining the operation of the security design support device according to the first embodiment. [Figure 12] FIG. 11 is a block diagram showing a configuration example of a security design support device according to a second embodiment. [Figure 13] 11 is a flowchart for explaining the operation of the security design support device according to the second embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0013] The present invention means the invention described in the claims or in the Summary of the Invention section, and is not limited to the following embodiments. Furthermore, at least the words in quotation marks mean the words described in the claims or in the Summary of the Invention section, and are not limited to the following embodiments.

[0014] The configurations and methods described in the dependent claims are optional configurations and methods in the invention described in the independent claims. The configurations and methods of the embodiments corresponding to the configurations and methods described in the dependent claims, and the configurations and methods described only in the embodiments without being described in the claims, are optional configurations and methods in the present invention. The configurations and methods described in the embodiments when the description of the claims is broader than the description of the embodiments are also optional configurations and methods in the present invention in the sense that they are examples of the configurations and methods of the present invention. In either case, by being described in the independent claims, they become essential configurations and methods of the present invention.

[0015] The effects described in the embodiments are effects obtained when the configurations of the embodiments are provided as examples of the present invention, and are not necessarily effects that the present invention possesses.

[0016] When there are multiple embodiments (including modified examples, the same applies below), the configurations disclosed in each embodiment are not limited to each embodiment, but can be combined across the embodiments. For example, a configuration disclosed in one embodiment may be combined with another embodiment. Also, configurations disclosed in each of the multiple embodiments may be collected and combined.

[0017] The problem described in the section on problems that the invention is intended to solve is not a publicly known problem, but was discovered independently by the inventor, and this, together with the configuration and method of the present invention, is a fact that affirms the inventive step of the invention.

[0018] 1. Prerequisites for each embodiment (1) Systems subject to threat analysis, etc. First, the system that is the subject of the threat analysis and risk level assessment will be described. Figure 1 shows the configuration of a vehicle dispatch service system 1 as an example of a "system" that is the subject of the threat analysis and risk level assessment. The vehicle dispatch service system 1 is composed of the following "subsystems: a vehicle dispatch server 2, a vehicle management server 3, and a smartphone 4. Where: A "system" refers to a combination of interacting components to achieve a purpose or service. "Subsystem" refers to a unit of components that is distinguished by dividing them into sections using physical or virtual interfaces as boundaries.

[0019] The vehicle allocation server 2 is a device that arranges for an available vehicle based on a vehicle allocation request from a user. Specifically, the vehicle dispatch server 2 receives a vehicle dispatch request including a desired location and time of vehicle dispatch from the user via the smartphone 4. The vehicle dispatch server 2 transmits an available vehicle request to the vehicle management server 3 to inquire about the ID of an available vehicle 5. The available vehicle request includes the location and time of the user's desired vehicle dispatch. The vehicle dispatch server 2 receives an available vehicle response from the vehicle management server 3 as a response to the available vehicle request. The available vehicle response includes the ID of the available vehicle 5. The vehicle dispatch server 2 transmits a movement instruction to the vehicle 5 having the ID, specifying the location and time. Then, when an arrival notification is received from the vehicle 5 indicating that the vehicle 5 has arrived at the location, the vehicle dispatch server 2 transmits the arrival notification to the user's smartphone 4.

[0020] The vehicle management server 3 is a device that manages vehicles. Specifically, in response to an available vehicle request, the vehicle dispatch server 2 transmits an available vehicle response including the ID of an available vehicle 5 among the vehicles it manages.

[0021] The smartphone 4 is a device for requesting vehicle dispatch based on a user's operation. Specifically, the user transmits a vehicle dispatch request including a desired location and time of vehicle dispatch to the vehicle dispatch server 2. When the vehicle 5 arrives at the desired location, the vehicle dispatch server 2 receives an arrival notification.

[0022] In the vehicle dispatch service system 1 of Figure 1, the smartphone 4 and the vehicle dispatch server 2 are connected via LTE, the vehicle dispatch server 2 and the vehicle management server 3 are connected via the Internet, the vehicle dispatch server 2 and the vehicle 5 are connected via LTE, and the smartphone 4 and the vehicle 5 are connected via Bluetooth.

[0023] In the example of Fig. 1, the vehicle 5 is not included in the system, because the vehicle 5 is not included in the target of the threat analysis in the embodiment described below. In this way, it is desirable to determine the scope of the "system" based on the "subsystem" that is the target of the threat analysis. However, there is nothing to prevent the entire physical system from being defined as the "system". In addition, when some of the functions of a subsystem are not included in the scope of the threat analysis, the scope of the "subsystem" may be limited to the functions that are the subject of the analysis. The system in FIG. 1 is an example for specifically explaining each embodiment, and any system can be used in each embodiment.

[0024] (2) Example of a multi-hop threat scenario Figure 2 shows an example of a multi-hop threat scenario. The threat scenario in Figure 2(a) is "An external attacker attacks the protected assets of subsystem a." In this case, the target protected assets are directly attacked, so the subsystem is not taken over. The threat scenario in Figure 2(b) is "An external attacker takes over subsystem a, and uses subsystem a as a springboard to attack the protected assets of subsystem b." This is an example of a one-hop threat scenario. The threat scenario in Figure 2(c) is "An external attacker takes over subsystem a, uses subsystem a as a springboard to take over subsystem b, and uses subsystem b as a springboard to attack the protected assets of subsystem c." This is an example of a two-hop threat scenario.

[0025] In each embodiment, the threat scenarios of Figures 2(a) to 2(c) are not generated simultaneously, but are generated sequentially. That is, the threat scenario of Figure 2(a) is generated first, and if there is a possibility that subsystem a will be hijacked after the security countermeasures of the threat scenario of Figure 2(a) are implemented, the threat scenario of Figure 2(b) is generated. Next, based on the possibility that subsystem b will be hijacked after the security countermeasures of the threat scenario of Figure 2(b), the threat scenario of Figure 2(c) is generated. The same applies thereafter.

[0026] 2. Embodiment 1 (1) Configuration of security design support device 100 3 is a block diagram showing a configuration of a security design support device 100 in this embodiment. The security design support device 100 has an input unit 101, a threat analysis unit 102, a risk level analysis unit 106, a security countermeasure determination unit 109, a multi-hop threat analysis unit 110, a storage unit 114, and an output unit 115. The threat analysis unit 102 has a protected asset extraction unit 103, an impact assessment unit 104, and a threat scenario generation unit 105. The risk level analysis unit 106 has a feasibility assessment unit 107 and a risk level assessment unit 108. The multi-hop threat analysis unit 110 has a feasibility re-assessment unit 111, a takeover possibility assessment unit 112, and an additional threat scenario generation unit 113.

[0027] The security design support device 100 can be configured with a general-purpose CPU (Central Processing Unit), volatile memory such as RAM, non-volatile memory such as ROM, flash memory, or hard disk, various interfaces, and an internal bus connecting these. Then, by executing software on this hardware, the device can be configured to perform the functions of each functional block shown in FIG. 3. The same applies to the security design support device 200 and the security design support device 300 of the other embodiments.

[0028] In the following explanation of each block, in addition to Fig. 3, Fig. 4 to Fig. 10 will be used. Fig. 4, Fig. 6, Fig. 7, Fig. 9, and Fig. 10 show parts of one large table, and each row is connected to the same row via its identification number.

[0029] The input unit 101 inputs system information indicating the "system components" of the vehicle dispatch system 1. The system components include information indicating the subsystems that make up the vehicle dispatch system 1. That is, the input unit 101 inputs system information indicating other "system components" related to the vehicle dispatch system 1 in addition to information indicating the subsystems that make up the vehicle dispatch system 1, in this case the vehicle dispatch server 2, the vehicle management server 3, and the smartphone 4. An example of the system information to be input is described in FIG. 4. The input to the input unit 1 may be made by an operator inputting the system information, or may be made by reading a file in which the system information is stored from another device or block. Here, the "system components" may include not only hardware, but also software and data, as well as interrelationships such as sequences and data flows between hardware and software.

[0030] Fig. 4 shows an example of system information, protected asset information, and impact level of the vehicle dispatch system 1 shown in Fig. 1 of this embodiment. The system information in Fig. 4 is made up of components of the vehicle dispatch system 1, and specifically, includes subsystems, functions of the subsystems, classifications indicating functions or data, and specific types of data when the classification indicates data, communication methods, input / output directions, and input / output destination subsystems or functions.

[0031] 1, when the subsystem is the vehicle dispatch server 2, the function of the vehicle dispatch server 2 is a vehicle dispatch function or a notification function. Also, the classification of the vehicle dispatch server 2 is a function or transmitted / received data. When the classification of the vehicle dispatch server 2 is data, the data is a vehicle dispatch request, an available vehicle request, an available vehicle response, a movement instruction, or an arrival notification, the communication method is the Internet or LTE, the input / output direction is input or output, and the input destination subsystem, etc. is the smartphone 4, the vehicle management server 3, or the vehicle 5. 4 shows only the case where the function is a vehicle dispatch function, the data is a vehicle dispatch request, the communication method is LTE, the input / output direction is output, and the input destination subsystem is the smartphone 4, but basically, all combinations according to the number of candidates for each component are included. The same applies to the vehicle management server 3 and smartphone 4 described later.

[0032] 1, when the subsystem is the vehicle management server 3, the function of the vehicle management server 3 is an empty vehicle management function, and the classification of the vehicle management server 3 is function, transmitted / received data, or stored data. When the classification of the vehicle management server 3 is data, the data is an empty vehicle request or an empty vehicle response, the communication method is the Internet, the input / output direction is input or output, and the subsystem of the input / output destination is the vehicle dispatch server 2. In FIG. 4, only examples of the empty vehicle management function are shown among all combinations of system information.

[0033] 1, when the subsystem is the smartphone 4, the function of the smartphone 4 is a dispatch request function or a notification function, and the classification of the smartphone 4 is function or transmitted / received data. When the classification of the smartphone 4 is data, the data is a dispatch request or arrival notification, the communication method is LTE or Bluetooth, the input / output direction is input or output, and the subsystem of the input / output destination is the dispatch server 2 or the vehicle 5. In FIG. 4, among all the combinations of system information, only an example of the function of requesting a ride is shown.

[0034] The threat analysis unit 102 identifies possible security threats to the vehicle dispatch system 1 based on the system information input from the input unit 101. In this embodiment, the threat analysis unit 102 has a protected asset extraction unit 103, an impact assessment unit 104, and a threat scenario generation unit 105 as sub-blocks.

[0035] The protected asset extraction unit 103 obtains protected asset information indicating the "protected assets" of the vehicle dispatch system 1 from the system information input by the input unit 101. Specifically, the protected asset information is obtained by extracting the functions of the subsystems and specific data that the subsystems hold, transmit, or receive. For example, when the subsystem is the vehicle dispatch server 2, the protected asset information is extracted as the vehicle dispatch function and notification function, as well as location information and time information included in the vehicle dispatch request, etc. Here, the "protected assets" may include information and functions as well as the state of the information and functions.

[0036] In addition to these, the protected asset extraction unit 103 may further include CIA information regarding the confidentiality (C), integrity (I), or availability (A) of the functions and data.

[0037] The impact assessment unit 104 calculates the impact of risk on the protected asset extracted by the protected asset extraction unit 103. The impact can be calculated, for example, by a method disclosed in ISO / SAE 21434 Annex F (informative) Guidelines for impact rating. Then, the impact of damage caused when the set of functions, data, and CIA is lost can be determined for each of the asset categories of safety (S), economy (F), operation (O), and privacy (P), and the maximum value of the impacts of the four asset categories can be determined as the impact on the protected asset.

[0038] The protected asset information in FIG. 4 describes only the dispatch function and location information among the data, and omits time information. The degree of influence in Fig. 4 is expressed in four levels, but may be any other number or set. The higher the numerical value of the degree of influence, the greater the degree of influence.

[0039] The threat scenario generation unit 105 generates a first threat scenario indicating possible security threats from the system information of the vehicle dispatch system 1 and the protected asset information of the vehicle dispatch system 1, using "predetermined" elements of the threat scenario. In this embodiment, the threat scenario generation unit 105 generates the first threat scenario using a template of the elements of the threat scenario. The template of the elements of the threat scenario can be read and used from, for example, the one stored in the storage unit 114. The template may be of any format as long as it contains the elements of the threat scenario. The template may also be updated from time to time, for example, by a learning function. It should be noted that the first threat scenario can also be generated by a method that does not use a template. Here, "predetermined" means that it is sufficient that it is determined before the first threat scenario is generated, and it is not necessarily required that it is determined in the initial state of the security design support apparatus.

[0040] Figure 5 is an example of a template for the components of a threat scenario. The template in Figure 5 abstractly lists candidates for the components of a threat scenario, consisting of the time of threat occurrence (when), the actor generating the threat (who), the intention of generating the threat (why), the origin of the threat (where), and the target and content of the threat (what). The content of each template in Figure 5 is as follows. Note that each component may be defined in more detail than the example given in Figure 5. Furthermore, "takeover" may be further included as the content of the threat (what). When the threat occurs: When the service is running, when the service is down Threat actors (who): internal attackers, external attackers Intention to create a threat (why): intentional or negligent Where the threat originates: Within the subsystem, outside the subsystem Threat target 1 (what): Subsystem Threat Object 2 (what): Functions, Data Threat content (what): Confidentiality (C), Integrity (I), Availability (A)

[0041] The threat scenario generator 105 generates a first threat scenario by applying the system information and the protected asset information to the template stored in the storage unit 114. FIG. 6 shows an example of a first threat scenario generated by the threat scenario generator 105. In FIG. For example, in the case of identification number 1, if the candidates of the components of the threat scenario are service in operation (when), external attacker (who), intentional (why), and outside the subsystem (where), and the system information and protected asset information are dispatch server 2 (what), dispatch function (what), and integrity (I) (what), the first threat scenario generated will be "an external attacker intentionally violates the integrity by tampering with the dispatch function of the dispatch server 2 from outside the subsystem while the service is in operation." In the case of identification number 7, if the candidates of the components of the threat scenario are service in operation (when), external attacker (who), intentional (why), and outside the subsystem (where), and the system information and protected asset information are dispatch server 2 (what), location information (what), and confidentiality (C) (what), the first threat scenario generated will be "an external attacker intentionally violates confidentiality by leaking the location information of the dispatch server 2 from outside the subsystem while the service is in operation." Similarly, for the other identification numbers, a first threat scenario is generated using a combination of candidate threat scenario components. In Fig. 6, only the combinations of (who) being an external attacker or an internal attacker, (where) being outside or inside the subsystem, and (what) being tampering corresponding to integrity (I), denial of service corresponding to availability (A), or information leakage corresponding to confidentiality (C) are shown. However, for the other components as well, the first threat scenario is generated using all combinations using all candidates.

[0042] In the example of Fig. 6 of this embodiment, the first threat scenario is generated using all the components of the threat scenario and all the combinations of the subsystems and the protected assets, but it is also possible not to generate the first threat scenario that indicates a fact that cannot occur. For example, when the protected asset is a function, the confidentiality of the function (C) cannot be conceived, so these combinations may be excluded in advance. Also, when the protected asset is data, the availability of the data (A) cannot be conceived, so these combinations may also be excluded in advance.

[0043] In the example of Figure 6 of this embodiment, the origin of the threat is set to either inside or outside the subsystem, so that multi-hop threat scenarios are not generated, and only threat scenarios related to direct attacks can be generated, thereby reducing the number of first threat scenarios to be generated.

[0044] The risk level analysis unit 106 calculates a risk level, which is the level of security risk of the first threat scenario, based on the first threat scenario generated by the threat scenario generation unit 105. In this embodiment, the risk level analysis unit 106 has a feasibility evaluation unit 107 and a risk level evaluation unit 108 as sub-blocks.

[0045] The feasibility evaluation unit 107 obtains a first feasibility, which is the feasibility of the first threat scenario generated by the threat scenario generation unit 105. For example, the feasibility can be obtained by a method disclosed in ISO / SAE 21434 Annex G (informative) Guidelines for attack feasibility rating. More specifically, the feasibility is obtained by calculating any one of 1) the attack potential of the attack potential-based approach (Table G.7: Example attack potential mapping), 2) the CVSS of the CVSS-based approach (Table G.8: Example CVSS exploitability mapping), and 3) the attack vector of the attack vector-based approach (Table G.9: Attack vector-based approach), and determining whether the value falls within a range set for each feasibility level.

[0046] As another example, the "attack potential score" indicating the effort required by an attacker to realize a threat as disclosed in ISO / IEC 18045 Common Methodology for Information Technology Security Evaluation may be determined by determining the scores of each of the parameters "required time," "expertise," "product knowledge," "attack opportunity," and "facilities," and the total value may be used as the first feasibility. The score values ​​and standards of each parameter may be taken from Tables G1 to G6 of ISO / SAE 21434 Annex G (informative) or ISO / IEC 18045 B.4.2 Characterizing attack potential.

[0047] FIG. 7 shows an example of the first feasibility, risk level, and necessity of security measures and the security measures of this embodiment. The first feasibility is obtained using the other examples above. For example, the "time required", "expertise", "product knowledge", "opportunity of attack", and "equipment" of the first threat scenario with identification number 1 are 4, 3, 3, 4, and 0, respectively, with a total value of 14. Also, those of the first threat scenario with identification number 2 are 0, 3, 3, 4, and 0, with a total value of 10. The higher the value of each value and the total value, the higher the difficulty. Then, the first feasibility is calculated according to the range that the total value falls within. For example, a table showing the relationship between the range of the total value and the score indicating the first feasibility as shown in Fig. 8(a) is used. In Fig. 7, the first feasibility is 3 for identification number 1, and 4 for identification number 2. The larger the value of the first feasibility, the higher the feasibility.

[0048] In Fig. 7, the first feasibility of the first threat scenario is directly calculated, but if there are multiple means or attack paths to realize the first threat scenario, the first feasibility may be calculated for each of the means or attack paths. In this case, the feasibility of the first threat scenario as a whole is calculated.

[0049] The risk level assessment unit 108 determines the security risk level of the first threat scenario using the first feasibility determined by the feasibility assessment unit 107. The risk level assessment unit 108 may further determine the risk level using the impact determined by the impact assessment unit 104. An example of a method for determining a risk level using the first feasibility and the impact is ISO / SAE 21434 Annex H (informative) Table H.8: Risk matrix example.

[0050] Fig. 8(b) is an example of a table used to calculate the risk level. When the risk level is calculated using this table, in the case of identification number 1 in Fig. 7, the impact degree is 4 and the first feasibility is 3, so the risk level is 4. Similarly, in the case of identification number 2, the impact degree is 4 and the first feasibility is 4, so the risk level is 5. The higher the risk level number, the higher the risk.

[0051] The security countermeasure determination unit 109 determines necessary countermeasures for a first threat scenario whose risk level obtained by the risk level assessment unit 108 is "above" a predetermined level. For example, the security countermeasure determination unit 109 determines necessary security countermeasures for a first threat scenario whose risk level is 2 or higher. Here, "greater than or equal to" includes both the case where the comparison target is included (≧) and the case where the comparison target is not included (>).

[0052] As specific examples of determining necessary countermeasures, in the case of a threat against the integrity of functions (I), a program tamper detection function is placed in the subsystem; in the case of a threat against the confidentiality of stored data (C), data encryption is performed; in the case of a threat related to the confidentiality of transmitted data (C), data encryption and decryption functions are placed in the source subsystem and destination subsystem; and in the case of a threat against the availability of functions and data (A), rules such as rate limiting, CAPTCHA, increasing the delay between attempts, account locking, IP address restriction, and the use of a WAF (Web Application Firewall) are defined in advance, and necessary countermeasures are determined according to the rules that apply to the first threat scenario. In addition, examples of well-known security measures include CIS Controls, OWASP (Open Web Application Security Project) Application Security Verification Standard, and OWASP Mobile Application Security Verification Standard, and the security measures determination unit 109 may determine necessary measures based on these well-known rules.

[0053] In the example of Figure 7, all risk levels are 2 or higher, so measures are required for all identification numbers. For example, identification number 1 is a threat to integrity (I), so a tamper detection function is deployed as a security measure. For example, identification number 7 is a threat to confidentiality (C), so data encryption is used as a security measure.

[0054] The multi-hop threat analysis unit 110 generates a second threat scenario, which is a multi-hop threat scenario, based on the possibility that the subsystem will be hijacked if necessary security measures are taken. In this embodiment, the multi-hop threat analysis unit 110 has a feasibility re-evaluation unit 111, a hijacking possibility evaluation unit 112, and an additional threat scenario generation unit 113 as sub-blocks.

[0055] The feasibility re-evaluation unit 111 obtains a second feasibility, which is the feasibility of the first threat scenario when the necessary measures determined by the security countermeasures determination unit 109 are implemented. FIG. 9 is an example of a second feasibility and hijacking possibility of this embodiment. The first feasibility of the first threat scenario in Figure 7 is the feasibility before security measures are implemented, while the second feasibility of the first threat scenario in Figure 9 is the feasibility after security measures are implemented, so the latter is less feasible than the former. For example, in Fig. 7, the time required in the first threat scenario of identification number 7 was 4, but in Fig. 9, the time required in the first threat scenario after data encryption is applied is 19. In other words, since it takes a considerable amount of time to decrypt encrypted data, the time required before and after the security countermeasure is different. As a result, the total value is also different.

[0056] The method by which the feasibility re-evaluation unit 111 obtains the second feasibility is the same as the method by which the feasibility evaluation unit 107 obtains the first feasibility. That is, the score which is the second feasibility is obtained using the table in Fig. 8(a). In the case of Fig. 9, the total value of identification number 1 is 29, so the second feasibility is 1, and the total value of identification number 6 is 22, so the second feasibility is 2. Although there is no first threat scenario in Fig. 9 for which security measures are not required, for a first threat scenario for which security measures are not required, the first feasibility is treated as the second feasibility as it is. In this embodiment, the method by which the feasibility re-evaluation unit 111 determines the second feasibility is the same as the method by which the feasibility evaluation unit 107 determines the first feasibility, but this does not prevent the use of a different method.

[0057] The takeover possibility evaluation unit 112 estimates the takeover possibility, which is the possibility that the subsystem is taken over, by using the second feasibility obtained by the feasibility re-evaluation unit 111. For example, among the first threat scenarios for which the second feasibility is obtained, at least one, preferably two or more, of the following first threat scenarios are identified: the origin of the threat is outside the subsystem (condition 1), the intention of the threat is deliberate (condition 2), and the content of the threat is tampering with functions or tampering with data (condition 3), and the identified first threat scenarios are classified for each subsystem that is the protected asset targeted by the identified first threat scenario. Then, for each subsystem, the takeover possibility is evaluated based on the second feasibility of each of the first threat scenarios. For example, when the total value of the second feasibility is equal to or greater than a predetermined value, or when the maximum value of the second feasibility is the takeover possibility.

[0058] The starting point of the threat being outside the subsystem (Condition 1) is a condition for extracting the first threat scenario that mainly matches the route of a takeover, focusing on the fact that the takeover occurs from an action outside the subsystem. The threat intent being deliberate (condition 2) focuses on the fact that the takeover is an act of a malicious individual, and is a condition for extracting the first threat scenario that matches the subjective perception of the takeover. The content of the threat being tampering with functions or tampering with data (Condition 3) is a condition for extracting a first threat scenario that mainly matches the result of a hijacking, focusing on the fact that tampering often occurs as a result of a system hijacking. In addition, a condition for extracting a first threat scenario that matches the means of hijacking may be set. These conditions may be used alone or in combination. When used in combination, a conditional expression using a sum or product may be set. In other words, by analyzing the first threat scenario that satisfies these conditions, the possibility of takeover can be objectively evaluated.

[0059] By classifying the first threat scenarios identified under these conditions for each subsystem that they target, it is possible to comprehensively evaluate the possibility of a takeover using the first threat scenarios possessed by that subsystem.

[0060] The sum of the second feasibility values ​​of the first threat scenarios included in a subsystem indicates how vulnerable the subsystem is as a whole, and the sum can be used as an indicator of the possibility that the subsystem may be taken over. Alternatively, the maximum value of the second feasibility in the first threat scenario included in the subsystem can be evaluated as the most vulnerable threat scenario in that subsystem, and the maximum value can be used as an indicator of the possibility that the subsystem will be taken over.

[0061] In this embodiment, the condition is that all of (Condition 1), (Condition 2), and (Condition 3) are satisfied. In the example of Fig. 9, identification numbers 1, 2, 10, and 11 satisfy the condition. The subsystem that is the protected asset of these first threat scenarios is the vehicle dispatch server 2, and since the total value of the second feasibility of these first threat scenarios is 4, the hijacking possibility is set to 4.

[0062] The hijacking possibility of other subsystems is estimated in a similar manner. In the example of Fig. 9, the hijacking possibility of the vehicle management server 3 is 2, and the hijacking possibility of the smartphone 4 is 10. The higher the level number, the higher the possibility of hijacking.

[0063] If the hijacking possibility estimated by the hijacking assessment possibility evaluation unit 112 is "above" a predetermined level, the additional threat scenario generation unit 113 generates a second threat scenario indicating a security threat that may occur originating from a subsystem that may be hijacked. More specifically, the additional threat scenario generation unit 113 generates the second threat scenario by rewriting the origin of the threat in the first threat scenario generated by the threat scenario generation unit 105 from "outside the subsystem" to "subsystem that may be hijacked." Here, "greater than or equal to" includes both the case where the comparison target is included (≧) and the case where the comparison target is not included (>).

[0064] FIG. 10 shows an example of a second threat scenario generated by the additional threat scenario generator 113. In FIG. In FIG. 9, for example, when the predetermined level is set to 10, it is evaluated that the dispatch server 2 and the vehicle management server 3 are unlikely to be hijacked, but the smartphone 4 is likely to be hijacked. The additional threat scenario generating unit 113 then extracts a subsystem that is directly connected to the smartphone 4 from the first threat scenario generated by the threat scenario generating unit 105. According to FIG. 1, the subsystem that is directly connected to the smartphone 4 is the dispatch server 2. Therefore, the additional threat scenario generating unit 113 extracts a first threat scenario in which the distribution server 2 is a subsystem that is a protected asset, and rewrites the threat origin (where) of the components of the threat scenario from "outside the subsystem" to "hijacked smartphone 4". For example, when rewriting the first threat scenario of the identification number 1, it is rewritten to "an external attacker intentionally hijacks the smartphone 4 during service operation and tampers with the dispatch function of the dispatch server 2 to violate the integrity". The rewritten threat scenario is then set as the second threat scenario.

[0065] In addition, the first threat scenario, whose threat origin is "within the subsystem", is a threat scenario that is completed within the subsystem, so there is no need to use it to generate the second threat scenario. In other words, in Figure 10, only identification numbers 1, 2, 4, 5, 7, 8, 10, and 11 are used to generate the second threat scenario, and identification numbers 3, 6, 9, and 12 are not used to generate the second threat scenario because they are not related to takeover.

[0066] In other words, the additional threat scenario generator 113 can generate only multi-hop threat scenarios with a certain or higher probability of takeover, thereby making it possible to reduce the number of second threat scenarios to be generated.

[0067] The additional threat scenario generation unit 113 outputs the second threat scenario to the risk level analysis unit 106. Then, the feasibility assessment unit 107 and the risk level assessment unit 108 constituting the risk level analysis unit 106 use the second threat scenario to determine the first feasibility and risk level. Then, the security countermeasure determination unit 109 determines necessary countermeasures for the second threat scenario using the determined risk level. In this way, by re-determining the risk level and necessary measures using the second threat scenario, it is possible to take measures against the first-stage multi-hop threat scenario. Then, by further performing analysis in the multihop threat analysis unit 110, a second-stage multihop threat scenario (corresponding to a "second threat scenario") can be generated. This process is repeated until all risk levels fall below a predetermined level, or until all takeover possibilities fall below a predetermined level.

[0068] A threat scenario describing a scenario before the takeover may be added to the second threat scenario. For example, a threat scenario before the takeover may be generated in which "an external attacker intentionally takes over the smartphone 4 from outside the subsystem while the service is in operation," and then a threat scenario after the takeover may be generated in which "an external attacker intentionally takes over the smartphone 4 while the service is in operation and uses it to tamper with the dispatch function of the dispatch server 2, thereby violating its integrity," and these may be combined to form the second threat scenario.

[0069] The output unit 115 outputs the results of each block of the security design support device 100 to an external device such as a display device. The results to be output may be selected based on which block of the block is required, as necessary. In the case of Fig. 3, the first threat scenario generated by the threat scenario generation unit 105, the risk level evaluated by the risk level assessment unit 108, the necessary measures determined by the security measures determination unit 109, the takeover possibility evaluated by the takeover possibility assessment unit 112, and the second threat scenario generated by the additional threat scenario generation unit 113 are output. Examples of the external device include a display device, a speaker, a storage device, and a server device provided separately from the security design support device. The form of the output data may be set appropriately according to the external device. Examples of the data include image or text data, audio data, and files. The external device may be a virtual machine realized by the same hardware as the security design support device.

[0070] (2) Operation of the Security Design Support Device 100 Next, the operation of security design support device 100 will be described with reference to Fig. 11. Fig. 11 not only shows a security design support method executed by security design support device 100, but also shows the processing procedure of a security design support program executable by security design support device 100. The order of these processes is not limited to the order shown in Fig. 11. In other words, the order may be changed as long as there are no constraints such as a relationship in which a certain step utilizes the result of the previous step. The same applies to other embodiments.

[0071] System information indicating components of the vehicle dispatch system 1 is input from the input unit 101 (S101). The system information includes information indicating the vehicle dispatch server 2, the vehicle management server 3, and the smartphone 4, which are subsystems that configure the vehicle dispatch system 1. The protected asset extraction unit 103 extracts and obtains protected asset information indicating the protected asset of the vehicle dispatch system 1 from the system information input in S101 (S102). The threat scenario generation unit 105 generates a first threat scenario indicating possible security threats using predetermined components of the threat scenario from the system information input in S101 and the protected asset information obtained in S102 (S103).

[0072] The feasibility assessment unit 107 calculates and obtains a first feasibility, which is the feasibility of the first threat scenario obtained in S103 (S104). The risk level assessment unit 108 calculates and determines the risk level of the first threat scenario using the first feasibility determined in S104 (S105). The security countermeasure determination unit 109 determines necessary countermeasures for the first threat scenario whose risk level obtained in S105 is equal to or higher than a predetermined level (S106).

[0073] The feasibility reevaluation unit 111 calculates and obtains a second feasibility, which is the feasibility of the first threat scenario when the necessary measures determined in S106 are implemented (S107). The takeover possibility assessment unit 112 estimates the takeover possibility, which is the possibility that the subsystem will be taken over, by using the second feasibility calculated in S107 (S108). If the hijacking possibility calculated in S108 is equal to or greater than a predetermined level (L) (S109: Yes), the additional threat scenario generator 113 generates a second threat scenario indicating a security threat that may occur originating from the subsystem that may be hijacked (S110), and returns the process to S104. If the hijacking possibility is less than the predetermined level (L) (S109: No), the process ends. If necessary, the information obtained in each step may be output from the output unit 115. For example, the output unit 115 outputs the second threat scenario generated in S110.

[0074] (3) Summary As described above, according to this embodiment, the security design support device 100 provides the following technical effects. Since the first threat scenario, which is a threat scenario relating to a direct attack, and the second threat scenario, which is a threat scenario relating to a multi-hop attack, are generated in a stepwise manner, it is possible to suppress the generation of threat scenarios with low feasibility.

[0075] Since the first threat scenario is generated using predetermined components of the threat scenario, the threat scenario can be generated automatically using a computer or other device, and past knowledge can be incorporated, making it possible to generate a threat scenario without any omissions. In addition, since the threat origin of the components of the threat scenario is either inside or outside the subsystem, it is possible to generate only the first threat scenario related to a direct attack. Also, the first threat scenario in which the threat origin is outside the subsystem can be used to generate a second threat scenario related to a multi-hop attack.

[0076] Since the takeover possibility, which is the possibility that the subsystem will be taken over, is evaluated using the second feasibility, which is the feasibility when necessary measures are taken against the first threat scenario, the accuracy of estimating the takeover possibility can be improved. Also, since the direct fact of a subsystem being taken over cannot be directly observed, the possibility can be evaluated using indirect facts observed when the subsystem is taken over.

[0077] By identifying subsystems whose hijacking probability is equal to or higher than a predetermined level and generating a second threat scenario with the subsystem as the starting point of the attack, it is possible to generate only multi-hop threat scenarios that are likely to be realized, and to suppress the generation of multi-hop threat scenarios that are unlikely to be realized. In addition, since the second threat scenario is generated by rewriting the origin of the threat in the first threat scenario to a subsystem that may be hijacked, the second threat scenario can be generated by utilizing the first threat scenario that has already been generated, thereby reducing the amount of work required to generate the second threat scenario.

[0078] 3. Embodiment 2 (1) Configuration of security design support device 200 The first embodiment is an example in which all processing and calculations are performed by the security support device 100 based on system information input to the input unit 101. However, it is not necessary for all processing and calculations to be performed by the security support device 100, and processing and calculation results from other devices may be received and used, or information generated by a person may be input and used midway. This embodiment is an example in which it is assumed that some processing and calculations are performed externally, including by a person. The configuration of this embodiment will be described below with reference to FIG.

[0079] 12 is a block diagram showing the configuration of a security design support device 200 in this embodiment. The security design support device 200 has an input unit 201, a threat scenario generation unit 205, a risk level assessment unit 208, a takeover possibility assessment unit 212, an additional threat scenario generation unit 213, a storage unit 214, and an output unit 215. In addition, among the blocks of embodiment 1, the blocks of this embodiment that have the same last two digits of the block number basically have the same functions except for the source of information input, so the explanation of embodiment 1 (excluding the source of information input) will be quoted.

[0080] The input unit 201 inputs various information such as the system information of the vehicle dispatch system 1, the protected asset information of the vehicle dispatch system 1, the impact degree, the first feasibility, the necessary measures, and the second feasibility. The timing of the input is arbitrary, but as described below, it is desirable to input the information sequentially based on the intermediate processing or calculation results of the security design support device 200 output from the output unit 215, or after confirming the processing or calculation results. The various types of information input to the input unit 201 may be either information generated by other devices or blocks, or information generated by human thought. The following description will be given as an example of a case in which information generated by a person's thought is sequentially input after checking the processing and calculation results outputted to a display or the like.

[0081] The threat scenario generating unit 205 generates a first threat scenario indicating possible security threats from the system information and protected asset information input from the input unit 201, using predetermined components of the threat scenario. The generated first threat scenario is output to the output unit 215.

[0082] After the first threat scenario is confirmed by the output unit 215, the impact level and the first feasibility, which is the feasibility of the first threat scenario, are input from the input unit 201. The risk level assessment unit 208 determines the risk level of the first threat scenario by using the first feasibility input from the input unit 201. The risk level assessment unit 208 may further determine the risk level by using the impact degree input from the input unit 201. The determined risk level is output to the output unit 215.

[0083] After the risk level is confirmed by the output unit 215, for a first threat scenario whose risk level is equal to or higher than a predetermined level, necessary measures are input from the input unit 201. Furthermore, a second feasibility, which is the feasibility of the first threat scenario when the necessary measures are implemented, is input. The takeover possibility assessment unit 212 uses the second feasibility input from the input unit 201 to estimate the takeover possibility, which is the possibility that the subsystem will be taken over. The obtained takeover possibility is output to the output unit 215.

[0084] If the hijacking possibility estimated by the hijacking possibility assessment unit 212 is "above" a predetermined level, the additional threat scenario generation unit 213 generates a second threat scenario indicating a security threat that may occur originating from a subsystem that may be hijacked. The generated second threat scenario is output to the output unit 215. In addition, the additional threat scenario generation unit 213 outputs the second threat scenario to the risk level assessment unit 208.

[0085] After the second threat scenario is confirmed by the output unit 215, the first feasibility, which is the feasibility of the second threat scenario, is input from the input unit 201. The risk level assessment unit 208 uses the first feasibility input from the input unit 201 to determine the risk level of the second threat scenario. This process is repeated until all risk levels fall below a predetermined level, or until all takeover possibilities fall below a predetermined level.

[0086] (2) Operation of the Security Design Support Device 200 Next, the operation of security design support device 200 will be described with reference to FIG. 11, which shows the operation of the security design support device 100 of the first embodiment, and Fig. 13, which shows the operation of the security design support device 200 of this embodiment, differ in that in Fig. 11, extraction of protected asset information (S102), calculation of first feasibility (S104), decision of necessary measures (S106), and calculation of second feasibility (S107) are changed to input of protected asset information (S202), input of first feasibility (S204), input of necessary measures (S206), and input of second feasibility (S207), respectively. The flow with the same step numbers as Fig. 11 has the same processing as Fig. 11, except for the source of information input.

[0087] System information indicating components of the vehicle dispatch system 1 is input from the input unit 201 (S101). Protected asset information indicating the protected asset of the vehicle dispatch system 1 is input from the input unit 201 (S202). The threat scenario generation unit 205 generates a first threat scenario indicating possible security threats using predetermined components of the threat scenario from the system information input in S101 and the protected asset information input in S202 (S103).

[0088] A first feasibility, which is the feasibility of the first threat scenario calculated in S103, is input from the input unit 201 (S204). The risk level assessment unit 208 calculates and determines the risk level of the first threat scenario using the first feasibility input in S204 (S105). Necessary measures for the first threat scenario, the risk level of which is equal to or higher than a predetermined level as determined in S105, are inputted from the input unit 201 (S206).

[0089] A second feasibility, which is the feasibility of the first threat scenario in the case where the necessary measures input in S206 are taken, is input from the input unit 201 (S207). The takeover possibility assessment unit 212 estimates the takeover possibility, which is the possibility that the subsystem will be taken over, by using the second feasibility input in S207 (S108). If the hijacking possibility calculated in S108 is equal to or greater than a predetermined level (L) (S109: Yes), the additional threat scenario generator 213 generates a second threat scenario indicating a security threat that may occur originating from the subsystem that may be hijacked (S110) and returns the process to S204. If the hijacking possibility is less than the predetermined level (L) (S109: No), the process ends. If necessary, the information obtained in each step may be output from the output unit 215. For example, the output unit 215 outputs the second threat scenario generated in S110.

[0090] (3) Summary According to the present embodiment, the security design support device 200 has the following advantages in addition to the advantages of the first embodiment. Since the protected asset information, the first feasibility, the necessary measures, and the second feasibility are input from the input unit, there is no need to provide a block for analyzing and calculating these in security design support device 200, and the burden on security design support device 200 can be reduced.

[0091] 4. Other embodiments The security design support device 300 of this embodiment has a configuration intermediate between the security design support device 100 of the first embodiment and the security design support device 200 of the second embodiment. That is, in the first embodiment, protected asset information is extracted by the protected asset extraction unit 103, the first feasibility is calculated by the feasibility assessment unit 107, necessary measures are decided by the security countermeasure decision unit 109, and the second feasibility is calculated by the feasibility re-evaluation unit 111. In contrast, in the second embodiment, these pieces of information are not generated inside the security design support device 200, but are input from the input unit 201. In other words, they are generated outside the security design support device 200.

[0092] However, it is not necessary to generate all of these pieces of information either inside or outside the security design support device. At least a part of these pieces of information may be generated inside the security design support device, and the rest may be generated outside the security design support device and input. That is, the security design support device 300 of this embodiment may have at least one of the protected asset extraction unit 103, the feasibility evaluation unit 107, the security countermeasure decision unit 109, and the feasibility reevaluation unit 111 in addition to the configuration of the security design support device 200 of the second embodiment. Alternatively, the security design support device 300 of this embodiment may further input at least one of the protected asset information, the first feasibility, the necessary measures, and the second feasibility from the input unit 101 instead of at least one of the protected asset extraction unit 103, the feasibility evaluation unit 107, the security countermeasure decision unit 109, and the feasibility reevaluation unit 111 in the configuration of the security design support device 100 of the first embodiment.

[0093] 5. Summary The features of the security design support device and the like in each embodiment of the present invention have been described above.

[0094] The terms used in each embodiment are merely examples and may be replaced with synonymous terms or terms having the same functions.

[0095] The block diagrams used to explain the embodiments classify and organize the configuration of the device by function. The blocks showing the respective functions are realized by any combination of hardware or software. In addition, since the block diagrams show the functions, they can also be understood as disclosures of a method invention and a program invention that realizes the method.

[0096] The order of the functional blocks that can be understood as the processes, flows, and methods described in each embodiment may be changed as long as there are no constraints such as a relationship in which one step utilizes the results of another step prior to it.

[0097] The terms first, second, through Nth (N is an integer) used in each embodiment and in the claims are used to distinguish two or more configurations or methods of the same type, and do not limit the order or superiority or inferiority.

[0098] Moreover, examples of the form of the security design support device of the present invention include the following. Examples of the component form include a semiconductor element, an electronic circuit, a module, and a microcomputer. Examples of semi-finished products include electronic control units (ECUs (Electric Control Units)) and system boards. Finished product forms include mobile phones, smartphones, tablets, personal computers (PCs), workstations, and servers. Other examples include devices with communication functions, such as video cameras, still cameras, and car navigation systems.

[0099] It is assumed that the security design support device of the present invention will be used, particularly on the server side, for the purpose of providing various services. In providing such services, the security design support device of the present invention will be used, the method of the security design support device of the present invention will be used, and / or the program of the security design support device of the present invention will be executed.

[0100] In addition, the present invention can be realized not only by dedicated hardware having the configuration and functions described in each embodiment, but also as a combination of a program for realizing the present invention recorded on a recording medium such as a memory or a hard disk, and general-purpose hardware having a dedicated or general-purpose CPU and memory capable of executing the program.

[0101] A program stored in a non-transient physical recording medium (for example, an external storage device (hard disk, USB memory, CD / BD, etc.) or an internal storage device (RAM, ROM, etc.)) of dedicated or general-purpose hardware can be provided to the dedicated or general-purpose hardware via a recording medium, or via a communication line from a server without using a recording medium. This makes it possible to always provide the latest functions through program upgrades. [Industrial Applicability]

[0102] The security design support device of the present invention is intended for automobile-related systems, but may also be intended for systems not related to automobiles. [Explanation of symbols]

[0103] 100,200,300 Security design support device, 101,201 input unit, 102 threat analysis unit, 103 protection asset extraction unit, 104 impact evaluation unit, 105,205 threat scenario generation unit, 106 risk level analysis unit, 107 feasibility evaluation unit, 108,208 risk level evaluation unit, 109 security measure decision unit, 110 multi-hop threat analysis unit, 111 feasibility re-evaluation unit, 112,212 hijacking possibility evaluation unit, 113,213 additional threat scenario generation unit, 114,214 storage unit, 115,215 output unit

Claims

1. An input unit (101, 201) for inputting system information including information indicating components of a system (1) and indicating subsystems (2, 3, 4) constituting the system as the components of the system; a threat scenario generation unit (105, 205) that generates a first threat scenario indicating a possible security threat from the system information and protected asset information indicating a protected asset of the system, using predetermined components of the threat scenario; a risk level assessment unit (108, 208) for determining a risk level of the first threat scenario using a first feasibility that is the feasibility of the first threat scenario; a takeover possibility assessment unit (112, 212) for estimating a takeover possibility, which is the possibility that the subsystem will be taken over, by using a second feasibility, which is the feasibility of the first threat scenario when necessary measures are taken against the first threat scenario having a risk level equal to or higher than a predetermined level; an additional threat scenario generating unit (113, 213) for generating a second threat scenario indicating a security threat that may occur starting from the subsystem that may be hijacked if the hijacking possibility is equal to or higher than a predetermined level; and an output unit (115, 215) that outputs the second threat scenario. A security design support device (100, 200, 300).

2. Furthermore, a protected asset extraction unit (103) that obtains the protected asset information from the system information; a feasibility assessment unit (107) for determining the first feasibility, which is the feasibility of the first threat scenario; a security countermeasure determination unit (109) that determines the necessary countermeasure for the first threat scenario whose risk level is equal to or higher than a predetermined level; a feasibility re-evaluation unit (111) for determining the second feasibility, which is the feasibility of the first threat scenario when the necessary measures are taken; The security design support device (100, 300) according to claim 1.

3. the input unit further inputs at least one of the protected asset information, the first feasibility, the necessary measures, and the second feasibility.

2. The security design support device (200, 300) according to claim 1.

4. The component of the threat scenario that indicates the origin of a threat is either within the subsystem or outside the subsystem; The security design support device according to claim 1.

5. the hijacking possibility assessment unit identifies, from the first threat scenarios for which the second feasibility has been calculated, the first threat scenarios that satisfy at least one of a condition that matches a hijacking route, a condition that matches a hijacking subjectivity, a condition that matches a hijacking result, and a condition that matches a hijacking means, classifies the identified first threat scenarios for each of the subsystems that are the protected assets targeted by the identified first threat scenarios, and calculates the hijacking possibility for each of the subsystems based on the second feasibility of each of the first threat scenarios; The security design support device according to claim 1.

6. the additional threat scenario generation unit generates the second threat scenario by rewriting the origin of the threat in the first threat scenario generated by the threat scenario generation unit to the subsystem that may be hijacked; 5. The security design support device according to claim 4.

7. Further, an impact assessment unit (104) is provided for determining an impact of the protected asset on a risk, the risk level assessment unit determines the risk level of the first threat scenario using the first feasibility and the impact degree; The security design support device according to claim 1.

8. A security design support method executed by a security design support device, comprising: Inputting system information indicating components of a system (1) and including information indicating subsystems (2, 3, 4) constituting the system as the components of the system (S101); A first threat scenario indicating a possible security threat is generated from the system information and protected asset information indicating a protected asset of the system, using predetermined components of the threat scenario (S103); determining a risk level of the first threat scenario using a first feasibility, which is the feasibility of the first threat scenario (S105); estimating a takeover possibility, which is the possibility that the subsystem will be taken over, using a second feasibility, which is the feasibility of the first threat scenario when necessary measures are taken against the first threat scenario having a risk level equal to or higher than a predetermined level (S108); If the hijacking possibility is equal to or greater than a predetermined level, a second threat scenario is generated that indicates a security threat that may occur originating from the subsystem that may be hijacked (S110); outputting the second threat scenario; Security design support methodology.

9. A security design support program executable by a security design support device, Inputting system information indicating components of a system (1) and including information indicating subsystems (2, 3, 4) constituting the system as the components of the system (S101); A first threat scenario indicating a possible security threat is generated from the system information and protected asset information indicating a protected asset of the system, using predetermined components of the threat scenario (S103); determining a risk level of the first threat scenario using a first feasibility, which is the feasibility of the first threat scenario (S105); estimating a takeover possibility, which is the possibility that the subsystem will be taken over, using a second feasibility, which is the feasibility of the first threat scenario when necessary measures are taken against the first threat scenario having a risk level equal to or higher than a predetermined level (S108); If the hijacking possibility is equal to or greater than a predetermined level, a second threat scenario is generated that indicates a security threat that may occur originating from the subsystem that may be hijacked (S110); outputting the second threat scenario; The security design support program causes the security design support device to execute the above steps.

Images