JP7470856B1 - Information processing device and information processing method - Google Patents

Abstract

[Problem] To provide an information processing device and information processing method that enable vulnerability information to be appropriately identified from a vulnerability database. [Solution] The information processing device includes a storage unit that stores dictionary information that associates a specific name of software with a reference name that indicates the same software as the software having the specific name, an acquisition unit that acquires a reference name of target software, and a control unit that refers to the dictionary information to identify a specific name of the target software that corresponds to the reference name of the target software and to identify a first identifier of the target software that corresponds to the identified specific name of the target software, the storage unit stores a vulnerability database that associates the first identifier of the software with vulnerability information and stores it, and the control unit identifies vulnerability information of the target software from the vulnerability database using the first identifier of the target software as a search key. [Selected Figure] Figure 2

Description

The present invention relates to an information processing device and an information processing method.

Technology has been proposed to identify information related to software vulnerabilities (for example, Patent Document 1).

JP 2007-58514 A

However, in cases where there are variations in the way software names are written, it can be difficult to identify information about vulnerabilities or other information about the software.

The present invention has been made to solve the above-mentioned problems, and aims to provide an information processing device and information processing method that enable appropriate identification of information related to vulnerabilities and information related to software.

The disclosed embodiment is an information processing device that includes a storage unit that stores dictionary information that associates a specific name of software with a reference name that indicates the same software as the software having the specific name, an acquisition unit that acquires a reference name of target software, and a control unit that refers to the dictionary information to identify a specific name of the target software that corresponds to the reference name of the target software and to identify a first identifier of the target software that corresponds to the identified specific name of the target software, where the storage unit stores a vulnerability database that associates the first identifier of the software with vulnerability information and where the control unit uses the first identifier of the target software as a search key to identify vulnerability information of the target software from the vulnerability database.

The disclosed aspect is an information processing method comprising: step A of storing dictionary information that associates a specific name of software with a reference name that indicates the same software as the software having the specific name; step B of acquiring a reference name of target software; step C of referring to the dictionary information to identify a specific name of the target software that corresponds to the reference name of the target software and to identify a first identifier of the target software that corresponds to the identified specific name of the target software; step D of storing a vulnerability database that stores the first identifier of the software in association with vulnerability information; and step E of identifying vulnerability information of the target software from the vulnerability database using the first identifier of the target software as a search key.

The present invention provides an information processing device and an information processing method that enable vulnerability information to be appropriately identified.

FIG. 1 is a diagram showing an information processing system 100 according to an embodiment. FIG. 2 is a diagram showing an information processing device 10 according to the embodiment. FIG. 3 is a diagram illustrating an example of software information according to the embodiment. FIG. 4 is a diagram illustrating an example of dictionary information according to the embodiment. FIG. 5 is a diagram illustrating an example of vulnerability information according to the embodiment. FIG. 6 is a diagram illustrating an example of information stored in the vulnerability DB according to the embodiment. FIG. 7 is a diagram illustrating an example of information stored in the vulnerability DB according to the embodiment. FIG. 8 is a diagram for explaining triage according to the embodiment. FIG. 9 is a diagram showing an information processing method according to the embodiment. FIG. 10 is an example of information stored in the master DB according to the first modification.

The following describes the embodiments with reference to the drawings. In the following description of the drawings, the same or similar parts are denoted by the same or similar reference numerals.

However, it should be noted that the drawings are schematic and the ratios of the dimensions may differ from the actual ones. Therefore, the specific dimensions should be determined with reference to the explanation below. Of course, the drawings may also contain parts with different dimensional relationships or ratios.

[Disclosure Summary]
An information processing device according to the disclosed summary includes a storage unit that stores dictionary information that corresponds a specific name of software with a reference name that indicates the same software as the software having the specific name, an acquisition unit that acquires a reference name of target software, and a control unit that refers to the dictionary information to identify a specific name of the target software that corresponds to the reference name of the target software and identifies a first identifier of the target software that corresponds to the identified specific name of the target software, wherein the storage unit stores a vulnerability database that corresponds to the first identifier of the software and vulnerability information, and the control unit uses the first identifier of the target software as a search key to identify the vulnerability information of the target software from the vulnerability database.

The information processing method according to the disclosed overview includes a step A of storing dictionary information that associates a specific name of software with a reference name that indicates the same software as the software having the specific name, a step B of acquiring a reference name of the target software, a step C of referring to the dictionary information to identify a specific name of the target software that corresponds to the reference name of the target software and to identify a first identifier of the target software that corresponds to the identified specific name of the target software, a step D of storing a vulnerability database that stores the first identifier of the software in association with vulnerability information, and a step E of identifying vulnerability information of the target software from the vulnerability database using the first identifier of the target software as a search key.

In the summary of the disclosure, the information processing device refers to dictionary information to identify a specific name of the target software that corresponds to the reference name of the target software, identifies a first identifier of the target software that corresponds to the identified specific name of the target software, and identifies vulnerability information of the target software from a vulnerability database using the first identifier of the target software as a search key. With this configuration, even in cases where there are variations in the spelling of software names, etc., it is possible to appropriately identify vulnerability information of the target software by referring to dictionary information to identify the first identifier of the target software from the reference name of the target software.

[Embodiment]
(Information Processing System)
An information processing system according to an embodiment will be described below. Fig. 1 is a diagram showing an information processing system 100 according to an embodiment.

As shown in FIG. 1, the information processing system 100 has an information processing device 10, a terminal 20, a system server 30, and a vulnerability server 40. The information processing device 10, the terminal 20, the system server 30, and the vulnerability server 40 are connected by a network. Although not particularly limited, the network 200 may be configured by the Internet. The network 200 may include a local area network, a mobile communication network, or a VPN (Virtual Private Network).

