Vulnerability analysis device and vulnerability analysis method

Abstract

To effectively analyze the vulnerability of an analysis target device.SOLUTION: A vulnerability analysis device 2 performs vulnerability analysis of an analysis target device, and includes a vulnerability information acquisition unit 212 that acquires vulnerability information 231 concerning the vulnerability of the analysis target device, an abuse possibility condition deriving unit 213 that derives at least one abuse possibility condition of the possibility of abuse of the vulnerability on the basis of the vulnerability information 231, and an analysis result output unit 218 that outputs the abuse possibility condition derived by the abuse possibility condition deriving unit 213.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to an apparatus and method for analyzing vulnerabilities of a device to be analyzed. [Background technology]

[0002] In recent years, the use of services using IoT (Internet of Things) devices has increased in various fields, and this has led to an increase in cyberattacks targeting vulnerabilities in IoT devices. In order to respond appropriately to cyberattacks targeting these IoT devices, the introduction of PSIRT (Product Security Incident Response Team) has been attracting attention in recent years. PSIRT is an organization responsible for security measures in companies that develop and manufacture IoT devices. It collects and analyzes information on known threats and vulnerabilities, and plans effective countermeasures taking into account the impact on the company's products and services.

[0003] One of the important tasks of a PSIRT is to analyze the possibility that threats and vulnerabilities will cause damage to a company's products based on the collected threat and vulnerability information, and to determine whether or not countermeasures are necessary based on the analysis results. This requires analysts who are knowledgeable about both the company's products and security. However, such analysts are valuable and human resources are limited. Furthermore, as the scale of software used in IoT devices increases, the workload on analysts is increasing day by day. Due to these factors, the operational burden of PSIRTs in companies continues to increase.

[0004] In order to solve the above problems, a device has been proposed that collects and analyzes security information related to vulnerabilities to be analyzed and presents the analysis results to the user, thereby supporting the user who is a security analyst. For example, Patent Document 1 describes an analysis device that evaluates the environmental assessment criteria and basic assessment criteria of the Common Vulnerability Scoring System (CVSS) for vulnerabilities in an information system, and determines whether or not a response to the vulnerabilities in the information system is required based on these assessment results. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Patent No. 7396371 Summary of the Invention [Problem to be solved by the invention]

[0006] The analysis device of Patent Document 1 determines whether or not a vulnerability in an information system needs to be addressed based on a score (index value) defined by CVSS. However, because CVSS scores do not fully take into account the operating environment of an information system, when applied to security analysis of target devices that may be used in various operating environments, such as IoT devices, it is difficult to perform an analysis that accurately reflects the operating environment. Therefore, the analysis method using the analysis device of Patent Document 1 cannot be said to be sufficient for analyzing vulnerabilities in target devices that require analysis tailored to the operating environment, such as IoT devices.

[0007] The present invention has been made in light of the above background, and aims to provide a technique that enables effective analysis of vulnerabilities in a device to be analyzed. [Means for solving the problem]

[0008] A vulnerability analysis device according to the present invention is a device that performs vulnerability analysis of a device to be analyzed, and includes a vulnerability information acquisition unit that acquires vulnerability information regarding vulnerabilities of the device to be analyzed, an exploitable condition derivation unit that derives one or more exploitable conditions under which the vulnerability may be exploited based on the vulnerability information, and an analysis result output unit that outputs the exploitable conditions derived by the exploitable condition derivation unit. A vulnerability analysis method according to the present invention is a method for analyzing vulnerabilities of a device to be analyzed, in which a computer acquires vulnerability information regarding vulnerabilities in the device to be analyzed, derives one or more exploitable conditions under which the vulnerability may be exploited based on the vulnerability information, and presents the exploitable conditions to a user. [Effects of the Invention]

