Vulnerability countermeasure management system and vulnerability countermeasure management method

Abstract

To efficiently and properly manage countermeasures against vulnerability of software, while considering software dependencies or responses to the vulnerability of constituent components.SOLUTION: A vulnerability countermeasure management system uses one or more information processing apparatuses including a processor and a storage apparatus. The system is configured to: acquire, as needed, configuration information of software applied to an execution environment of the software and vulnerability information which is information on vulnerability of constituent components of the software; detect vulnerability of the constituent components based on the vulnerability information; acquire information indicating dependencies between the constituent components of the software; determine countermeasures against the vulnerability of a first constituent component, which is one of the constituent components, in accordance with a status of measures against the vulnerability of a second constituent component, which is another constituent component dependent on the first constituent component; and generate information indicating the determined countermeasures.SELECTED DRAWING: Figure 2

Description

[Technical Field]

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

[0002] Managing software vulnerabilities is essential to ensuring the safety and security of products and services that utilize software. Regarding software vulnerability management, for example, Patent Document 1 describes a vulnerability management system configured for the purpose of quickly and accurately responding to vulnerabilities in software implemented in a variety of products. The vulnerability management system collects and stores predetermined configuration information of target products as configuration information, collects and stores predetermined vulnerability information that has been made public or discovered, extracts target products for which a vulnerability impact investigation should be conducted based on the configuration information and vulnerability information, conducts an impact investigation of vulnerabilities in software implemented in the extracted target products, generates report information indicating the results of the impact investigation, and transmits the report information to a predetermined destination at a predetermined time. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2020-21309 Summary of the Invention [Problem to be solved by the invention]

[0004] In recent years, with the increasing complexity of software supply chains and the widespread use of open source software (OSS), it has become increasingly difficult to determine the extent to which software components are affected when a vulnerability is detected.

[0005] Furthermore, when different software components have interdependencies (such as containment relationships or hierarchical structures), vulnerability management and countermeasures may be implemented for the containing (or higher-level) software (hereinafter referred to as "primary"), but vulnerability management and countermeasures may not be implemented appropriately for the contained (or lower-level) software (hereinafter referred to as "secondary").

[0006] Furthermore, while information on software vulnerabilities is updated daily, the degree of impact of each vulnerability varies from severe to minor. As a result, determining the need for and urgency of countermeasures in software operations incurs enormous costs.

[0007] Furthermore, with regard to software components provided by third parties, such as OSS, it is necessary to constantly monitor the status of countermeasures (such as version upgrades) against vulnerabilities by the provider (supplier) and quickly consider various response methods, such as waiting for the provision of software that addresses vulnerabilities (hereinafter referred to as a "countermeasure version"), or abandoning the acquisition of a countermeasure version and considering alternative software that can address vulnerabilities. This places a heavy burden on those in the software operation field to gather information and make decisions.

[0008] In Patent Document 1, a vulnerability management system allows developers to determine whether or not a vulnerability response is necessary (whether or not a response is required) using report information showing the results of an impact investigation. However, this document does not describe a mechanism for supporting the consideration of vulnerability response methods while taking into account software dependencies and the status of countermeasures against vulnerabilities that are updated from time to time.

[0009] The present invention has been made in light of the above background, and aims to provide a vulnerability countermeasure management system and vulnerability countermeasure management method that are capable of efficiently and appropriately managing countermeasures against software vulnerabilities while taking into account software dependencies and the response status of vulnerabilities in individual components. [Means for solving the problem]

[0010] One aspect of the present invention for achieving the above-mentioned object is 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, and which periodically acquires configuration information of the software applied to the software's execution environment and vulnerability information which is information regarding vulnerabilities in the components of the software, detects vulnerabilities in the components based on the vulnerability information, acquires information indicating dependencies between the components of the software, determines countermeasures against vulnerabilities in a first component which is one of the components, based on the status of countermeasures against vulnerabilities in a second component which is another component that has a dependency on the first component, and generates information indicating the determined countermeasures.

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

[0012] According to the present invention, it is possible to efficiently and appropriately manage countermeasures against software vulnerabilities while taking into consideration software dependencies and the status of responses to vulnerabilities in individual components. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a diagram illustrating a schematic configuration of a vulnerability countermeasure management system. [Figure 2] FIG. 2 is a diagram illustrating main functions of a vulnerability countermeasure management device. [Figure 3A] 10 is an example of software configuration information. [Figure 3B] 10 is an example of vulnerability information. [Figure 3C] 1 is an example of vulnerability countermeasure management information. [Figure 3D] 10 is an example of a countermeasure request message. [Figure 4A]FIG. 10 is a diagram showing types and contents of flags. [Figure 4B] FIG. 10 is a diagram showing types and contents of status. [Figure 5] FIG. 10 is a sequence diagram illustrating a vulnerability countermeasure generation process. [Figure 6] FIG. 10 is a sequence diagram illustrating a flag setting process. [Figure 7] 10 is a flowchart illustrating a status setting process. [Figure 8] 10 is a flowchart illustrating a status update process. [Figure 9] 1 is an example of an information processing device used to realize a vulnerability countermeasure management system. DETAILED DESCRIPTION OF THE INVENTION

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