The information processing device 10 is a device that identifies vulnerability information of software. The software may be software that runs on the system server 30. Hereinafter, software for which vulnerability information is identified may be referred to as target software. Details of the information processing device 10 will be described later.

The terminal 20 is a terminal used by an administrator who manages software vulnerabilities. The terminal 20 may be a personal computer, a smartphone, or a tablet terminal. The terminal 20 may have a display unit 21. The display unit 21 may be configured with a display such as a liquid crystal panel, an organic EL (Electroluminescence) panel, or an LED (Light Emitting Diode).

The system server 30 is a server on which a system including various types of software is built and provided. The software running on the system server 30 may include OSS (Open Source Software).

Software running on the system server 30 may be managed by a list of components that make up the software. The list of components (software parts) that make up the software may be referred to as a Software Bill of Materials (SBOM). The components included in the SBOM may be read as software.

The software running on the system server 30 may include software managed by a package management tool (package manager). The package management tool is a tool that manages components and other parts used in software development as packages, and has functions such as distributing software packages, providing means for installation, uninstallation, and version upgrades, and managing dependencies between packages. The package management tool may be a tool provided by a third party other than the user of the software.

The vulnerability server 40 is an external server that manages software vulnerability information. The vulnerability server 40 may be composed of one or more servers. The one or more vulnerability servers 40 may include a server connected to one or more websites selected from external vulnerability information websites (databases) such as NVD (National Vulnerability Database), ICAT (IPA Cyber security Alert Service) Metabase, JVN (Japan Vulnerability Notes), JVN iPedia, and OSVDB (Open Source Vulnerability Database). The one or more vulnerability servers 40 may include a server that stores vulnerability information provided independently by software suppliers (e.g., security advisories).

(Information processing device)
The information processing device 10 according to the embodiment will be described below. Fig. 2 is a diagram showing the information processing device 10 according to the embodiment.

As shown in FIG. 2, the information processing device 10 has a transmitting unit 11, a receiving unit 12, a storage unit 13, and a control unit 14.

The transmitter 11 may be configured by a communication module. The communication module may be a wireless communication module conforming to a standard such as IEEE802.11a/b/g/n/ac/ax, LTE, 5G, or 6G, or may be a wired communication module conforming to a standard such as IEEE802.3.

For example, the transmission unit 11 transmits display data that displays the processing results of the information processing device 10 to the terminal 20. The transmission unit 11 may also transmit data to the system server 30 and the vulnerability server 40.

The receiver 12 may be configured by a communication module. The communication module may be a wireless communication module conforming to a standard such as IEEE802.11a/b/g/n/ac/ax, LTE, 5G, or 6G, or may be a wired communication module conforming to a standard such as IEEE802.3.

First, the receiving unit 12 may receive information (hereinafter, software information) related to software (target software) running on the system server 30 from the system server 30. The software information may be an SBOM, or may be information about the target software managed by a package management tool. The software information may include version information of the target software. The receiving unit 12 may automatically identify components (software parts) included in the software by scanning the software running on the system server 30 using a software analysis tool or the like, and create an SBOM.

SBOM stands for software bill of materials, and is a list of components (software parts) including OSS (Open Source Software) used within the software. As shown in Figure 3, it includes information showing the dependencies of each component (AAAA ver.xxx, BBBB ver.xxx, CCCC ver.xxx, DDDD ver.xxx). Specifically, SBOM is information that associates component names, supplier names, versions, authors, hashes, dependencies, etc. Also, SBOM may be output or displayed in formats such as json or xml.

The component name is the name of the component. The component is an example of the target software. The supplier name is the name of the provider of the component. The version is information that uniquely identifies the version of the component. The version is an example of version information of the target software. The author is the name of the author of the SBOM for the component. The hash is the hash value of the component. The dependencies are information that indicate the dependencies of the components.

Additionally, the SBOM may include a timestamp indicating the date and time the SBOM was created. The SBOM may also be obtained by importing a file created outside the information processing device 10, such as in another system, into the information processing device 10.

For example, the information on the target software managed by the package management tool may include a second identifier of the target software managed by the package management tool. The second identifier is an identifier that uniquely identifies the software managed by the package management tool. The second identifier may be a package universal resource locator (purl). A purl may be called a Package URL, which is a unified rule for notating the package name and version information of the package management tool, and is an identifier that uniquely identifies the software managed by the package management tool. The information on the target software managed by the package management tool may include the version information of the target software along with the second identifier of the target software. Here, the second identifier may include a portion indicating the package name and a portion indicating the version information.

Second, the receiving unit 12 receives vulnerability information from the vulnerability server 40. The vulnerability information received from the vulnerability server 40 may include a vulnerability identifier that uniquely identifies a software vulnerability, software affected by the vulnerability, whether or not attack code (PoC; Proof of Concept code) for the software vulnerability is in circulation, score information indicating the level of the software vulnerability, and the like.

For example, if the vulnerability server 40 is a server related to the NVD, as shown in FIG. 4, the vulnerability information may include a vulnerability identifier (CVE-2021-xxxx), an overview, score information, response methods, and affected software.

The summary may include a description of the vulnerability. For example, the description may include the events that result from the vulnerability.

The score information may be information indicating the level of software vulnerability (hereinafter, "score value"). For example, the score information may be a score value (e.g., Base Score) defined by the Common Vulnerability Scoring System (CVSS).

The response method may include information indicating how to respond to the vulnerability (e.g., an update, etc.) and a website URL that describes the response method.

The affected software may include information indicating the software affected by the vulnerability, and the software may be identified by an identifier such as the Common Platform Enumeration (CPE) described below. The software affected by the vulnerability may be software included in the SBOM, or may be software managed by a package management tool.

