A power monitoring multi-level threat cooperative defense method and system based on situation judgment

Abstract

This invention discloses a multi-level threat collaborative defense method and system for power monitoring based on situational assessment, relating to the field of power system network security technology. The method includes: acquiring local security data from defense nodes at each level of the power monitoring system and mapping it to standardized threat object instances; performing threat assessment based on the standardized threat object instances broadcast by the current and adjacent defense nodes to obtain assessment conclusions; generating service-level candidate blocking domains, host-level candidate blocking domains, and region-level candidate blocking domains according to the impact surface topology coverage description; verifying the effectiveness of damage mitigation based on attack propagation trend predictions to obtain multiple effective damage mitigation blocking domains; determining the target blocking domain with the lowest service impact cost; and generating collaborative defense action requests to drive each level of defense nodes to execute threat blocking. This application achieves a balance between effectively curbing attack propagation and ensuring the continuous operation of normal services.

Description

Technical Field

[0001] This invention relates to the field of power system network security technology, and in particular to a multi-level threat collaborative defense method and system for power monitoring based on situational assessment. Background Technology

[0002] Power monitoring systems are core infrastructure for ensuring the safe and stable operation of the power grid. Their network architecture exhibits a clear multi-level distribution, from autonomous stations and regional centralized control to substations. Each level is equipped with various heterogeneous security defense devices, including security monitoring, intrusion detection, and boundary protection. As power monitoring systems continue to evolve towards digitalization and networking, network attacks targeting secondary systems are becoming increasingly covert and multi-stage. Attacks often begin at a weak point and spread horizontally and vertically along the business dependency chain, host communication links, and regional subnets, ultimately impacting critical services related to the safe and stable operation of the power grid, such as relay protection and automatic generation control.

[0003] In existing power monitoring threat defense systems, most security defense devices at each level operate independently, each detecting threats based on locally collected security data and executing on-site response actions upon detection. Because the data formats, semantic descriptions, and alarm standards collected by devices at different levels are inconsistent, a single defense device can only perceive threats within its local area, making it difficult to grasp the actual impact and subsequent spread of the attack across the entire network. In this situation, each defense device typically employs a fixed response strategy when handling threats, implementing blocking at a preset, single granularity upon detection. This approach has significant shortcomings when facing multi-level propagation attacks: if the preset granularity is too coarse, it may interrupt a large number of normal services unrelated to the attack, and even affect critical services related to power grid security, resulting in over-handling; if the preset granularity is too fine, it is insufficient to curb the continued spread of the attack along the topology, resulting in insufficient damage mitigation.

[0004] Therefore, existing power monitoring threat defense methods struggle to strike a balance between effectively curbing the spread of attacks and ensuring the continuous operation of normal business, which has become a pressing technical problem to be solved. Summary of the Invention

[0005] To address the technical challenge of existing power monitoring threat defense technologies in striking a balance between effectively curbing attack spread and ensuring continuous normal business operations, this invention proposes a multi-level collaborative threat defense method and system for power monitoring based on situational assessment. This method integrates security awareness data from all defense nodes across the network to conduct a global threat situational assessment. It dynamically adjusts the granularity of threat handling based on the actual spread and impact level of the attack, achieving differentiated and precise handling. This effectively curbs further attack spread along the network topology while minimizing excessive intervention and disruption to normal business operations. The specific technical solution is as follows: A multi-level threat collaborative defense method for power monitoring based on situational assessment includes the following steps: acquiring local security data of each level of defense nodes in the power monitoring system; mapping the local security data into standardized threat object instances based on a preset threat object ontology model and broadcasting them among the defense nodes at each level; performing threat assessment based on the standardized threat object instances generated by the defense node at this level and the standardized threat object instances broadcast by adjacent defense nodes to obtain assessment conclusions, including an impact surface topology coverage description and an attack propagation trend prediction value; generating service-level candidate blocking domains, host-level candidate blocking domains, and regional-level candidate blocking domains based on the impact surface topology coverage description; verifying the effectiveness of the loss mitigation for the service-level candidate blocking domains, host-level candidate blocking domains, and regional-level candidate blocking domains based on the attack propagation trend prediction value to obtain multiple effective loss mitigation blocking domains; determining the target blocking domain with the lowest business impact cost based on the business importance level of the normal business interrupted by the multiple effective loss mitigation blocking domains, and mapping the target blocking domain to the corresponding blocking level; generating collaborative defense action requests based on the blocking level to drive each level of defense nodes to execute threat blocking.

[0006] Preferably, the preset threat object ontology model includes a physical layer, an asset layer, a behavioral layer, and a threat layer. Mapping local security data to standardized threat object instances based on the preset threat object ontology model includes: parsing local security data into a structured event stream; mapping the structured event stream to object instances with physical, asset, behavioral, and threat layers based on a preset ontology dictionary, thus obtaining standardized threat object instances; wherein, the standardized threat object instances use TLV encoding containing a parent object reference field, which is used to represent the cross-layer attribution reference chain between the threat layer, behavioral layer, asset layer, and physical layer.

[0007] Preferably, the assessment conclusion also includes the set of affected service points; based on the impact surface topology coverage description, generate service-level candidate blocking domains, host-level candidate blocking domains, and region-level candidate blocking domains, including: pre-constructing a full-network logical topology graph based on the logical connection relationships resolved by defense nodes at each level, the full-network logical topology graph including service nodes, host nodes, and region nodes, as well as connection edges representing the affiliation relationships and data flow dependencies between service nodes, host nodes, and region nodes; using the service nodes in the affected service point set as the seed node set, traversing along the connection edges based on preset traversal rules to obtain a minimum connected subgraph containing all affected nodes, which serves as the impact surface topology coverage description; and obtaining the corresponding service-level candidate blocking domains, host-level candidate blocking domains, and region-level candidate blocking domains based on the service node set, host node set, and region node set in the minimum connected subgraph.

[0008] Preferably, the judgment conclusion also includes attack stage labels; the steps for verifying the effectiveness of loss prevention include: based on a preset attack stage and diffusion direction mapping table, determining the diffusion direction of the attack on the entire network logical topology graph according to the attack stage labels; traversing one hop along the connection edge of the entire network logical topology graph according to the diffusion direction, and obtaining the diffusion probability level by combining the behavior chain reconstruction, to obtain the next hop node set as the attack diffusion trend prediction value; comparing the business-level candidate blocking domain, host-level candidate blocking domain, and region-level candidate blocking domain with the next hop node set respectively, and determining the candidate blocking domain containing all the next hop node sets as the effective loss prevention blocking domain.

[0009] Preferably, based on the business importance level of the normal services interrupted by multiple effective loss-stopping blocking domains, the target blocking domain with the lowest business impact cost is determined, including: determining the business importance level of the normal services interrupted by each of the multiple effective loss-stopping blocking domains based on a preset business type and business importance level mapping table; when the highest business importance level of the interrupted services of the multiple effective loss-stopping blocking domains is the same, the effective loss-stopping blocking domain with the fewest normal services under the highest interrupted business importance level is taken as the target blocking domain; wherein, the business type and business importance level mapping table is configured with multiple levels according to the operation mode of the power monitoring system, and is dynamically loaded according to the operation mode switching command.

[0010] Preferably, the method further includes: deploying an adaptive decision-making module for blocking granularity at each level of defense nodes, and configuring the blocking level that each adaptive decision-making module can autonomously decide based on the preset responsibility mapping relationship between the deployment level and the blocking level; identifying the target blocking domains for the same attack event by multiple adaptive decision-making modules for the same attack event based on the global attack event identifier to which the standardized threat object instances generated at each level belong; when multiple target blocking domains have an inclusion or overlap relationship, obtaining the final blocking domain according to the preset resolution priority rule, and driving each level of defense nodes to perform threat blocking according to the final blocking domain; wherein, the preset resolution priority rule includes adopting the target blocking domain with a smaller scope when one target blocking domain is included by another target blocking domain.

