Security measures management device and method

Abstract

To enable efficient implementation of measures against vulnerabilities in a manner that suppresses adverse effects on a computer system.SOLUTION: A security measures management device comprises: a configuration information storage unit that stores information related to a management target system being a computer system to be managed; an analysis result storage unit that stores information related to results of analyses of respective threats that may be input to the management target system; an emergency response necessity determination unit that acquires vulnerability information being information related to a vulnerability, identifies a countermeasure-required threat caused by an attack utilizing the vulnerability on the basis of the information related to the management target system and the information related to the analysis results, and classifies the countermeasure-required threat into ones requiring an emergency response and ones not requiring an emergency response; and a residual risk monitoring unit that determines a degree of priority regarding implementation of measures at a current time for the countermeasure-required threats classified as not requiring an emergency response.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a technique for managing the implementation of countermeasures against threats related to the security of a computer system. [Background technology]

[0002] As DevSecOps development has become more widespread, computer system providers are now required to respond to security vulnerabilities that are newly disclosed after the computer system has been released as a product. To prevent damage or other adverse effects from occurring to a computer system, it is desirable to quickly implement countermeasures for newly disclosed vulnerabilities. However, because various security vulnerabilities are frequently discovered and information about new vulnerabilities is published daily, it is not easy for computer system providers to immediately implement countermeasures for all vulnerabilities. Therefore, it is necessary to efficiently implement countermeasures in order to appropriately mitigate adverse effects, such as damage, that may occur to a computer system.

[0003] In this regard, Patent Document 1 discloses a technique for evaluating the probability that a vulnerability will be exploited. The technique in Patent Document 1 acquires published vulnerability data and published attack code for exploiting the vulnerability, identifies the elapsed time for each vulnerability from the time the vulnerability data was published to the time the attack code for exploiting the vulnerability was published, and calculates the probability that each vulnerability will be exploited based on the distribution of the elapsed time. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] International Patent Publication No. WO2023 / 105590 Summary of the Invention [Problem to be solved by the invention]

[0005] As described above, the method of Patent Document 1 uses the elapsed time from when vulnerability data is made public to when exploit code is made public as an evaluation index. Therefore, the value of the vulnerability evaluation index is not determined until the exploit code is made public, making it unsuitable for triage decisions that include newly disclosed vulnerabilities with high urgency. Furthermore, vulnerabilities that experience a rapid increase in attack cases in a short period of time or vulnerabilities whose awareness rises rapidly in a short period of time tend to have a rapidly increasing likelihood of being exploited, and are therefore considered to require a high level of urgency to address. However, because the method of Patent Document 1 uses elapsed time as an evaluation index, it is unable to grasp the urgency of a rapidly increasing likelihood of exploitation. One objective of the present disclosure is to provide a technology that enables measures to be taken to efficiently suppress adverse effects on a computer system. [Means for solving the problem]

[0006] A security countermeasure management device according to one aspect included in the present disclosure has a configuration information storage unit that stores information about a managed system, which is a computer system to be managed; an analysis result storage unit that stores information about the results of analysis of each threat that may be input to the managed system; an emergency response necessity determination unit that acquires vulnerability information, which is information about vulnerabilities, and identifies threats requiring countermeasures due to attacks that exploit the vulnerabilities based on the information about the managed system and the information about the analysis results, and classifies the threats requiring countermeasures into those requiring emergency response and those not requiring emergency response; and a residual risk monitoring unit that determines the degree of priority for implementing countermeasures at the current time for threats requiring countermeasures classified as not requiring emergency response. [Effects of the Invention]

[0007] According to one aspect of the present disclosure, it is possible to efficiently implement countermeasures against vulnerabilities that limit adverse effects on computer systems. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a block diagram showing the functional configuration of a security measures management device according to an embodiment of the present invention; [Figure 2] 1 is a block diagram showing a hardware configuration of a security countermeasures management device according to an embodiment of the present invention; [Figure 3] 10 is a flowchart of a security countermeasure management process. [Figure 4] FIG. 10 is a diagram illustrating an example of software relationship information. [Figure 5] FIG. 10 is a diagram illustrating an example of a security analysis result. [Figure 6] FIG. 10 is a diagram illustrating an example of a security analysis result. [Figure 7] 10 is a flowchart of an emergency response necessity determination process. [Figure 8] FIG. 10 is a diagram illustrating an example of vulnerability information. [Figure 9] FIG. 10 is a diagram showing an implementation situation in which it is determined that no emergency response is required. [Figure 10] FIG. 10 is a diagram showing an implementation situation in which it is determined that an emergency response is required. [Figure 11] 10 is a flowchart of a residual risk monitoring process. [Figure 12] FIG. 10 is a diagram for explaining calculation of a trend value. [Figure 13] FIG. 10 is a diagram for explaining calculation of a threat trend value. [Figure 14] 10 is a flowchart of a security countermeasure implementation process. [Figure 15] FIG. 10 is a diagram showing an example of a screen display notifying that an emergency response is required. [Figure 16] FIG. 10 is a diagram showing an example of a screen display showing the priority order of measures. [Figure 17] FIG. 10 is a diagram showing an example of a screen display indicating measures that need to be implemented. [Figure 18] FIG. 10 is a diagram showing an example of a screen display showing measures that have been implemented. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. <Overview of security management device>

[0010] Fig. 1 is a block diagram showing the functional configuration of a security countermeasures management device according to this embodiment, and Fig. 2 is a block diagram showing the hardware configuration of a security countermeasures management device according to this embodiment.

