Vulnerability assessment device, vulnerability assessment system, and vulnerability assessment method

Abstract

To provide vulnerability evaluation means capable of determining software that may contain a vulnerability similar to software that contains a specific vulnerability, even when configuration information on components contained in the software is not provided.SOLUTION: A vulnerability evaluation device includes: a vulnerability management unit configured to acquire vulnerability information that characterizes vulnerabilities related to software assets; a knowledge database management unit configured to generate a knowledge database that indicates a relationship between software asset information and the vulnerability information; an input management unit configured to accept a vulnerability designation input that designates a first vulnerability in a first software asset; and a vulnerability containing candidate determination unit configured to search the knowledge database based on the vulnerability designation input to generate vulnerability containing candidate information that indicates a second software asset that may contain the first vulnerability.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a vulnerability assessment device, a vulnerability assessment system, and a vulnerability assessment method. [Background technology]

[0002] In recent years, cybersecurity technology has been attracting attention due to the discovery of new vulnerabilities in information systems and the emergence of new attack methods against information systems. Under these circumstances, issues such as whether information systems contain vulnerabilities and the extent of damage that could occur if a cyberattack exploits these vulnerabilities have become important concerns for society and organizations.

[0003] Therefore, for example, companies are required to obtain various reports on newly discovered vulnerabilities and cyber attacks (hereinafter referred to as cyber events) in order to understand business risks, and to take appropriate measures based on these reports.

[0004] Conventionally, several proposals have been made to determine whether software has vulnerabilities. For example, U.S. Patent No. 1,121,8510 (Patent Document 1) describes a technology that "analyzes the code and / or behavior of a software application to identify the components that make up the software, identifies the sources of the components, identifies vulnerabilities associated with the components, compiles a list of the components, creates a directed graph of the relationships between the components and their sources, and assesses the overall threat associated with the software application based on vulnerabilities in the software supply chain." [Prior art documents] [Patent documents]

[0005] [Patent Document 1] U.S. Patent No. 1,121,8510 Summary of the Invention [Problem to be solved by the invention]

[0006] The above-mentioned Patent Document 1 describes a means for evaluating the resistance of specific software to cyber attacks based on the vulnerabilities and sources (origins) of each of the software components that make up the software.

[0007] However, in the current software sales model, configuration information about the components included in the software is not often provided to end users such as clients. For this reason, when configuration information about the components included in the software is not provided to end users, the application of vulnerability assessment based on the configuration method of software components, such as that described in Patent Document 1, is limited, and it may not be possible to determine whether or not there are vulnerabilities in the software.

[0008] Furthermore, while the means described in Patent Document 1 can determine whether or not a particular piece of software being evaluated has any vulnerability, it is not intended to determine whether or not a particular vulnerability specified by a user exists, or to determine related software that is highly similar to software containing a particular vulnerability and may contain a similar vulnerability.

[0009] Furthermore, the method described in Patent Document 1 creates a cyber-physical graph that shows the components included in the specified software to be evaluated and the relationships between the sources of these components. However, this cyber-physical graph does not associate the components with public vulnerability information, making it difficult to perform vulnerability assessment that takes into account new vulnerabilities that are discovered every day.

[0010] Therefore, the present disclosure aims to provide a vulnerability assessment means that can determine whether or not software has a specific vulnerability, even when, for example, configuration information regarding components included in the software is not provided, and can determine software that is highly similar to software that contains a specific vulnerability and may contain a similar vulnerability. [Means for solving the problem]

[0011] To solve the above-mentioned problems, one representative vulnerability assessment device of the present invention includes a processor, a memory, and a storage unit, the storage unit including a software asset database that stores software asset information that characterizes software assets, and the memory includes processing instructions that cause the processor to function as a vulnerability management unit that acquires vulnerability information that characterizes vulnerabilities related to the software assets, a knowledge database management unit that generates a knowledge database that indicates the relationship between the software asset information and the vulnerability information, an input management unit that accepts a vulnerability designation input that designates a first vulnerability in a first software asset, and a vulnerability candidate determination unit that generates vulnerability candidate information that indicates a second software asset that may contain the first vulnerability by searching the knowledge database based on the vulnerability designation input. [Effects of the Invention]

[0012] According to the present disclosure, it is possible to provide a vulnerability assessment means that can determine whether or not software has a specific vulnerability, even if configuration information regarding components contained in the software is not provided, and can determine software that is highly similar to software containing a specific vulnerability and may contain a similar vulnerability. Problems, configurations, and effects other than those described above will become apparent from the following description of the preferred embodiment of the invention. [Brief explanation of the drawings]

[0013] [Figure 1]FIG. 1 is a diagram illustrating a computer system for implementing an embodiment of the present disclosure. [Figure 2] FIG. 2 is a diagram illustrating an example of the configuration of a vulnerability assessment system according to an embodiment of the present disclosure. [Figure 3] FIG. 3 is a diagram illustrating an example of the overall flow of processing by the vulnerability assessment system according to an embodiment of the present disclosure. [Figure 4] FIG. 4 is a diagram illustrating an example of the flow of a vulnerability candidate determination process according to an embodiment of the present disclosure. [Figure 5] FIG. 5 is a diagram showing an example of the flow of a software asset verification process according to an embodiment of the present disclosure. [Figure 6] FIG. 6 is a diagram illustrating an example of a knowledge database in a graph format according to an embodiment of the present disclosure. [Figure 7] FIG. 7 is a diagram illustrating an example of a knowledge database in a tabular format according to an embodiment of the present disclosure. [Figure 8] FIG. 8 is a diagram illustrating an example of a software asset management database according to an embodiment of the present disclosure. [Figure 9] FIG. 9 is a diagram illustrating an example of an SBOM database according to an embodiment of the present disclosure. [Figure 10] FIG. 10 is a diagram illustrating an example of the configuration of a binary database according to an embodiment of the present disclosure. [Figure 11] FIG. 11 is a diagram illustrating an example of the configuration of a vulnerability database according to an embodiment of the present disclosure. [Figure 12] FIG. 12 is a diagram illustrating an example of the configuration of the software asset configuration information database according to an embodiment of the present disclosure. [Figure 13] FIG. 13 is a diagram illustrating an example of the configuration of vulnerability candidate information according to an embodiment of the present disclosure. [Figure 14] FIG. 14 is a diagram showing the configuration of evaluation result information according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0014] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Note that the present invention is not limited to this embodiment. In addition, in the description of the drawings, the same parts are designated by the same reference numerals. Furthermore, although terms such as "first," "second," and "third" may be used to describe various elements or components in this disclosure, it will be understood that these elements or components should not be limited by these terms. These terms are used only to distinguish one element or component from another. Thus, a first element or component discussed below could also be referred to as a second element or component without departing from the teachings of the inventive concept.

[0015] First, referring to Figure 1, a computer system 100 for implementing embodiments of the present disclosure will be described. The mechanisms and devices of various embodiments disclosed herein may be applied to any suitable computing system. The main components of the computer system 100 include one or more processors 102, memory 104, a terminal interface 112, a storage interface 113, an I / O (input / output) device interface 114, and a network interface 115. These components may be interconnected via a memory bus 106, an I / O bus 108, a bus interface unit 109, and an I / O bus interface unit 110.

[0016] Computer system 100 may include one or more general-purpose programmable central processing units (CPUs) 102A and 102B, collectively referred to as processors 102. In some embodiments, computer system 100 may include multiple processors, while in other embodiments, computer system 100 may be a single CPU system. Each processor 102 executes instructions stored in memory 104 and may include an on-board cache.

[0017] In one embodiment, memory 104 may include random-access semiconductor memory, storage devices, or storage media (either volatile or non-volatile) for storing data and programs. Memory 104 may store all or part of the programs, modules, and data structures that implement the functions described herein. For example, memory 104 may store vulnerability assessment application 150. In one embodiment, vulnerability assessment application 150 may include instructions or descriptions that execute the functions described below on processor 102.