[0011] Preferably, after driving each level of defense nodes to perform threat blocking, the method further includes: obtaining the blocking execution result and sending it back to the analysis node for verification; if it is found that the target blocking domain has not completely contained the spread of the attack, the blocking level will be upgraded step by step and the execution will be re-driven.

[0012] Preferably, generating collaborative defense action requests based on the blocking level and driving each level of defense nodes to perform threat blocking includes: selecting atomic actions from a preset atomic action set based on a preset collaborative defense action protocol, generating collaborative defense action requests, wherein the atomic actions in the preset atomic action set have preset mapping relationships with the business level, host level, and region level; selecting a collaborative execution channel based on the attack stage label and confidence level in the assessment conclusion, wherein the collaborative execution channel includes an emergency fast channel and a three-phase negotiation channel; and issuing collaborative defense action requests based on the collaborative execution channel, driving each level of defense nodes to perform threat blocking.

[0013] Preferably, the blocking execution results are obtained and sent back to the analysis node for verification. When it is found that the target blocking domain has not completely contained the spread of the attack, the blocking level is upgraded step by step and the execution is re-driven. This includes: obtaining the blocking execution results of each level of defense node; encoding the blocking execution results into standardized threat object instances based on a preset threat object ontology model; and sending them back to the level defense node that performs threat analysis; verifying whether the target blocking domain contains nodes that are still spreading after the threat is blocked, based on the blocking execution results; and when the target blocking domain does not contain nodes that are still spreading after the threat is blocked, upgrading the blocking level by one level and regenerating the collaborative defense action request to drive each level of defense node to perform threat blocking.

[0014] This invention also provides a multi-level threat collaborative defense system for power monitoring based on situational assessment, applied to the aforementioned multi-level threat collaborative defense method for power monitoring based on situational assessment, comprising: The data acquisition and mapping module is used to acquire local security data of defense nodes at all levels of the power monitoring system; based on the preset threat object ontology model, it maps the local security data into standardized threat object instances and broadcasts them among defense nodes at all levels. The threat assessment module is used to assess threats based on standardized threat object instances generated by the defense nodes at this level and standardized threat object instances broadcast by defense nodes at adjacent levels, and to obtain assessment conclusions, including an impact surface topology coverage description and attack spread trend prediction values. The candidate domain generation module is used to generate service-level candidate blocking domains, host-level candidate blocking domains, and region-level candidate blocking domains based on the influence surface topology coverage description. The validity verification module is used to verify the effectiveness of stop-loss blocking domains at the business level, host level, and region level based on the attack spread trend prediction value, and obtain multiple effective stop-loss blocking domains. The decision mapping module is used to determine the target blocking domain with the lowest business impact cost based on the business importance level of the normal business interrupted by multiple effective stop-loss blocking domains, and to map the target blocking domain to the corresponding blocking level. The collaborative defense execution module is used to determine the list of objects to be blocked based on the target blocking domain, select the corresponding atomic actions according to the blocking level, generate a collaborative defense action request, and drive each level of defense nodes to perform threat blocking. The execution verification module is used to obtain the blocking execution results and send them back to the analysis node for verification. When it is found that the target blocking domain has not completely contained the spread of the attack, the blocking level will be upgraded step by step and the execution will be re-driven.

[0015] Compared with existing technologies, the beneficial effects of this invention are as follows: This invention achieves dynamic adjustment of threat handling granularity through global situational assessment, breaking the limitations of fixed handling strategies in existing defense technologies. It effectively solves the technical problem of balancing attack containment effectiveness and normal business continuity in power monitoring system threat defense scenarios. It can accurately block attack propagation paths, preventing further attack spread and endangering network security, while minimizing the impact of defense handling on normal business, ensuring the continuous and stable operation of core power monitoring services. The multi-level candidate blocking domain verification and screening mechanism proposed in this invention can make optimal handling decisions based on attack propagation trends and business impact costs, effectively balancing defense effectiveness and business operation security. Compared with traditional single-dimensional defense handling methods, it significantly improves the overall effectiveness of power monitoring system threat defense. Simultaneously, this invention constructs a closed-loop collaborative defense process of assessment-decision-execution-verification, which can dynamically adjust and upgrade blocking strategies based on execution feedback. This adapts to complex and ever-changing power monitoring network attack scenarios, further enhancing the robustness and adaptability of threat defense. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0017] Figure 1 This is a flowchart of the multi-level threat collaborative defense method for power monitoring based on situational assessment, as described in Example 1. Figure 2 This is an example diagram of three candidate blocking domains for the power monitoring system in Example 1. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0020] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0021] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] Example 1 This embodiment provides a multi-level threat collaborative defense method for power monitoring based on situational assessment. It is primarily applied to multi-level collaborative handling scenarios when power monitoring systems face multi-stage lateral spread attacks. In these scenarios, the same attack event often spans multiple levels and affects various services and hosts within minutes. In these application scenarios, a key challenge in operation and maintenance defense is selecting the appropriate blocking granularity for each response during the continuous spread of the attack, one that both curbs the spread and minimizes disruption to normal services.

[0023] Please refer to Figure 1 , Figure 1 This is a flowchart of a multi-level threat collaborative defense method for power monitoring based on situational assessment. The multi-level threat collaborative defense method for power monitoring based on situational assessment provided in this embodiment includes the following steps: S1. Acquire local security data of each level of defense nodes in the power monitoring system; map the local security data into standardized threat object instances based on the preset threat object ontology model, and broadcast them among the defense nodes at each level.

[0024] Specifically, in this embodiment, the power monitoring system has several defense nodes at the main station layer, regional control layer, and substation layer. Each defense node acquires local security data within its jurisdiction. This local security data includes multi-source data generated by security devices from different manufacturers and models, such as intrusion detection alarms, traffic audit records, host behavior logs, and boundary access control logs. After acquiring the local security data, each defense node does not directly process the data. Instead, it first maps the local security data, which differ in format and semantics, into standardized threat object instances based on a preset threat object ontology model.

[0025] In step S1, the preset threat object ontology model includes a physical layer, an asset layer, a behavioral layer, and a threat layer. The physical layer describes the actual physical devices and network carriers in the power monitoring system, such as measurement and control devices, switches, and servers. The asset layer describes the logical assets carried on the physical devices, such as running services, open services, and accounts. The behavioral layer describes the operations and access actions that occur on the assets, such as login, command issuance, and data reading and writing. The threat layer describes the attack nature reflected by abnormal behavior, such as unauthorized access, malicious control, and lateral movement.

[0026] Furthermore, based on a pre-defined threat object ontology model, local security data is mapped to standardized threat object instances, including: 1. Parse local security data into a structured event stream.

[0027] Specifically, local security data is first broken down and organized according to a unified field specification. Each piece of raw data is organized into several structured events containing fields such as time, source, object, and action. Multiple structured events arranged in chronological order constitute a structured event stream.

[0028] 2. Based on a pre-defined ontology dictionary, the structured event flow is mapped to object instances with physical, asset, behavioral, and threat layers, resulting in standardized threat object instances. These standardized threat object instances are encoded using TLV encoding that includes a parent object reference field, which represents the cross-layer attribution reference chain between the threat, behavioral, asset, and physical layers.

