Risk deduction method for power grid assets and related equipment

Abstract

The embodiment of the invention provides a risk deduction method of power grid assets and related equipment, and belongs to the technical field of network security. The method comprises the steps of obtaining asset data of a power grid; performing relation graph construction according to the asset data to obtain an initial asset relation graph; performing risk calculation on different nodes according to the node information of the asset relation graph to obtain a target asset relation graph with risk weights; and performing risk deduction on the target asset relation graph according to the risk weight, and determining a target attack path. According to the embodiment of the invention, the accuracy and reliability of the target attack path deduction result can be improved.

Description

Technical Field

[0001] This application relates to the field of cybersecurity technology, and in particular to a risk simulation method and related equipment for power grid assets. Background Technology

[0002] Against the backdrop of rapid development in the informatization, digitalization, and networking of power systems, the operation and dispatch of power grids increasingly rely on distributed computing platforms, industrial control systems (ICS), and large-scale networked equipment. Power grids not only include core control layers such as dispatch control centers, substation automation systems, distribution management systems (DMS), and energy management systems (EMS), but also a vast number of support and auxiliary systems, such as metering data acquisition and management systems (MDMS), geographic information systems (GIS), office automation systems, and video surveillance systems. As these systems gradually achieve interconnection through dedicated communication networks or cross-domain data exchange platforms, the network boundaries and asset forms of power grids exhibit significant characteristics of "wide distribution, diverse types, complex relationships, and rapid changes."

[0003] At the same time, the form of cybersecurity threats has also undergone profound changes. Traditional security models that focus primarily on perimeter defense are no longer sufficient to meet the protection needs of the power grid throughout its entire lifecycle. Attackers often utilize entry points exposed on the public internet or in the supply chain to gradually approach core business objectives through multi-hop penetration across network domains.

[0004] In the field of power grid network security asset modeling and attack path analysis technology, most of the attack path deduction technologies are based on simple calculations of static reachability or hop count, which cannot generate high-risk paths that conform to the actual operation of the power grid.

[0005] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention

[0006] The main objective of this application is to propose a risk estimation method and related equipment for power grid assets, which can provide results that are more consistent with the actual situation of the power grid and improve the accuracy and reliability of the target attack path estimation results.

[0007] To achieve the above objectives, one aspect of this application proposes a risk estimation method for power grid assets, the method comprising: Obtain power grid asset data; Based on the asset data, a relationship graph is constructed to obtain an initial asset relationship graph; Risk calculations are performed on different nodes based on the node information of the asset relationship graph to obtain a target asset relationship graph with risk weights; Based on the risk weights, risk deduction is performed on the target asset relationship graph to determine the target attack path.

[0008] In some embodiments, acquiring power grid asset data includes: Data is collected from different assets of the power grid to obtain active detection data, passive flow data, and host agent data. The asset data is obtained by aggregating the active detection data, the passive traffic data, and the host proxy data.

[0009] In some embodiments, the step of constructing a relationship graph based on the asset data to obtain an initial asset relationship graph includes: The asset data is parsed and fused from multiple sources to obtain the asset entity; Based on the asset entities, the relationship is extracted from the asset data to generate directed edges representing the relationships between the asset entities; Based on the asset entities and the directed edges, a graph is constructed to obtain an initial asset relationship graph.

[0010] In some embodiments, the step of performing risk calculations on different nodes based on the node information of the asset relationship graph to obtain a target asset relationship graph with risk weight attributes includes: Based on the pre-stored vulnerability records, the attributes of each node in the target asset relationship graph are matched for vulnerabilities to obtain the vulnerabilities associated with the node. Vulnerability scoring is performed based on the vulnerabilities' metrics to obtain the node's base score; Determine the business impact factor of the node based on its business attributes; Risk weights are calculated based on the base score and the business impact factor to determine the risk weight of each node, thereby obtaining the target asset relationship map.

[0011] In some embodiments, the step of performing risk extrapolation on the target asset relationship graph based on the risk weights to determine the target attack path includes: By performing attack simulations on the target asset relationship graph, several potential attack paths for attacking power grid assets are obtained. The potential attack paths are calculated based on the risk weights to determine the target attack path.

[0012] In some embodiments, the risk extrapolation based on the target asset relationship graph to obtain several potential attack paths for attacks on power grid assets includes: Determine the target asset nodes in the target asset relationship graph; The target asset relationship graph is used to identify attack entry points and determine the set of nodes at the attack entry points; Based on the target asset node and the node set, a path traversal is performed to obtain several potential attack paths.

[0013] In some embodiments, determining the target attack path based on the risk weights of each node in the potential attack path includes: The risk weights are adjusted based on the business impact coefficients of the nodes to obtain the corrected risk weights; Based on the revised risk weights, the risks of each node are accumulated to obtain the risk value of the potential attack path; The potential attack path with the highest risk value is identified as the target attack path.

[0014] To achieve the above objectives, another aspect of this application proposes a risk simulation device for power grid assets, the device comprising: The acquisition module is used to acquire power grid asset data; The construction module is used to construct a relationship graph based on the asset data to obtain an initial asset relationship graph; The calculation module is used to perform risk calculations on different nodes based on the node information of the asset relationship graph to obtain a target asset relationship graph with risk weights. The deduction module is used to perform risk deduction on the target asset relationship graph based on the risk weights to determine the target attack path.

[0015] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0016] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0017] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer program product, including a computer program that, when executed by a processor, implements the aforementioned method.

[0018] The embodiments of this application include at least the following beneficial effects: This application provides a method and related equipment for risk estimation of power grid assets. This method involves acquiring power grid asset data; constructing a relationship graph based on the asset data to obtain an initial asset relationship graph; calculating the risk of different nodes based on the node information of the asset relationship graph to obtain a target asset relationship graph with risk weights; and performing risk estimation on the target asset relationship graph based on the risk weights to determine the target attack path. This application calculates the risk weight of nodes based on node information, accurately quantifying the importance and operational risk of assets corresponding to different nodes through risk weights. This makes the estimation of target attack paths more consistent with the actual operation of the power grid, improving the accuracy and reliability of the estimation results. Attached Figure Description

[0019] Figure 1 This is a flowchart of the risk extrapolation method for power grid assets provided in the embodiments of this application; Figure 2 This is a flowchart of the asset data acquisition process provided in the embodiments of this application; Figure 3 This is a flowchart of the initial asset relationship map construction process provided in the embodiments of this application; Figure 4 This is a flowchart of risk weight calculation provided in the embodiments of this application; Figure 5 This is a flowchart illustrating the generation of a target attack path provided in an embodiment of this application; Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0023] 1) Multi-source heterogeneous data: refers to power grid assets and their operation information from different acquisition methods, formats, protocols and sources.

[0024] 2) Active Probe Data: Asset reachability and open port information obtained through methods such as Internet Control Message Protocol (ICMP) and Transmission Control Protocol (TCP) SYN (synchronization sequence bit) probes.

[0025] 3) Passive traffic data: Traffic characteristics such as session 5-tuples, HTTP response headers, and TLS certificate information collected through network mirror ports.

[0026] 4) Host Agent Data: Process list, listening port, service tag and physical location information collected by the agent process installed on the asset host.

[0027] 5) External management data: sourced from the configuration management database (CMDB), log management platform, security information and event management system (SIEM), time series database, and the running status information of the industrial control protocol parser.

[0028] 6) Business Impact Factor (W_business): A coefficient obtained through hierarchical modeling of the power grid business system, used to measure the importance of assets in the overall operation of the power grid business. Its value can be dynamically adjusted according to business priority strategies and is reflected in the risk weight calculation formula.

