Cybersecurity Risk Integrated Assessment and Response Prioritization System

Abstract

When numerous vulnerability findings are detected in an organization's publicly held assets, simply examining the technical severity and operational impact individually presents a challenge: it becomes difficult to determine a unique priority for response, leading to inconsistent procedures. [Solution] A basic technical risk index is calculated from the publicly available vulnerability score and the exploit prediction score. An effective technical risk index is calculated by asymmetrically applying a priority reduction correction based on quality classification based on the detection source, an independent priority reduction correction based on the results of active verification, and a priority increase correction based on matching the known exploit catalog. This is then combined with a business impact index calculated from three independent tags: application, confidentiality, and availability, to present an integrated risk band and an estimated response time.

Description

Technical Field

[0001] The present invention relates to cybersecurity technology, and particularly to a cybersecurity risk integrated evaluation and response priority presentation system that calculates a response priority integrating technical severity and business impact for vulnerability findings detected in public assets owned by an organization, and presents the response priority together with an estimated response time. As used herein, "vulnerability finding" refers to a data item indicating that a specific vulnerability or improper configuration has been observed with respect to a specific public asset. "Public asset" refers to information technology resources (FQDNs, IP addresses, service ports, web applications, API endpoints, etc.) that are publicly disclosed by an organization or are in a state accessible from the outside. As used herein, "public vulnerability score" is a general term for widely used vulnerability severity indicators as industry standards, including the Common Vulnerability Scoring System (CVSS) published by the National Institute of Standards and Technology (NIST) of the United States, and is not limited to a specific indicator system or its numerical range. Similarly, "exploit prediction score" is a general term for widely used exploit prediction indicators as industry standards, including the Exploit Prediction Scoring System (EPSS) published by FIRST of the United States, and is not limited to a specific indicator system or its numerical range. The specific selection of these indicators and the boundary threshold used for discretization do not limit the functional requirements of the present invention, and the present invention functions under the broad indicator concept.

Background Art