[0015] In the following, various types of information may be described using expressions such as "information," "data," and "table" as examples, but the various types of information may also be expressed using data structures other than these.

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

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

[0018] 1 shows a schematic configuration of a vulnerability countermeasure management system 1, which will be described as one embodiment of the present invention. As shown in the figure, the vulnerability countermeasure management system 1 includes a developer device 3, an execution environment device 2, a vulnerability information providing device 4, and a vulnerability countermeasure management device 100.

[0019] The execution environment device 2, developer device 3, vulnerability information providing device 4, and vulnerability countermeasure management device 100 are all configured using one or more information processing devices (computers), and are connected to each other via a communication network 5 in a state where they can communicate with each other bidirectionally.

[0020] 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, and dedicated lines.

[0021] The execution environment device 2 provides an execution environment (for example, an execution environment for production work) for software (application software, operating system, device driver, etc.). The execution environment device 2 generates configuration information of software executed in the execution environment device 2 (hereinafter referred to as "software configuration information") and provides the generated software configuration information to the developer device 3 and the vulnerability countermeasure management device 100 as needed.

[0022] The software configuration information includes information about software components and licenses, and is information managed by, for example, a software bill of materials (SBOM).

[0023] The software executed in the execution environment device 2 includes a plurality of components. The software includes, for example, open system software (OSS (Open Source Software)) and proprietary system software as components.

[0024] Software components may have dependencies (inclusion relationships, hierarchical structures, etc.) with other components. In the following explanation, among the components in the dependency relationship, the containing (or higher-level) component will be referred to as the "primary" component, and the contained (or lower-level) component will be referred to as the "secondary" component.

[0025] The developer device 3 is used by a person (hereinafter also referred to as a "user") who verifies, develops, maintains, etc. the software executed in the execution environment device 2. The developer device 3 performs processing to verify, for example, software executed in the execution environment device 2 for which measures against vulnerabilities have been taken (measures have been taken).

[0026] The vulnerability information providing device 4 provides various information (hereinafter referred to as "vulnerability information") related to vulnerabilities in software executed in the execution environment device 2 to the vulnerability countermeasure management device 100 via the communication network 5. The vulnerability information providing device 4 is operated, for example, by organizations that collect, organize, and provide vulnerability information (various public organizations (government agencies, academic institutions, etc.), various companies such as software vendors, etc.). The vulnerability information includes, for example, information identifying vulnerable software, the severity of the vulnerability, the disclosure date of the vulnerability, 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 countermeasure method, and the substance of the countermeasure version.

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

[0028] The vulnerability countermeasure management device 100 acquires software configuration information from the execution environment device 2 as needed. The vulnerability countermeasure management device 100 also acquires vulnerability information from the vulnerability information providing device 4 as needed. The vulnerability countermeasure management device 100 may acquire software configuration information and vulnerability information by other methods. For example, the vulnerability countermeasure management device 100 may acquire software configuration information and vulnerability information from a user via a user interface.

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

[0030] Furthermore, the vulnerability countermeasure management device 100 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. If there is a difference between the newly acquired software configuration information or vulnerability information and the previously acquired information, the vulnerability countermeasure management device 100 redetects vulnerabilities for the latest software components using the latest vulnerability information and updates the information.

[0031] 2 shows the main functions of the vulnerability countermeasure management device 100. As shown in the figure, the vulnerability countermeasure management device 100 has the following functions: a storage unit 110, a software configuration information acquisition unit 120, a vulnerability information acquisition unit 125, a vulnerability detection unit 130, a flag setting unit 135, a status generation unit 140, and a countermeasure request transmission unit 145.

[0032] As shown in the figure, the storage unit 110 stores software configuration information 111 , vulnerability information 112 , vulnerability countermeasure management information 113 , and countermeasure request messages 114 .

[0033] The software configuration information acquisition unit 120 acquires software configuration information from the runtime environment device 2 as needed, and manages the acquired software configuration information in the storage unit 110 as software configuration information 111 .

[0034] The vulnerability information acquisition unit 125 acquires vulnerability information from the vulnerability information providing device 4, a user, or the like as needed, and manages the acquired vulnerability information in the storage unit 110 as vulnerability information 112.

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

[0036] The flag setting unit 135 checks with the user whether or not a response to the vulnerability is required for each component in which a vulnerability managed in the vulnerability countermeasure management information 113 has been detected, and manages information indicating the result of the check (whether or not a response is required) as a "response requirement flag" in the vulnerability countermeasure management information 113.

[0037] Furthermore, the flag setting unit 135 confirms with the user whether a component in which a vulnerability has been detected and which is managed in the vulnerability countermeasure management information 113 is primary or secondary (for example, obtains from the user information indicating the dependency between the components), and manages the confirmation result (information indicating the dependency) as a "secondary flag" in the vulnerability countermeasure management information 113. Note that the flag setting unit 135 may automatically obtain information indicating the dependency between the components (information indicating whether the component is primary or secondary) from the software configuration information 111, for example, by using a known software structure analysis tool.