[0029] 7) Comprehensive Risk Weight: A quantitative risk value obtained by combining the technical severity of the vulnerability (CVSS base score) with the business impact factor, representing the comprehensive risk level of the asset in terms of both technical exploitability and business harm.

[0030] 8) Dynamic Directed Asset Relationship Graph: A graph structure built with assets as nodes, business dependencies between assets, network strategies, physical locations, etc. as directed edges. It can be partially reconstructed as the collected data is updated and maintains consistency with the actual operating environment.

[0031] 9) Minimum high-risk attack path: The path selected from the set of paths from the attack entry node to the target asset node in the graph according to the principle of minimizing the total risk value of the path, while ensuring that the included nodes and edges meet the conditions of technical accessibility and high business risk.

[0032] Against the backdrop of rapid development in the informatization, digitalization, and networking of power systems, the operation and dispatch of power grids increasingly rely on distributed computing platforms, industrial control systems (ICS), and large-scale networked equipment. Power grids not only include core control layers such as dispatch control centers, substation automation systems, distribution management systems (DMS), and energy management systems (EMS), but also a vast number of support and auxiliary systems, such as metering data acquisition and management systems (MDMS), geographic information systems (GIS), office automation systems, and video surveillance systems. As these systems gradually achieve interconnection through dedicated communication networks or cross-domain data exchange platforms, the network boundaries and asset forms of power grids exhibit significant characteristics of "wide distribution, diverse types, complex relationships, and rapid changes."

[0033] Meanwhile, the forms of cybersecurity threats have also undergone profound changes. Traditional security models focused on perimeter defense are no longer sufficient to meet the protection needs of the power grid throughout its entire lifecycle. Attackers often exploit entry points exposed on the public internet or in the supply chain, gradually approaching core business targets through multi-hop penetration across network domains. In recent years, Advanced Persistent Threat (APT) incidents targeting the energy industry have been frequent. The attack chain not only spans the information domain (office networks, dispatch data networks, etc.) and control domain (SCADA, EMS, etc.), but also extends to the physical domain (relay protection devices, circuit breakers, etc.). Moreover, the attack path combines various methods such as exploiting known vulnerabilities, zero-day attacks, configuration defect exploitation, and social engineering attacks, forming a highly concealed and wide-ranging attack surface. In a highly sensitive industry like the power grid, the loss of any critical asset can trigger a chain reaction, leading to regional power outages or even large-scale power supply disruptions. Therefore, how to comprehensively, accurately, and dynamically characterize the power grid's attack surface, and on this basis, conduct quantifiable risk simulations and path assessments, has become a core issue in upgrading the power grid's cybersecurity protection system.

[0034] Traditional network asset management and security analysis tools often describe network assets and their relationships based on static scanning and manually maintained device lists. This approach has significant limitations: First, scanning frequency is limited, asset status updates are not timely, and it is difficult to reflect the addition, changes, or decommissioning of power grid assets in a timely manner. Second, scanning results mainly focus on the attributes of individual assets, while lacking systematic modeling of complex business dependencies, network policy relationships, and physical deployment relationships between assets. Third, existing risk assessments rely more on the severity of vulnerabilities (such as CVSS scores) for ranking, lacking quantitative measurement of the importance of assets in the power grid business system, thus failing to accurately reflect the true risk of vulnerabilities at the business level. Fourth, in terms of attack path deduction, existing solutions mostly rely on manual analysis or simple network reachability judgments, lacking an automated path search and minimization optimization mechanism based on multi-source heterogeneous data fusion and combined with risk weights.

[0035] Some energy sector entities have attempted to combine active scanning, passive traffic analysis, and host proxy data collection to construct asset lists and perform simple correlation analysis. While this approach can improve asset discovery coverage to some extent, it primarily remains at the level of static lists and basic topology diagrams. The data fusion granularity is coarse, failing to achieve timely incremental updates. In risk assessment, the generated risk rankings are disconnected from actual business risks. In attack path simulation, it can only perform simple hop count calculations based on IP reachability, unable to generate high-risk paths that reflect the actual operation of the power grid. Furthermore, these solutions typically lack efficient incremental reconstruction and version management mechanisms at the architectural level, leading to outdated and unreliable simulation results in environments like the power grid where assets change frequently.

[0036] In view of this, this application provides a risk estimation method for power grid assets. This method calculates the risk weight of nodes based on node information, and accurately quantifies the importance and operational risk of assets corresponding to different nodes through risk weight. This makes the estimation of target attack paths more consistent with the actual operation of the power grid, and improves the accuracy and reliability of the estimation results of target attack paths.

[0037] The risk estimation method for power grid assets provided in this application relates to the field of network security technology. This method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the risk estimation method for power grid assets, but is not limited to the above forms.

[0038] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0039] Figure 1 This is an optional flowchart of the risk extrapolation method for power grid assets provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S101 to S106.

[0040] Step S101: Obtain power grid asset data; Step S102: Construct a relationship graph based on the asset data to obtain an initial asset relationship graph; Step S103: Calculate the risk of different nodes based on the node information of the asset relationship graph to obtain a target asset relationship graph with risk weights. Step S104: Perform risk deduction on the target asset relationship graph based on risk weights to determine the target attack path.

[0041] Steps S101 to S106 as shown in the embodiments of this application calculate the risk weight of nodes based on node information. The risk weight accurately quantifies the importance of assets and operational risks corresponding to different nodes, making the deduction of target attack paths more consistent with the actual operation of the power grid and improving the technical feasibility and guiding significance of the deduction results.

[0042] In step S101 of some embodiments, the power grid asset data is multi-source heterogeneous data. Within the security boundary consistent with the power grid production network and sub-control areas, the unified deployment of three types of acquisition probes, unified initialization of the key and time system, a collaborative control closed loop of link load awareness and frequency adaptation, and trusted data aggregation for subsequent map construction are completed. The system achieves stable end-to-end operation with a four-domain structure of "dispatch control center—side-side acquisition node—secure transmission channel—aggregation and buffer cluster," thereby obtaining the power grid asset data. All acquisition and control messages are encrypted and transmitted using Transport Layer Security (TLS) mutual authentication (mTLS), and the time base is unified to millisecond-level alignment using Precision Time Protocol (PTP) or Network Time Protocol (NTP), improving the time consistency of multi-source observations.

[0043] The multi-source heterogeneous data in this application embodiment is not limited to traditional network detection data, but also includes operational information parsed from device management systems, log management platforms, configuration management databases (CMDBs), time-series databases, and various industrial control protocols (such as IEC 60870-5-104, Modbus / TCP, DL / T 634, etc.). This means that the data fusion layer needs to process structured, semi-structured, and unstructured data simultaneously, and have the ability to decode, extract, and normalize protocol features.

[0044] In some embodiments, step S101 may include, but is not limited to, steps S110 to S120: Step S110: Data is collected from different assets of the power grid to obtain active detection data, passive flow data, and host agent data; Step S120: Aggregate active probe data, passive traffic data, and host proxy data to obtain asset data.

[0045] In step S110 of some embodiments, the data collection side is divided into three categories: active probe nodes, passive traffic nodes, and host proxy nodes, which respectively cover three observation dimensions: reachability and port plane, north-south session and service fingerprint, and host process and local port, and collect active probe data, passive traffic data, and host proxy data respectively.

