Vulnerability countermeasure management system and vulnerability countermeasure management method

Abstract

To properly formulate countermeasures against vulnerability while considering a request response period or a period required for implementing countermeasures.SOLUTION: A vulnerability countermeasure management system is configured to: acquire, as needed, configuration information of software, and vulnerability information which is information on vulnerability of constituent components of the software; store a countermeasure implementation period, which is a period required for implementing each of countermeasure candidates against vulnerability; detect vulnerability of the constituent components based on the vulnerability information; determine a response deadline at which the countermeasures against the vulnerability should be completed, based on a request response period at which the countermeasures are to be completed, which is acquired based on the vulnerability information of the detected vulnerability and required for the vulnerability; and generate a plan for countermeasures against the vulnerability so that the countermeasures against the vulnerability meet the response deadline, based on a countermeasure implementation period of the detected vulnerability.SELECTED DRAWING: Figure 2D

Description

[Technical Field]

[0001] The present invention relates to a vulnerability countermeasure management system and a vulnerability countermeasure management method. [Background technology]

[0002] Patent Document 1 describes an inspection device configured for the purpose of presenting countermeasures for vulnerabilities for an entire system. Based on system configuration information indicating the configuration of a system including multiple devices and vulnerability information indicating vulnerabilities in the multiple devices, the inspection device generates vulnerability assessment items for each device, each of which corresponds to a device, a method for assessing the vulnerability of the device, and a criterion for determining the results of the assessment method. The inspection device executes the assessment method described in the assessment item and generates a vulnerability assessment result for the device by comparing the results of the assessment method with the criterion. The inspection device extracts devices that do not meet the criterion from the assessment result. The inspection device obtains vulnerability countermeasures for the extracted devices from a vulnerability countermeasure database that holds multiple types of vulnerability countermeasures. The inspection device generates a countermeasure list that includes the obtained vulnerability countermeasures and identification information that identifies the devices. The inspection device determines whether the vulnerability countermeasures included in the countermeasure list can be implemented as countermeasures for vulnerabilities in the devices identified by the identification information. If the countermeasures are determined to be implementable, the inspection device generates countermeasure information that includes the vulnerability countermeasures. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] International Publication No. 2021 / 144975 Summary of the Invention [Problem to be solved by the invention]

[0004] In recent years, with the advancement of system development utilizing cloud computing and OSS (Open Source Software), the number of vulnerability information disclosures and cyber attacks targeting vulnerabilities has increased, and organizations such as companies and public institutions are increasingly establishing guidelines for countermeasures against vulnerabilities.

[0005] The above guidelines require that when a vulnerability is discovered, the extent of its impact must be investigated to determine whether or not countermeasures are necessary and the urgency of the action, and that countermeasures must be taken, and that the response to the vulnerability must be completed within a specified period (hereinafter referred to as the "required response period").

[0006] The best state after addressing a vulnerability is when the software affected by the vulnerability has been updated to a fixed version. However, in cases where it is necessary to wait for the provision of a fixed version of the software (including the provision of a security patch), it may be necessary to take temporary measures to address the vulnerability in order to meet the required response period, which can make it difficult to plan appropriate measures to address the vulnerability.

[0007] In the above-mentioned Patent Document 1, countermeasures against vulnerabilities for the entire system are proposed using the CVSS (Common Vulnerability Scoring System) (severity of vulnerabilities) etc. However, the document does not mention that countermeasures are proposed taking into consideration the required response time or the time required to implement the countermeasures.

[0008] The present invention has been made in light of the above background, and aims to provide a vulnerability countermeasure management system and a vulnerability countermeasure management method that are capable of appropriately planning countermeasures against vulnerabilities while taking into account the time required to respond to requests and the time required to implement the countermeasures. [Means for solving the problem]

[0009] One aspect of the present invention for achieving the above-mentioned object is a vulnerability countermeasure management system that is configured using one or more information processing devices each having a processor and a storage device, and that periodically acquires software configuration information and vulnerability information that is information regarding vulnerabilities in the components of the software, and stores a countermeasure implementation period, which is the period required to implement each candidate countermeasure for a vulnerability, detects vulnerabilities in the components based on the vulnerability information, and determines a response deadline, which is the deadline by which countermeasures for the vulnerability must be completed, based on a required response period, which is the period required for completing countermeasures for the vulnerability, obtained based on the vulnerability information for the detected vulnerability, and generates a countermeasure proposal for the vulnerability so that the countermeasure for the vulnerability can be completed in time for the response deadline, based on the countermeasure implementation period for the detected vulnerability.

[0010] Other problems and solutions disclosed in the present application will be made clear in the detailed description and drawings. [Effects of the Invention]

[0011] According to the present invention, it is possible to appropriately plan countermeasures against vulnerabilities while taking into consideration the period required to respond to requests and the period required to implement countermeasures. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram illustrating a schematic configuration of a vulnerability countermeasure management system. [Figure 2A] FIG. 2 is a diagram showing main functions of the runtime environment device. [Figure 2B] FIG. 2 is a diagram illustrating main functions of the verification environment device. [Figure 2C] FIG. 2 is a diagram illustrating main functions of a vulnerability information providing device. [Figure 2D] FIG. 2 is a diagram illustrating main functions of the countermeasure management device. [Figure 3A] 10 is an example of software configuration information. [Figure 3B] 10 is an example of vulnerability information. [Figure 3C]10 is an example of request response period information. [Figure 3D] 10 is an example of countermeasure candidate information. [Figure 3E] 10 is an example of countermeasure proposal information. [Figure 4] FIG. 10 is a sequence diagram illustrating an information acquisition and generation process. [Figure 5] 10 is an example of an information setting screen. [Figure 6] FIG. 10 is a sequence diagram illustrating a countermeasure management process. [Figure 7] 10 is a flowchart illustrating a countermeasure proposal generation process. [Figure 8] 10 is a flowchart illustrating a countermeasure status update process. [Figure 9] 10 is an example of a countermeasure proposal presentation screen. [Figure 10] 1 is an example of an information processing device used to realize a vulnerability countermeasure management system. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Note that the following embodiment is merely an example for explaining the present invention, and for clarity of explanation, appropriate omissions and simplifications have been made. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural.

[0014] In the following, various types of information may be described using expressions such as "information" and "data" as examples, but the data structure of the various types of information may also be expressed in other ways such as "table" and "diagram."

[0015] In the following description, when describing identification information, expressions such as "identifier," "ID," and "identification information" may be used, but these can be used interchangeably.

[0016] In the following description, the letter "S" before a reference numeral denotes a processing step.

[0017] In the following description, a "security patch" may be referred to as a "patch."