[0009] According to the present invention, it is possible to effectively analyze the vulnerability of a device to be analyzed. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a configuration diagram of a vulnerability analysis system according to an embodiment of the present invention. [Figure 2] FIG. 2 is a diagram illustrating a hardware configuration of a vulnerability analysis device. [Figure 3] FIG. 2 is a functional block diagram of a vulnerability analysis device. [Figure 4] 10 is a flowchart showing a processing flow of the vulnerability analysis device. [Figure 5] 10A and 10B are diagrams illustrating examples of attack models and extraction criteria used to extract exploitable conditions. [Figure 6] FIG. 10 is a diagram illustrating an example of extraction of exploitable conditions. [Figure 7] 10 is a flowchart showing the flow of a process for determining whether or not an exploit is possible. [Figure 8] 10A and 10B are diagrams illustrating examples of determination results of whether or not an exploit is possible for each exploitable condition, and the basis for the determination or suggestions. [Figure 9] FIG. 10 is a diagram illustrating an example of a method for estimating the necessity of countermeasures. DETAILED DESCRIPTION OF THE INVENTION

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

[0012] Fig. 1 is a configuration diagram of a vulnerability analysis system according to one embodiment of the present invention. The vulnerability analysis system 1 shown in Fig. 1 is a system that analyzes vulnerabilities in various IoT devices installed in, for example, railway systems and automobiles, as a business support service for users who belong to a PSIRT that is responsible for security measures for the devices. The vulnerability analysis system 1 is configured by connecting a vulnerability analysis device 2 and a terminal device 3 via a network 4.

[0013] When a user operates the terminal device 3 to designate any information device such as various IoT devices as an analysis target device and make a request for vulnerability analysis, the vulnerability analysis device 2 executes calculation processing in response to the request and provides the obtained information to the terminal device 3. The user can obtain information on the analysis results for vulnerabilities in the analysis target device by checking the contents of the information provided by the vulnerability analysis device 2 on the terminal device 3. The specific contents of the information provided by the vulnerability analysis device 2 will be described later.

[0014] The network 4 is configured using, for example, a LAN (Local Area Network), a WAN (Wide Area Network), the Internet, etc., and transmits data exchanged between the vulnerability analysis device 2 and the terminal device 3. Note that the vulnerability analysis device 2 may also exchange data with other information processing devices (not shown) not included in the vulnerability analysis system 1 via the network 4.

[0015] FIG. 2 is a diagram showing the hardware configuration of the vulnerability analysis device 2. As shown in FIG.

[0016] The vulnerability analysis device 2 is realized by using a general information processing device such as a PC (Personal Computer), a server, etc. As shown in Fig. 2, the vulnerability analysis device 2 includes a processor 21, a memory 22, an external storage device 23, a communication interface (communication IF) 24, an input / output device 25, and a communication bus 26 connecting these components.

[0017] The processor 21 controls each part of the vulnerability analysis device 2 and performs various arithmetic processing related to analyzing vulnerabilities of the device to be analyzed. The processor 21 is configured using, for example, a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit), and can realize each functional block (see FIG. 3 described later) of the vulnerability analysis device 2 by executing a program stored in the memory 22. The memory 22 is, for example, a semiconductor storage device such as a RAM (Random Access Memory), and temporarily stores programs that are loaded from an external storage device 23 and executed by the processor 21, as well as necessary work data.

[0018] The external storage device 23 is, for example, a large-capacity non-transitory magnetic storage device or semiconductor storage device such as a hard disk drive (HDD) or a solid state drive (SSD), and stores programs executed by the processor 21 and data used in the processing of the processor 21. As described above, some or all of these programs and data may be stored in the external storage device 23 in advance, or may be introduced from outside as necessary.

[0019] The communication IF 24 operates under the control of the processor 21 and performs interface processing for sending and receiving various information via the network 4 between the vulnerability analysis device 2 and the terminal device 3, or between the vulnerability analysis device 2 and other information processing devices.

[0020] The input / output device 25 is a device for receiving input from an administrator who manages the vulnerability analysis device 2 and outputting information to be presented to the administrator, and is configured using, for example, a mouse, keyboard, display, and the like.

[0021] FIG. 3 is a functional block diagram of the vulnerability analysis device 2.

[0022] The vulnerability analysis device 2 includes the following functional blocks: a communication unit 211, a vulnerability information acquisition unit 212, an exploitable condition derivation unit 213, an exploitability determination unit 214, a basis content generation unit 215, a suggested content generation unit 216, a countermeasure necessity estimation unit 217, and an analysis result output unit 218. These functional blocks are realized by the processor 21 executing a predetermined program.