[0011] The security measures management device 10 is a device that manages the implementation of security measures for computer systems. The computer systems that are managed by the security measures management device 10 may be systems applied to any product field or systems used for any business, and are not particularly limited.

[0012] 1, the security countermeasure management device 10 has, as functional blocks, a countermeasure implementation timing decision unit 11, a vulnerability information collection unit 14, a vulnerability information database (DB) 15, a security analysis unit 16, a security analysis result database 17, an SBOM database 18, and a security countermeasure implementation unit 19. The countermeasure implementation timing decision unit 11 has a residual risk monitoring unit 12 and an emergency response necessity determination unit 13. The residual risk monitoring unit 12 has a vulnerability information acquisition unit 20 for determining the long-term response necessity, an attack case collection unit 21, an academic information collection unit 22, a trend value calculation unit 23, a countermeasure priority update unit 24, a response decision and notification unit 25, and a trend information database 26. In addition, the emergency response necessity determination unit 13 has a vulnerability information acquisition unit 27 for determining whether emergency response is necessary, a vulnerability information conversion unit 28, an SBOM relationship information acquisition unit 29, a security analysis result acquisition unit 30, an information matching unit 31, and a response necessity determination unit 32. The countermeasure implementation timing decision unit 11 decides the timing for implementing countermeasures against the threat of attacks that exploit the vulnerability, for which information has been made public.

[0013] The emergency response necessity determination unit 13 acquires information about the published vulnerabilities, identifies threats that require countermeasures from among the threats posed by attacks that exploit those vulnerabilities, and determines whether or not the threats require emergency response. If there is currently a risk that the assets to be protected in the managed system would be harmed if an attack using that threat were to be carried out, then it is deemed that emergency response is necessary. On the other hand, if there is currently no risk that the assets to be protected in the managed system would be harmed if an attack using that threat were to be carried out, then it is deemed that emergency response is necessary. The timing for implementing countermeasures for threats that require emergency response is immediate.

[0014] The residual risk monitoring unit 12 determines the degree of priority for implementing countermeasures at the current time for threats that are determined not to require an emergency response, and determines the timing of implementing countermeasures according to the priority. For example, it may be determined that countermeasures are to be implemented periodically in descending order of priority. The function of each unit will be described later along with the processing flow.

[0015] On the other hand, referring to FIG. 2, the security measure management device 10 is a computer having, as hardware, a communication unit 41, a storage unit 42, a control unit 43, an input unit 44, and an output unit 45.

[0016] The communication unit 41 is a communication interface that enables the security measures management device 10 to communicate with other devices via communication networks such as the Internet, an intranet, a LAN (Local Area Network) or a WAN (Wide Area Network), or via wired connections such as a USB (Universal Serial Bus).

[0017] The storage unit 42 includes a nonvolatile storage device such as an HDD (Hard Disc Drive) or an SSD (Solid State Drive), and stores various programs such as application programs and programs for implementing functions according to the embodiments of the present invention. The storage unit 42 also at least temporarily stores information acquired by the communication unit 41 and the input unit 44, and various data (including intermediate data) generated by processing by the control unit 43. A database for storing such data may be constructed in the storage unit 42.

[0018] The control unit 43 is a computing device that controls the transmission and reception of data between each element and performs information processing necessary for application execution and authentication processing. For example, the control unit 43 is a CPU (Central Processing Unit) and / or GPU (Graphics Processing Unit), and performs each type of information processing by executing programs stored in the storage unit 42. The control unit 43 functions as each processing unit of the security measure management device 10 by executing the programs stored in the storage unit 42.

[0019] The input unit 44 is an input interface that accepts inputs for the user to operate the security measures management device 10, and can be configured, for example, with a keyboard, a mouse, a pointing device such as a joystick, a touch panel, an audio microphone, or any combination thereof. The output unit 45 is a display device that provides visual information such as the results of processing by the control unit 43 to the user.

[0020] As described above, the security measure management device 10 itself is configured, for example, by a computer, just like the managed objects. To avoid confusion with the management computers that configure the security measure management device 10, the computer system that is the managed object may be referred to as the managed system. <Security measures management process> The security countermeasure management process is a process for managing the implementation of security countermeasures in the managed system, and is an overall process executed by the security countermeasure management device 10. FIG. 3 is a flowchart of the security countermeasure management process.

[0021] In step S101, the SBOM relationship information acquisition unit 29 acquires software relationship information of the managed system in advance. At that time, the SBOM relationship information acquisition unit 29 adds information (association information) that associates each piece of software constituting the managed system with the components related to that software and the functions contributed by that software to the SBOM stored in advance in the SBOM database 18. The functions referred to here are functions as elements provided in a computer system, that is, protected assets. The SBOM with the association information added becomes software relationship information, and hereinafter this software relationship information may be referred to as SBOM relationship information. FIG. 4 is a diagram illustrating an example of software relationship information.

[0022] Referring to Figure 4, for each piece of software, the components related to that piece of software and the functions contributed by that piece of software are set. For example, software "S_01" is related to a web server, a database (DB) server, and an application (AP) server, and contributes to the "screen share" and "transfer control" functions. Software related to the web server includes software "S_01," software "S_02," and software "S_03." Furthermore, software "S_01" contributes to the function "screen share." Note that the table structure is based on the SBOM, and information is added to it to add component and function information to the software. However, the format of the table structure is not limited. Furthermore, components related to software and the functions contributed by the software may be stored using identification information such as an ID.

[0023] 3, in step S102, the security analysis unit 16 performs security analysis of the managed system. The security analysis is a process of analyzing security risks in the managed system, and the security analysis result is stored in the security analysis result database 17. 5 and 6 are diagrams showing examples of security analysis results.