[0018] 1 shows a schematic configuration of a vulnerability countermeasure management system 1 described as one embodiment of the present invention. As shown in the figure, the vulnerability countermeasure management system 1 includes an execution environment device 200, a verification environment device 300, a vulnerability information providing device 400, and a countermeasure management device 100. Each of the execution environment device 200, the verification environment device 300, the vulnerability information providing device 400, and the countermeasure management device 100 is configured using one or more information processing devices (computers).

[0019] The execution environment device 200, the verification environment device 300, the vulnerability information providing device 400, and the countermeasure management device 100 are connected to each other in a state where they can communicate with each other bidirectionally via a communication network 5. The communication network 5 is, for example, a wireless or wired communication infrastructure configured using physical communication lines, such as the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), various public communication networks, dedicated lines, etc.

[0020] The execution environment device 200 provides an execution environment (for example, a production environment) for software (application software, an operating system, a device driver, etc.). The software executed by the execution environment device 200 includes multiple components. The above software includes, for example, open system software (OSS (Open Source Software)) and proprietary system software as components.

[0021] The execution environment device 200 generates configuration information of the software executed in the execution environment device 200 (hereinafter referred to as "software configuration information") and provides the generated software configuration information to the countermeasure management device 100 and the verification environment device 300 as needed.

[0022] The components of the software executed in the execution environment device 200 may have dependencies (inclusion relationships, hierarchical structures) with other components of the software. The software configuration information includes information about the dependencies and licenses between the components of the software. The software configuration information is, for example, information managed by a software bill of materials (SBOM).

[0023] In the following explanation, among the components in a dependent relationship, the component that corresponds to the containing side (or higher level) is referred to as the "primary," and the component that corresponds to the contained side (or lower level) is referred to as the "secondary."

[0024] The verification environment device 300 is used (operated) by a person (hereinafter also referred to as a "user") who verifies, develops, maintains, etc. software executed in the execution environment device 200. The verification environment device 300 verifies software executed in the execution environment device 200 that has been treated against vulnerabilities.

[0025] The vulnerability information providing device 400 provides various information (hereinafter referred to as "vulnerability information") related to vulnerabilities in software executed in the execution environment device 200 to the countermeasure management device 100 via the communication network 5. The vulnerability information providing device 400 is operated, for example, by an organization (such as various public institutions (government agencies, academic institutions, etc.), various companies such as vendors, etc.) that collects, organizes, and provides vulnerability information. The vulnerability information includes, for example, information identifying software having a vulnerability, the severity of the vulnerability, the publication date of the vulnerability information, the status of countermeasures against the vulnerability (such as the status of provision of software for countering the vulnerability (hereinafter referred to as "countermeasure versions")), the method of countering the vulnerability, and the substance of the countermeasure versions.

[0026] In the following explanation, when we say "a countermeasure version has been provided (released)," it refers to the provision of not only the countermeasure version itself, but also the provision (release) of a security patch to update existing software to the countermeasure version. Also, in the following explanation, when we say "provision of a countermeasure version," it refers to the provision of a security patch to create a countermeasure version. Also, in the following explanation, when we say "countermeasure version," it refers to the security patch and software created by applying a security patch to existing software.

[0027] The countermeasure management device 100 acquires software configuration information from the execution environment device 200 as needed. The countermeasure management device 100 also acquires vulnerability information from the vulnerability information providing device 400 as needed. Note that the countermeasure management device 100 can also acquire software configuration information and vulnerability information by other methods, such as acquiring software configuration information and vulnerability information from a user via a user interface.

[0028] The countermeasure management device 100 checks whether vulnerability information exists for each component of software executed in the execution environment device 200 (for example, a component identified by a package name and a version number), and manages information (countermeasure candidate information 114, described later) that associates the vulnerability information with the component where vulnerability information exists (hereinafter also referred to as a "component in which vulnerability information has been detected").

[0029] The countermeasure management device 100 manages the software configuration information and vulnerability information acquired in the past (history of the software configuration information and vulnerability information) in association with the respective acquisition dates and times.

[0030] For example, if there is a difference between the newly acquired software configuration information or vulnerability information and the previously acquired information, the countermeasure management device 100 redetects vulnerabilities for the latest software components using the latest vulnerability information and updates the above information. The countermeasure management device 100 generates countermeasure proposals for the components in which vulnerabilities have been detected and presents the generated countermeasure proposals to the user.

[0031] 2A shows the main functions of the execution environment device 200. As shown in the figure, the execution environment device 200 has the functions of a storage unit 210, a software execution management unit 220, a software configuration information generation unit 225, and a software configuration information transmission unit 230.

[0032] Of the above functions, the storage unit 210 stores software components 211 and software configuration information 212. The software components 211 include software source code, executable programs (executable codes), and various information required for executing the software. The software configuration information 212 includes configuration information of the software executed in the execution environment device 200.

[0033] The software execution management unit 220 executes the software based on the software components 211 .

[0034] The software configuration information generation unit 225 generates software configuration information based on the software configuration elements 211 and manages the generated software configuration information as software configuration information 212 in the storage unit 210 .

[0035] The software configuration information transmission unit 230 transmits the software configuration information 212 to the countermeasure management device 100 as needed.

[0036] 2B shows the main functions of the verification environment device 300. As shown in the figure, the verification environment device 300 has the functions of a storage unit 310, a verification instruction receiving unit 320, a software verification unit 325, and a verification result transmitting unit 330.

[0037] Of the above functions, the storage unit 310 stores a verification instruction 311, software to be verified 312, and a verification result 313.

[0038] Among these, the verification instruction 311 is the content of the verification instruction 311 received from the countermeasure management device 100. The verification target software 312 includes components of the software to be verified (source code, execution code, etc.) and various information required for executing the software. The verification result 313 includes information indicating the result of the verification performed by the software verification unit 325.

[0039] The verification instruction receiving unit 320 receives a verification instruction from the countermeasure management device 100, and manages the received verification instruction in the storage unit 310 as a verification instruction 311. The verification instruction 311 includes information specifying the software components to be verified and information specifying the vulnerabilities to be verified.

[0040] The software verification unit 325 verifies whether the vulnerability specified in the verification instruction 311 has been resolved (whether appropriate measures have been taken) for the components specified in the verification instruction 311, and manages the verification results in the memory unit 310 as verification results 313.

[0041] The verification result transmission unit 330 transmits the verification result 313 to the countermeasure management device 100 .

[0042] 2C shows the main functions of vulnerability information providing device 400. As shown in the figure, vulnerability information providing device 400 has the functions of storage unit 410, vulnerability information management unit 420, countermeasure version management unit 425, vulnerability information transmission unit 430, and countermeasure version transmission unit 435.

[0043] Of the above functions, the storage unit 410 stores vulnerability information 411 and a countermeasure version 412 .