[0029] In this embodiment, a pre-defined ontology dictionary records the correspondence between original field values ​​and concepts at each layer of the ontology. For example, a certain device model identifier corresponds to a certain type of device in the physical layer, a certain port access action corresponds to a certain operation in the behavior layer, and a certain alarm type corresponds to a certain attack nature in the threat layer. By looking up the dictionary field by field, the originally scattered fields are assigned to their corresponding ontology layers, ultimately resulting in standardized threat object instances. The pre-defined ontology dictionary is organized in the form of a set of key-value pairs. Each entry contains an original feature pattern, an ontology layer, and an ontology concept identifier. The original feature pattern is the possible values ​​or value ranges of a certain field in the structured event stream. The ontology layer indicates which layer (physical, asset, behavior, or threat) the pattern should be assigned to. The ontology concept identifier is the standard concept number corresponding to the pattern at the corresponding layer.

[0030] The default ontology dictionary can be built offline once and maintained incrementally as needed: using the list of commonly used equipment models, communication protocol specifications (such as DL / T 634.5104, IEC 61850), alarm dictionary and asset ledger as the corpus source, domain engineers classify the field values ​​into the four ontology levels one by one and assign concept labels to form the initial dictionary; when a new model of equipment or a new protocol is connected, only the corresponding entries need to be added to the dictionary.

[0031] Specifically, standardized threat object instances are carried using TLV (Type-Length-Value) encoding, which includes a parent object reference field. Standardized threat object instances are encoded field by field in TLV format, with each field consisting of a type field T, a length field L, and a value field V, concatenated sequentially. The type field T is 1 byte and is used to identify the semantic category of the field. In this embodiment, it is agreed that: T=0x01 indicates the ontology level to which it belongs, T=0x02 indicates the ontology concept identifier, T=0x03 indicates the unique instance number of the object, T=0x04 indicates the parent object reference field, T=0x05 indicates the timestamp, and T=0x06 indicates the global attack event identifier; the length field L is 1 to 2 bytes, representing the byte length of the value field V; the value field V is the actual value of the field. For example, a threat layer instance can be encoded as: {T=0x01,L=1,V=threat layer}{T=0x02,L=2,V=THR-0105}{T=0x03,L=4,V=this instance number}{T=0x04,L=4,V=the number of the behavior layer instance it is attached to}. The value of the parent object reference field (T=0x04) is filled with the unique instance number of the object instance at the next higher level: the parent object reference of the threat layer instance points to the behavior layer instance number that caused the threat, the parent object reference of the behavior layer instance points to the asset layer instance number that the behavior affects, the parent object reference of the asset layer instance points to the physical layer instance number that carries the asset, and the parent object reference field of the physical layer instance is set to empty. Thus, the instances at the four levels are connected end-to-end through the parent object reference field, forming a cross-level attribution reference chain that can be traced back step by step.

[0032] After mapping is complete, each defense node broadcasts the standardized threat object instances generated at its current level to defense nodes at adjacent levels, while simultaneously receiving standardized threat object instances broadcast from adjacent defense nodes. For example, a plant / site layer defense node maps an abnormal control command detected locally as a standardized threat object instance and then broadcasts it to its corresponding area control layer defense node; the area control layer defense node then broadcasts abnormal access instances related to the same network segment at its current level to both the plant / site layer and the master site layer.

[0033] S2. Based on the standardized threat object instances generated by the defense nodes at this level and the standardized threat object instances broadcast by the defense nodes at adjacent levels, a threat assessment is performed to obtain assessment conclusions, which include an impact surface topology coverage description and an attack spread trend prediction.

[0034] In this embodiment, the input for analysis includes instances generated at the current level and instances broadcast from adjacent levels. Since the standardized instances broadcast from each level are initially scattered and isolated, the primary task of analysis is to associate them as the same attack event. The defense node makes a determination based on the following three association conditions: first, instances can be traced back to a common physical layer or asset layer instance through a parent object reference chain; second, the timestamps of the instances fall within the same sliding time window (e.g., 5 minutes by default); and third, the objects involved in the instances have reachable edges on the entire network logical topology graph. Instances that meet the above association conditions are determined to be the same attack event, and the defense node generates a globally unique attack event identifier for it and writes it back to the T=0x06 field of each instance; subsequent newly arrived instances associated with this event use the same identifier. This mechanism links alarms that were originally scattered across different levels and devices into a complete attack chain.

[0035] After completing the time correlation, the defense node outputs its analysis conclusions. These conclusions include an impact surface topology coverage description and an attack propagation trend prediction. The impact surface topology coverage description is defined as depicting the entire set of nodes that the attack has actually reached, including affected services, affected hosts, and affected regions. The attack propagation trend prediction is defined as predicting the target nodes (next-hop node set) to which the attack is most likely to spread next; that is, the most likely exit nodes for the attack to expand outward along the topology from the current impact surface.

[0036] Step S3. Based on the influence surface topology coverage description, generate service-level candidate blocking domains, host-level candidate blocking domains, and region-level candidate blocking domains.

[0037] In this embodiment, the defense node generates three candidate blocking domains of different granularities based on the impact surface topology coverage description in the assessment conclusion, surrounding the area affected by the attack. The difference between the three lies in the granularity of the action: the service-level candidate blocking domain focuses on the specific affected service, the host-level candidate blocking domain focuses on the host on which the affected service depends or resides, and the region-level candidate blocking domain focuses on the regional subnet where the affected object is located. The three candidate blocking domains expand in coverage from fine to coarse.

[0038] Please refer to Figure 2 , Figure 2 This is an example diagram of three candidate blocking domains for a power monitoring system. The power monitoring system used in this embodiment includes a master station, a dispatch data network, and several substations. The master station is equipped with a situational awareness system master station, which includes a situational awareness analysis platform and a situational awareness front-end unit. It collects business data such as stability, dispatch automation, information protection, equipment status monitoring, and metering automation through the master station's data acquisition device. Each substation is interconnected with the master station through the dispatch data network, and each substation is equipped with a monitoring backend, measurement and control, and protection devices. Figure 2The three sites illustrate the three levels of granularity corresponding to the three candidate blocking domains in this application: service blocking at site X can control only the affected service without disconnecting the network cable at the site; host blocking at site B can control a single host without disconnecting a portion of the network; and area blocking at site A can control a small area network without interrupting the main site or the entire region. These three levels, from finest to coarsest, correspond to the service-level, host-level, and area-level candidate blocking domains generated by S3.

[0039] Furthermore, the assessment conclusions also include a set of affected service points, which records services confirmed by the threat assessment to have been affected by the attack; based on the impact surface topology coverage description, service-level candidate blocking domains, host-level candidate blocking domains, and region-level candidate blocking domains are generated, including: S31. Based on the logical connection relationship of the defense nodes at each level, a full network logical topology graph is pre-constructed. The full network logical topology graph includes business nodes, host nodes, and regional nodes, as well as connection edges that represent the affiliation relationship and data flow dependency relationship between business nodes, host nodes, and regional nodes.

[0040] In this embodiment, during the parsing of local security data, each level of defense node simultaneously parses the logical connections between its subordinate objects. For example, a service may run on a certain host, a host may belong to a certain region, or the data flow of a certain service may depend on another service. The system aggregates the logical connections parsed from each level and pre-constructs a logical topology map covering the entire network. This "pre-construction" mechanism is used because the network-wide logical topology map reflects the relatively stable structural relationships during normal system operation. It can be established offline before an attack occurs and incrementally updated as the structure changes, allowing for direct invocation during analysis without the need for temporary construction.