[0024] As shown in Figures 5 and 6, the security analysis results include, for each threat that may be input to the managed system, the protected assets targeted by the threat, the CIA of the threat, the content of the threat, the security risk score of the threat, the attack path of the threat, and countermeasures against the threat. The CIA of the threat indicates which of the three security elements (confidentiality, integrity, and availability) the threat affects. The content of the threat is expressed by the entry point corresponding to "Where (from)," the target corresponding to "Where (to)," the "Who," the "Why," and the "What." The security risk score of the threat is calculated, for example, using the CVSS (CVSS-based Risk Scoring System) method.

[0025] For example, referring to FIG. 5, a threat with a threat ID of "F02-C-T1" has a protected asset identification information of "F02," a lost CIA of "C," an entry point of "Internet," a target of "DB server," and a threat of "leaking confidential information." Referring to FIG. 6, a threat with a threat ID of "F02-C-T1" has an attack path consisting of eight attack steps (1) to (8), and countermeasures are defined for each attack step. As an example, each attack step may be associated with an attack method ID that identifies the attack method extracted from a database of attack methods (not shown) that lists and classifies attack methods. The database of attack methods is, for example, MITRE ATT&CK.

[0026] For example, the attack step "(2) Investigate the target's IP address via the Internet" has the content "Scan the network via the Internet and check for a response." The countermeasure for this attack step has the countermeasure ID "M-10" and the content is "Configure so as not to respond to network scans (ping response)."

[0027] The column for whether the measure can be implemented shown in Figure 5 is a column for setting whether the measure can be implemented, cannot be implemented, can be implemented and there is a plan for its implementation, or there is no plan for its implementation. If the measure can be implemented, "Can be implemented" is set. If the measure cannot be implemented, "Not implemented" is set. If the measure can be implemented and there is a plan for its implementation, "Planned to be implemented" is set. If there is no plan for the measure, "No plan" is set.

[0028] The column for the planned implementation of the measure is a column for setting whether or not the implementation time has been determined when the measure is possible to implement (the column for whether or not the measure is possible is "possible"), or when the measure is possible to implement and there is a plan to implement it (the column for whether or not the measure is possible is "planned"). If the implementation time has been determined, a "○ (circle)" is set, and otherwise the column is left blank.

[0029] Returning to FIG. 3, in step S103, vulnerability information collection unit 14 periodically acquires vulnerability report information published from various information sources on the Internet and records it in vulnerability information database 15. Information sources for vulnerability reports include, for example, JVN (Japan Vulnerability Notes (JVN is a registered trademark)) and CVE. Vulnerability reports include detailed information indicating the content of the vulnerability, the expected impact of possible attacks, and countermeasures.

[0030] In step S104, each unit of the emergency response necessity determination unit 13 cooperates to execute an emergency response necessity determination process. The emergency response necessity determination process is a process for determining whether an emergency response is necessary for a threat including an attack step that exploits a vulnerability whose information has been newly disclosed. <Emergency response necessity determination process> FIG. 7 is a flowchart of the emergency response necessity determination process. The emergency response necessity determination process is a process for determining whether or not the threat posed by an attack exploiting a vulnerability for which information has been newly made public requires an emergency response. The flow of the emergency response necessity determination process and a specific example of the process will be described below.

[0031] The emergency response necessity determination process is initiated when the emergency response necessity determination vulnerability information acquisition unit 27 acquires vulnerability information of newly disclosed software. Note that hereinafter, software for which vulnerability information has been made public may be referred to as vulnerable software. Hereinafter, as a specific example, it is assumed that vulnerability information regarding software S_02 has been made public. Therefore, software S_02 is vulnerable software.

[0032] When newly disclosed vulnerability information is acquired, in step S201, the vulnerability information conversion unit 28 analyzes the vulnerability information written in natural language to convert it into structured data, and identifies the entry point and type of attack that exploits the vulnerability.

[0033] Hereinafter, the entry points of attacks that exploit vulnerabilities identified here may be referred to as vulnerability entry points, and the types of attacks that exploit vulnerabilities identified here may be referred to as vulnerability attack types. FIG. 8 is a diagram illustrating an example of vulnerability information.

[0034] As shown in FIG. 8, some vulnerability information is written in natural language. In this case, the vulnerability information conversion unit 28 performs natural language analysis on the vulnerability information to identify the entry point and the type of attack. Here, the expected impact includes the statement "by a remote third party," so the vulnerability entry point is identified as the Internet. Furthermore, the title includes the statement "privilege escalation vulnerability," so the vulnerability attack type is identified as "privilege escalation." Note that if the vulnerability information is disclosed as structured or semi-structured information rather than in natural language, the entry point and the type of attack can be identified without the need for natural language analysis.

[0035] Next, in step S202, the SBOM relationship information acquisition unit 29 acquires the SBOM relationship information of the managed system, and the information matching unit 31 refers to the SBOM relationship information to confirm whether the vulnerable software exists in the managed system.

[0036] If the vulnerable software does not exist in the managed system, the process for determining whether or not an emergency response is necessary ends. Here, it is assumed that the vulnerable software exists in the managed system.

[0037] Next, in step S203, the information collating unit 31 refers to the SBOM relationship information and identifies the components to which the vulnerable software is related and the functions (protected assets) to which the vulnerable software contributes. Here, from the SBOM relationship information shown in Fig. 4, it is identified that the components to which software S_02 is related are the Web server, DB server, and AP server, and that the function to which software S_02 contributes is transfer control. Here, it is assumed that the identification information of transfer control is F02. Next, in step S204, the information matching unit 31 checks whether the identified component can be an entry point for an attack that exploits the vulnerability.