[0038] The status generation unit 140 generates information (hereinafter referred to as "status") regarding measures to resolve vulnerabilities for components in which vulnerabilities have been detected, based on the response necessity flag and secondary flag, and manages the generated status in vulnerability countermeasure management information 113.

[0039] If the status generated for the component in which a vulnerability is detected is any one of "update required (primary)", "update required (secondary)", and "replacement required", the countermeasure request sending unit 145 obtains a message corresponding to the status from the countermeasure request message 114 and presents the obtained message to a user (for example, a person operating the developer device 3 or the execution environment device 2) via a user interface.

[0040] 3A is an example of the software configuration information 111. The software configuration information 111 is updated to the latest state every time the vulnerability countermeasure management device 100 acquires new software configuration information. The software configuration information 111 includes an update date and time 1110 that indicates the date and time of the most recent update of the software configuration information 111.

[0041] As shown in the figure, the illustrated software configuration information 111 includes information described in one or more records (entries) each including an item such as a component name 1111, a version 1112, a provider ID 1113, a part ID 1114, and a license 1115. One record in the software configuration information 111 corresponds to one software component.

[0042] Of the above items, component name 1111 stores the component name, which is the name of the component. Version 1112 stores information indicating the version of the component. Provider 1113 stores a provider ID, which is the identifier of the provider of the component. Component ID 1114 stores information on an identifier (such as a PURL) that uniquely identifies the component. License 1115 stores information indicating the license of the component (for example, an OSS license).

[0043] 3B shows an example of the vulnerability information 112. The vulnerability information 112 is updated to the latest information every time the vulnerability countermeasure management device 100 acquires new vulnerability information. The vulnerability information 112 includes an update date and time 1120 that indicates the most recent update date and time.

[0044] As shown in the figure, the illustrated vulnerability information 112 includes information related to one or more Common Vulnerabilities and Exposures Identifiers 1121. The Common Vulnerabilities and Exposures Identifiers 1121 store identifiers that identify vulnerabilities, for example, Common Vulnerabilities and Exposures Identifiers (CVE IDs).

[0045] 3C shows an example of the vulnerability countermeasure management information 113. The vulnerability countermeasure management information 113 stores information indicating the vulnerability response status, flags (response necessity flag, secondary flag), and generated status for each software component in which a vulnerability has been detected. One record in the vulnerability countermeasure management information 113 corresponds to one component.

[0046] As shown in the figure, the illustrated vulnerability countermeasure management information 113 is made up of one or more records each having the following items: component name 1131 , version 1132 , vulnerability countermeasure status 1133 , flag 1134 , and status 1135 .

[0047] The component name 1131 stores the component name, which is the name of the component.

[0048] The version 1132 stores information indicating the version of the component.

[0049] Information about vulnerabilities in the relevant version of the relevant component is stored in the vulnerability response status 1133. As shown in the figure, the vulnerability response status 1133 includes information about each item, namely, common vulnerability identifiers 1133a and countermeasure versions 1133b.

[0050] Among these, the common vulnerability identifier 1133a stores the common vulnerability identifier of the vulnerability detected in the relevant version of the relevant component.

[0051] In the countermeasure version 1133b, when a version (countermeasure version) that addresses the vulnerability exists, information indicating the version is stored.

[0052] Flag information of the component element is stored in the flag 1134. As shown in the figure, the flag 1134 includes items of a response necessary flag 1134a and a secondary flag 1134b.

[0053] Of these, the support necessity flag 1134a stores information indicating whether support is necessary for the relevant version of the relevant component.

[0054] The secondary flag 113b includes information on secondary 1134b1, primary component name and version 1134b2, and primary countermeasure version 1134b3.

[0055] Of these, the secondary 1134b1 stores information indicating whether or not the component of the relevant version of the relevant component is secondary.

[0056] The primary component name and version 1134b2 stores information indicating the primary component name and version of the secondary component when the version of the component is secondary.

[0057] In the primary countermeasure version 1134b3, if a countermeasure version for the vulnerability exists (is provided) for the primary of the secondary, that version is stored.

[0058] 4A shows examples of flags (action required flag 1134a, secondary flag 1134b). Action required flag 1134a takes the value of either "action required" or "action not required." Secondary flag 1134b contains information indicating either "secondary" or no content (not secondary).

[0059] Returning to FIG. 3C, status 1135 stores the status generated for the vulnerability in the version of the component.

[0060] An example of the status is shown in Fig. 4B. As shown in the figure, the status 1135 takes one of the following values: "Update Required," "Update Required (Secondary)," "Update Required (Primary)," "Replacement Required," "Waiting for a fixed version," "Standby," and "No Action Required."

[0061] 3D is an example of the countermeasure request message 114. As shown in the figure, the countermeasure request message 114 manages a message 1142 to be presented to the user for each status 1141.