[0041] Specifically, the overall network logical topology diagram contains three types of nodes: service nodes, host nodes, and regional nodes. Service nodes are the segmented services running within the power monitoring system; host nodes are the physical or virtual hosts / servers that carry these services; and regional nodes are regions / subnets divided by geographical location or network. Nodes are connected by edges, which represent two types of relationships: one is affiliation edges, representing vertical hierarchical relationships of "belonging to," such as a service node belonging to the host node it runs on, and a host node belonging to the regional node it is located in; the other is data flow dependency edges, representing horizontal dependencies in the data interaction of service nodes, such as a service node's operation depending on data provided by another service node, reflecting horizontal correlation. See also Figure 2 The three types of objects—business, host, and region—are physically distributed across the main station and various factory stations. In the logical topology graph, they are abstracted into three types of nodes and their connecting edges, allowing the impact of attacks to be expressed on a unified graph structure.

[0042] S32. Using the business nodes within the affected business point set as the seed node set, traverse along the connecting edges based on the preset traversal rules to obtain the minimum connected subgraph containing all affected nodes, which serves as the topological coverage description of the affected surface.

[0043] In this embodiment, the defense node uses the business nodes within the affected business point set in the assessment conclusion as the seed node set, that is, it takes the businesses confirmed to be affected by the attack as the starting point for traversal. Subsequently, based on preset traversal rules, the defense node starts from the seed node set and traverses outward along the connection edges of the entire network logical topology graph, gradually including other nodes that have affiliation or data flow dependency with the affected businesses, until no new affected nodes are included.

[0044] Specifically, the preset traversal rules stipulate the edge selection and termination conditions that should be followed when expanding on the entire logical topology graph starting from the seed node set, including edge type admission conditions, expansion termination conditions, and edge filtering conditions.

[0045] The edge type admission criteria stipulate that bidirectional expansion is allowed along the attribution relationship edge: from the business node, it can be traced back to its host node, and from the host node, it can be traced back to its region node, and vice versa. However, expansion is only allowed along the data flow dependency relationship edge in the dependency direction, that is, from the dependent business to the dependent business, or from the dependent business to the dependent business. The specific direction is determined by the direction attribute marked on the dependency edge.

[0046] The expansion termination condition specifies that the traversal adopts a breadth-first approach to expand hop by hop, and terminates when a hop no longer includes any new affected nodes, thus obtaining the minimum subgraph that "exactly covers all affected nodes and is connected"; at the same time, a maximum number of hops can be set as a fallback, such as the default of 3 hops.

[0047] Edge filtering conditions refer to filtering edges with data flow dependencies by combining the dependency strength attribute marked on the edge, expanding only along edges with dependency strength higher than a set threshold, and excluding weak dependency edges from traversal.

[0048] For example, suppose the seed node is the affected service node B1, B1 belongs to host H1, H1 belongs to region Z1, and service node B2 depends on B1's data with a strong dependency relationship. Traversing according to the above rules: the first hop is to include H1 along the belonging edge and B2 along the strong dependency edge; the second hop is to include Z1 from H1 along the belonging edge and B2 from B2 along the belonging edge to its host H2; the third hop terminates if no new node is included. The final minimal connected subgraph consists of {B1, B2}, {H1, H2}, and {Z1}, thus obtaining the service node set, host node set, and region node set.

[0049] S33. Based on the service node set, host node set, and region node set in the minimum connected subgraph, the corresponding service-level candidate blocking domain, host-level candidate blocking domain, and region-level candidate blocking domain are obtained.

[0050] The defense nodes group the nodes in the minimum connected subgraph by type, obtaining candidate blocking thresholds at three granularities: service-level candidate blocking domains, host-level candidate blocking domains, and region-level candidate blocking domains. The service-level candidate blocking domains are grouped from the service node set in the minimum connected subgraph; the host-level candidate blocking domains are grouped from the host node set in the minimum connected subgraph; and the region-level candidate blocking domains are grouped from the region node set in the minimum connected subgraph.

[0051] Since all three candidate blocking domains are projected from the same minimum connected subgraph, the objects they cover all fall within the boundaries that fit the actual range of the attack, only with different granularities—the finest at the business level, the middle at the host level, and the coarsest at the region level.

[0052] S4. Based on the predicted attack spread trend, the effectiveness of the stop-loss measures is verified for the business-level candidate blocking domains, host-level candidate blocking domains, and regional-level candidate blocking domains, resulting in multiple effective stop-loss blocking domains.

[0053] In this embodiment, after obtaining the three-level candidate blocking domains, the defense node does not immediately select from them. Instead, it first uses the attack propagation trend prediction value in the analysis conclusion to verify the effectiveness of each candidate blocking domain in stopping the attack. The core issue of the verification is whether the scope covered by a candidate blocking domain can also include the objects that the attack is most likely to spread to next. If it can, then the candidate blocking domain can block the next step of the attack's propagation once it is executed, and is considered effective; if it cannot, it means that although the candidate blocking domain has dealt with the currently affected part, it has left an exit for the attack to continue to spread, and the damage control is insufficient.

[0054] Specifically, the assessment conclusions also include attack phase labels; the steps for verifying the effectiveness of stop-loss measures include: S41. Based on the preset attack stage and diffusion direction mapping table, determine the diffusion direction of the attack on the entire network logical topology map according to the attack stage label.

[0055] In this embodiment, the attack stage label is used to characterize the current stage of the attack, such as reconnaissance, initial access, lateral movement, and control execution. A preset attack stage and propagation direction mapping table records the correspondence between each attack stage and its typical propagation direction. Because attacks at different stages often exhibit regularity in their next propagation direction, for example, attacks in the lateral movement stage tend to spread along the connection edges between hosts to other hosts in the same area, while attacks in the control execution stage tend to approach critical services along the service dependency edges.

[0056] The preset attack phase and diffusion direction mapping table uses attack phase labels as indexes. Each entry gives the type and direction of the expansion edge. For example: Reconnaissance phase → No substantial diffusion, only marking the probe source, no expansion direction is generated; Initial access phase → Tracing up from the business node to its host node along the home edge; Lateral movement phase → Expanding to other host nodes in the same region along the home edge between hosts in the same region and the host-host dependency edge; Privilege escalation phase → Tracing up from the host node to the regional node along the home edge; Control execution phase → Expanding from the current business node to the high-importance business nodes it depends on along the data flow dependency edge.

[0057] The mapping table is pre-built based on knowledge of attack tactics. Attacks at different stages have a regular pattern in their next spread direction, and the table is an explicit encoding of this pattern.

[0058] The attack phase label is determined by the threat assessment stage based on the behavior chain reconstruction results. The defense node pre-establishes a correspondence between "behavior type sequence pattern - attack phase", matches the behavior type sequence at the end of the reconstructed behavior chain with the correspondence, and takes the matched phase as the attack phase label; for example, if the behavior chain shows "port scanning → credential acquisition", it is labeled as the initial access phase, and if it shows "lateral login → cross-host command issuance", it is labeled as the lateral movement phase.

[0059] S42. Based on the diffusion direction, traverse one hop along the connecting edges of the entire network logical topology graph, and combine the diffusion probability level obtained from the behavior chain reconstruction to obtain the next hop node set, which serves as the attack diffusion trend prediction value.

[0060] In this embodiment, the defense node, based on the propagation direction determined in S41, starts from the current impact surface and traverses one hop outward along the connecting edges of the entire network logical topology to obtain the adjacent nodes most likely to be reached by the attack in the next step. The reason for traversing only one hop is that the effectiveness verification of the damage mitigation focuses on the next step of the attack's spread immediately afterward. As long as the next hop can be blocked, the path for its continued propagation can be cut off.

