Vulnerability analysis device and vulnerability analysis method

Abstract

This vulnerability analysis device performs vulnerability analysis on a device to be analyzed. The vulnerability analysis device comprises: a vulnerability information acquisition unit that acquires vulnerability information pertaining to the vulnerability of the device to be analyzed; an exploitable condition derivation unit that derives, on the basis of the vulnerability information, at least one exploitable condition in which the vulnerability could be exploited; and an analysis result output unit that outputs the exploitable condition derived by the exploitable condition derivation unit.

Description

Vulnerability analysis device, vulnerability analysis method

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

[0002] In recent years, the use of services using IoT (Internet of Things) devices has increased in various fields, leading to an increase in cyberattacks targeting vulnerabilities in IoT devices. In order to respond appropriately to cyberattacks targeting IoT devices, the introduction of Product Security Incident Response Teams (PSIRTs) has been attracting attention in recent years. A PSIRT is an organization responsible for security measures in companies that develop or manufacture IoT devices. It collects and analyzes information on known threats and vulnerabilities, and develops 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 potential damage that threats and vulnerabilities may cause to a company's products based on the collected threat and vulnerability information, and to determine whether 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 PSIRT at 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.

[0005] Japanese Patent No. 7396371

[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 the CVSS score does not fully take into account the operating environment of the 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 according 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.

[0008] A vulnerability analysis device according to the present invention is a device for analyzing vulnerabilities of an analysis target device, and includes: a vulnerability information acquisition unit that acquires vulnerability information related to vulnerabilities of the analysis target device, 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 an analysis target device, and includes: acquiring vulnerability information related to vulnerabilities of the analysis target device, deriving one or more exploitable conditions under which the vulnerability may be exploited based on the vulnerability information, and presenting the exploitable conditions to a user.

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

[0010] 1 is a configuration diagram of a vulnerability analysis system according to an embodiment of the present invention; FIG. 2 is a diagram illustrating the hardware configuration of a vulnerability analysis device; FIG. 3 is a functional block diagram of a vulnerability analysis device; FIG. 4 is a flowchart illustrating the processing flow of a vulnerability analysis device; FIG. 5 is a diagram illustrating examples of attack models and extraction criteria used to extract exploitable conditions; FIG. 6 is a diagram illustrating an example of extraction of exploitable conditions; FIG. 7 is a flowchart illustrating the processing flow of exploitability determination; FIG. 8 is a diagram illustrating an example of a determination result of exploitability for each exploitable condition and a determination basis or suggestion; and FIG. 9 is a diagram illustrating an example of a method for estimating the need for countermeasures.

[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 belonging 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 content of the information provided by the vulnerability analysis device 2 on the terminal device 3. The specific content of the information provided by the vulnerability analysis device 2 will be described later.

[0014] The network 4 is configured using, for example, a local area network (LAN), a wide area network (WAN), the Internet, or the like, 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.

[0016] The vulnerability analysis device 2 is realized 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 central processing unit (CPU) or a graphics processing unit (GPU), and can realize each functional block (see FIG. 3 described below) of the vulnerability analysis device 2 by executing programs stored in the memory 22. The memory 22 is, for example, a semiconductor storage device such as a random access memory (RAM), and temporarily stores programs loaded from the 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 transmitting 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, etc.

[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 related 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 related 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 in the device under analysis will be exploited. 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 in the device under analysis will be exploited. 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 can be acquired from databases of vulnerability information managed by predetermined public institutions and made publicly available, such as CVE (Common Vulnerabilities and Exposures), NVD (National Vulnerability Database), and JVN (Japan Vulnerability Notes), as well as various reports and blog information related to vulnerabilities, via 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 in the analysis target device may be exploited, based on the vulnerability information 231. For example, by reading a 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 potentially exploit the vulnerability 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 in 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 makes it possible to present the analysis results of the vulnerabilities of the device to be analyzed to the user, and to provide operational support for the security countermeasures that the user takes.

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

[0036] In step S10 , the vulnerability information acquisition unit 212 acquires vulnerability information relating to vulnerabilities in 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] 5A and 5B are diagrams showing examples of attack models and extraction criteria used to extract exploitable conditions. Fig. 5A shows a model of an attack on a target device that exploits a vulnerability, and Fig. 5B shows an example of extraction criteria for exploitable conditions determined based on the attack model in Fig. 5A.

[0039] FIG. 5A shows an attack model based on the perspectives of vulnerabilities, access routes (external access, internal access), and protected assets. The attack model in FIG. 5A is a model that overviews and divides the flow of an attack on a target device that exploits vulnerabilities based on a general threat analysis concept. FIG. 5B 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. 5A. In step S120 of 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. 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 content of the vulnerability is 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 as shown in each row of Figure 6(b) by extracting parts corresponding to the exploitable conditions from the sentences 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 sentences 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 the exploitable condition should be considered 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, the exploitability determination unit 214 executes the process shown in the flowchart of Fig. 7 to determine whether the vulnerability corresponding to the selected exploitable condition is exploitable in the device to be analyzed. Details of the flowchart of Fig. 7 will be described later.

[0045] In step S50, it is determined whether or not a determination result of whether or not the exploitability is possible has been obtained in the exploitability determination in step S40. If a determination result of whether or not the exploitability is possible has been obtained, the process proceeds to step S60. If a determination result of whether or not the exploitability is possible 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 abuseability determination in step S40. Here, the basis for the determination is generated by, for example, identifying the information used in the abuseability 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 generator 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 one 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 exploitable condition can be exploited, and the basis for that determination or a suggestion, are determined.

[0049] 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 shown in FIG. 6B ("Applicable" / "Unconfirmed") and the basis for the determination result (if the determination result of whether or not the exploit is possible is "Applicable") or a suggestion (if the determination result of whether or not the 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 equipment 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 condition 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 condition 2312, and further, the estimation rule 2313 identifies an exploitability condition pattern according to the type of constraint condition. The need for countermeasures is estimated by reading the numerical value of the part corresponding to the aforementioned "version" in this exploitability condition pattern.

[0053] Specifically, the numerical value of the exploitability determination result is compared with the numerical value read from the exploitability condition pattern of the estimation rule 2313, and if the values ​​of the relevant part do not match, the invalid condition of the estimation rule 2313 is referenced. Then, the item in the exploitable condition list 2311 corresponding to the part where the invalid condition is set to "0" is referenced, and the estimation result of whether countermeasures are necessary is determined based on the exploitability determination result of this item. As a result, if the exploitability determination result is "Yes (0)," the necessity of countermeasures is estimated not only by this determination result but also by taking into consideration the combination of the exploitability condition pattern and the invalid condition specified in the estimation rule 2313.

[0054] In the example of FIG. 9 , focusing on “Version” in the exploitability condition list 2311, the exploitability judgment result is “Yes (0).” Meanwhile, in the exploitability condition pattern of the estimation 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 estimation 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 an estimation 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 an estimation result is obtained 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 estimated 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 countermeasures against vulnerabilities in the device to be analyzed are required.

[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 the exploitability determination. As described above, in step S40 in Fig. 4, the exploitability determination unit 214 determines whether the 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 additional information is available for the exploitable condition of the target identified in step S110. If additional information is available, the process proceeds to step S150, where the additional information corresponding to the exploitable condition of the target is acquired, and then the process proceeds to step S160. On the other hand, if no additional information is available, 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 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 target identified in step S110 is met. Here, for example, the product information 232 is searched for information necessary to determine whether or not the target satisfies the exploitability condition. At this time, if the processing of steps S130 and S150 has been performed, the information acquired by these processing steps 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 necessary 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 of the exploitability determination performed in step S40 of Fig. 4, 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, is obtained. 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 checking and countermeasures. The analysis result output unit 218 outputs the priority determined for each exploitable condition. This allows the user to be presented with a priority for each exploitable condition that should be considered when countering vulnerabilities, thereby providing useful security analysis results.

[0070] (3) The exploitable condition derivation unit 213 can derive exploitable conditions using the generation AI, which makes it possible to derive all exploitable conditions from the vulnerability information 231 described 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 the analysis target device for each exploitable condition derived by the exploitable condition derivation unit 213, based on the 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 regarding at least one of the basis for the exploitability determination 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 determines 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 regarding the basis for 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 regarding a 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 regarding 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 IoT devices, 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-described 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-described 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 recording device such as a hard disk or SSD, or a recording medium such as an IC card, an SD card, or a DVD.

[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.

[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: Exploitable 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: Exploitable condition list, 2312: Constraint condition, 2313: Estimation rule

Claims

1. A vulnerability analysis device that performs vulnerability analysis on a device to be analyzed, comprising: a vulnerability information acquisition unit that acquires vulnerability information related to vulnerabilities in 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.

2. A vulnerability analysis device as described in claim 1, wherein the exploitable condition derivation unit determines a priority for each of the exploitable conditions according to the ease of confirmation work and countermeasures, and the analysis result output unit outputs the priority determined for each of the exploitable conditions.

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

4. A vulnerability analysis device as described in claim 1, comprising 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 exploitability condition derivation unit, based on product information related to the specifications of the analysis target device and the exploitable condition, and the analysis result output unit outputs the results of the exploitability determination made by the exploitability determination unit for each exploitable condition.

5. A vulnerability analysis device according to claim 4, wherein the analysis result output unit outputs, for each exploitable condition, information relating to at least one of the grounds for determining whether or not the vulnerability can be exploited and a proposal for confirming the impact of the vulnerability on the device to be analyzed.

6. A vulnerability analysis device according to claim 5, wherein the analysis result output unit outputs information on the basis of the determination result for an exploitable condition for which the exploitability determination unit has determined that the vulnerability can be exploited in the device to be analyzed based on the exploitability determination, and outputs information on the proposal for an exploitable condition for which the exploitability determination cannot be performed.

7. A vulnerability analysis device according to claim 4, further comprising a countermeasure necessity estimation unit that estimates the necessity of countermeasures for the vulnerability in the device to be analyzed based on the results of the exploitability determination for each exploitable condition by the exploitability determination unit, and on preset constraint conditions and estimation rules.

8. A method for analyzing vulnerabilities of a device to be analyzed, comprising: acquiring vulnerability information regarding vulnerabilities in the device to be analyzed by a computer; deriving one or more exploitable conditions under which the vulnerability may be exploited based on the vulnerability information; and presenting the exploitable conditions to a user.

Images