Risk identification method, device, equipment, medium and program product

Abstract

This application provides a risk identification method applicable to the fields of big data technology and information security. The method includes: constructing a target topology graph based on business information and equipment information of related physical devices; wherein each node in the target topology graph represents at least a business node and / or a physical device node, and each edge in the topology graph represents at least a business process relationship and / or a physical device connection relationship; identifying at least one important node among all nodes based on the edges and paths of each node; calculating the static vulnerability of each node, where static vulnerability represents the degree of risk corresponding to the node's own attributes; calculating the dynamic risk of important nodes based on their static vulnerabilities, where dynamic risk represents the impact of an important node's failure; and identifying risky nodes based on static vulnerability and dynamic risk. This application also provides a risk identification device, equipment, storage medium, and program product.

Description

Technical Field

[0001] This application relates to the fields of big data and information security, specifically to risk identification in big data and information security, and more specifically to a risk identification method, apparatus, equipment, medium, and program product. Background Technology

[0002] In today's information environment, network systems are becoming increasingly complex, and the dependencies between business systems and underlying physical infrastructure are intricate, posing significant challenges to the identification and management of network security risks. Current technologies for identifying network security risks typically assess the vulnerabilities of individual assets in isolation, combining this with their pre-defined business importance to determine risk. However, this approach fails to take a global topology perspective, objectively quantifying the true pivotal role of assets in complex networks, and neglects dynamic stress factors such as the real-time operational load of assets. The final risk assessment is often based solely on static vulnerability severity, failing to comprehensively consider the network importance, inherent vulnerabilities, and dynamic operational pressure of nodes, resulting in insufficient accuracy in risk identification and a high likelihood of false negatives and false negatives. Summary of the Invention

[0003] In view of the above problems, this application provides risk identification methods, apparatus, equipment, media and procedures to improve the accuracy of risk identification.

[0004] According to the first aspect of this application, a risk identification method is provided, comprising: constructing a target topology graph based on business information and equipment information of physical devices associated with the business, wherein the nodes of the target topology graph represent at least business nodes and / or physical device nodes, and the edges of the topology graph represent at least business process relationships and / or physical device connection relationships; determining at least one important node among the nodes based on the edges of each node and the path in which the node is located; calculating the static vulnerability of each node, wherein the static vulnerability represents the degree of risk corresponding to the node's own attributes; calculating the dynamic risk of the important node based on the static vulnerability of the important node, wherein the dynamic risk represents the degree of impact caused by the failure of the important node; and identifying risky nodes based on the static vulnerability and the dynamic risk.

[0005] According to an embodiment of this application, constructing a target topology map includes: determining business asset nodes based on business information, whereby each business asset node represents at least one of asset value level, service call relationship, dependency degree, and service level protocol level; determining physical device nodes based on device information, whereby each physical device node represents at least one of device type, administrator, and deployment location; and merging or connecting at least a portion of each business asset node and each physical device node based on the business process, the correspondence between the business and the physical device, and the deployment relationship between each physical device to construct the target topology map.

[0006] According to an embodiment of this application, constructing a target topology map further includes: obtaining attack path information of a preset attack event; determining attack event nodes based on the attack path information, wherein each attack event node represents at least one of the target device, attack type, and attack time in the attack path; and merging or connecting the attack event nodes to nodes in the target topology map based on the association between the attack event and services, and / or physical devices.

[0007] According to embodiments of this application, constructing a target topology map further includes: obtaining historical vulnerability information, wherein the historical vulnerability information represents historical data associated with discovered vulnerabilities; determining historical vulnerability nodes based on the historical vulnerability information, wherein the historical vulnerability nodes represent at least one of the following: the risk quantification value of the vulnerability, the remediation status of the vulnerability, the asset information affected by the vulnerability, the time of occurrence of the vulnerability, and the duration of the vulnerability; and merging or connecting the historical vulnerability nodes to nodes in the target topology map based on the association between attack events and services, and / or physical devices.

[0008] According to an embodiment of this application, determining at least one important node among the nodes includes: calculating the importance of each node, wherein the importance represents the combination of a first importance and a second importance of the node, the first importance represents the connection status of the node with its neighboring nodes, and the second importance represents the frequency of the node's occurrence in each shortest path in the target topology graph; and in response to an importance greater than or equal to an importance threshold, designating the node as an important node.

[0009] According to an embodiment of this application, the calculation process for the first importance level includes: calculating the first importance level based on the number of edges connected to the node and the total number of nodes in the target topology network.

[0010] According to an embodiment of this application, the calculation process for the second importance level includes: determining the shortest path in the target topology graph, wherein the shortest path is the shortest path between any two other nodes in the topology graph excluding the node; determining the target shortest path that passes through the node in each shortest path; and taking the ratio of the number of target shortest paths to the number of shortest paths as the second importance level.

[0011] According to embodiments of this application, calculating the static vulnerability of each node includes: determining at least one object corresponding to the node, where the object represents a target asset that can be attacked, and the target asset includes at least one of physical devices, virtualization resources, applications, and stored data; calculating the basic vulnerability based on the object's exposure coefficient, the object's vulnerability risk value, and the object's corresponding preset protection strength, where the exposure coefficient represents the degree to which the object can be exploited under preset conditions, and the vulnerability risk value represents the risk value of the object's corresponding preset basic risk after being affected by time; and calculating the node's static vulnerability based on the association between the objects corresponding to the node and the basic vulnerability of each object.

[0012] According to an embodiment of this application, calculating basic vulnerability includes: obtaining the duration for which a vulnerability remains unpatched after it occurs; calculating a vulnerability risk value based on the duration and the preset basic risk corresponding to the object; calculating an exposure coefficient based on the exploitation difficulty and the network location coefficient of the object, where the exploitation difficulty represents the minimum requirements for attacking the object and the network location coefficient represents the ease of accessing the object; and obtaining the basic vulnerability by multiplying the vulnerability risk value by the exposure coefficient and dividing the preset protection strength corresponding to the object by the product.

[0013] According to embodiments of this application, calculating the static vulnerability of a node includes: in response to the relationship characterization node having only one corresponding object, using the object's basic vulnerability as the node's static vulnerability; in response to the relationship characterization node having multiple corresponding objects, and the multiple objects having no association with a preset critical business system, using the average of the basic vulnerabilities corresponding to each object as the node's static vulnerability; in response to the relationship characterization node having multiple corresponding objects, and among the multiple objects being an object associated with a preset critical business system, using the maximum value of the basic vulnerabilities corresponding to each object as the node's static vulnerability.

[0014] According to an embodiment of this application, calculating the dynamic risk of an important node includes: calculating the dependency coefficient of the node based on the dependency level and service level protocol level represented by the node; and calculating the dynamic risk of the node based on the ratio of the service load carried by the node to the preset maximum service load of the node, the static vulnerability of the node, and the dependency coefficient of the node.

[0015] According to an embodiment of this application, the method further includes: in response to identifying a risk node, generating and sending risk alarm information corresponding to the risk node; in response to receiving a processing measure corresponding to the risk alarm information, constructing a target relationship based on the time from sending the risk alarm information to receiving the processing measure and the effect of the processing measure, wherein the target relationship characterizes the pattern of the risk level of the risk node changing over time; and determining a processing plan for the risk node after the processing measure based on the target relationship.

[0016] According to an embodiment of this application, identifying risk nodes based on static vulnerability and dynamic risk includes: in response to a static vulnerability being greater than a static vulnerability threshold and a dynamic risk being greater than a dynamic risk threshold, identifying the corresponding important nodes as risk nodes.

