Information processor, information processing method, and program

Abstract

To provide an information processor that can evaluate a vulnerability risk with higher accuracy and a lower calculation cost.SOLUTION: An information processor according to the embodiment includes a generation unit, an identification unit, and a vulnerability risk calculation unit. The generation unit generates dependency information including an execution user of a first evaluation target and a dependency relationship having a dependency relationship with the first evaluation target, and resource access authority information. The identification unit identifies, on the basis of the execution user and the access authority information, a resource that the first evaluation target can access. The vulnerability risk calculation unit calculates a vulnerability risk indicating a risk level for each vulnerability from a resource accessible to the first evaluation target and one or more pieces of vulnerability information.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] An embodiment of the present invention relates to an information processing device, an information processing method, and a program. [Background technology]

[0002] Indicators such as CVSS (Common Vulnerability Scoring System) and EPSS (Exploit Prediction Scoring System) are available for determining the severity of vulnerabilities. These indices do not take into account the usage of vulnerable software or the resources accessible from the software. On the other hand, attack simulation techniques such as BAS (Breach and Attack Simulation) can be used to assess vulnerabilities on a system-by-system basis. However, these simulation techniques do not take into account the software implementation (dependencies) within a device, and are based on the assumption that if there is a vulnerability, the entire device will be affected, which can actually result in an overestimation of risk. [Prior art documents] [Patent documents]

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

[0004] With conventional technology, it has been difficult to assess vulnerability risk with higher accuracy and at lower computational costs. [Means for solving the problem]

[0005] An information processing device according to an embodiment includes a generating unit, an identifying unit, and a vulnerability risk calculation unit. The generating unit generates dependency information including an execution user of a first evaluation target and a dependency relationship having a dependency relationship with the first evaluation target, and access authority information of resources. The identifying unit identifies resources accessible to the first evaluation target based on the execution user and the access authority information. The vulnerability risk calculation unit calculates a vulnerability risk indicating a risk level for each vulnerability from the resources accessible to the first evaluation target and one or more pieces of vulnerability information. [Brief description of the drawings]

[0006] [Figure 1] FIG. 2 is a diagram showing an example of a functional configuration of the information processing apparatus according to the embodiment. [Diagram 2] FIG. 4 is a diagram showing an example of a dependency information DB according to the embodiment. [Diagram 3] FIG. 4 is a diagram showing an example of an ACL DB according to the embodiment. [Figure 4] FIG. 4 is a diagram showing an example of an asset importance information DB according to the embodiment. [Diagram 5] 11 is a flowchart showing an example of a flow of generating dependency information and an ACL according to the embodiment. [Figure 6] 11 is a flowchart showing an example of a calculation flow of an equipment risk according to the embodiment. [Figure 7] FIG. 13 is a diagram showing an example of a dependency information DB according to a modified example of the embodiment. [Figure 8] FIG. 13 is a diagram showing an example of an ACL DB according to a modified example of the embodiment. [Figure 9] FIG. 13 is a diagram showing an example of an asset importance information DB according to a modified example of the embodiment. [Figure 10] FIG. 2 is a diagram showing an example of a hardware configuration of an information processing apparatus according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] Hereinafter, embodiments of an information processing device, an information processing method, and a program will be described in detail with reference to the accompanying drawings.

[0008] Existing vulnerability assessment indices and attack simulation techniques may not necessarily represent the risk of leaving vulnerabilities in devices, or may not be able to assess risk correctly because they do not take into account the software implementation in the devices. In addition, if it is necessary to obtain data flows for risk assessment, the calculation costs are high.

[0009] In the following embodiment, an information processing device that can accurately estimate the impact of devices in a system at a lower calculation cost and thereby improve the accuracy of risk calculation will be described. The information processing device of the embodiment can make it possible to more appropriately determine the method and timing of dealing with risks.

[0010] [Example of functional configuration] 1 is a diagram illustrating an example of a functional configuration of an information processing device 100 according to an embodiment. The information processing device 100 according to the embodiment includes a generation unit 1, a vulnerability risk calculation unit 2, an identification unit 3, a correction unit 4, an equipment risk calculation unit 5, and an output unit 6. The information processing device 100 according to the embodiment also stores a dependency information DB101, an ACL (Access Control List) DB102, and an asset importance information DB103.

