Vulnerability impact evaluation support device and vulnerability impact evaluation support method

Abstract

To support the evaluation of the impact of vulnerabilities in an information processing system composed of sub systems built in different environments on each sub system.SOLUTION: A vulnerability impact evaluation support device 40 comprises: a memory device that stores software component information, the software component information being information about software that constitutes each of a plurality of subsystems constructed in different environments that constitute an information processing system; and a control device that creates extended software component information including information about a second subsystem that is affected by a processing impact caused by a vulnerability in software of a first subsystem within the information processing system, identifies other subsystems that are affected by a processing impact caused by a vulnerability in software of a selected subsystem based on the extended software component information, and outputs information about the identified subsystems based on the software component information.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a vulnerability impact assessment support device and a vulnerability impact assessment support method.

Background Art

[0002] In the operation of an information system, ensuring information security is an essential element. An operator such as an SIer (System Integrator) may perform security operations by receiving the provision of an SBOM (Software Bill of Materials: software component list), which is information on components (software components) constituting the system, from the developer of each system. By using the SBOM, it is possible to perform vulnerability management of the system.

[0003] As a method for analyzing the vulnerability of a system, for example, Patent Document 1 discloses storing in association a risk factor that can occur in an evaluation target system and a plurality of components in the evaluation target system that are affected by the risk factor, and storing in association a component in the evaluation target system and characteristic information indicating the characteristics of the component, and referring to this information to calculate the degree of influence of each risk factor on the availability of the evaluation target system based on the characteristic information of the plurality of components affected by each risk factor.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, in recent years, the system configuration has become more complex, and SIers have started integrating each system provided by multiple suppliers to build a customer system. In this case, SIers receive SBOMs from each supplier, but it is difficult to determine the vulnerabilities of the systems of each supplier with different environments. Also, it is very difficult for system operators (customers of SIers) to perform security operations using these SBOMs. Patent Document 1 also does not have a mechanism for determining the risks of a system constructed by such multiple systems.

[0006] The present invention has been made in view of such problems, and an object thereof is to provide a vulnerability impact assessment support device and a vulnerability impact assessment support method that can assist in evaluating the impact of vulnerabilities in an information processing system configured by subsystems constructed in different environments on each subsystem.

Means for Solving the Problems

[0007] One aspect of the present invention for solving the above problems is, for each of a plurality of subsystems constructed in different environments that make up an information processing system, a storage device that stores software component information, which is information on the software that makes up the subsystem, and an extended data generation process for creating extended software component information including information on a second subsystem in the information processing system that is affected in terms of processing due to a vulnerability existing in the software of the first subsystem in the information processing system, and an impact assessment process for identifying other subsystems that are affected in terms of processing due to a vulnerability existing in the software of a selected subsystem based on the extended software component information, and outputting information on the identified subsystems to an output device based on the software component information. A vulnerability impact assessment support device comprising a control device that executes the process.

Effects of the Invention

[0008] According to the present invention, it is possible to assist in evaluating the impact of vulnerabilities in an information processing system composed of subsystems constructed in different environments on each subsystem. Configurations, effects, etc. other than those described above will be clarified by the description of the following embodiments.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Mode for Carrying Out the Invention

[0010] Embodiments of the present invention will be described with reference to the drawings.

[0011] FIG. 1 is a diagram showing an example of the configuration of a vulnerability impact assessment support system 1 according to the present embodiment. The vulnerability impact assessment support system 1 includes one or more supplier systems 10 (10A, B, ···, N) managed by each supplier that develops a system (hereinafter referred to as a subsystem) composed of a plurality of components (software), an integration system 20 managed by a system integrator (SIer) that integrates each subsystem to construct an information processing system (hereinafter referred to as a target system) as a product, a customer system 30 managed by a customer that introduces the target system constructed by the integration system 20, and a vulnerability impact assessment support device 40 managed by a predetermined administrator or the like. The supplier system 10, the integration system 20, the customer system 30, and the vulnerability impact assessment support device 40 may be communicably connected by a wired or wireless communication network such as the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), a VPN (Virtual Private Network), or a dedicated line.

[0012] The supplier system 10 is composed of information processing devices including software repositories 100 (100A, B, ···, N) that manage each component in a predetermined format (e.g., Git, SVN), one or more program development terminals 102 (102A, B, ···, N) for developing each component, and program management terminals 103 (103A, B, ···, N) that construct a subsystem from each developed component and perform an execution test of the subsystem. These information processing devices are communicably connected by a communication network 101 (101A, B, ···, N) such as a LAN. Each subsystem is constructed (built) in a different environment according to the configuration of the supplier system 10.

[0013] The integration system 20 includes a software repository 100S having the same functions as the supplier system 10 for managing each subsystem constructed in the supplier system 10, one or more program development terminals 102S having the same functions as the supplier system 10 for integrating each subsystem to construct a target system, a system test computer 104S for instructing an execution test of the integrated subsystem, i.e., the target system, and a system test computer 105S for executing the execution test of the target system. These information processing devices are communicably connected by a communication network 101S such as a LAN.

[0014] The customer system 30 includes an execution computer 110 for executing the introduced target system and one or more system user terminals 112 used by each customer who uses the target system. These information processing devices are communicably connected by a communication network 11 such as a LAN.

[0015] When there is a vulnerability in the software of the target system constructed by the integration system 20, the vulnerability impact assessment support device 40 evaluates what impact the vulnerability has on each subsystem and displays the result on the screen of the vulnerability impact assessment support device 40 or the customer system 30.

[0016] In this embodiment, it is assumed that the software vulnerability is caused by a library, which is the software used by the application in the subsystem, but it is not the intention to limit the location of the vulnerability cause. Also, in this embodiment, it is assumed that the vulnerability impact assessment support device 40 is managed by the SIer and evaluates the impact of software vulnerabilities, but it is not the intention to limit the administrator of the vulnerability impact assessment support device 40. For example, the vulnerability impact assessment support device 40 may be managed by a customer who procures a plurality of business systems from a plurality of SIers.