The affected software may include version information of the software affected by the vulnerability. The version information may be information that directly indicates a single version, or may be information that indicates a range of versions. Note that, if the software is identified by a CPE, the version information may be one of the pieces of information included in the CPE.

In the embodiment, the receiving unit 12 constitutes an acquisition unit that acquires a reference name of the target software. Acquire may be interpreted interchangeably with receive. The reference name means the name of the target software received by the receiving unit 12, and may be a name that may include spelling variations depending on the creator of the SBOM.

The storage unit 13 is composed of storage media such as a solid state drive (SSD) or a hard disk drive (HDD), and stores various information.

First, the storage unit 13 stores dictionary information that associates a specific name of software with a reference name that indicates the same software as the software having the specific name. The specific name means the name of the software used in the information processing device 10, and may be a name that uniquely identifies the software. The specific name may be composed of the name of the software supplier and the name of the asset.

Furthermore, the dictionary information may include information that associates a specific name of software with a first identifier of the software having the specific name. The first identifier may be an identifier that uniquely identifies the software. The first identifier may be an identifier that can be associated with vulnerability information stored in the vulnerability server 40. The first identifier may be an identifier that can be associated with a vulnerability identifier (e.g., CVE) stored in the vulnerability server 40. For example, the first identifier may be a Common Platform Enumeration (CPE). CPE is a unified rule regarding the notation of software names and version information, and is an identifier of software that includes information such as a supplier name, a product name, and version information. The first identifier may include a software name and version information. The first identifier may also include a supplier name, information about updates, information about an edition (free version, standard version, etc.), information about a language, etc.

Specifically, the storage unit 13 may store the dictionary information shown in FIG. 5. As shown in FIG. 5, the dictionary information may be information that associates a specific name, a supplier name, a reference name, and a first identifier. As described above, the reference name may be a name that may include spelling variations depending on the creator of the SBOM.

In an embodiment, the storage unit 13 constitutes a storage unit that stores dictionary information that associates a specific name of software with a reference name that indicates the same software as the software having the specific name.

Secondly, the storage unit 13 stores a vulnerability database (hereinafter, vulnerability DB). The vulnerability DB may store information based on the vulnerability information received from the vulnerability server 40. The vulnerability DB may store information obtained by extracting various information from the vulnerability information received from the vulnerability server 40. In addition, the vulnerability DB may store information obtained by the user from other websites such as security-related news sites and blogs, which the user inputs and registers, and the vulnerability DB may correct the vulnerability information obtained from the vulnerability server 40. In this way, it is possible to collect information that is not published on external vulnerability information websites such as NVDs and store it in the vulnerability DB, and even if the information on the vulnerability information site is incorrect due to a clerical error or the like, it is possible to store correct information in the vulnerability DB. The following options are possible for information to be stored in the vulnerability DB.

In option 1-1, the vulnerability DB stores the information shown in FIG. 6. As shown in FIG. 6, the vulnerability DB may store information that associates a vulnerability identifier, a first identifier, and vulnerability information.

As described above, the vulnerability identifier is a unique identifier that identifies a software vulnerability. The vulnerability identifier may include a CVE. The vulnerability identifier may be extracted from vulnerability information received from the vulnerability server 40.

The first identifier may be an identifier that uniquely identifies software, such as a CPE, as described above. The first identifier may be an identifier that can be associated with vulnerability information stored in the vulnerability server 40, and indicates software affected by a vulnerability identified by the vulnerability identifier. The first identifier may be an identifier that can be associated with a vulnerability identifier (e.g., CVE) stored in the vulnerability server 40. The first identifier may be extracted from vulnerability information received from the vulnerability server 40 (e.g., "Affected Software" shown in FIG. 4).

The first identifier may include a software version. As described above, the version is information (version information) that uniquely identifies the software version. The version may be information that directly indicates one version (e.g., "1.1" in cpe:x:x:xxxxx:xxxx:1.1) or information that indicates a range of versions (e.g., "from ver.xxx1 up to ver.xxxN" corresponding to cpe:y:y:yyyyy:yyyy:*). The version may be extracted from vulnerability information received from the vulnerability server 40 (e.g., "Affected Software" shown in FIG. 4).

Vulnerability information may include PoC information, score information, response information, and more.

The PoC information may include information indicating attack code in circulation. The PoC information may be considered to be information indicating whether or not attack code for software vulnerabilities is in circulation. For example, when the PoC information includes information indicating attack code in circulation, the information may indicate that attack code is in circulation, and when the PoC information does not include information indicating attack code in circulation, the information may indicate that attack code is not in circulation. The PoC information may be extracted from vulnerability information received from the vulnerability server 40.

The score information may be a score value indicating the level of vulnerability of the software, as described above. The score information may be a score value defined by CVSS (e.g., Base Score). The score information may be extracted from vulnerability information received from the vulnerability server 40 (e.g., "Score Information" shown in FIG. 4).

As described above, the response method may include information indicating a response method to the vulnerability (e.g., software update, etc.). The response method may be extracted from the vulnerability information received from the vulnerability server 40 (e.g., "Response Method" shown in FIG. 4).

The "others" may be information other than the PoC information, score information, and response methods. Although not particularly limited, the "others" may include information indicating that exploitation of a vulnerability has been confirmed. Information indicating that exploitation of a vulnerability has been confirmed may be interpreted as information indicating that circulating attack code has been exploited. Information indicating that exploitation of a vulnerability has been confirmed may be obtained from a vulnerability server 40 (e.g., a Known Exploited Vulnerabilities Catalog). The "others" may include information indicating the magnitude of the impact on business if an attack against a vulnerability is made. The magnitude of the impact on business may be expressed in two stages, that is, large or small.