[0062] 5 is a sequence diagram illustrating the main processing (hereinafter referred to as "vulnerability countermeasure generation processing S500") performed in the vulnerability countermeasure management system 1 when formulating countermeasures against vulnerabilities. Below, the vulnerability countermeasure generation processing S500 will be explained with reference to this diagram.

[0063] First, the runtime environment device 2 generates software configuration information and transmits the generated software configuration information to the vulnerability countermeasure management device 100 (S511).

[0064] When the vulnerability countermeasure management device 100 receives software configuration information from the execution environment device 2, it manages the received software configuration information in the storage unit 110 as software configuration information 111 (S512). Note that the vulnerability countermeasure management device 100 also manages software configuration information received in the past as history in the storage unit 110.

[0065] Next, the vulnerability countermeasure management device 100 acquires vulnerability information from the vulnerability information providing device 4, etc., and manages the acquired vulnerability information in the storage unit 110 as vulnerability information 112 (S513). Note that the vulnerability countermeasure management device 100 manages vulnerability information acquired in the past in the storage unit 110 as history.

[0066] Next, the vulnerability countermeasure management device 100 determines whether there is a difference between the software configuration information received last time and the software configuration information received this time, or whether there is a difference between the vulnerability information acquired last time and the vulnerability information acquired this time (S514). If there is no difference between the previously acquired software configuration information and the currently acquired vulnerability information (S514: No), the vulnerability countermeasure management device 100 ends the vulnerability countermeasure generation process S500.

[0067] On the other hand, if there is a difference in at least one of the software configuration information and the vulnerability information (S514: Yes), the vulnerability countermeasure management device 100 compares the information of each component listed in the software configuration information 111 with the vulnerability information to detect whether or not each component has a vulnerability, and stores the result in the vulnerability countermeasure management information 113 (S515).

[0068] Next, the vulnerability countermeasure management device 100 performs a process of setting a flag for each component in which a vulnerability has been detected (hereinafter referred to as "flag setting process S516") and a process of setting a status for each component in which a vulnerability has been detected ("status setting process S517" or "status update process S622"). Details of the status setting process S517 and the status update process S622 will be described later.

[0069] Next, the vulnerability countermeasure management device 100 selects a message corresponding to the status set (generated) in the status setting process S517 or the status update process S622 from the countermeasure request message 114 (S518), and sends the selected message to the developer device 3 (S519).

[0070] Upon receiving the above message, the developer device 3 presents the received message to the user, who then takes action to resolve the vulnerability by referring to the presented message (S520 to S521).

[0071] For example, if the status 1135 of a combination of a component and a vulnerability is "needs update," "needs update (primary)," or "needs update (secondary)," the user can, for example, upgrade the component stored in the execution environment device 2 to software that has been modified to address the vulnerability, or apply a patch to resolve the vulnerability.

[0072] Also, for example, if the status of a combination of a component and a vulnerability is "requires replacement," the user selects an alternative for the component stored in the execution environment device 2 (other software that is guaranteed to have measures against the vulnerability).

[0073] If the status 1135 is "waiting for a fix," "standby," or "no action required," the user does not currently take any action.

[0074] Fig. 6 is a sequence diagram explaining the details of the flag setting process S516 in the vulnerability countermeasure generation process S500 in Fig. 5. The process shown in Fig. 6 is repeated for each vulnerability detected in each of the components of the vulnerability countermeasure management information 113 (by sequentially selecting and repeating combinations of a component and a vulnerability detected in that component).

[0075] First, the vulnerability countermeasure management device 100 determines whether the combination of the selected configuration element and vulnerability has already been detected (previously) (S611). If it has already been detected (S611: Yes), the process proceeds to S621. If it has not already been detected (S611: No), the process proceeds to S631.

[0076] In S621, the vulnerability countermeasure management device 100 obtains the flag 1134 set for the selected combination from the vulnerability countermeasure management information 113, executes the status update process S622 to update the status, and then the flag setting process S516 for the selected combination is completed.

[0077] In this way, when the combination of the selected component and vulnerability has already been selected, the vulnerability countermeasure management device 100 carries out processing by inheriting the flag 1134 set for the selected combination. Therefore, for example, there is no need to force the user to set flags (action necessity flag, secondary flag) again (the setting work in S641 to S642 and S651 to S652 described later), thereby reducing the burden on the user.

[0078] In S631, the vulnerability countermeasure management device 100 sends a request to determine the action necessity flag for the selected combination to the developer device 3. Upon receiving the determination request (S641), the developer device 3 accepts the setting of the action necessity flag from the user via the user interface, and sends the contents of the accepted action necessity flag to the vulnerability countermeasure management device 100 (S642).

[0079] Upon receiving the content of the action necessity flag, the vulnerability countermeasure management device 100 stores the received content of the action necessity flag in the action necessity flag 1134a of the vulnerability countermeasure management information 113 of the currently selected combination (S632).

[0080] Next, the vulnerability countermeasure management device 100 determines whether the content of the action necessity flag 1134a of the selected combination is "action required" (S633). If the content of the action necessity flag 1134a is not "action required" (S633: No), the flag setting process S516 for the selected combination ends. On the other hand, if the content of the action necessity flag is "action required" (S633: Yes), the process proceeds to S635.