[0017] Next, FIG. 2 is a diagram for explaining an example of the functions provided by the vulnerability impact assessment support device 40.

[0018] The vulnerability impact assessment support device 40 stores a software repository 201. The software repository 201 stores the build information of each subsystem (for example, information such as the configuration of components and hardware, and the build environment), and the program files of each subsystem.

[0019] In addition, the vulnerability impact assessment support device 40 has functional units (programs) such as a build information reading unit 202, a program reading unit 203, a dependent library picking-up unit 204, a per-program dependency evaluation unit 205, and a per-function dependency evaluation unit 206.

[0020] The build information reading unit 202 acquires build information from the software repository 201.

[0021] Based on the build information acquired by the build information reading unit 202, the dependent library picking-up unit 204 identifies the components within each subsystem and the relationships between the components. The dependent library picking-up unit 204 stores the identified content in the SBOM information 208 for each subsystem. The SBOM information 208 is similar to a software bill of materials (SBOM).

[0022] Next, the program reading unit 203 acquires the programs of the components of each subsystem from the software repository 201.

[0023] By analyzing the programs acquired by the program reading unit 203, the per-program dependency evaluation unit 205 calculates, for each library, a parameter (dependency degree per library) representing the degree to which the processing of the subsystem having a library (which may have vulnerabilities) depends on the library, and stores it in the library dependency information 209.

[0024] For each function, the dependency evaluation unit 206 analyzes the program acquired by the program loading unit 203, calculates, for each function, a parameter (library dependency degree for each function) representing the degree to which a processing unit (a function in this embodiment) constituting the software of the subsystem depends on a library that is vulnerable software, and stores it in the library dependency information 209.

[0025] Next, the vulnerability impact evaluation support device 40 stores a vulnerability information 305 which is a database regarding vulnerabilities possessed by libraries, and a relationship definition file 303 that defines and lists processing relationships (for example, access modes) that can be established between a plurality of SBOMs.

[0026] Next, the vulnerability impact evaluation support device 40 has each functional unit (program): a file loading unit 301, a relationship definition unit 306, an extended data generation unit 308, a vulnerability identification unit 307, and an impact evaluation unit 309.

[0027] The file loading unit 301 reads a library dependency information group 304 obtained by integrating the library dependency information 209, the vulnerability information 305, an SBOM information group 302 obtained by integrating the SBOM information 208, and the relationship definition file 303.

[0028] The relationship definition unit 306 uses the SBOM information group 302 to set SBOM standard dependency impact degree information 321 (described later), which is data representing the degree of the processing impact (dependency impact degree) of a vulnerability existing in one component on the other component between two components in the SBOM.

[0029] Also, the relationship definition unit 306 sets processing relationships (for example, connection relationships, call relationships) that can be established between each SBOM in the relationship definition file 303.

[0030] Then, the relationship definition unit 306 uses the above-set relationship definition file 303 to set SBOM (subsystem) - to - SBOM dependency impact information 322 (described later), which is data representing the degree of processing impact (dependency impact degree) of vulnerabilities existing in one subsystem on another subsystem among the SBOMs related to the target system.

[0031] The extended data generation unit 308 stores the SBOM - to - SBOM dependency impact information 322 set by the relationship definition unit 306 in the inter - element extended SBOM information 311 (described later).

[0032] The vulnerability identification unit 307 uses the vulnerability information 305 to identify the vulnerabilities and their types in the libraries of each subsystem of the target system.

[0033] The impact evaluation unit 309 calculates the impact of each vulnerability on each subsystem (SBOM) and the spread of the impact among the subsystems based on the vulnerabilities identified by the vulnerability identification unit 307 and the inter - element extended SBOM information 311 generated by the extended data generation unit 308, and displays the calculated content on various screens.

[0034] (Relationship Definition File) FIG. 3 is a diagram showing an example of the relationship definition file 303. The relationship definition file 303 defines relationships such as, for example, one SBOM (subsystem) calling another subsystem via an API (REST on), one subsystem connecting to the database of another subsystem (DBMS on), one subsystem connecting to another subsystem in a stateful manner (State-full connect to), one subsystem connecting to another subsystem in a stateless manner (State-less connect to), one subsystem and another subsystem sharing a directory (Share directory on), one subsystem starting on another subsystem (Stand on. For example, a container or a virtual machine), one subsystem connecting to another subsystem using a predetermined communication service (connect by (TCP / UDP) service). Note that the relationship information described here is an example, and any information representing the relationship between SBOMs may be set.

[0035] (Vulnerability information) FIG. 4 is a diagram showing an example of the vulnerability information 305. The vulnerability information 305 has each data item of CVE421 in which the identifier of each vulnerability existing in the library is set, description 422 in which the description text of each vulnerability is set, CVSS423 in which the threat level of each vulnerability is set, software 424 in which information on the software affected by each vulnerability is set, countermeasures and mitigation measures 425 in which countermeasures or mitigation measures for each vulnerability are set, link 426 in which the location (for example, a website) where information related to each vulnerability is stored is set, CWE427 in which the type (CWE) of each vulnerability is set, and date and time 428 in which information on the setting date and time (issue date and time, update date and time) of this information is set.