[0046] At the start of the deployment process, the scheduling and control center generates whitelists, blacklists, and graylists for addresses and assets in each region. The whitelist limits the network segments, ports, and protocol combinations that can be probed; the blacklist blocks objects known to be vulnerable or untouchable during specific windows of operation; and the graylist is used for temporary access via an approval process when business windows are open. The control center distributes configurations via the gRPC (gRPC Remote Procedure Call) framework and uses Public Key Infrastructure (PKI) to distribute device certificates and private keys to each probe. The certificates contain non-repudiable attributes of node roles, regions, and permissions. Each node immediately completes a TLS handshake and sends back a heartbeat upon startup. The heartbeat includes health indicators such as device clock skew, interface bandwidth, CPU (Central Processing Unit) and memory levels, serving as input for scheduling and adaptive algorithms. To prevent lateral movement abuse, all active probe tasks can only be issued by the scheduling and control center based on approved tickets. When the probe is executed, it must strictly follow the Access Control List (ACL) and Role-Based Access Control (RBAC), and the firewall policy at the gateway side will perform packet-level re-verification.

[0047] The active probing node employs a combination of Internet Control Message Protocol (ICMP) echo probes and Transmission Control Protocol (TCP) SYN half-open scans to achieve high coverage identification on both the linear and port planes. The ICMP module performs concurrent probing of whitelisted network segments by task fragmentation, recording round-trip latency, packet loss rate, and reachability. The TCP module initiates SYN probes on a specified set of ports. Upon receiving a SYN-ACK (synchronization confirmation) from the peer in the first step of the handshake, it confirms the port is open and actively sends an RST (reset) to terminate, avoiding the establishment of a complete connection and minimizing the impact on services. To avoid irrelevant traffic on the mirrored ports of the boundary protection device, the probe loads an extended Berkeley Packet Filter (eBPF) program on the kernel side, collecting only protocols and ports permitted by the policy and filtering broadcast and multicast background noise. The frequency of active probes is constrained by an adaptive coordination protocol: the token bucket controls the number of probes allowed per unit time using an average rate parameter *r* and a bucket capacity parameter *b*. The AIMD control loop linearly increases *r* in low-load areas and proportionally decreases *r* in high-load areas based on link utilization and latency thresholds, thus achieving closed-loop control of "idle scanning and yielding to busy traffic". All probe results (active probe data) are encapsulated in JavaScript Object Notation (JSON) format, carrying task ID, timestamp, source / destination address and port, handshake result, latency statistics, and acquisition window information, and are sent to the receiving service of the aggregation cluster via TLS encryption.

[0048] Passive traffic nodes are deployed on mirrored ports or bypass acquisition devices of the core switch, receiving north-south and east-west session copies using port mirroring. The node kernel continues to use eBPF to perform 5-tuple extraction and lightweight flow table aggregation. A 5-tuple consists of the source address, destination address, source port, destination port, and transport layer protocol. For the application layer, a parser identifies Hypertext Transfer Protocol (HTTP) response headers, server fingerprints, and certificate information, thereby confirming the service type and version without actively interacting with the business logic. To reduce the pressure on the master device from replicated traffic, the passive node enables large page buffering on the Network Interface Controller (NIC) side and combines Direct Memory Access (DMA) with a multi-core binding strategy, fixing the unpacking and parsing pipeline on a dedicated CPU core to avoid resource contention with production processes. The nodes write the merged stream digest, application fingerprint, and time-series statistics to the message queue in a segmented batch manner. The message queue can adopt a "distributed commit log" architecture (such as Apache Kafka, Chinese name "distributed stream processing and message queue"), and use partition keys to achieve the orderliness and traceability of the same session.

[0049] Host agent nodes are installed on approved critical assets. The agent process extracts host information such as the list of currently running processes, program signatures, listening ports, established connections, and local business tags through system calls and kernel interfaces. To reduce collection overhead, the agent uses a change-triggered reporting mechanism for high-frequency fields, generating differential messages only when processes or ports change. To enhance trustworthiness, the agent performs local data signing within a Trusted Execution Environment (TEE), binding immutable host identifiers and metrics to the signature to prevent tampered data from entering the aggregation surface. Communication between the agent and the control center also establishes a bidirectional trusted channel via mTLS, carrying the host clock offset in each reporting cycle to facilitate cross-source time alignment on the central side.

[0050] The adaptive probe coordination protocol uses the scheduling and control center as a "single source of fact," aggregating heartbeats and link metrics from each node to form a load status map for each network segment. The coordination engine of the control center operates on a loop cycle T: In each cycle, the coordination engine reads the link utilization, end-to-end latency, and median packet loss rate from the monitoring database to calculate the congestion level of the current interval; when the congestion level is in a low interval, the token issuance rate of the active probe task is increased by an additive step size, and a supplementary scan list is issued. The supplementary scan list prioritizes covering graylist objects that have not been reached for a long time and newly appeared unknown ports; when the congestion level is in a high interval or a critical business window is detected to be open, the coordination engine immediately decreases the token issuance rate by a multiplicative factor, while freezing all non-urgent active tasks, retaining only passive collection and approved micro-window scans. The message format of the coordination protocol is fixed and includes four types: "Heartbeat", "Metric", "Task" and "Receipt". All messages contain timestamps, sequence numbers and signatures. The task message requires the probe to send a receipt after execution. The receipt contains the execution window, completion percentage and exception summary. The scheduler uses the receipt to drive subsequent incremental scans or rollbacks.

[0051] In step S120 of some embodiments, trusted data aggregation relies on a three-stage access of the aggregation and buffering cluster: the ingress receiving service is responsible for TLS termination and certificate verification, basic message body verification and decompression, and then delivers the message to the memory queue; the standardization service applies the corresponding parser according to the source identifier and uniformly inputs the active, passive and proxy data into the model; the buffering and disk persistence service performs idempotent writing and time window alignment, merging multi-source observations of the same asset and the same port within the time window to generate an "asset-attribute observation snapshot" for subsequent graph construction, while attaching source proof and the earliest-latest observation time to each snapshot. To achieve high availability (HA), the aggregation cluster adopts primary-backup dual-active and cross-data center redundancy, key components have automatic failover, and the message queue is set with a reasonable retention period to withstand short-term upstream jitter.

[0052] The system architecture comprises a scheduling and control center, a policy and approval subsystem, an adaptive collaboration engine, a certificate and key management service, a time synchronization subsystem, active probing nodes, passive traffic nodes, host proxy nodes, an aggregation and buffer cluster, a message queue, and a monitoring and alarm platform. The scheduling and control center handles policy orchestration and task distribution; the approval subsystem manages work orders for scanning windows and gray lists; the adaptive collaboration engine integrates AIMD and token bucket control; the certificate and key management service provides PKI lifecycle management and revocation checks; the time synchronization subsystem ensures clock consistency across nodes via PTP / NTP; three types of acquisition nodes perform observation tasks across different dimensions; the aggregation and buffer cluster handles reception, standardization, and snapshot merging; the message queue is used for distributed decoupling and backpressure absorption; and the monitoring and alarm platform continuously monitors the availability and latency metrics of each component and triggers alarms. The devices are interconnected via encrypted links, forming a logical closed loop: policy—acquisition—aggregation—metrics—adaptation—redistribution.