[0011] When the generation unit 1 receives information used to generate the dependency information and the ACL, it generates the dependency information and the ACL, stores the generated dependency information in the dependency information DB 101 shown in Fig. 2, and stores the generated ACL in the ACL DB 102 shown in Fig. 3. Information used to generate the dependency information and the ACL includes, for example, file permissions, process information, and library dependency relationships.

[0012] 2 is a diagram showing an example of the dependency information DB 101 according to the embodiment. The dependency information DB 101 according to the embodiment stores data including a program name, an executable (possible) user, and a dependency relationship. The program name is the name of the program. The executable (possible) user indicates a user who can execute the program.

[0013] Dependencies are information indicating libraries, programs, services, etc., necessary for the operation of programs, services, etc. As shown in FIG. 2, information on users who can execute (possibly execute) a program may be associated with dependencies. In the example of FIG. 2, if library A (example of a second program) is required for the operation of program A (example of a first program), library A is included in the dependency information. As for the executing user, if program A is executed by user A, user A is associated with the dependency information.

[0014] There are various possible forms of resource information used to generate dependency information. Resource information is information about files, hardware, programs, etc. For example, resource information is process information obtained from an operating device. Another example of resource information is information about library dependencies obtained by analyzing executable files, etc.

[0015] The process information includes library information loaded into the running program, other programs communicating with the running program, and information about the user executing the running program.

[0016] Furthermore, when the executable file is analyzed by the generation unit 1, for example, library load information included in the header of the binary file may be analyzed. For example, library information required for the execution of the executable file may be analyzed by means of decompiling the program. Note that since a library may depend on another library, it is desirable to analyze the library information recursively.

[0017] Since it is often impossible to determine the (possible) user from the file contents, there is a method to identify the users who can execute the file from the owner and permissions of the executable file. For example, if the owner of the executable file is User A, and the permissions limit the users who can execute the file to only the owner, then User A is the only user who can execute the file. Even if the owner is User A, if the users who can execute the file are all users, then the (possible) users who can execute the file will be everyone.

[0018] Returning to FIG. 1, the generating unit 1 generates an ACL (an example of access authority information) from accessible resource information, and stores it in an ACL DB 102 shown in FIG. 3, which will be described later.

[0019] Information on accessible resources may take various forms. For example, permission information may be used as input. The generating unit 1 stores in the ACL DB 102 the user who owns the resource and the permission for the resource.

[0020] Fig. 3 is a diagram showing an example of the ACL DB 102 according to the embodiment. The ACL DB 102 according to the embodiment stores data including resource names, owning users, and permissions. Fig. 3 is an example of an access control list based on permissions of a Unix (registered trademark) based OS. The resource name is the name of the resource. The owning user indicates the user who owns the resource. The permissions indicate the resource permissions expressed in octal numbers.

[0021] For example, FileA on the first line is owned by User A and the permissions are 0600, meaning that only User A, the owner of the file, can read and write to it. For example, FileB on the second line is owned by User B and the permissions are 0666, meaning that not only User B but all users can read and write to it.

[0022] Returning to Fig. 1, when the vulnerability risk calculation unit 2 receives vulnerability information, it requests the identification unit 3 to identify the range of resources that can be accessed by a program having a vulnerability or a program using a library. The vulnerability information is, for example, the EPSS and CVSS scores of individual vulnerabilities. The vulnerability risk calculation unit 2 then obtains information indicating the asset importance of the resources from the identification unit 3, and calculates the vulnerability risk indicating the risk for each vulnerability.

[0023] The asset importance includes at least one of a resource confidentiality importance, a resource security importance, and a resource availability importance.

[0024] For example, methods such as the CVSS environmental assessment criteria are used to calculate vulnerability risk.

[0025] 4 is a diagram showing an example of the asset importance information DB 103 according to the embodiment. The asset importance information DB 103 according to the embodiment stores data including a resource name, confidentiality importance, integrity importance, and availability importance.