[0017] A second aspect of this application provides a risk identification device, comprising: a topology construction module for constructing a target topology graph based on business information and equipment information of physical devices associated with the business, wherein the nodes of the target topology graph at least represent business nodes and / or physical device nodes, and the edges of the topology graph at least represent business process relationships and / or physical device connection relationships; a first determination module for determining at least one important node among the nodes based on the edges of each node and the path in which the node is located; a first calculation module for calculating the static vulnerability of each node, wherein the static vulnerability represents the degree of risk corresponding to the node's own attributes; a second calculation module for calculating the dynamic risk of the important node based on the static vulnerability of the important node, wherein the dynamic risk represents the degree of impact caused by the failure of the important node; and a first identification module for identifying risky nodes based on the static vulnerability and dynamic risk.

[0018] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0019] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0020] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0021] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0022] Figure 1 The illustrations depict application scenarios of risk identification methods, apparatus, devices, media, and program products according to embodiments of this application.

[0023] Figure 2 A flowchart illustrating a risk identification method according to an embodiment of this application is shown schematically.

[0024] Figure 3 Another flowchart of a risk identification method according to an embodiment of this application is illustrated schematically;

[0025] Figure 4 A schematic diagram illustrating the structure of a risk identification device according to an embodiment of this application is shown; and

[0026] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a risk identification method according to an embodiment of this application. Detailed Implementation

[0027] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0028] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0029] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0030] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0031] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0032] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this application all offer users corresponding entry points for choosing to agree to or reject the automated decision-making results. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0033] Embodiments of this application provide a risk identification method, comprising: constructing a target topology graph based on business information and device information of physical devices associated with the business, wherein the nodes of the target topology graph at least represent business nodes and / or physical device nodes, and the edges of the topology graph at least represent business process relationships and / or physical device connection relationships; determining at least one important node among the nodes based on the edges of each node and the path in which the node is located; calculating the static vulnerability of each node, wherein the static vulnerability represents the degree of risk corresponding to the node's own attributes; calculating the dynamic risk of the important node based on the static vulnerability of the important node, wherein the dynamic risk represents the degree of impact caused by the failure of the important node; and identifying risky nodes based on the static vulnerability and the dynamic risk.

[0034] Figure 1 The diagram illustrates an application scenario for risk identification according to an embodiment of this application.

[0035] like Figure 1 As shown, application scenario 100 according to this embodiment may include a target network environment to be analyzed. This environment may include terminal devices 101, 102, 103 and server 105, which are interconnected via network 104. Network 104 serves as a medium for providing communication links between terminal devices 101, 102, 103 and server 105, and may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0036] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various computing devices that constitute the target network environment, such as maintenance terminals used by administrators for system management, office computers used by employees, or business servers that provide specific services. These devices are potential analysis objects for risk identification in this application embodiment.

[0037] Server 105 can be a risk identification server, used to execute the risk identification method provided in the embodiments of this application. Specifically, server 105 can collect asset information, connection relationships, vulnerability data, and real-time operational status data from the target network environment (including terminal devices 101-103 and other physical or virtual assets not shown in the network environment). Subsequently, server 105 analyzes and processes the collected data, such as constructing a network topology map, identifying important nodes, calculating static vulnerabilities and dynamic risks, and finally determining risky nodes, presenting the analysis results to the security administrator or triggering automated response actions.

[0038] It should be noted that the risk identification method provided in this application embodiment can generally be executed by server 105. Correspondingly, the risk identification device provided in this application embodiment can generally be located in server 105. The risk identification method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the risk identification device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0039] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0040] The following will be based on Figure 1 The described scene, through Figures 2-5 The risk identification method according to the embodiments of this application will be described in detail.

[0041] Prior to implementing the solution of this application, data processing operations may also be included. These operations include: acquiring raw data such as business asset data, historical vulnerability information, attack event information, risk quantification standards, and business process relationships from one or more heterogeneous data sources, such as an asset management system, configuration management system, and production management system. After acquiring the raw data, the raw data is cleaned and standardized.

[0042] The cleaning process may include the following steps:

[0043] First, perform deduplication. For example, for asset or configuration data, the asset code and CI identifier (Configuration Item Identifier) ​​can be combined into a composite primary key, and duplicate data records can be removed by judging the uniqueness of the composite primary key. For attack event or vulnerability data, the technology type and discovery time field can be combined into a composite primary key, and similar attack events launched by the same attack source against the same target within a specific time window (e.g., within 10 minutes) can be merged into a single continuous attack.

[0044] Secondly, perform invalid data filtering. For example, for asset or configuration data, devices that are offline or have no activity for a preset period (e.g., 90 days) can be marked as invalid data after manual verification; for attack or vulnerability data, data that is confirmed as a false alarm or is manually verified as an error can be marked as invalid data.

[0045] Secondly, conflict arbitration is performed. For example, when a single asset record in the data source has multiple ownership or dependency relationships, a ruling can be made based on preset business importance or business dependency weights; when there is a contradiction between system records and manual records, the result of manual verification shall prevail.

[0046] Standardization aims to establish a unified format and quantification rules for data from different sources and of different types, and may include at least one of the following:

[0047] Business asset data is standardized to include fields such as asset code, CI identifier, management personnel, asset value level, deployment location, and equipment type. Among them, the asset value level can be quantified into progressive levels from 1 to 10 based on the coreness of the business system to which it belongs.

[0048] Historical vulnerability information is standardized to include fields such as vulnerability number, CVE number (Common Vulnerabilities and Exposures), vulnerability type, remediation status, affected assets, and discovery time. The remediation status can be quantified, for example, "1" indicates remediated, and "0" indicates other statuses.

[0049] The attack event information is standardized to include fields such as source IP address, target device, attack type, attack time, and attack status. The attack status can be quantified, for example, with "1" indicating a successful attack and "0" indicating a failed attack.

[0050] The risk quantification standard is standardized, and risks are divided into multiple levels such as emergency, high risk, medium risk, low risk, and warning based on dimensions such as utilization complexity and sensitivity, and assigned a quantitative value of "5" to "1" respectively.

[0051] The business process relationships are standardized to include fields such as service call relationships, dependency levels, critical link markers, and SLA (Service Level Agreement) levels. Among them, the core indicators of the SLA level, such as service availability, can be mapped to different quantitative coefficient values ​​(such as 0.6, 0.8, etc.) based on their percentages (such as 99.9%, 99.99%).

[0052] Figure 2 A flowchart illustrating a risk identification method according to an embodiment of the present disclosure is shown schematically.

[0053] like Figure 2 As shown, the risk identification method may include at least operations S210 to S250.

[0054] In operation S210, based on the business information and the device information of the physical devices associated with the business, a target topology graph is constructed. The nodes of the target topology graph represent at least business nodes and / or physical device nodes, and the edges of the topology graph represent at least business process relationships and / or physical device connection relationships. Nodes represent various objects in the system, such as business applications or physical servers; edges represent the relationships between these entities, such as the call flow between business applications or the physical network cable connection between servers.

[0055] For example, a physical server can be abstracted as a physical device node, and the order processing system running on that server can be abstracted as a business node. These two nodes can be connected by an edge representing a "deployed on" relationship. If the order processing system needs to call another inventory query system, an edge representing a "service call" relationship can be established between these two business nodes (the inventory query system and the order processing system).