[0038] Here, the components associated with the vulnerable software, software S_02, are identified as a web server, a DB server, and an AP server, and it is confirmed that the entry point of the attack is the Internet, so the information matching unit 31 determines whether the web server, DB server, and AP server can be the Internet, and determines that they cannot.

[0039] Next, in step S205, the information matching unit 31 refers to the part of the function identified in S203 in the security analysis results, and identifies a threat whose Where (from) is the vulnerability entry point identified in S201 and whose Where (to) is a component identified in S203 that was determined not to be an entry point in S204.

[0040] Here, from the security analysis results shown in FIG. 5, threats with threat IDs F02-C-T1, F02-C-T2, F02-CI-T1, F02-CI-T2, . . . are identified as threats requiring countermeasures.

[0041] Next, in step S206, the information matching unit 31 refers to the attack path in the security analysis result for the threat identified in step S205, and checks whether the attack path includes an attack step that corresponds to the vulnerability attack type identified in step S201. If the attack path of the threat identified in step S205 does not include an attack step that corresponds to the vulnerability attack type, the emergency response necessity determination process ends. If the attack path of the threat identified in step S205 includes an attack step that corresponds to the vulnerability attack type, the threat is identified as a threat that requires countermeasures (a countermeasure-requiring threat).

[0042] Next, in step S207, the response necessity determination unit 32 refers to the security analysis result and determines whether or not measures have been taken for attack steps other than the attack steps corresponding to the vulnerability attack types in the threats requiring measures. Here, "measures have been taken" includes not only cases where measures have already been taken, but also cases where implementation is planned.

[0043] Furthermore, the response necessity determination unit 32 determines that the countermeasure-required threat does not require an emergency response if an attack step for which a countermeasure has been taken is included among attack steps other than those related to the vulnerability attack type.

[0044] Figure 9 shows the implementation status where it is determined that no emergency response is required. Figure 9 shows the security analysis results for threats that require countermeasures, and the attack step (6) enclosed in a thick rectangle is the attack step of an attack that exploits a newly disclosed vulnerability. Looking at the other attack steps, it is determined that no emergency response is required because countermeasures have been taken for the attack steps indicated by the arrows.

[0045] On the other hand, if measures have not been taken for all attack steps other than the attack steps related to the vulnerability attack type, the action necessity determining unit 32 determines that the threat requiring action is one that requires an emergency action.

[0046] Figure 10 shows the implementation status that is judged to require an emergency response. Figure 10 shows the security analysis results for the threat requiring countermeasures, and the attack step (3) enclosed in a thick rectangle is the attack step of an attack that exploits a newly disclosed vulnerability. Looking at the other attack steps, it is judged that an emergency response is required because countermeasures have not been taken against any of the attack steps. <Residual risk monitoring process> FIG. 11 is a flowchart of the residual risk monitoring process.

[0047] The residual risk monitoring process observes the remaining risk of each threat that was determined not to require an emergency response in the emergency response necessity determination process, and assigns a priority to the implementation of countermeasures. Because the residual risk of each threat changes over time, the residual risk monitoring process is continuously and repeatedly executed at time intervals, and the priority is updated.

[0048] Each attack step that constitutes the attack path of each threat can be associated with one of the attack methods in the classification system of the attack method database. MITRE ATT&CK is a well-known example of an attack method database. Then, vulnerability information published on various security-related websites is collected, and the number of times each attack method is published within a certain period of time is tallied. The total number of times each attack method corresponds to an attack step can be used as an index to estimate the risk of an attack using that attack step. Empirical evidence has shown that there is a correlation between increases and decreases in the frequency of vulnerability information publication and increases and decreases in the risk of attacks exploiting that vulnerability. By utilizing this correlation, it is possible to capture risk trends that fluctuate over time as an index. This index is then used to determine the priority of countermeasure implementation. The vulnerability information referred to here includes information reporting vulnerabilities, information on attack cases, and information on papers.

[0049] Therefore, prior to the residual risk monitoring process, the vulnerability information acquisition unit 20 for determining the necessity of long-term measures acquires, from the vulnerability information database 15, information reporting vulnerabilities that have been made public in a recent fixed period.

[0050] The attack case collection unit 21 also collects information on attack cases that have been made public over a recent period. Sources of attack cases include, for example, domestic government-related media, overseas security media, and private security media. Domestic government-related media include, for example, JPCERT / CC (Japan Computer Emergency Response Team Coordination Center), NISC (National Center of Incident Readiness and Strategy for Cybersecurity), IPA (Information-technology Promotion Agency, Japan), and JNSA (Japan Network Security Association, a non-profit organization; JNSA is a registered trademark). Overseas security media include CISA (Cybersecurity and Infrastructure Security Agency, a registered trademark) from the United States, WIRED (WIRED is a registered trademark), and The Register from the United Kingdom. Private security media include ScanNetSecurity (registered trademark), Internet Watch (registered trademark), ZDNet Japan (ZDNet is a registered trademark), ITmedia Enterprise (ITmedia is a registered trademark), Mynavi News TECH+ (Mynavi and TECH+ are registered trademarks), and ESET (Cybersecurity Intelligence Bureau, ESET is a registered trademark). Attack cases include information about attacks that have been carried out by exploiting vulnerabilities.

[0051] The academic information collection unit 22 also collects information on papers about attacks that have been published in the recent past within a certain period of time. Sources of information for these papers include, for example, databases compiled by security-related organizations and programs of academic symposiums related to security. The residual risk monitoring process will be described below with reference to FIG. In step S301, each threat is processed in turn, and the process is repeated the number of times equal to the number of threats.