[0018] In some embodiments, vulnerability assessment application 150 may be implemented in hardware via semiconductor devices, chips, logic gates, circuits, circuit cards, and / or other physical hardware devices instead of or in addition to a processor-based system. In some embodiments, vulnerability assessment application 150 may include data other than instructions or descriptions. In some embodiments, cameras, sensors, or other data input devices (not shown) may be provided to communicate directly with bus interface unit 109, processor 102, or other hardware of computer system 100.

[0019] Computer system 100 may include a bus interface unit 109 that facilitates communication between processor 102, memory 104, display system 124, and I / O bus interface unit 110. I / O bus interface unit 110 may couple to an I / O bus 108 for transferring data to and from various I / O units. I / O bus interface unit 110 may communicate via I / O bus 108 with multiple I / O interface units 112, 113, 114, and 115, also known as I / O processors (IOPs) or I / O adapters (IOAs).

[0020] Display system 124 may include a display controller, a display memory, or both. The display controller may provide video, audio, or both data to display device 126. Computer system 100 may also include one or more sensors or other devices configured to collect data and provide the data to processor 102.

[0021] For example, computer system 100 may include biometric sensors that collect heart rate data, stress level data, etc., environmental sensors that collect humidity data, temperature data, pressure data, etc., and motion sensors that collect acceleration data, movement data, etc. Other types of sensors may also be used. Display system 124 may be connected to a display device 126, such as a standalone display screen, a television, a tablet, or a handheld device.

[0022] The I / O interface unit provides functionality for communicating with various storage or I / O devices. For example, the terminal interface unit 112 may be attached to user I / O devices 116, such as user output devices such as a video display, a television with speakers, and user input devices such as a keyboard, a mouse, a keypad, a touchpad, a trackball, buttons, a light pen, or other pointing device. A user may use a user interface to enter input data or instructions into the user I / O devices 116 and the computer system 100, and receive output data from the computer system 100, by operating the user input devices. The user interface may be displayed on a display, played through speakers, or printed via a printer via the user I / O devices 116, for example.

[0023] Storage interface 113 allows attachment of one or more disk drives or direct access storage device 117 (typically a magnetic disk drive storage device, but may also be an array of disk drives or other storage devices configured to appear as a single disk drive). In some embodiments, storage device 117 may be implemented as any secondary storage device. The contents of memory 104 may be stored in storage device 117 and retrieved as needed from storage device 117. I / O device interface 114 may provide an interface to other I / O devices, such as printers, fax machines, etc. Network interface 115 may provide a communications path that allows computer system 100 and other devices to communicate with each other. This communications path may be, for example, network 130.

[0024] In some embodiments, computer system 100 may be a device that receives requests from other computer systems (clients) without a direct user interface, such as a multi-user mainframe computer system, a single-user system, or a server computer. In other embodiments, computer system 100 may be a desktop computer, a portable computer, a laptop, a tablet computer, a pocket computer, a telephone, a smartphone, or any other suitable electronic device.

[0025] Next, a vulnerability assessment system according to an embodiment of the present disclosure will be described with reference to FIG.

[0026] 2 is a diagram illustrating an example of a configuration of a vulnerability assessment system 200 according to an embodiment of the present disclosure. The vulnerability assessment system 200 is a system for performing vulnerability assessment. As shown in FIG. 2, the vulnerability assessment system 200 includes a vulnerability assessment device 210, a communication network 250, an external DB 260, and a client terminal 270. In the vulnerability assessment system 200, the vulnerability assessment device 210, the external DB 260, and the client terminal 270 may be connected to each other via the communication network 250.

[0027] The vulnerability assessment device 210 is a device for determining other software assets that are highly similar to software containing a specific vulnerability and may contain similar vulnerabilities, and as shown in Figure 2, mainly includes a memory 220, a storage unit 230, a processor 244, and an input / output unit 246. In one embodiment, the vulnerability assessor 210 may be implemented by the computer system 100 shown in FIG.

[0028] The memory 220 may be a memory for storing a vulnerability assessment application 150 for implementing a vulnerability assessment means according to an embodiment of the present disclosure. The vulnerability assessment application 150 may include processing instructions for implementing the functions of software modules such as a vulnerability management unit 221, a knowledge database management unit 222, an input management unit 223, a vulnerability candidate determination unit 224, a search unit 225, a risk assessment unit 226, and a result output unit 227, as shown in FIG.

[0029] The vulnerability management unit 221 is a functional unit that acquires vulnerability information that characterizes vulnerabilities related to software assets and stores the information in, for example, a vulnerability DB 235 described below. In an embodiment, the vulnerability management unit 221 may acquire the vulnerability information from an external public vulnerability database such as a CVEDB 261, a CWEDB 262, or a CAPECDB 263 described below.

[0030] In this disclosure, "software assets" refers to a collection of programs and data that cause a computer to perform a specific task or function, and may be, for example, proprietary software owned by a specific individual or organization, or open source software. Furthermore, in this disclosure, "vulnerability" refers to an information security flaw that occurs in the above-mentioned software assets due to a program malfunction or design error.

[0031] The knowledge database management unit 222 is a functional unit for generating a knowledge database that shows the relationship between software asset information and vulnerability information. As will be described later, this knowledge database may be a data set that shows, in graph or table format, the logical relationships between information such as software assets, software providers that develop and sell the software assets, packages that include software products used with the software assets, vulnerabilities in the software assets, and attack methods and weaknesses that exploit the vulnerabilities. As will be described later, using this knowledge database makes it possible to determine other software assets that are highly similar to software containing a specific vulnerability and that may contain similar vulnerabilities.

[0032] The input management unit 223 is a functional unit for receiving information such as a vulnerability designation input that designates a specific vulnerability (e.g., a first vulnerability) in a specific software asset (e.g., a first software asset) from, for example, a client terminal 270 described later. As an example, the input management unit 223 may receive a vulnerability designation input that indicates a specific CVEID.

[0033] The vulnerability candidate determination unit 224 is a functional unit that generates vulnerability candidate information indicating software assets (e.g., second software assets) that may contain the vulnerability indicated in the vulnerability designation input (e.g., first vulnerability) by searching the knowledge database generated by the knowledge database management unit 222 based on the vulnerability designation input received by the input management unit 223. The vulnerability candidate determining unit 224 can determine other software assets that are highly similar to software that contains a specific vulnerability and that may contain a similar vulnerability.

[0034] The search unit 225 is a functional unit that, based on the software asset management DB 231 stored in the memory unit 230 described below and the vulnerability candidate information generated by the vulnerability candidate determination unit 224, identifies software assets (third software assets) from among the software assets stored in the software asset management database 231 that satisfy the similarity criteria with the software assets (second software assets) indicated in the vulnerability candidate information and that may contain vulnerabilities similar to those in the vulnerability candidate information. The search unit 225 can determine whether or not a software asset that is determined to be a candidate for vulnerability and that may contain a vulnerability is being used by a specific client, for example.

[0035] The risk assessment unit 226 is a functional unit for calculating a risk assessment value that quantitatively indicates the risk of a vulnerability (for example, a first vulnerability indicated by a vulnerability specification input) to a software asset (a third software asset) that meets a similarity standard with respect to a software asset (a second software asset) indicated in the vulnerability-containing candidate information.

[0036] The result output unit 227 is a functional unit for generating evaluation result information indicating software assets (third software assets) that satisfy similarity criteria for the software assets (second software assets) indicated in the vulnerability candidate information and the risk evaluation value calculated by the risk evaluation unit 226, and outputting the information to the client terminal 270 described later, for example, via the input / output unit 246.