[0023] The vulnerability analysis device 2 also has vulnerability information 231, product information 232, and countermeasure necessity estimation related information 233. The countermeasure necessity estimation related information 233 includes an exploitable condition list 2311, constraints 2312, and estimation rules 2313. These pieces of information are stored in the external storage device 23.

[0024] The vulnerability information 231 is information relating to vulnerabilities of the device to be analyzed, and is acquired by the vulnerability information acquisition unit 212 and stored in the external storage device 23 .

[0025] The product information 232 is information relating to the system configuration and product specifications of the device to be analyzed. For example, the product information 232 may include a software bill of materials (SBOM) and a hardware bill of materials (HBOM), which are information indicating the software configuration and hardware configuration of the device to be analyzed, information relating to the program, network settings, and firewall settings of the device to be analyzed, information on the results of various tests previously conducted on the device to be analyzed, and design information of the device to be analyzed.

[0026] The countermeasure necessity estimation related information 233 is information for estimating whether countermeasures are necessary when there is a risk that a vulnerability will be exploited in the device being analyzed. In the countermeasure necessity estimation related information 233, the exploitable condition list 2311 is a list of exploitable conditions that indicate the conditions under which a vulnerability will be exploited in the device being analyzed. Meanwhile, the constraint conditions 2312 indicate constraint conditions that are applied to each item in the exploitable condition list 2311. Furthermore, the estimation rules 2313 indicate estimation rules for whether countermeasures are necessary for each item in the exploitable condition list 2311. Each item in the exploitable condition list 2311 is derived by the exploitable condition derivation unit 213, and the constraint conditions 2312 and the estimation rules 2313 are stored in advance in the external storage device 23.

[0027] The communication unit 211 uses the communication IF 24 in FIG. 2 to perform information communication via the network 4 between the vulnerability analysis device 2 and the terminal device 3, or between the vulnerability analysis device 2 and other information processing devices.

[0028] The vulnerability information acquisition unit 212 acquires vulnerability information related to vulnerabilities of the device to be analyzed. For example, vulnerability information such as CVE (Common Vulnerabilities and Exposures), NVD (National Vulnerability Database), and JVN (Japan Vulnerability Notes), which are databases of vulnerability information managed by predetermined public institutions and made publicly available, as well as various reports and blog information related to vulnerabilities, can be acquired as vulnerability information through information communication using the communication unit 211. The vulnerability information acquired by the vulnerability information acquisition unit 212 is stored in the external storage device 23 in the vulnerability analysis device 2 and used as vulnerability information 231.

[0029] The exploitable condition deriving unit 213 derives, as an exploitable condition, a condition for determining that a vulnerability may be exploited in the analysis target device, based on the vulnerability information 231. For example, by reading the description of the vulnerability represented by the vulnerability information 231 and analyzing and interpreting the description, the exploitable condition deriving unit 213 determines what conditions the analysis target device must satisfy to have the vulnerability exploited in the analysis target device. This makes it possible to derive one or more exploitable conditions from the vulnerability information 231. Each exploitable condition derived by the exploitable condition deriving unit 213 is stored in the external storage device 23 as an item in an exploitable condition list 2311 included in the countermeasure necessity estimation related information 233. Note that a specific example of a method for deriving an exploitable condition by the exploitable condition deriving unit 213 will be described later.

[0030] The exploitability determination unit 214 determines whether or not a vulnerability can be exploited in the device under analysis for each item in the exploitable condition list 2311 derived by the exploitable condition derivation unit 213. For example, the exploitability determination unit 214 can perform an exploitability determination for each derived exploitable condition by referring to the product information 232 and specifically identifying the software configuration, hardware configuration, network settings, firewall settings, etc. of the device under analysis from the contents of the product information 232 and comparing them with each item in the exploitable condition list 2311. Details of the exploitability determination by the exploitability determination unit 214 will be described later.

[0031] The basis content generation unit 215 generates the basis for the result of the exploitability determination by the exploitability determination unit 214. For example, the basis for the exploitability determination can be generated by identifying the contents of the software configuration, hardware configuration, network settings, firewall settings, etc. that are determined to satisfy the exploitability conditions in the device to be analyzed.