In option 1-2, the vulnerability DB stores the information shown in FIG. 7. As shown in FIG. 7, the vulnerability DB may store information that associates a vulnerability identifier, a second identifier, and vulnerability information. The second identifier that is associated with the vulnerability information stored in the vulnerability DB may be information collected from security advisories provided by software suppliers or from open source security advisory information.

The second identifier is an identifier that uniquely identifies the software managed by the package management tool. The second identifier may be purl. The second identifier may be extracted from the vulnerability information received from the vulnerability server 40 (e.g., "Affected Software" shown in FIG. 4).

Here, the vulnerability information may be the same as in option 1-1.

The control unit 14 may include at least one processor. The at least one processor may be configured with a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), one or more Integrated Circuits, one or more Discrete Circuits, or a combination thereof.

First, the control unit 14 identifies vulnerability information of the target software from the vulnerability DB stored in the storage unit 13. The following options are possible methods for identifying vulnerability information:

Option 2-1 describes a case where a reference name that may include spelling variations is obtained. The reference name may be the name of the software obtained from the SBOM. In such a case, the vulnerability DB described in Option 1-1 (see, for example, Figure 6) may be used as the vulnerability DB. Here, the name of the software may be a combination of the supplier's name and the name of the asset such as the software.

The control unit 14 refers to the dictionary information (e.g., see FIG. 5) to identify a specific name of the target software that corresponds to the reference name of the target software, and identifies a first identifier of the target software that corresponds to the identified specific name of the target software. The control unit 14 uses the first identifier of the target software as a search key to identify vulnerability information of the target software from the vulnerability DB (e.g., see FIG. 6).

The reference name here is a name that is a variation of a specific name, and includes names that differ from the specific name due to, for example, character types (uppercase and lowercase letters, half-width and full-width kana, etc.), typing errors, synonyms, similar words, etc.

Furthermore, the control unit 14 determines whether the version information included in the first identifier associated with the vulnerability information in the vulnerability DB includes the version information included in the first identifier of the target software. If the control unit 14 determines that the version information included in the first identifier of the target software is included, it identifies the vulnerability information of the target software. On the other hand, if the control unit 14 determines that the version information included in the first identifier of the target software is not included, it does not identify the vulnerability information of the target software.

In option 2-1, the acquired reference information is not used as is as a search key for the vulnerability DB, but a specific name corresponding to the reference name is identified, and a first identifier corresponding to the specific name is used. Note that the acquired reference information may be used to directly identify the corresponding first identifier. Specifically, the control unit 14 refers to dictionary information (e.g., see FIG. 5) to identify the first identifier of the target software corresponding to the reference name of the target software. The control unit 14 uses the first identifier of the target software as a search key to identify vulnerability information of the target software from the vulnerability DB (e.g., see FIG. 6).

Furthermore, when version information of the target software is acquired, the specific name is identified using the specific name and the version information. Here, for the version information of the target software, variations in the spelling may also be registered in the dictionary information in association with the correct spelling. In this case, once the version information of the target software is acquired, the dictionary information is referenced to identify the version information of the target software with the correct spelling. The first identifier may be identified using the identified version information of the target software.

In option 2-1, after the first identifier is identified, vulnerability information can be identified using the first identifier as a search key. Even if the name of the acquired target software has spelling variations from the official software name, the spelling variations can be absorbed and vulnerability information can be identified.

Option 2-2 describes a case where a second identifier (e.g., purl) of software managed by a package management tool is obtained. In such a case, the vulnerability DB described in Option 1-2 (e.g., see FIG. 7) may be used as the vulnerability DB.

The control unit 14 uses the second identifier of the target software as a search key to identify vulnerability information of the target software from the vulnerability DB (see FIG. 7).

Furthermore, the control unit 14 determines whether the version information included in the second identifier associated with the vulnerability information in the vulnerability DB includes the version information included in the second identifier of the target software. If the control unit 14 determines that the version information included in the second identifier of the target software is included, it identifies the vulnerability information of the target software. On the other hand, if the control unit 14 determines that the version information included in the second identifier of the target software is not included, it does not identify the vulnerability information of the target software.

In option 2-2, for software managed by a package management tool, the obtained second identifier can be used as a search key to identify the vulnerability database.

Second, the control unit 14 determines the priority of implementing measures against the vulnerability corresponding to the identified vulnerability information. The process of determining the priority of responding to the vulnerability information may be referred to as triage. The priority may be referred to as Level.

As shown in FIG. 8, the Level may be expressed in five stages, from Level 0 to Level 4. The higher the Level value, the higher the priority of implementing measures against the vulnerability. Vulnerabilities may be narrowed down in the order of Level 0 to Level 4.

Level 0 includes all vulnerabilities whose score value (e.g., the Base Score defined by CVSS) is below a threshold. Level 0 vulnerabilities can be considered vulnerabilities for which no special countermeasures are required.

Level 1 or higher vulnerabilities may include vulnerabilities whose score value is equal to or greater than a threshold. Level 1 vulnerabilities are Level 1 or higher vulnerabilities excluding Level 2 or higher vulnerabilities. Level 1 vulnerabilities may be determined as vulnerabilities for which countermeasures are implemented during regular maintenance (e.g., once a month), and the priority of responding to Level 1 vulnerabilities is higher than the priority of Level 0 vulnerabilities.