[0052] In step S302, each attack step constituting the attack path of the threat being processed is processed in order, and the process is repeated the number of times equal to the number of attack steps.

[0053] In step S303, the attack methods associated with the attack steps that constitute the attack path of the threat being processed are processed in order, and the process is repeated the number of times equal to the number of attack methods. In step S304, the trend value calculation unit 23 calculates a trend value, which is an index value for estimating the risk of an attack of the attack method being processed. As described above, the attack steps are associated with attack techniques extracted from a database of attack techniques, with MITRE ATT&CK being one example.

[0054] The trend value calculation unit 23 calculates the number of times information reporting vulnerabilities over a certain period acquired by the vulnerability information acquisition unit 20 for determining the need for long-term response, the information on attack cases over a certain period collected by the attack case collection unit 21, and the information on papers over a certain period collected by the academic information collection unit 22, and sets the total value of these as the trend value.

[0055] Fig. 12 is a diagram for explaining how to calculate a trend value. In the example of Fig. 12, the number of times information reporting vulnerabilities related to attack technique PE01 has been published is 4, the number of times information on attack examples has been published is 8, and the number of times information on papers has been published is 7. Therefore, the trend value is 4 + 8 + 7 = 19.

[0056] After the trend values ​​of all attack methods corresponding to all attack steps constituting the attack path of the threat being processed are calculated by the repeated processing of steps S302 and S303, the trend value calculation unit 23 then calculates a threat trend value, which is an index value for estimating the risk of the threat being processed, in step S305. At this time, the trend value calculation unit 23 calculates the total value of the trend values ​​of all attack methods corresponding to all attack steps constituting the attack path of the threat being processed as the threat trend value of that threat.

[0057] Fig. 13 is a diagram for explaining the calculation of a threat trend value. In the example of Fig. 13, using a threat with a threat ID of "F02-C-T1" as an example, information on each attack step included in the threat, the attack method ID of each attack method corresponding to the attack step, the trend value of the attack method, and the threat trend value which is the sum of the trend values ​​of the attack methods are shown.

[0058] When the threat trend values ​​of all threats are calculated by the repeated processing in step S303, the countermeasure priority update unit 24 then prioritizes each threat based on the threat trend value in step S306.

[0059] Note that, although an example has been shown here in which the sum of the trend values ​​of the attack methods corresponding to each attack step in the attack path of a threat is used as the threat trend value of the threat, the method of calculating the threat trend value is not limited to this. As another example, the sum of values ​​obtained by multiplying the trend values ​​of the attack methods corresponding to each attack step in the attack path by a weight (coefficient) according to the depth of the attack step in the attack path may be calculated as the threat trend value. In this case, the weight may be set to be lighter the deeper the attack step in the attack path, from the perspective that it is more difficult for an attack to reach the deeper attack step in the attack path. Furthermore, the weight may be set to be heavier the deeper the attack step in the attack path, from the perspective that it is more likely for an attack to reach the target if that attack step is breached. <Security measures implementation process>

[0060] The security countermeasure implementation process focuses on a threat that includes an attack that exploits a disclosed vulnerability as an attack step, and is a series of processes related to implementing countermeasures against that threat. FIG. 14 is a flowchart of the security countermeasure implementation process.

[0061] When a vulnerability report is made public, in step S401, the emergency response necessity determination unit 13 determines whether or not an emergency response is required for a threat including an attack that exploits the vulnerability, using the emergency response necessity determination process described above.

[0062] If it is determined that an emergency response is required, the emergency response necessity determining unit 13 notifies the security manager in step S402 by displaying a message on the screen indicating that an emergency response is required. FIG. 15 is a diagram showing an example of a screen display notifying that an emergency response is required.

[0063] 15, emergency response display screen 50 shows vulnerability ID display 51 that identifies the vulnerability that is the source of the threat, notification display 52 that an emergency response is required, countermeasure information display 53, and details button display 54. Countermeasure information display 53 shows, for the countermeasure, the component that is the target of the countermeasure, the countermeasure content, identification information (threat ID) of the threat that is the target of the countermeasure, the vulnerable location of each attack step included in the attack path of the threat, and the threat trend value of the threat. Clicking on details button display 54 displays the security analysis results of the threat. In step S403, the security countermeasures manager implements countermeasures with the support of the security countermeasures implementation unit 19.

[0064] On the other hand, if a threat is determined not to require an emergency response, no response is made at that time (step S404), and the threat is subjected to the above-mentioned residual risk monitoring process. The residual risk monitoring process continuously calculates the threat trend value of the threat at a predetermined time interval, and assigns a priority to the implementation of countermeasures.

[0065] Then, in step S405, the security measure implementation unit 19 compares the threat trend value with a predetermined threshold and determines whether or not a measure should be implemented at the present time. If the threat trend value exceeds the threshold, it is determined that a measure should be implemented at the present time. If the threat trend value does not exceed the threshold, it is determined that a measure does not need to be implemented at the present time.

[0066] If it is determined that measures should be implemented at this time, the security measures implementation unit 19 notifies the security measures manager by displaying a notice on the screen that measures should be implemented at this time in step S402. The security measures manager implements measures with the support of the security measures implementation unit 19 in step S403.

[0067] On the other hand, for threats that are determined in step S405 not to be serious enough to warrant the implementation of countermeasures at this time, in step S406 the security countermeasure implementation unit 19 determines whether or not the implementation of countermeasures should be included in the plan, depending on whether or not the priority of the threat is within a predetermined high rank. FIG. 16 is a diagram showing an example of a screen display showing the priority order of countermeasures.