[0032] The suggestion content generation unit 216 generates a suggestion for checking the impact of a vulnerability in an analysis target device for an exploitable condition for which the exploitability determination unit 214 cannot make an exploitability determination. For example, to check whether or not an analysis target device is affected by a vulnerability, the suggestion content generation unit 216 can generate a suggestion for the user by identifying which specific parts of the software configuration, hardware configuration, network settings, firewall settings, etc. should be checked.

[0033] The countermeasure necessity estimation unit 217 estimates the necessity of countermeasures for vulnerabilities in the analysis target device based on the result of the exploitability determination for each exploitable condition by the exploitability determination unit 214, the constraint conditions 2312, and the estimation rules 2313. For example, for each exploitable condition determined to be exploitable by the exploitability determination, the countermeasure necessity estimation unit 217 can refer to the corresponding items in the constraint conditions 2312 and the estimation rules 2313 and estimate the necessity of countermeasures based on the combination of these. In this case, for an exploitable condition for which there is no corresponding item in at least one of the constraint conditions 2312 or the estimation rules 2313, the necessity of countermeasures may be estimated based only on the result of the exploitability determination. In this way, it is possible to estimate the necessity of countermeasures in the analysis target device for each exploitable condition.

[0034] The analysis result output unit 218 outputs the processing results of the exploitable condition derivation unit 213, the exploitability determination unit 214, the basis content generation unit 215, the suggested content generation unit 216, and the countermeasure necessity estimation unit 217 to the terminal device 3 as the analysis results of the vulnerability analysis device 2. This allows the analysis results of the vulnerabilities of the device to be analyzed to be presented to the user, and enables business support for the security countermeasures taken by the user to be provided.

[0035] FIG. 4 is a flowchart showing the flow of processing performed by the vulnerability analysis device 2.

[0036] In step S10, the vulnerability information acquisition unit 212 acquires vulnerability information relating to vulnerabilities of the device to be analyzed, and stores it as vulnerability information 231 in the external storage device 23.

[0037] In step S20, the exploitable condition deriving unit 213 extracts exploitable conditions for the vulnerabilities of the device to be analyzed from the vulnerability information 231 acquired in step S10.

[0038] Figure 5 shows an example of an attack model and extraction criteria used to extract exploitable conditions. Figure 5(a) shows a model of an attack on a target device that exploits a vulnerability, and Figure 5(b) shows an example of extraction criteria for exploitable conditions determined based on the attack model in Figure 5(a).

[0039] FIG. 5(a) shows an attack model consisting of the perspectives of vulnerabilities, access paths (external access, internal access), and protected assets. The attack model in FIG. 5(a) is based on the general concept of threat analysis and is a model that overviews and divides the flow of an attack on a target device that exploits a vulnerability. FIG. 5(b) defines criteria for determining whether an exploitable condition exists (existence criteria) and criteria for determining whether the exploitable condition is valid (validity criteria) for each exploitable condition from each perspective of the attack model in FIG. 5(a). In step S120 in FIG. 4, one or more exploitable conditions are extracted from the vulnerability information 231, for example, according to such extraction criteria.

[0040] 6A and 6B are diagrams showing examples of exploitable conditions extracted. Fig. 6A shows an example of CVE information as an example of vulnerability information 231 from which exploitable conditions are extracted. In the vulnerability information 231, the details of the vulnerability are described in the following sentence, for example.

[0041] Figure 6(b) shows an example of an exploitable condition extracted from the CVE information of Figure 6(a). The exploitable condition derivation unit 213 can extract exploitable conditions such as those shown in each row of Figure 6(b) by extracting parts corresponding to the exploitable conditions from the text described in the CVE information of Figure 6(a) in accordance with the extraction criteria exemplified in Figure 5. Note that the process of extracting parts corresponding to the exploitable conditions from the text of vulnerability information can be realized using, for example, AI calculation processing using a well-known trained generation AI or calculation processing using a rule-based algorithm.

[0042] In the example of extracted exploitable conditions shown in Fig. 6(b), each exploitable condition is assigned a priority determined by the exploitable condition deriving unit 213. The higher the priority of an exploitable condition, the higher the priority that should be taken into consideration when taking measures against the vulnerability. The exploitable condition deriving unit 213 can determine the priority of each exploitable condition depending on, for example, the ease of confirmation work or the ease of taking measures.