[0044] The vulnerability information 411 is vulnerability information acquired by the vulnerability information management unit 420. The vulnerability information includes, for example, information identifying software having a vulnerability, the severity of the vulnerability, the publication date, the status of countermeasures (such as the availability status of a countermeasure version), and countermeasure methods.

[0045] The countermeasure version 412 is the countermeasure version acquired by the countermeasure version management unit 425 .

[0046] The vulnerability information management unit 420 acquires vulnerability information as needed via the communication network 5 or a user interface, and manages the acquired information as vulnerability information 411 in the storage unit 410 .

[0047] The countermeasure version management unit 425 acquires countermeasure versions as needed via the communication network 5 or a user interface, and manages the acquired countermeasure versions in the storage unit 410 as countermeasure versions 412. Note that the countermeasure versions may be included in the vulnerability information 411.

[0048] The vulnerability information transmitting unit 430 transmits the vulnerability information 411 to the countermeasure management device 100 as needed.

[0049] The countermeasure version transmitting section 435 transmits the countermeasure version 412 to the countermeasure management device 100 as needed.

[0050] 2D shows the main functions of the countermeasure management device 100. As shown in the figure, the countermeasure management device 100 has the following functions: a storage unit 110, an information acquisition management unit 120, a vulnerability detection unit 130, a requested response period information management unit 135, a countermeasure candidate management unit 140, a countermeasure plan generation unit 150, a countermeasure status update unit 155, and a countermeasure plan presentation unit 160.

[0051] As shown in the figure, the storage unit 110 stores software configuration information 111, vulnerability information 112, required response period information 113, countermeasure candidate information 114, and countermeasure proposal information 115.

[0052] The information acquisition management unit 120 receives software configuration information from the runtime environment device 200 as needed, and manages the received software configuration information in the storage unit 110 as software configuration information 111 .

[0053] Furthermore, the information acquisition and management unit 120 acquires vulnerability information from the vulnerability information providing device 400 as needed, and manages the acquired vulnerability information in the storage unit 110 as vulnerability information 112 .

[0054] Furthermore, the information acquisition and management unit 120 acquires information necessary for generating the countermeasure proposal information 115 , such as the requested response period information 113 and the countermeasure candidate information 114 , and manages the acquired information in the storage unit 110 .

[0055] The information acquisition management unit 120 can also acquire the above information in other ways, such as by acquiring it from the user via a user interface.

[0056] Furthermore, the information acquisition management unit 120 manages previously acquired software configuration information and vulnerability information (history of software configuration information and vulnerability information) in association with the respective acquisition dates and times.

[0057] Furthermore, the information acquisition management unit 120 receives the verification results 313 sent from the verification environment device 300 at any time, and stores the received verification results 313 in the countermeasure proposal information 115 .

[0058] Vulnerability detection unit 130 detects whether or not each component in software configuration information 111 has a vulnerability by comparing information about each component in software configuration information 111 (such as component identifier, provider, and version) with vulnerability information 112, and manages the detection results in countermeasure proposal information 115. Note that vulnerability detection unit 130 may perform the above-described vulnerability detection by, for example, presenting information about each component in software configuration information 111 and vulnerability information 112 via a user interface and receiving information about the presence or absence of a vulnerability in each component from the user.

[0059] The requested response period information management unit 135 manages the period required from the time a vulnerability is detected to the time a vulnerability countermeasure is completed (hereinafter referred to as the "requested response period") in the memory unit 110 as requested response period information 113, according to the severity of the vulnerability obtained from the vulnerability information 112.

[0060] The countermeasure candidate management unit 140 acquires candidate countermeasures (templates of countermeasure proposals) (hereinafter referred to as "countermeasure candidates") for vulnerabilities detected in software components, and manages information related to the acquired countermeasure candidates in the storage unit 110 as countermeasure candidate information 114. Note that the countermeasure candidate management unit 140 acquires information related to countermeasure candidates from a user via a user interface, for example.

[0061] The countermeasure candidate management unit 140 automatically generates a countermeasure implementation period, which is the period required to implement a countermeasure candidate, based on, for example, the actual number of man-hours required to implement countermeasures implemented in the past. In addition, the countermeasure candidate management unit 140 can also obtain the countermeasure implementation period from the user via, for example, a user interface.

[0062] The countermeasure proposal generating unit 150 generates countermeasure proposals for the detected vulnerabilities managed in the countermeasure proposal information 115, and manages the generated countermeasure proposals in the countermeasure proposal information 115. Details of countermeasure proposal generation will be described later.

[0063] The countermeasure status update unit 155 periodically acquires information relating to the status of countermeasures against vulnerabilities and information necessary for countermeasures (such as response methods and countermeasure versions), and updates the countermeasure proposal information 115 based on the acquired information.

[0064] The countermeasure proposal presentation unit 160 generates countermeasure proposals for vulnerabilities based on the countermeasure proposal information 115, and presents the generated countermeasure proposals to the user via a user interface.

[0065] 3A shows an example of software configuration information 111. Software configuration information 111 is updated to the latest state every time countermeasure management device 100 acquires new software configuration information. Software configuration information 111 is accompanied by update date and time 1110, which is information indicating the date and time of the most recent update of software configuration information 111.

[0066] As shown in the figure, the illustrated software configuration information 111 includes information described in one or more records (entries) each including items such as a component ID 1111, a version 1112, a provider ID 1113, a classification 1114, a storage location 1115, and a dependency relationship 1116. One record in the software configuration information 111 corresponds to one of the components of the software executed in the execution environment device 200.

[0067] Of the above items, the component ID, which is an identifier of the component, is stored in the component ID 1111. The version 1112 stores information indicating the version of the component.

[0068] The provider ID 1113 stores a provider ID that is an identifier of the provider of the component.

[0069] The classification 1114 stores information indicating the type of the software (commercial software, OSS, proprietary software, etc.).

[0070] The storage location 1115 stores information indicating the storage location (location) of the component.

[0071] Information about the dependency relationship between the software and other software is stored in the dependency relationship 1116. For example, if the software is primary, "primary" is stored, and if the software is secondary, the name of the primary software for the software is stored.

[0072] 3B shows an example of the vulnerability information 112. The vulnerability information 112 is updated to the latest information every time the countermeasure management device 100 acquires new vulnerability information. The vulnerability information 112 is accompanied by update date and time 1120, which is information indicating the most recent update date and time.

[0073] As shown in the figure, the illustrated vulnerability information 112 is made up of one or more records each including items such as a vulnerability ID 1121, a component ID 1122, a version 1123, a severity level 1124, a publication date 1125, a provider ID 1126, and a countermeasure 1127. One record of the vulnerability information 112 corresponds to one piece of vulnerability information.

[0074] Among the above items, a vulnerability identifier (hereinafter referred to as a "vulnerability ID") is stored in the vulnerability ID 1121. The vulnerability ID is, for example, a Common Vulnerabilities and Exposures IDentifier (CVE ID).