[0056] In operation S220, based on the edges of each node and the paths they occupy, at least one important node is identified among all nodes. An important node is one that has a high structural influence in the target topology graph, and its state changes can significantly affect the overall connectivity or functionality of the network. Based on the structure of the target topology graph, nodes occupying key positions in the network are analyzed and identified. Important nodes are typically hubs in the network; compared to other ordinary nodes, the loss of functionality or connectivity of important nodes will affect a wider range of business processes or system functions.

[0057] In S230, the static vulnerability of each node is calculated. Static vulnerability characterizes the degree of risk corresponding to the node's inherent attributes. Static vulnerability quantifies the extent to which a node is exposed to potential threats due to its inherent and relatively stable attributes (such as configuration flaws, known vulnerabilities, etc.), and this risk level does not depend on whether there is any active attack behavior. For example, a web server node with a high-risk, unpatched CVE vulnerability in its operating system and unnecessary management ports exposed to the outside world will have a high static vulnerability score. Conversely, a server node with complete system patches, compliant configuration, and deployed firewalls and other protective measures will have a lower static vulnerability score.

[0058] In operating S240, based on the static vulnerabilities of critical nodes, the dynamic risk of these nodes is calculated. Dynamic risk characterizes the impact of a critical node's failure. Dynamic risk is a predictive risk metric used to assess the potential scope and severity of damage to the entire system caused by the chain reaction triggered by a critical node's failure or successful attack. Calculating the dynamic risk of a critical node involves, based on its known static vulnerabilities, combining the node's business dependencies and connectivity relationships in the target topology, simulating the propagation and spread of risk in the network when the node fails. Calculating the dynamic risk of a critical node can consider the dependencies of other nodes connected to it, thereby assessing the systemic impacts such as service interruptions and degradation that its failure may cause.

[0059] For example, for an authentication service node that is identified as an important node, even if its static vulnerability is medium, since the vast majority of business systems within the enterprise rely on it to provide login verification services, once the node fails, it will cause a wide range of business systems to be unable to log in. Therefore, this important node will have a very high dynamic risk.

[0060] When operating the S250, risk nodes are identified based on static vulnerability and dynamic risk. A risk node is a node with inherently high security vulnerabilities; its failure would have severe consequences for the system. Specifically, identifying risk nodes involves comprehensively judging the results of static vulnerability assessments and dynamic risk assessments. A node must possess both high static vulnerability and high dynamic risk to be ultimately identified as a risk node requiring priority attention and action. For example, a node with high static vulnerability but located at the network edge, whose impact after failure is small (i.e., low dynamic risk), may not be identified as a high-priority risk node. Conversely, another important node with both high static vulnerability and high dynamic risk will be explicitly identified as a risk node, requiring immediate action.

[0061] According to embodiments of this application, by constructing a target topology graph that reflects the coupling relationship between the physical layer and the business layer, and based on this, the static vulnerability (characterizing its own defects) and dynamic risk (characterizing systemic impact) of nodes are calculated differentially, achieving accurate risk identification. Compared to traditional methods that only focus on individual vulnerabilities or assets, this application can accurately locate "risk nodes" that are both security threats and in critical positions from a holistic system perspective, avoiding the investment of excessive security resources in non-critical nodes, thereby significantly improving the accuracy of risk identification and the efficiency of subsequent security protection.

[0062] Based on the foregoing embodiments, operation S210 may include the following operations.

[0063] Business asset nodes are identified based on business information. Each business asset node represents at least one of the following: asset value level, service call relationship, dependency level, and service level agreement (SLA) level. Specifically, entities in the logical layer, application layer, or service layer of the information system are abstracted into analyzable business asset nodes. Each business asset node carries attribute information describing its characteristics from a business perspective. For example, the importance of the business asset in the entire business system (reflected in the asset value level), its interaction method with other business assets (reflected in the service call relationship and dependency level), and its promised service quality level (reflected in the SLA level). For example, an "online transaction system" can be identified as a business asset node. Its asset value level can be set to high (e.g., "9") based on its core business attributes, its service call relationship can be recorded as "calling the inventory management system," and its SLA level can be set to the quantitative value corresponding to "99.99%" based on business requirements.

[0064] Physical device nodes are identified based on device information. Each physical device node represents at least one of the following: device type, administrator, and deployment location. Specifically, the physical infrastructure entities supporting the operation of the information system are abstracted into analyzable physical device nodes. Each physical device node carries attribute information describing its physical characteristics, such as the device's hardware category (e.g., server, network device), its physical or network topology location, and the information of the administrators responsible for its operation and maintenance. For example, a "Server No. 2" deployed in "City A Data Center" can be identified as a physical device node, with its device type being "Server-2," its deployment location being "City A Data Center," and its administrator being recorded as the corresponding employee unified authentication code.

[0065] Based on business processes, the correspondence between business operations and physical devices, and the deployment relationships between physical devices, at least some of the business asset nodes and physical device nodes are merged or connected to construct a target topology map. Specifically, based on the relationships at different levels, the nodes identified in the preceding steps, belonging to different levels, are connected to form a unified, multi-layered coupled target topology map. Connections can include: connections between business asset nodes, established based on service call relationships in business processes; connections between physical device nodes, established based on physical connections or network adjacencies between devices; and connections between business asset nodes and physical device nodes, established based on the deployment relationships of business systems on physical devices.

[0066] For example, the "Online Transaction System" business asset node identified in the aforementioned operations is connected to the "Server No. 2" physical device node identified in the aforementioned operations through an edge representing a "deployed on" relationship. Simultaneously, if the "Online Transaction System" calls the "Inventory Management System," an edge representing a "service call" relationship is established between these two business asset nodes (the Online Transaction System node and the Inventory Management System node).

[0067] According to embodiments of this application, by distinguishing and separately identifying business asset nodes and physical device nodes, and connecting these nodes at different levels based on business processes, deployment relationships, etc., a multi-layer network topology that clearly reflects the coupling relationship between the business layer and the physical layer is constructed. Compared to analyzing all entities on a single plane, this multi-layer model can more accurately and realistically depict the complex structure of modern information systems, providing a structured foundation for subsequent precise risk analysis, thereby improving the depth and accuracy of risk identification.

[0068] Based on the foregoing embodiments, operation S210 may also include the following operations.

[0069] The system acquires attack path information for a pre-defined attack event. Based on this information, it identifies attack event nodes, each representing at least one of the following: the target device, the attack type, and the attack time. An attack event node is an entity formed by abstracting and structuring a specific, already-occurring network attack. Specifically, key attack elements are extracted from attack data obtained from sources such as security monitoring systems and log files, and encapsulated into an independent attack event node. The attributes represented by this node, such as the target, the technical means used, and the time of the attack, collectively constitute a profile of the attack event. For example, if the security information and event management system records an alarm stating "The host with IP address 1.2.3.4 launched an SQL injection attack against Web server 10.0.0.5 at 15:30," then an attack event node can be identified. This node represents the attack type as "SQL injection," the target device as "Web server 10.0.0.5," and the attack time as "15:30."

[0070] The attack event nodes are merged or connected to nodes in the target topology graph based on the association between the attack event and the business operations, and / or physical devices. Specifically, the attack event nodes, which represent abstract attack behaviors and are identified in the preceding steps, are connected to nodes representing concrete objects in the target topology graph, thereby explicitly expressing the relationship between the attack and the attacked object in the graph model. For example, based on the target device identifier (such as asset code, IP address, etc.) recorded in the attack event information, the corresponding business asset node or physical device node is located in the target topology graph, and then an edge is created between the two.