[0026] Taking the CVSS environmental assessment criteria as an example, when only FileA is included in the accessible range, the confidentiality importance, integrity importance, and availability importance are High, High, and Medium, respectively. When FileA and FileB are included in the accessible range, a higher importance value is selected, and the confidentiality importance, integrity importance, and availability importance are High, High, and High, respectively.

[0027] The vulnerability risk calculation unit 2 determines the environmental values ​​calculated by using the confidentiality importance, integrity importance, and availability importance values ​​as CR, IR, and AR in CVSS, respectively, as the vulnerability risk.

[0028] Note that the environmental assessment criteria indicate the technical risk of an attack, but do not necessarily indicate the possibility of an attack. In reality, the possibility of an attack varies depending on the presence of an attack proof code (a program for checking whether software has a specific vulnerability) and the presence or absence of an attack campaign. For this reason, when calculating the vulnerability risk, the vulnerability risk calculation unit 2 may multiply the environment value calculated by the environmental assessment criteria by a parameter indicating the possibility of an attack, so that the higher the possibility of an attack, the higher the vulnerability risk. Examples of indices that may be used include the CVSS current value and EPSS.

[0029] That is, the vulnerability risk calculation unit 2 may determine the attackability of a specific vulnerability based on whether or not there is a verification code for checking whether or not there is a specific vulnerability in at least one of the first program and the second program on which the first program depends, or based on whether or not there is an attack campaign against the specific vulnerability. In this way, the vulnerability risk of a specific vulnerability may be calculated further based on the attackability of the specific vulnerability.

[0030] Returning to FIG. 1, when the identification unit 3 receives vulnerability information from the vulnerability risk calculation unit 2, it identifies the range of resources that can be accessed by a vulnerable program (first program) or a program that uses a library (second program). For example, the generation unit 1 analyzes the first program to identify the second program, and generates dependency information including the identified second program. When one or more pieces of vulnerability information include vulnerability information of the second program, the identification unit 3 identifies the resources that can be accessed by the first program.

[0031] Moreover, the identifying unit 3 reads out the asset importance information (see FIG. 4 above) of the identified resource from the asset importance information DB 103.

[0032] Specifically, for example, when program A has a vulnerability, the identifying unit 3 determines that the executing user is A from Fig. 2, and therefore obtains resources accessible to user A from Fig. 3. In the example of Fig. 3, File A, whose owner is A, and File B, which anyone can read and write, correspond to the accessible resources. Furthermore, the identifying unit 3 obtains the confidentiality importance, integrity importance, and availability importance for the accessible resources from the asset importance information in Fig. 4, and returns the confidentiality importance, integrity importance, and availability importance to the vulnerability risk calculation unit 2.

[0033] The identifying unit 3 may identify in more detail the operations that can be performed on the resource from the ACL (an example of access authority information). The vulnerability risk calculation unit 2 may then calculate the vulnerability risk further based on the operations that can be performed on the resource.

[0034] Specifically, the identification unit 3 may analyze the permissions in Fig. 3 in detail and recalculate the confidentiality importance, integrity importance, and availability importance at the granularity of read, write, and execute. For example, for FileC, integrity is important in Fig. 4, but referring to the permissions in Fig. 3, it is a file that can only be read, and tampering is difficult. Therefore, when a vulnerability is found in Program B that can access FileC, the identification unit 3 may change the integrity importance from high to low and return it to the vulnerability risk calculation unit 2.

[0035] For example, if a vulnerability is found in Library A, the programs that use Library A are ProgramA and ProgramD according to dependency information DB 101 in Fig. 2. In this case, since the user who can execute ProgramA is A, the accessible resource of ProgramA is FileA according to the owner user and permission information in ACL DB 102 in Fig. 3. Furthermore, since the user who can execute ProgramD is B, the accessible resources of ProgramD are FileB and FileC according to the owner user and permission information in ACL DB 102 in Fig. 3. In other words, if a vulnerability exists in Library A, the accessible range will be FileA, FileB, and FileC.