[0081] In S635, the vulnerability countermeasure management device 100 sends a request to determine the secondary flag for the selected combination to the developer device 3. Upon receiving the determination request (S651), the developer device 3 accepts the setting of the secondary flag from the user via the user interface and transmits the contents of the accepted secondary flag to the vulnerability countermeasure management device 100 (S652).

[0082] When the vulnerability countermeasure management device 100 receives the contents of the secondary flag, it stores the received contents of the secondary flag in the secondary flag 1134b of the vulnerability countermeasure management information 113 for the selected combination (S636), and the flag setting process S516 for the selected combination ends.

[0083] FIG. 7 is a flowchart illustrating the details of the status setting process S517 in the vulnerability countermeasure generation process S500 in FIG.

[0084] First, the vulnerability countermeasure management device 100 determines whether the content of the action necessity flag 1134a in the vulnerability countermeasure management information 113 for the currently selected combination is "action required" (S711). If the content of the action necessity flag 1134a is not "action required" (S711: No), "action not required" is stored in the status 1135 of the vulnerability countermeasure management information 113 for the currently selected combination (S731). Thereafter, the status setting process S517 for the currently selected combination ends.

[0085] On the other hand, if the content of the action necessity flag 1134a is "action necessary" (S711: Yes), the process proceeds to S712. In S712, the vulnerability countermeasure management device 100 determines whether "secondary" is stored in the secondary flag 1134b of the vulnerability countermeasure management information 113 for the selected combination. If "secondary" is not stored in the secondary flag 1134b (S712: No), the process proceeds to S741. If "secondary" is stored in the secondary flag 1134b (S712: Yes), the process proceeds to S713.

[0086] In S741, the vulnerability countermeasure management device 100 determines whether or not a countermeasure version for the components in the selected combination has been published on, for example, the website of the vendor that provides the components (whether or not a countermeasure version is available). Note that this determination is made by the user via, for example, a user interface.

[0087] If a countermeasure version for the components of the selected combination has been made public (S741: Yes), the vulnerability countermeasure management device 100 stores "Update Required" in the status 1135 of the vulnerability countermeasure management information 113 (S742), and the status setting process S517 for the selected combination ends.

[0088] On the other hand, if a countermeasure version has not been released (S741: No), the vulnerability countermeasure management device 100 determines whether a countermeasure version is expected to be released in the future for the components of the selected combination (S743). This determination is made, for example, by the user via the user interface of the developer device 3. If a countermeasure version is expected to be released (S743: Yes), the vulnerability countermeasure management device 100 stores "Waiting for countermeasure version" in the status 1135 of the vulnerability countermeasure management information 113 (S744), and the status setting process S517 for the selected combination ends.

[0089] Thereafter, the status setting process S517 ends, and the process proceeds to S518 in Fig. 5. If there is no prospect of a fixed version being released (S743: No), the vulnerability countermeasure management device 100 stores "replacement required" in the status 1135 of the vulnerability countermeasure management information 113 for the selected combination (S745), and the status setting process S517 for the selected combination ends.

[0090] In S713, the vulnerability countermeasure management device 100 determines whether or not a countermeasure for the vulnerability of the currently selected combination has been determined for the primary of the constituent elements of the currently selected combination (whether or not the status 1135 has been set for the primary of the constituent elements of the currently selected combination). If a countermeasure has not been determined (S713: No), the vulnerability countermeasure management device 100 stores "Waiting" in the status 1135 of the vulnerability countermeasure management information 113 for the currently selected combination (S717), and the status setting process S517 for the currently selected combination ends.

[0091] On the other hand, if a countermeasure has been decided (S713: Yes), the vulnerability countermeasure management device 100 determines whether the primary of the constituent elements of the selected combination needs to be updated in order to take a countermeasure against the vulnerability in the constituent elements of the selected combination (S714). This determination is made, for example, by the user via the user interface of the developer device 3. If it is determined that an update is not necessary for the primary (S714: No), the process proceeds to S751. If it is determined that an update is necessary for the primary (S714: Yes), the process proceeds to S715.

[0092] In S751, the vulnerability countermeasure management device 100 determines whether a countermeasure version for the component (secondary) of the selected combination has been made public. If a countermeasure version has been made public (S751: Yes), the vulnerability countermeasure management device 100 stores "Update Required (Secondary)" in the status 1135 of the vulnerability countermeasure management information 113 (S752), and the status setting process S517 for the selected combination ends.

[0093] On the other hand, if a countermeasure version for the component (secondary) of the selected combination has not been made public (S751: No), the vulnerability countermeasure management device 100 stores "standby" in the status 1135 of the vulnerability countermeasure management information 113 (S717), and the status setting process S517 for the selected combination ends.