[0071] For example, continuing the previous example, after locating the physical device node representing "Web Server 10.0.0.5" in the target topology graph, an edge is drawn from the attack event node representing "SQL Injection Attack" and connected to that physical device node. This edge visually represents on the topology graph that the server has suffered an SQL injection attack.

[0072] According to embodiments of this application, by introducing attack event nodes and associating them with asset nodes in the target topology graph, actual network attack behaviors are mapped onto a structured model that includes business and physical layer relationships. Compared to a static topology graph that only contains asset and business relationships, this fusion makes risk analysis no longer a purely structural deduction, but rather able to intuitively show which assets are currently or have been attacked by combining actual attack data. This provides direct, event-driven input for subsequent identification of attack paths and assessment of the actual risk exposure level, greatly enhancing the realism and timeliness of risk identification.

[0073] Based on the foregoing embodiments, operation S210 may include the following operations.

[0074] Historical vulnerability information represents historical data associated with discovered vulnerabilities. Specifically, it involves collecting data on identified security flaws within information systems from one or more sources, such as vulnerability scan reports, security bulletins, and production management systems. For example, a network scan using a vulnerability scanning tool might yield a report indicating a publicly disclosed database software vulnerability (vulnerability number ABC) on a server (asset code 001). The relevant entry in this report constitutes the acquired historical vulnerability information.

[0075] Based on historical vulnerability information, historical vulnerability nodes are identified. Each historical vulnerability node represents at least one of the following: a vulnerability's risk quantification value, its patching status, the assets affected, the time of its occurrence, and its duration. Specifically, each discovered vulnerability record is abstracted and instantiated into an independent, analyzable historical vulnerability node. This node acts as a data container, carrying attributes describing the core characteristics of the vulnerability, such as its severity level, whether it has been patched, which specific asset it affects, and the time information of its discovery and persistence. For example, for the aforementioned discovered vulnerability, a historical vulnerability node can be identified. The attributes represented by this node may include: a risk quantification value (assigned a preset value based on its severity, such as "4"), a patching status ("0" if not patched), affected assets (recorded as 001), and the time of occurrence (recording the date the vulnerability was discovered).

[0076] Based on the association between attack events and business operations, and / or physical devices, historical vulnerability nodes are merged or connected to nodes in the target topology graph. Specifically, historical vulnerability nodes representing abstract security flaws are connected to nodes in the target topology graph representing specific affected assets. Based on the "affected assets" information contained in the historical vulnerability information, the corresponding business asset nodes or physical device nodes are located in the target topology graph, and then an edge representing the "existence" or "impact" relationship is created between them.

[0077] For example, after finding the physical device node representing asset "001" in the target topology graph, the historical vulnerability node representing vulnerability ABC, which was determined in the previous steps, is connected to the physical device node through an edge.

[0078] According to embodiments of this application, by introducing historical vulnerability nodes and associating them with asset nodes in the target topology graph, the inherent, static security flaws of the assets are integrated into a multi-layer network model in a structured manner. Compared to a topology graph that only contains assets and their connections, this integration allows the topology graph to not only show "what is there" but also "where the weaknesses are." This provides direct and visualized data input for subsequent static vulnerability analysis, enabling risk assessment to move beyond a macro-level analysis detached from specific asset defects and instead consider specific vulnerability levels, thereby significantly improving the accuracy and depth of risk identification.

[0079] Based on the foregoing embodiments, operation S220 may include the following operations.

[0080] The importance of each node is calculated, representing a combination of its primary and secondary importance scores. Primary importance reflects the node's connectivity with neighboring nodes, while secondary importance reflects its frequency of appearance in shortest paths within the target topology. Primary importance measures a node's local influence or connectivity breadth; secondary importance measures its role as a "bridge" or "mediator" in the network. The overall influence of a node is evaluated by combining these two different dimensions. Specifically, first, primary and secondary importance scores are calculated separately for each node. Then, these two scores are combined using a pre-defined algorithm (e.g., weighted summation) to form a single, comprehensive importance score.

[0081] Nodes are designated as important nodes if their importance score is greater than or equal to a certain threshold. This threshold is a pre-defined value used as a baseline for determining whether a node is important. After calculating the overall importance score for all nodes in the network, each node's score is compared to this threshold. Nodes whose scores reach or exceed the threshold are selected and marked as important nodes.

[0082] According to embodiments of this application, by merging the first importance level representing the local influence of a node with the second importance level representing its global bridging role, a multi-dimensional and more comprehensive assessment of the importance of a node can be achieved. Compared to assessment methods that rely solely on a single indicator (e.g., considering only the number of connections), this avoids potential biases and can identify both "central" nodes with numerous connections and "hub" nodes with fewer connections but crucial locations, thus making the identification of important nodes more accurate and reliable.

[0083] Based on the foregoing embodiments, the calculation process for the first importance level may include the following operations.

[0084] The first importance level is calculated based on the number of edges connected to a node and the total number of nodes in the target topology network. First, for a given node in the target topology graph, the total number of edges directly connected to it is counted; this number is the "number of edges connected to the node". Then, to eliminate the influence of network size on the absolute value of this number and make it comparable, the number of edges can be normalized. One normalization method is to divide the number of edges by a value related to the total number of nodes in the network (e.g., the total number of nodes minus one), resulting in a relative value between 0 and 1, which is the first importance level.

[0085] For example, in a target topology containing 100 nodes (including physical device nodes and business asset nodes), if a core switch node is directly connected to 20 other server nodes or business nodes, then its "number of edges connected to the nodes" is 20. In this case, its first importance can be calculated as 20 divided by (100-1), which is approximately equal to 0.202.

[0086] According to embodiments of this application, a standardized method is provided to quantify the primary importance of a node by correlating the number of edges directly connected to a node with the total number of nodes in the network. This makes the assessment of a node's local influence no longer an isolated absolute value, but a relative indicator that can be objectively measured within the context of the entire network.

[0087] Based on the foregoing embodiments, the calculation process for the second degree of importance may include the following operations.

[0088] The shortest path in the target topology is determined by finding the shortest path between any two nodes in the topology, excluding the node currently being evaluated. This involves traversing all node pairs in the target topology except for the node currently being evaluated, and finding the path connecting each pair with the fewest edges. These found paths collectively form the set of paths used to evaluate the global network flow. For example, in the target topology, to evaluate the second importance of node C, we need to first find the shortest path between node A and node B, the shortest path between node A and node D, the shortest path between node B and node D, and so on, until all node pairs that do not include node C are covered.

[0089] The process involves identifying the target shortest path that passes through each node in the shortest paths. After obtaining the set of shortest paths from the previous steps, this operation checks each path in the set to determine if the node to be evaluated exists on that path. All paths containing the node to be evaluated are filtered out to form the set of target shortest paths. For example, when evaluating node C, if the shortest path between node A and node B is ACB, then that path will be identified as a target shortest path.

[0090] The ratio of the number of target shortest paths to the total number of shortest paths is used as the second importance level. The second importance level of a node is calculated by dividing the number of target shortest paths (i.e., the number of paths passing through the node being evaluated) by the total number of all shortest paths. For example, if there are a total of 100 shortest paths between all other node pairs in the network, and 25 of them pass through node C, then the second importance level of node C is calculated as 25 divided by 100, which is 0.25.