Level 2 or higher vulnerabilities may include vulnerabilities in the target software that are accessible from the outside and are Level 1 or higher. Level 2 may include vulnerabilities in the target software that have a large impact on business operations when attacked and are Level 1 or higher vulnerabilities. Level 2 vulnerabilities are Level 2 or higher vulnerabilities excluding Level 3 or higher vulnerabilities. Level 2 vulnerabilities may be determined as vulnerabilities for which countermeasures should be implemented within a first deadline (e.g., within two weeks), and the priority of responding to Level 2 vulnerabilities is higher than the priority of responding to Level 1 vulnerabilities.

Level 3 or higher vulnerabilities may include Level 2 or higher vulnerabilities for which attack code is in circulation. Level 3 vulnerabilities are Level 3 or higher vulnerabilities excluding Level 4 vulnerabilities. Level 3 vulnerabilities may be determined as vulnerabilities for which countermeasures should be implemented within a second deadline (e.g., within one day) that is shorter than the first deadline, and the priority of responding to Level 3 vulnerabilities is higher than the priority of responding to Level 2 vulnerabilities.

Level 4 vulnerabilities may include Level 3 or higher vulnerabilities for which attacks have actually been observed and exploitation has been confirmed. Level 4 vulnerabilities may be determined to be vulnerabilities for which countermeasures should be implemented within a third deadline (e.g., immediately) that is shorter than the second deadline, and the priority of responding to Level 4 vulnerabilities is higher than the priority of responding to Level 3 vulnerabilities. In other words, Level 4 vulnerabilities have the highest priority.

Information indicating that a vulnerability has been exploited may be obtained from a vulnerability server 40 (e.g., a Known Exploited Vulnerabilities Catalog).

To achieve the above-mentioned triage, the control unit 14 may be expressed as executing the processes shown below.

First, the control unit 14 sets a priority for the vulnerability information of the identified target software based on at least one of the following: information indicating the vulnerability level set by a third-party organization, information indicating whether the target software is accessible from the outside, information indicating whether an attack against the vulnerability will have a significant impact on business operations, information indicating whether attack code against the vulnerability is in circulation, and information indicating whether exploitation of the vulnerability has been confirmed.

Secondly, when the vulnerability information of the target software is specific vulnerability information and the target software is accessible from outside, the control unit 14 sets the highest priority (Level 4 shown in FIG. 8) as the priority of the vulnerability information of the target software. Specific vulnerability information is vulnerability information in which exploitation of the vulnerability corresponding to the vulnerability information of the target software has been confirmed.

Third, when the control unit 14 determines, based on the vulnerability information of the identified target software, that attack code is in circulation for a vulnerability corresponding to the vulnerability information of the target software, the control unit 14 sets the priority of the vulnerability information of the target software to a first priority (Level 3 shown in FIG. 8). When the vulnerability information of the target software is specific vulnerability information and the target software is accessible from outside, the control unit 14 sets the priority of the vulnerability information of the target software to a second priority (Level 4 shown in FIG. 8), which is higher than the first priority. Specific vulnerability information is vulnerability information in which exploitation of a vulnerability has been confirmed.

Fourth, the control unit 14 determines, based on the identified vulnerability information of the target software, that attack code is in circulation against a vulnerability corresponding to the vulnerability information of the target software, and if the target software is accessible from the outside, sets the priority of the vulnerability information of the target software to a third priority (Level 3 or higher shown in FIG. 8). If the vulnerability information of the target software is specific vulnerability information and the target software is not accessible from the outside, the control unit 14 sets the priority of the vulnerability information of the target software to a fourth priority (Level 2 shown in FIG. 8), which is lower than the third priority. Specific vulnerability information is vulnerability information in which exploitation of a vulnerability has been confirmed.

(Information Processing Method)
An information processing method according to an embodiment will be described below. Fig. 9 is a diagram showing the information processing method according to an embodiment.

As shown in FIG. 9, in step S10, the information processing device 10 stores dictionary information that associates specific names with reference names. The dictionary information may include information that associates specific names with first identifiers (see FIG. 5). Although not particularly limited, the information processing device 10 may collect SBOMs created by various creators and include names included in the collected SBOMs in the dictionary information as reference names.

In step S11, the information processing device 10 receives vulnerability information (e.g., see FIG. 4) from the vulnerability server 40.

In step S12, the information processing device 10 stores the vulnerability information in the vulnerability DB. The information processing device 10 may store information obtained by extracting various information from the vulnerability information received from the vulnerability server 40 in the vulnerability DB (see FIG. 6 or FIG. 7).

In step S13, the information processing device 10 receives software information from the system server 30. The software information is information about the software target software operating on the system server 30. The system information may be an SBOM or may be information about the target software managed by a package management tool. The software information may include version information of the target software.

In step S14, the information processing device 10 stores software information regarding the software target software running on the system server 30.

In step S20, the information processing device 10 receives a request for information about vulnerabilities. The information about vulnerabilities may include the results of the triage described above.

In step S21, the information processing device 10 executes a name matching process. The name matching process is a process of identifying a specific name from a reference name by referring to dictionary information. The name matching process may include a process of identifying a first identifier from a specific name.

In step S22, the information processing device 10 identifies vulnerability information. In option 2-1, the information processing device 10 identifies vulnerability information of the target software from the vulnerability DB (see, for example, FIG. 6) using the first identifier of the target software as a search key. In option 2-2, the information processing device 10 identifies vulnerability information of the target software from the vulnerability DB (see FIG. 7) using the second identifier of the target software as a search key.

In step S23, the information processing device 10 performs triage on the vulnerabilities corresponding to the identified vulnerability information. Details of the triage are as described above (see FIG. 8).

In step S24, the information processing device 10 transmits display data displaying information about the vulnerability to the terminal 20. The information about the vulnerability may include the results of the triage described above.