[0036] Here, FIG. 5 is a diagram showing an example of the hardware included in the vulnerability impact assessment support device 40. The vulnerability impact assessment support device 40 includes a control device 91 such as a CPU (Central Processing Unit), a DSP (Digital Signal Processor), a GPU (Graphics Processing Unit), an FPGA (Field-Programmable Gate Array), and an ASIC (Application Specific Integrated Circuit), a main memory device 92 such as a RAM (Random Access Memory) and a ROM (Read Only Memory), an auxiliary storage device 93 such as an HDD (Hard Disk Drive) or an SSD (Solid State Drive), an input device 94 such as a keyboard, a mouse, or a touch panel, an output device 95 such as a liquid crystal monitor or an LCD (Liquid Crystal Display), and a communication device 96 composed of a NIC (Network Interface Card), a wireless communication module, a USB (Universal Serial Interface) module, or a serial communication module.

[0037] Each functional part of the vulnerability impact assessment support device 40 described above is realized by the control device 91 reading and executing each program stored in the main memory device 92 or the auxiliary storage device 93. Also, each program can be recorded and distributed on a recording medium, for example. Note that the vulnerability impact assessment support device 40 may be realized using virtual information processing resources provided using virtualization technology, process space separation technology, etc., such as a virtual server provided by a cloud system, for example, with all or part of it. Also, all or part of the functions provided by the vulnerability impact assessment support device 40 may be realized by a service provided by a cloud system via an API (Application Programming Interface) or the like, for example. Next, the processing performed in the vulnerability impact assessment support system 1 will be described.

[0038] Figure 6 is a flowchart for explaining the outline of the processing performed by the vulnerability impact assessment support system 1. First, the vulnerability impact assessment support device 40 executes an SBOM information creation process s1 for creating SBOM information 208 of each subsystem.

[0039] Also, the vulnerability impact assessment support device 40 executes a per-library dependency calculation process s3 for calculating the dependency for each library.

[0040] Also, the vulnerability impact assessment support device 40 executes a per-function library dependency calculation process s5 for calculating the library dependency for each function.

[0041] Then, the vulnerability impact assessment support device 40 executes an inter-element extended SBOM information creation process s7 for creating inter-element extended SBOM information 311.

[0042] After that, based on information such as the inter-element extended SBOM information 311, the vulnerability impact assessment support device 40 displays, on the screen of an information processing device (for example, the vulnerability impact assessment support device 40, the customer system 20) within the vulnerability impact assessment support system 1, information on the impact of vulnerabilities existing in the target system on each subsystem (SBOM) or the mutual influence between subsystems, in an impact display process s9.

[0043] At this time, the vulnerability impact assessment support device 40 identifies the subsystems (SBOM) affected by vulnerabilities using the dependency impact degree, the dependency for each library, the library dependency for each function, etc. (details will be described later).

[0044] Note that the vulnerability impact assessment support device 40 may also display the calculated dependency for each library and the library dependency for each function on each screen. Next, the details of each of the above processes will be described.

[0045] <SBOM Information Creation Process> In the SBOM information creation process s1, the vulnerability impact assessment support device 40 acquires the build information of each subsystem from the software repository 201. Based on each build information acquired by the build information reading unit 202, the vulnerability impact assessment support device 40 identifies the components within each subsystem and also identifies the relationships between the components within each subsystem. The vulnerability impact assessment support device 40 stores the identified content in the SBOM information 208. The vulnerability impact assessment support device 40 repeats the above processes for each subsystem to create a group of SBOM information 302 that combines the SBOM information 208.

[0046] Here, FIG. 7 is a diagram showing an example of the configuration of a subsystem indicated by build information. As shown in the figure, in this subsystem, the application 701 is executed depending on (based on) the library 702, the package, and the OS 703 (OS: Operation System), and the middleware 704 is executed depending on the package and the OS 703. The package and the OS 703 are executed depending on the hardware 705.

[0047] Note that the vulnerability impact assessment support device 40 may perform a predetermined file scan to identify each component. FIG. 8 is a diagram showing another example of the configuration of a subsystem identified by file scanning. As shown in the figure, the application 801 is executed depending on the library 802, the package, and the OS 803 (OS: Operation System), the middleware 804 is executed depending on the package and the OS 803, the package and the OS 803 are executed depending on the virtual machine 805, the virtual machine 805 is executed depending on the OS and the hypervisor 806, and the OS and the hypervisor 806 are executed depending on the hardware 807.

[0048] In addition to the examples shown in FIGS. 7 and 8, various use cases can be assumed. For example, an environment in which an application or the like operates based on a container machine operating on container software (container environment), and an environment in which an application or the like operates based on a predetermined system (such as SaaS (Software as a Service)) connected via a communication network such as the Internet (cloud cooperation) can be assumed.

[0049] (SBOM information) FIG. 9 is a diagram showing an example of the SBOM information 208. The SBOM information 208 includes a supplier name 401 in which identification information of each component (for example, the creator of the component, definition information, identifier, etc.) is set, a software component name 402 in which a name assigned to each component by a supplier or the like is set, a version 403 in which a version of each component set by a supplier or the like is set, a unique identifier 404 in which a lookup key of an identifier of each component or a database (PURL, CPE, SWID, etc.) related to each component is set, a hash 405 in which an encryption hash used to identify the binary of each component is set, a relationship 406 in which information for specifying the positional relationship of each component on the software architecture (for example, the upstream component X is included in the software Y) is set, a creator name 407 in which the creator of the SBOM entry is set, and a timestamp 408 in which information of the date and time when these pieces of information are set is set.

[0050] <Dependency calculation process for each library> Next, FIG. 10 is a flowchart for explaining an example of the dependency calculation process s3 for each library.

[0051] The vulnerability impact assessment support device 40 identifies the files of each component (such as applications, libraries, etc.) in each project (the scope managed by the build information. For example, at the subsystem level) from the SBOM information group 302, and reads the identified files (such as source code) from the software repository 201 (s802).

[0052] The vulnerability impact assessment support device 40 identifies all the library files used by the application (for example, called or referenced by the application) among the files read in s802 (s803).

[0053] The vulnerability impact assessment support device 40 identifies all the functions in the application using the above library and the functions called within the functions (s804).