[0091] According to embodiments of this application, by calculating the frequency of a node's appearance in all shortest paths of the network, the "mediator" or "bridge" role of the node in the global information flow can be accurately quantified. This allows for the identification of nodes that, although having a small number of direct connections, control critical communication paths in the network. This overcomes the shortcomings of relying solely on the number of connections to assess node importance, and can more deeply reveal potential bottlenecks and key control points in the network topology.

[0092] Based on the foregoing embodiments, operation S230 may include the following operations.

[0093] Identify at least one object corresponding to a node. This object represents a target asset that can be attacked, including at least one of physical devices, virtualized resources, applications, and stored data. A node in a topology graph is further decomposed into its smallest independently assessable unit of risk, i.e., an object. A node (such as a server) may consist of multiple objects at different levels (such as the operating system, database service, web application, etc. running on it), each of which can be an independent attack target. For example, an "online payment gateway" identified as a "business asset node" can be decomposed into multiple objects, including the physical device object of the "web server" hosting the gateway, and the application object of "payment processing" running on it.

[0094] The basic vulnerability is calculated based on the object's exposure coefficient, vulnerability risk value, and corresponding preset protection strength. The exposure coefficient characterizes the exploitability of the object under preset conditions, while the vulnerability risk value characterizes the risk value of the object's corresponding preset basic risk over time. The exposure coefficient measures the ease with which an attacker can access and exploit an object; the vulnerability risk value measures the severity of the security flaws inherent in the object itself, taking into account the potential increase in risk over time; and the preset protection strength quantifies the effectiveness of deployed security measures to mitigate attacks against the object. A preset calculation model combines the evaluation results of these three dimensions—vulnerability risk value, exposure coefficient, and protection strength—to derive a quantitative score that comprehensively reflects the object's single-layer security status, namely, the basic vulnerability.

[0095] For example, if an object has a high vulnerability risk (e.g., an unpatched critical vulnerability) and a high exposure factor (e.g., directly exposed to the internet), then even if its protection strength is medium, its calculated basic vulnerability score will still be very high. Conversely, an object with a low vulnerability risk, if deployed in an isolated network (low exposure factor) and with multiple protection measures (high protection strength), will have a very low basic vulnerability score.

[0096] The static vulnerability of a node is calculated based on the relationships between the objects corresponding to that node and the basic vulnerabilities of each object. Relationships describe the composition or dependency relationships between a node and its corresponding objects. After calculating the basic vulnerabilities of each object that constitutes a node, this operation aggregates their individual basic vulnerabilities based on how these objects collectively contribute to the node's functionality, thus obtaining the overall static vulnerability of the node. The aggregation method depends on the relationships between these objects.

[0097] For example, a server node may correspond to both an operating system and a database. After calculating the basic vulnerabilities of these two objects separately, the system will combine the scores of these two basic vulnerabilities according to a preset aggregation rule to obtain the final static vulnerability of the server node.

[0098] According to embodiments of this application, a multi-dimensional, hierarchical static vulnerability assessment model is established by decomposing nodes into more granular "objects" for analysis and calculating the basic vulnerability of each object from three dimensions: vulnerability risk, exposure level, and protection strength. Compared to performing a single, general risk assessment on a node, this model can more accurately characterize the security status of different components within the node and ultimately aggregate to form an overall vulnerability assessment result for the node, thereby significantly improving the granularity and accuracy of static risk identification.

[0099] Based on the foregoing embodiments, calculating basic vulnerabilities may include the following operations.

[0100] This section describes the duration for which a vulnerability remains unpatched after its discovery. A time dimension is introduced for each discovered but unpatched vulnerability. By querying vulnerability management records or scanning historical data, the time elapsed from the date a vulnerability was first discovered to the current assessment time is determined; this time is the duration. For example, if a vulnerability was discovered and recorded on May 1, 2025, and was still unpatched when assessed on July 31, 2025, its unpatched duration is approximately 90 days.

[0101] The vulnerability risk value is calculated based on the duration and the preset basic risk corresponding to the object. The preset basic risk is a baseline score set in advance based on the inherent severity of the vulnerability (e.g., critical, high-risk, medium-risk). The preset basic risk is used as the baseline, and an efficiency coefficient is applied to adjust it according to the duration of the vulnerability that has not been patched. The longer the duration, the larger the efficiency coefficient, and the higher the calculated vulnerability risk value. For example, the preset baseline risk value can be defined as: critical (5) -0.9, high-risk (4) -0.7, medium-risk (3) -0.5, low-risk (2) -0.3, warning (1) -0.1. Vulnerability risk value = baseline risk x (1 + efficiency coefficient), where the efficiency coefficient = 0.2 x min (2, number of days not patched / 90). If the duration of a "high-risk" vulnerability is 90 days, its vulnerability risk value can be calculated as: 0.7 × (1 + 0.2) = 0.84.

[0102] An exposure coefficient is calculated based on the exploit difficulty and network location coefficient of an object. Exploitation difficulty represents the minimum requirements for attacking the object, while the network location coefficient represents the ease of accessing the object. These two dimensions are combined: first, the object's network reachability, i.e., the network location coefficient; and second, the technical threshold required to exploit the vulnerability itself, i.e., the exploit difficulty. Multiplying these two coefficients yields a comprehensive exposure coefficient value. For example, the network location coefficient can be assigned based on the object's deployment area: Internet exposure (public network reachability) -0.9, isolated zone (indirect exposure) -0.6, internal network core zone (with boundary protection) -0.3, isolated zone (physical isolation) -0.1. Exploitation difficulty can be: direct access without authentication -1.0, low-privilege account required -0.7, local network access required -0.4, social engineering attack required -0.2. An object deployed in an isolated zone (network location coefficient 0.6) whose vulnerability can be exploited without authentication (exploitation difficulty 1.0) has an exposure coefficient of 0.6 × 1.0 = 0.6.

[0103] The basic vulnerability is obtained by multiplying the vulnerability risk value by the exposure coefficient and then dividing the preset protection strength of the object. A raw risk exposure is obtained by multiplying the vulnerability risk value (reflecting the inherent danger of the vulnerability) by the exposure coefficient (reflecting its exploitability). This raw risk exposure is then divided by a preset protection strength value that characterizes the effectiveness of existing security measures, thus reflecting the mitigation effect of the protection measures on the raw risk. The final quantitative basic vulnerability score is obtained, as shown in the following formula.

[0104]

[0105] Protection strength quantifies the ability of existing protection measures to mitigate vulnerabilities. For example, protection strength = min(1, 0.1 + 0.15 * number of effective protection measures). Effective protection measures may include: firewalls, intrusion detection, host protection, encrypted transmission, two-factor or multi-factor authentication, log auditing, etc.

[0106] For example, if an object has a vulnerability risk value of 0.84, an exposure coefficient of 0.6, and a corresponding preset protection strength value of 1.2, then its basic vulnerability can be calculated as: (0.84×0.6) / 1.2=0.42.

[0107] According to embodiments of this application, the assessment process for fundamental vulnerabilities is transformed from qualitative description to quantitative, repeatable calculation. By introducing a "duration" factor to dynamically adjust vulnerability risk values, the assessment results reflect the cumulative effect of risks over time. Simultaneously, by combining "exploitation difficulty" and "network location" to calculate the exposure coefficient, the assessment of exploitability becomes more refined and closer to real-world scenarios. This multi-dimensional, data-driven quantitative calculation method significantly improves the objectivity, accuracy, and comparability of vulnerability assessments.