[0068] 16, a countermeasure priority order display screen 60 lists the countermeasures in order of priority, and for each countermeasure, a priority order display 61, countermeasure information display 62, and a details button display 63 are displayed. The countermeasure information display 62 displays, for the countermeasure, the component targeted by the countermeasure, the countermeasure content, identification information (threat ID) of the threat targeted by the countermeasure, vulnerable points in each attack step included in the attack path of the threat, and the threat trend value of the threat. Clicking the details button display 63 displays the security analysis results of the threat.

[0069] If the priority is within the predetermined high level, it is judged that the implementation of the countermeasure should be included in the plan. If the priority is not within the predetermined high level, it is judged that the implementation of the countermeasure is not worth including in the plan. FIG. 17 is a diagram showing an example of a screen display showing measures that need to be implemented.

[0070] 17, a countermeasure requirement display screen 70 displays a priority order display 71 for countermeasures that need to be implemented, i.e., countermeasures whose implementation should be included in a plan, a countermeasure information display 72, and a details button display 73. The countermeasure information display 72 displays, for the countermeasure, the component that is the target of the countermeasure, the countermeasure content, identification information (threat ID) of the threat that is the target of the countermeasure, the vulnerable points of each attack step included in the attack path of the threat, and the threat trend value of the threat. Clicking the details button display 73 displays the security analysis results of the threat.

[0071] If it is determined that the implementation of measures should be included in the plan, then in step S403 the security measures manager implements the measures in accordance with the implementation plan with the support of the security measures implementation unit 19. On the other hand, if it is determined that the implementation of measures is not worth including in the plan, the process returns to step S404 after a certain period of time has elapsed.

[0072] After the countermeasure is implemented in step S403, the security countermeasure implementation unit 19 then updates the security analysis result in step S407. Specifically, a "◯ (circle)" is added to the column for the planned implementation of the countermeasure in the security analysis result shown in Fig. 6. Furthermore, in step S408, the security countermeasure implementation unit 19 records information about the countermeasure in a database of implemented countermeasures (not shown). Measures recorded in the database of implemented measures can be viewed from the Implemented Measures screen. FIG. 18 is a diagram showing an example of a screen display showing measures that have been implemented.

[0073] 18, an implemented countermeasure display screen 80 displays, for implemented countermeasures, a display 81 indicating that the countermeasure has been implemented, a display 82 of information about the countermeasure, and a details button display 83. The countermeasure information display 82 displays, for the countermeasure, the component targeted by the countermeasure, the countermeasure content, identification information (threat ID) of the threat targeted by the countermeasure, the vulnerability points of each attack step included in the attack path of the threat, and the threat trend value of the threat. Clicking the details button display 83 displays the security analysis results of the threat.

[0074] If the implementation of the countermeasure is triggered by the need for an emergency response (Yes in S401) or the need to implement the countermeasure at the present time (Yes in S405), in step S409, the security countermeasure implementation unit 19 erases the notification output on the screen in step S402 and terminates the security countermeasure implementation process.

[0075] On the other hand, if the implementation of the measure was triggered by the priority being within a predetermined high rank, the security measure implementation unit 19 deletes the measure from the priority display in step S410, updates the priority of the measure, and terminates the security measure implementation process.

[0076] The above-described embodiments are merely examples for explaining the present invention, and are not intended to limit the scope of the present invention to these embodiments. Those skilled in the art can implement the present invention in various other forms without departing from the scope of the present invention. This embodiment also includes the following features, but the features included in this embodiment are not limited to those listed below. (Item 1)

[0077] a configuration information storage unit that stores information about a managed system, which is a computer system to be managed, an analysis result storage unit that stores information about the results of analyses of each threat that may be input to the managed system, an emergency response necessity determination unit that acquires vulnerability information, which is information about vulnerabilities, and identifies threats requiring countermeasures due to attacks that exploit the vulnerabilities based on the information about the managed system and the information about the results of the analysis, and classifies the threats requiring countermeasures into those requiring emergency response and those not requiring emergency response, and a residual risk monitoring unit that determines the level of priority for implementing countermeasures at this time for threats requiring countermeasures that are classified as not requiring emergency response. This makes it possible to implement countermeasures against vulnerabilities that minimize adverse effects on the computer system, taking into account the need for countermeasures against threats, the need for emergency response, and the level of priority. (Item 2)

[0078] In the security measure management device described in item 1, the analysis result includes the attack path of the threat, and the emergency response necessity determination unit determines whether an emergency response is necessary based on whether or not an attack step for which no countermeasures have been implemented is included among attack steps in the attack path other than the attack step of the attack that exploits the vulnerability. This makes it possible to appropriately determine whether or not an emergency response is necessary from the perspective of whether or not an attack can be carried out. (Item 3)

[0079] In the security measure management device described in item 2, the residual risk monitoring unit calculates a threat index value, which is an index value for estimating the risk of a threat, based on an index value indicating the risk of an attack by an attack method corresponding to each attack step in the attack path of the threat. In this way, the risk of a threat is calculated based on the risk of an attack by an attack method corresponding to each attack step in the attack path of the threat, so it is possible to monitor the trend of the threat risk, which changes over time, based on information about the attack method. (Item 4)

[0080] In the security measure management device described in item 3, the residual risk monitoring unit counts the number of times that vulnerability report information, case information of attacks exploiting the vulnerability, and / or academic information related to the vulnerability is published within a predetermined period, and calculates an index value of the attack method corresponding to the attack step of the attack exploiting the vulnerability based on the number of times. This makes it possible to capture the trend of risk that fluctuates over time as an index value by utilizing the correlation between the increase and decrease in the publication frequency of vulnerability report information, attack case information, and academic information related to the vulnerability and the increase and decrease in the risk of attacks exploiting the vulnerability. (Item 5)