[0054] Based on the functions identified in s804, the vulnerability impact assessment support device 40 calculates the per-library dependency for each library identified in s803 (s805). The vulnerability impact assessment support device 40 stores the calculated per-library dependency. The library dependency in a certain project is represented by, for example, the following formula (1).

[0055] dx = flx / ft ··· Formula (1)

[0056] Here, dx is the per-library dependency regarding library x, flx is the total number of functions using library x, and ft is the total number of functions in the project.

[0057] The vulnerability impact assessment support device 40 repeats all of the above processes for the projects of all subsystems.

[0058] In this way, in the present embodiment, the per-library dependency is regarded as a parameter based on the number of functions, but the dependency may be calculated in other processing units such as classes.

[0059] <Function-by-Function Library Dependency Calculation Process> FIG. 11 is a flowchart for explaining an example of the function-by-function library dependency calculation process S5.

[0060] First, the vulnerability impact assessment support device 40 refers to the SBOM information group 302 and selects one application in each subsystem. Then, the vulnerability impact assessment support device 40 acquires the program (source code, etc.) of the selected application. And the vulnerability impact assessment support device 40 executes the following processes S902 to S908 for each function in the acquired application program.

[0061] First, the vulnerability impact assessment support device 40 determines whether the function of the application is a function called from within the program (S902). If the function of the application is not a function called from within the program (S902: YES), the vulnerability impact assessment support device 40 executes the process of S904. If the function of the application is a function called from within the program (S902: NO), the vulnerability impact assessment support device 40 executes the process of S903.

[0062] In S903, the vulnerability impact assessment support device 40 determines whether the function is a type of function called from another program (system) (that is, a function that realizes the function of the application). For example, the vulnerability impact assessment support device 40 determines whether the function is a function corresponding to a Web API or a SaaS (Software as a Service) system, etc., by checking the format of the function.

[0063] When the function is a type of function that is called from another program (system) (s903: YES), the vulnerability impact assessment support device 40 executes the process of s904. When the function is not a type of function that is called from another program (system) (s903: NO), the vulnerability impact assessment support device 40 determines that the function is a function that does not realize the function of the application (hereinafter referred to as an internal function), stores that fact in the library dependency information 209, and ends the per-function library dependency calculation process s5 for that function.

[0064] In s904, the vulnerability impact assessment support device 40 determines that the function is a function that realizes the function of the application (hereinafter referred to as an external function).

[0065] Then, the vulnerability impact assessment support device 40 identifies all the functions that depend on the external function (s906).

[0066] The vulnerability impact assessment support device 40 calculates the per-function library dependency for the external function (s907), stores it in the library dependency information 209, and ends the per-function library dependency calculation process s5 for that function.

[0067] The per-function library dependency dfxy is calculated by, for example, the following formula (2). dfxy = fxly / fxt ···(2)

[0068] Here, dfxy is the per-function library dependency of the external function x regarding the library y, fxt is the total number of internal functions in the external function x, and fxly is the total number of internal functions in the external function x that use the library y.

[0069] In this way, the per-function library dependency further refines the dependency of the application on the library, and is a parameter representing the degree to which the functions that realize the functions of the application among the respective functions of the application use the library.

[0070] In this embodiment, the library dependency for each function is assumed to be a parameter based on the number of functions in this way, but the dependency may be calculated for other processing units such as classes.

[0071] Here, FIG. 12 is a diagram showing an example of the information on the library dependency for each function stored in the library dependency information 209.

[0072] As shown in the figure, this information includes each record containing each function name (which may also be the corresponding function name) in each subsystem (SBOM), information on the relationship (dependency such as a call relationship) between each function and each library, the author name of the SBOM related to each subsystem, and the creation date and time (timestamp) of these data.

[0073] <Inter - element Extended SBOM Information Creation Process> Next, the inter - element extended SBOM information creation process s7 will be described.

[0074] First, the vulnerability impact assessment support device 40 displays a predetermined editing screen on which the SBOM information group 302 is displayed, and accepts the input of each dependency impact degree from an administrator or the like, thereby setting the SBOM standard dependency impact degree information 321.

[0075] Also, the vulnerability impact assessment support device 40 displays a predetermined editing screen on which the SBOM information group 302 and the relationship definition file 303 are displayed, and accepts the input of each dependency impact degree from an administrator or the like, thereby setting the SBOM - to - SBOM dependency impact degree information 322.

[0076] The vulnerability impact assessment support device 40 stores information summarizing the SBOM - to - SBOM dependency impact degree information 322 for the SBOM in the target system in the inter - element extended SBOM information 311.

[0077] (SBOM Standard Dependency Impact Degree Information) Figure 13 is a diagram showing an example of SBOM standard dependency impact information 321. The SBOM standard dependency impact information 321 has data for each of the type 3211 of the relationship between two components in the SBOM related to the target system, and the degree of the impact on processing (dependency impact degree 3212) of the vulnerability of one component on the other component in the relationship of that type.

[0078] Examples of the type 3211 of the relationship between two components include, for example, one containing the other, one depending on the other, etc. Also, examples of the dependency impact degree 3212 include the impact on availability and the impact on security (confidentiality and integrity), and any numerical value from 0% to 100% can be set. Here, confidentiality and integrity are set together as the impact related to security, but they may also be set and managed separately.

[0079] (Dependency impact information between SBOMs) Figure 14 is a diagram showing an example of the dependency impact information 322 between SBOMs. The dependency impact information 322 between SBOMs has data for each of the type 3221 of the relationship between two SBOMs (sub-systems) related to the target system, and the degree of the impact (dependency impact degree 3222) of the vulnerability of one SBOM on the other SBOM in the relationship of that type.