[0075] The component ID of the component of the software that is the target of the vulnerability information (hereinafter also referred to as "target software") is stored in the component ID 1122. The version 1123 stores information indicating the version of the target software.

[0076] The severity 1124 stores information indicating the severity of the vulnerability.

[0077] The publication date 1125 stores the publication date of the vulnerability information (such as the date it was posted on a web page).

[0078] The provider ID 1126 stores the provider ID of the provider of the target software.

[0079] The countermeasure 1127 stores information indicating the status of countermeasures against the vulnerability (measure method, countermeasure version, provider's countermeasure status against the vulnerability, etc.).

[0080] 3C shows an example of the required response period information 113. The required response period information 113 manages a required response period, which is set according to the severity of the vulnerability and is the period required to complete countermeasures against the vulnerability.

[0081] As shown in the figure, the requested response period information 113 includes information associating a severity level 1131 with a requested response period 1132. In this example, the greater the severity level, the shorter the requested response period 1132 is set. The severity level 1131 and the requested response period 1132 are determined by an organization such as a company or public institution, taking into consideration the possibility that the vulnerability will be exploited, the scope of the vulnerability's impact, the potential impact if the vulnerability is exploited, and the like.

[0082] 3D shows an example of the countermeasure candidate information 114. The countermeasure candidate information 114 manages candidate countermeasures for vulnerabilities (hereinafter referred to as "countermeasure candidate"), the implementation priority of the countermeasure candidate, the implementation period of the countermeasure candidate, etc. The contents of the countermeasure candidate information 114 are set, for example, by the organization that operates the vulnerability countermeasure management system 1.

[0083] As shown in the figure, the countermeasure candidate information 114 is made up of a plurality of records each consisting of the following items: countermeasure candidate 1141 , countermeasure / premise 1142 , priority 1143 , countermeasure implementation period 1144 , and prerequisite 1145 .

[0084] Of the above items, the countermeasure candidate 1141 stores information indicating the contents of the countermeasure candidate and countermeasures that are prerequisites for implementing other countermeasure candidates (hereinafter referred to as "prerequisite countermeasures").

[0085] Countermeasure / Prerequisite 1142 stores information indicating whether the candidate countermeasure is a prerequisite countermeasure or not. If it is a prerequisite countermeasure, "Prerequisite" is stored, and if it is not a prerequisite countermeasure, "Countermeasure" is stored.

[0086] Information indicating the execution priority of the proposed measure is stored in the priority 1143. In this example, the smaller the value of the priority 1143, the higher the priority.

[0087] The countermeasure implementation period 1144 stores the countermeasure implementation period (man-hours required to implement the candidate countermeasure). The countermeasure implementation period 1144 is set, for example, by the organization that operates the vulnerability countermeasure management system 1. The organization collects information widely, such as methods for dealing with vulnerabilities, workarounds, and stumbling blocks when implementing countermeasures, and sets the countermeasure implementation period 1144 based on the collected information. For example, the organization sets the countermeasure implementation period 1144 to be short if the countermeasure is effective, and sets the countermeasure implementation period 1144 to be long if there are many failures and no effective solution can be found.

[0088] In the prerequisite 1145, when a prerequisite measure needs to be implemented in advance when the candidate measure is implemented, information specifying the prerequisite measure is stored.

[0089] 3E shows an example of the countermeasure proposal information 115. The countermeasure proposal information 115 manages vulnerabilities detected by the vulnerability detection unit 130, information identifying the components that are the targets of the vulnerabilities, countermeasure proposals generated by the countermeasure information management unit 145, etc.

[0090] As shown in the figure, the countermeasure proposal information 115 consists of one or more records each having the following items: vulnerability ID 1151, severity 1152, publication date 1153, response deadline 1154, target software 1155, countermeasure 1156, estimated countermeasure period 1157, status 1158, waiting period 1159, and current countermeasure proposal 1160.

[0091] Among the above items, the vulnerability ID 1151 stores the content of the vulnerability ID 1121 in the vulnerability information 112.

[0092] The severity 1152 stores the content of the severity 1124 in the vulnerability information 112 .

[0093] The disclosure date 1153 stores the content of the disclosure date 1125 in the vulnerability information 112 .

[0094] The response deadline 1154 stores, for example, the response deadline date (response deadline), which is the date obtained by adding the value of the requested response period 1132 in the requested response period information 113 corresponding to the severity 1152 to the publication date 1153.

[0095] Information identifying the software that is the target of the vulnerability (target software) is stored in target software 1155. In this example, if the target software is secondary, the component ID of the primary component of the secondary, obtained from software configuration information 111, is stored in target software 1155. Furthermore, if the target software is primary (including cases where the target software does not have a dependency relationship with other components), information indicating that it is primary, such as "P," is stored in target software 1155.

[0096] Information about measures for the vulnerability generated by the measure information management unit 145 is stored in the measure 1156. As shown in the figure, the measure 1156 includes items of primary 1156a, verification 1156b, and secondary 1156c.

[0097] Of these, the primary 1156a stores the content of the countermeasures in the vulnerability information 112 when the target software is primary.

[0098] Furthermore, in the verification 1156b, "OK" is stored if the verification of the revised version of the target software by the verification environment device 300 is successful.

[0099] Further, in the secondary 1156c, when the target software is secondary, measures for the software are stored.

[0100] In the next countermeasure estimated period 1157, the countermeasure implementation period 1144 of the countermeasure in question in the countermeasure candidate information 114 is stored.

[0101] The status 1158 stores information indicating the current status of countermeasures for the vulnerability in question for the target software.

[0102] The waiting deadline 1159 stores the deadline obtained by subtracting the value of the estimated countermeasure period 1157 from the countermeasure deadline 1154 (the limit date beyond which countermeasures will not be completed by the countermeasure deadline if waiting any longer).

[0103] The current countermeasure plan 1160 stores information indicating the current countermeasure plan for the vulnerability.

[0104] Next, the processing performed in the vulnerability countermeasure management system 1 will be described.

[0105] 4 is a sequence diagram illustrating the process (hereinafter referred to as "information acquisition and generation process S400") in which the information acquisition management unit 120 of the countermeasure management device 100 acquires information used when executing the vulnerability countermeasure generation process S500, which will be described later. The information acquisition and generation process S400 will be described below with reference to this diagram.

[0106] First, the information acquisition management unit 120 acquires information (guidelines, etc.) regarding the requested response period from the vulnerability information providing device 400 or the user 6 via the user interface (S411-S412), and generates requested response period information 113 based on the acquired information (S413).

[0107] Next, the information acquisition management unit 120 acquires information about measures (for example, from the user 6 via the user interface) (S414), and generates measure candidate information 114 based on the acquired information (S415).

[0108] The information acquisition and management unit 120 generates requested response period information 113 and candidate countermeasure information 114 while presenting the acquired information (information on requested response period, information on countermeasure management) to the user 6 via a user interface.

[0109] 5 shows an example of a screen (hereinafter referred to as "information setting screen 500") that the information acquisition management unit 120 presents to the user 6 when generating the requested response period information 113 and the countermeasure candidate information 114. As shown in the figure, the illustrated information setting screen 500 has a setting field 510 for requested response period information and a setting field 520 for countermeasure information.

[0110] In the request response period information setting field 510, the user 6 can select whether to follow guidelines provided by an organization or to create one by the user. If a guideline is to be followed, the user can select one from among multiple guidelines if they exist.

[0111] In the countermeasure information setting field 520, the user 6 can set the contents of the countermeasure candidate information 114 shown in FIG. 3D.

[0112] 4, the information acquisition management unit 120 then receives a request from the user 6 via the user interface to modify the logic of the countermeasure generation process S615, which will be described later, and modifies the logic based on the received information. In this way, the user 6 can modify the logic of the countermeasure generation process S615 at any time as needed.

[0113] The information acquisition management unit 120 can independently execute the above-described processes of S413, S415, and S417 at any time.

[0114] 6 is a sequence diagram outlining the process (hereinafter referred to as "countermeasure management process S600") performed in the vulnerability countermeasure management system 1 when generating vulnerability countermeasure proposals. Below, the countermeasure management process S600 will be described with reference to this diagram.

[0115] The information acquisition management unit 120 of the countermeasure management device 100 acquires software configuration management information and vulnerability information as needed, and updates the software configuration information 111 and vulnerability information 112 based on the acquired information (S611).

[0116] The vulnerability detection unit 130 detects vulnerabilities based on the updated software configuration information 111 and vulnerability information 112 (S613: Yes), and stores the detected vulnerabilities in the countermeasure proposal information 115 (S614).

[0117] Next, the countermeasure plan generating unit 150 performs a process (hereinafter referred to as "countermeasure plan generating process 615") to generate countermeasure plans for the vulnerabilities stored in the countermeasure plan information 115. Details of the countermeasure plan generating process 615 will be described later.

[0118] Next, the countermeasure proposal presenting unit 160 presents the countermeasure proposal generated by the countermeasure proposal generating unit 150 to the user 6 via the user interface (S616).

[0119] The user 6 takes necessary measures for the software stored in the runtime environment device 200, referring to the proposed measures (S617).

[0120] Next, the countermeasure status update unit 155 acquires information on the current status of vulnerability countermeasures, determines the status based on the acquired information, and performs processing to update the countermeasure proposal information 115 (hereinafter referred to as "countermeasure status update processing S618"). Details of the countermeasure status update processing S618 will be described later.

[0121] Fig. 7 is a flowchart for explaining the details of the countermeasure plan generation process S615 shown in Fig. 6. Below, the countermeasure plan generation process S615 will be explained with reference to Fig. 7. Note that the process shown in Fig. 7 is performed by selecting the vulnerabilities detected in S613 (vulnerabilities managed in the countermeasure plan information 115) one by one and repeatedly performing the process for each vulnerability ID (for each target software corresponding to the selected vulnerability).

[0122] First, the countermeasure proposal generator 150 determines whether a primary countermeasure version of the software affected by the selected vulnerability has been provided by the provider or the like (S711). The countermeasure proposal generator 150 makes this determination based on, for example, vulnerability information 112 acquired from time to time or information acquired through interactive processing with the user 6 via a user interface. If a primary countermeasure version has been provided (S711: Yes), the process proceeds to S712. On the other hand, if a primary countermeasure version has not been provided (including the case where the software is not secondary) (S711: No), the process proceeds to S721.

[0123] In S712, the countermeasure proposal generation unit 150 determines whether or not there is any problem in the preliminary verification of the software in which the fixed version has been applied to the primary version of the target software of the selected vulnerability. Note that the countermeasure proposal generation unit 150 performs the above preliminary verification, for example, by using the verification environment device 300. Also, the countermeasure proposal generation unit 150 makes the above determination, for example, by interactive processing with the user via a user interface.

[0124] If there is no problem in the preliminary verification (S712: No problem), the countermeasure proposal generation unit 150 stores "Apply patch to primary" in the current countermeasure proposal 1160 of the countermeasure proposal information 115 (S713), and ends the processing for the selected vulnerability. On the other hand, if there is a problem in the preliminary verification (S712: Problem exists), the processing proceeds to S721.

[0125] In S721, the countermeasure proposal generating unit 150 determines whether a countermeasure (countermeasure method or countermeasure version) for the selected software targeting the vulnerability is provided by the provider. Note that the countermeasure proposal generating unit 150 makes this determination based on, for example, the contents of the countermeasure 1127 in the vulnerability information 112 or an interactive process with the user via a user interface.

[0126] If a countermeasure for the vulnerability has been provided (S721: Yes), the countermeasure generation unit 150 stores "Implement the countermeasure disclosed by the provider" in the current countermeasure 1160 for the selected vulnerability in the countermeasure information 115 (S722), and ends the processing for the selected vulnerability. On the other hand, if a countermeasure has not been provided (S721: No), the processing proceeds to S731.

[0127] In S731, the countermeasure proposal generator 150 refers to the target software 1155 of the countermeasure proposal information 115, and determines whether the target software of the selected vulnerability is primary or secondary. If the target software is primary (S731: primary), the process proceeds to S732. On the other hand, if the target software is secondary (S731: secondary), the process proceeds to S741.

[0128] Furthermore, even if the target software for the selected vulnerability is secondary, if the primary software for the target software is, for example, proprietary software, commercial software, or supported open source software, the target software may be set as primary and countermeasures for the target software may follow the instructions of the provider of the primary software.

[0129] In S741, the countermeasure proposal generator 150 refers to the countermeasure candidate information 114 and determines whether or not the highest priority is set to "apply patch to secondary" among the countermeasures that can be applied to the target software. If the highest priority is set to "apply patch to secondary" (S741: Yes), the process proceeds to S751. On the other hand, if the highest priority is not set to "apply patch to secondary" (S741: No), the process proceeds to S732.

[0130] In S751, the countermeasure proposal generator 150 determines whether a fixed version of the target software (secondary) is available. The countermeasure proposal generator 150 makes this determination, for example, based on the countermeasures 1127 in the vulnerability information 112 or through interactive processing with the user 6 via a user interface. If a fixed version of the target software is available (S751: available), the process proceeds to S752; if not (S751: no), the process proceeds to S732.

[0131] In S752, the countermeasure proposal generation unit 150 determines whether there are any problems in the preliminary verification of the countermeasure version of the target software. The countermeasure proposal generation unit 150 performs the above preliminary verification, for example, using the verification environment device 300. The countermeasure proposal generation unit 150 also makes the above determination, for example, through interactive processing with the user 6 via a user interface. The countermeasure proposal generation unit 150 determines that there are no problems in the preliminary verification, for example, if the above preliminary verification can be performed and the verification result shows no problems.

[0132] If there is no problem in the preliminary verification (S752: No problem), the countermeasure proposal generation unit 150 stores "Apply patch to secondary" in the current countermeasure proposal 1160 of the countermeasure proposal information 115 (S753), and ends the processing for the selected vulnerability. On the other hand, if there is a problem in the preliminary verification (S752: Problem exists), the processing proceeds to S732.

[0133] In S732, the countermeasure proposal generation unit 150 refers to the countermeasure candidate information 114 and determines which of the countermeasures applicable to the target software has a higher priority: "System Stop" or "Workaround Consideration." If "Workaround Consideration" has a higher priority (S732: Workaround Consideration), the countermeasure proposal generation unit 150 stores "Workaround Consideration" in the current countermeasure proposal 1160 of the countermeasure proposal information 115 (S733), and ends processing for the selected vulnerability. On the other hand, if "System Stop" has a higher priority (S732: System Stop), the countermeasure proposal generation unit 150 stores "System Stop" in the current countermeasure proposal 1160 of the countermeasure proposal information 115 (S734), and ends processing for the selected vulnerability.

[0134] If the proposed countermeasure is "considering a workaround," for example, the user may plan a workaround using information provided by an organization other than the provider. The workaround may also be a measure other than "providing a countermeasure version," such as preventing the vulnerability from occurring by implementing a countermeasure in another information processing system that cooperates with the vulnerability countermeasure management system 1.

[0135] It is also conceivable that the system cannot be stopped due to the circumstances of the system operating in the execution environment device 200 (such as the importance of the system or the impact on business operations), and in such cases, for example, the priority of "system shutdown" may be lowered.

[0136] Fig. 8 is a flowchart explaining the details of the countermeasure status update process S618 shown in Fig. 6. The countermeasure status update process S618 will be explained below with reference to Fig. 8. The process shown in Fig. 8 is repeatedly performed by selecting (for each vulnerability ID) each vulnerability detected in S613 (vulnerabilities managed in the countermeasure proposal information 115).

[0137] First, the countermeasure status update unit 155 determines whether or not "-patch applied" ("patch applied to primary" or "patch applied to secondary") is stored in the current countermeasure plan 1160 of the countermeasure plan information 115 (S811). If "-patch applied" is stored in the countermeasure plan 1160 (S811: Yes), the process proceeds to S812. On the other hand, if "-patch applied" is not stored in the countermeasure plan 1160 (S811: No), the process proceeds to S821.

[0138] In S812, the countermeasure status update unit 155 stores "Current countermeasure plan being implemented" in the status 1158 of the countermeasure plan information 115. Thereafter, the process proceeds to S851.

[0139] In S821, the countermeasure status update unit 155 stores “primary patch standby” in the status 1158 of the countermeasure proposal information 115.

[0140] Next, the countermeasure status update unit 155 refers to the primary 1156a of the countermeasure 1156 in the countermeasure proposal information 115, and waits for the acquisition of the primary countermeasure version (S822). When the primary countermeasure version is acquired (S822: Yes), the process proceeds to S812. The countermeasure status update unit 155 also checks whether the waiting period 1159 in the countermeasure proposal information 115 has currently expired, and if the waiting period 1159 has expired (S822: Waiting period expired), the process proceeds to S823.

[0141] In S823 , the countermeasure status update unit 155 stores “current countermeasure plan being implemented” in the status 1158 of the countermeasure plan information 115 .

[0142] Next, the countermeasure status update unit 155 waits for information that countermeasures have been implemented (S824). The countermeasure status update unit 155 acquires information that countermeasures have been implemented, for example, through interactive processing with the user 6 via a user interface. Upon acquiring information that countermeasures have been implemented (S824: Yes), the countermeasure status update unit 155 stores "provisional countermeasures taken, primary patch not yet applied" in the status 1158 of the countermeasure proposal information 115 (S825).

[0143] Thereafter, the countermeasure status update unit 155 refers to the primary 1157a of the countermeasure 1156 in the countermeasure proposal information 115, and waits for the acquisition of a primary countermeasure version (S826). If it is confirmed that the primary countermeasure version has been acquired (S826: Yes), the process proceeds to S851.

[0144] In S851, the countermeasure status update unit 155 waits for information that a countermeasure has been implemented. The countermeasure status update unit 155 acquires the information that a countermeasure has been implemented, for example, through interactive processing with the user 6 via a user interface. When the countermeasure status update unit 155 acquires the information that a countermeasure has been implemented (S851: Yes), it stores "Countermeasure Completed" in the status 1158 of the countermeasure proposal information 115 (S852), and ends the processing for the selected vulnerability.

[0145] FIG. 9 shows an example of a screen (hereinafter referred to as a "countermeasure proposal presentation screen 900") that the countermeasure proposal presentation unit 160 presents to the user 6 via the user interface in S616.

[0146] As shown in the figure, the example countermeasure proposal presentation screen 900 has a display field 910 for the total number of countermeasure days and a display field 920 for countermeasure proposals.

[0147] A display field 910 for the total number of days required for countermeasures displays an estimate of the total number of days required for countermeasures for each of the currently detected vulnerabilities.

[0148] A countermeasure display column 920 displays information (countermeasure deadline 922, recommended implementation date 923, countermeasure 924) about a currently detected vulnerability (vulnerability identified by a vulnerability ID 921).

[0149] Of these, the countermeasure deadline 922 displays the contents of the countermeasure deadline 1154 of the countermeasure proposal information 115 .

[0150] The recommended implementation date 923 stores, for example, a date or period determined by the countermeasure proposal presenting unit 160 based on at least one of the waiting period 1159, the estimated countermeasure period 1157, and the response period 1154 of the countermeasure proposal information 115. Note that the countermeasure proposal presenting unit 160 adjusts (advances, delays, etc.) the period depending on, for example, the severity (priority) of the vulnerability countermeasure, the importance of the vulnerability, the feasibility (probability) of the attack, the importance of the target software, etc. The period can also be adjusted by the user 6 via a user interface.

[0151] Countermeasure 924 stores information indicating the specific content of the countermeasure against the vulnerability.

[0152] [Technical effects, etc.] As described above, the vulnerability countermeasure management system 1 of this embodiment stores the countermeasure implementation period, which is the time required to implement each countermeasure (candidate countermeasure) against a vulnerability, detects vulnerabilities in components based on vulnerability information, and calculates the response deadline, which is the deadline for completing the countermeasure for the detected vulnerability, based on the required response period, which is the period for completing the countermeasure for the vulnerability, obtained from the vulnerability information.The vulnerability countermeasure management system 1 then generates a countermeasure plan for the vulnerability based on the countermeasure implementation period for the detected vulnerability so that the countermeasure for the vulnerability will meet the response deadline.As a result, the vulnerability countermeasure management system 1 of this embodiment can appropriately plan countermeasures for vulnerabilities while taking into account the time required to complete the countermeasure.

[0153] Furthermore, the vulnerability countermeasure management system 1 determines, based on the vulnerability information, how to deal with the detected vulnerability or whether a countermeasure version for the component that is the target of the vulnerability can be acquired to deal with the vulnerability, and generates a countermeasure plan based on the result of the determination. This allows appropriate countermeasure plans for vulnerabilities to be formulated while taking into account how to deal with the vulnerability and the availability of a countermeasure version.

[0154] The vulnerability countermeasure management system 1 also determines whether the secondary (first component) that detected the vulnerability can acquire the countermeasure version of the primary (second component) and generates a countermeasure plan based on the result of the determination. This allows appropriate countermeasures for the vulnerability of the secondary to be planned while taking into account the acquisition status of the primary.

[0155] Furthermore, if neither a response method nor a countermeasure version can be acquired, the vulnerability countermeasure management system 1 generates a countermeasure plan that instructs the user 6 to consider a workaround for the detected vulnerability. This allows the system to present the user 6 with an appropriate countermeasure plan that takes into account the acquisition status of the response method and the countermeasure version.

[0156] The vulnerability countermeasure management system 1 also stores multiple candidate countermeasures, sets priorities for adopting each of the candidate countermeasures, and generates countermeasures based on the candidate countermeasures selected according to the priorities. This allows the system to present appropriate countermeasures to the user 6 based on the preset priorities.

[0157] The vulnerability countermeasure management system 1 also obtains the results of pre-verification of the components to which the countermeasures have been applied, and generates countermeasures based on the results of the pre-verification, thereby making it possible to present appropriate countermeasures to the user 6 according to the results of the pre-verification.

[0158] Furthermore, after presenting a countermeasure plan to user 6, the vulnerability countermeasure management system 1 re-acquires vulnerability information as needed, determines based on the newly acquired vulnerability information whether a countermeasure method or countermeasure version that was not previously available has become available, and re-generates a countermeasure plan based on the determination result. Therefore, appropriate countermeasure plans can be presented to user 6 depending on the status of countermeasure methods or countermeasure versions available after the countermeasure plan is presented to user 6. Furthermore, based on the newly presented countermeasure plan, user 6 can have an opportunity to check whether any high-urgency vulnerabilities have been added, and to review the time required for countermeasures and the content of the countermeasures.

[0159] The vulnerability countermeasure management system 1 also accumulates and stores the time required to implement each countermeasure implemented in the past, and generates a countermeasure period for each countermeasure based on the time required. This allows the countermeasure implementation period to be set appropriately based on the performance of countermeasures implemented in the past.

[0160] Furthermore, the vulnerability countermeasure management system 1 sets the countermeasure period according to the severity of the vulnerability, so that it is possible to formulate appropriate countermeasure plans according to the severity of the vulnerability.

[0161] Furthermore, the vulnerability countermeasure management system 1 accepts the setting of the required response period according to the severity from the user 6 via the user interface, so that the required response period according to the severity can be flexibly set in accordance with the user 6's wishes.

[0162] Furthermore, the vulnerability countermeasure management system 1 accepts the setting of the countermeasure implementation period for each countermeasure candidate from the user 6 via a user interface, so that the countermeasure implementation period for each countermeasure candidate can be flexibly set according to the user 6's wishes.

[0163] In addition, the vulnerability countermeasure management system 1 presents the generated countermeasure proposals to the user 6 via a user interface, so that the user 6 can refer to the presented countermeasure proposals and efficiently and appropriately plan countermeasures against the detected vulnerabilities.

[0164] 10 shows an example of an information processing device (computer) used to realize the vulnerability countermeasure management system 1 described in the above embodiment. The verification environment device 300, the execution environment device 200, the vulnerability information providing device 400, and the countermeasure management device 100 are configured using, for example, one or more information processing devices 10 having the configuration shown in the figure.

[0165] The information processing device 10 includes a processor 11, a main storage device 12 (memory), an auxiliary storage device 13 (external storage device), an input device 14, an output device 15, and a communication device 16. These are communicatively connected via a bus, a communication cable, etc. Examples of the information processing device 10 include personal computers, various server devices, office computers, general-purpose machines (mainframes), smartphones, tablets, etc.

[0166] All or part of the information processing device 10 may be realized using virtual information processing resources provided using virtualization technology, process space separation technology, or the like, such as a virtual server provided by a cloud system. All or part of the functions provided by the information processing device 10 may be realized by a service provided by a cloud system via an API (Application Programming Interface), for example. All or part of the functions provided by the information processing device 10 may be realized using, for example, Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), or the like.