[0061] The defense node sorts standardized threat object instances from various levels under the same global attack event identifier according to the timestamp field of each instance, and connects the scattered instances into a chronologically arranged sequence of behaviors, i.e., a behavior chain, along the cross-layer attribution reference chain constructed by the parent object reference field. Each node in the behavior chain is a behavior layer instance, where behavior layer instances are such as "lateral login," "command issuance," and "port scanning," and are accompanied by the asset layer and physical layer instances to which they are attributed. Behavior chain reconstruction itself is a sorting and concatenation of existing instances. The diffusion probability level is used to characterize the likelihood of an attack spreading from the current impact towards a certain adjacent node on the topology graph.

[0062] In this embodiment, a lightweight classification model is used to output the diffusion probability level for each candidate neighbor node. The lightweight classification model can be implemented using a gradient boosting decision tree. The input features of the lightweight classification model include behavioral chain features, topological relationship features, and candidate node attribute features. Behavioral chain features include the attack stage label of the current behavioral chain, the type number of the behavior at the end of the behavioral chain, the length of the behavioral chain, and the average time interval between two adjacent behaviors; topological relationship features include the shortest hop count from the current influence surface to the candidate neighbor node, the edge type connecting the two (belonging edge / dependent edge), the direction attribute and dependency strength attribute of the dependent edge; candidate node attribute features include the node type of the candidate node (service / host / region), the importance level of the service running on it, and the frequency of the node being affected by similar attacks in history.

[0063] It should be noted that the training samples for the lightweight classification model come from: real attack cases that have been reviewed and confirmed in the historical security event database of the power monitoring system; labeled data generated from injection attacks using typical attack methods (lateral movement, privilege escalation, control execution, etc.) in the power monitoring simulation range; and a small number of boundary samples manually labeled by domain experts based on their attack tactics knowledge. The label of each training sample is taken from the fact that the adjacent node was "subsequently affected" in the corresponding attack process, thereby discretizing the diffusion probability level into several categories. The model discretizes the diffusion probability level into three output categories: high, medium, and low. A high level indicates that the node is highly likely to be affected in the subsequent short time window; a medium level indicates that the node is reachable in terms of affiliation / dependency but has a moderate probability of being affected historically; and a low level indicates that the node is topologically reachable but rarely affected.

[0064] The output confidence score of the lightweight classification model is used to filter the next-hop node set in S42—only neighboring nodes with a high diffusion probability level and a confidence score not lower than a set threshold (e.g., 0.6) are included in the next-hop node set, while nodes with medium / low levels are removed when the confidence score is sufficiently high. The output confidence score is written back as an edge attribute of the corresponding connecting edge on the entire network logical topology graph.

[0065] S43. Compare the business-level candidate blocking domain, host-level candidate blocking domain, and region-level candidate blocking domain with the next-hop node set respectively, and determine the candidate blocking domain containing the entire next-hop node set as the effective stop-loss blocking domain.

[0066] Specifically, if a candidate blocking domain contains all nodes of the next-hop node set, it means that once the blocking domain is executed, the target that the attack is most likely to spread to next will also be blocked, and the spread path of the attack will be cut off. Therefore, the candidate blocking domain is determined to be an effective stop-loss blocking domain. Conversely, if a candidate blocking domain fails to completely contain the next-hop node set, it means that although it has dealt with the current impact, it has left an exit for the attack to continue to spread. The stop-loss is insufficient and it is screened out.

[0067] S5. Based on the business importance level of the normal business interrupted by multiple effective stop-loss blocking domains, determine the target blocking domain with the lowest business impact cost, and map the target blocking domain to the corresponding blocking level.

[0068] In this embodiment, the defense node compares multiple effective loss-mitigation blocking domains and selects the one with the lowest business impact cost as the target blocking domain. That is, the solution that minimizes and avoids interrupting important services while ensuring all options can mitigate the damage. Therefore, the final determined target blocking domain simultaneously meets two requirements: it falls within the range capable of containing the attack's spread, and it causes the least damage to normal services among all feasible ranges. After determining the target blocking domain, the defense node maps it to the corresponding blocking level, that is, based on the granularity of the target blocking domain, it determines whether the current action should be performed at the service level, host level, or region level.

[0069] Specifically, step S5 includes the following steps: S51. Based on the preset business type and business importance level mapping table, determine the business importance level of the normal business interrupted by each of the multiple effective stop-loss blocking domains.

[0070] Specifically, for each effective stop-loss blocking domain obtained in step S4, the defense node first determines which normal services will be interrupted once it is executed, and then determines the service importance level of each of these interrupted normal services based on the preset service type and service importance level mapping table.

[0071] Taking the normal operation mode as an example, relay protection, automatic safety devices, and automatic generation control can be classified as Level 1 (highest), dispatch automation and equipment status monitoring as Level 2, and metering automation as Level 3. However, in the major event supply guarantee mode, dispatch automation services directly related to supply guarantee can be upgraded from Level 2 to Level 1. The operation mode switching command is issued by the dispatch side, carrying the target mode identifier. After receiving the operation mode switching command, each level of defense node atomically replaces the currently effective mapping table with the mapping table corresponding to the target mode.

[0072] Furthermore, the mapping table is constructed as follows: based on the business ledgers and operating procedures of the power monitoring system, experts in the field of power grid operation classify the data according to the severity of the consequences of business interruption. It is typically divided into three levels, but can be expanded to four or more levels as needed.

[0073] The operation mode of a power monitoring system is not static; the importance of the same service may change under different operating modes. Therefore, the mapping table is configured with multiple levels. For example, each of the following levels corresponds to a different importance level: normal operation, peak summer demand, major event supply guarantee, and maintenance. When the system operating mode changes, the defense node dynamically loads the corresponding level of the mapping table based on the operating mode switching command.

[0074] S52. When multiple effective stop-loss blocking domains have the same highest service importance level, the effective stop-loss blocking domain with the fewest normal services under the highest service importance level is selected as the target blocking domain. The service type-service importance level mapping table has multiple levels configured according to the power monitoring system's operating mode and is dynamically loaded based on the operating mode switching command.

[0075] Specifically, the defense node compares multiple effective stop-loss blocking domains according to the importance level of the normal services interrupted by each domain, selecting the one with the least business impact cost. The comparison adopts a hierarchical approach, first comparing the highest importance level, then comparing the number of interrupted services. Furthermore, when multiple effective stop-loss blocking domains have the same highest importance level of interrupted services, and cannot be distinguished by the highest importance level alone, the defense node further compares the number of normal services interrupted at that highest importance level for each blocking domain, and selects the effective stop-loss blocking domain with the fewest interrupted services at that level as the target blocking domain.

[0076] After determining the target blocking domain, the defense node directly maps it to the corresponding blocking level: the blocking level mapped to the service-level candidate blocking domain is the service-level; the blocking level mapped to the host-level candidate blocking domain is the host-level; and the blocking level mapped to the region-level candidate blocking domain is the region-level.

[0077] Preferably, the multi-level threat collaborative defense method for power monitoring based on situational assessment in this embodiment further includes: S10: Deploy blocking granularity adaptive decision modules at each level of defense nodes, and configure the blocking level that each granularity adaptive decision module can decide autonomously according to the preset responsibility mapping relationship between the deployment level and the blocking level.

[0078] In this embodiment, to prevent the decision-making scope of each module from exceeding its actual jurisdiction, the blocking levels are configured to be autonomously decided by each blocking granularity adaptive decision-making module based on the preset responsibility mapping relationship between the deployment level and the blocking level. For example, the plant layer module can be configured to autonomously decide on service-level and host-level blocking, the regional control layer module can autonomously decide on host-level and regional-level blocking, and the master station layer module can autonomously decide on regional-level blocking and has global decision-making authority. When a module determines that the target blocking domain exceeds its autonomously decided blocking level, it will not execute the decision itself, but will report it to the superior module with decision-making authority at that level for processing, thereby ensuring that the handling actions match the actual jurisdictional responsibilities of each level.