[0080] The type 3221 of the relationship between two SBOMs is the type of the method by which one (the first) sub-system accesses the other (the second) sub-system. For example, one (A) connects to the other (B) via REST, one (A) connects to the other (B) via a DBMS, one (A) connects to the other (B) in a stateful / stateless manner, etc.

[0081] In addition, the dependency impact degree 3222 includes information 3224 (dependency impact degree) on the impact on the processing of the other (second) subsystem due to a vulnerability existing in the software of one (first) subsystem, and information (dependency impact degree) on the impact on the processing of one (first) subsystem due to a vulnerability existing in the software of the other (second) subsystem 3223. The dependency impact degree includes, for example, a dependency impact degree regarding the impact on availability and a dependency impact degree regarding the impact on security (data confidentiality), and any numerical value from 0% to 100% can be set. Note that dependency impact degrees from other types of viewpoints based on vulnerabilities, such as data integrity, may be set.

[0082] (Inter - element Extended SBOM Information) FIG. 15 is a diagram showing an example of the data structure of the inter - element extended SBOM information 311. The inter - element extended SBOM information 311 includes a relationship 411 in which information indicating the relationship (corresponding to the type 3221 of the SBOM - to - SBOM dependency impact information 322, etc.) between two subsystems (SBOMs) in the target system is set, a dependency 412 in which the dependency impact degree (corresponding to the dependency impact degree 3222 of the SBOM - to - SBOM dependency impact information 322, etc.) between the two subsystems, the dependency degree per library of each subsystem, or the library dependency degree per library function of each subsystem is set, a creator name 413 set by the creator of this information, and a timestamp 414 in which information on the date and time when this information is set is set, and has each data including these.

[0083] Note that the dependency impact degree may be corrected based on the dependency degree per library or the library dependency degree per function. For example, when a vulnerability in subsystem A affects subsystem B, the dependency degree per library related to subsystem A or B or the library dependency degree per function related to the functions in subsystem A or B is multiplied (weighted) by the set dependency impact degree.

[0084] As described above, the vulnerability impact assessment support device 40 of the present embodiment analyzes not only the SBOM within a subsystem as in the prior art but also the relationship (dependency) between SBOMs and outputs the result to the inter - element extended SBOM information 311.

[0085] <Impact assessment display process> Next, FIG. 16 is a flowchart for explaining an example of the impact assessment display process s9.

[0086] The vulnerability impact assessment support device 40 receives vulnerability information 305 (s1102).

[0087] Then, based on the vulnerability information 305 received in s1102, the vulnerability impact assessment support device 40 identifies all subsystems (SBOM) (here, subsystems equipped with libraries having vulnerabilities) that are directly affected by the impact of each vulnerability for each vulnerability (s1103).

[0088] For example, the vulnerability impact assessment support device 40 identifies the subsystems (SBOM) by collating the software 424 affected by the impact of each vulnerability 421 (CVE) of the vulnerability information 305 with the specific information of the components in the SBOM information group 302 (for example, the supplier name 401, the software component name 402, the version 403, and the unique identifier 404).

[0089] The vulnerability impact assessment support device 40 refers to the element - extended SBOM information 311 to identify all other subsystems (SBOM) affected by the vulnerability in each subsystem (SBOM) identified in s1103 (s1104).

[0090] Based on the subsystems identified in s1103 (hereinafter referred to as the directly - affected SBOM) and the subsystems identified in s1104 (hereinafter referred to as the indirectly - affected SBOM), the vulnerability impact assessment support device 40 displays various screens described below (s1105).

[0091] (Relationship display screen) FIGS. 17 and 18 are diagrams showing examples of the relationship display screens 1700 and 1800, which are screens showing information about the impact on the availability of each vulnerability on each subsystem (SBOM).

[0092] These relationship display screens 1700 and 1800 include an impact display section 1710 and 1810 that graphically display significant availability impacts between SBOMs, and a vulnerability information display section 1720 and 1820 that shows in a table the information of SBOMs that significantly affect availability for each vulnerability.

[0093] Note that the SBOMs (subsystems) to be displayed on the relationship display screens 1700 and 1800 may be selected by an administrator or the like, or all or some of the SBOMs may be automatically selected (the same applies to each of the following screens).

[0094] In the impact display sections 1710 and 1810, figures representing each SBOM in the application layer are displayed in the upper part, and figures representing each SBOM in the platform layer are displayed in the lower part.

[0095] Between these figures 1711 and 1811, they are connected by connection figures 1712 and 1812 (such as arrows) indicating that there is a significant impact due to vulnerability between subsystems, and phrases 1713 and 1813 (e.g., REST, DBMS, RUN) indicating the content of the relationship between those subsystems are displayed in the vicinity.

[0096] The identification of the SBOMs (subsystems) connected by the connection figures 1712 and 1812 may be performed based on any rule, such as by the value of the dependency impact degree between subsystems (further multiplying the dependency impact degree for each hop of the SBOM). For example, it is performed as follows. That is, the vulnerability impact assessment support device 40 identifies pairs of subsystems in which the dependency impact degree in the dependency 412 of the element - to - element extended SBOM information 311 is equal to or greater than a predetermined threshold, and connects between the figures 1711 and 1811 of the identified subsystems with the connection figures 1712 and 1812. At this time, the vulnerability impact assessment support device 40 will respectively identify which of the subsystems in the pair of subsystems corresponds to the subsystem that exerts an impact and which corresponds to the subsystem that receives the impact.

[0097] Regarding the dependency impact degree in the above specification, a modified dependency impact degree value obtained by taking into account the per-library dependency degree or the per-function library dependency degree may be used for the dependency impact degree value of dependency 412. For example, for the library included in the subsystem related to the dependency impact degree, the per-library dependency degree related to that library is further multiplied. Also, for the function included in the subsystem related to the dependency impact degree, the per-function library dependency degree related to that function is further multiplied.