[0167] The processor 11 is configured using, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), an AI (Artificial Intelligence) chip, etc.

[0168] The main memory device 12 is a device used by the processor 11 when executing a program, and is, for example, a ROM (Read Only Memory), a RAM (Random Access Memory), or a non-volatile memory (NVRAM (Non Volatile RAM)). The various functions realized by each component of the vulnerability countermeasure management system 1 are realized by each processor 11 reading out programs and data stored (memorized) in the auxiliary memory device 13 into the main memory device 12 and executing them.

[0169] The auxiliary storage device 13 is a device that stores programs and data, and can be configured, for example, by various storage systems such as an SSD (Solid State Drive), a hard disk drive, an optical storage device (e.g., a CD (Compact Disc), a DVD (Digital Versatile Disc)), or an NAS (Network Attached Storage), a read / write device for non-transitory recording media such as an IC card, an SD card, or an optical recording medium, or a non-transitory storage area of ​​a cloud server. Programs and data can be read into the auxiliary storage device 13 from other information processing devices equipped with non-transitory recording media or non-transitory storage devices via a recording medium reader or a communication device 16. The programs and data stored in the auxiliary storage device 13 are read into the main storage device 12 as needed.

[0170] The input device 14 is an interface that accepts input of information from the outside, and is, for example, a keyboard, a mouse, a touch panel, a card reader, a pen-input tablet, a voice input device, or the like.