[0079] The preset responsibility mapping relationship registers the set of blocking levels that each module can independently decide on, and whether it has global decision-making authority: Plant / Station Level → {Business Level, Host Level}, no global decision-making authority; Regional Control Level → {Host Level, Regional Level}, no global decision-making authority; Master Station Level → {Regional Level}, has global decision-making authority. Its configuration is based on the actual reachable and manageable scope of each level—the Plant / Station Level can directly operate its own station's business and hosts, therefore it is authorized to the two most granular levels; the Master Station Level has overall control, therefore it is granted regional-level decision-making authority and conflict resolution authority.

[0080] S20: Based on the global attack event identifier to which the standardized threat object instances generated at each level for the same attack event belong, identify the target blocking domain for the same attack event by multiple blocking granularity adaptive decision modules.

[0081] In this embodiment, since the same attack event is often detected by multiple layers of defense nodes during its propagation, each layer may generate its own target blocking domain. To link these dispersed decisions, the defense nodes use the global attack event identifier (T=0x06 field in the aforementioned TLV encoding) carried in the standardized threat object instance for identification. The global attack event identifier is a unified identifier assigned to multiple instances when threat assessment confirms that they belong to the same attack event; all instances belonging to the same attack event carry the same global attack event identifier.

[0082] S30: When multiple target blocking domains have an inclusion or overlap relationship, the final blocking domain is obtained according to the preset resolution priority rule, and each level of defense node is driven to perform threat blocking according to the final blocking domain; wherein, the preset resolution priority rule includes adopting the target blocking domain with a smaller scope when one target blocking domain is included by another target blocking domain.

[0083] In this embodiment, for multiple target blocking domains aggregated from the same attack event, the defense node first determines whether they have an inclusion or overlap relationship on the entire network logical topology map. If each target blocking domain is independent and does not overlap with the others, they can be executed separately; if one target blocking domain is included by another target blocking domain, or the two partially overlap, they need to be resolved according to the preset resolution priority rules to obtain a unique final blocking domain, and then drive the defense nodes at each level to execute the blocking accordingly.

[0084] Specifically, the preset resolution priority rules stipulate the following regarding containment relationships: when one target blocking domain is completely contained by another target blocking domain, the target blocking domain with the smaller scope is adopted as the final blocking domain. Regarding partial overlap relationships: first, the union of all overlapping target blocking domains is taken as a candidate final domain, and then the S4 stop-loss validity check is re-executed on this union; if the union passes the check, the main station layer module with global decision-making authority selects one of the union and each original target domain as the final blocking domain according to the S5 minimum business cost criterion.

[0085] After obtaining the unique final blocking domain, a collaborative defense action request is generated according to the process in step S6, which drives the defense nodes at each level to perform threat blocking based on the final blocking domain.

[0086] S6. Generate collaborative defense action requests based on the blocking level, and drive each level of defense nodes to perform threat blocking.

[0087] In this embodiment, each level of defense node that receives the request for coordinated defense action performs threat blocking within its jurisdiction, such as disabling affected services at the service level, isolating relevant hosts at the host level, or blocking the corresponding subnet at the region level.

[0088] Specifically, step S6 includes the following sub-steps: S61. Based on the preset collaborative defense action protocol, select atomic actions from the preset atomic action set according to the blocking level, and generate a collaborative defense action request. The atomic actions in the preset atomic action set have preset mapping relationships with the service level, host level and region level.

[0089] The collaborative defense action request is encapsulated according to a preset standardized protocol to ensure that heterogeneous defense devices at all levels can uniformly parse and execute it. Specifically, the message consists of two parts: a protocol header and an action body. The protocol header includes a global attack event identifier, request sequence number, target blocking level, selected collaborative execution channel identifier, and timestamp. The action body is a list of one or more action items, each consisting of {action number, target identifier, and input parameter list}. The preset atomic action set is an action table that registers several standardized minimum handling operations. Each atomic action is described by five items: action number, action name, target type, input parameter list, and expected result status.

[0090] For example, the atomic action set contains: ACT-B01 "Disable Service", the target object type is service, the input parameter is {service identifier}, and the expected result is that the service process stops; ACT-B02 "Block Service Session", the target type is service, the input parameters are {service identifier, peer address}, and the expected result is that the service's external session is interrupted. ACT-H01 "Isolate Host", the target type is host, the input parameter is {host address}, and the expected result is that all non-management network ports of the host are disconnected. ACT-H02 "Block Host Port" targets a host and takes {host address, port number, protocol} as input parameters. The expected result is that the port will refuse to establish new connections. ACT-Z01 "Block Subnet", the target type is area, the input parameter is {subnet segment}, and the expected result is that the subnet is disconnected from external routes; ACT-Z02 "Enable Zone ACL", the target type is zone, the input parameters are {subnet segment, access control policy identifier}, and the expected result is that the traffic of the subnet is filtered according to the policy.

[0091] Furthermore, the preset mapping relationship between atomic actions and blocking levels is as follows: The preset mapping relationship uses the blocking level as an index and registers the set of atomic action numbers that can be invoked at each level: the service level is mapped to {ACT-B01, ACT-B02}, the host level is mapped to {ACT-H01, ACT-H02}, and the region level is mapped to {ACT-Z01, ACT-Z02}. After the defense node determines the blocking level, it retrieves the corresponding action number set according to this mapping relationship, and then instantiates them one by one according to each specific object covered by the target blocking domain—for example, if the target blocking domain is the host level and covers hosts H1 and H2, then it instantiates two actions, ACT-H01(H1) and ACT-H01(H2), and encapsulates them together into a collaborative defense action request. When there are multiple atomic actions mapped at the same level, the defense node selects them according to the preset action priority order (e.g., host level prioritizes ACT-H01 for whole-machine isolation, and only selects ACT-H02 for port blocking when it is necessary to retain other functions of the host).

[0092] S62. Based on the attack phase label and confidence level in the analysis conclusion, select the collaborative execution channel, which includes the emergency rapid channel and the three-stage negotiation channel.

[0093] In this embodiment, before issuing a collaborative defense action request, the defense node first selects one of two collaborative execution channels based on the attack stage label and confidence level in the assessment conclusion. These two channels are the emergency rapid channel and the three-stage negotiation channel. The emergency rapid channel's execution process involves the assessment node issuing the request directly, and all nodes executing it immediately, without negotiation or confirmation. The three-stage negotiation channel's execution process proceeds sequentially through three extremes: pre-notification, confirmation, and execution. Specifically, the pre-notification stage involves the assessment node issuing a pre-notification to relevant defense nodes, informing them of the proposed blocking domain and atomic actions; the confirmation stage involves each relevant node verifying the impact of the action on its own level of business and responding with confirmation or objection, which is then decided by the assessment node or the superior module; and the execution stage involves formally issuing the execution instruction after confirmation.

[0094] Furthermore, the confidence level is determined by grading the confidence level output from the diffusion probability level model in step S42: The confidence levels of each node within the next-hop node set are weighted and averaged (weights are determined by the diffusion probability level of each node, high > medium > low). Confidence levels falling within [0.8, 1.0] are categorized as high-level, [0.6, 0.8] as medium-level, and below 0.6 as low-level. Accordingly, the emergency fast channel is selected when the confidence level is high and the attack phase is critical; otherwise, the three-stage negotiation channel is selected. Continuous confidence levels are then categorized into discrete levels.