[0053] In some embodiments, please refer to Figure 2The process begins with "Start" and enters the "System Initialization" phase, which includes certificate distribution, time synchronization, whitelist and blacklist activation, and probe node registration and heartbeat reporting. It then enters the "Link Status Acquisition" phase, where the scheduling and control center receives link utilization, end-to-end latency, and packet loss metrics from each probe within period T and establishes the current congestion level in the monitoring database. The process then proceeds to "Congestion Level Determination." When the congestion level is low, "Issuance of Scan Tokens and Generation of Scan List" is executed. The scan list prioritizes and covers long-unreached objects and newly added suspicious ports, while simultaneously distributing it to the active probe nodes. The active probe nodes then "Perform ICMP / TCP SYN Probing," collecting reachability, open port, and latency information and transmitting it back with encrypted messages. When the congestion level is high or a critical window is open, the process switches to "Frequency Reduction and Freezing of Non-Emergency Tasks," reducing the token issuance rate multiplicatively, retaining only necessary probes. Simultaneously, passive traffic nodes continuously engage in "Mirror Stream Acquisition and Fingerprint Parsing," outputting five-tuple summaries and application fingerprints in real time. The host agent node is in the "host state change capture and difference reporting" state, generating and sending difference messages when processes or ports change. Three data streams simultaneously enter the "aggregation and standardization" stage, with the entry reception, standardization, and buffer disk write processes executed sequentially to ultimately form an "asset-attribute observation snapshot" (asset data). This is followed by "closed-loop feedback," where the scheduling and control center updates the congestion level and adjusts the token issuance strategy for the next cycle based on the new snapshot and link metrics. If the system detects an anomaly, such as certificate verification failure or clock drift exceeding the threshold, the process enters "anomaly handling and rollback," performing node isolation, certificate revocation, or time resynchronization until normal operation is restored, returning to "link status acquisition." The process reaches "end" when the planned task batch is completed and there are no outstanding scan items, and returns to "link status acquisition" when cycle T arrives, forming a continuous loop.

[0054] To ensure compatibility with power grid production constraints, this embodiment enforces rate limiting and Quality of Service (QoS) priority marking for east-west and north-south probe packets at the network policy level, reducing interleaving with protection and control flows. At the profiler level, all active probes are limited to a whitelist set, preventing probes to unknown addresses and ports. At the operations and maintenance level, the approval subsystem records the application, approval, execution, and receipt of each active task, ensuring process compliance and traceability. At the fault handling level, any disconnection or abnormal report from any data acquisition node triggers an event generated by the monitoring alarm platform, which then performs isolation, restart, or rollback based on the event level. After completing the linkage of the above devices and processes, the system obtains a highly complete, time-aligned, and verifiable "asset-attribute observation snapshot" (asset data) required for subsequent graph construction, and operates in a low-disturbance manner for an extended period, providing a stable data foundation for subsequent multimodal asset normalization and relationship graph construction.

[0055] In step S102 of some embodiments, after the upstream interface of the data aggregation and buffer cluster is running stably, the unified ontology and schema-driven asset normalization and relation graph construction pipeline is started. The system operates in a closed-loop seven-stage pipeline: "Ontology Registry—Normalization Service—Entity Parsing Engine—Relationship Extractor—Topology Associate—Graph Builder—Version and Increment Manager," producing a dynamic directed attribute graph (initial asset relation graph) that can be used for subsequent risk calculation and path deduction. The system stably maps multi-source heterogeneous observations to unified asset ID-attribute key-value pairs and constructs a dynamic directed relation graph. At the same time, it reduces the high cost of full reconstruction by capturing change data and partial reconstruction, providing an accurate, timely, and traceable graph data foundation for subsequent risk weight calculation.

[0056] In some embodiments, step S102 may include, but is not limited to, steps S201 to S203: Step S201: Analyze and fuse the multi-source data of the asset data to obtain the asset entity; Step S202: Extract relationships from asset data based on asset entities and generate directed edges representing the relationships between asset entities; Step S203: Construct a graph based on the asset entities and directed edges to obtain an initial asset relationship graph.

[0057] In some embodiments, before executing steps S201 to S203, the system publishes a unified data model for power grid assets in the ontology registry center, and determines the composition and generation rules of the asset identifier AssetID. AssetID consists of a three-part namespace: "Region - Domain - NaturalKey". The Region binds to the geographical and operational area, the Domain indicates its affiliation in the information domain, control domain, and physical domain, and the NaturalKey is generated using a deterministic hash of "Management Plane MAC (Media Access Control) + First Discovery Timestamp". The model defines a standard naming and unit system for attribute key-value pairs, such as "ip.v4", "port.tcp", "svc.http.server", "role.bus.tag", "geo.room", "fw.acl.rule", etc., and specifies the data type, value range, and conflict merging strategy for the attributes. The model defines both edge types and directions, including service dependency edges (DEPEND_ON, upstream → downstream), network policy edges (ALLOWED_BY_POLICY, policy source → policy target), physical co-location edges (CO_LOCATED, device A ←→ device B), link topology edges (L2_LINK, switch port → host port), and session observation edges (OBSERVED_FLOW, client → server). Each type of edge includes three mandatory attributes: occurrence time window, acceptance level, and source proof.

[0058] Subsequently, multi-source data normalization mapping is performed. This involves retrieving original records from three sources (multi-source data for asset data) from the message queue via a normalization service, and performing a four-stage mapping process: field validation, unit conversion, encoding normalization, and time window alignment. ICMP / TCP probe results (active probe data) are entered into the communication attribute mapper and unified as ip.v4, port.tcp, proto.l4, and latency.rtt.ms. Passive traffic fingerprints (passive traffic data) are transcribed into service attributes such as svc.http.server, svc.http.version, tls.cert.subject, and tls.cert.not_after by the application protocol parser. Host proxy records (host proxy data) are mapped into business and physical attributes such as proc.name, proc.hash.sha256, listen.port, role.bus.tag, and geo.site / room / rack by the host acquisition adapter. The normalization service enforces uniformity in character sets and locale settings. All text uses a unified encoding format (UnicodeUTF-8), and all timestamps are represented using Coordinated Universal Time (UTC) with millisecond precision. For missing fields, the normalization service does not make inferences but maintains an explicit null value with a missing reason code, ensuring interpretability in subsequent entity parsing.

[0059] In step S201 of some embodiments, the multi-source data of asset data may include probe data, passive traffic data, and host proxy data. Since data from different sources may describe the same asset, the entity parsing engine performs a three-stage process of deterministic matching, probabilistic merging, and confidence update for the multi-source observations of the same asset. Deterministic matching uses a strong key set consisting of AssetID natural key, mac.addr, ip.v4, and tls.cert.fingerprint for equivalence matching. Probabilistic merging uses Gradient Boosting Decision Tree (GBDT) to score weak key features (such as hostname, svc.banner, geo.room, and role.bus.tag similarity). If the score exceeds a threshold, the assets are immediately merged into a single entity (asset entity). The merging process maintains confidence levels across two dimensions: source authority and attribute freshness. Source authority is weighted according to the order of "host proxy > passive fingerprint > active detection," while attribute freshness decreases with the most recent observation time. Finally, when resolving conflicts, the value with the highest "authority * freshness" is written to the entity view, and all candidate values ​​are written to a multi-version column family for traceability. The entity resolution engine generates a non-repudiable merging log after each merge, and this log is written to the traceability repository for compliance auditing.

[0060] In step S202 of some embodiments, directed edges are generated from normalized records (asset data after normalization service) by a relation extractor, and the directed edges include various types.