[0171] The output device 15 is an interface that outputs various information such as the progress of processing and the results of processing to the outside. The output device 15 is, for example, a display device (liquid crystal monitor, LCD (Liquid Crystal Display), graphic card, etc.) that visualizes the various information described above, a device that converts the various information described above into audio (audio output device (speaker, etc.)), or a device that converts the various information described above into text (printer, etc.). Note that, for example, the information processing device 10 may be configured to input and output information to and from other devices via the communication device 16.

[0172] The input device 14 and the output device 15 constitute a user interface that realizes interactive processing with the user 6 (receiving information, providing information, etc.).

[0173] The communication device 16 is a device that realizes communication with other devices. The communication device 16 is a wired or wireless communication interface that realizes communication with other devices via the communication network 5, and is, for example, a NIC (Network Interface Card), a wireless communication module, a USB module, or the like.

[0174] The information processing device 10 may be equipped with, for example, an operating system, a file system, a DBMS (DataBase Management System) (relational database, NoSQL, etc.), a KVS (Key-Value Store), etc.

[0175] Although the embodiments have been described above, the present invention is not limited to the above-described embodiments, and various modifications are included, and the present invention is not necessarily limited to those including all of the configurations described. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

[0176] For example, the various functions and processes provided by the vulnerability countermeasure management system 1 described above may be realized using information output by inputting a predetermined prompt into a large-scale language model (LLM). [Explanation of symbols]