[0098] The vulnerability information display units 1720 and 1820 include display columns 1721 and 1821 for each vulnerability, display columns 1722 and 1822 for the direct impact SBOM related to the vulnerability, and display columns 1723 and 1823 where the indirect impact SBOM corresponding to the direct impact SBOM is displayed. When any of the display columns 1721 and 1821 for a vulnerability in the vulnerability information display units 1720 and 1820 is selected, in the impact display units 1710 and 1810, the display modes of the graphics 1711 and 1811 related to all SBOMs related to the vulnerability are changed (for example, displayed in different colors, shapes, or sizes).

[0099] In the example of FIG. 17, the graphic 1711B indicating SBOM2, which is the direct impact SBOM, is displayed in a dark color, and the graphic 1711B indicating SBOM1, which is an indirect impact SBOM having a dependency in that it calls the WebAPI in SBOM2, is displayed in a light color.

[0100] In the example of FIG. 18, the graphic 1811A indicating SBOM4, which is the direct impact SBOM, is displayed in a dark color, and the graphics 1811B indicating SBOM1 and SBOM2, which are indirect impact SBOMs having a dependency in that they call SBOM4, are displayed in a light color.

[0101] (Extended Relationship Display Screen) Next, FIG. 19 is a diagram showing an example of an extended relationship display screen 1900, which is a screen that displays the impact of each vulnerability on each subsystem (SBOM) from different perspectives (availability, security).

[0102] The extended relationship display screen 1900 is a screen that displays the impacts on vulnerabilities between SBOMs from different perspectives based on the vulnerability type impact information 2000 described later.

[0103] The extended relationship display screen 1900 includes an impact display section 1910 that graphically displays the availability and security impacts between SBOMs, and a vulnerability information display section 1920 that shows in a table the information of SBOMs that affect each other in terms of availability and security for each vulnerability.

[0104] The display content of the impact display section 1910 is the same as that of the relationship display screens 1700 and 1800.

[0105] The vulnerability information display section 1920 has a display column 1921 for each vulnerability, a display column 1922 for the directly affected SBOM related to that vulnerability, a display column 1923 for the indirectly affected SBOM that is affected in terms of availability corresponding to the directly affected SBOM, and a display column 1924 for the indirectly affected SBOM that is affected in terms of security corresponding to the directly affected SBOM. When a display column 1921 of any vulnerability in the vulnerability information display section 1920 is selected, in the impact display section 1910, the display mode of the graphics 1911 related to all SBOMs related to that vulnerability is changed (for example, displayed in a different color, shape, or size).

[0106] (Vulnerability Type Impact Information) Figure 20 is a diagram showing an example of the vulnerability type impact information 2000. The vulnerability type impact information 2000 is information that defines for each type of the above vulnerabilities whether the vulnerabilities existing in the software of the subsystem have an impact on the processing of other subsystems.

[0107] Specifically, the vulnerability type impact information 2000 has each data including the type 2001 (CWE) of the vulnerability to which each vulnerability belongs, the content 2002 of the vulnerability, and the impact presence parameter (impact spread 2003) which is a parameter indicating whether or not the type of the vulnerability affects the dependent impact degree. That is, depending on the type of vulnerability, there are cases where the vulnerability has an impact on the subsystem and cases where it does not. Therefore, with the vulnerability type impact information 2000, a detailed dependent impact degree corresponding to the type of vulnerability can be calculated.

[0108] The type 2001 of the vulnerability is, for example, out-of-bounds write (787), use of freed memory (416), OS command injection (78), improper input validation (20), path traversal (22), improper authentication (287), deserialization of untrusted data (502), server-side request forgery (918).

[0109] In the impact spread 2003, when one (first) subsystem A accesses the other (second) subsystem B, the information 2004 about the impact on the processing of the second subsystem B due to the vulnerability existing in the software of the first subsystem A and the information 2005 about the impact on the processing of the first subsystem A due to the vulnerability existing in the software of the second subsystem B are set. And in the above information 2004 and 2005, the impact presence parameters indicating whether or not there is an impact on availability and whether or not there is an impact on security are respectively set.

[0110] The vulnerability impact assessment support device 40 calculates the dependency impact degree used for identifying the SBOM (subsystem) coupled by the coupling graphic 1912 in the impact display unit 1910 as follows using the vulnerability type impact information 2000. That is, the vulnerability impact assessment support device 40 identifies the values of the impact presence / absence parameters related to availability and security corresponding to the type of vulnerability from the impact spread 2004 and 2005 of the vulnerability type impact information 2000, respectively. When the value of the impact presence / absence parameter is "yes", the vulnerability impact assessment support device 40 uses the already calculated dependency impact degree, and when the value is "no", it corrects the already calculated dependency impact degree to 0.

[0111] (System Element Information Display Screen) Next, FIG. 21 is a diagram showing an example of a system element information display screen 2100 that displays information such as vulnerabilities of each subsystem (SBOM).

[0112] The system element information display screen 2100 has a plurality of tabs 2101 for selecting information of the SBOM that displays information from a plurality of SBOMs, and a detailed information display column 2110 for displaying information on the subsystem related to the SBOM selected by the tab 2101.

[0113] In the detailed information display column 2110, each piece of information including each vulnerability 2111 that the subsystem has, the component 2112 (software such as a library) in the subsystem affected by the vulnerability, the score 2113 (CVSS) of the vulnerability, the content of the impact on other components affected by the component 2112 (impact element 2114), and the type 2115 (CWE) to which the vulnerability belongs is displayed.

[0114] In the example of the figure, in the impact element 2114, the level (none: N, low: L, medium: M, high: H) or the numerical value of the magnitude of the dependency impact degree from each perspective of security or confidentiality (C), integrity (I), and availability (A) is displayed. Thereby, an outline of what kind of impact the subsystem (SBOM) receives can be known.