[0095] Furthermore, the selection of defense nodes is based on both the attack phase label and the confidence level. When the attack phase label indicates that the attack is in a critical and rapidly spreading stage, such as lateral movement or control execution, and the confidence level is high, the emergency fast channel is selected to strive for timely response and complete the blocking before the attack spreads further. At this time, because the assessment is highly reliable, the risk of misjudgment caused by skipping the negotiation process is low, and prioritizing speed is reasonable. When the attack phase label indicates that the attack is still in a stage of non-urgent spread, such as reconnaissance or initial access, or when the confidence level is in the low to medium range, the three-stage negotiation channel is selected.

[0096] S63. Based on the collaborative execution channel, issue collaborative defense action requests to drive each level of defense nodes to perform threat blocking.

[0097] Specifically, after selecting a collaborative execution channel, the defense node issues a pre-packaged collaborative defense action request: when passing through the emergency fast channel, it issues the request directly and triggers all levels of defense nodes to execute it immediately; when passing through the three-stage negotiation channel, it proceeds in three stages: pre-notification, confirmation, and execution, and execution is triggered after confirmation.

[0098] The multi-level threat collaborative defense method for power monitoring based on situational assessment in this embodiment further includes step S7: obtaining the blocking execution result and sending it back to the assessment node for verification. If it is found that the target blocking domain has not completely contained the attack spread, the blocking level is upgraded level by level and the execution is restarted. Specifically, step S7 includes the following sub-steps: S71. Obtain the blocking execution results of each level of defense nodes, encode the blocking execution results into standardized threat object instances based on the preset threat object ontology model, and send them back to the level of defense nodes that perform threat assessment.

[0099] In this embodiment, after each level of defense node performs threat blocking, it obtains the blocking execution result of its level. The blocking execution result includes whether the blocking action was successfully executed and the current connectivity and activity status of the blocked object. The defense node still encodes the blocking execution result into a standardized threat object instance based on the preset threat object ontology model and sends it back to the level of defense node that previously performed the threat assessment.

[0100] S72. Based on the blocking execution result, verify whether the target blocking domain contains nodes that are still spreading after the threat is blocked.

[0101] Specifically, the analysis-level defense nodes, based on the returned blocking execution results, re-examine the current spread of the attack. They need to verify whether any nodes are still in a state of continuous spread after the blocking corresponding to the target blocking domain has been executed, and whether these still-spreading nodes are now within the coverage area of ​​the target blocking domain. If the blocking execution results show that no nodes are continuing to spread, or that all still active nodes are within the target blocking domain, it indicates that the attack has been effectively contained, and the loop is closed. If nodes are found to be still spreading and not covered by the target blocking domain, it indicates that although the previously selected granularity has been verified for damage control, the actual spread of the attack exceeded the prediction, resulting in insufficient damage control, and further action is required.

[0102] S73. If the target blocking domain does not contain nodes that are still spreading after threat blocking, upgrade the blocking level by one level and regenerate the collaborative defense action request to drive the defense nodes at each level to perform threat blocking.

[0103] Specifically, after upgrading the blocking level, the defense nodes redetermine the blocking domain according to the upgraded granularity and regenerate the collaborative defense action request, which then drives the defense nodes at each level to perform threat blocking again. Each time, only one level is upgraded and the process returns to S71 for re-verification, progressing step by step until S72 no longer finds any uncovered nodes that are still spreading.

[0104] In summary, this invention uses a pre-defined threat object ontology model to uniformly map heterogeneous local security data collected by defense nodes at each level into standardized threat object instances, which are then broadcast among the defense nodes at each level. This allows each level to perform threat assessment based on standardized threat object instances of its own level and adjacent levels, thus overcoming the limitations of existing defense devices that conduct independent assessments and have fragmented understanding between different levels. Secondly, based on the impact surface topology coverage description obtained from the assessment, three levels of candidate blocking domains—service level, host level, and region level—are generated. The effectiveness of the three levels of candidate blocking domains in stopping damage is verified step by step based on the attack spread trend prediction value. From multiple effective blocking domains that meet the damage stopping requirements, the target blocking domain with the minimum business impact cost is calculated based on the business importance level of the normal business interrupted by each candidate domain. Based on this, the blocking level is mapped and the defense nodes at each level are driven to collaboratively execute threat blocking. Therefore, this invention changes the selection of threat handling granularity from the existing fixed single granularity to a multi-granularity decision that is adaptively determined according to the actual impact and diffusion trend of the attack. This makes the handling granularity sufficient to curb the continuous spread of the attack along the topology and minimize the interruption cost of normal business. It effectively solves the technical problem in the existing multi-level defense where the handling granularity is too coarse, resulting in over-handling, or too fine, resulting in insufficient loss mitigation, and it is difficult to achieve both.

[0105] Example 2 This embodiment provides a multi-level collaborative threat defense system for power monitoring based on situational assessment, applied to the multi-level collaborative threat defense method for power monitoring based on situational assessment in Embodiment 1, including: The data acquisition and mapping module is used to acquire local security data of defense nodes at all levels of the power monitoring system; based on the preset threat object ontology model, it maps the local security data into standardized threat object instances and broadcasts them among defense nodes at all levels. The threat assessment module is used to assess threats based on standardized threat object instances generated by the defense nodes at this level and standardized threat object instances broadcast by defense nodes at adjacent levels, and to obtain assessment conclusions, including an impact surface topology coverage description and attack spread trend prediction values. The candidate domain generation module is used to generate service-level candidate blocking domains, host-level candidate blocking domains, and region-level candidate blocking domains based on the influence surface topology coverage description. The validity verification module is used to verify the effectiveness of stop-loss blocking domains at the business level, host level, and region level based on the attack spread trend prediction value, and obtain multiple effective stop-loss blocking domains. The decision mapping module is used to determine the target blocking domain with the lowest business impact cost based on the business importance level of the normal business interrupted by multiple effective stop-loss blocking domains, and to map the target blocking domain to the corresponding blocking level. The collaborative defense execution module is used to determine the list of objects to be blocked based on the target blocking domain, select the corresponding atomic actions according to the blocking level, generate a collaborative defense action request, and drive each level of defense nodes to perform threat blocking. The execution verification module is used to obtain the blocking execution results and send them back to the analysis node for verification. When it is found that the target blocking domain has not completely contained the spread of the attack, the blocking level will be upgraded step by step and the execution will be re-driven.

[0106] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

Claims

1. A multi-level collaborative threat defense method for power monitoring based on situational assessment, characterized in that, Includes the following steps: Acquire local security data from defense nodes at each level of the power monitoring system; Based on a preset threat object ontology model, the local security data is mapped into standardized threat object instances and broadcast among the defense nodes at each level. Threat assessment is performed based on standardized threat object instances generated by the defense nodes at this level and standardized threat object instances broadcast by defense nodes at adjacent levels, and assessment conclusions are obtained. The assessment conclusions include an impact surface topology coverage description and an attack spread trend prediction value. Based on the influence surface topology coverage description, service-level candidate blocking domains, host-level candidate blocking domains, and region-level candidate blocking domains are generated. Based on the attack propagation trend prediction value, the effectiveness of the stop-loss blocking domains, the host-level candidate blocking domains, and the region-level candidate blocking domains is verified to obtain multiple effective stop-loss blocking domains. Based on the business importance level of the normal business interrupted by the multiple effective stop-loss blocking domains, the target blocking domain with the lowest business impact cost is determined, and the target blocking domain is mapped to the corresponding blocking level; Based on the blocking hierarchy, a collaborative defense action request is generated, driving each level of defense node to perform threat blocking.