[0094] In S715, the vulnerability countermeasure management device 100 determines whether a countermeasure version for the primary component (secondary) of the currently selected combination has been made public. If a countermeasure version for the primary component has been made public (S715: Yes), the vulnerability countermeasure management device 100 stores "Update Required (Primary)" in the status 1135 of the vulnerability countermeasure management information 113 for the currently selected combination (S716).

[0095] On the other hand, if the primary countermeasure version has not been made public (S715: No), the vulnerability countermeasure management device 100 stores "standby" in the status 1135 of the vulnerability countermeasure management information 113 for the selected combination (S717), and the status setting process S517 for the selected combination ends.

[0096] FIG. 8 is a flowchart illustrating the details of the status update process S622 in the flag setting process S516 in FIG.

[0097] First, the vulnerability countermeasure management device 100 determines whether the content of the status 1135 in the vulnerability countermeasure management information 113 for the combination of the selected component and vulnerability is "standby" (S811). If the content of the status 1135 is not "standby" (S811: No), the process proceeds to S831. If the content of the status 1135 is "standby" (S811: Yes), the process proceeds to S812.

[0098] In S831, the vulnerability countermeasure management device 100 determines whether the content of the status 1135 of the vulnerability countermeasure management information 113 for the selected combination is "waiting for countermeasure version." If the content of the status 1135 of the vulnerability countermeasure management information 113 for the combination is not "waiting for countermeasure version" (S831: No), the vulnerability countermeasure management device 100 leaves the content of the status 1135 as it is (inherits the current content) (S832), and the status update process S622 for the selected combination ends.

[0099] On the other hand, if the content of the status 1135 of the vulnerability countermeasure management information 113 for the selected combination is "Waiting for a countermeasure version" (S831: Yes), the vulnerability countermeasure management device 100 determines whether a countermeasure version has been made public (S833). If a countermeasure version has been made public (S833: Yes), the vulnerability countermeasure management device 100 stores "Update required" in the status 1135 of the vulnerability countermeasure management information 113 for the selected combination, and the status update process S622 for the selected combination ends.

[0100] On the other hand, if a countermeasure version has not been released (S833: No), the vulnerability countermeasure management device 100 determines whether or not a countermeasure version is likely to be released (S835). This determination is made, for example, by the user via the user interface of the developer device 3. If a countermeasure version is likely to be released (S835: Yes), the vulnerability countermeasure management device 100 stores "Waiting for countermeasure version" in the status 1135 of the vulnerability countermeasure management information 113 for the selected combination (S836), and the status update process S622 for the selected combination ends.

[0101] Also, if there is no prospect of a countermeasure version being released (S835: No), the vulnerability countermeasure management device 100 stores "replacement required" in the status 1135 of the vulnerability countermeasure management information 113 for the selected combination (S837), and the status update process S622 for the selected combination ends.

[0102] In S812, the vulnerability countermeasure management device 100 determines whether a countermeasure has been decided for the primary of the selected configuration element. If a countermeasure has not been decided for the primary (S812: No), the vulnerability countermeasure management device 100 stores "Waiting" in the status 1135 of the vulnerability countermeasure management information 113 of the configuration element (S851), and the status update process S622 for the selected combination ends.

[0103] On the other hand, if a countermeasure has been decided for the primary (S812: Yes), the vulnerability countermeasure management device 100 determines whether or not the primary needs to be updated (S813). If the primary needs to be updated (S813: Yes), the process proceeds to S814. If the primary does not need to be updated (S813: No), the process proceeds to S841.

[0104] In S841, the vulnerability countermeasure management device 100 determines whether a countermeasure version for the selected component (secondary) has been made public. This determination is made, for example, by the user via the user interface of the developer device 3. If a countermeasure version for the selected component (secondary) has not been made public (S841: No), the vulnerability countermeasure management device 100 stores "Waiting" in the status of the vulnerability countermeasure management information 113 for that component (S851), and the status update process S622 for the selected combination ends.

[0105] Furthermore, if a countermeasure version for the selected component (secondary) has been made public (S841: Yes), the vulnerability countermeasure management device 100 stores "Update Required (Secondary)" in the status 1135 of the vulnerability countermeasure management information 113 for that component (S842), and the status update process S622 for the selected combination ends.

[0106] In S814, the vulnerability countermeasure management device 100 determines whether a countermeasure version of the primary for the selected component (secondary) has been made public. This determination is made, for example, by the user via the user interface of the developer device 3. If a countermeasure version of the primary has been made public (S814: Yes), the vulnerability countermeasure management device 100 stores "Update Required (Primary)" in the status 1135 of the vulnerability countermeasure management information 113 for that component (S815), and the status update process S622 for the selected combination ends.

[0107] On the other hand, if the primary countermeasure version has not been made public (S814: No), the vulnerability countermeasure management device 100 stores "standby" in the status 1135 of the vulnerability countermeasure management information 113 for the component in question (S851), and the status update process S622 for the selected combination ends.