[0043] Returning to the explanation of FIG. 4, in step S30, one of the exploitable conditions extracted in step S20 is selected.

[0044] In step S40, the exploitability determination unit 214 determines whether the exploitable condition selected in step S30 is exploitable. Here, for example, by executing the process shown in the flowchart of Fig. 7 in the exploitability determination unit 214, it is possible to determine whether the vulnerability corresponding to the selected exploitable condition is exploitable in the device to be analyzed. The flowchart of Fig. 7 will be described in detail later.

[0045] In step S50, it is determined whether or not a determination result of whether or not the exploitability is available has been obtained in the exploitability determination in step S40. If a determination result of whether or not the exploitability is available has been obtained, the process proceeds to step S60. If a determination result of whether or not the exploitability is available has not been obtained, i.e., if it has been determined that the exploitability determination cannot be performed, the process proceeds to step S70.

[0046] In step S60, the basis content generation unit 215 generates a basis for the determination result obtained in the exploitability determination in step S40. Here, the basis for the determination is generated by, for example, identifying the information used in the exploitability determination in step S40 from among various pieces of information about the device to be analyzed contained in the product information 232. This process can be realized, for example, by AI calculation processing using a well-known trained generation AI. Once the basis for the determination has been generated in step S60, the process proceeds to step S80.

[0047] In step S70, the suggestion content generation unit 216 generates suggestions for exploitable conditions for which the exploitability determination in step S40 could not be performed. Here, for example, by identifying the cause of the determination that the exploitability determination in step S40 was not possible, a measure is devised for the user to confirm the impact of the vulnerability for the exploitable condition in the device to be analyzed, and this is used as a proposal (suggestion) to the user. This process can be realized, for example, by AI calculation processing using a well-known trained generation AI. If a suggestion can be generated in step S70, proceed to step S80.

[0048] In step S80, it is determined whether there are any other exploitable conditions among the exploitable conditions extracted in step S20, in addition to the ones selected in step S30. If there are other exploitable conditions, i.e., if there are unselected exploitable conditions, the process returns to step S30, and one of the unselected exploitable conditions is selected in step S30, after which the processes from step S30 onwards are carried out. By repeating the processes of steps S30 to S80 in this manner, for each exploitable condition derived from the vulnerability information 231, a determination result of whether or not the exploit is possible, and the basis for that determination or a suggestion, are determined.

[0049] Fig. 8 is a diagram showing an example of the determination result of whether or not an exploit is possible for each exploitable condition and the basis for the determination or a suggestion. In this example, the determination result of whether or not an exploit is possible for each of the exploitable conditions exemplified in Fig. 6(b) ("Applicable" / "Unconfirmed") and the basis for the determination result (if the determination result of whether or not an exploit is possible is "Applicable") or a suggestion (if the determination result of whether or not an exploit is possible is "Unconfirmed") are shown.

[0050] On the other hand, if it is determined in step S80 of FIG. 4 that there are no other exploitable conditions, that is, if all the exploitable conditions have been selected, the process proceeds to step S90.

[0051] In step S90, the countermeasure necessity estimation unit 217 estimates whether countermeasures are necessary for the vulnerability in the device being analyzed based on the results of the exploitability determination for each exploitable condition obtained by the exploitability determination in step S40, and the pre-stored constraint conditions 2312 and estimation rules 2313.

[0052] 9 is a diagram showing an example of a method for estimating the need for countermeasures. The example in FIG. 9 shows a case where the exploitability determination result for "version" among the items of the exploitable conditions shown in the exploitable condition list 2311 is "yes," and there is an item corresponding to this exploitable condition in the constraint conditions 2312 and the estimation rule 2313. In such a case, for example, the type of constraint condition corresponding to "version" is identified in the constraint conditions 2312, and further, the estimation rule 2313 identifies an exploitability condition pattern according to the type of constraint condition. In this exploitability condition pattern, the value of the part corresponding to the aforementioned "version" is read to estimate the need for countermeasures.