(Action and Effects)
In the embodiment, the information processing device 10 refers to the dictionary information to identify a specific name of the target software corresponding to the reference name of the target software, identifies a first identifier of the target software corresponding to the identified specific name of the target software, and identifies vulnerability information of the target software from the vulnerability database using the first identifier of the target software as a search key. According to such a configuration, even in a case where there are variations in the spelling of the software name, etc., it is possible to match the target software with the vulnerability database by referring to the dictionary information to identify the first identifier of the target software from the reference name of the target software, and it is possible to appropriately identify vulnerability information of the target software.

In an embodiment, for target software included in the SBOM, the information processing device 10 may identify vulnerability information of the target software from a vulnerability DB (e.g., see FIG. 6) using the first identifier of the target software as a search key (option 2-1). In option 2-1, although the process of identifying a specific name from a reference name (name matching process) is complicated, after identifying the first identifier, it is possible to identify vulnerability information using the first identifier as a search key.

In an embodiment, for target software managed by a package management tool, the information processing device 10 may identify vulnerability information of the target software from a vulnerability DB (see FIG. 7) using the second identifier of the target software as a search key (option 2-1). In option 2-2, although it is cumbersome to extract the second identifier from the vulnerability information received from the vulnerability server 40 (for example, "Affected Software" shown in FIG. 4) and construct the vulnerability DB, the obtained second identifier can be used as a search key as is.

In an embodiment, the information processing device 10 may set the highest priority (e.g., Level 4 shown in FIG. 8) as the priority for implementing measures against a vulnerability for vulnerability information in which exploitation of the vulnerability has been confirmed. However, when the target software corresponding to the vulnerability information in which exploitation of the vulnerability has been confirmed is not accessible from the outside, the information processing device 10 may set a low priority (e.g., Level 1 shown in FIG. 8) as the priority for implementing measures against the vulnerability. With such a configuration, triage can be performed appropriately.

[Change Example 1]
Modification 1 of the embodiment will be described below. Differences from the embodiment will be mainly described below.

In the first modification, an alert regarding software support will be described. Generally, software maintenance and support ends a certain period of time after the software is no longer on sale. Here, software maintenance and support includes software updates for vulnerabilities, inquiries, and maintenance when a failure occurs. The date on which software support ends may be called the EOL (End of Life) date. For software that has passed its EOL date, patches are not applied even when vulnerabilities are discovered, increasing the risk of attack. Therefore, from a security perspective, users usually need to take measures such as upgrading the software or switching to another software before the EOL date.

Under such a premise, the information processing device 10 (storage unit 13) may store a master DB that stores the information shown in FIG. 10. As shown in FIG. 9, the master DB may store information that associates an ID, a software name, related information, an EOL date, a first identifier (e.g., CPE), and a second identifier (e.g., purl).

The ID is an identifier used to identify software in the information processing device 10. The ID may be associated with at least one of two or more first identifiers and second identifiers in a one-to-many relationship (for example, "PAxxxx" and "PBxxxx" associated with "XXXX"). The ID may be associated with at least one of one first identifier and second identifier in a one-to-one relationship (for example, "PAyyyy" associated with "YYYY").

The software name is the name of the software corresponding to the ID, and may be a specific name of the software. Furthermore, when two or more first identifiers or second identifiers are associated with an ID, the software name may be a comprehensive name that includes each of the software indicated by the two or more first identifiers or second identifiers.

Related information is information related to the software corresponding to the ID. Related information may include the release date of the software, etc.

The EOL date is the date when support for the software ends, and is information provided by the software supplier, etc. The EOL date may be managed by ID or software name.

The first and second identifiers may be extracted from vulnerability information (e.g., "Affected Software" shown in FIG. 4) received from the vulnerability server 40. The extracted first and second identifiers are associated with the ID or name of a master DB that manages EOL dates, etc.

The information processing device 10 (control unit 14) refers to the master DB and outputs an alert regarding the target software based on the EOL date when support for the target software ends. Specifically, the information processing device 10 acquires at least one of the first and second identifiers of the target software based on the scan results of the target software or an SBOM imported from outside. The control unit 14 acquires the specific name and EOL date of the target software from the master DB using at least one of the first and second identifiers of the target software as a search key, and outputs an alert based on the EOL date. Here, a comprehensive name including two or more software may be acquired as the specific name of the target software. More specifically, the control unit 14 identifies the specific name of the corresponding target software using at least one of the first and second identifiers of the target software as a search key. Thereafter, the control unit 14 acquires the EOL date corresponding to the identified specific name. The control unit 14 may also directly acquire the corresponding EOL date using at least one of the first and second identifiers of the target software as a search key. The alert may be visually displayed in the EOL date column of the master DB. The alert may be output in stages according to the number of days remaining until the EOL date. The number of days remaining can also be interpreted as the priority for taking measures against the end of support.

The search key used to search for the EOL date is not limited to the first identifier (e.g., CPE) and the second identifier (e.g., purl), but may be an identifier or name that can identify the target software.

For example, the information processing device 10 may output an alert six months before the EOL date to inform the user that support will end in six months, or may output an alert three months before the EOL date to inform the user that support will end in three months, or may output an alert when the EOL date arrives to inform the user that support will end. The information processing device 10 may also output an alert after the EOL date to inform the user that support has expired.

The EOL date may be called the EOS (End of Support) date or the EOSL (End of Service Life) date. It may also be read as the EOS (End of Sale) date, which indicates the end of sales of a service, or the EOE (End of Engineering) date, which indicates the end of technical support.

(Action and Effects)
In the first modification, an alert is output regarding the target software based on the EOL date when support for the target software ends in the information processing device 10. With this configuration, measures such as software upgrades and software changes can be appropriately taken for the target software for which support ends.