[0061] Business dependency edges originate from the connection matrix and access path: When passive traffic is consistently observed to access the server svc.mysql or svc.http via the client process proc.name within a fixed time window, the relation extractor establishes business dependency edges (DEPEND_ON edges) based on the five-tuple (source address, destination address, source port, destination port, protocol) and attaches statistical attributes such as "request count, failure rate, average latency". Network policy edges are parsed from firewall access control lists (ACLs) and role-based access control (RBAC) configurations. The parser forms a normalized six-tuple of "source set - destination set - service set - action - priority - effective time" for policy entries, and generates ALLOWED_BY_POLICY edges (network policy edges) for the matched entity pairs. The physical co-location edge is composed of the Link Layer Discovery Protocol (LLDP) and the Configuration Management Database (CMDB). When the geo.room / rack of the two entities are completely identical, a CO_LOCATED edge (physical co-location edge) is established. At the same time, a secondary verification is performed using the Forwarding Database (FDB) and the Address Resolution Protocol (ARP) table. The link topology edge (L2_LINK) is directly generated from LLDP neighbor information and switch port information; The session observation edge (OBSERVED_FLOW) is generated from the session aggregation of passive traffic and has the attributes of "time window, number of sessions, and cumulative bytes".

[0062] All directed edges are generated with two attributes attached: proof of source (prov.source) and generation algorithm version, thus achieving traceability and reproducibility.

[0063] In step S203 of some embodiments, the graph builder writes asset entities and directed edges to the graph database. The system uses an attribute-oriented graph data store (such as Neo4j) for online read and write operations and uses a wide-column store (Apache HBase, a distributed wide-column database) to persist time-versioned column families. The graph builder performs a two-level indexing during writes: a first-level inverted index of AssetID and key attributes, and a second-level "source-type-destination" composite index of edges, to ensure efficient path calculation and local reconstruction. To improve transactional consistency during writes, the builder uses a serializable isolation level for batch commits, automatically rolling back to the previous consistent snapshot version (snapshot.version) if any batch fails.

[0064] In some embodiments, after performing steps S201 to S203, when an asset change occurs, a partial reconstruction of the event-driven graph based on Change Data Capture (CDC) is performed by the version and incremental manager.

[0065] The system calculates the affected subgraph boundary set B(v) for each CDC event: when the attribute of an asset node v changes, the incremental manager uses the first-order neighborhood of OBSERVED_FLOW and DEPEND_ON as the boundary set; when the network policy or physical location changes, the boundary set is expanded to the second-order neighborhood and a set of nodes related to the policy hit is introduced.

[0066] The local reconstruction process comprises four defined steps: "undoing expired edges—recalculating extraction rules—reconstructing affected edges—updating the index," without scanning the entire graph. The incremental manager simultaneously maintains a triplet of "effective time window—version number—proof of origin," allowing for backtracking of the graph state at any point in time. For nodes with frequent changes, the system initiates a batching window, merging multiple minor changes into a single atomic commit within the window period, reducing write amplification and lock contention.

[0067] In some embodiments, a Quality Gate performs four types of checks on the upcoming snapshot (initial asset relationship graph): integrity, uniqueness, constraint consistency, and cross-source consistency. Integrity checks ensure that each entity possesses at least one communication attribute and one proof of origin; uniqueness checks ensure that the same natural key appears at most once as a valid entity within the same time window; constraint consistency verifies the "essential attributes, edge directions, and type compatibility matrix" within the model; cross-source consistency cross-validates "actively probed open ports" and "passively observed session ports," lowering the acceptance level of the port and dispatching a review task when contradictions are found. The Quality Gate rejects unqualified batches for release and returns the reasons for failure to the normalization service and entity parsing engine for targeted repair.

[0068] In some embodiments, a consumable snapshot (initial asset relationship graph) is generated and published to a read-only interface. The consumable snapshot consists of six parts: a set of nodes, a set of edges, a global version number, a time window, source coverage, and a quality score. The interface service provides three types of access: a tabular view based on Structured Query Language (SQL), a graph view based on Cypher Query Language, and an Application Programming Interface (API) based on Representational State Transfer (REST). The risk calculation and path deduction service triggers a self-check immediately upon obtaining the new version number, and proceeds to the next stage of calculation after confirming that the dependency edge types and attributes are complete.

[0069] In some embodiments, regarding the system device structure, the device in this embodiment comprises an ontology registry center, a normalization service cluster, an entity parsing engine cluster, a relation extractor, a network policy parser, an LLDP / ARP / FDB collector, a topology associate, a graph builder, a graph database cluster, a wide-column version control repository, a version and increment manager, a quality gate, and a read-only interface service. Devices are interconnected via encrypted links; all write paths pass through the version and increment manager to improve graph consistency; all read paths pass through the read-only interface service to protect online write transactions. The device's operating status and latency metrics are continuously collected by a monitoring platform, and anomalies trigger automated recovery and bypass degradation strategies to improve the availability of critical production windows.

[0070] In some embodiments, please refer to Figure 3The process begins with "Start" and proceeds to "Pull Multi-Source Data and Align Time Windows." The normalization service retrieves three types of records—active, passive, and proxy—from the message queue in batches, performs field validation, unit conversion, and unified encoding, and then outputs normalized records. The process then moves to "Entity Parsing and Deduplication Fusion." The entity parsing engine merges multiple observations into a single asset entity based on strong key equivalence matching and weak key similarity scoring, and writes it to the fusion log. Next, the process moves to "Relation Extraction and Semantic Annotation." The relation extractor generates edges such as DEPEND_ON, ALLOWED_BY_POLICY, CO_LOCATED, L2_LINK, and OBSERVED_FLOW based on session statistics, policy configuration, and physical inventory, and attaches source proofs and generation algorithm versions. Finally, the process moves to "Graph Construction and Index Writing." The graph builder... The process materializes nodes and edges into the graph database using a batch transaction commit method, and updates the inverted index and composite index. When the process reaches the decision node for "whether there is a CDC change event", if it exists, it proceeds to "calculate the boundaries of the affected subgraph and perform local reconstruction", cancels expired edges, recalculates extraction rules, rebuilds the index, and then returns to "graph construction and index writing". If there is no change or the reconstruction is complete, the process proceeds to "quality gate verification". If the verification fails, it returns to the corresponding "normalization / parsing / extraction" stage for repair and restarts the process. When the quality gate passes, the process proceeds to "generate a consumable snapshot and publish the interface", publishes the SQL view, Cypher view, and REST interface, and records the global version number and time window. The process finally reaches "end (graph version publication completed)" and waits for the next batch of data-driven incremental processing.

[0071] Through the above steps, multi-source heterogeneous observations are mapped into unified asset ID-attribute key-value pairs and a dynamic directed relation graph is constructed. At the same time, change data capture and partial reconstruction avoid the high cost of full reconstruction, providing an accurate, timely and traceable graph data foundation for subsequent risk weight calculation.

[0072] In step S103 of some embodiments, based on the dynamic directed asset relationship graph (initial asset relationship graph) described in the preceding embodiments, the service attributes, version information, business tags, and associated network policy relationships (node ​​information) carried by the nodes are used, combined with an external authoritative vulnerability information database and a power grid business importance model, to perform quantitative risk weight calculation for each asset node. The calculation results are then written back to the graph database in real time to support subsequent attack path deduction and protection priority ranking. The entire process is completed collaboratively by the vulnerability matching and scoring module, the business impact factor calculation module, the comprehensive weight generator, and the weight write-back and version manager. It runs in a risk calculation service cluster with high availability and high concurrency processing capabilities. All data exchanges are conducted through a two-way authentication channel of Transport Layer Security (TLS) protocol, improving the security of the link and the trustworthiness of the identity.

[0073] In some embodiments, step S103 may include, but is not limited to, steps S301 to S304: Step S301: Based on the pre-stored vulnerability records, perform vulnerability matching on the attributes of each node in the target asset relationship graph to obtain the vulnerabilities associated with the nodes. Step S302: Analyze the vulnerability based on its metrics to obtain the node's base score. Step S303: Determine the business impact factor of the node based on its business attributes; Step S304: Calculate the risk weights based on the base scores and business impact factors to determine the risk weights of each node, thereby obtaining the target asset relationship map.