[0053] Specifically, the numerical value of the exploitability judgment result is compared with the numerical value read from the exploitability condition pattern of the inference rule 2313, and if the values ​​of the relevant part do not match, the invalid condition of the inference rule 2313 is referenced. Then, the item in the exploitable condition list 2311 corresponding to the part set to "0" in the invalid condition is referenced, and the inferred result of whether countermeasures are necessary is determined based on the exploitability judgment result of this item. In this way, if the exploitability judgment result is "Yes (0)", not only this judgment result but also the combination of the exploitability condition pattern and the invalid condition specified in the inference rule 2313 is taken into consideration to infer whether countermeasures are necessary.

[0054] In the example of FIG. 9 , when focusing on “Version” in the exploitability condition list 2311, the exploitability judgment result is “Yes (0).” Meanwhile, in the exploitability condition pattern of the inference rule 2313, the value of the item corresponding to “Version” is set to “1.” Because these values ​​do not match, when the corresponding invalid condition in the inference rule 2313 is referenced, the first item in the invalid condition is set to “0.” As a result, in order to adopt the above exploitability judgment result as the inferred result of whether or not a countermeasure is required, it is determined that the exploitability judgment result for the first item in the exploitability condition list 2311 (whose exploitability condition is “Software”) must be “Yes (0).” However, in the example of FIG. 9 , since the exploitability judgment result for that item is “No (1),” the above exploitability judgment result is not adopted, and the inferred result is that no countermeasure is required. In other words, although the “Version” among the exploitability conditions is determined to be exploitable, since the software does not meet the exploitability condition in the first place, it is inferred that no countermeasure is required for the vulnerability of that item.

[0055] 4, the analysis result output unit 218 outputs the processing results obtained by the processes of steps S20, S40, S60, S70, and S90 to the terminal device 3. As a result, the user is presented on the terminal device 3 with the priority order for each exploitable condition shown in FIG. 8, the determination result of whether or not the exploit is possible, and the basis / suggestion for the determination, as well as the corresponding estimation result of whether or not measures against the vulnerability in the device to be analyzed are necessary.

[0056] After executing the process of step S100, the vulnerability analysis device 2 ends the process shown in the flowchart of FIG.

[0057] Next, the flowchart in Fig. 7 will be described below. Fig. 7 is a flowchart showing the process flow of determining whether or not an exploit is possible. As described above, in step S40 in Fig. 4, the exploitability determination unit 214 determines whether or not an exploitable condition is exploitable by executing, for example, the process shown in the flowchart in Fig. 7.

[0058] In step S110, an exploitable condition to be judged is identified. Here, the exploitable condition selected in the immediately preceding step S30 in the flowchart of Fig. 4 is identified as the exploitable condition to be judged.

[0059] In step S120, it is determined whether the exploitable condition of the target identified in step S110 is subject to refinement. If it is subject to refinement, the process proceeds to step S130, where the exploitable condition of the target is refined, and then the process proceeds to step S140. On the other hand, if it is not subject to refinement, the process proceeds to step S140 without executing step S130. Here, it is possible to determine whether it is subject to refinement based on, for example, the type and content of the exploitable condition of the target.

[0060] In step S140, it is determined whether or not there is additional information for the exploitable condition of the determination target identified in step S110. If there is additional information, the process proceeds to step S150, where the additional information corresponding to the exploitable condition of the determination target is acquired, and then the process proceeds to step S160. On the other hand, if there is no additional information, the process proceeds to step S160 without executing step S150. Here, the presence or absence of additional information can be determined by searching for information related to the exploitable condition of the determination target in, for example, the vulnerability information 231 or the product information 232.

[0061] In step S160, it is determined whether or not it is possible to determine whether or not the exploitability condition of the determination target identified in step S110 is met. Here, for example, product information 232 is searched for information necessary to determine whether or not the exploitability condition of the determination target is met. At this time, if the processing of steps S130 and S150 has been performed, the information acquired by these processing is included in the search targets. As a result, if the necessary information can be found, it is determined that the exploitability determination is possible, and the process proceeds to step S170; if the information cannot be found, it is determined that the exploitability determination is impossible, and the process proceeds to step S200.

[0062] In step S170, it is determined whether the exploitability condition of the target identified in step S110 is satisfied based on the information retrieved in step S160. If the exploitability condition of the target is satisfied, the process proceeds to step S180; if not, the process proceeds to step S190.