[0108] Based on the foregoing embodiments, the static vulnerability of computing nodes may include the following operations.

[0109] In response to the association relationship indicating that a node has only one corresponding object, the object's basic vulnerability is used as the node's static vulnerability. In simple scenarios where there is a one-to-one correspondence between a node and an attackable target asset, the node itself does not contain a more complex internal structure; its overall security status is entirely determined by the unique object it corresponds to. Therefore, the basic vulnerability value of that object is directly assigned to the node as its static vulnerability. For example, a node in a target topology graph represents only one independent firewall device, which is considered as a single object. If the calculated basic vulnerability of this firewall object is 0.2, then the static vulnerability of the firewall node is also 0.2.

[0110] In response to the relationship that a node corresponds to multiple objects, and these objects are not associated with a pre-defined critical business system, the average of the basic vulnerabilities of each object is used as the node's static vulnerability. A pre-defined critical business system refers to a system whose functional failure or data breach will have a significant impact on core business operations, once pre-identified. When a node represents an asset cluster composed of multiple homogeneous or non-core components (e.g., a load-balanced web server cluster), the failure of a single object does not necessarily lead to the interruption of the entire node's functionality. Therefore, calculating the arithmetic mean of the basic vulnerabilities of all objects can objectively reflect the overall, average vulnerability level of the node. For example, a node represents an asset cluster consisting of three web server objects (objects A, B, and C), which is not a critical business system. If the basic vulnerabilities of these three server objects are calculated to be 0.3, 0.4, and 0.5 respectively, then the node's static vulnerability is the average of these three values: (0.3 + 0.4 + 0.5) / 3 = 0.4.

[0111] In response to the scenario where a node represents a critical business system and contains multiple objects, including those associated with a predefined critical business system, the maximum value of the basic vulnerabilities of each object is taken as the node's static vulnerability. When a node represents a critical business system, the components (such as application servers, databases, and middleware) are tightly coupled. A security flaw in any one object can become the "weakest link" in the entire system, leading to the paralysis or compromise of the entire critical business. Therefore, following the "barrel principle," the highest basic vulnerability value among all objects is selected as the static vulnerability of the entire node. For example, a node represents a critical online transaction system composed of an application server object (basic vulnerability of 0.4) and a database server object (basic vulnerability of 0.7). Since this system is a critical business system, the node's static vulnerability should be the maximum of the two, i.e., 0.7.

[0112] The overall formula is as follows.

[0113]

[0114] Where n is the total number of objects.

[0115] According to embodiments of this application, a scenario-adaptive static vulnerability calculation method is implemented by differentiating the aggregation methods of internal object vulnerabilities based on the nature of nodes (whether they are independent assets or critical business systems). Compared to calculations using a single fixed rule (such as always calculating the mean or maximum value), this method can provide assessment results that better reflect the risk characteristics of different types of assets: the mean method is used for ordinary clusters to reflect the overall level, while the maximum value method is used for critical systems to focus on their weakest points. This differentiated aggregation strategy makes the final calculated static vulnerability values ​​of nodes more targeted and convincing.

[0116] Based on the foregoing embodiments, operation S240 may include the following operations.

[0117] The dependency coefficient for a node is calculated based on its dependency level and service level agreement (SLA) rating. A pre-defined merging algorithm weights and combines the "dependency level" value (representing the tightness of business process dependencies) with the quantified value corresponding to the "Service Level Agreement" (SLA) rating, representing the service quality commitment, to obtain a comprehensive dependency coefficient. For example, a node's dependency level might be quantified as 0.8 based on its coreity in the business call relationship, and its SLA rating might be "99.999%", with a quantified value of 1.0. If the pre-defined weighted merging algorithm is: Dependency Coefficient = 0.6 × Dependency Level + 0.4 × SLA Rating Quantified Value, then the dependency coefficient for this node can be calculated as: 0.6 × 0.8 + 0.4 × 1.0 = 0.88.

[0118] The dynamic risk of a node is calculated based on the ratio of its load to its maximum preset load, its static vulnerability, and its dependency coefficient. The dynamic risk is determined by multiplying these three core dimensions: the node's dependency coefficient (representing the breadth of impact if it fails), its static vulnerability (representing its inherent security flaws), and its load ratio (representing its current operational pressure). For example, continuing the previous example, if the node's dependency coefficient is 0.88, its static vulnerability calculated in the preceding steps is 0.5, and its current load is 70% of its maximum preset load (i.e., a ratio of 0.7), then the node's dynamic risk can be calculated as: 0.88 × 0.5 × 0.7 = 0.308.

[0119] Conversely, the dynamic risk P of the entire network can be:

[0120]

[0121] Among them, W i V represents the dependency coefficient of node i.i For the static vulnerability of node i, A i / C i K represents the service load carried by node i / the preset maximum service load. s This is the critical path coefficient, used to identify critical links; a critical path coefficient of 1.5 is used for critical paths, and 1 otherwise.

[0122] According to embodiments of this application, by innovatively introducing the ratio of a node's current "business load" to its "maximum load" when calculating dynamic risk, risk assessment is expanded from purely static structural and inherent defect analysis to consideration of the system's actual operating state. This allows for the identification of risks that are not apparent under normal load but may be triggered under high load pressure (e.g., system crashes caused by performance bottlenecks). By combining the node's inherent vulnerability (static vulnerability), business importance (dependency coefficient), and real-time operating pressure (load ratio), this application can predict node failure risks more dynamically and realistically.

[0123] Figure 3 Another flowchart of a risk identification method according to an embodiment of the present disclosure is illustrated schematically.

[0124] like Figure 3 As shown, based on the aforementioned embodiments, the risk identification method may further include operations S310 to S330.

[0125] S310, in response to identifying risk nodes, generates and sends risk alert information corresponding to those nodes. High-risk targets are identified and notified in real-time to relevant security operations personnel or automated processing systems in the form of structured alert information. Risk alert information may include the unique identifier of the risk node, its static vulnerability score, dynamic risk score, key factors constituting the risk (e.g., specific vulnerability number, critical business link it is located in, etc.), and a suggested initial handling level.

[0126] For example, when a database server "DB-01" is identified as a risk node, the system can automatically generate an alert message and send it to the database administrator via email or enterprise instant messaging tools. The message content could be: "[High-risk alert] Risk node identified: DB-01. Static vulnerability: 0.85, Dynamic risk: 0.92. Reason: An unpatched remote code execution vulnerability exists, and this node is a critical dependency of the core transaction system. Immediate isolation is recommended."

[0127] S320, in response to receiving the corresponding handling measures for the risk alarm information, a target relationship is constructed based on the time elapsed between sending the risk alarm information and receiving the handling measures, and the effectiveness of the corresponding measures. The target relationship characterizes the pattern of risk level changes over time at the risk node. The time elapsed represents the emergency response timeliness; the effectiveness of the measures is a quantitative value of the pre-set risk reduction capability for different handling methods (such as isolation, flow restriction, and repair). Using the initial risk value, the timeliness of the response (time elapsed), and the effectiveness of the measures (measure effectiveness) as input parameters, a decay curve describing the change of risk value from high to low is generated. This curve is the target relationship, and the specific formula is as follows:

[0128]