[0037] The storage unit 230 is a storage area that contains databases (hereinafter referred to as "DBs") for storing various types of information according to an embodiment of the present disclosure, and may include a software asset management unit DB231, a binary DB232, a software asset configuration information DB233, an SBOM DB234, and a vulnerability DB236, as shown in Fig. 2. In the present disclosure, the software asset management unit DB231, the binary DB232, the software asset configuration information DB233, the SBOM DB234, and the vulnerability DB235 stored in the storage unit 230 are collectively referred to as the "software asset databases." Details of the software asset management DB231, binary DB232, software asset configuration information DB233, SBOMDB234 and vulnerability DB235 stored in the memory unit 230 will be explained with reference to Figures 7 to 14, so they will not be explained here.

[0038] The processor 244 is a processing unit for executing processing instructions stored by the memory 220 that define the function of each functional unit of the vulnerability assessment application 150 .

[0039] The input / output unit 246 is a functional unit for accepting information input to the vulnerability assessment device 210 and outputting information such as result data generated by the vulnerability assessment device 210. In an embodiment, the input / output unit 246 may output, via the client terminal 270, an interface screen for accepting, from a user, a vulnerability designation input for designating a specific vulnerability in a specific software asset, and an interface screen for presenting to the user software assets that may include vulnerabilities and assessment result information indicating the risk assessment value of the software assets. In an embodiment, the input / output unit 246 may include, for example, a keyboard, a mouse, a display for displaying a GUI (Graphical User Interface), and the like.

[0040] The communications network 250 may include, for example, a local area network (LAN), a wide area network (WAN), a satellite network, a cable network, a WiFi network, or any combination thereof.

[0041] The external DB 260 is a database that stores public information related to vulnerabilities, weaknesses, attack methods, etc. of software assets. As shown in Fig. 2, the external DB 260 may include, for example, a CVE (Common Vulnerabilities and Exposure) DB 261 that indicates known vulnerabilities in software assets, a CWE (Common Weakness Enumeration) DB 262 that indicates known weaknesses in software assets, and a CAPEC (Common Attack Pattern Enumeration and Classification) DB 263 that indicates known attack methods against software assets.

[0042] As described above, the vulnerability management unit 221 can obtain vulnerability information used to generate the knowledge database according to an embodiment of the present disclosure by accessing the CVEDB 261, CWEDB 262, and CAPECDB 263 contained in the external DB 260.

[0043] The client terminal 270 is a terminal device that can be used by a user of the vulnerability assessment device 210. In one embodiment, this user may be a user of a software asset, and may be a client that requests the vulnerability assessment device 210 to determine whether or not a specific vulnerability exists in the software asset that is being used. By using the client terminal 270, a user can input vulnerability designation input for determining the presence or absence of a specific vulnerability to, for example, a GUI provided by the input / output unit 246, or can check assessment result information output from the vulnerability assessment device 210. As an example, the client terminal 270 may include, for example, a smartphone, a smartwatch, a tablet, a personal computer, etc., and is not particularly limited.

[0044] For ease of explanation, FIG. 2 illustrates an example of a configuration including one client terminal 270. However, in reality, in addition to the client terminal 270 used by the client, a configuration including a terminal that can be used by an organization (PSIRT: Product Security Incidence Response Team) that improves security levels and responds to incidents when they occur for products and services manufactured and developed by the client, or a configuration including multiple client terminals 270 is also possible.

[0045] According to the vulnerability assessment system 200 described above, even if configuration information regarding the components contained in the software is not provided, it is possible to determine whether or not the software has a specific vulnerability, and to determine software that is highly similar to software containing a specific vulnerability and may contain a similar vulnerability.

[0046] Next, with reference to FIG. 3, an overall flow of processing by the vulnerability assessment system according to an embodiment of the present disclosure will be described.

[0047] 3 is a diagram showing an example of an overall processing flow 300 by the vulnerability assessment system 200 according to an embodiment of the present disclosure. As described above, the vulnerability assessment system 200 according to an embodiment of the present disclosure is a system that executes processing for vulnerability assessment, and as shown in FIG. 3, the processing flow 300 by the vulnerability assessment system 200 includes a vulnerability candidate determination process 400 that determines software assets that may contain a specific vulnerability (hereinafter, vulnerability candidates), and a software asset verification process 500 that determines whether the determined vulnerability candidate is being used by a specific user (client, etc.). An overview of the overall processing flow 300 by the vulnerability assessment system 200 will be described with reference to FIG. 3, but details of the vulnerability candidate determination process 400 and the software asset verification process 500 will be described later with reference to FIGS. 5 and 6.

[0048] First, in step S301, the vulnerability management unit 221 of the vulnerability assessment apparatus 210 transmits a public vulnerability information acquisition request to the external DB 260 in order to acquire vulnerability information. The vulnerability management unit 221 may periodically transmit a public vulnerability information acquisition request to the external DB 260 at predetermined intervals (every day, every three days, or every week).

[0049] Next, in step S302, the vulnerability management unit 221 acquires the requested vulnerability information as a result of the request to acquire public vulnerability information sent in step S301. The vulnerability information here may include, for example, information regarding a specific software asset, such as CVEID indicating a specific vulnerability, CWEID indicating a specific weakness, CAPECID indicating a specific attack method, and CVSS (Common Vulnerability Scoring System) indicating the severity of these vulnerabilities, weaknesses, and attack methods. The vulnerability management unit 221 may store the acquired vulnerability information in, for example, the vulnerability DB 235 shown in FIG. 2.

[0050] Next, in step S303, the knowledge DB management unit 222 generates or updates a knowledge database indicating the relationship between software asset information (for example, information on software assets managed in the software asset management unit DB 231 shown in FIG. 2) and the acquired vulnerability information, based on the vulnerability information acquired in step S302. The knowledge DB management unit 222 may update the knowledge database every time it receives new vulnerability information that is not included in the knowledge database.

[0051] Next, in step S304, the client terminal 270 inputs to the vulnerability assessment apparatus 210 a vulnerability designation input that designates a first vulnerability in a first software asset, the presence or absence of which is to be confirmed.

[0052] Next, in step S305, the vulnerability management unit 221 sends an attribute acquisition request to the external DB 270 to acquire attributes related to the first software asset indicated by the vulnerability designation input received from the client terminal 270 (provider ID of the first software asset, software asset ID of the first software asset, package information of the first software asset, OS of the first software asset, CWEID or CAPECID related to the first vulnerability, etc.). Note that Figure 3 shows an example in which the vulnerability management unit 221 sends an attribute acquisition request to the external DB 260, but the present disclosure is not limited to this, and information regarding the attributes of software assets may also be acquired from an internal database that has been constructed in advance.

[0053] Next, in step S306, the vulnerability management unit 221 acquires the requested attribute information as a result of the attribute acquisition request sent in step S305.

[0054] Next, in step S307, the vulnerability management unit 221 sends a search request to the vulnerability candidate determination unit 224 for the knowledge database generated in step S303 based on the vulnerability specification input received in step S304 and the attribute information of the first software asset acquired in step S306.

[0055] Next, in step S308, the vulnerability candidate determining unit 224 searches the knowledge database based on the vulnerability specification input received in step S304 and the attribute information of the first software asset acquired in step S306.

[0056] Next, in step S309, the vulnerability candidate determination unit 224 obtains, as a result of the search performed in step S308, vulnerability candidate information indicating software assets having attribute information that meets a predetermined similarity standard with the attribute information of the first software asset, and second software assets that may contain the first vulnerability like the first software asset.

[0057] Next, in step S310, the risk assessment unit 226 calculates a risk assessment value indicating the severity of the vulnerability in the software asset (second software asset) indicated in the vulnerability candidate information acquired in step S309.

[0058] Next, in step S311, the risk assessment unit 226 transfers the risk assessment value calculated in step S310 to the vulnerability candidate determination unit 224.

[0059] Next, in step S312, the vulnerability candidate determining unit 224 transmits to the client terminal 270 the vulnerability candidate information acquired in step S309 and the risk assessment value transferred in step S311.

