Method for guaranteeing consistency of vulnerability detection results across micro-grid isolation regions
By leveraging the collaborative efforts of a unified strategy hub and distributed execution agents, combined with blockchain-based evidence storage and root cause analysis, the problem of inconsistent vulnerability detection results across micronet isolated areas was resolved, thereby achieving reliable global risk assessment and accurate security decision-making.
Patent Information
- Application Number
- CN202511484115.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-17
- Publication Date
- 2026-01-13
AI Technical Summary
Inconsistent vulnerability detection results across micronet isolation zones lead to unreliable overall risk assessment data, impacting security resource allocation and emergency response decisions.
By establishing a unified strategy hub to formulate standardized basic strategies for the entire domain and regionally differentiated strategies, the strategy is pushed to the distributed execution agent through an encrypted channel. Combined with a version lock mechanism, the distributed execution agent performs scanning and uploads data to the result verification engine. The results are calibrated using a 3D model and traced and calibrated through blockchain evidence storage and root cause analysis engine.
It achieves consistency in vulnerability detection results across isolated micronet regions, provides reliable data support for overall risk assessment, and ensures the accuracy of security decisions.
Smart Images

Figure CN121333686A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of smart grid network security management, and in particular to a method for ensuring the consistency of vulnerability detection results across microgrid isolation areas. Background Technology
[0002] With the development of smart grids, power monitoring systems adopt a microgrid isolation architecture with secure partitioning and horizontal isolation. This architecture divides the network into multiple physically or logically isolated areas, such as control areas, non-control areas, and management information areas. Each area achieves data isolation through firewalls and horizontal isolation devices to ensure the security and stability of power services. Vulnerability detection, as the core means of security situation awareness in power monitoring systems, needs to cover all microgrid isolation areas to provide data support for overall risk assessment and security decisions. However, there are still many technical bottlenecks in the current process of vulnerability detection across microgrid isolation areas.
[0003] The scanning strategies for each region are configured independently, lacking a unified management and synchronization mechanism, resulting in significant differences in vulnerability database updates and detection modes. Variations in regional hardware resources, network quality, and workload lead to discrepancies in scan completeness and accuracy. Furthermore, the lack of effective verification and tracing methods when results are inconsistent makes it impossible to distinguish between genuine differences and detection errors. These issues distort the overall risk view, impacting security resource allocation and emergency response decisions. Existing general-purpose vulnerability management platforms are not adapted to the characteristics of power microgrids and fail to meet the requirements. Summary of the Invention
[0004] Therefore, the technical problem that this invention aims to solve is that the risk assessment data for the entire domain is unreliable.
[0005] The above-mentioned technical problems are solved by the following technical solution: This invention proposes a method for ensuring the consistency of vulnerability detection results across micronet isolated areas, which includes, The unified strategy center formulates standardized basic strategies for the entire domain and differentiated strategies for different regions. These strategies are pushed to distributed execution agents in each micronet isolated area through encrypted channels, and a version lock mechanism is used to restrict the execution agents from modifying core strategy parameters. The distributed execution agents in each region, based on the received policy execution vulnerability scans, synchronously collect the environmental parameters and full-process execution logs of their respective regions, and upload the scan results, environmental parameters, and execution logs to the result verification engine; The result verification engine is based on a 3D model. It first determines the consistency of the same source assets and verification strategy, and then performs deviation calibration on the scanning results of different areas according to environmental parameters, and outputs the consistency detection results. The source tracing calibration mechanism writes the execution log and the hash value of the detection results into the blockchain for evidence storage, identifies the root causes of the result differences through the root cause analysis engine and generates calibration rules, and incorporates the calibration rules into the dynamic calibration library for automatic calibration of subsequent scans.
[0006] In a preferred embodiment of the method for ensuring consistency of vulnerability detection results across microgrid isolation areas described in this invention: the global standardization basic strategy includes weekly automatic synchronization of the vulnerability database with the national vulnerability database and the power industry-specific database; the mandatory plugin set includes system service vulnerability plugins, Web general vulnerability plugins and power-specific protocol vulnerability plugins; and the detection depth is divided according to the region type. The regional differentiation strategy includes controlling the region with a concurrent scan count of ≤10 and disabling brute-force plugins, and managing the region with a concurrent scan count of ≤50 and enabling brute-force plugins.
[0007] In a preferred embodiment of the vulnerability detection result consistency assurance method across micronet isolated areas described in this invention: the environmental parameters include hardware resource parameters, network quality parameters, and service load parameters; the execution log includes plugin activation status, number of probe packets sent and number of responses, and vulnerability verification steps.
[0008] In a preferred embodiment of the vulnerability detection result consistency assurance method across micronet isolation areas described in this invention: the asset homogeneity determination is achieved through an asset fingerprint database. When the matching degree of the IP, MAC, and device model of an asset is ≥90%, it is determined to be a homogeneous asset. The policy matching verification includes comparing the vulnerability database version and the enabled status of required plugins in different regions. If the core parameters are inconsistent, the policy will be resynchronized and rescanned. The environmental impact calibration includes: when the regional packet loss rate is >15%, referencing the protocol vulnerability results of low packet loss regions; when the CPU utilization is >80%, re-scanning plugin detection items that were skipped due to insufficient resources.
[0009] In a preferred embodiment of the vulnerability detection result consistency assurance method across micronet isolated regions described in this invention: the blockchain is a consortium blockchain, and the nodes of the blockchain include a unified policy hub and distributed execution agents for each region; the triggering condition of the root cause analysis engine is: the number of vulnerabilities of the same source assets deviates by ≥20% or the number of high-risk vulnerabilities differs by ≥1; the root causes of the differences identified by the root cause analysis include: policy unsynchronization, network packet loss, plugin disabling, and asset configuration differences.
[0010] In a preferred embodiment of the vulnerability detection result consistency guarantee method across micronet isolated areas described in this invention: the encrypted channel adopts the TLS 1.3 protocol; the policy synchronization cycle is: the basic policy is pushed once every 2 hours, and the regional differential parameters are pushed once every 24 hours; if the policy version of the execution agent and the unified policy center are inconsistent for more than 1 hour, an alarm is triggered and offline policy caching is enabled, and the differential assets are automatically scanned after synchronization is restored.
[0011] In a preferred embodiment of the vulnerability detection result consistency guarantee method across micronet isolated regions described in this invention: the distributed execution agent is deployed using Docker containerization, and the execution agents in all regions use the same version of the scanning engine.
[0012] In a preferred embodiment of the vulnerability detection result consistency assurance method across micronet isolated areas described in this invention: the specific scenarios for the environmental impact calibration include: when the management area misses an IEC61850 protocol vulnerability due to a packet loss rate of 18%, the calibration result of the management area is determined to be a protocol vulnerability based on the detection result of the control area and the fact that port 102 in the asset fingerprint database is always open; when the control area determines a weak password as medium-risk due to the disabling of brute-force cracking plugins, the calibration result of the control area is determined to be high-risk based on the high-risk determination of the management area and the fact that the asset is a core server.
[0013] In a preferred embodiment of the vulnerability detection result consistency guarantee method across micronet isolated areas described in this invention: the storage period of the blockchain evidence is greater than 1 year; if a blockchain node in a certain area is offline for more than 30 minutes, a multi-node consensus mechanism is activated, and the missing evidence data is automatically synchronized after the node failure is recovered.
[0014] In a preferred embodiment of the vulnerability detection result consistency assurance method across micronet isolated areas described in this invention: the update mechanism of the dynamic calibration library is as follows: the calibration rules generated by root cause analysis are written into the dynamic calibration library in real time, and the execution agent automatically calls the rules in the library during subsequent scans; if different calibration rules conflict in the judgment of the same vulnerability, the most stringent result is taken, and a manual review process is triggered.
[0015] The beneficial effects of this invention are as follows: by constructing a technical system of unified policy management, distributed execution verification, and result traceability calibration, it solves the problem of inconsistent vulnerability detection results in different isolated areas, and provides reliable data support for overall risk assessment and security decision-making. Attached Figure Description
[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings of the embodiments of the present invention will be briefly described below. Obviously, the drawings described below only relate to some embodiments of the present invention and are not intended to limit the present invention. Wherein: Figure 1 A flowchart of the present invention is shown. Detailed Implementation
[0017] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to specific embodiments and accompanying drawings.
[0018] The terminology used in this invention is that which is currently widely used in the art in consideration of the function of the invention; however, these terms may vary according to the intent of those skilled in the art, precedent, or new technology in the art. Furthermore, specific terms may be chosen by the applicant, and in such cases, their detailed meanings will be described in the detailed description of the invention. Therefore, the terms used in this specification should not be construed as simple names, but rather based on their meanings and the overall description of the invention.
[0019] Reference Figure 1 This embodiment provides a method for ensuring the consistency of vulnerability detection results across micronet isolated areas, including the following steps: S1. The unified strategy center formulates strategies and pushes them to the distributed execution agent; The unified policy hub is deployed in the provincial security management area. First, a standardized basic policy is defined for the entire domain. Then, regional differentiated policies are generated based on the business importance and resource capacity characteristics of the micronet isolated areas. The unified policy hub pushes the basic policy and differentiated policies to the distributed execution agents of each micronet isolated area through a TLS1.3 encrypted channel, and uses a version lock mechanism to restrict the distributed execution agents from modifying the core policy parameters without authorization. The standardized basic strategy for the entire domain includes automatic weekly synchronization of the national vulnerability database and the power industry-specific database to ensure that the vulnerability database version is consistent across the entire domain. It also includes a mandatory plugin set, which includes system service vulnerability plugins, general web vulnerability plugins, and power-specific protocol vulnerability plugins. All microgrid isolation areas must enable this set. The detection depth is divided according to the region type: deep verification is used in the control area, medium verification is used in the non-control area, and shallow verification is used in the management area. The regional differentiation strategy includes that the number of concurrent scans in the control area is ≤10 and brute-force plugins are disabled, while the number of concurrent scans in the management area is ≤50 and brute-force plugins are enabled.
[0020] The strategy synchronization cycle is as follows: the standardized basic strategy for the entire domain is pushed once every 2 hours, and the regional differentiated strategy is pushed once every 24 hours. If the strategy version of the distributed execution agent is inconsistent with that of the unified strategy center for more than 1 hour, an audible and visual alarm is triggered and offline strategy caching is enabled. After the network is restored and the strategy synchronization is completed, the distributed execution agent automatically identifies the different assets and re-executes the scan.
[0021] S2, Distributed execution agent performs scanning and uploads data; Each micronet isolation area deploys 1-2 distributed execution agents. The distributed execution agents scan for vulnerabilities in the assets within the area based on the received policies, and simultaneously collect environmental parameters and execution logs of the entire scanning process in real time. The scan results, environmental parameters and execution logs are then uploaded to the result verification engine. The environmental parameters specifically include hardware resource parameters, network quality parameters, and service load parameters. The hardware resource parameters are the CPU utilization and memory utilization of the servers in the region where the distributed execution agent is located, collected in real time. The network quality parameters are the packet loss rate and round-trip latency of the network in the region, collected in real time. The service load parameters are the proportion of real-time tasks collected in the control area and the proportion of resources occupied by service processes collected in the non-control area and management area.
[0022] The execution log specifically includes the plugin activation status, probe packet sending and receiving status, and vulnerability verification steps. The plugin activation status records the running status of required and optional plugins; the probe packet sending and receiving status records the type and number of probe packets sent to the target port, as well as the number of response packets received; and the vulnerability verification steps record the key operations and results during the vulnerability verification process.
[0023] The scanning engine of the distributed execution agent is strictly consistent with the policy generation service version of the unified policy hub to avoid deviations in detection results due to differences in engine version. When the distributed execution agent performs a scan, if it detects that the proportion of real-time tasks in the control area is >80%, it automatically reduces the number of concurrent scans to prevent excessive resource consumption from causing power monitoring service interruption.
[0024] S3, the result verification engine is based on the calibration results of the 3D model; The result verification engine is deployed on the provincial big data platform. It first calls the asset fingerprint database to determine the same source assets, then verifies the consistency of scanning strategies for the same source assets in different regions, and finally performs deviation calibration on the scanning results with consistent strategies but different results based on environmental parameters, and outputs the overall consistency detection results. The specific implementation method of the three-dimensional model of asset homogeneity-strategy matching degree-environmental impact degree is as follows: the asset homogeneity determination is that when the asset IPs of two regions in the asset fingerprint database are different but the MAC addresses and device models are the same, and the asset fingerprint matching degree is ≥90%, they are determined to be homogeneous assets. The policy matching verification specifically compares the vulnerability database version and the enabled status of required plugins for the same asset in different regions. If any core parameter is inconsistent, the unified policy center will be triggered to re-push the policy to the corresponding distributed execution agent, and the distributed execution agent will re-execute the scan. The environmental impact calibration specifically involves referencing the protocol vulnerability detection results from low-packet-loss regions when the regional network packet loss rate is >15%; and re-scanning plugin detection items that were skipped due to insufficient resources when the regional server CPU utilization is >80%.
[0025] The specific application scenarios for the environmental impact calibration are as follows: Scenario 1: The core server with IP address 192.168.1.10 in the control zone and IP address 10.0.1.10 in the management zone has the same origin asset. The network packet loss rate collected by the distributed execution agent in the control zone is 3%, and the IEC61850 protocol parsing vulnerability is detected. The network packet loss rate collected by the distributed execution agent in the management zone is 18%, and the vulnerability is not detected. The result verification engine refers to the detection results of the control zone and the record of port 102 being always open in the asset fingerprint database. The result of the calibration in the management zone is that the IEC61850 protocol parsing vulnerability exists. Scenario 2: Among the aforementioned servers from the same origin, the control zone, due to disabling the brute-force plugin, classifies the weak password for the Web backend as medium-risk; the management zone, with the brute-force plugin enabled, classifies the vulnerability as high-risk; the result verification engine, combined with the importance attributes of the core asset server, calibrates the control zone result as a weak password for the Web backend.
[0026] S4. The traceability calibration mechanism enables traceability and rule iteration. The source tracing and calibration mechanism first writes the policy version, execution log, environment parameters, and hash value of the calibration result into the consortium blockchain for evidence storage. When the difference in the scanning results of the same source assets meets the trigger threshold, the root cause analysis engine is started to identify the root cause of the difference and generate calibration rules. The calibration rules are then incorporated into the dynamic calibration library for subsequent automatic calibration of the distributed execution agent, forming a closed loop of policy-execution-verification-source tracing.
[0027] The root cause analysis engine is triggered when: the number of vulnerabilities in assets from the same source differs by ≥20%, or the number of high-risk vulnerabilities differs by ≥1. The root causes of the differences identified by the root cause analysis engine fall into four categories: policy synchronization issues, network environment impacts, plugin configuration restrictions, and asset configuration differences. Policy synchronization issues specifically refer to inconsistencies between the vulnerability database version and the status of required plugins in the distributed execution agent and the unified policy hub. Network environment impacts specifically refer to a regional network packet loss rate >15%, resulting in lost probe packets. Plugin configuration restrictions specifically refer to the disabling of specific plugins in some regions due to business characteristics. Asset configuration differences specifically refer to different service configurations of assets from the same source in different regions, which are genuine differences.
[0028] The specific requirements for the consortium blockchain evidence storage are as follows: the policy version, execution log, environment parameters, and hash value of calibration results are written to the consortium blockchain node in real time, with a storage period of ≥1 year; if a consortium blockchain node in a certain region is offline for more than 30 minutes, a multi-node consensus mechanism is activated, and the missing evidence storage data is automatically synchronized after the faulty node recovers.
[0029] The management mechanism of the dynamic calibration library includes an update mechanism, an application mechanism, and conflict handling. Specifically, the update mechanism involves writing the calibration rules generated by the root cause analysis engine into the dynamic calibration library in real time. Specifically, the application mechanism involves automatically calling the rules in the dynamic calibration library that match the current region and asset type when the distributed execution agent performs a scan, thereby achieving automatic calibration of the results. Specifically, when different calibration rules conflict in their determination of the same vulnerability, the most stringent result is taken, and a manual review process is triggered.
[0030] Finally, it should be noted that the methods and devices described in detail above are merely embodiments, and those skilled in the art can modify these embodiments in different ways as long as they do not depart from the scope of the present invention.
Claims
1. A method for ensuring consistency of vulnerability detection results across micronet isolated areas, characterized in that: include, The unified strategy center formulates standardized basic strategies for the entire domain and differentiated strategies for different regions. These strategies are pushed to distributed execution agents in each micronet isolated area through encrypted channels, and a version lock mechanism is used to restrict the execution agents from modifying core strategy parameters. The distributed execution agents in each region, based on the received policy execution vulnerability scans, synchronously collect the environmental parameters and full-process execution logs of their respective regions, and upload the scan results, environmental parameters, and execution logs to the result verification engine; The result verification engine is based on a 3D model. It first determines the consistency of the same source assets and verification strategy, and then performs deviation calibration on the scanning results of different areas according to environmental parameters, and outputs the consistency detection results. The source tracing calibration mechanism writes the execution log and the hash value of the detection results into the blockchain for evidence storage, identifies the root causes of the result differences through the root cause analysis engine and generates calibration rules, and incorporates the calibration rules into the dynamic calibration library for automatic calibration of subsequent scans.
2. The method for ensuring consistency of vulnerability detection results across micronet isolated areas according to claim 1, characterized in that: The comprehensive standardization strategy includes weekly automatic synchronization of the vulnerability database with the national vulnerability database and the power industry-specific database; a mandatory plugin set that includes system service vulnerability plugins, general web vulnerability plugins, and power-specific protocol vulnerability plugins; and detection depth categorized by region type. The regional differentiation strategy includes controlling the region with a concurrent scan count of ≤10 and disabling brute-force plugins, and managing the region with a concurrent scan count of ≤50 and enabling brute-force plugins.
3. The method for ensuring consistency of vulnerability detection results across micronet isolated areas according to claim 1, characterized in that: The environmental parameters include hardware resource parameters, network quality parameters, and service load parameters; the execution log includes plugin activation status, number of probe packets sent and the number of responses, and vulnerability verification steps.
4. The method for ensuring consistency of vulnerability detection results across micronet isolated areas according to claim 1, characterized in that: The asset homology determination is achieved through an asset fingerprint database. When the matching degree of the IP, MAC, and device model of an asset is ≥90%, it is determined to be a homologous asset. The policy matching verification includes comparing the vulnerability database version and the enabled status of required plugins in different regions. If the core parameters are inconsistent, the policy will be resynchronized and rescanned. The environmental impact calibration includes: when the regional packet loss rate is >15%, referencing the protocol vulnerability results of low packet loss regions; when the CPU utilization is >80%, re-scanning plugin detection items that were skipped due to insufficient resources.
5. The method for ensuring consistency of vulnerability detection results across micronet isolated areas according to claim 1, characterized in that: The blockchain is a consortium blockchain, and the nodes of the blockchain include a unified policy hub and distributed execution agents in each region; the triggering condition for the root cause analysis engine is: the number of vulnerabilities of the same source assets deviates by ≥20% or the number of high-risk vulnerabilities differs by ≥1. The root causes of discrepancies identified by the root cause analysis include: policy synchronization issues, network packet loss, disabled plugins, and asset configuration differences.
6. The method for ensuring consistency of vulnerability detection results across micronet isolated areas according to claim 1, characterized in that: The encrypted channel adopts the TLS 1.3 protocol; the policy synchronization cycle is as follows: the basic policy is pushed once every 2 hours, and the regional differential parameters are pushed once every 24 hours; if the policy version of the execution agent and the unified policy center are inconsistent for more than 1 hour, an alarm is triggered and the offline policy cache is enabled, and the differential assets are automatically scanned after the synchronization is restored.
7. The method for ensuring consistency of vulnerability detection results across micronet isolated areas according to claim 1 or 2, characterized in that: The distributed execution agent is deployed using Docker containers, and all execution agents in all regions use the same version of the scanning engine.
8. The method for ensuring consistency of vulnerability detection results across micronet isolated areas according to claim 4, characterized in that: The specific scenarios for the environmental impact calibration include: when the management area misses an IEC61850 protocol vulnerability due to an 18% packet loss rate, the calibration result of the management area is based on the detection results of the control area and the fact that port 102 in the asset fingerprint database is always open; when the control area determines a weak password as medium-risk due to disabling brute-force plugins, the calibration result of the control area is based on the high-risk determination of the management area and the fact that the asset is a core server.
9. The method for ensuring consistency of vulnerability detection results across micronet isolated areas according to claim 5, characterized in that: The storage period for the blockchain-based evidence is greater than one year; if a blockchain node in a certain area is offline for more than 30 minutes, a multi-node consensus mechanism is activated, and the missing evidence data is automatically synchronized after the node failure is resolved.
10. The method for ensuring consistency of vulnerability detection results across micronet isolated areas according to claim 5, characterized in that: The update mechanism of the dynamic calibration library is as follows: the calibration rules generated by root cause analysis are written into the dynamic calibration library in real time, and the execution agent automatically calls the rules in the library during subsequent scans; if different calibration rules conflict in their judgment of the same vulnerability, the most stringent result is taken, and a manual review process is triggered.