[0074] In step S301 of some embodiments, before vulnerability matching, the vulnerability matching and scoring module synchronizes the latest vulnerability records from multiple vulnerability data sources, including multiple authoritative vulnerability databases or platforms and security announcements from various device or software vendors, according to a preset period or when a triggering event occurs. The synchronization process is performed via Secure File Transfer Protocol (SFTP) or Hypertext Transfer Protocol Secure (HTTPS), and the retrieved files or data streams are subjected to SHA-256 hash verification to confirm their integrity.

[0075] After synchronization, the system matches the affected product identifier, version number, build number, fingerprint hash, and other information provided in the vulnerability record with service attributes such as svc.http.server, svc.mysql.version, and os.kernel.version in the graph nodes. The matching strategy includes exact matching for complete equality, range matching to parse semantic version ranges, and fuzzy fingerprint matching when a complete version number is missing but a specific characteristic hash exists, thereby maximizing the discovery of potential vulnerability associations between nodes.

[0076] In step S302 of some embodiments, after a match is established, the system parses the Common Vulnerability Scoring System (CVSS) vector string contained in the vulnerability record, extracting indicators such as attack vector, attack complexity, required permissions, user interaction, and impact on confidentiality, integrity, and availability, and calculates a base score according to the standard formula of CVSS v3.1. If the vulnerability database lacks a CVSS vector, the scoring module calls the local scoring engine to derive an equivalent base score based on the vulnerability description and exploit details, and simultaneously marks the source information of this score to distinguish between manual evaluation and automatic calculation results. This base score can objectively reflect the technical severity of the vulnerability itself.

[0077] In step S303 of some embodiments, to reflect the differences in importance of different assets in power grid production, the business impact factor calculation module searches a predefined power grid business hierarchy mapping table based on the node's role.bus.tag attribute. This mapping table divides assets into three levels: the core control layer, the important support layer, and the general business layer. The core control layer includes equipment and systems directly involved in scheduling and control, such as SCADA (Supervisory Control And Data Acquisition), EMS (Energy Management System), and DMS (Distribution Management System). The important support layer includes key support platforms such as the scheduling data center database and the Meter Data Management System (MDMS). The general business layer covers non-core businesses such as office automation systems and general monitoring terminals. Each level corresponds to a fixed weight coefficient; for example, the core control layer might have a weight of 3.0, the important support layer 2.0, and the general business layer 1.0. When an asset has multiple business tags, the system takes the coefficient corresponding to the highest priority as the business impact factor for that node.

[0078] The business impact factors described in this application are implemented through hierarchical modeling of the power grid business system, and this hierarchical model is scalable. Different power grid companies or at different times may adjust the definition of business levels. For example, in an emergency, some systems that were originally in the support layer may be temporarily elevated to the core control layer. The implementation method of this embodiment allows the business impact factor mapping table to be dynamically updated at runtime and automatically take effect in the next round of risk weight calculation, thereby ensuring that the risk assessment results always match the current business priorities.

[0079] In step S304 of some embodiments, the comprehensive weight generator multiplies the CVSS base score with the business impact factor to obtain the comprehensive risk weight Rasset of the asset node, Rasset=BaseScore×WbusinessR_{\text{asset}}, where BaseScore represents the base score and WbusinessR_{\text{asset}} represents the business impact factor.

[0080] If an asset is associated with multiple vulnerabilities, the maximum value among all vulnerability calculation results is taken as the final risk weight for that node to prevent low-risk vulnerabilities from diluting the impact of high-risk vulnerabilities. The comprehensive weight calculation result includes not only the score itself, but also a timestamp, a list of involved vulnerability IDs, the source of the score, and the source of the business tag, making the results traceable and auditable.

[0081] In some embodiments, to facilitate rapid screening in subsequent attack path deduction and protection strategy formulation, the system sets classification thresholds based on risk weights, categorizing assets into four types: high-risk, medium-high-risk, medium-risk, and low-risk. The classification results are written to the node's `risk.level` attribute, and a secondary index for risk levels is created in the graph database. All calculation results and classification information are batch-written to the graph database via weight write-back and version manager, and stored in the `risk.version` column family of wide-column storage to save version history, thereby supporting historical trend analysis and time-based risk status retrospection.

[0082] Risk weight calculations are not only performed at fixed intervals, but are also triggered immediately by a series of conditions, such as new records appearing in the vulnerability database and affecting current assets, changes in the business tags of nodes leading to adjustments in business impact factors, or updates to the service version information of nodes. The change trigger controller detects these events through the Change Data Capture (CDC) mechanism of the graph database and sends notifications to the risk calculation service cluster via message queues, driving a full or incremental rerun of the above calculation process, ensuring that the risk assessment results always reflect the latest status.

[0083] Throughout the process, the system architecture revolves around a risk calculation service cluster, which deploys a vulnerability matching and scoring module, a business impact factor calculation module, a comprehensive weight generator, a weight write-back and version manager, and a change trigger controller. It is interconnected with the graph database, wide-column version store, and message queue via a secure intranet, and all interfaces require TLS mutual authentication to prevent unauthorized access.

[0084] In some embodiments, please refer to Figure 4 The process begins with "Start" and proceeds to "Vulnerability Information Database Synchronization," where external vulnerability data is retrieved and its integrity verified. Next, it moves to "Asset Service and Vulnerability Matching," comparing various matching strategies based on service attributes and vulnerability records. Once a vulnerability is matched, it proceeds to "Analyze CVSS Basic Score," calculating or evaluating the vulnerability's base score. Then, it proceeds to "Calculate Business Impact Factor," obtaining coefficients based on business tags. Next, it proceeds to "Comprehensive Risk Weight Calculation," generating the final score and taking the maximum value from multiple vulnerability results. Finally, it proceeds to "Risk Level Classification," classifying levels based on thresholds. Then, in the "Weight Write-back and Version Storage" stage, the scores and levels are batch-written into the graph database and version storage. The process checks for trigger events; if present, it returns to the matching steps and re-executes; otherwise, it proceeds to "End," awaiting the next round of periodic calculations or event triggers.

[0085] Step S103 described in the preceding embodiments not only completes the quantitative mapping from the severity of the vulnerability technology to the actual business risk, but also improves the traceability and real-time update capability of the results, providing directly usable risk weight data with business semantics for subsequent attack path deduction.

[0086] In step S104 of some embodiments, the dynamic directed asset relationship graph with comprehensive risk weight attributes completed in step S103 generates technically feasible and business-high-risk minimum attack paths (target attack paths) through a graph database-driven path search and evaluation algorithm. These minimal attack paths are then output in a visualized and structured format, providing the operations and protection departments with a basis for targeted hardening priorities. This process consists of an attack path deduction engine, a path search and optimization module, a risk accumulation calculator, a visualization generator, and result storage and interface services. During runtime, the entire calculation process is subject to transactional control, ensuring consistency between the path deduction results and the graph version. Furthermore, each deduction has clear source proof and parameter records, meeting audit and traceability requirements.

[0087] In some embodiments, step S104 may include, but is not limited to, steps S401 to S402: Step S401: Perform attack simulation on the target asset relationship graph to obtain several potential attack paths for attacking power grid assets; Step S402: Calculate the risk of potential attack paths based on risk weights to determine the target attack path.