[0177] 1. Vulnerability Management System 5. Communication Network 10. Information processing equipment 100 Countermeasures Management Device 110 Storage section 111 Software configuration information 112 Vulnerability information 113 Request response period information 114 Countermeasure candidate information 115 Countermeasures Information 120 Information Acquisition Management Department 130 Vulnerability Detection Unit 135 Request Response Period Information Management Department 140 Countermeasures Candidate Management Department 145 Countermeasures Information Management Department 150 Countermeasure proposal generation unit 155 Countermeasure Status Update Department 160 Countermeasures Proposal Department 200 Execution environment device 210 Storage section 211 Software Components 212 Software configuration information 220 Software Execution Management Department 225 Software configuration information generation unit 230 Software configuration information transmission unit 300 Verification environment equipment 310 Storage section 311 Verification Instructions 312 Software to be verified 313 Verification Results 320 Verification instruction receiving unit 325 Software Verification Department 330 Verification result transmission unit 400 Vulnerability information providing device 410 Storage section 411 Vulnerability information 412 Countermeasures Edition 420 Vulnerability Information Management Department 425 Countermeasures Management Department 430 Vulnerability Information Transmission Unit 435 Countermeasures Transmission Unit S400 Information acquisition and generation process 500 Information setting screen S600 Countermeasure Management Processing S615 Countermeasure plan generation process S618 Countermeasure status update process 900 Countermeasure proposal screen