[Other embodiments]
Although the present invention has been described by the above-mentioned embodiment, the description and drawings forming a part of this disclosure should not be understood as limiting the present invention. From this disclosure, various alternative embodiments, examples and operating techniques will become apparent to those skilled in the art.

In the above disclosure, the information processing device 10 receives software information from the system server 30. However, the above disclosure is not limited to this. The software information may be input via a user interface of the information processing device 10. The software information may be acquired by importing the SBOM. Terms such as receive, input, import, and acquisition may be read interchangeably.

In the above disclosure, the vulnerability DB is stored in the storage unit 13 of the information processing device 10. However, the above disclosure is not limited to this. One or more vulnerability servers 40 may be used as the vulnerability DB as is.

In the above disclosure, the triage priority level is expressed in five stages. However, the above disclosure is not limited to this. The triage priority level may be expressed in four stages or less, or in six stages or more.

Although not specifically mentioned in the above disclosure, a program may be provided that causes a computer to execute each process performed by the information processing device 10. The program may also be recorded on a computer-readable medium. Using the computer-readable medium, it is possible to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transient recording medium. The non-transient recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

Alternatively, a chip may be provided that is configured with a memory that stores programs for executing each process performed by the information processing device 10 and a processor that executes the programs stored in the memory.

[Additional Notes]
A first feature is an information processing device comprising: a storage unit that stores dictionary information that corresponds a specific name of software with a reference name that indicates software identical to the software having the specific name; an acquisition unit that acquires a reference name of target software; and a control unit that refers to the dictionary information to identify a specific name of the target software that corresponds to the reference name of the target software and to identify a first identifier of the target software that corresponds to the identified specific name of the target software, wherein the storage unit stores a vulnerability database that corresponds to the first identifier of the software and vulnerability information, and the control unit identifies the vulnerability information of the target software from the vulnerability database using the first identifier of the target software as a search key.

The second feature is an information processing device according to the first feature, in which the acquisition unit acquires version information of the target software along with a reference name of the target software, and the control unit identifies a first identifier of the target software corresponding to the specific name of the target software and the version information of the target software, determines whether the version information included in the first identifier associated with the vulnerability information in the vulnerability database includes the version information included in the first identifier of the target software, and identifies vulnerability information of the target software when it is determined that the version information is included.

The third feature is an information processing device according to the first or second feature, wherein the vulnerability database stores a second identifier of software managed by a package management tool in association with vulnerability information, the acquisition unit acquires a second identifier of the target software managed by a package management tool, the storage unit stores the second identifier of the software in association with vulnerability information in the vulnerability database, and the control unit identifies the vulnerability information of the target software from the vulnerability database using the second identifier of the target software as a search key.

The fourth feature is an information processing device according to the third feature, wherein the acquisition unit acquires version information of the target software included in a second identifier of the target software, and the control unit determines whether the version information included in the second identifier associated with the vulnerability information in the vulnerability database includes the version information included in the second identifier of the target software, and if it is determined that the version information is included, identifies vulnerability information of the target software.

The fifth feature is an information processing device according to the third or fourth feature, wherein the storage unit stores at least one of the first identifier of the target software and the second identifier of the target software in association with a specific name of the target software, and stores the specific name of the target software in association with a date on which support for the target software will end, and the control unit identifies the specific name of the target software and the date on which support for the target software will end based on at least one of the first identifier of the target software and the second identifier of the target software, and outputs an alert regarding the target software based on the date on which support for the target software will end.

The sixth feature is an information processing device in at least one of the first to fifth features, in which the acquisition unit acquires a list of components constituting the software by importing it from an external device, and acquires a reference name of the target software from the list of components.

The seventh feature is an information processing device in at least one of the first to sixth features, in which the control unit sets a priority of the vulnerability information of the target software based on at least one of information indicating a vulnerability level set by a third party organization for a vulnerability corresponding to the identified vulnerability information of the target software, information indicating whether the target software is accessible from the outside, information indicating whether an attack against the vulnerability will have a significant impact on business operations, information indicating whether attack code against the vulnerability is in circulation, and information indicating whether exploitation of the vulnerability has been confirmed.

The eighth feature is an information processing device according to at least one of the first to seventh features, wherein, when the vulnerability information of the target software is specific vulnerability information and the target software is accessible from the outside, the control unit sets the highest priority as the priority of the vulnerability information of the target software, and the specific vulnerability information is vulnerability information in which exploitation of a vulnerability corresponding to the vulnerability information of the target software has been confirmed.

The ninth feature is an information processing device according to at least one of the first to eighth features, wherein, when the control unit determines, based on the identified vulnerability information of the target software, that an attack code for a vulnerability corresponding to the vulnerability information of the target software is in circulation, the control unit sets a first priority as the priority of the vulnerability information of the target software, and when the vulnerability information of the target software is specific vulnerability information and is accessible from outside the target software, the control unit sets a second priority higher than the first priority as the priority of the vulnerability information of the target software, and the specific vulnerability information is vulnerability information in which exploitation of the vulnerability has been confirmed.

The tenth feature is an information processing device in which, in at least one of the first to ninth features, the control unit identifies, based on the identified vulnerability information of the target software, that an attack code for a vulnerability corresponding to the vulnerability information of the target software is in circulation, and when the target software is accessible from the outside, sets a third priority as the priority of the vulnerability information of the target software, and when the vulnerability information of the target software is specific vulnerability information and the target software is not accessible from the outside, sets a fourth priority lower than the third priority as the priority of the vulnerability information of the target software, and the specific vulnerability information is vulnerability information in which exploitation of the vulnerability has been confirmed.