[0002] In recent years, the number of publicly available assets held by organizations has been steadily increasing, and the number of observed vulnerability findings has also increased proportionally. Industry-standard indicators such as the Common Vulnerability Scoring System (CVSS) published by the U.S. National Institute of Technology (NIST), the Exploit Prediction Scoring System (EPSS) published by FIRST, and the Known Exploited Vulnerabilities Catalog (KEV) published by CISA are widely used to assess the severity of vulnerability findings. The use of a combination of these industry-standard indicators for evaluation is also indicated in the "Summary of Risk Assessment Methods for Vulnerability Response ver1.1" (published July 2024) by the Information-technology Promotion Agency, Japan (IPA). This guideline describes a method for evaluating CVSS, EPSS, Stakeholder-Specific Vulnerability Categorization (SSVC, published by SEI CMU in the US), and KEV by discretizing them into three stages (Non-Patent Literature 1). Furthermore, SSVC v2.0 proposes a method that combines multiple indicators in a decision tree (Non-Patent Literature 2). Regarding patent documents, U.S. Patent No. 10,372,915 (Patent Document 1) discloses a technology for mapping and visualizing vulnerabilities and their severity on two axes (application ranking and network location), and U.S. Patent No. 11,201,891 (Patent Document 2) discloses a technology for weighting and synthesizing asset importance and exploitability. Furthermore, U.S. Patent Application Publication No. 2024 / 0250979 (Patent Document 3) proposes exploitation prediction using multiple models based on machine learning. In Japan, JP 2025-516572 (Patent Document 4) discloses a technology for dynamically calculating vulnerability priority scores using contextual features and CVSS, and the presentation of risk response proposals is known as a related technology of the integrated risk management platform commercialized by Nippon Telegraph and Telephone Corporation (Non-Patent Document 3). However, these conventional indicators and prior patents all focus on the technical characteristics of the vulnerability itself or the predicted probability of exploitation, and do not directly reflect the degree to which the asset in which the vulnerability is observed impacts the organization's operations. In other words, although the actual damage and the urgency of response are clearly different when a CVSS 10.0 vulnerability exists only in an organization's internal testing environment compared to when a CVSS 6.0 vulnerability exists in a core system handling customer personal information, conventional response priority calculations based solely on technical indicators cannot express the difference between the two. Furthermore, factors such as the combination of detection sources (whether it's multiple detection where the same finding is detected from multiple sources, or detection relying solely on a single publicly available database), whether existence is confirmed through active non-destructive verification, and the degree of agreement with the known exploit catalog, which shows the actual history of the vulnerability being exploited in attacks, all significantly influence the reliability of the findings. Nevertheless, a mechanism for uniformly and asymmetrically reflecting these factors in the score and presenting it in a format that allows operations teams and management to share the same indicators has not been adequately developed in conventional literature, including the aforementioned patent and non-patent documents. In particular, Patent Document 1 employs a format in which vulnerabilities and their severity are arranged in a 5x5 cell matrix composed of application ranking and network location. However, this matrix consists only of technical indicators and does not disclose any of the following: (a) a mechanism for independently evaluating business impact as a sum of three axes: usage, data confidentiality classification, and availability requirements; (b) a bidirectional correction mechanism that asymmetrically combines detection evidence quality, known exploit boost, and active verification penalty; (c) a mechanism for maintaining and making referable recommended response time estimates for each band as an internal master; or (d) a mechanism for finally discretely classifying into five bands: S / A / B / C / D. Furthermore, Patent Document 4 only outputs priority as a single continuous score and does not describe asymmetric bidirectional correction between detection evidence quality and active verification results. Here, Non-Patent Document 1 (Information-technology Promotion Agency, Japan (IPA) "Summary of Risk Assessment Methods for Vulnerability Response ver1.1", published July 2024) discloses a method of discretizing CVSS, EPSS, SSVC, and KEV into three stages and then combining them in stages, and Non-Patent Document 2 (Spring et al. "SSVC v2.0", 2021) discloses a method of combining multiple indicators in a decision tree type. However, Non-Patent Documents 1 and 2 do not disclose or suggest any of the following: (i) the motivation for asymmetric bidirectional correction that applies priority reduction correction based on detection evidence quality and priority increase correction based on known exploit catalog matching in different directions and with different strengths; (ii) the motivation for designing to avoid double counting by treating the verification results by the active verification unit as a correction term independent of detection evidence quality; or (iii) the motivation for designing to sum business impacts by simple addition from three independent tags: application, data confidentiality classification, and availability requirements. Furthermore, in order to present the priority of detected vulnerability findings in a format that can be implemented by the operational team—specifically, "how many vulnerabilities need to be addressed and by when"—it is necessary to clarify and internally maintain the correspondence between priority bands and recommended response time estimates. However, in the past, this correspondence was often implicitly managed as part of operational policy, and mechanisms for internally maintaining master data and making it available via APIs were limited. As described above, no technical means is disclosed in any of the Patent Documents 1-10 or Non-Patent Documents 1-5 for integrating technical severity, business impact, detection evidence quality, active verification results, and abuse history information, performing asymmetric bidirectional correction, and presenting the results to management as a two-axis scatter plot with discrete matrix cells as the background. [Prior art documents] [Patent Documents]

[0003] [Patent Document 1] U.S. Patent No. 10,372,915 [Patent Document 2] U.S. Patent No. 11,201,891 [Patent Document 3] U.S. Patent Application Publication No. 2024 / 0250979 Specification [Patent Document 4] Special Publication No. 2025-516572 [Patent Document 5] Patent No. 7320211 [Patent Document 6] Patent No. 7344614 [Patent Document 7] Patent No. 7348698 [Patent Document 8] U.S. Patent No. 11,489,860 [Patent Document 9] U.S. Patent No. 9,043,920 [Patent Document 10] U.S. Patent No. 9,294,498 [Non-patent literature]

[0004] [Non-Patent Document 1] The Information-technology Promotion Agency, Japan (IPA) published "Summary of Risk Assessment Methods for Vulnerability Response ver1.1" in July 2024. [Non-Patent Document 2] Spring, J. et al., "Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (SSVC) Version 2.0", Software Engineering Institute, Carnegie Mellon University, 2021 [Non-Patent Document 3] Nippon Telegraph and Telephone Corporation, "Integrated Risk Management Platform-Related Technologies," Transactions of the Information Processing Society of Japan, 2023. [Non-Patent Document 4] Cybersecurity and Infrastructure Security Agency (CISA), "Known Exploited Vulnerabilities Catalog" [Non-Patent Document 5] FIRST.org, "Exploit Prediction Scoring System (EPSS)" [Overview of the project] [Problems that the invention aims to solve]

[0005] The object of the present invention is to provide a mechanism that enables the operational staff and management to share response priorities using the same indicator system for vulnerability findings related to publicly available assets held by an organization, thereby suppressing false positives and over-responding to theoretical risks, while highlighting findings that directly lead to actual harm as high priority. This is achieved by: (a) calculating basic technical risk indicators in stages based on public vulnerability scores and exploit prediction scores for vulnerability findings related to publicly available assets held by an organization; (b) correcting the basic technical risk indicators bidirectionally based on the quality of detection evidence based on the detection source combination of the findings, the verification status by the active verification unit, and the degree of agreement with the known exploit catalog; (c) independently calculating business impact indicators based on multiple attribute tags linked to the target asset of the findings; (d) classifying integrated risk bands in multiple stages according to the combination of effective technical risk indicators and business impact indicators; (e) maintaining an estimated recommended response time for each finding as an internal master and making it available via API; and (f) presenting it to the user's terminal in a format including a two-axis scatter plot. [Means for solving the problem]

[0006] The present invention comprises a vulnerability information acquisition unit, a technical risk indicator calculation unit, a detection evidence classification unit, an active verification unit, a known exploit matching unit, an effective technical risk indicator calculation unit, a business impact indicator calculation unit, an integrated risk band classification unit, a response time estimate master reference unit, a presentation unit, a re-evaluation unit, and a status management interface unit. By combining these components, it becomes possible to dynamically manage the entire lifecycle, from detection to re-evaluation, based on a single set of metrics. This allows for the independent evaluation of technical severity and operational impact, integrated into a final band classification, and incorporates detection evidence quality, active verification results, and known abuse history as asymmetric corrections in the direction of priority reduction and priority increase. This provides an indicator that enables operations teams to uniquely determine "which findings should be addressed and by when." [Effects of the Invention]

[0007] According to the present invention, the following effects can be obtained. Firstly, because response priorities can be expressed using a single band index that integrates technical severity and operational impact, it becomes possible for operations staff and management to share the same index system. Secondly, by incorporating detection evidence quality, active verification results, and known exploitation history as corrective factors for effective technical risk indicators, highly reliable findings detected from multiple sources and vulnerabilities actually exploited in attacks will emerge as high-priority findings, while findings relying solely on publicly available information or those unconfirmed through active verification will be appropriately given lower priority, thereby suppressing false positives and over-reliance on theoretical risks. Thirdly, by using a method that aggregates business impact indicators from three independent tags—purpose, data confidentiality classification, and availability requirements—organizations can proceed with inputting asset attributes in stages, and initial evaluations can be performed using default values ​​when tags are not set, thus reducing operational implementation costs. Fourthly, by maintaining the correspondence between integrated risk bands and recommended response time estimates as an internal master and making it available via API or internal calls, operational policies can be formulated on a per-finding basis without becoming tacit knowledge. Fifth, by adopting a configuration in which the presentation section visualizes findings on a two-axis scatter plot, management can grasp at a glance "how serious the threats to key assets are," enabling them to make decisions without delving into technical details. Sixth, the re-evaluation unit recalculates risk indicators at predetermined triggers and makes the results available to an external status management unit, thereby providing input information to maintain the organization's risk posture in a healthy manner over time. Seventh, the correction term design of the present invention employs an asymmetric design in which both the correction direction and correction intensity differ between correction terms: (i) detection evidence quality correction (0 to +3, priority reduction direction only), (ii) active verification penalty (0 or +1, priority reduction direction only), and (iii) known exploit boost (0 or -1, priority increase direction only). This asymmetric design cannot be achieved with a general configuration that involves unidirectional discretization of the CVSS+EPSS combination or adding the correction terms as a single continuous value, and solves the design difficulty of integrating the functional independence of the correction terms (detection quality, verification reliability, attack performance) into a single metric while explicitly maintaining their independence. Eighth, each component of the present invention is essential for realizing the effects of the present invention in the sense that the following structural problems arise if the component is missing. Specifically, (i) if the technical risk index calculation unit lacks a configuration that maintains the public vulnerability score and the exploitation prediction score on separate axes, the priority difference between extremely high-severity vulnerabilities with low exploitability potential and medium-severity vulnerabilities with high exploitability potential cannot be represented in the score. (ii) if the detection evidence classification unit lacks a multi-stage quality classification based on the detection source combination, the confidence difference between high-accuracy findings due to multiple detections and findings from a single external source will not be reflected in the correction. (iii) if the verification penalty by the active verification unit lacks a configuration that positions it as a correction item independent of the detection evidence quality, the verification "unconfirmed" state will be reflected twice in the determination of the detection evidence quality and the addition of the verification penalty (double counting problem), and the functional independence between correction items will break down. (iv) If the known abuse boost is not configured to be independently positioned as a priority-enhancing correction term, it will be offset by the priority-down correction due to low detection evidence, and the high priority of known abuse-matching findings will be lost. (v) If the business impact indicator calculation unit is not configured to be composed of a simple sum of three independent tags: use, data confidentiality classification, and availability requirements, a single business importance value will not be able to distinguish which axis is dominant, and explainability to management will be impaired. (vi) If the response time estimate master reference unit is not configured to be maintained as an internal master and made available via the application programming interface or internal calls, operational policies will remain as tacit knowledge, making it difficult to monitor for exceeding deadlines and track progress. (vii) If the integrated risk band classification unit is not configured to perform band classification based on a two-dimensional combination of effective technical risk indicators and business impact indicators, a single continuous score will make it difficult for management to grasp at a glance "how many serious threats exist to critical assets." Fifth, in the operation of vulnerability response in an organization, compared with the conventional method that relies only on technical indicators, the present invention provides the following effects: (a) Findings determined as "unconfirmed" in active verification are automatically classified into lower bands by verification penalties, which reduces the man-hours spent by operation sites on desktop risk investigation and priority judgment; (b) The recommended estimated response time for each band is stored as an internal master and can be obtained via an application programming interface or internal call, which facilitates over-deadline monitoring and progress tracking and contributes to the improvement of deadline compliance rate; (c) Matching with a known exploit catalog acts as an independent priority raising correction term, which suppresses unnecessary priority reduction caused by priority lowering correction due to low detection evidence, and prevents the omission of surfacing findings that should truly be addressed. Brief Description of the Drawings

[0008] [Figure 1] It is an overall configuration diagram in an embodiment of the present invention. [Figure 2] It is a two-axis matrix diagram of technical risk indicators in an embodiment of the present invention. [Figure 3] It is a state transition diagram of detection evidence quality in an embodiment of the present invention. [Figure 4] It is a correction flowchart of effective technical risk indicators in an embodiment of the present invention. [Figure 5] It is a three-axis sum data flow diagram of business impact indicators in an embodiment of the present invention. [Figure 6] It is a matrix diagram of integrated risk band classification in an embodiment of the present invention. [Figure 7] It is a presentation diagram by a two-axis scatter plot in an embodiment of the present invention. [Figure 8] It is a sequence diagram of a re-evaluation trigger in an embodiment of the present invention. Modes for Carrying Out the Invention

[0009] The following describes an example of an embodiment of the present invention. Note that this embodiment is merely an example to facilitate understanding of the present invention, and the present invention is not limited thereto. 1.Vulnerability information acquisition department The vulnerability information acquisition unit (1) acquires vulnerability findings related to the publicly available assets held by the organization from one or more detection sources. Examples of detection sources include the following: • Results of actively performed non-destructive testing tools • Results of a version matching scan from a remote or local source • Security advisory information from the OS distributor • Information from publicly available vulnerability databases (e.g., NVD) Vulnerability findings are stored along with attributes including the target asset identifier (FQDN, IP address, etc.), vulnerability identifier (CVE, etc.), detection source identifier, public vulnerability score, exploit prediction score, and verification status by the active verification unit. 2. Technical Risk Indicator Calculation Section The technical risk index calculation unit (2) calculates a basic technical risk index as a discrete value of a predetermined number of levels based on a combination of the public vulnerability score and the exploit prediction score. In this embodiment, the public vulnerability score is discretized into four levels (e.g., 9 or more, 7 or more, 4 or more, and less than 4), and the exploit prediction score is divided into two parts by a predetermined threshold (e.g., 0.1). Based on the combination of the two, the basic technical risk index is determined into five levels (highest to lowest) from an 8-cell matrix. The basic technical risk index is internally stored as a rank value (1 to 5, with 1 being the highest). The boundary thresholds for the public vulnerability score (e.g., 9.0, 7.0, 4.0), the bipartite threshold for the exploit prediction score (e.g., 0.1), and the number of discretization stages (e.g., 4 stages, 5 stages, 8 cells) are all examples of specific numerical values ​​in this embodiment, and configurations that adopt other boundary thresholds and number of stages in accordance with revisions to the operating environment or external standards (Common Vulnerability Assessment System and Exploit Prediction Score System) are also within the scope of the present invention. The independent claims of the present invention do not limit these specific numerical values, but define discretization by multiple thresholds and bipartiteization by predetermined thresholds as a configuration, and the specific numerical values ​​are exemplified in the dependent claims and embodiments. 3. Classification of Detected Evidence The detection evidence classification unit (3) classifies the quality of the detection evidence for a vulnerability finding into multiple levels (e.g., four levels: A, B, C, and D) based on the combination of detection sources for the vulnerability finding and whether or not the asset in question belongs to a product line whose version notation is unreliable due to the patch backport method. The verification status by the active verification unit is not used in this classification and is independently corrected as a verification penalty "verification_penalty" described later (see claim 3). Examples of judgments are shown below. Findings detected from multiple sources (e.g., both local scan results and distributor advisories) are classified as the highest level (A). Findings detected solely from active local scans or distributor advisories from a single source are classified as intermediate level (B). • Relying solely on publicly available vulnerability databases, if the target asset belongs to an OS system using a patch backport method, it will be classified as the lowest level (D). • Findings from a single external source other than those mentioned above are classified as low-level (C). It is important to emphasize that the status of the active verification unit is not used in this detection evidence classification. In other words, regardless of whether a finding is "confirmed," "not confirmed," or "not performed" in active verification, the detection evidence quality (stages A to D) is determined solely by the detection source combination and patch backport judgment for that finding. The active verification status is separately incorporated into the correction as a verification penalty "verification_penalty" (add +1 if not confirmed, 0 otherwise). This prevents the active verification result from being mixed into the double correction of detection evidence quality and verification penalty. 4. Active Verification Department The active verification unit (4) selects or generates a verification template that is permitted for non-destructive execution only for assets whose ownership has been pre-verified (e.g., assets whose domain ownership has been confirmed by DNS text records, etc.), sends a verification request, and analyzes the response to assign a verification status of confirmed, unconfirmed, or not performed to the vulnerability findings. The verification template may be selected from a pre-existing set of verification templates, or it may be generated based on the attributes of the vulnerability findings, the attributes of the target asset, or the detection source. 5. Known misuse matching unit The known exploit matching unit (5) obtains externally provided known exploit catalog information and compares the vulnerability identifiers in the catalog with the vulnerability identifiers in the vulnerability findings. A known exploit flag is assigned to matching findings. 6. Effective Technology Risk Indicator Calculation Unit The effective technical risk index calculation unit (6) corrects the basic technical risk index bidirectionally based on the quality of detected evidence, the active verification status, and the results of known abuse matching. The correction formula in this embodiment is as follows (rank value notation, 1 is the highest priority). Effective rank "effective_rank" = GREATEST(LEAST(Base rank "base_rank" + Evidence correction value "grade_shift" + Verification penalty "verification_penalty", 5) - Known abuse boost "kev_boost", 1) The definitions of each correction term are as follows: • Evidence correction value "grade_shift": An added value corresponding to a reduction in the quality of detected evidence: 0 for A, 1 for B, 2 for C, and 3 for D. • Verification penalty "verification_penalty": Adds 1 if the verification status of the active verification unit is unconfirmed, otherwise adds 0. • Known exploit boost "kev_boost": Subtracts 1 if there is a match in the known exploit catalog, otherwise subtracts 0 (increases priority). Ultimately, the effective technology risk index is clamped to a range of 1-5 by the GREATEST and LEAST criteria. 7.Business impact index calculation department The business impact indicator calculation unit (7) calculates business impact indicators from attribute tags associated with the target assets. In this embodiment, the following three axes are adopted. 7.1 Application axis The usage axis represents the functional positioning of the asset. An example of the correspondence between tag values ​​and numerical values ​​is as follows: • "public" (public system): 5 • "remote_access" (remote access): 5 • "restricted" (limited access): 4 • "mail_infra" (mail infrastructure): 4 • "development" (development / verification): 3 · "unknown" (unclassified): 3 • "internal_only" (for internal use only): 2 • "archived" (retired): 1 7.2 Data Confidentiality Classification Axis An example of the correspondence between tag values ​​and numerical values ​​is as follows: • "personal_data" (personal data): 5 • "payment_data" (payment data): 5 ·“confidential”:5 • "public_only" (public information only): 3 · "unknown" (unclassified): 3 7.3 Availability Requirements Axis An example of the correspondence between tag values ​​and numerical values ​​is as follows: • "mission_critical" (equivalent to core system): 3 · "unknown" (unclassified): 3 ·“business_hours” (business hours):2 · "non_critical" (can be stopped): 1 7.4 Total The business impact indicator is calculated by simply summing the numerical values ​​of the three axes mentioned above. After the values ​​for each axis are determined from the associated tag set by maximizing the maximum value, the business impact indicator is output as an integer value between 5 and 13 by summing them up. If no tag is set for any axis, the default contribution value (e.g., 3) is applied to that axis. In this embodiment, three axes are adopted: application, data confidentiality classification, and availability requirements. However, depending on the business environment, it is also possible to calculate business impact indicators by simply summing up multiple axes, adding or replacing some of these three axes or other attribute axes (e.g., regulatory compliance axis, customer access frequency axis, etc.), and this is also within the scope of the present invention. 8. Integrated Risk Band Classification Section The integrated risk band classification unit (8) classifies the findings into one of the following bands based on the combination of effective technical risk indicators and operational impact indicators. An example of the classification rules in this embodiment is as follows: • Combinations of high effective technical risk (effective rank 1-2) and low business impact (5-7) are given high priority (A). • Combinations of high effective technical risk (effective rank 1-2) and moderate business impact (8-10) are given high priority (A). • A combination of high effective technical risk (effective rank 1-2) and high business impact (11-13) requires emergency response (S). • Combinations of moderate effective technical risk (effective rank 3) and low business impact are given moderate priority (B). • A combination of moderate effective technical risk (effective rank 3) and moderate business impact is given moderate priority (B). • A combination of moderate effective technical risk (effective rank 3) and high business impact is given high priority (A). • Combinations of low effective technical risk (effective rank 4) and low business impact are given low priority (C). • Combinations of low effective technical risk (effective rank 4) and moderate business impact are given medium priority (B). • Combinations of low effective technical risk (effective rank 4) and high business impact are given medium priority (B). • Combinations with the lowest effective technical risk (effective rank 5) and low business impact are monitored (D). • Combinations of minimum effective technical risk (effective rank 5) and moderate business impact are given low priority (C). • Combinations of the lowest effective technical risk (effective rank 5) and high business impact are given medium priority (B). The rules for each cell in the above classification are just one example and can be adjusted as policies that can be set by the system operator. 9. Estimated response time master reference section The response time estimate master reference unit (9) maintains recommended response time estimates for each band as an internal master and allows referencing them via API or internal calls. Specific presentations and additions to observations will be described later as optional embodiments. The following correspondence is used as an example. • Emergency response (S): Within 24 hours • High priority (A): Within 1 week • Medium priority (B): Within 1 month • Low priority (C): Next patch cycle • Monitoring (D): Monitoring only 10.Presentation part The presentation unit (10) displays the findings, along with the integrated risk band and recommended response time estimates, on the subject's terminal. As an example of the presentation format, the following two-axis scatter plot is used. • Horizontal axis (X): Business impact indicators (5-13) • Vertical axis (Y): Effective technology risk indicator (rank 1-5, higher ranks indicate higher priority) • Dot color: Integrated risk band (5 colors from emergency response to surveillance, color scheme designed with consideration for color vision diversity) In addition, detailed information including vulnerability identifiers, target asset identifiers, operational impact indicators, effective technical risk indicators, bands, detection evidence quality, responsible group, and asset tags will be displayed as hover displays for each finding. 11. Re-evaluation Department The reassessment unit (11) recalculates the effective technical risk indicators, operational impact indicators, and integrated risk bands at predetermined triggers. Examples of triggers are as follows: • Registration of new findings • Verification completed by the Active Verification Department • Updating external information sources such as known abuse catalogs. • Change asset attribute tags • Regular schedule (e.g., daily batch) If a change occurs as a result of the recalculation, the difference will be saved in the audit record. 12. State Management Interface Section The state management interface unit (12) enables the recalculation results by the re-evaluation unit (11) to be provided to an external state management unit. In this invention, the re-evaluation results (effective technical risk indicators, business impact indicators, integrated risk bands, and estimated response times) are output in a format that can be obtained via API or internal calls, and the specific implementation of the state transition logic of the findings (open / closed / overdue, etc.) is outside the scope of this invention. 13. Multitenant Execution Environment In this embodiment, each of the above components is executed as a multi-tenant environment capable of processing data related to multiple organizations or contracts in parallel while maintaining logical separation (e.g., a configuration implemented as a function on a database with row-level security (RLS)). [Examples]

[0010] [Example 1: Observations on emergency response at a core e-commerce site] The following vulnerabilities were observed in the domain shop.example.com, an e-commerce site operated by the organization. Vulnerability identifier: CVE-XXXX-YYYY (tentative) • Public vulnerability score: 9.8 • Abuse prediction score: 0.35 • Detection sources: Local scan + Distributor advisories (multiple) • Known misuse catalog match: Yes • Active verification status: Confirmed The technical risk index calculation unit calculates the basic technical risk index as the highest level (rank=1) from the combination of a public vulnerability score of 9.8 and an exploit prediction score of 0.35. The detection evidence classification unit classifies the detection evidence quality as level A based on multi-source detection (local scan + distributor advisory) and outputs the evidence correction value "grade_shift" = 0. The verification status of the active verification unit is "confirmed", so the verification penalty "verification_penalty" = 0. The known exploit matching unit confirms the known exploit match for the finding, and the effective technical risk index calculation unit applies the known exploit boost "kev_boost" = 1. As a result, the effective technical risk index remains at the highest level, GREATEST(LEAST(1+0+0, 5) - 1, 1)=1. On the other hand, the target asset shop.example.com had the following tags attached. ·Usage: "public" (5) • Data confidentiality classification: "payment_data" (5) ·Availability requirement: "mission_critical" (3) The business impact index is calculated as 5+5+3=13. The integrated risk band classification unit classifies the finding into the emergency response band (S) based on the combination of a high effective technical risk index (rank=1) and a high business impact index (13). The response time estimate master reference unit can retrieve "within 24 hours" corresponding to the band (S) from the internal master and provide it to an external system or hover display via API. The presentation unit displays the finding in the emergency response band color in the upper right corner of the two-axis scatter plot and outputs vulnerability details and the response time estimate as a hover display. [Example 2: Severity assessment based solely on publicly available information in the development environment] The following vulnerabilities were observed in the internal development and testing environment host, dev-staging.internal-example.org. Vulnerability identifier: CVE-ZZZZ-AAAA (provisional) • Public vulnerability score: 6.5 • Abuse prediction score: 0.05 • Detection source: Publicly available vulnerability database (NVD) only • Known misuse catalog match: None • Active verification status: Not performed • Target asset OS: Debian-based (eligible for patch backporting) The technical risk index calculation unit calculates the basic technical risk index as rank = 4 (low). The detected evidence classification unit classifies the detected evidence quality as D level because it is a single externally published database and the target asset is a patch backport OS system, and outputs the evidence correction value "grade_shift" = 3. Since active verification has not been performed, the verification penalty "verification_penalty" = 0, and since there is no known abuse match, the known abuse boost "kev_boost" = 0. The effective technical risk index calculation unit calculates GREATEST(LEAST(4+3+0, 5) - 0, 1) = 5, and corrects the findings to the lowest level. The tags for the target assets are as follows: ·Use: “development” (3) • Data confidentiality classification: "unknown" (3) ·Availability requirement: "business_hours" (2) The business impact index is calculated as 3+3+2=8. The integrated risk band classification unit classifies the finding into the low-priority band (C) based on the combination of the lowest effective technical risk index (rank=5) and the medium business impact index (8). The response time estimate master reference unit allows the "next patch cycle" to be obtained from the internal master, minimizing the immediate response effort required at the operational site. [Example 3: Lowering the priority of findings that were not confirmed by active verification] The following vulnerabilities were observed in the organization's front-end delivery host, cdn.example.com. Vulnerability identifier: CVE-BBBB-CCCC (provisional) • Public vulnerability score: 7.5 • Abuse prediction score: 0.20 • Detection source: Local scan (standalone) • Known misuse catalog match: None • Active verification status: Unconfirmed (Unable to confirm the response intended by the template) The technical risk index calculation unit calculates the basic technical risk index as rank = 2 (high). The detected evidence classification unit classifies the detected evidence quality as B-level because it originates from a single local scan and outputs an evidence correction value "grade_shift" = 1. A verification penalty "verification_penalty" = 1 is set because active verification is unconfirmed, and a known abuse boost "kev_boost" = 0 is set because there is no known abuse match. The effective technical risk index calculation unit calculates GREATEST(LEAST(2+1+1, 5) - 0, 1) = 4 and corrects the findings to a low level. The tags for the target assets are as follows: ·Usage: "public" (5) ·Data confidentiality classification: "public_only" (3) ·Availability requirement: "business_hours" (2) The business impact index is calculated as 5 + 3 + 2 = 10. The integrated risk band classification unit classifies the finding into the medium priority band (B) based on the combination of a low effective technical risk index (rank = 4) and a medium business impact index (10). The response time estimate master reference unit can retrieve "within 1 month" corresponding to the band (B) from the internal master and provide it to an external system or hover display via API. This example demonstrates how the effective technical risk index can be lowered based on the fact that, despite both the publicly available vulnerability score and business impact being at a medium to high level, the vulnerability could not be confirmed through active verification. This prevents the operational team from overreacting to theoretical risks. [Example 4: Default application to assets without tags and phased maintenance] The system detected a vulnerability in the newly discovered asset legacy.example.com, even though none of its attribute tags were set. Vulnerability identifier: CVE-DDDD-EEEE (tentative) • Public vulnerability score: 8.0 • Abuse prediction score: 0.15 • Detection source: Local scan + Distributor advisory • Known misuse catalog match: None • Active verification status: Confirmed The technical risk index calculation unit calculates the basic technical risk index as rank = 2. The detected evidence classification unit classifies the quality as A based on multi-source detection (local scan + distributor advisory) and outputs the evidence correction value "grade_shift" = 0. The verification status of the active verification unit is "confirmed", so the verification penalty "verification_penalty" = 0, and the known abuse boost "kev_boost" = 0 because there is no known abuse match. The effective technical risk index remains GREATEST(LEAST(2+0+0, 5) - 0, 1) = 2. The business impact indicator calculation unit determines that since the asset's usage tag, data confidentiality tag, and availability requirement tag are all unset, it applies a default contribution value of 3 to each axis and calculates the business impact indicator as 3+3+3=9. The integrated risk band classification unit classifies the finding into the high-priority band (A) based on the combination of a high effective technical risk index (rank = 2) and a medium operational impact index (9). The response time estimate master reference unit allows the "within one week" timeframe to be retrieved from the internal master data. If the organization subsequently reclassifies legacy.example.com as "internal use only and non-confidential," the re-evaluation unit recognizes the trigger as "attribute tag change" and recalculates the business impact index to 2+3+1=6. The integrated risk band classification unit automatically reclassifies the findings to the medium-priority band (B) based on the recalculation results, and the response time estimate master reference unit makes "within 1 month" available from the internal master. Changes resulting from the recalculation are saved in the audit record. This embodiment demonstrates that even assets without tags can be provisionally evaluated using default contribution values, and that re-evaluation is automatically performed when attributes are later established. [Example 5: Comparison with a simple additive configuration] As a comparative example, if the detection evidence quality correction (A~D → 0~+3), active verification penalty (+1 for unconfirmed), and known abuse boost (+1 for match) are constructed as a single correction term that is simply added together, the following scenario occurs. That is, for a finding of CVSS=9.0 (base rank=1), detection evidence quality=D (correction +3), active verification=confirmed (correction 0), and known abuse=match (in simple addition, this is mixed in as +1 in a single correction term instead of a priority increase correction), the simple addition type corrects it to base rank 1+3+0+1=5 (lowest rank), resulting in a constructive flaw where the critical event of "known abuse match" is offset and buried by the reduction correction due to the low detection evidence. In contrast, the present invention corrects the scenario to an effective rank of GREATEST(LEAST(1+3+0, 5) - 1, 1)=4 (low rank) by placing the known abuse boost as an independent priority-raising correction term ("kev_boost" = -1) outside the "GREATEST" parentheses, thereby structurally maintaining high-priority protection due to known abuse matching while reflecting the reduction due to low detection evidence. This difference in effect is unattainable with a simple additive configuration that does not maintain functional independence between correction terms, demonstrating the structural superiority of the asymmetric bidirectional correction of the present invention. [Industrial applicability]

[0011] The system of the present invention is widely applicable to security services that provide attack surface management and continuous threat exposure management (CTEM) for public assets held by an organization. Therefore, the system of the present invention is applicable to all organizations, including corporations, government agencies, local authorities, medical institutions, educational institutions, financial institutions, research institutions, and non-profit organizations, and can be widely used in areas such as vulnerability management, attack surface management, risk-based vulnerability management (RBVM), security response planning, and security reporting for management. Furthermore, the present invention is also suitable for a multi-tenant SaaS model and possesses high practicality and versatility in the industrial sector. [Explanation of symbols]

[0012] 1 Vulnerability information acquisition section 2. Technical Risk Indicator Calculation Unit 3. Classification of Detected Evidence 4. Active Verification Department 5. Known misuse matching unit 6. Effective Technology Risk Indicator Calculation Unit 7 Business impact index calculation department 8. Integrated Risk Band Classification Section 9. Estimated response time master reference section 10 Presentation part 11 Re-evaluation Department 12. State Management Interface Unit 13 Vulnerability Findings Database 14 Asset Attribute Tag Database 15. Department for Acquiring Known Misuse Catalogs 16. Verification Template Database 17 Audit Record Database 18 Target user's device 19 Administrator terminal

Claims

1. A vulnerability information acquisition unit that acquires vulnerability findings relating to publicly available assets; a technology risk index calculation unit that calculates basic technology risk indexes based on the public vulnerability score and exploit prediction score associated with the vulnerability findings; a detection evidence classification unit that classifies the quality of detection evidence based on the detection source combination of the vulnerability findings; an active verification unit that selects or generates a verification template that is permitted to be executed non-destructively only for assets whose ownership relationship has been pre-verified and sends a verification request; a known exploit matching unit that determines the degree of agreement with a known exploit catalog; an effective technology risk index calculation unit that calculates an effective technology risk index by correcting the basic technology risk index based on the quality of detection evidence, the verification status by the active verification unit and the agreement status by the known exploit matching unit; a business impact index calculation unit that calculates a business impact index for an asset by summing the values ​​of multiple attribute tags associated with the asset that is the target of the vulnerability findings; an integrated risk band classification unit that classifies integrated risk bands based on the combination of the effective technology risk index and the business impact index; and a presentation unit that presents the vulnerability findings together with the integrated risk bands to the target person's terminal. A cybersecurity risk integrated assessment and response priority setting system equipped with the following features.

2. The system according to claim 1, characterized in that the technical risk index calculation unit calculates the basic technical risk index as a discrete value using a matrix based on a combination of severity categories obtained by discretizing the public vulnerability score by a plurality of thresholds and exploit prediction categories obtained by dividing the exploit prediction score into two by a predetermined threshold.

3. The system according to claim 1 or claim 2, wherein the vulnerability detection source includes a plurality of actively executed non-destructive verification tools, detection by local scans, distributor advisory information, and publicly available vulnerability database information, and the detection evidence classification unit classifies the quality of the detection evidence for the vulnerability finding in multiple stages based on the combination of the detection sources for the vulnerability finding and whether or not the asset subject to the finding belongs to a product line whose version notation is unreliable due to the patch backport method.

4. The system according to claim 3, wherein the effective technical risk index calculation unit comprises an asymmetric bidirectional correction means that outputs an effective technical risk index by clamping the result of combining (i) a first correction that lowers the basic technical risk index in multiple steps according to the stage of the quality of the detected evidence, (ii) a second correction that lowers the basic technical risk index by one step independently of the first correction when the verification result by the active verification unit is unconfirmed, and (iii) a third correction that raises the basic technical risk index in a direction different from the first and second corrections when the matching status with the known abuse catalog is matched, within predetermined upper and lower limits.

5. The system according to Claim 1, wherein the business impact indicator calculation unit outputs a business impact indicator expressed as an integer between a predetermined minimum and maximum value by summing a usage contribution value obtained by numerically representing the values ​​of usage tags associated with the asset according to a predetermined correspondence relationship, a data confidentiality contribution value obtained by numerically representing the values ​​of data confidentiality classification tags according to a predetermined correspondence relationship, and an availability contribution value obtained by numerically representing the values ​​of availability requirements tags according to a predetermined correspondence relationship.

6. The system according to claim 5, characterized in that the business impact indicator calculation unit can calculate a business impact indicator by applying a default contribution value to the unset axis when any of the application tag, data confidentiality classification tag, or availability requirement tag is not set.

7. The system according to Claim 1, wherein the integrated risk band classification unit divides the effective technical risk indicator into a plurality of categories including low, medium, and high, and divides the business impact indicator into a plurality of categories including low, medium, and high, and classifies the findings into one of a plurality of bands including an emergency response band, a high priority band, a medium priority band, a low priority band, and a monitoring band based on a combination of both categories.

8. The system according to claim 7, wherein the system includes a guideline master that internally maintains a correspondence between each of the integrated risk bands and a recommended response time guideline, the master is accessible via an application programming interface (API) or internal call, and the system is capable of obtaining a recommended response time guideline corresponding to the integrated risk band of the vulnerability finding.

9. The system according to Claim 1, wherein the display unit arranges the vulnerability findings as points on a two-axis scatter plot with the horizontal axis being the business impact index and the vertical axis being the effective technology risk index, draws discrete matrix cells corresponding to the classification rules of the integrated risk band in the background, and displays each point colored with the color corresponding to the integrated risk band to which it belongs.

10. The system according to Claim 1, wherein the known exploit matching unit acquires externally provided known exploit catalog information at predetermined intervals, matches the vulnerability identifiers included in the catalog with the vulnerability identifiers included in the vulnerability findings, and provides the matching results to the effective technical risk index calculation unit and the presentation unit.

11. The system according to Claim 1, wherein the active verification unit selects or generates a verification template that is permitted to be executed non-destructively only on pre-verified assets, sends a verification request and analyzes the response to assign a verification status of confirmed, unconfirmed, or not performed to the finding, and provides the effective technical risk index calculation unit with the verification status as a correction term independent of the detected evidence quality.

12. The system according to Claim 1, wherein the system is provided to multiple organizations or users via a network, and the vulnerability findings, effective technical risk indicators, business impact indicators, integrated risk bands, and asset attributes are configured to be executed in a multi-tenant environment that logically separates and manages data from multiple organizations.

13. The system according to Claim 1, wherein the system further comprises a re-evaluation unit that recalculates at least one of the effective technical risk index, the business impact index, and the integrated risk band at predetermined triggers, wherein the triggers include at least one of the following: registration of new findings, completion of active verification, updating of external catalog information, change of asset attribute tags, or a periodic schedule.

14. The system according to claim 13, further comprising an interface unit for providing the recalculation result to the state management unit.

15. The system according to Claim 4, wherein the detection evidence classification unit relies solely on publicly available vulnerability database information, and when the asset subject to the finding belongs to a product line whose version notation is unreliable due to the patch backport method, it classifies the detection evidence quality of the finding to the lowest level, and the effective technical risk index calculation unit reduces the basic technical risk index of the finding by a predetermined maximum number of levels.

16. The system according to claim 15, characterized in that when the quality of the detected evidence is at the lowest level and the verification result by the active verification unit is unconfirmed, the system calculates the effective technical risk index by clamping the result of adding both correction terms to within the upper limit level.

17. The system according to claim 10, characterized in that the known exploit matching unit acquires externally provided known exploit catalog information at predetermined intervals and updates the known exploit matching status incrementally by re-matching only the difference information from the previous acquisition with the existing set of vulnerability findings.

18. The system according to claim 9, characterized in that the display unit aggregates points belonging to the same integrated risk band on the biaxial scatter plot into a cluster when the number of such points exceeds a predetermined number, and redisplays the individual vulnerability findings as individual points in response to an operation to expand the cluster.

19. The system according to claim 9, wherein the display unit displays all findings or only findings related to a specific group of findings depending on whether the target asset belongs to a group of findings, recalculates the number of findings by integrated risk band in accordance with the switch, and redraws the two-axis scatter plot.

20. A computer-based method for integrated assessment of cybersecurity risks and prioritizing responses, the method comprising: the computer obtaining vulnerability findings relating to publicly available assets owned by an organization; calculating a basic technical risk index based on the public vulnerability score and exploit prediction score associated with the vulnerability findings; classifying the detection evidence quality into multiple levels based on the detection source combination of the vulnerability findings; executing a verification template that is permitted to be executed non-destructively only on assets whose ownership has been pre-verified and assigning a verification status; determining the degree of agreement with a known exploit catalog; correcting the basic technical risk index and calculating an effective technical risk index by asymmetrically applying a priority reduction correction based on the detection evidence quality and the verification status and a priority increase correction based on the degree of agreement; calculating a business impact index by summing the values ​​of three axes: usage tags, data confidentiality tags, and availability requirement tags associated with the target assets of the vulnerability findings; classifying an integrated risk band based on the combination of the effective technical risk index and the business impact index; and presenting the vulnerability findings together with the integrated risk band to the target person's terminal.

21. A program for causing a computer to perform the method described in claim 20.

22. A non-temporary, computer-readable recording medium having the program described in claim 20 recorded on it.

Images