[0129] Among them, R t R0 represents the risk level at each risk node; t represents the response time, i.e., the emergency response timeliness, reflecting the time interval from the discovery and confirmation of a risk event to the implementation of the first handling measure; τ represents the risk half-life, for example, different values ​​are set according to different target business systems, 1 hour for core business systems and 3 hours for ordinary business systems; M r To assess the effectiveness of risk mitigation measures, for example, circuit breaker shutdown is rated at 0.9, flow restriction opening at 0.6, emergency reinforcement at 0.3, and version-based repair at 0.1.

[0130] S330, Based on the target relationship, determine the treatment plan for the risk node after the initial treatment measures. Predict the residual risk value at a future point in time (e.g., 24 hours later) based on the target relationship (attenuation curve). If the predicted value is still higher than the preset safety threshold, it indicates that the current single measure is insufficient to completely control the risk, and an upgraded or supplementary treatment plan will be automatically generated or recommended.

[0131] For example, continuing the previous example, based on the constructed target relationship, it was found that 24 hours after implementing the "flow restriction opening" measure, the predicted residual risk value of the node remained high. Therefore, the subsequent handling plan can be determined as follows: "The current 'flow restriction opening' measure is insufficient to reduce the risk to an acceptable level in the short term; it is recommended to implement 'circuit breaker closing' within 8 hours (measure effect M)." r (Version 0.9) or schedule an emergency maintenance window for version repair.

[0132] According to embodiments of this application, by introducing a closed-loop process of alarm, response assessment, and solution optimization after risk identification, risk management is transformed from a one-off identification action into a continuous and dynamic lifecycle management process. By constructing a target relationship (target relationship) that can quantify response timeliness and measure effectiveness, the effectiveness of emergency response can be objectively evaluated in a data-driven manner, and the future trend of risks can be predicted. This allows for the timely identification and adjustment of deficiencies in response measures, avoiding long-term risk exposure due to inappropriate or untimely measures, thereby significantly improving the closed-loop efficiency and overall security of risk management.

[0133] Based on the foregoing embodiments, operation S250 may include the following operations.

[0134] In response to static vulnerability exceeding a static vulnerability threshold and dynamic risk exceeding a dynamic risk threshold, the corresponding critical nodes are designated as risk nodes. Both the static vulnerability threshold and the dynamic risk threshold are pre-set numerical benchmarks used to differentiate risk levels. For a target identified as a "critical node," two core risk indicators are simultaneously examined: the "static vulnerability," representing the severity of its inherent security flaws; and the "dynamic risk," representing its probability of failure under current operating conditions. Only when the calculated values ​​of both indicators for a critical node simultaneously exceed their respective pre-set thresholds will the node be ultimately determined as a "risk node" requiring immediate attention and action.

[0135] For example, a static vulnerability threshold of 0.8 and a dynamic risk threshold (or cascading failure probability threshold) of 1 can be preset. A core database server that has been identified as an important node (e.g., in the top 10% of centrality) will be ultimately identified as a risk node if its calculated static vulnerability is 0.85 (greater than 0.8) and its dynamic risk is 1.2 (greater than 1), since both conditions are met.

[0136] After identifying these critical nodes as risk nodes, a layered, closed-loop defense and response system can be further constructed. For example, a layered defense strategy can be implemented for nodes with different risk levels:

[0137] For targets identified as risk nodes (i.e., high-potential risk nodes), multi-layered, in-depth protection measures can be automatically implemented. For example, at the network layer, traffic probes can be injected to monitor abnormal behavior; at the physical layer, out-of-band management channels can be pre-configured to achieve rapid port isolation; and at the data layer, transparent encrypted gateways can be deployed to protect core data fields. Simultaneously, it can be linked with a knowledge base and a predictive solution library. For instance, for risk nodes with unpatched vulnerabilities, virtual patch scripts can be automatically pushed, and circuit breaker thresholds can be preset.

[0138] For important nodes that do not meet the dual thresholds but still pose a certain risk (i.e., low-potential-risk nodes), a periodic immunization plan can be established. For example, reinforcement templates can be pushed regularly through a knowledge base and included in the automated inspection checklist.

[0139] In addition, after any defensive action is performed, a performance verification process can be initiated immediately. For example, at the technical level, scan to confirm the status of vulnerability remediation and the improvement value of protection strength; at the business level, check whether the fluctuation of service level agreement (SLA) is within an acceptable threshold; at the model level, recalculate the risk value of the node to verify whether the risk decreases according to the expected decay curve.

[0140] The verification data can be fed back to the analysis model in real time to dynamically optimize core parameters such as risk half-life, thereby forming a complete closed-loop prevention and control system covering risk prediction, dynamic deployment, and effectiveness verification.

[0141] Based on the above-described risk identification method, this application also provides a risk identification device. The following will be combined with... Figure 4 The device is described in detail.

[0142] Figure 4 A schematic block diagram of a risk identification device according to an embodiment of this application is shown.

[0143] like Figure 4 As shown, the risk identification device 400 in this embodiment includes a topology construction module 410, a first determination module 420, a first calculation module 430, a second calculation module 440, and a first identification module 450.

[0144] The topology construction module 410 is used to construct a target topology graph based on business information and device information of physical devices associated with the business. Nodes in the target topology graph at least represent business nodes and / or physical device nodes, and edges in the topology graph at least represent business process relationships and / or physical device connection relationships. In one embodiment, the topology construction module 410 can be used to perform the operation S210 described above, which will not be repeated here.

[0145] The first determining module 420 is used to determine at least one important node among the nodes based on the edges of each node and the path in which the node is located. In one embodiment, the first determining module 420 can be used to perform the operation S220 described above, which will not be repeated here.

[0146] The first calculation module 430 is used to calculate the static vulnerability of each node, whereby static vulnerability characterizes the risk level corresponding to the node's own attributes. In one embodiment, the first calculation module 430 can be used to perform the operation S230 described above, which will not be repeated here.

[0147] The second calculation module 440 is used to calculate the dynamic risk of important nodes based on their static vulnerability. The dynamic risk characterizes the impact of an important node's failure. In one embodiment, the second calculation module 440 can be used to perform the operation S240 described above, which will not be repeated here.

[0148] The first identification module 450 is used to identify risk nodes based on static vulnerability and dynamic risk. In one embodiment, the first identification module 450 can be used to perform the operation S250 described above, which will not be repeated here.

[0149] According to embodiments of this application, any multiple modules among the circuit construction module 410, the first determination module 420, the first calculation module 430, the second calculation module 440, and the first identification module 450 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the circuit construction module 410, the first determination module 420, the first calculation module 430, the second calculation module 440, and the first identification module 450 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in any one of the three implementation methods of software, hardware, and firmware, or in a suitable combination of any of these. Alternatively, at least one of the following modules can be implemented, at least partially, as a computer program module: the construction module 410, the first determination module 420, the first calculation module 430, the second calculation module 440, and the first identification module 450. When the computer program module is run, it can perform the corresponding function.

[0150] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a risk identification method according to an embodiment of this application.

[0151] like Figure 5As shown, an electronic device 500 according to an embodiment of this application includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage portion 508 into a random access memory (RAM) 503. The processor 501 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 501 may also include onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0152] RAM 503 stores various programs and data required for the operation of electronic device 500. Processor 501, ROM 502, and RAM 503 are interconnected via bus 504. Processor 501 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 502 and / or RAM 503. It should be noted that the programs may also be stored in one or more memories other than ROM 502 and RAM 503. Processor 501 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0153] According to embodiments of this application, the electronic device 500 may further include an input / output (I / O) interface 505, which is also connected to a bus 504. The electronic device 500 may also include one or more of the following components connected to the input / output (I / O) interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the input / output (I / O) interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0154] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0155] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 502 and / or RAM 503 and / or one or more memories other than ROM 502 and RAM 503 described above.