[0063] In step S180, it is determined that the exploitable condition identified in step S110 is exploitable, and the process proceeds to step S210.

[0064] In step S190, it is determined that the exploitable condition identified in step S110 is not exploitable, and the process proceeds to step S210.

[0065] In step S200, it is determined that it is not possible to perform an exploitability determination for the exploitable condition identified in step S110, and the process proceeds to step S210.

[0066] In step S210, the determination result obtained in step S180, S190, or S200 is output as the result of the exploitability determination. As a result, the result of the exploitability determination performed in step S40 of Fig. 4 is obtained as a determination result that the exploitable condition is exploitable or not exploitable, or a determination result that it is not possible to perform an exploitability determination for the exploitable condition. Based on this determination result, the determination process of step S50 of Fig. 4 is performed.

[0067] According to the embodiment of the present invention described above, the following advantageous effects can be obtained.

[0068] (1) The vulnerability analysis device 2 is a device that performs vulnerability analysis of a target device, and includes a vulnerability information acquisition unit 212 that acquires vulnerability information 231 related to vulnerabilities of the target device, an exploitable condition derivation unit 213 that derives one or more exploitable conditions under which the vulnerability may be exploited based on the vulnerability information 231, and an analysis result output unit 218 that outputs the exploitable conditions derived by the exploitable condition derivation unit 213. This configuration makes it possible to effectively analyze the vulnerabilities of target devices that may be used in various operating environments, such as IoT devices.

[0069] (2) The exploitable condition derivation unit 213 determines a priority for each exploitable condition according to the ease of confirmation work and countermeasures. The analysis result output unit 218 outputs the priority determined for each exploitable condition. This makes it possible to present to the user, for each exploitable condition, the priority to be considered when taking countermeasures against vulnerabilities, and provide useful security analysis results.

[0070] (3) The exploitable condition derivation unit 213 can derive exploitable conditions using a generation AI, which makes it possible to derive all exploitable conditions from the vulnerability information 231 written in various ways.

[0071] (4) The vulnerability analysis device 2 includes an exploitability determination unit 214 that determines whether or not a vulnerability can be exploited in an analysis target device for each exploitable condition derived by the exploitable condition derivation unit 213, based on product information 232 related to the specifications of the analysis target device and the exploitable condition. The analysis result output unit 218 outputs the result of the exploitability determination for each exploitable condition made by the exploitability determination unit 214. This configuration allows the user to be informed of whether or not the exploitable condition is actually likely to be exploited in the analysis target device, thereby providing more useful security analysis results.

[0072] (5) The analysis result output unit 218 outputs, for each exploitable condition, information on at least one of the basis of the exploitability determination made by the exploitability determination unit 214, generated by the basis content generation unit 215, and a proposal for confirming the impact of the vulnerability in the analysis target device, generated by the suggestion content generation unit 216. Specifically, for an exploitable condition for which the exploitability determination unit 214 has determined that the vulnerability in the analysis target device is exploitable, based on the exploitability determination performed in step S40 of FIG. 4, the analysis result output unit 218 outputs information on the basis of the determination result. On the other hand, for an exploitable condition for which the exploitability determination cannot be performed, the analysis result output unit 218 outputs information on the proposal for confirming the impact of the vulnerability in the analysis target device. In this manner, it is possible to provide useful security analysis results corresponding to the results of the exploitability determination for each exploitable condition.

[0073] (6) The vulnerability analysis device 2 includes a countermeasure necessity estimation unit 217 that estimates the necessity of countermeasures against vulnerabilities in the analysis target device based on the result of the exploitability determination for each exploitable condition by the exploitability determination unit 214, and the preset constraint conditions 2312 and estimation rules 2313. As a result, it is possible to accurately estimate whether countermeasures against vulnerabilities in the analysis target device are necessary for the acquired vulnerability information 231, using the result of the exploitability determination for each exploitable condition.

[0074] (7) The vulnerability analysis device 2, which is a computer, acquires vulnerability information about vulnerabilities in the analysis target device (step S10), and derives one or more exploitable conditions under which the vulnerability may be exploited based on the acquired vulnerability information (step S20). Then, each of the derived exploitable conditions is presented to the user (step S100). This allows for effective vulnerability analysis of the analysis target device, such as an IoT device, which may be used in various operating environments.