[0115] Regarding the vulnerability score 2113, CVSS may be further considered (for example, by performing multiplication, etc.) to further correct the dependency impact.

[0116] (Function Impact Display Screen) FIG. 22 is a diagram showing an example of a function impact display screen 2200 which is a screen that displays vulnerability information for each function of a subsystem (SBOM).

[0117] The function impact display screen 2200 has a plurality of tabs 2201 for an administrator or the like to select an SBOM that displays information from a plurality of SBOMs, and a detailed information display column 2210 that displays information on components related to the SBOM selected by the tab 2201.

[0118] In the detailed information display column 2210, the function 2211 of each function, the external function 2212 that realizes the function, the number 2213 of internal functions existing in the external function, the number 2214 of libraries used by the internal function, and the number 2215 of vulnerabilities of the library are displayed.

[0119] Note that when the part of the number 2214 of libraries is selected by an administrator or the like, a list of the libraries and components (applications, etc.) that depend on the libraries are displayed. Thereby, an administrator or the like can confirm applications or the like that are affected by the vulnerabilities of the libraries.

[0120] (Vulnerability Function Impact Display Screen) FIG. 23 is a diagram showing an example of a vulnerability function impact display screen 2300 that displays functions affected by each vulnerability. On the vulnerability function impact display screen 2300, each vulnerability 2301, the component 2302 affected by each vulnerability, and the function 2303 affected in the component (corresponding to the external function 2212 of the function impact display screen 2200) are displayed.

[0121] As described above, the vulnerability impact assessment support apparatus 40 of the present embodiment creates extended software component information (inter-element extended SBOM information 311) including information on other subsystems in the target system that are affected in terms of processing due to vulnerabilities existing in the software of a certain subsystem (SBOM) in the target system composed of a plurality of subsystems constructed in different environments. Based on the inter-element extended SBOM information 311, it identifies other subsystems (SBOMs) that are significantly affected in terms of processing due to vulnerabilities existing in the software of the selected subsystem (SBOM), and displays information on the identified subsystems on screens (for example, relationship display screens 1700 and 1800) in the vulnerability impact assessment support system 1 based on the software component information (SBOM information group 302).

[0122] In this way, based on the inter-element extended SBOM information 311, which is information on the impact of the spread of vulnerabilities among a plurality of subsystems (SBOMs) constructed in different environments, the vulnerability impact assessment support apparatus 40 can display information on subsystems (SBOMs) that are significantly affected by the vulnerability due to the subsystem having the vulnerability.

[0123] This can assist in evaluating the impact of vulnerabilities in an information processing system composed of subsystems constructed in different environments on each subsystem.

[0124] Further, the vulnerability impact assessment support apparatus 40 of the present embodiment calculates and outputs the dependency degree for each library representing the degree to which the processing of a subsystem having software (library) with vulnerabilities depends on that library.

[0125] Thereby, an administrator or the like can know the degree of risk that a subsystem (SBOM) is affected by the vulnerability of the library.

[0126] In addition, the vulnerability impact assessment support device 40 of the present embodiment identifies other subsystems that are affected in terms of processing due to vulnerabilities existing in the libraries of the selected subsystem based on the per-library dependency and the element-to-element extended SBOM information 311 (for example, by calculating the dependency impact).

[0127] In this way, by calculating whether the significant impact of a vulnerability extends to a subsystem based on the per-library dependency, it is possible to more precisely identify the affected subsystems (SBOM).

[0128] In addition, the vulnerability impact assessment support device 40 of the present embodiment calculates the per-function library dependency representing the degree to which the processing units (functions) constituting the software of the subsystem depend on the software (library) having vulnerabilities for each function, and outputs the calculated per-function library dependency.

[0129] Thereby, an administrator or the like can know the degree of risk of being affected by the vulnerabilities of the library for each function of the subsystem (SBOM).

[0130] In this case, the vulnerability impact assessment support device 40 of the present embodiment calculates the per-function library dependency for functions (such as Web APIs) that are used as functions from other software among the processing units (functions) constituting the software of the subsystem.

[0131] In this way, by calculating the per-function library dependency of functions called as functions from other software, the impact of vulnerabilities can be grasped for each function.

[0132] At this time, the vulnerability impact assessment support device 40 of the present embodiment outputs information on the vulnerabilities of the functions for which the per-function library dependency has been calculated to the function impact display screen 2200.

[0133] Thereby, an administrator or the like can grasp the impact of vulnerabilities from the perspective of functions.

[0134] Furthermore, the vulnerability impact assessment support device 40 of the present embodiment identifies other subsystems (SBOM) that are affected in terms of processing due to vulnerabilities existing in the libraries of the selected subsystem based on the library dependency degree for each function and the inter-element extended SBOM information 311.

[0135] As a result, it is possible to identify the subsystems (SBOM) affected by the vulnerability according to the function, so that it is possible to support the evaluation of the impact considering the characteristics of the subsystems.

[0136] In addition, the vulnerability impact assessment support device 40 of the present embodiment creates inter-element extended SBOM information 311 in which SBOM inter-dependency impact degree information 322 is reflected (information including the information on the impact (dependency impact degree) on the processing of the other subsystem due to a vulnerability existing in the software of one subsystem when one subsystem accesses the other subsystem, and the information on the impact (dependency impact degree) on the processing of one subsystem due to a vulnerability existing in the software of the other subsystem), and based on this inter-element extended SBOM information 311, by identifying which of the above-mentioned one subsystem or the other subsystem the selected subsystem corresponds to, it identifies other subsystems (SBOM) that are affected in terms of processing due to vulnerabilities existing in the libraries of the selected subsystem.

[0137] By using such inter-element extended SBOM information 311, it is possible to more accurately identify other subsystems (SBOM) that are affected, taking into account the access relationship between subsystems.