[0156] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code enables the computer system to implement the risk identification method provided in the embodiments of this application.

[0157] When the computer program is executed by the processor 501, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0158] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 509, and / or installed from a removable medium 511. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0159] In such an embodiment, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by processor 501, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0160] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0161] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0162] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A risk identification method, characterized in that, The method includes: Based on the business information of the business and the device information of the physical devices associated with the business, a target topology graph is constructed. The nodes of the target topology graph at least represent business nodes and / or physical device nodes, and the edges of the topology graph at least represent business process relationships and / or physical device connection relationships. Based on the edges of each node and the path in which the node is located, at least one important node is determined among each node; Calculate the static vulnerability of each node, whereby static vulnerability characterizes the degree of risk corresponding to the node's own attributes; Based on the static vulnerability of the important node, the dynamic risk of the important node is calculated, and the dynamic risk characterizes the degree of impact caused by the failure of the important node. Risk nodes are identified based on the static vulnerability and the dynamic risk.

2. The method according to claim 1, characterized in that, The construction of the target topology map includes: Based on the business information, business asset nodes are determined, and each business asset node represents at least one of the following: asset value level, service invocation relationship, dependency degree, and service level protocol level. Based on the device information, physical device nodes are determined, wherein the physical device node represents at least one of the device type, administrator, and deployment location of the device. Based on the business process of the business, the correspondence between the business and the physical devices, and the deployment relationship between the physical devices, at least some of the business asset nodes and the physical device nodes are merged or connected to construct the target topology map.

3. The method according to claim 2, characterized in that, The construction of the target topology graph also includes: Obtain attack path information for preset attack events; Based on the attack path information, attack event nodes are determined, wherein each attack event node represents at least one of the target device, attack type, and attack time in the attack path; The attack event nodes are merged or connected to nodes in the target topology based on the association between the attack event and the service, and / or the physical device.

4. The method according to claim 2, characterized in that, The construction of the target topology graph also includes: Obtain historical vulnerability information, which represents historical data associated with discovered vulnerabilities; Based on the historical vulnerability information, historical vulnerability nodes are determined. Each historical vulnerability node represents at least one of the following: the risk quantification value of the vulnerability, the remediation status of the vulnerability, the asset information affected by the vulnerability, the time of occurrence of the vulnerability, and the duration of the vulnerability. Based on the association between the historical vulnerability nodes and the service and / or the physical device, merge or connect them to nodes in the target topology graph.

5. The method according to any one of claims 1-4, characterized in that, The determination of at least one important node among the nodes includes: Calculate the importance of each node, where the importance represents the combination of the first importance and the second importance of the node. The first importance represents the connection status of the node with its neighboring nodes, and the second importance represents the frequency of the node's occurrence in each shortest path in the target topology graph. In response to the importance level being greater than or equal to the importance level threshold, the node is designated as the important node.

6. The method according to claim 5, characterized in that, The calculation process for the first level of importance includes: The first importance level is calculated based on the number of edges connected to the node and the total number of nodes in the target topology network.

7. The method according to claim 5, characterized in that, The calculation process for the second degree of importance includes: Determine the shortest path in the target topology graph, where the shortest path is the shortest path between any two other nodes in the topology graph excluding the node in question; Determine the target shortest path that passes through the nodes in each of the shortest paths; The ratio of the number of target shortest paths to the total number of shortest paths is used as the second importance level.

8. The method according to any one of claims 1-4, characterized in that, The calculation of the static vulnerability of each node includes: Identify at least one object corresponding to the node, the object representing a target asset that can be attacked, the target asset including at least one of physical devices, virtualized resources, applications, and stored data; The basic vulnerability is calculated based on the exposure coefficient of the object, the vulnerability risk value of the object, and the preset protection strength corresponding to the object. The exposure coefficient represents the degree to which the object can be exploited under preset conditions, and the vulnerability risk value represents the risk value of the preset basic risk corresponding to the object after being affected by time. The static vulnerability of a node is calculated based on the association relationships between the objects corresponding to the node and the basic vulnerabilities corresponding to each object.

9. The method according to claim 8, characterized in that, The computational vulnerability includes: Obtain the duration for which the vulnerability was not patched after it was discovered in the object; The vulnerability risk value is calculated based on the duration and the preset basic risk corresponding to the object. The exposure coefficient is calculated based on the exploitation difficulty of the object and the network location coefficient of the object. The exploitation difficulty represents the minimum requirement to attack the object, and the network location coefficient represents the ease or difficulty of accessing the object. The basic vulnerability is obtained by multiplying the vulnerability risk value by the exposure coefficient and then dividing the preset protection strength corresponding to the object.

10. The method according to claim 8, characterized in that, The calculation of the static vulnerability of the node includes: In response to the association relationship indicating that the node has only one corresponding object, the basic vulnerability of the object is taken as the static vulnerability of the node; In response to the association relationship indicating that the node corresponds to multiple objects and that the multiple objects are not associated with a preset key business system, the average of the basic vulnerabilities corresponding to each of the objects is taken as the static vulnerability of the node. In response to the association relationship indicating that the node corresponds to multiple objects, and that among the multiple objects there is an object associated with a preset key business system, the maximum value of the basic vulnerabilities corresponding to each of the objects is taken as the static vulnerability of the node.

11. The method according to any one of claims 1-4, characterized in that, The calculation of the dynamic risk of the important nodes includes: Calculate the dependency coefficient corresponding to the node based on the degree of dependency represented by the node and the service level protocol level; The dynamic risk of a node is calculated based on the ratio of the service load carried by the node to the preset maximum service load corresponding to the node, the static vulnerability of the node, and the dependency coefficient of the node.

12. The method according to any one of claims 1-4, characterized in that, The method further includes: In response to identifying the risk node, generate and send the risk alarm information corresponding to the risk node; In response to receiving the processing measures corresponding to the risk alarm information, a target relationship is constructed based on the time elapsed between sending the risk alarm information and receiving the processing measures, and the effect of the processing measures. The target relationship characterizes the pattern of change in the risk level of the risk node over time. Based on the target relationship, determine the processing plan for the risk node after the processing measures.

13. The method according to any one of claims 1-4, characterized in that, The identification of risk nodes based on the static vulnerability and the dynamic risk includes: In response to the static vulnerability being greater than the static vulnerability threshold and the dynamic risk being greater than the dynamic risk threshold, the corresponding important node is designated as the risk node.

14. A risk identification device, characterized in that, The device includes: The topology construction module is used to construct a target topology graph based on the business information of the business and the device information of the physical devices associated with the business. The nodes of the target topology graph at least represent business nodes and / or physical device nodes, and the edges of the topology graph at least represent business process relationships and / or physical device connection relationships. The first determining module is used to determine at least one important node among the nodes based on the edges of each node and the path where the node is located; The first calculation module is used to calculate the static vulnerability of each node, whereby the static vulnerability characterizes the risk level corresponding to the node's own attributes. The second calculation module is used to calculate the dynamic risk of the important nodes based on their static vulnerability, wherein the dynamic risk characterizes the impact of the important node's failure; and The first identification module is used to identify risk nodes based on the static vulnerability and the dynamic risk.

15. An electronic device comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 13.

16. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 13.

17. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 13.

Images