[0060] Next, in step S313, the client terminal 270 sends a software asset verification request to the vulnerability assessment device 210, requesting software asset verification to determine whether the vulnerability candidate determined in step S309 is being used by a specific user (client, etc.).

[0061] Next, in step S314, the search unit 225 performs software asset verification to determine whether the vulnerability candidate is being used by a specific user (client, etc.) based on the vulnerability candidate information acquired in step S309 and the software asset DB stored in the memory unit 230 (for example, information on the client's software assets managed in the software asset management unit DB 231 shown in Figure 2).

[0062] Next, in step S315, the search unit 225 determines, as a result of the software asset verification performed in step S314, a third software asset among the client's software assets managed in the software asset DB that matches the second software asset included in the vulnerability-containing candidate (i.e., satisfies a specified similarity standard).

[0063] Next, in step S316, the risk assessment unit 226 calculates a risk assessment value indicating the risk of the first vulnerability for the third software asset determined in step S315.

[0064] Next, in step S317, the risk assessment unit 226 transfers to the search unit 225 the risk assessment value calculated in step S316, which indicates the risk of the first vulnerability for the third software asset.

[0065] Next, in step S318, the search unit 225 generates evaluation result information indicating the third software asset determined in step S315 and the risk evaluation value calculated in step S316 via the result output unit 227 and the input / output unit 246, and transmits it to the client terminal 270.

[0066] According to the vulnerability assessment system 200 described above, even if configuration information regarding the components contained in the software is not provided, it is possible to determine whether or not the software has a specific vulnerability, and to determine software that is highly similar to software containing a specific vulnerability and may contain a similar vulnerability.

[0067] Next, with reference to FIG. 4, a vulnerability candidate determination process according to an embodiment of the present disclosure will be described.

[0068] 4 is a diagram showing an example of the flow of a vulnerability candidate determination process 400 according to an embodiment of the present disclosure. The vulnerability candidate determination process 400 is a process for determining software assets that contain specific vulnerabilities (hereinafter, vulnerability candidates), and is performed by the vulnerability management unit 221, knowledge database management unit 222, input management unit 223, and vulnerability candidate determination unit 224 shown in FIG.

[0069] First, in step S402, the vulnerability management unit 221 of the vulnerability assessment device 210 acquires vulnerability information from the external DB 260. Here, the vulnerability management unit 221 may acquire, as vulnerability information, information on vulnerabilities, weaknesses, and attack patterns related to each software asset managed in the software asset management unit DB 231 by transmitting a public vulnerability information acquisition request to the CVEDB 261, CWE 262, and CAPEC DB 263 to acquire vulnerability information indicating known vulnerabilities for each software asset (e.g., software asset to be determined for the presence or absence of vulnerabilities) managed in the software asset management unit DB 231 shown in Fig. 2, for example.

[0070] Next, in step S404, the knowledge database management unit 222 generates a knowledge database showing the relationship between software asset information (for example, information on software assets managed in the software asset management unit DB231 shown in Figure 2) and the acquired vulnerability information based on the vulnerability information acquired in step S402.

[0071] Here, to generate the knowledge database, first, the knowledge database management unit 222 executes a predetermined named entity recognition (NER) method on the vulnerability information acquired in step S402 to extract a first named entity related to the software asset and a second named entity related to the vulnerability in the vulnerability information. More specifically, the knowledge database management unit 222 may extract information related to the software asset name, version name, provider name, and OS (Operating System) as the first named entity, and may extract information related to the vulnerability name, attack method name, weakness name, CVEID, CWEID, CAPECID, and damage as the second named entity. This named entity recognition may be performed manually or by machine learning techniques.

[0072] Next, the knowledge database management unit 222 extracts information about the relationships between the extracted named entities by applying a predetermined relationship extraction method to the vulnerability information, thereby obtaining information in the form of "noun-verb-noun" (triplet information). By associating the acquired information on named entities and information on their relationships based on their respective logical relationships, it is possible to generate a knowledge database such as those shown in Figures 6 and 7. Furthermore, the knowledge database management unit 222 may aggregate and configure the knowledge database using so-called STIX (Structured Threat Information Expression).

[0073] Next, in step S406, the input management unit 223 receives a vulnerability designation input that designates a first vulnerability in the first software asset from the client terminal 270. This vulnerability designation input may include, for example, information that specifies a CVEID that identifies a specific vulnerability (i.e., a vulnerability whose presence or absence is to be determined in the software asset being used).

[0074] Next, in step S408, the vulnerability-containing candidate determination unit 224 searches the knowledge database generated in step S404 based on the vulnerability specification input received in step S406 to determine a second software asset that may contain the first vulnerability specified in the vulnerability specification input, and generates vulnerability-containing candidate information indicating the determined second software asset.

[0075] The details of the process of searching the knowledge database will be described with reference to steps S409 to S411 shown in FIG. First, in step S409, the vulnerability candidate determination unit 224 determines attribute information indicating software asset attributes that characterize the first software asset indicated in the vulnerability designation input received in step S406 (i.e., the software asset containing a known vulnerability). This attribute information may include, for example, the provider ID of the first software asset, the software asset ID of the first software asset, package information of the first software asset, the OS of the first software asset, the function of the first software asset, the API, code, software module used in the first software asset, etc. In an embodiment, the vulnerability candidate determination unit 224 may obtain the attribute information of the first software asset from the external DB 260 or from software asset information pre-stored in the storage unit 230.

[0076] Next, in step S410, the vulnerability candidate determination unit 224 generates a search query based on the attribute information of the first software asset acquired in step S409. This search query is a search query for identifying other software assets in the knowledge database that satisfy a similarity criterion for the attribute information of the first software asset. In one embodiment, the vulnerability candidate determination unit 224 may generate this search query in a query language capable of generating queries in the (noun-verb-noun) format, such as Neo4j (registered trademark)'s "Cypher" (registered trademark). As an example, the vulnerability candidate determining unit 224 may generate a search query of "MATCH (:product {name: 'XYZ'})-[:contains]->(package:'ABC')". When multiple pieces of attribute information related to the first software asset are acquired, the vulnerability candidate determining unit 224 may generate different search queries for each attribute.

[0077] Next, in step S411, the vulnerability candidate determination unit 224 performs a search of the knowledge database using the search query generated in step S410. As described above, by searching the knowledge database using the search query generated based on the attribute information of the first software asset, it is possible to identify a second software asset that matches the attributes of the first software asset. Then, the second software asset that matches the attributes of the first software asset may contain the first vulnerability, just like the first software asset. Therefore, the second software asset is determined to be a vulnerability candidate, and by performing the software asset verification process 500 described below, it is possible to avoid damage caused by cyber-attacks that exploit vulnerabilities.

[0078] Next, in step S412, the risk assessment unit 226 calculates and outputs a risk assessment value for a vulnerability (first vulnerability) in the software asset (second software asset) indicated in the vulnerability candidate information generated in step S408. Here, the risk assessment unit 226 may calculate the risk assessment value based on the probability that the second software asset contains the first vulnerability, the importance or severity of the first vulnerability for the second software asset, the number of software assets affected by the first vulnerability, the resistance of a system that uses the second software asset to the first vulnerability, the extent of impact of the first vulnerability in the supply chain, etc.

[0079] Next, with reference to FIG. 5, a software asset verification process according to an embodiment of the present disclosure will be described.

[0080] 5 is a diagram showing an example of the flow of a software asset verification process 500 according to an embodiment of the present disclosure. The software asset verification process 500 is a process for determining whether a vulnerability candidate determined in the vulnerability candidate determination process 400 described with reference to FIG. 4 is being used by a specific user (such as a client), and is performed by a search unit 225, a risk assessment unit 226, and a result output unit 227.

[0081] First, in step S502, the search unit 225 identifies a third software asset from among the software assets whose information is stored in the software asset management unit DB231 shown in Figures 2 and 8, etc., that meets the similarity criteria for a second software asset that is a vulnerability candidate that may contain the first vulnerability.

[0082] In the present disclosure, the term "similarity criterion" refers to information for determining whether different software assets (e.g., a first software asset and a second software asset, or a second software asset and a third software asset) are substantially similar, and may be, for example, a similarity threshold calculated using a Euclidean distance or cosine distance calculation method.

[0083] The search unit 225 may use natural language based search, software code based search, software bill of materials based search, and binary based search to search for a third software asset that meets similarity criteria to the second software asset.

[0084] For example, in one embodiment, the search unit 225 may use a predetermined natural language processing method to identify, as the third software asset, a software asset that satisfies a similarity criterion for the software asset ID (such as the name of the software asset) of the second software asset among the software assets in the software asset management database 231. Here, the search unit 225 may obtain the software asset ID of the second software asset from the software asset management database 231.

[0085] In addition, in one embodiment, the search unit 225 may extract a source code portion that is a part of the source code from the second software asset, and use a predetermined code comparison method to identify, as the third software asset, a software asset among the software assets in the software asset management database 231 that satisfies a similarity criterion for the source code portion of the second software asset.

[0086] In addition, in one embodiment, the search unit 225 may identify, as the third software asset, a software asset in the software asset management database 231 that satisfies a similarity criterion for the software bill of materials of the second software asset stored in the SBOMDB shown in Figures 2 and 9.

[0087] Furthermore, in one embodiment, the search unit 225 may identify, as a third software asset, a software asset in the software asset management database 231 that satisfies a similarity criterion for the binary data of the second software asset stored in the binary DB 232 shown in Figures 2 and 10.

[0088] In this way, by performing a search based on natural language, source code, software bill of materials, and binary, a third software asset that substantially resembles a second software asset that is a vulnerability candidate and may contain a first vulnerability can be identified, for example, from among software assets used by a specific client.

[0089] Next, in step S504, the risk assessment unit 226 calculates a risk assessment value indicating the risk of the first vulnerability for the third software asset identified in step S502.

[0090] In one embodiment, the risk assessment value may be a value indicating the probability that the third software asset includes the first vulnerability. In this case, the risk assessment unit 226 may calculate the probability that the third software asset includes the first vulnerability based on the similarity of the second software asset to the first software asset, the second similarity to the third software asset, etc., and use this as the risk assessment value.

[0091] In one embodiment, the risk assessment value may be a value indicating the importance or severity of the first vulnerability with respect to the third software asset. In this case, the risk assessment unit 226 may calculate a CVSS (Common Vulnerability Scoring System) score that quantitatively indicates the impact of the first vulnerability on the confidentiality, integrity, and availability of the third software asset, and use this as the risk assessment value.

[0092] Furthermore, in one embodiment, the risk assessment unit 226 may calculate the risk assessment value based on the number of software assets affected by the first vulnerability (i.e., the number of third software assets), the number of companies or organizations that use the third software assets, and the scope of impact of the first vulnerability in the supply chain.

[0093] Next, in step S506, the risk assessment unit 226 generates assessment result information indicating the third software asset identified in step S502 and the risk assessment value calculated in step S504, and may provide this to the client terminal 270, for example, via the input / output unit 246 or communication network 250 shown in Fig. 2. Details of this assessment result information will be described with reference to Figs. 16 and 17, and therefore will not be described here.

[0094] 5, it is possible to determine whether a third software asset that is substantially similar to a software asset containing a first vulnerability specified by a user such as a client and corresponds to a second software asset (a vulnerability candidate) that may contain the first vulnerability is currently being used by the client. In this way, by identifying software assets that may contain a specific vulnerability among the software assets currently in use, the user can prepare measures to eliminate the vulnerability or to mitigate damage, thereby improving cybersecurity.

[0095] Next, the configuration of a knowledge database according to an embodiment of the present disclosure will be described with reference to Figures 6 and 7. As described above, one aspect of the present disclosure relates to performing vulnerability assessment based on a knowledge database that indicates the relationship between software asset information and vulnerability information. This knowledge database may be configured in a graph format or a table format.

[0096] FIG. 6 is a diagram illustrating an example of a knowledge database 600 in a graph format according to an embodiment of the present disclosure.

[0097] As shown in FIG. 6, the graph-style knowledge database 600 may be a data structure that shows, in a graph format consisting of nodes and edges, dependencies between information such as a specific software asset 606 identified by, for example, a name or software asset ID, a version 604 of the software asset, an OS 608 for the software asset, a provider 602 of the software asset, a package 610 including the software asset, a software version 612 of the package, a vulnerability 614 of the package, a CVEID 616 for the vulnerability, damage caused by the vulnerability 618, weaknesses related to the vulnerability 620 and their CWEIDs 622, an attack method for the vulnerability 624 and a CAPECID 626 for the attack method, etc.

[0098] This graph-based knowledge database 600 can be searched by a search query in the form of (noun-verb-noun) generated in a query language such as the above-mentioned "Cypher."

[0099] FIG. 7 is a diagram illustrating an example of a knowledge database 700 in a tabular format according to an embodiment of the present disclosure.

[0100] As shown in FIG. 7, the tabular knowledge database 700 may be a data structure that displays, for example, for a given software asset 702, information regarding the provider 704, version 706, vulnerability candidates 708 that may contain the same vulnerability, technical classification 710, application field 712, CVEID 714, attack method 716, OS 718, CWE 720, and CAPEC ID 722 in a tabular format consisting of rows and columns. This tabular knowledge database 700 is searchable by search queries formulated in existing table query languages.

[0101] 6 and 7, a search using a search query based on the attributes of a specific software asset (such as the provider, package, or software asset name) enables a similarity comparison based on the attributes of the software asset. This makes it possible to determine whether or not a specific vulnerability exists in the software, and to identify software that is highly similar to software that contains a specific vulnerability and is likely to contain a similar vulnerability, even if configuration information about components included in the software is not provided.

[0102] Next, with reference to FIG. 8, the software asset management unit DB according to the embodiment of the present disclosure will be described.

[0103] 8 is a diagram illustrating an example of a software asset management unit DB231 according to an embodiment of the present disclosure. The software asset management unit DB231 according to an embodiment of the present disclosure is a database for storing information about software assets that are the subject of vulnerability assessment, and may include information such as a software asset ID 801, a version ID 802, a user ID 803, and a provider ID 804, as shown in the software asset management unit DB231.

[0104] The software asset ID 801 is information that uniquely identifies a specific software asset, and may be a string of characters such as "P1," "P2," or "P3," as shown in FIG. 8, or may be the name of the software asset.

[0105] The version ID 802 is information indicating the software version of a particular software asset, and may be "V1," "V2," "V3," etc., as shown in FIG.

[0106] User ID 803 is information that uniquely identifies the user of a specific software asset, and may be a character string such as "O1," "O2," or "O3," as shown in Fig. 8, or the user's company name, name, etc. The user here may be, for example, a client requesting a vulnerability assessment of their own software asset (i.e., the user of client terminal 270 shown in Fig. 2).

[0107] The provider ID 804 is information that uniquely identifies the provider (also called the vendor) that provides a specific software asset to the user, and may be a string of characters such as "S1," "S2," or "S3," as shown in Figure 8, or the provider's company name or name, etc.

[0108] In the above-mentioned software asset verification process 500, the search unit 225 analyzes the information stored in the software asset management unit DB231 using a predetermined natural language processing method, and can identify, among the software assets in the software asset management database 231, software assets that satisfy the similarity criteria with respect to the second software asset as the third software asset.

[0109] Next, the SBOMDB according to an embodiment of the present disclosure will be described with reference to FIG.

[0110] 9 is a diagram illustrating an example of the SBOMDB 234 according to an embodiment of the present disclosure. The SBOMDB 234 according to an embodiment of the present disclosure is a database for storing a software bill of materials of a software asset to be subjected to vulnerability assessment, and may include information such as a component ID 902, a version ID 904, a license 906, a file path 908, and a security score 910, as shown in FIG. A software bill of materials is information that indicates the software components (proprietary and open source, etc.) included in a particular product, their licenses, and their dependencies.

[0111] A component ID is information for uniquely identifying each software component included in a particular software asset, and may be a string of characters such as "C1," "C2," or "C3," as shown in Figure 9, or the name of the software component.

[0112] The version ID 904 is information indicating the software version of the software component, and may be expressed as, for example, "2.0," "1.2.1," "6.0," etc., as shown in FIG.

[0113] License 906 is information indicating the license related to the software component, and may be "MIT" or "BSD-3-Clause" as shown in FIG.

[0114] The file path 908 is information indicating the file path where the software component is stored in a predetermined storage area, and may be, for example, "demo1 / example" as shown in FIG.

[0115] The security score 910 is information that quantitatively indicates the evaluation of the security level of the software component, and may be, for example, "90," "80," "40," etc., as shown in FIG.

[0116] In the above-mentioned software asset verification process 500, the search unit 225 can use the information stored in the SBOMDB 234 to identify, as the third software asset, a software asset in the software asset management database 231 that satisfies the similarity criteria with respect to the software bill of materials of the second software asset.

[0117] Next, a binary DB according to an embodiment of the present disclosure will be described with reference to FIG.

[0118] 10 is a diagram illustrating an example of the configuration of the binary DB 232 according to an embodiment of the present disclosure. The binary DB 232 according to an embodiment of the present disclosure is a database for storing binary data of software assets to be subjected to vulnerability assessment, and may include a file ID 1002, a creation date and time 1004, a modification date and time 1006, and a size 1008 indicating the binary file of the software asset, as shown in FIG.

[0119] The file ID 1002 is information that uniquely identifies a binary file of a specific software asset, and may be expressed as, for example, "F1," "F2," "F3," etc., as shown in FIG. The creation date and time 1004 indicates the date and time when a particular binary file was created, and the modification date and time indicates the date and time when a created binary file was modified. As shown in Figure 10, the creation date and time 1004 and modification date and time 1006 may be in YYYY / MM / DD format. The size 1008 is information indicating the file size of the binary file in kilobytes (KB), for example.

[0120] In the above-mentioned software asset verification process 500, the search unit 225 can use the information stored in the binary DB 232 to identify, as the third software asset, a software asset in the software asset management database 231 that satisfies the similarity criteria for the binary data of the second software asset. SBOMDB234

[0121] Next, a vulnerability DB according to an embodiment of the present disclosure will be described with reference to FIG.

[0122] 11 is a diagram illustrating an example of the configuration of the vulnerability DB 235 according to an embodiment of the present disclosure. The vulnerability DB 235 according to an embodiment of the present disclosure is a database that stores vulnerability information related to software assets that are the subject of vulnerability assessment (for example, software assets whose information is stored in the software asset management DB 231 shown in FIG. 2 or FIG. 8), and may include a vulnerability ID 1102, a CVE ID 1104, a CWE ID 1106, a software asset ID 1108, and a CVSS 1110, as shown in FIG. The information stored in the vulnerability DB 235 shown in FIG. 11 may be acquired from an external DB 260 such as the CVEDB 261, the CWEDB 262, or the CAPECDB 263 shown in FIG.

[0123] The vulnerability ID 1102 is information that uniquely identifies a specific vulnerability in the vulnerability DB 235, and may be expressed as a character string such as "2351" or "48521" as shown in FIG.

[0124] CVEID 1104 is information that uniquely identifies a known vulnerability in a software asset in the above-mentioned CVEDB 261, and may be expressed as a string in the format "CVE-2022-XXXX" as shown in FIG.

[0125] The CWEID 1106 is information that uniquely identifies a known weakness in a software asset in the above-mentioned CWEDB 262, and may be expressed as information in the "XXX" format as shown in FIG.

[0126] The software asset ID 1108 is information for uniquely identifying a software asset associated with a specific vulnerability ID 1102, CVEID 1104, CWEID 1106, and CVSS 1110, and may be a string of characters such as "P1," "P2," or "P3," as shown in FIG. 11, or may be the name of the software asset.

[0127] CVSS1110 is information indicating the severity of vulnerabilities, weaknesses, attack methods, etc. related to a specific software asset, and may be "5.5" or "9.7" as shown in Fig. 11. In one embodiment, this CVSS1110 is a value associated with a specific vulnerability, and may be obtained from the external DB260.

[0128] Next, with reference to FIG. 12, a software asset configuration information DB according to an embodiment of the present disclosure will be described.

[0129] 12 is a diagram showing an example of the configuration of the software asset configuration information DB 233 according to an embodiment of the present disclosure. As described above, the software asset configuration information DB 233 according to an embodiment of the present disclosure is a database that stores configuration information related to software assets that are the subject of vulnerability assessment (for example, software assets whose information is stored in the software asset management DB 231 shown in FIG. 2 or FIG. 8), and may include information related to a file name 1202, a file size 1204, a file type 1206, file permissions 1208, and an owner 1210, as shown in FIG.

[0130] The file name 1202 is a file name that identifies a configuration file related to a specific software asset, and may be a character string such as "2351" as shown in FIG. The file size 1204 is information indicating the file size of a configuration file relating to a specific software asset, for example, in kilobytes (KB). The file type 1206 is information indicating the type of configuration file related to a specific software asset, and may be, for example, "PHP" or "HTACCESS" as shown in FIG.

[0131] The file permissions 1208 are information indicating permissions for access such as reading and writing, which are defined for each configuration file related to a specific software asset, and may be, for example, "-rwx-xr-x" or "-rw-rr--", as shown in FIG. 12. The owner 1210 is information indicating the owner of the configuration file related to a specific software asset, and may be, for example, "Root" as shown in FIG.

[0132] In the above-mentioned software asset verification process 500, the search unit 225 can use the information stored in the software asset configuration information DB 233 to identify, as the third software asset, a software asset in the software asset management database 231 that satisfies the similarity criteria with respect to the configuration data of the second software asset.

[0133] Next, vulnerability candidate information according to an embodiment of the present disclosure will be described with reference to FIG.

[0134] 13 is a diagram illustrating an example of the configuration of vulnerability candidate information 1300 according to an embodiment of the present disclosure. The vulnerability candidate information 1300 according to an embodiment of the present disclosure is information related to a second software asset that may contain a first vulnerability specified by a user, and is generated by the vulnerability candidate determination process 400 described with reference to FIG. As shown in FIG. 13 , vulnerability candidate information 1300 may include a CVE ID 1302, a software asset ID 1304, a provider 1306, a service type 1308, code / library 1310, a CWE ID 1312, a technical classification 1314, a vulnerability candidate 1316, a risk assessment value 1318, and an application field 1320.

[0135] CVEID 1302 is information that uniquely identifies a vulnerability in a specific software asset, and may be, for example, "CVE-2022-XXXX" as shown in Fig. 13. This CVEID 1302 may be, for example, the CVEID indicated in the vulnerability specification input described above.

[0136] The software asset ID 1304 includes the vulnerability identified by the CVEID 1302 and is information that identifies the software asset (first software asset) indicated in the vulnerability specification input described above. For example, as shown in FIG. 13, the software asset ID 1304 may be a string of characters such as "P1," "P2," or "P3," or may be the name of the software asset.

[0137] The provider 1306 is information indicating the provider (vendor, supplier) who provides the software asset, and may be, for example, "V1," "V2," "V3," etc. as shown in FIG. The service type 1308 is information indicating the type of service related to the software asset, and may be, for example, "S1," "S2," "S3," etc. as shown in FIG. The code / library 1310 is information indicating the code or library of the software asset, and may be "C1," "C2," "C3," etc., as shown in FIG.

[0138] CWEID 1312 is information that uniquely identifies a vulnerability in a specific software asset, and may be, for example, "276" as shown in Figure 13. This CWEID 1312 may be, for example, the CWEID indicated in the vulnerability specification input described above, or may be obtained from the external DB 260.

[0139] The technical classification 1314 is information indicating the technical classification of the software asset, and may be, for example, "SSL" or "REST API" as shown in FIG. 13.

[0140] The vulnerability candidate 1316 is information indicating other software assets that may contain the vulnerability specified by the CVEID 1302, similar to the software asset identified by the software asset ID 1304, and may be, for example, "P23," "P17," "P103," etc., as shown in Fig. 13. The vulnerability candidate 1316 may be determined by the vulnerability candidate determination process 400 described with reference to Fig. 4, for example.

[0141] The risk assessment value 1318 is a value that quantitatively indicates the risk of a specific vulnerability for a specific software asset, and as described above, may be calculated based on the probability that a specific software asset contains a specific vulnerability, the importance or severity of the specific vulnerability for a specific software asset, the number of software assets affected by the specific vulnerability, the resistance of a system that uses the specific software asset to vulnerabilities, the scope of impact of the specific vulnerability in the supply chain, etc.

[0142] The application field 1320 is information indicating the application field in which the software asset can be used, and may be, for example, "automotive industry" or "IT web server" as shown in FIG.

[0143] The vulnerability candidate information 1300 described with reference to FIG. 13 may be used, for example, in the software asset verification process 500 described above, to determine a third software asset that meets the similarity criteria for a second software asset that is a candidate for vulnerability and may contain a vulnerability.

[0144] Next, evaluation result information according to an embodiment of the present disclosure will be described with reference to FIG.

[0145] 14 is a diagram showing a configuration of evaluation result information 1400 according to an embodiment of the present disclosure. The evaluation result information 1400 according to an embodiment of the present disclosure is information indicating the presence or absence of a specific vulnerability (not illustrated in FIG. 14) and a risk evaluation value for each software asset that is the target of vulnerability evaluation (for example, software assets whose information is stored in the software asset management DB 231 shown in FIG. 2 or FIG. 8), and may be generated by the software asset verification process 500 described with reference to FIG. 5. As shown in FIG. 14, the evaluation result information 1400 may include a software asset ID 1402 , a vulnerability presence / absence 1404 , and a risk evaluation value 1406 .

[0146] The software asset ID 1402 is information that uniquely identifies the software asset that is the subject of vulnerability assessment (for example, a software asset whose information is stored in the software asset management DB 231 shown in Figures 2 and 8), and may be, for example, a character string such as "P3," "P43," or "P18," as shown in Figure 14, or the name of the software asset.

[0147] Vulnerability presence / absence 1404 is information indicating the presence or absence of a specific vulnerability for each software asset identified by the software asset ID 1402, and may be, for example, "YES" or "NO" as shown in Fig. 14. The presence or absence of a vulnerability here may be determined by the software asset verification process 500 described with reference to Fig. 5.

[0148] The risk assessment value 1406 is information that quantitatively indicates the risk posed by a vulnerability for each software asset identified by the software asset ID 1402, and may be, for example, "7.2" or "10" as shown in Fig. 14. This risk assessment value may be calculated in step S504 of the software asset verification process 500 described with reference to Fig. 5, and, as described above, may be a value that indicates the probability that a specific software asset contains a specific vulnerability, or may be a value that indicates the importance or seriousness of the vulnerability for the software asset.

[0149] As described above, by providing the evaluation result information 1400 shown in Figure 4 to the client, the provider can easily identify which software assets in use by the provider may contain specific vulnerabilities.

[0150] As mentioned above, with the increasing number of new vulnerabilities discovered and new attack methods emerging, understanding the cybersecurity status of software assets in use has become an important concern for society and organizations. Although there are methods for analyzing the components that make up software assets and determining whether they have vulnerabilities, configuration information about the components included in the software is generally not provided to end users such as clients, which limits the applicability of traditional vulnerability assessment methods and sometimes makes it impossible to determine whether software has vulnerabilities.

[0151] Therefore, in the vulnerability assessment means according to an embodiment of the present disclosure, a search query generated based on attribute information of a software asset containing a specific vulnerability is used to search a knowledge database showing the relationship between software asset information and public vulnerability information, thereby identifying other software assets that match the attributes of the software asset as candidates for vulnerability that may contain the same vulnerability. The knowledge database information and software asset attribute information used in this search can be obtained even if proprietary configuration information about the components of the software asset is not provided, making it possible to perform reliable vulnerability assessment even if, for example, configuration information about the components included in the software is not provided.

[0152] Furthermore, the vulnerability assessment means according to an embodiment of the present disclosure identifies vulnerability candidates that are substantially similar to software assets containing a specific vulnerability specified by a user such as a client and that may contain the same vulnerability, and then identifies software assets that meet the similarity criteria for the vulnerability candidates among the software assets used by a specified client, thereby enabling the client to prepare measures to eliminate the vulnerability or to mitigate damage, thereby improving cybersecurity.

[0153] In this way, according to the vulnerability assessment means of the embodiment of the present disclosure, even if configuration information regarding the components contained in the software is not provided, it is possible to provide a vulnerability assessment means that can determine whether or not the software has a specific vulnerability, and can determine software that is highly similar to software that contains a specific vulnerability and may contain a similar vulnerability.

[0154] As described above, the vulnerability assessment means according to the embodiment of the present disclosure includes the following aspects.

[0155] (Aspect 1) A vulnerability assessment device, A processor, a memory, and a storage unit are provided, The storage unit a software asset database that stores software asset information that characterizes the software assets; The memory controls the processor a vulnerability management unit that acquires vulnerability information that characterizes vulnerabilities related to the software assets; a knowledge database management unit that generates a knowledge database that indicates the relationship between the software asset information and the vulnerability information; an input management unit that receives a vulnerability designation input that designates a first vulnerability in a first software asset; a vulnerability candidate determination unit that searches the knowledge database based on the vulnerability specification input to generate vulnerability candidate information indicating a second software asset that may contain the first vulnerability; A vulnerability assessment device comprising a processing instruction for causing the device to function as a vulnerability assessment device.

[0156] (Aspect 2) The software asset database includes: a software asset management database including at least a software asset ID for identifying a software asset and a user ID for identifying a user of the software asset; The vulnerability assessment device a search unit that identifies, for each user ID, a third software asset that satisfies a similarity standard with respect to the second software asset among the software assets in the software asset management database based on the software asset management database and the vulnerability candidate information; a risk assessment unit that calculates a risk assessment value indicating a risk of the first vulnerability to the third software asset; a result output unit that generates and outputs evaluation result information indicating the third software asset and the calculated risk evaluation value; 2. The vulnerability assessment device according to aspect 1, further comprising:

[0157] (Aspect 3) The search unit using a predetermined natural language processing method, identifying, from among the software assets in the software asset management database, a software asset that satisfies a similarity criterion for the software asset ID of the second software asset as the third software asset; 3. The vulnerability assessment device according to aspect 2.

[0158] (Aspect 4) The search unit extracting a source code portion from the second software asset; using a predetermined code comparison technique, identifying, as the third software asset, a software asset in the software asset management database that satisfies a similarity criterion for the source code portion of the second software asset; 4. The vulnerability assessment device according to aspect 2 or 3.

[0159] (Aspect 5) The software asset database includes: an SBOM database showing a software bill of materials for the software assets; The search unit Identifying, among the software assets in the software asset management database, software assets that satisfy a similarity criterion for the software bill of materials of the second software asset as the third software asset; 5. The vulnerability assessment device according to any one of aspects 2 to 4.

[0160] (Aspect 6) The software asset database includes: a binary database representing binary data of the software assets; The search unit Identifying, among the software assets in the software asset management database, a software asset that satisfies a similarity criterion for the binary data of the second software asset as the third software asset; 6. The vulnerability assessment device according to any one of aspects 2 to 5.

[0161] (Aspect 7) The vulnerability candidate determination unit determining software asset attributes characterizing the first software asset; generating a search query for searching the knowledge database based on the software asset attributes; searching the knowledge database based on the search query to determine software assets that satisfy a similarity criterion for the software asset attribute, and determining the software asset that satisfies the similarity criterion for the software asset attribute as the second software asset that may contain the first vulnerability; 7. The vulnerability assessment device according to any one of aspects 1 to 6.

[0162] (Aspect 8) The software asset attributes include: The information includes any one of a provider ID of the first software asset, a software asset ID of the first software asset, and package information of the first software asset. 8. The vulnerability assessment device according to aspect 7.

[0163] (Aspect 9) The knowledge database management unit extracting a first named entity related to a software asset and a second named entity related to a vulnerability in the vulnerability information by executing a predetermined named entity recognition method on the vulnerability information; extracting relationship information regarding a relationship between the extracted first named entity and the extracted second named entity by executing a predetermined relationship extraction method on the vulnerability information; generating the knowledge database by associating the first named entity with the second named entity based on the relationship information; 9. The vulnerability assessment device according to any one of aspects 1 to 8.

[0164] Although the embodiments of the present invention have been described above, the present invention is not limited to the above-described embodiments, and various modifications are possible within the scope of the gist of the present invention. [Explanation of symbols]

[0165] 150 Vulnerability Assessment Applications 200 Vulnerability Assessment System 210 Vulnerability Assessment Device 220 memory 221 Vulnerability Management Department 222 Knowledge Database Management Department 223 Input Management Unit 224 Vulnerability candidate determination section 225 Search Department 226 Risk Assessment Department 227 Result output section 230 Storage section 231 Software Asset Management Database 232 Binary Database 233 Software Asset Configuration Information Database 234 SBOM database 235 Vulnerability Database 244 processors 246 Input / output section 250 Communication Network 260 External Databases 270 client terminals

Claims

1. A vulnerability assessment device, A processor, a memory, and a storage unit are provided, The storage unit a software asset database that stores software asset information that characterizes the software assets; The memory controls the processor a vulnerability management unit that acquires vulnerability information that characterizes vulnerabilities related to the software assets; a knowledge database management unit that generates a knowledge database that indicates the relationship between the software asset information and the vulnerability information; an input management unit that receives a vulnerability designation input that designates a first vulnerability in a first software asset; a vulnerability candidate determination unit that searches the knowledge database based on the vulnerability specification input to generate vulnerability candidate information indicating a second software asset that may contain the first vulnerability; A vulnerability assessment device comprising a processing instruction for causing the device to function as a vulnerability assessment device.

2. The software asset database includes: a software asset management database including at least a software asset ID for identifying a software asset and a user ID for identifying a user of the software asset; The vulnerability assessment device a search unit that identifies, for each user ID, a third software asset that satisfies a similarity standard with respect to the second software asset among the software assets in the software asset management database based on the software asset management database and the vulnerability candidate information; a risk assessment unit that calculates a risk assessment value indicating a risk of the first vulnerability with respect to the third software asset; a result output unit that generates and outputs evaluation result information indicating the third software asset and the calculated risk evaluation value; The vulnerability assessment device according to claim 1 , further comprising:

3. The search unit using a predetermined natural language processing method, identifying, from among the software assets in the software asset management database, a software asset that satisfies a similarity criterion for the software asset ID of the second software asset as the third software asset; The vulnerability assessment device according to claim 2 .

4. The search unit extracting a source code portion from the second software asset; using a predetermined code comparison method, identifying, as the third software asset, a software asset in the software asset management database that satisfies a similarity criterion for the source code portion of the second software asset; The vulnerability assessment device according to claim 2 .

5. The software asset database includes: an SBOM database showing a software bill of materials for the software assets; The search unit identifying, as the third software asset, a software asset that satisfies a similarity criterion for the software bill of materials of the second software asset among the software assets in the software asset management database; The vulnerability assessment device according to claim 2 .

6. The software asset database includes: a binary database representing binary data of the software assets; The search unit identifying, as the third software asset, a software asset that satisfies a similarity criterion for the binary data of the second software asset among the software assets in the software asset management database; The vulnerability assessment device according to claim 2 .

7. The vulnerability candidate determination unit determining software asset attributes characterizing the first software asset; generating a search query for searching the knowledge database based on the software asset attributes; searching the knowledge database based on the search query to determine software assets that satisfy a similarity criterion for the software asset attribute, and determining the software asset that satisfies the similarity criterion for the software asset attribute as the second software asset that may contain the first vulnerability; The vulnerability assessment device according to claim 1 .

8. The software asset attributes include: the information includes any one of a provider ID of the first software asset, a software asset ID of the first software asset, and package information of the first software asset; The vulnerability assessment device according to claim 7 .

9. The knowledge database management unit extracting a first named entity related to a software asset and a second named entity related to a vulnerability in the vulnerability information by executing a predetermined named entity recognition method on the vulnerability information; extracting relationship information regarding a relationship between the extracted first named entity and the extracted second named entity by executing a predetermined relationship extraction method on the vulnerability information; generating the knowledge database by associating the first named entity with the second named entity based on the relationship information; The vulnerability assessment device according to claim 1 .

10. A client terminal; a vulnerability assessment device for assessing vulnerabilities in software assets; A vulnerability assessment system connected via a communication network to a public vulnerability database that stores information about known vulnerabilities, The vulnerability assessment device A processor, a memory, and a storage unit are provided, The storage unit a software asset database that stores software asset information that characterizes the software assets; The memory controls the processor a vulnerability management unit that acquires vulnerability information characterizing vulnerabilities related to the software assets from the public vulnerability database; a knowledge database management unit that generates a knowledge database that indicates the relationship between the software asset information and the vulnerability information; an input management unit that receives a vulnerability designation input that designates a first vulnerability in a first software asset; a vulnerability candidate determination unit that searches the knowledge database based on the vulnerability specification input to generate vulnerability candidate information indicating a second software asset that may contain the first vulnerability, and transmits the vulnerability candidate information to the client terminal; A vulnerability assessment system comprising a processing instruction for causing the system to function as a vulnerability assessment system.

11. 1. A vulnerability assessment method, comprising: constructing a software asset database that stores software asset information that characterizes the software assets; obtaining vulnerability information characterizing vulnerabilities related to the software asset; extracting a first named entity related to a software asset and a second named entity related to a vulnerability in the vulnerability information by executing a predetermined named entity recognition method on the vulnerability information; extracting relationship information regarding a relationship between the extracted first named entity and the extracted second named entity by executing a predetermined relationship extraction method on the vulnerability information; generating a knowledge database indicating the relationship between the software asset information and the vulnerability information by associating the first named entity with the second named entity based on the relationship information; receiving a vulnerability designation input that designates a first vulnerability in a first software asset; determining software asset attributes characterizing the first software asset; generating a search query for searching the knowledge database based on the software asset attributes; searching the knowledge database based on the search query to determine software assets that satisfy a similarity criterion for the software asset attribute, and determining the software assets that satisfy the similarity criterion for the software asset attribute as second software assets that may contain the first vulnerability; generating vulnerability candidate information indicating the second software asset; a step of identifying a third software asset that satisfies a similarity standard with respect to the second software asset from among the software assets in the software asset database based on the software asset database and the vulnerability candidate information; calculating a risk assessment value indicating a risk of the first vulnerability to the third software asset; generating and outputting evaluation result information indicating the third software asset and the calculated risk evaluation value; A vulnerability assessment method comprising:

Images