[0138] More specifically, the vulnerability impact assessment support device 40 of the present embodiment creates inter-element extended SBOM information 311 including information on other subsystems whose availability and security are affected due to vulnerabilities existing in the software of a certain subsystem, and based on this inter-element extended SBOM information 311, it identifies other subsystems (SBOM) that are affected in terms of processing due to vulnerabilities existing in the libraries of the selected subsystem.

[0139] As a result, it becomes possible to more specifically grasp the content of the influence received and to more accurately perform the vulnerability assessment.

[0140] In addition, the vulnerability impact assessment support device 40 of the present embodiment creates vulnerability type impact information 2000 that further includes information defined for each type of vulnerability (CWE) indicating whether or not there is an impact on processing in other subsystems due to vulnerabilities existing in the software of a certain subsystem, identifies the type of vulnerability existing in the software of the selected subsystem, and uses the vulnerability type impact information 2000 to identify other subsystems (SBOM) that are affected in terms of processing due to vulnerabilities existing in the library of the selected subsystem.

[0141] Depending on the type of vulnerability existing in the library or the like, there may be differences in whether or not the impact of the vulnerability spreads. Therefore, by using the vulnerability type impact information 2000, it becomes possible to more accurately estimate the spread of the impact of the vulnerability.

[0142] As described above, the embodiments of the present invention have been described. However, the present invention is not limited to the above embodiments, and can be implemented using any components without departing from the gist thereof. The embodiments and modifications described above are merely examples, and the present invention is not limited to these contents as long as the features of the invention are not impaired. Also, although various embodiments and modifications have been described above, the present invention is not limited to these contents. Other aspects conceivable within the scope of the technical idea of the present invention are also included in the scope of the present invention.

[0143] In addition, a part of the hardware provided in each device of the present embodiment may be provided in other devices.

[0144] Also, each program of each device may be provided in other devices, a certain program may be composed of a plurality of programs, or a plurality of programs may be integrated into one program.

Explanation of Reference Numerals

[0145] 1 Vulnerability Impact Assessment Support System, 40 Vulnerability Impact Assessment Support Device, 208 SBOM Information, 311 Extended SBOM Information between Elements

Claims

1. For each of a plurality of subsystems constructed in different environments that constitute an information processing system, a storage device that stores software component information, which is information on software that constitutes the subsystem, and an extended data generation process that creates extended software component information including information on a second subsystem in the information processing system that is affected in terms of processing due to a vulnerability existing in the software of the first subsystem in the information processing system, and an impact assessment process that, based on the extended software component information, identifies other subsystems that are affected in terms of processing due to a vulnerability existing in the software of a selected subsystem, and outputs information on the identified subsystems to an output device based on the software component information, A vulnerability impact assessment support device comprising a control device that executes the above.

2. The control device executes a library-by-library dependency calculation process that calculates, for software with a vulnerability, a parameter representing the degree to which the processing of the subsystem having the software depends on the software, and outputs the calculated parameter to an output device. The vulnerability impact assessment support device according to claim 1.

3. The control device In the impact assessment process, identifies the other subsystems based on the calculated parameter and the extended software component information. The vulnerability impact assessment support device according to claim 2.

4. The control device executes a function-by-library dependency calculation process that calculates, for each processing unit constituting the software of the subsystem, a parameter representing the degree to which the processing unit depends on software with a vulnerability, and outputs the calculated parameter to an output device. The vulnerability impact assessment support device according to claim 1.

5. The control device In the function-by-library dependency calculation process, calculates the parameter for a processing unit that is used as a function from other software among the processing units constituting the software. The vulnerability impact assessment support device according to claim 4.

6. The control device In the function-by-library dependency calculation process, outputs information on the vulnerability of the processing unit for which the parameter has been calculated to an output device. The vulnerability impact assessment support device according to claim 5.

7. The control device The vulnerability impact assessment support device according to claim 4, wherein, in the impact assessment process, the other subsystem is identified based on the calculated parameter and the extended software component information.

8. The control device In the extended data generation process, when the first subsystem accesses the second subsystem, extended software component information including information on the impact on the processing of the second subsystem due to a vulnerability existing in the software of the first subsystem and information on the impact on the processing of the first subsystem due to a vulnerability existing in the software of the second subsystem is created. In the impact assessment process, based on the created extended software component information, by identifying which of the first subsystem or the second subsystem the selected subsystem corresponds to, the other subsystem is identified. The vulnerability impact assessment support device according to claim 1.

9. The control device In the extended data generation process, extended software component information including information on the second subsystem affected by the vulnerability existing in the software of the first subsystem in terms of availability and security is created. In the impact assessment process, based on the extended software component information, other subsystems affected by the vulnerability existing in the software of the selected subsystem in terms of availability and security are identified. The vulnerability impact assessment support device according to claim 1.

10. The control device In the extended data generation process, vulnerability type impact information including information defining, for each type of vulnerability, whether the vulnerability existing in the software of the first subsystem has an impact on the processing of the second subsystem is created. In the impact assessment process, the type of vulnerability existing in the software of the selected subsystem is identified, and based on the identified type and the vulnerability type impact information, the other subsystem is identified. The vulnerability impact assessment support device according to claim 1.

11. A vulnerability impact assessment support method by an information processing apparatus including a storage device that stores software component information, which is information on software that constitutes a subsystem, for each of a plurality of subsystems constructed in different environments that constitute an information processing system, and a control device, comprising: the control device:[[]] an extended data generation process for creating extended software component information including information on a second subsystem in the information processing system that is affected in processing due to a vulnerability existing in the software of the first subsystem in the information processing system; an impact assessment process for identifying other subsystems that are affected in processing due to a vulnerability existing in the software of a selected subsystem based on the extended software component information, and outputting information on the identified subsystems to an output device based on the software component information; A vulnerability impact assessment support method that executes the above.

Images