[0108] [Technical effects, etc.] As described above, the vulnerability countermeasure management system 1 of this embodiment acquires the software configuration information 111 and the vulnerability information 112 as needed, and detects vulnerabilities in the components currently applied (deployed) in the runtime environment device 2 based on the vulnerability information 112. The vulnerability countermeasure management system 1 then determines a countermeasure for a vulnerability in a secondary (first component) depending on the status of the countermeasure for the vulnerability in a primary (second component). In this way, the vulnerability countermeasure management system 1 of this embodiment determines a countermeasure for a vulnerability in a secondary component depending on the status of the countermeasure for the primary component that is in a dependent relationship with the secondary component, and therefore can efficiently and appropriately determine a countermeasure for a vulnerability in a secondary component.

[0109] For example, if a countermeasure for a vulnerability in the primary has not been determined, the vulnerability countermeasure management system 1 determines to wait until a countermeasure for the primary has been determined as a countermeasure for a vulnerability in the secondary. Therefore, for example, if a countermeasure for the secondary needs to be determined after a countermeasure for the primary has been confirmed, the countermeasure for the secondary can be determined appropriately.

[0110] Furthermore, for example, when a countermeasure against a vulnerability has been decided for the primary, the vulnerability countermeasure management system 1 obtains information indicating whether the primary needs to be updated to a countermeasure version, and if the above information indicates that an update is necessary, if a countermeasure version for the primary is available, it decides to update the primary to the countermeasure version as a secondary countermeasure, and if a countermeasure version for the primary is not available, it decides to wait for the provision of the countermeasure version as a secondary countermeasure.

[0111] Furthermore, for example, if the above information does not need to be updated, the vulnerability countermeasure management system 1 determines the countermeasure for the vulnerability depending on whether a secondary version with fixed versions is available.

[0112] For example, if a secondary countermeasure version is available, the vulnerability countermeasure management system 1 decides to update the secondary to the countermeasure version as a secondary countermeasure, and if a secondary countermeasure version is not available, it decides to wait for the provision of the countermeasure version as a secondary countermeasure.

[0113] For example, the vulnerability countermeasure management system 1 acquires information indicating whether or not a countermeasure version that addresses the vulnerability of a component is available or its availability, and if the component does not have a dependency relationship with other components, determines countermeasures against the vulnerability depending on whether or not a countermeasure version is available or its availability.

[0114] For example, if a secondary countermeasure version is available, the vulnerability countermeasure management system 1 decides to update the secondary to the countermeasure version as a secondary countermeasure, and if a secondary countermeasure version is not available, it decides to consider replacing the secondary with other software as a secondary countermeasure.

[0115] For example, the vulnerability countermeasure management system 1 repeatedly acquires software configuration information 111 and vulnerability information 112 at predetermined times, acquires information indicating the availability or feasibility of countermeasure versions that address vulnerabilities in components, updates information indicating dependencies between components based on the newly acquired configuration information, detects vulnerabilities in the most recently acquired components based on the most recently acquired vulnerability information, acquires information indicating updated dependencies between different components from the software configuration information 111, determines countermeasures for secondary vulnerabilities based on the status of countermeasures for primary vulnerabilities, generates information indicating the determined countermeasures, and manages information indicating countermeasures for vulnerabilities detected in the components.

[0116] Furthermore, for example, if the information indicating a countermeasure for a vulnerability detected in a component does not indicate a waiting list for a countermeasure version that has been implemented to address the vulnerability in the component, the vulnerability countermeasure management system 1 inherits the information (flag and status) already set for the vulnerability in the component. In this way, the vulnerability countermeasure management system 1 determines a countermeasure (updates the status) using the information already set for the flag and status previously determined by the user, thereby reducing the user's duplicated work of setting flags and statuses for the same combination of component and vulnerability and improving the efficiency of the user's vulnerability management work.

[0117] Furthermore, for example, the vulnerability countermeasure management system 1 classifies the type and status of vulnerability using flag 1134 and status 1135, and determines appropriate countermeasures accordingly, thereby enabling centralized management of countermeasures against vulnerabilities while taking into consideration the individual status of software (packages), including dependencies between components.

[0118] In this way, the vulnerability countermeasure management system 1 of this embodiment can efficiently and appropriately manage countermeasures against software vulnerabilities while taking into consideration software dependencies and the response status of vulnerabilities in individual components.

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

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

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

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

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

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

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

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

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

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

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

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

[0131] 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]

[0132] 1. Vulnerability Management System 2. Execution environment device 3 Developer Equipment 4 Vulnerability information providing device 5. Communication Network 10. Information processing equipment 100 Vulnerability Management Device 110 Storage section 111 Software configuration information 112 Vulnerability information 113 Vulnerability Countermeasure Management Information 114 Action Request Message 120 Software configuration information acquisition unit 125 Vulnerability Information Acquisition Department 130 Vulnerability Detection Unit 135 Flag setting section 140 Status Generation Unit 145 Countermeasure Request Transmission Unit S500 Vulnerability countermeasure generation process S516 Flag setting process S517 Status setting process S622 Status update process

Claims