[0036] When one or more pieces of vulnerability information include a vulnerability that allows at least one of the first program and the second program on which the first program depends to be run by another user, the correction unit 4 makes a correction to add resources accessible by the other user to the range of resources accessible by the first program.

[0037] Specifically, when resources can be accessed beyond the initially accessible range of a program having a vulnerability such as a privilege escalation vulnerability, the correction unit 4 corrects the accessible range by recalculating the resources that can be accessed with the elevated privileges. For example, when Program B has a vulnerability, FileB and FileC can be accessed initially, but when there is a vulnerability that allows the privileges to be changed to a privileged user or User A, FileA can also be accessed. In addition, when there is a kernel vulnerability that allows operation in a privileged mode, the correction unit 4 corrects the accessible range to all of FileA, FileB, and FileC, since all resources are accessible.

[0038] When multiple vulnerability risks are calculated for the equipment to be evaluated, the equipment risk calculation unit 5 calculates the equipment risk indicating the vulnerability risk in the equipment based on the multiple vulnerability risks. That is, when there are multiple vulnerabilities, the equipment risk calculation unit 5 calculates the risk at the equipment level (risk in the equipment) from the vulnerability risk (risk of a single vulnerability) calculated by the vulnerability risk calculation unit 2. An example of the calculation of the risk at the equipment level is as follows.

[0039] Let R(i) be the risk of vulnerability i normalized within the range of 0-1.0 (0: lowest risk, 1.0: highest risk). Vulnerabilities that have already been fixed are not included in the population, or R(i) = 0. There are various ways to calculate the overall risk within the device, Rall, which is the sum of the risks R(0) to R(n-1). For example, it is calculated using the following formula (1). Rall=1-Π(1-R(i)) (i=0,...,n-1)...(1)

[0040] The above formula (1) is an example of calculating the risk within the entire device, assuming that R(i) is the probability of an attack by a single vulnerability, and the risk of an attack by all the vulnerabilities as a whole is calculated as the probability of occurring as an independent event.

[0041] In addition to the above formula (1), the risk within the entire device may be calculated by simply adding up R(i), as shown in the following formula (2). Rall=ΣR(i) (i=0,...,n-1)...(2)

[0042] Also, for example, the maximum value of the individual vulnerability risks may be regarded as the overall risk within the device, as shown in the following formula (3). Rall=max(R(i)) (i=0,...,n-1)...(3)

[0043] The output unit 6 outputs presentation information based on the equipment risk calculated by the equipment risk calculation unit 5 (for example, an evaluation result including at least one of the vulnerability risk and the equipment risk) by at least one of display information and audio.

[0044] Regarding the timing of presenting information based on the device risk, for example, the output unit 6 may present Rall every time a vulnerability is discovered, or may present the current risk value Rall at regular intervals. Also, the output unit 6 may notify when R(i) becomes equal to or greater than a predetermined threshold value.

[0045] In addition, the information presented by the output unit 6 may be not only Rall (equipment risk) but also the risk R(i) of each vulnerability (vulnerability risk level), or the accessible range that serves as the basis for the calculation, or vector information for CVSS calculation, etc.

[0046] 5 is a diagram showing an example of a flow of generating dependency information and an ACL according to an embodiment. First, the generating unit 1 acquires information (e.g., file permissions, process information, and library dependencies) used in generating the dependency information and the ACL (step S1).

[0047] Next, the generating unit 1 generates dependency information and an ACL from the information acquired in step S1 (steps S2 and S3). Next, the generating unit 1 stores the dependency information generated in step S2 in the dependency information DB 101, and stores the ACL generated in step S3 in the ACL DB 103 (step S4).

[0048] 6 is a diagram showing an example of a calculation flow of device risk (vulnerability risk in device) according to the embodiment. When performing device-level vulnerability calculation after a certain period of time has elapsed or upon discovery of a new vulnerability, the vulnerability risk calculation unit 2 first checks whether there are any vulnerabilities that have not been calculated in order to calculate the risk of each vulnerability (step S11).

[0049] If there is an uncalculated vulnerability (step S11: Yes), the identifying unit 3 acquires dependency information having a dependency relationship with the program, library, etc. in which the vulnerability was discovered from the dependency information DB 101 (step S12). In step S12, a list of programs whose operations depend on the program, library, etc. in which the vulnerability was discovered is identified.