[0081] In the security measure management device described in item 3, the residual risk monitoring unit continuously calculates the threat index value at predetermined time intervals, and when the threat index value exceeds a predetermined threshold, outputs a notification that it is time to implement measures against the threat. This notifies the user that measures are necessary when the possibility of an attack increases, making it possible to avoid attacks in advance. (Item 6)

[0082] In the security measure management device described in item 3, the residual risk monitoring unit calculates the threat index value as the sum of index values ​​of attack methods corresponding to each attack step in the attack path of the threat. This makes it possible to appropriately calculate the risk of a threat from the risk of each attack step in the attack path of the threat. (Item 7)

[0083] In the security measure management device described in item 3, the residual risk monitoring unit calculates the threat index value as the sum of values ​​obtained by multiplying the index value of the attack method corresponding to each attack step in the attack path by a weight according to the depth of the attack step in the attack path. This makes it possible to more appropriately calculate the risk of a threat when the impact of the risk of each attack step on the risk of the threat differs depending on the depth of each attack step in the attack path of the threat. (Item 8)

[0084] In the security measure management device described in item 1, the emergency response necessity determination unit presents information indicating whether the threat requiring countermeasures requires emergency response or not. This makes it easy to know whether the threat requiring countermeasures requires emergency response. (Item 9)

[0085] In the security countermeasure management device described in item 1, the residual risk monitoring unit presents information in which the threats requiring countermeasures are ranked according to the degree of priority. This makes it easy to know the priority of the threats requiring countermeasures. (Item 10)

[0086] In the security measure management device described in item 1, the information about the managed system is software relationship information indicating managed system software, which is software included in the managed system, managed system components, which are components that configure the managed system and to which each of the managed system software is related, and managed system protected assets, which are protected assets provided in the managed system and to which each of the managed system software contributes; and the information about the results of the analysis is security analysis result information including, for each threat that may be input to the managed system, threat protected assets, which are protected assets affected by the threat, threat entry points, which are entry points of the threat, threat targets, which are targets of the threat, and threat attack steps, which indicate attack steps that configure the attack path of the threat; and the emergency response necessity determination unit: determines vulnerable software, which is software that corresponds to a vulnerability, and vulnerability entry points, which are entry points of an attack that utilizes the vulnerability. acquire vulnerability information that enables the determination of the vulnerability entry point and the vulnerability attack type that is the type of attack, identify the components in the managed system related to the software in the managed system that is vulnerable software and the protected assets in the managed system to which the software in the managed system that is vulnerable software contributes, identify threats that have the protected assets in the managed system as threat protection assets, whose threat entry point is the vulnerability entry point and whose threat target is a component in the managed system that cannot be the vulnerability entry point among the components in the managed system, determine as threats requiring countermeasures those threats that have an attack step related to the vulnerability attack type among the identified threats, determine whether countermeasures have been taken for attack steps other than the attack step related to the vulnerability attack type in the threats requiring countermeasures, and if an attack step for which countermeasures have been taken is included among the attack steps other than the attack step related to the vulnerability attack type, determine that the threat requiring countermeasures does not require an emergency response,If measures have not been taken for all attack steps other than the attack step related to the vulnerability attack type, the threat requiring countermeasures is determined to require an emergency response, and the residual risk monitoring unit: for the threat requiring countermeasures determined not to require an emergency response, calculates index values ​​indicating the risk of an attack using an attack method corresponding to each of the threat attack steps of the threat requiring countermeasures, calculates a threat index value for the threat requiring countermeasures based on the index values ​​of the attack methods corresponding to the threat attack steps, and assigns a priority for implementing countermeasures to the threat requiring countermeasures based on the threat index value on an ongoing basis. This makes it possible to identify the need for an emergency response and the priority for implementing countermeasures, taking into account the impact of the threat on the protected assets. (Item 11)

[0087] In the security measure management device described in item 10, the protected asset is a function provided in the managed system. This makes it possible to determine the need for emergency response and the priority of implementing measures, taking into account the impact of threats on the functions of the computer system. (Item 12)

[0088] A security countermeasure management method executed by a management computer, which includes the steps of: storing information about a managed system, which is a computer system to be managed; storing information about the results of analysis of each threat that may be input to the managed system; acquiring vulnerability information, which is information about vulnerabilities; identifying threats requiring countermeasures due to attacks that exploit the vulnerabilities based on the information about the managed system and the information about the results of the analysis; classifying the threats requiring countermeasures into those requiring emergency response and those not requiring emergency response; and determining the degree of priority for implementing countermeasures at the current time for threats requiring countermeasures classified as not requiring emergency response. [Explanation of symbols]

[0089] 10...Security measure management device, 11...Countermeasure implementation timing decision unit, 12...Residual risk monitoring unit, 13...Emergency response necessity determination unit, 14...Vulnerability information collection unit, 15...Vulnerability information database, 16...Security analysis unit, 17...Security analysis result database, 18...SBOM database, 19...Security measure implementation unit, 20...Vulnerability information acquisition unit for determining long-term response necessity, 21...Attack case collection unit, 22...Academic information collection unit, 23...Trend value calculation unit, 24 ...Countermeasure priority update unit, 25...Notification unit, 26...Trend information database, 27...Vulnerability information acquisition unit for determining whether emergency response is necessary, 28...Vulnerability information conversion unit, 29...SBOM relationship information acquisition unit, 30...Security analysis result acquisition unit, 31...Information matching unit, 32...Response necessity determination unit, 41...Communication unit, 42...Memory unit, 43...Control unit, 44...Input unit, 45...Output unit, 50...Emergency response display screen, 60...Countermeasure priority display screen, 70...Measures required display screen, 80...Countermeasure display screen