1. It is an information processing system that manages countermeasures against software vulnerabilities. The system is configured using one or more information processing devices having a processor and a storage device, Software configuration information applied to the software's execution environment; Vulnerability information, which is information about vulnerabilities of components of the software; Acquire at any time, Detecting vulnerabilities in the components based on the vulnerability information; obtaining information indicating dependencies between components of the software; determining a countermeasure against a vulnerability of a first component, which is one of the components, in accordance with the status of a countermeasure against the vulnerability of a second component, which is another component having a dependency relationship with the first component; generating information indicating the determined countermeasure; Vulnerability management system.

2. The vulnerability countermeasure management system according to claim 1, When a countermeasure against the vulnerability for the second component has not been determined, the countermeasure for the first component is determined to wait until a countermeasure against the vulnerability for the second component is determined. Vulnerability management system.

3. The vulnerability countermeasure management system according to claim 1, When a countermeasure against the vulnerability has been decided for the second component, information indicating whether or not an update is required to counter the vulnerability for the second component is acquired; If the information needs updating, If software for addressing the vulnerability of the second component is available, it is determined to update the second component with the software as the measure for the first component. if the software for addressing the vulnerability for the second component is not available, determining to wait for the provision of software for addressing the vulnerability for the first component as the measure for the first component; Vulnerability management system.

4. The vulnerability countermeasure management system according to claim 3, If the information indicating whether or not an update is required to address the vulnerability of the second component does not require an update, determining a countermeasure for the vulnerability of the first component depending on availability of software for countering the vulnerability of the first component; Vulnerability management system.

5. The vulnerability countermeasure management system according to claim 4, If software for addressing the vulnerability of the first component is available, determining to update the first component with the software as the address for the first component; if software for addressing the vulnerability of the first component is not available, determining to wait for the provision of the software as the address for the first component; Vulnerability management system.

6. The vulnerability countermeasure management system according to claim 1, obtaining information indicating the availability or unavailability of software for addressing the vulnerability of the component; determining the countermeasure for the first component depending on the availability or the availability of the software when the component does not have a dependency relationship with another component; Vulnerability management system.

7. The vulnerability countermeasure management system according to claim 6, If software for addressing the vulnerability of the first component is available, determining to update the first component with the software as the address for the first component; If software for addressing the vulnerability of the first component is not available, determining to consider replacing the first component with other software as the measure for the first component. Vulnerability management system.

8. The vulnerability countermeasure management system according to claim 1, storing information indicating vulnerabilities of the components that have been detected in the past and information indicating the dependencies of the components; If the vulnerability of the component detected based on the latest acquired vulnerability information has already been found, a countermeasure against the vulnerability of the first component is determined based on a dependency relationship between the first component and the second component that has been detected in the past. Vulnerability management system.

9. The vulnerability countermeasure management system according to claim 1, storing a message to notify the user for each of the measures; notifying a user of the message corresponding to the determined measure via a user interface; Vulnerability management system.

10. A vulnerability countermeasure management method, comprising: one or more information processing devices each having a processor and a memory device, Software configuration information applied to the software's execution environment; Vulnerability information, which is information about vulnerabilities of components of the software; a step of acquiring the detecting vulnerabilities of the components based on the vulnerability information; obtaining information indicating dependencies between components of the software; determining a countermeasure against a vulnerability of a first component, which is one of the components, depending on the status of a countermeasure against the vulnerability of a second component, which is another component having a dependency relationship with the first component; and generating information indicating the determined countermeasure; A vulnerability management method that implements the following:

11. The vulnerability countermeasure management method according to claim 10, The information processing device, a step of deciding to wait until a countermeasure for the vulnerability of the second component is determined, as a countermeasure for the first component, when the countermeasure for the vulnerability of the second component has not been determined; A vulnerability management method that further implements the above.

12. The vulnerability countermeasure management method according to claim 10, The information processing device, acquiring information indicating whether or not an update is required to address the vulnerability of the second component when the countermeasure against the vulnerability has been determined for the second component; If the information needs updating, If software for addressing the vulnerability of the second component is available, it is determined to update the second component with the software as the measure for the first component. If the software for addressing the vulnerability of the second component is not available, determining to wait for the provision of software for addressing the vulnerability of the first component as the solution for the first component; A vulnerability management method that further implements the above.

13. The vulnerability countermeasure management method according to claim 12, The information processing device, When the information indicating whether or not an update is required to address the vulnerability of the second component is not required, determining a countermeasure for the vulnerability of the first component depending on availability of software for countering the vulnerability of the first component; A vulnerability management method that further implements the above.

14. The vulnerability countermeasure management method according to claim 13, The information processing device, If software for addressing the vulnerability of the first component is available, determining that the first component is updated with the software as the address for the first component; and If software for addressing the vulnerability for the first component is not available, determining to wait for the provision of the software as the address for the first component; A vulnerability management method that further implements the above.

15. The vulnerability countermeasure management method according to claim 10, The information processing device, obtaining information indicating the availability or availability of software for addressing the vulnerability of the component; and determining the countermeasure for the first component depending on the availability or the availability of the software if the component has no dependencies with other components; A vulnerability management method that further implements the above.

Images