2. The multi-level threat collaborative defense method for power monitoring based on situational assessment as described in claim 1, characterized in that, The preset threat object ontology model includes a physical layer, an asset layer, a behavioral layer, and a threat layer; The process of mapping the local security data into standardized threat object instances based on a preset threat object ontology model includes: The local security data is parsed into a structured event stream; Based on a preset ontology dictionary, the structured event stream is mapped to object instances having the physical layer, the asset layer, the behavior layer, and the threat layer, thus obtaining the standardized threat object instance; The standardized threat object instance is encoded using TLV encoding, which includes a parent object reference field. The parent object reference field is used to characterize the cross-layer attribution reference chain between the threat layer, the behavior layer, the asset layer, and the physical layer.

3. The multi-level threat collaborative defense method for power monitoring based on situational assessment as described in claim 1, characterized in that, The assessment conclusion also includes a set of affected service points; the generation of service-level candidate blocking domains, host-level candidate blocking domains, and region-level candidate blocking domains based on the impact surface topology coverage description includes: Based on the logical connection relationships resolved by the defense nodes at each level, a full network logical topology diagram is pre-constructed. The full network logical topology diagram includes business nodes, host nodes, and regional nodes, as well as connection edges that represent the affiliation relationships and data flow dependencies between the business nodes, host nodes, and regional nodes. Using the business nodes within the affected business point set as the seed node set, and traversing along the connecting edges based on preset traversal rules, a minimum connected subgraph containing all affected nodes is obtained, which serves as the topological coverage description of the affected surface. Based on the service node set, host node set, and region node set in the minimum connected subgraph, the service-level candidate blocking domain, the host-level candidate blocking domain, and the region-level candidate blocking domain are obtained.

4. The multi-level threat collaborative defense method for power monitoring based on situational assessment as described in claim 3, characterized in that, The assessment conclusions also include attack phase labels; The steps for verifying the effectiveness of the stop-loss order include: Based on a preset attack phase and diffusion direction mapping table, the diffusion direction of the attack on the entire network logical topology is determined according to the attack phase label. Based on the diffusion direction, traverse one hop along the connecting edge of the entire network logical topology graph, and combine the diffusion probability level obtained by behavior chain reconstruction to obtain the next hop node set, which is used as the attack diffusion trend prediction value. The business-level candidate blocking domain, the host-level candidate blocking domain, and the region-level candidate blocking domain are compared with the next-hop node set, and the candidate blocking domain containing all the next-hop node sets is determined as the effective stop-loss blocking domain.

5. The multi-level threat collaborative defense method for power monitoring based on situational assessment as described in claim 1, characterized in that, The step of determining the target blocking domain with the minimum business impact cost based on the business importance level of the normal business interrupted by multiple effective stop-loss blocking domains includes: Based on a preset mapping table between business types and business importance levels, the business importance level of the normal business interrupted by each of the multiple effective loss prevention and blocking domains is determined. When multiple effective stop-loss blocking domains have the same highest service importance level, the effective stop-loss blocking domain with the fewest normal service items under the highest service importance level is taken as the target blocking domain. The mapping table between business type and business importance level is configured with multiple levels according to the operation mode of the power monitoring system, and is dynamically loaded according to the operation mode switching command.

6. The multi-level threat collaborative defense method for power monitoring based on situational assessment as described in claim 1, characterized in that, Also includes: Deploy blocking granularity adaptive decision modules at each level of defense nodes, and configure the blocking level that each granularity adaptive decision module can decide autonomously according to the preset responsibility mapping relationship between the deployment level and the blocking level; Based on the global attack event identifier to which the standardized threat object instances generated at each level of the same attack event belong, the target blocking domains of multiple blocking granularity adaptive decision modules for the same attack event are identified. When multiple target blocking domains have an inclusion or overlap relationship, the final blocking domain is obtained according to the preset resolution priority rule, and the defense nodes at each level are driven to perform threat blocking according to the final blocking domain. The preset resolution priority rule includes adopting the target blocking domain with a smaller scope when one target blocking domain is contained by another target blocking domain.

7. The multi-level threat collaborative defense method for power monitoring based on situational assessment as described in claim 1, characterized in that, After driving the defense nodes at each level to perform threat blocking, the process also includes: obtaining the blocking execution result and sending it back to the analysis node for verification; if it is found that the target blocking domain has not completely contained the spread of the attack, the blocking level will be upgraded step by step and the execution will be re-driven.

8. The multi-level threat collaborative defense method for power monitoring based on situational assessment as described in claim 1, characterized in that, Based on the aforementioned blocking hierarchy, a collaborative defense action request is generated, driving each level of defense node to perform threat blocking, including: Based on a preset collaborative defense action protocol, atomic actions are selected from a preset atomic action set according to the blocking level to generate the collaborative defense action request. The atomic actions in the preset atomic action set have preset mapping relationships with the service level, host level and region level. Based on the attack phase label and confidence level in the assessment conclusion, a collaborative execution channel is selected, which includes an emergency rapid channel and a three-stage negotiation channel. Based on the collaborative execution channel, the collaborative defense action request is issued, driving the defense nodes at each level to perform threat blocking.

9. The multi-level threat collaborative defense method for power monitoring based on situational assessment as described in claim 7, characterized in that, The blocking execution results are obtained and sent back to the analysis node for verification. If it is found that the target blocking domain has not completely contained the spread of the attack, the blocking level is upgraded step by step and the execution is re-driven, including: Obtain the blocking execution results of each level of defense nodes, encode the blocking execution results into standardized threat object instances based on the preset threat object ontology model, and send them back to the level defense nodes that perform threat assessment; Based on the blocking execution result, verify whether the target blocking domain contains nodes that are still spreading after the threat has been blocked; If the target blocking domain does not contain any nodes that are still spreading after the threat has been blocked, the blocking level is upgraded by one level, and the collaborative defense action request is regenerated to drive the defense nodes at each level to perform threat blocking.

10. A multi-level threat collaborative defense system for power monitoring based on situational assessment, characterized in that, The method for multi-level threat collaborative defense based on situational assessment in power monitoring, as described in any one of claims 1 to 9, includes: The data acquisition and mapping module is used to acquire local security data of each level of defense nodes in the power monitoring system; based on a preset threat object ontology model, the local security data is mapped into standardized threat object instances and broadcast among the defense nodes at each level; The threat assessment module is used to perform threat assessment based on the standardized threat object instances generated by the defense nodes at this level and the standardized threat object instances broadcast by the defense nodes at adjacent levels, and to obtain assessment conclusions, which include an impact surface topology coverage description and an attack spread trend prediction value. The candidate domain generation module is used to generate service-level candidate blocking domains, host-level candidate blocking domains, and region-level candidate blocking domains based on the influence surface topology coverage description. The validity verification module is used to perform loss prevention validity verification on the service-level candidate blocking domain, the host-level candidate blocking domain, and the region-level candidate blocking domain based on the attack spread trend prediction value, and obtain multiple valid loss prevention blocking domains; The decision mapping module is used to determine the target blocking domain with the least business impact cost based on the business importance level of the normal business interrupted by the multiple effective stop-loss blocking domains, and to map the target blocking domain to the corresponding blocking level. The collaborative defense execution module is used to determine the list of objects to be blocked based on the target blocking domain, select the corresponding atomic actions according to the blocking level, generate a collaborative defense action request, and drive the defense nodes at each level to perform threat blocking. The execution verification module is used to obtain the blocking execution results and send them back to the analysis node for verification. When it is found that the target blocking domain has not completely contained the spread of the attack, the blocking level will be upgraded step by step and the execution will be re-driven.

Images