[0050] Next, the identification unit 3 further identifies the executing user of the program from the dependency information (step S13). Since the resources that can be accessed vary depending on the executing user, the following process is executed for each executing user.

[0051] The identification unit 3 first determines whether or not there is an unprocessed execution user (step S14), and if there is an unprocessed execution user (step S14: Yes), obtains resources accessible to that execution user from the ACL (step S15).

[0052] On the other hand, if there is no unprocessed executing user (step S14: No), the correction unit 4 judges whether or not the authority correction is necessary depending on the characteristics of the vulnerability (step S16). The criterion for this authority correction is, for example, whether or not the vulnerability is a vulnerability of a program or service that runs in kernel mode. Also, for example, the criterion for limit correction is whether or not the vulnerability is a vulnerability that allows privilege escalation.

[0053] If the authority needs to be corrected (step S16: Yes), the correction unit 4 corrects the accessible range (step S17). Specifically, in the case of a kernel vulnerability or a vulnerability where administrator authority can be obtained, the correction unit 4 corrects the accessible range to make all resources accessible. Also, for example, in the case of a vulnerability where a program executed by another user can be infiltrated, the correction unit 4 performs a correction to add resources accessible by the other user to the accessible range.

[0054] After correcting the accessible range, or if no correction of authority is required, the identification unit 3 obtains the asset importance for each resource determined to be accessible. Specifically, the identification unit 3 determines whether or not there is an unprocessed resource (step S18), and if there is an unprocessed resource (step 18: Yes), the identification unit 3 obtains the asset importance information of the resource from the asset importance information DB 103 shown in Fig. 4 (step S19). Furthermore, the correction unit 4 may correct the asset importance information from the permission of the resource (step S20).

[0055] Steps S19 and S20 are repeated until there are no unprocessed resources, and when there are no unprocessed resources (step 18: No), the vulnerability risk calculation unit 2 determines the overall importance of resources that may be affected by the vulnerability from the asset importance of each resource (step S21). Furthermore, the vulnerability risk calculation unit 2 calculates the vulnerability risk for each vulnerability from the overall resource importance, vulnerability information, the possibility of attack, etc. (step S22).

[0056] Possible calculation methods for step S22 include, for example, a method of calculating the characteristics of the vulnerability such as the CVSS environmental assessment criteria, and a method of multiplying the risk level that takes into account the possibility of an attack such as the CVSS current value or EPSS, but are not limited to these methods.

[0057] When there are no more uncalculated vulnerabilities (step S11: No), the equipment risk calculation unit 5 calculates the equipment risk that indicates the degree of danger taking into account all vulnerabilities in the equipment (step S23). The calculation method in step S23 uses the above-mentioned formula (1), (2) or (3), etc.

[0058] Finally, the output unit 6 determines whether to output the output information and the evaluation result to be presented by the output information depending on the vulnerability risk calculated in step S22 and the equipment risk calculated in step S23, etc., and controls the output of the evaluation result (step S24).

[0059] As described above, in the information processing device 100 of the embodiment, the generation unit 1 generates dependency information including an executing user of a first evaluation target (a program in the embodiment) and dependencies that have a dependency relationship with the first evaluation target, and resource access authority information (ACL in the embodiment). The identification unit 3 identifies resources that can be accessed by the first evaluation target based on the executing user information and the access authority information. Then, the vulnerability risk calculation unit 2 calculates a vulnerability risk indicating the risk level for each vulnerability from the resources that can be accessed by the first evaluation target and one or more pieces of vulnerability information.

[0060] As a result, the information processing device 100 according to the embodiment can evaluate the risk of vulnerability with lower calculation cost and higher accuracy. Specifically, the impact of the vulnerability on resources in the device is clarified, and the impact can be calculated with higher accuracy than with conventional attack simulation techniques. In addition, the present embodiment does not require acquisition of data flows, and can clarify the impact of an attack exploiting a vulnerability using static information obtained statically, or dynamic information obtained dynamically in a short time. Specifically, not only the vulnerability risk of a single vulnerability, but also the impact at the device level (the above-mentioned device risk) can be clarified when there are multiple vulnerabilities, so that the timing of applying a patch to a vulnerability can be more appropriately determined.