[0088] In steps S401 to S402 of some embodiments, based on the target asset relationship graph and after determining the starting node and target node, possible attack chains (potential attack paths) are enumerated between the starting node and target node using a directed graph traversal. Each potential attack path is technically feasible, meaning that each jump between nodes has corresponding exploitable conditions. Each node in the target asset relationship graph is assigned a risk weight. Therefore, based on the risk weights of nodes on potential attack paths, the potential attack path with the highest risk is selected as the target attack path. This allows for the selection of the route most likely to be chosen by the attacker from feasible paths, providing a directly usable decision-making basis for defense deployment and emergency response.

[0089] In some embodiments, step S401 may include, but is not limited to, steps S411 to S413: Step S411: Determine the target asset nodes in the target asset relationship graph; Step S412: Identify the attack entry points in the target asset relationship graph and determine the set of nodes at the attack entry points; Step S413: Perform path traversal based on the target asset node and node set to obtain several potential attack paths.

[0090] In steps S411 to S413 of some embodiments, the endpoint of the deduction process is that the operation and maintenance or security policy engine identifies one or more target asset nodes at the interface layer, such as a "meter centralized control server" or a "substation SCADA master control unit". The attack path deduction engine first reads the current version of the asset relationship graph from the graph database. This graph contains the comprehensive risk weight, risk level, business label of the nodes, and the type, direction, and attributes of all associated edges. The engine uses all nodes that can serve as attack entry points as the starting point set. These entry point nodes typically include servers exposed to the public network, maintenance interface devices that can be remotely accessed, and assets with historically confirmed exploitable vulnerabilities. Between the starting point set and the target nodes, the engine enumerates possible attack chains in a directed graph traversal manner.

[0091] In some embodiments, step S402 may include, but is not limited to, steps S421 to S423: Step S421: Adjust the risk weights according to the business impact coefficients of the nodes to obtain the corrected risk weights; Step S422: Accumulate the risk of each node according to the corrected risk weight to obtain the risk value of the potential attack path; Step S423: The potential attack path with the highest risk value is identified as the target attack path.

[0092] In steps S421 to S423 of some embodiments, in order to filter out the route most likely to be chosen by the attacker from potential attack paths, the path search and optimization module uses a weighted shortest path algorithm for calculation. Common methods include Dijkstra's algorithm and A* heuristic search, where the edge weight is calculated by combining the risk weight of the source node, the risk weight of the target node, and the availability attribute of the edge itself. For example, in a candidate path from the starting point to the ending point, the system calculates a "jump risk cost" for each hop, which combines the risk score of the source node, the edge access policy (e.g., ALLOWED_BY_POLICY indicates policy permission), session stability (session persistence statistics based on passive traffic observation), and the preconditions required for the jump (e.g., crossing firewalls, bypassing authentication, etc.). The optimization objective of path search is to minimize the total risk value of the path while ensuring that the path is technically reachable, i.e., each hop has corresponding availability conditions satisfied.

[0093] During the traversal, the risk accumulation calculator accumulates risk scores according to the risk weights of path nodes and combines this with a business impact coefficient to amplify or reduce the overall risk. This business impact coefficient can be the business impact factor described in the previous embodiments. For example, if an intermediate node of a path is directly associated with a primary business system (such as SCADA or EMS), the risk score of that node will be multiplied by an additional weighting coefficient during accumulation, making paths containing this node more likely to be marked as high-priority targets. Furthermore, the total number of vulnerability exploits, the number of times network policy edges are crossed, and the number of times physical location changes occur in real time during the risk accumulation process, for subsequent visualization and annotation.

[0094] The weight allocation strategy in this embodiment is not fixed to a specific algorithm, but allows for dynamic switching of weight definitions during path search. For example, in a simulation oriented towards business continuity risk analysis, the weight of business impact factors can be increased, while in a simulation oriented towards technical penetration defense exercises, the severity of the vulnerability technology can be used as the primary weight. This flexibility not only improves the adaptability of the simulation results to different application scenarios, but also provides multi-dimensional references for subsequent protection strategy formulation.

[0095] Once all feasible paths from the starting point to the destination have been traversed, the path search and optimization module selects one or more minimum attack paths that meet the minimum objective, or outputs the top N paths with the highest risk values, i.e., the target attack paths, based on the policy requirements. The inference engine then passes these paths to the visualization generator, which constructs a highly readable attack chain graph based on the node and edge metadata of the graph database. This graph includes the identifier, risk score and level, vulnerability details, and business tag for each node, as well as the type, direction, exploitation conditions, and time window information for each edge. These visualizations can be generated as static images (such as SVG or PNG format) for report archiving, or as interactive front-end displays for analysts to dynamically view path details.

[0096] The generated path derivation results, along with all computational parameters, the definitions of the start and end point sets, the graph version number, and the execution timestamp, are written to the result storage and provided with standardized access through an interface service. The interface service supports API calls based on the Representational State Transfer (REST) ​​style, as well as direct queries based on the Cypher Query Language, facilitating subsequent integration with automated protection strategy systems or Security Information and Event Management (SIEM) systems.

[0097] The version management and incremental update mechanism of this application embodiment is particularly important in an environment where power grid assets change rapidly. All maps, risk weights, and simulation results are bound to version numbers and time windows, supporting horizontal comparison (differences between different versions at the same time) and vertical tracing (the change trajectory of a single asset or path over time). This capability enables this embodiment not only to be used for real-time protection decision-making but also to serve as a core data source for post-event security forensics and attack-defense drill evaluation.

[0098] In some embodiments, the system architecture includes an attack path inference engine, a path search and optimization module, a risk accumulation calculator, a visualization generator, result storage, and interface services. The inference engine coordinates the entire computation process, the path search and optimization module is responsible for algorithm execution and pruning strategies, the risk accumulation calculator calculates the total risk of the path during traversal, the visualization generator outputs the result graph, the result storage persists the results and maintains the index in the form of a graph database or relational database, and the interface services provide access capabilities to external systems.

[0099] In some embodiments, please refer to Figure 5The process begins with "Start" and proceeds to "Read Current Graph Version and Target Assets," where the simulation engine loads the current asset relationship graph and target node set. It then proceeds to "Identify Attack Entry Nodes," filtering all potential intrusion starting nodes from the graph. Next, it enters "Execute Path Search," where the path search and optimization module uses a weighted shortest path algorithm to traverse all feasible paths from the starting point to the endpoint. During this traversal, it enters "Calculate Path Accumulated Risk," where a risk accumulation calculator accumulates risk for each node and edge and adjusts the business impact coefficient. After traversal, it enters "Filter Minimum Attack Paths," selecting a result set based on the total path risk value and technical feasibility. The result set then enters "Generate Visual Attack Chain," where a visualization generator constructs a graphical representation of nodes and edges. Following this, it enters "Storage and Interface Release," writing the results and calculation parameters to the result storage and providing them externally through the interface service. Finally, the process enters "End (Simulation Completed)," awaiting the next simulation request or graph update to trigger a new round of simulation.

[0100] By executing step S104 as described in the preceding embodiments, not only can the minimum attack path be automatically derived in a complex multi-source heterogeneous power grid asset network, but the comprehensive risk of each path can also be quantified. This makes the simulation results both technically feasible and provide guidance on business priorities, thereby providing a direct and usable decision-making basis for defense deployment and emergency response.

[0101] The embodiments of this application have significant advantages in terms of real-time performance, accuracy, and business relevance of risk assessment in power grid asset attack surface modeling. Through a unified asset identification system, multi-source data alignment with millisecond-level time windows, and incremental update algorithms, the continuous dynamic reflection of asset status is achieved. Furthermore, the graph construction comprehensively covers multiple types of directed edges, including business dependencies, network policies, and physical co-location, making the modeling results closer to the actual topology and business logic of the power grid.