[0075] It goes without saying that the present invention is not limited to the above-described embodiments and can be modified in various ways without departing from the spirit of the present invention. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those having all of the described configurations. Furthermore, it is possible to add, delete, or replace part of the configuration of the above-described embodiments with other configurations.

[0076] Furthermore, the above-mentioned configurations, functional units, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-mentioned configurations, functions, etc. may also be implemented in software, with a processor interpreting and executing a program that implements each function. Information such as the programs, tables, and files that implement each function can be stored in a memory, a hard disk, a recording device such as an SSD, an IC card, an SD card, a DVD, or other recording media.

[0077] In addition, in the above figures, the control lines and information lines shown are those that are considered necessary for explanation, and do not necessarily show all the control lines and information lines that are actually implemented. For example, it can be considered that almost all components are actually connected to each other.

[0078] The above-described layout of the various functional units, processing units, and databases is merely an example, and may be changed to an optimal layout in terms of the performance, processing efficiency, communication efficiency, etc., of the hardware and software included in these devices. [Explanation of symbols]

[0079] 1: Vulnerability analysis system, 2: Vulnerability analysis device, 3: Terminal device, 4: Network, 21: Processor, 22: Memory, 23: External storage device, 24: Communication interface, 25: Input / output device, 26: Communication bus, 211: Communication unit, 212: Vulnerability information acquisition unit, 213: Exploitability condition derivation unit, 214: Exploitability determination unit, 215: Basis content generation unit, 216: Suggested content generation unit, 217: Countermeasure necessity estimation unit, 218: Analysis result output unit, 231: Vulnerability information, 232: Product information, 233: Countermeasure necessity estimation related information, 2311: Exploitability condition list, 2312: Constraint condition, 2313: Estimation rule

Claims

1. An apparatus for performing vulnerability analysis of an analysis target device, a vulnerability information acquisition unit that acquires vulnerability information related to vulnerabilities in the analysis target device; an exploitable condition deriving unit that derives one or more exploitable conditions under which the vulnerability may be exploited based on the vulnerability information; an analysis result output unit that outputs the exploitable conditions derived by the exploitable condition derivation unit, Vulnerability analysis device.

2. The vulnerability analysis device according to claim 1 , the exploitable condition derivation unit determines a priority order for each of the exploitable conditions according to the ease of confirmation work and countermeasures; the analysis result output unit outputs the priority determined for each of the exploitable conditions. Vulnerability analysis device.

3. The vulnerability analysis device according to claim 1 , The exploitable condition derivation unit derives the exploitable condition using a generation AI. Vulnerability analysis device.

4. The vulnerability analysis device according to claim 1 , an exploitability determination unit that determines whether or not the vulnerability can be exploited in the analysis target device, for each exploitable condition derived by the exploitable condition derivation unit, based on product information related to the specifications of the analysis target device and the exploitable condition; the analysis result output unit outputs a result of the exploitability determination made by the exploitability determination unit for each of the exploitable conditions. Vulnerability analysis device.

5. The vulnerability analysis device according to claim 4, the analysis result output unit outputs, for each exploitable condition, information on at least one of a basis for the exploitability determination and a proposal for confirming the impact of the vulnerability on the analysis target device. Vulnerability analysis device.

6. The vulnerability analysis device according to claim 5, The analysis result output unit outputting information on the basis of the determination result for the exploitability condition for which the exploitability determination unit determines that the vulnerability can be exploited in the analysis target device based on the exploitability determination; For the exploitable condition for which the exploitability determination cannot be performed, output information about the proposal. Vulnerability analysis device.

7. The vulnerability analysis device according to claim 4, a countermeasure necessity estimation unit that estimates the necessity of a countermeasure against the vulnerability in the analysis target device based on a result of the exploitability determination by the exploitability determination unit for each of the exploitable conditions, and on preset constraint conditions and estimation rules; Vulnerability analysis device.

8. A method for performing vulnerability analysis of an analysis target device, comprising: By computer, Obtain vulnerability information regarding vulnerabilities in the analysis target device; deriving one or more exploitable conditions under which the vulnerability may be exploited based on the vulnerability information; presenting the exploitable condition to a user; Vulnerability analysis method.

Images