[0061] (Modification of the embodiment) Next, a modified example of the embodiment will be described. In the description of the modified example, the description similar to the embodiment will be omitted, and only the differences from the embodiment will be described. In the above-mentioned embodiment, the evaluation target is a program, and a method for determining the risk of the device from the vulnerability risk of the program has been described. In the modified example, a case will be described in which the evaluation target is a first service realized by one or more programs, and the dependency relationship is a second service on which the first service depends.

[0062] Specifically, in the modified example, program (software) dependencies are replaced with dependency information between services as shown in Fig. 7. In addition, in the modified example, the access control list is replaced with access authorization information for a service API for device-to-device calls as shown in Fig. 8. In addition, in the modified example, the importance of assets is replaced with importance at the service API level, etc. as shown in Fig. 9.

[0063] This makes it possible to apply the above-described embodiment to risk calculation for a system consisting of multiple services (multiple devices).

[0064] According to a modified example, when calculating the system-level risk, the calculation results for each service (device) are taken into account to calculate the service risk, making it possible to calculate the risk with higher accuracy from the vulnerability information.

[0065] Finally, a description will be given of an example of a hardware configuration of the information processing device 100 according to the embodiment. The information processing device 100 according to the embodiment can be realized, for example, by using any computer device as basic hardware.

[0066] [Example of hardware configuration] 10 is a diagram illustrating an example of a hardware configuration of an information processing device 100 according to an embodiment. The information processing device 100 according to the embodiment includes a processor 201, a main storage device 202, an auxiliary storage device 203, a display device 204, an input device 205, and a communication device 206. The processor 201, the main storage device 202, the auxiliary storage device 203, the display device 204, the input device 205, and the communication device 206 are connected via a bus 210.

[0067] Note that the information processing device 100 may not include some of the above configurations. For example, when the information processing device 100 can use the input function and display function of an external device, the information processing device 100 may not include the display device 204 and the input device 205.

[0068] The processor 201 executes a program read from the auxiliary storage device 203 to the main storage device 202. The main storage device 202 is a memory such as a ROM and a RAM. The auxiliary storage device 203 is a hard disk drive (HDD), a memory card, or the like.

[0069] The display device 204 is, for example, a liquid crystal display. The input device 205 is an interface for operating the information processing device 100. The display device 204 and the input device 205 may be realized by a touch panel or the like having a display function and an input function. The communication device 206 is an interface for communicating with other devices.

[0070] For example, the program executed by the information processing device 100 is provided as a computer program product in the form of a file in an installable or executable format, recorded on a computer-readable storage medium such as a memory card, a hard disk, a CD-RW, a CD-ROM, a CD-R, a DVD-RAM, or a DVD-R.

[0071] Also, for example, the program executed by the information processing device 100 may be configured to be stored on a computer connected to a network such as the Internet and provided by being downloaded via the network.

[0072] Also, for example, the program executed by the information processing device 100 may be provided via a network such as the Internet without being downloaded. Specifically, for example, the process may be executed by an ASP (Application Service Provider) type cloud service.

[0073] Furthermore, for example, the program for the information processing device 100 may be configured to be provided by being pre-installed in a ROM or the like.

[0074] The program executed by the information processing device 100 has a modular configuration including functions that can be realized by the program among the above-mentioned functional configurations. As for each function, as actual hardware, the processor 201 reads the program from a storage medium and executes it, and the above-mentioned functional blocks are loaded onto the main storage device 202. In other words, the above-mentioned functional blocks are generated on the main storage device 202.

[0075] Note that some or all of the above-described functions may be realized by hardware such as an integrated circuit (IC) instead of by software.

[0076] Furthermore, each function may be realized using a plurality of processors 201. In this case, each processor 201 may realize one of the functions, or may realize two or more of the functions.

[0077] Although some embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included in the scope and spirit of the invention, and are included in the scope of the invention and its equivalents described in the claims. [Explanation of symbols]