[0102] In the risk assessment and path deduction phase, this embodiment introduces a comprehensive risk weighting model that combines the severity of the vulnerability technology with the impact factors of power grid business. This ensures that risk ranking not only considers the technical feasibility of vulnerability exploitation but also accurately reflects its potential threat to critical business links. Simultaneously, a weighted minimum path search algorithm is used to generate attack chains that conform to both the characteristics of attack technology paths and reflect the priority of business harm. Version management ensures that the results are traceable and reproducible. This embodiment can continuously output high-value, business-guiding risk and path analysis results in a rapidly changing power grid environment, thereby significantly improving the scientific rigor and timeliness of protection decisions.

[0103] In some embodiments, the collection of multi-source heterogeneous data is simplified to passive analysis relying entirely on traffic mirroring, without deploying active probing and host proxy nodes. Asset attributes and relationships are inferred through deep packet inspection and traffic statistics. This approach reduces active interference with the network.

[0104] In some embodiments, a centralized, periodic full-scale scan and asset inventory method is used, combined with a Configuration Management Database (CMDB) and change records, to update the asset relationship graph. In this scheme, the graph update frequency depends on the scan and data synchronization cycle, making it simpler to implement.

[0105] In some embodiments, based directly on security event logs generated by the Intrusion Detection System (IDS) and Intrusion Prevention System (IPS), event correlation analysis is performed through a Security Information and Event Management (SIEM) platform to infer possible attack paths. This method can generate partial attack chain predictions without requiring comprehensive modeling of all network assets.

[0106] The embodiments of this application have at least the following beneficial effects: By coordinating the operation of three types of data collection nodes—active detection, passive traffic collection, and host agent monitoring—and implementing adaptive network bandwidth control under a unified clock and strategy in the scheduling and control center, asset information can be aligned and reliably fused from multiple sources within a millisecond time window, thereby improving the completeness and real-time performance of the asset view.

[0107] The design incorporates a three-segment asset identifier (region – domain – natural key) and a standardized attribute key-value system. This system normalizes and maps actively detected communication attributes, passively collected business fingerprints, and host proxy business and physical attributes. Furthermore, the entity parsing engine enables precise matching of strong keys and probabilistic merging of weak keys, resulting in traceable, high-confidence asset entities.

[0108] Based on the results of multi-source fusion, directed edges of various types, such as service dependencies, network policies, physical co-location, link topology, and session observations, are automatically generated, along with source proofs and time window information. An incremental update algorithm is used to perform local reconstruction only on the affected subgraphs, so that the graph structure continuously reflects the real network state.

[0109] The comprehensive risk formula, which combines the base score of the Common Vulnerability Scoring System (CVSS) with the power grid business impact factor, achieves unified quantification of technical severity and business harm, and maintains real-time updates of risk weights through a combination of event-driven and periodic calculations.

[0110] In the dynamic asset relationship graph, the comprehensive risk weight is used as the weight index of nodes and edges. The Dijkstra or A* algorithm is used to generate the minimum attack path that meets the requirements of technical accessibility and business high risk, and supports the sorting and filtering of multiple high-risk paths.

[0111] The asset graph, risk weights, and attack path results are stored in a versioned manner. Each version is bound to a time window, data source, and calculation parameters, making the results reproducible, auditable, and supporting historical trend analysis.

[0112] By providing external access capabilities through APIs based on the Representational State Transmission (REST) ​​style and the graph query language Cypher, it supports seamless integration with Security Information and Event Management Systems (SIEM) and automated protection strategy platforms, enabling closed-loop linkage from data collection and risk assessment to protection execution.

[0113] This application embodiment also provides a risk simulation device for power grid assets, which can implement the above method. The device includes: The acquisition module is used to acquire power grid asset data; The construction module is used to build a relationship graph based on asset data to obtain an initial asset relationship graph; The calculation module is used to perform risk calculations on different nodes based on the node information of the asset relationship graph, and obtain the target asset relationship graph with risk weights. The deduction module is used to perform risk deduction on the target asset relationship graph based on risk weights to determine the target attack path.

[0114] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0115] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0116] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0117] Please see Figure 6 , Figure 6 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 902 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 902 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901 using the methods described in the embodiments of this application. The input / output interface 903 is used to implement information input and output; The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 904); The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0118] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0119] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0120] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0121] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0122] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0123] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0124] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0125] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0126] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0127] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0128] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for risk estimation of power grid assets, characterized in that, The method includes the following steps: Obtain power grid asset data; Based on the asset data, a relationship graph is constructed to obtain an initial asset relationship graph; Risk calculations are performed on different nodes based on the node information of the asset relationship graph to obtain a target asset relationship graph with risk weights; Based on the risk weights, risk deduction is performed on the target asset relationship graph to determine the target attack path.

2. The method according to claim 1, characterized in that, The acquisition of power grid asset data includes: Data is collected from different assets of the power grid to obtain active detection data, passive flow data, and host agent data. The asset data is obtained by aggregating the active detection data, the passive traffic data, and the host proxy data.

3. The method according to claim 1, characterized in that, The step of constructing a relationship graph based on the asset data to obtain an initial asset relationship graph includes: The asset data from multiple sources is parsed and fused to obtain the asset entity; Based on the asset entities, the relationship is extracted from the asset data to generate directed edges representing the relationships between the asset entities; Based on the asset entities and the directed edges, a graph is constructed to obtain an initial asset relationship graph.

4. The method according to claim 1, characterized in that, The step of calculating the risk of different nodes based on the node information of the asset relationship graph to obtain a target asset relationship graph with risk weight attributes includes: Based on the pre-stored vulnerability records, the attributes of each node in the target asset relationship graph are matched for vulnerabilities to obtain the vulnerabilities associated with the node. Vulnerability scoring is performed based on the vulnerabilities' metrics to obtain the node's base score; Determine the business impact factor of the node based on its business attributes; Risk weights are calculated based on the base score and the business impact factor to determine the risk weight of each node, thereby obtaining the target asset relationship map.

5. The method according to claim 1, characterized in that, The step of performing risk extrapolation on the target asset relationship graph based on the risk weights to determine the target attack path includes: By performing attack simulations on the target asset relationship graph, several potential attack paths for attacking power grid assets are obtained. The potential attack paths are calculated based on the risk weights to determine the target attack path.

6. The method according to claim 5, characterized in that, The risk deduction based on the target asset relationship graph yields several potential attack paths for attacks on power grid assets, including: Determine the target asset nodes in the target asset relationship graph; The target asset relationship graph is used to identify attack entry points and determine the set of nodes at the attack entry points; Based on the target asset node and the node set, a path traversal is performed to obtain several potential attack paths.

7. The method according to claim 5, characterized in that, Determining the target attack path based on the risk weights of each node in the potential attack path includes: The risk weights are adjusted based on the business impact coefficients of the nodes to obtain the corrected risk weights; Based on the revised risk weights, the risks of each node are accumulated to obtain the risk value of the potential attack path; The potential attack path with the highest risk value is identified as the target attack path.

8. A risk simulation device for power grid assets, characterized in that, The device includes: The acquisition module is used to acquire power grid asset data; The construction module is used to construct a relationship graph based on the asset data to obtain an initial asset relationship graph; The calculation module is used to perform risk calculations on different nodes based on the node information of the asset relationship graph to obtain a target asset relationship graph with risk weights. The deduction module is used to perform risk deduction on the target asset relationship graph based on the risk weights to determine the target attack path.

9. An electronic device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the method as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images