Claims

1. a configuration information storage unit that stores information about a managed system, which is a computer system to be managed; an analysis result storage unit that stores information about the results of analysis of each threat that may be input to the managed system; an emergency response necessity determination unit that acquires vulnerability information that is information about vulnerabilities, identifies threats requiring countermeasures due to attacks that exploit the vulnerabilities based on information about the managed system and information about the results of the analysis, and classifies the threats requiring countermeasures into those requiring emergency response and those not requiring emergency response; a residual risk monitoring unit that determines the degree of priority regarding the implementation of countermeasures at present for threats that require countermeasures and are classified as not requiring an urgent response; A security measures management device having the same.

2. The results of the analysis include attack vectors for the threats; the emergency response necessity determination unit determines whether an emergency response is necessary based on whether an attack step for which no countermeasure has been implemented is included among attack steps other than the attack step exploiting the vulnerability in the attack path; The security countermeasure management device according to claim 1 .

3. the residual risk monitoring unit calculates a threat index value, which is an index value for estimating the risk of a threat, based on index values ​​indicating the risk of an attack being carried out by an attack method corresponding to each attack step in the attack path of the threat; The security countermeasure management device according to claim 2 .

4. the residual risk monitoring unit counts the number of times that vulnerability report information, case information of attacks exploiting the vulnerability, and / or academic information on the vulnerability has been published within a predetermined period, and calculates an index value of an attack technique corresponding to an attack step in an attack exploiting the vulnerability based on the number of times; The security countermeasure management device according to claim 3 .

5. the residual risk monitoring unit continuously calculates the threat index value at predetermined time intervals, and when the threat index value exceeds a predetermined threshold, outputs a notification that a state has arisen in which measures against the threat should be implemented. The security countermeasure management device according to claim 3 .

6. the residual risk monitoring unit calculates, as the threat index value, a sum of index values ​​of attack methods corresponding to each attack step in the attack path of the threat; The security countermeasure management device according to claim 3 .

7. the residual risk monitoring unit calculates, as the threat index value, a sum of values ​​obtained by multiplying the index value of the attack method corresponding to each attack step in the attack path by a weight according to the depth of the attack step in the attack path; The security countermeasure management device according to claim 3 .

8. the emergency response necessity determination unit presents information indicating whether the threat requiring countermeasure is one that requires an emergency response or not; The security countermeasure management device according to claim 1 .

9. the residual risk monitoring unit presents information in which the threats requiring countermeasures are ranked according to the degree of priority; The security countermeasure management device according to claim 1 .

10. The information related to the managed system is software relationship information indicating managed system software, which is software included in the managed system; managed system components, which are components constituting the managed system and to which each of the managed system software is related; and managed system protected assets, which are protected assets provided in the managed system and to which each of the managed system software contributes; The information regarding the results of the analysis is security analysis result information including, for each threat that may be input to the managed system, a threat protection asset that is a protection asset affected by the threat, a threat entry point that is an entry point of the threat, a threat target that is a target of the threat, and a threat attack step that indicates an attack step that constitutes an attack path of the threat, The emergency response necessity determination unit: Acquire vulnerability information that enables the user to know vulnerable software, which is software to which a vulnerability applies, a vulnerability entry point, which is an entry point of an attack that exploits the vulnerability, and a vulnerability attack type, which is a type of the attack; Identifying components in the managed system related to the software in the managed system that is the vulnerable software and protected assets in the managed system to which the software in the managed system that is the vulnerable software contributes; Identifying threats that have the managed system protection asset as a threat protection asset, the threat entry point of which is the vulnerability entry point, and the threat target of which is a component in the managed system that cannot be the vulnerability entry point among the components in the managed system; Among the identified threats, a threat having an attack step related to the vulnerability attack type among its threat attack steps is designated as a threat requiring countermeasures, and it is determined whether or not countermeasures have been taken for attack steps other than the attack step related to the vulnerability attack type in the threat requiring countermeasures; If an attack step for which a countermeasure has been taken is included among attack steps other than the attack steps related to the vulnerability attack type, the threat requiring countermeasures is determined not to require an emergency response, If countermeasures for all attack steps other than the attack steps related to the vulnerability attack type have not been completed, the threat requiring countermeasures is determined to require an urgent response, The residual risk monitoring unit: For threats that require countermeasures that are determined not to require an emergency response, calculate index values ​​indicating the risk of an attack using an attack method corresponding to each of the threat attack steps of the threat that requires countermeasures, calculate a threat index value for the threat that requires countermeasures based on the index values ​​of the attack methods corresponding to the threat attack steps, and assign a priority for implementing countermeasures to the threat that requires countermeasures based on the threat index values. The security countermeasure management device according to claim 1 .

11. The protected assets are functions provided in the managed system. The security countermeasure management device according to claim 10.

12. storing information about a managed system, which is a computer system to be managed; storing information regarding the results of an analysis of each of the threats that may be input to the managed system; acquiring vulnerability information that is information about vulnerabilities, identifying threats requiring countermeasures due to attacks that exploit the vulnerabilities based on information about the managed system and information about the results of the analysis, and classifying the threats requiring countermeasures into those requiring an emergency response and those not requiring an emergency response; Determine the current priority of implementing countermeasures for threats that are classified as not requiring an urgent response; A security measure management method that is implemented by a management computer.

Images