[0078] 1 Generation part 2. Vulnerability Risk Calculation Section 3 Specific part 4. Correction section 5. Equipment Risk Calculation Department 6 Output section 100 Information processing device 101 Dependency information DB 102 ACL DB 103 Asset Importance Information DB 201 Processor 202 Main storage 203 Auxiliary storage device 204 Display device 205 Input Device 206 Communication Equipment 210 Bus

Claims

1. a generation unit that generates dependency information including an executing user of a first evaluation target and a dependency relationship that has a dependency relationship with the first evaluation target, and resource access authority information; an identification unit that identifies resources that can be accessed by the first evaluation target based on the execution user and the access authority information; a vulnerability risk calculation unit that calculates a vulnerability risk indicating a risk level for each vulnerability based on a resource accessible by the first evaluation target and one or more pieces of vulnerability information; An information processing device comprising:

2. the first evaluation target is a first program, The dependency relationship includes information indicating a second program on which the first program depends. The information processing device according to claim 1 .

3. the generation unit analyzes a first program to identify the second program, and generates dependency information including the identified second program; the identifying unit identifies a resource accessible by the first program when the one or more pieces of vulnerability information include vulnerability information of the second program. The information processing device according to claim 2 .

4. The vulnerability risk calculation unit calculates the vulnerability risk further based on the asset importance of the resource. The information processing device according to claim 1 .

5. The asset importance includes at least one of a confidentiality importance of the resource, a security importance of the resource, and an availability importance of the resource. The information processing device according to claim 4.

6. The identification unit identifies an available operation for the resource from the access authority information, The vulnerability risk calculation unit calculates the vulnerability risk further based on an operation that can be performed on the resource. The information processing device according to claim 5 .

7. the vulnerability risk calculation unit determines an attackability of the specific vulnerability based on whether or not there is an identification code, which is a program for checking whether or not there is a specific vulnerability in at least one of the first program and the second program, or whether or not there is an attack campaign against the specific vulnerability, and calculates the vulnerability risk of the specific vulnerability further based on the attackability of the specific vulnerability; The information processing device according to claim 2 .

8. a correction unit that, when the one or more pieces of vulnerability information include a vulnerability that allows at least one of the first program and the second program to be operated by another user, performs a correction to add a resource accessible by the other user to a range of resources accessible by the first program; The information processing apparatus according to claim 2 , further comprising:

9. a correction unit that corrects a range of resources accessible to the first program to all resources when the one or more pieces of vulnerability information include a kernel vulnerability that enables at least one of the first program and the second program to operate in a privileged mode; The information processing device according to claim 8.

10. an equipment risk calculation unit that calculates an equipment risk indicating a vulnerability risk in the equipment based on the plurality of vulnerability risk levels when a plurality of vulnerability risk levels are calculated for the equipment to be evaluated; The information processing apparatus according to claim 1 , further comprising:

11. an output unit that outputs an evaluation result including at least one of the vulnerability risk level and the equipment risk by at least one of display information or sound; The information processing apparatus according to claim 10 , further comprising:

12. the first evaluation target is a first service realized by one or more programs; The dependency relationship includes information indicating a second service on which the first service depends. The information processing device according to claim 1 .

13. generating dependency information including execution user information of a first evaluation target and dependency information having a dependency relationship with the first evaluation target, and resource access authority information by an information processing device; a step of the information processing device identifying a resource that the first evaluation target can access based on the effective user information and the access authority information; a step of calculating a vulnerability risk level indicating a risk level for each vulnerability from a resource accessible by the first evaluation target and one or more pieces of vulnerability information by the information processing device; An information processing method comprising:

14. Computer, a generating unit that generates dependency information including execution user information of a first evaluation target and dependency information having a dependency relationship with the first evaluation target, and resource access authority information; an identification unit that identifies resources that can be accessed by the first evaluation target based on the actual user information and the access authority information; a vulnerability risk calculation unit that calculates a vulnerability risk indicating a risk level for each vulnerability based on a resource accessible by the first evaluation target and one or more pieces of vulnerability information; A program to function as a

Images