The eleventh feature is an information processing method including a step A of storing dictionary information that associates a specific name of software with a reference name that indicates the same software as the software having the specific name, a step B of acquiring a reference name of target software, a step C of referring to the dictionary information to identify a specific name of the target software that corresponds to the reference name of the target software and to identify a first identifier of the target software that corresponds to the identified specific name of the target software, a step D of storing a vulnerability database that stores the first identifier of the software in association with vulnerability information, and a step E of identifying vulnerability information of the target software from the vulnerability database using the first identifier of the target software as a search key.

10...information processing device, 11...transmission unit, 12...reception unit, 13...storage unit, 14...control unit, 20...terminal, 30...system server, 40...vulnerability server, 100...information processing system, 200...network

Claims (10)

a storage unit that stores dictionary information that associates a plurality of software names with a first identifier of the software, the plurality of software names including a plurality of names indicating the same software, the storage unit that associates the plurality of names indicating the same software with the same first identifier and stores the dictionary information;
an acquisition unit for acquiring the name of the target software;
a control unit that refers to the dictionary information and identifies a first identifier of the target software corresponding to a name of the target software,
the storage unit stores a vulnerability database that stores a first identifier of the software and vulnerability information in association with each other;
the control unit identifies vulnerability information of the target software from the vulnerability database by using a first identifier of the target software as a search key;
the storage unit stores, in the vulnerability database, a second identifier of software managed by a package management tool and vulnerability information in association with each other;
The acquisition unit acquires a second identifier of the target software managed by a package management tool,
The control unit identifies vulnerability information of the target software from the vulnerability database using the second identifier of the target software as a search key. The acquisition unit acquires version information of the target software together with the name of the target software,
The information processing device of claim 1, wherein the control unit identifies a first identifier of the target software corresponding to the name of the target software and the version information of the target software, determines whether the version information contained in the first identifier associated with the vulnerability information in the vulnerability database includes the version information contained in the first identifier of the target software, and if it is determined that the version information is included, identifies the vulnerability information of the target software. The acquisition unit acquires version information of the target software included in a second identifier of the target software,
The information processing device of claim 1, wherein the control unit determines whether the version information included in the second identifier associated with the vulnerability information in the vulnerability database includes the version information included in the second identifier of the target software, and if it determines that the version information is included, identifies the vulnerability information of the target software. the storage unit stores at least one of a first identifier of the target software and a second identifier of the target software in association with a name of the target software, and also stores the name of the target software in association with a date on which support for the target software will end;
2. The information processing device of claim 1, wherein the control unit identifies a name of the target software and a date on which support for the target software will end based on at least one of a first identifier of the target software and a second identifier of the target software, and outputs an alert regarding the target software based on the date on which support for the target software will end. The information processing device according to claim 1, wherein the acquisition unit acquires a list of components constituting the software by importing the list from an external device, and acquires the name of the target software from the list of components. The information processing device according to claim 1, wherein the control unit sets a priority of the vulnerability information of the target software based on at least one of information indicating a level of the vulnerability set by a third party organization for the vulnerability corresponding to the identified vulnerability information of the target software, information indicating whether the target software is accessible from the outside, information indicating whether an attack against the vulnerability will have a large impact on business operations, information indicating whether attack code against the vulnerability is in circulation, and information indicating whether exploitation of the vulnerability has been confirmed. the control unit, when the vulnerability information of the target software is specific vulnerability information and the target software is accessible from the outside, sets the highest priority as the priority of the vulnerability information of the target software;
The information processing apparatus according to claim 1 , wherein the specific vulnerability information is vulnerability information in which exploitation of a vulnerability corresponding to the vulnerability information of the target software has been confirmed. The control unit is
When it is identified that an attack code for a vulnerability corresponding to the vulnerability information of the target software is in circulation based on the identified vulnerability information of the target software, a first priority is set as a priority of the vulnerability information of the target software;
when the vulnerability information of the target software is specific vulnerability information and the target software is accessible from outside, setting a second priority higher than the first priority as the priority of the vulnerability information of the target software;
The information processing apparatus according to claim 1 , wherein the specific vulnerability information is vulnerability information in which exploitation of the vulnerability has been confirmed. The control unit is
based on the identified vulnerability information of the target software, it is identified that an attack code for a vulnerability corresponding to the vulnerability information of the target software is in circulation, and when the target software is accessible from outside, a third priority is set as a priority of the vulnerability information of the target software;
when the vulnerability information of the target software is specific vulnerability information and the target software is not accessible from the outside, setting a fourth priority level, which is lower than the third priority level, as the priority level of the vulnerability information of the target software;
The information processing apparatus according to claim 1 , wherein the specific vulnerability information is vulnerability information in which exploitation of the vulnerability has been confirmed. An information processing method executed by a computer having a processor, comprising:
The computer includes:
a storage unit for storing dictionary information that associates a plurality of software names with a first identifier of the software, the plurality of software names including a plurality of names indicating the same software, and the plurality of names indicating the same software are stored in association with the same first identifier;
The information processing method includes the processor:
obtaining a name of the subject software;
referring to the dictionary information to identify a first identifier of the target software corresponding to a name of the target software;
the storage unit stores a vulnerability database that stores a first identifier of the software and vulnerability information in association with each other;
In the step of identifying, the processor identifies vulnerability information of the target software from the vulnerability database by using a first identifier of the target software as a search key;
the storage unit stores, in the vulnerability database, a second identifier of software managed by a package management tool and vulnerability information in association with each other;
The processor, in the acquiring step, acquires a second identifier of the target software managed by a package management tool;
An information processing method, in which in the identifying step, vulnerability information of the target software is identified from the vulnerability database using a second identifier of the target software as a search key.