Claims

1. The system is configured using one or more information processing devices having a processor and a storage device, Software configuration information, Vulnerability information, which is information about vulnerabilities of components of the software; Acquire at any time, storing a countermeasure implementation period, which is the period required to implement each candidate countermeasure for the vulnerability; Detecting vulnerabilities in the components based on the vulnerability information; determining a response deadline for completing a countermeasure for the vulnerability based on a required response period for completing a countermeasure for the vulnerability, the required period being obtained based on the vulnerability information of the detected vulnerability; generating a countermeasure plan for the vulnerability based on the countermeasure implementation period for the detected vulnerability so that the countermeasure for the vulnerability can be completed in time for the response deadline; Vulnerability management system.

2. The vulnerability countermeasure management system according to claim 1, determining whether or not it is possible to obtain a countermeasure for the detected vulnerability or a countermeasure version of the component that is the target of the vulnerability based on the vulnerability information; generating the countermeasure plan based on the result of the determination; Vulnerability management system.

3. The vulnerability countermeasure management system according to claim 2, obtaining information indicating dependencies between components of the software; determining whether or not a fixed version of a second component can be acquired when a first component, which is the component in which a vulnerability has been detected, is included in the second component, which is another component; generating the countermeasure plan based on the result of the determination; Vulnerability management system.

4. The vulnerability countermeasure management system according to claim 2, If neither the response method nor the countermeasure version can be acquired as a result of the determination, the countermeasure plan is generated, the countermeasure plan instructing the user to consider a workaround for the detected vulnerability. Vulnerability management system.

5. The vulnerability countermeasure management system according to claim 1, storing a plurality of candidate measures that are candidates for the proposed measures; Setting priorities for selecting each of the candidate measures; generating the proposed countermeasures based on the candidate countermeasures selected according to the priority; Vulnerability management system.

6. The vulnerability countermeasure management system according to claim 2, Obtaining the results of preliminary verification performed on the countermeasure version of the component; generating the countermeasure plan based on the result of the advance verification; Vulnerability management system.

7. The vulnerability countermeasure management system according to claim 2, After generating the countermeasure plan, the vulnerability information is acquired again as needed, Based on the newly acquired vulnerability information, it is determined whether the previously unavailable countermeasure or solution version has become available; regenerating the countermeasure plan based on the result of the determination; Vulnerability management system.

8. The vulnerability countermeasure management system according to claim 1, Accumulating and storing the time required to implement each of the candidate countermeasures implemented in the past; generating the countermeasure implementation period for each of the countermeasure candidates based on the period; Vulnerability management system.

9. The vulnerability countermeasure management system according to claim 1, The required response period is set according to the severity of the vulnerability. Vulnerability management system.

10. The vulnerability countermeasure management system according to claim 9, accepting a setting of the request response period according to the severity via a user interface; Vulnerability management system.

11. The vulnerability countermeasure management system according to claim 1, accepting a setting of the countermeasure implementation period for each of the countermeasure candidates via a user interface; Vulnerability management system.

12. The vulnerability countermeasure management system according to claim 1, presenting the generated countermeasures to a user via a user interface; Vulnerability management system.

13. The vulnerability countermeasure management system according to claim 12, calculating a recommended implementation period, which is a period during which implementation of the countermeasure is recommended, based on the countermeasure implementation period and the response deadline, and presenting the calculated recommended implementation period to a user via a user interface; Vulnerability management system.

14. An information processing system for managing countermeasures against software vulnerabilities, which is configured using one or more information processing devices each having a processor and a storage device, Software configuration information, Vulnerability information, which is information about vulnerabilities of components of the software; a step of acquiring the a step of storing a countermeasure implementation period, which is a period required for implementing each candidate countermeasure for the vulnerability; detecting vulnerabilities of the components based on the vulnerability information; determining a response deadline for completing a countermeasure for the vulnerability based on a required response period for completing a countermeasure for the vulnerability, the required response period being obtained based on the vulnerability information of the detected vulnerability; and generating a countermeasure plan for the vulnerability based on the countermeasure implementation period for the detected vulnerability so that the countermeasure for the vulnerability will be completed in time for the response deadline; A vulnerability management method that implements the following:

15. The vulnerability countermeasure management method according to claim 14, The information processing system, determining whether or not it is possible to obtain a countermeasure for the detected vulnerability or a countermeasure version of the component that is the target of the vulnerability based on the vulnerability information; and generating the countermeasure plan based on the result of the determination; A vulnerability management method that further implements the above.

Images