Dynamic arrangement method for distributed risk detection tasks in microgrid isolation environment

Abstract

The invention relates to the technical field of intelligent power grid network security, in particular to a dynamic arrangement method for distributed risk detection tasks in a micro-grid isolation environment, which comprises the following steps: modules are decoupled, and a risk detection function is divided into an asset identification module, a vulnerability scanning module, a baseline inspection module, a task scheduling module, a data transmission module and a result aggregation module; according to the invention, data islands isolated by a micro-grid are broken, centralized analysis of cross-regional detection results is realized, the headquarters can generate a global risk view within 10 minutes, the efficiency is improved by 144 times compared with that of traditional manual summarization, the CPU utilization rate is improved from 30% to 80% by means of containerization execution of single PoC + single target, the memory utilization rate is improved from 25% to 75%, and the cost is reduced. And the hardware purchase cost is reduced by 60%.

Description

Technical Field

[0001] This invention relates to the field of smart grid network security technology, and in particular to a dynamic orchestration method for distributed risk detection tasks in a microgrid isolated environment. Background Technology

[0002] In microgrid-isolated environments, different regions (such as headquarters and branch offices, production areas and testing areas) are physically or logically isolated via networks, making it impossible to deploy traditional centralized risk detection systems across regions. Independent detection in each region creates "data silos," making it difficult for headquarters to obtain a comprehensive risk view and resulting in delays in vulnerability discovery. For example, in a provincial power dispatch center, the production and testing areas are strictly isolated by firewalls. Traditional scanning tools need to be deployed separately in both areas, and detection results require manual aggregation, leading to cross-regional vulnerability correlation analysis taking more than 24 hours.

[0003] Traditional risk detection systems employ a "whole-machine deployment" model, where one scanning device corresponds to one isolation area. Device resources (CPU, memory) are not allocated according to task granularity, leading to resource waste. For example, a survey unit's scanning devices typically operate at only 30% load, but when adding new isolation areas, it still needs to purchase devices with equivalent configurations, increasing hardware costs. Furthermore, the device-level deployment model is difficult to scale flexibly; when the number of areas increases from 10 to 50, communication links between management nodes and scanning devices become congested, resulting in task delivery delays exceeding 10 minutes.

[0004] Existing distributed scanning technologies mostly employ static task allocation strategies (such as dividing tasks evenly by IP segment), failing to consider the differences in business load across different regions. For example, during peak electricity consumption periods (8:00-22:00), the production area experiences heavy business activity. If scanning tasks are allocated according to a fixed strategy, server CPU utilization may surge from 50% to 90%, causing SCADA system response delays. Furthermore, emergency tasks (such as zero-day vulnerability responses) cannot prioritize resource allocation and must wait for regular tasks to complete before execution, resulting in response times exceeding 4 hours, far exceeding the power industry's "15-minute emergency response" requirement.

[0005] The independent configuration of scanning policies (such as vulnerability database version and scan depth) in each isolated region leads to inconsistent detection results for the same asset in different regions. For example, a server deployed across regions may be detected as having a "weak password vulnerability" in the production region, but may be missed in the testing region because the weak password detection plugin is not enabled, which can mislead risk assessments.

[0006] In traditional distributed systems, the failure of a single scanning node can cause the detection tasks in the corresponding area to be interrupted, and there is no automatic recovery mechanism. For example, if a scanning node in a branch office goes offline due to a hard drive failure, vulnerability detection in that area is interrupted for 3 days, during which no trace of ransomware intrusion is found, ultimately leading to business disruption.

[0007] Some existing distributed scanning solutions (such as Tenable.io) attempt to solve cross-regional issues through cloud management, but they are not optimized for the microgrid isolation characteristics of power monitoring systems: First, they do not adopt containerized lightweight deployment, making them unable to adapt to the limited resources of isolated areas (e.g., some production area servers only support 2C4G configuration); second, task scheduling does not take into account the power business load characteristics, posing a risk of business interference; and third, they lack vulnerability detection plugins for power-specific protocols (such as IEC61850), resulting in insufficient coverage. Summary of the Invention

[0008] In view of the problems existing in the prior art, the present invention is proposed.

[0009] To address the aforementioned technical problems, this invention provides the following technical solution: a dynamic orchestration method for distributed risk detection tasks in a microgrid isolation environment, comprising,

[0010] The modules are decoupled, and the risk detection function is broken down into an asset identification module, a vulnerability scanning module, a baseline check module, a task scheduling module, a data transmission module, and a result aggregation module. Each module communicates through a standardized interface.

[0011] Containerized execution: The smallest detection task unit is encapsulated into a container of "single PoC plugin + single target" using containerization technology. Each container is adapted to the hardware resources of the microgrid isolation area according to the preset resource configuration.

[0012] Dynamic scheduling: The task scheduling module allocates tasks to each engine node and monitors their execution status based on multi-dimensional characteristics such as regional load, business priority, asset correlation and network quality, and supports dynamic task migration.

[0013] Centralized management and control are achieved through a distributed architecture of "first-level management node + N engine nodes". The management node uniformly maintains the vulnerability knowledge base and scanning strategy, while the engine nodes are deployed in various isolated areas to perform detection tasks. The detection data is encrypted and transmitted before being aggregated and analyzed by the result aggregation module.

[0014] As a preferred embodiment of the dynamic orchestration method for distributed risk detection tasks in a microgrid isolation environment described in this invention, the module decoupling step includes: the asset identification module outputting asset information including IP, operating system, and service version, integrating host fingerprinting, domain name discovery, and passive traffic analysis functions; the vulnerability scanning module loading a PoC plugin to perform vulnerability verification, outputting vulnerability location and severity level; the baseline check module detecting system configuration compliance based on a security level protection template or CIS template, outputting non-compliant items; and each module communicating via RESTAPI or RabbitMQ message queue, ensuring that module upgrades do not affect the operation of other modules.

[0015] As a preferred embodiment of the dynamic orchestration method for distributed risk detection tasks in a microgrid isolation environment as described in this invention, the containerization execution step adopts Docker containerization technology, each container is configured with 2C4G resources, only loads the corresponding PoC plugin and performs detection on the specified port of the target IP, and is automatically destroyed to release resources after the task is completed.

[0016] As a preferred embodiment of the dynamic orchestration method for distributed risk detection tasks in a microgrid isolation environment described in this invention, the containerized execution step further includes a container lifecycle management strategy.

[0017] Dynamic creation: The task scheduling module automatically creates a corresponding number of containers based on the target quantity;

[0018] Release: Destroy the container within 30 seconds of task completion;

[0019] Hot standby upgrade: When the PoC plugin is updated, the new container loads the new version of the plugin, and the old container is destroyed after completing the current task.

[0020] As a preferred embodiment of the dynamic orchestration method for distributed risk detection tasks in a microgrid isolation environment as described in this invention, the dynamic scheduling step includes the following multi-dimensional features: Regional load dimension: real-time acquisition engine node CPU utilization (threshold ≤ 70%), memory usage (threshold ≤ 80%), and network bandwidth (production area ≤ 5Mbps), prioritizing task allocation to low-load nodes; Business priority dimension: tasks are divided into emergency tasks (priority 10), regular tasks (priority 5), and low-priority tasks (priority 3), with high-priority tasks able to preempt low-priority task resources; Asset association dimension: assets in the same business chain are bound to the same engine node for detection; Network quality dimension: tasks are prioritized for allocation to nodes with an ICMP round-trip time (RTT) < 100ms with the target.

[0021] As a preferred embodiment of the dynamic orchestration method for distributed risk detection tasks in a microgrid isolation environment as described in this invention, the algorithm flow of the dynamic scheduling step includes: the management node receiving task requests and splitting them into "PoC+IP" units; calling the load interface of each engine node to obtain real-time status; calculating node scores according to priority, load, and network quality weight (4:3:3), with the node with the highest score being assigned the most tasks; re-evaluating node status every 5 minutes during task execution and dynamically migrating overloaded node tasks.

[0022] As a preferred embodiment of the dynamic orchestration method for distributed risk detection tasks in a microgrid isolation environment described in this invention, in the centralized management step, the management node is deployed in the headquarters security management area, and its functions include uniformly maintaining a vulnerability knowledge base (including power dedicated protocol vulnerabilities) and scanning strategy templates, issuing tasks through the gRPC interface, receiving detection logs and generating a global risk report, monitoring the status of engine nodes and automatically migrating tasks when nodes are offline; the engine node is deployed in each microgrid isolation area, and its functions include receiving tasks and creating container execution units, locally caching asset fingerprint databases, and reporting execution progress and anomaly alarms in real time.

[0023] As a preferred embodiment of the dynamic orchestration method for distributed risk detection tasks in a microgrid-isolated environment described in this invention, the method further includes: a detection standard consistency guarantee mechanism; strategy synchronization: the management node pushes a unified scanning strategy to all engine nodes, and the engine nodes are not allowed to modify it without authorization; version control: the PoC plugin and asset fingerprint database versions are uniformly controlled by the management node and are pushed in a "pilot first, then full" manner; result verification: the detection results of cross-regional assets with the same source are hashed and compared, and automatic re-detection is performed when the difference rate exceeds 5%.

[0024] As a preferred embodiment of the dynamic orchestration method for distributed risk detection tasks in a microgrid isolation environment described in this invention, the data transmission module uses the TLS1.3 encryption protocol to transmit detection data across regions, only opens the UDP 5000 port, and uses the national cryptographic SM4 algorithm for data encryption.

[0025] As a preferred embodiment of the dynamic orchestration method for distributed risk detection tasks in a microgrid isolation environment described in this invention, the specific process, when applied to cross-isolation area vulnerability scanning in a power monitoring system, includes: task creation and parameter configuration: the administrator configures the target scope, detection type, task priority, time window, and concurrency limit through a web interface; task splitting and containerization: the management node splits the target scope into multiple "PoC+IP" container units; dynamic task allocation: the score is calculated based on the load of each regional engine node and container tasks are allocated; container execution and status feedback: the engine node creates containers to execute detection, reports progress and results in real time, and the containers are automatically destroyed after the task is completed; result aggregation and report generation: the detection results of each region are summarized, and a report containing asset ownership, vulnerability details, and remediation suggestions is generated by associating with the asset fingerprint database and pushed to the OA system.

[0026] The beneficial effects of this invention are: This invention breaks down the data silos of microgrid isolation, realizes centralized analysis of cross-regional detection results, and enables the headquarters to generate a global risk view within 10 minutes, which is 144 times more efficient than traditional manual summarization. The containerized execution of "single PoC + single target" increases CPU utilization from 30% to 80%, memory utilization from 25% to 75%, and reduces hardware procurement costs by 60%. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein:

[0028] Figure 1 This is a schematic diagram of the overall structure of the present invention. Detailed Implementation

[0029] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0030] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0031] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0032] In terms of module decoupling, the risk detection function is broken down into six independent service modules. Each module achieves cross-regional collaboration through standardized interfaces. In particular, the asset identification module, based on "asset discovery and identification" technology, integrates host fingerprinting, domain name discovery, and passive traffic analysis functions.

[0033] Host fingerprinting collects the target host's TTL value, port response characteristics, and operating system-specific service identifiers (such as Windows' NetBIOS service and Linux's SSH version) by sending specific probe packets (such as TCPSYN packets and ICMP echo requests), generating asset information that includes IP address, operating system type and version, and service type and version.

[0034] Domain discovery associates domain names with IP addresses by resolving DNS records (A records, AAAA records, CNAME records) and performing reverse DNS lookups; passive traffic analysis supplements the service characteristics of assets (such as web server type and certificate-bound domains) by monitoring network traffic within the region (e.g., HTTP request headers, SSL certificate information), and outputs the data in a JSON structure containing the following fields:

[0035] {IP:"xxxx",OS:"WindowsServer2016",Service:"Apache / 2.4.41",Port:80}.

[0036] The vulnerability scanning module is compatible with general vulnerability detection capabilities. It performs vulnerability verification by loading the PoC (ProofofConcept) plugin. The PoC plugin is written in Python script and follows a unified interface specification (including the check() method for vulnerability detection and the info() method to return vulnerability information).

[0037] Supported vulnerability types include system service vulnerabilities (such as MS17-010), general web vulnerabilities (such as SQL injection and XSS), and power-specific protocol vulnerabilities (such as the unauthorized access vulnerability of the IEC61850MMS protocol). During execution, based on the service version output by the asset identification module (such as "Apache / 2.4.41"), the corresponding PoC plugin (such as the Apache directory traversal vulnerability plugin) is automatically matched. By sending a crafted malicious request (such as an HTTP request containing a specific path), the existence of a vulnerability is determined based on the response result. The vulnerability details are output in JSON structure, containing the fields: {IP:"xxxx",Vulnerability:"Apache directory traversal",Severity:"High",Location:"port 80",PoC:"apache-traversal-v1.0"}.

[0038] The baseline inspection module, based on the Level 3 / Level 2 Information Security Protection template and the CIS (Center for Internet Security) template, detects system configuration compliance.

[0039] The built-in templates include operating system configuration items (such as password complexity and login failure lockout policies), network configuration items (such as firewall rules and port opening policies), and application configuration items (such as database auditing switches and web server security header configurations).

[0040] The target configuration can be read remotely via SSH protocol (for Linux) or WMI protocol (for Windows), or the configuration can be collected locally via Agent plugin and compared with the compliance threshold in the template.

[0041] The non-compliant output is {IP:"xxxx",Item:"Password validity period",Actual:"90 days",Expected:"≤60 days",Standard:"Level 3 Information Security Protection"}.

[0042] The task scheduling module, as the core control module, receives instructions from the management node, assigns tasks to container units, and monitors the execution status.

[0043] Receive task instructions (including target range, detection type, priority, etc.) from the management node via the gRPC interface; maintain the task execution status table (database table structure:

[0044] task_id, container_id, target_ip, status [pending / running / completed / failed], progress); when the container execution times out (default 300 seconds) or exits abnormally (return code non-zero), a retry mechanism is triggered (maximum 3 retries).

[0045] The data transmission module uses an encrypted protocol to transmit detection data across regions, ensuring data security.

[0046] The transport protocol is TLS 1.3, supporting the forward secrecy (FS) feature to prevent the decryption of historical data due to key leakage; only UDP port 5000 is open for data transmission to reduce the port exposure surface; data is transmitted in fragments, each fragment being ≤1KB in size, and the fragment header contains a checksum (CRC32) to ensure data integrity.

[0047] The results aggregation module will summarize the detection results from each region and link them to the asset fingerprint database to achieve risk rating:

[0048] Association logic: matching asset information (such as department of ownership, asset importance level) output by the IP asset identification module;

[0049] The risk rating adopts a weighted scoring method, with the following weights: vulnerability severity level (60%), asset importance (30%), vulnerability exploitability (10%). The final rating is divided into four levels: "Critical", "High", "Medium" and "Low".

[0050] The output aggregation results are structured data, which supports integration with third-party systems (such as SIEM and OA).

[0051] Each module communicates via REST API (synchronous communication, such as the asset identification module providing asset information to the vulnerability scanning module) or RabbitMQ message queue (asynchronous communication, such as the task scheduling module sending execution instructions to the container). When a module is upgraded, only its own code and interface documentation need to be updated, without affecting the normal operation of other modules.

[0052] Specifically, using Docker containerization technology, the smallest detection task unit is encapsulated as a container of "single PoC plugin + single target (Url / IP)", as implemented below:

[0053] Each container is configured with "2C4G" (2 CPU cores, 4GB memory) to accommodate the limited hardware resources of micronet isolation areas (e.g., some production area servers only support 2C4G configuration):

[0054] CPU limit: Limit CPU usage using Docker's --cpus=2 parameter to avoid consuming too many host node resources;

[0055] Memory limit: Limit memory usage using the --memory=4g --memory-swap=4g parameters to prevent node crashes caused by memory leaks;

[0056] Storage limitations: Temporary storage (--tmpfs) is used, and data is automatically cleared after the container is destroyed to avoid leaving sensitive information.

[0057] The base image uses AlpineLinux (lightweight, image size ≤100MB), and integrates the Python 3 runtime environment and necessary dependencies (such as requests and paramiko libraries);

[0058] For different PoC plugins, build dedicated images (such as apache-poc:v2.1 which includes the Apache vulnerability detection plugin), and the image tag includes the version number to support version tracking;

[0059] The image repository is deployed locally in each isolated region to avoid network latency caused by pulling images across regions.

[0060] Dynamic creation: The task scheduling module automatically calculates the required number of containers based on the number of targets (1 target corresponds to 1 container), and creates the container through the Docker API (POST / containers / create). The startup command is python / poc / [plugin name].py --target[IP:port];

[0061] Release execution: After the task is completed (status code 0 is returned), the container is destroyed within 30 seconds using the dockerrm -f [container ID] command, releasing CPU and memory resources; Hot standby upgrade: When the PoC plugin is updated, the management node pushes the new version image to each regional repository, and the new container loads the new version plugin to execute the task; the old container is automatically destroyed after completing the current task, without the need for manual stopping, achieving seamless upgrade.

[0062] The task scheduling module achieves intelligent allocation based on multi-dimensional features, balancing efficiency and business security, as detailed below:

[0063] Real-time data collection of engine node CPU utilization (collected via the ps command or Prometheusexporter, sampling frequency 5 seconds / time), memory usage (collected via the free command), and network bandwidth (collected via the iftop tool for outbound bandwidth of production nodes).

[0064] Set thresholds: CPU utilization ≤ 70%, memory usage ≤ 80%, production area network bandwidth ≤ 5Mbps. If the thresholds are exceeded, the system will be marked as "overloaded" and new task assignments will be suspended.

[0065] Task priorities are quantified as numerical values ​​(10 for emergency tasks, 5 for regular tasks, and 3 for low-priority tasks) and stored in the task attribute field. High-priority tasks can preempt low-priority task resources: when an emergency task arrives, the scheduling module sends a SIGTERM signal to the low-priority task container, causing it to terminate and release resources within 30 seconds. The released resources are then allocated to the emergency task first.

[0066] Based on a pre-defined business chain relationship table (such as "database server → application server → terminal"), assets in the same business chain are bound to the same engine node through IP matching;

[0067] The business chain relationship table supports dynamic updates (configured by administrators via a web interface) to ensure real-time matching of associations. Network quality between nodes and targets is assessed by sending ICMP echo requests (ping commands), and the average RTT (Round-Trip Time) is calculated (sampled 10 times, with the maximum and minimum values ​​removed before averaging). Tasks are prioritized for nodes with RTT < 100ms, while nodes with RTT ≥ 500ms are marked as having "poor network quality" and are not assigned tasks.

[0068] Step 1: The management node receives the task request (e.g., "scan for system service vulnerabilities in the 10.0.0.0 / 24 network segment") and parses the request parameters (target scope, detection type, priority);

[0069] Step 2: Split the task into "single target + single PoC", such as 1000 targets corresponding to 1000 task units (each unit contains the target IP and the corresponding PoC plugin name);

[0070] Step 3: Call the load interface (GET / node / status) of each engine node to obtain real-time status data (CPU, memory, bandwidth, RTT);

[0071] Step 4: Calculate node scores by weight: Priority Matching (40%), Load Coefficient (30%, the lower the load, the higher the score), and Network Quality Coefficient (30%, the lower the RTT, the higher the score). The formula is: Score = Priority Matching × 0.4 + Load Coefficient × 0.3 + Network Quality Coefficient × 0.3;

[0072] Step 5: Assign tasks according to the scores from high to low, and assign the most tasks to the node with the highest score (assignment ratio = node score / total score of all nodes);

[0073] Step 6: During task execution, the node status is reassessed every 5 minutes. If the load of a node exceeds the threshold (e.g., CPU utilization ≥ 80%), the unfinished tasks are migrated to other low-load nodes (the container state is saved via Dockercommit and execution is resumed on the target node).

[0074] A distributed architecture of "first-level management node + N engine nodes" is adopted to separate global control from regional execution, as detailed below:

[0075] Deployed in the headquarters security management area, the hardware configuration consists of one physical server (8 cores and 16 gigabytes), running the following services: Task scheduling service: developed using Golang, based on the gRPC framework to communicate with the engine node, supporting task creation, pausing, termination, and querying; Policy management service: developed using the Python + Django framework, providing a web management interface, supporting the configuration and distribution of scanning policies (vulnerability level thresholds, detection port ranges);

[0076] Data storage service: PostgreSQL14 is used to store task configuration (task_config table), asset information (asset_info table), and detection results (detection_result table), and data backup is achieved through master-slave replication;

[0077] Log analysis service: Uses ElasticSearch 7.14 to store detection logs, supports searching by time, region, vulnerability type and other dimensions, and integrates Kibana to achieve visualization analysis.

[0078] A unified vulnerability knowledge base is maintained, including vulnerability ID (CVE number), severity level, scope of impact, and remediation recommendations, and is updated monthly.

[0079] It supports scheduled tasks (configured via Cron expressions, such as "03**1" indicating execution at 3 AM every Monday) and recurring tasks (such as "* / 2***" indicating execution every 2 hours);

[0080] Monitor engine node status (online / offline, load). If a node remains offline for more than 30 seconds, automatically migrate its unfinished tasks to a backup node (the backup node is another engine node in the same region, selected based on load score).

[0081] Each microgrid isolation zone deploys 1-3 engine nodes (hardware configuration 4C8G), running DockerEngine (version 20.10.0+). Specific configurations are as follows: Production zone nodes: single node concurrency limit of 50 containers (configured via DockerDaemon --max-concurrent-downloads=50) to reduce interference with business systems; Test zone nodes: single node concurrency limit of 100 containers to improve testing efficiency.

[0082] The local cached asset fingerprint database (using Redis for storage, with a cache validity of 24 hours) prioritizes matching the local database during detection. If no match is found, the database is updated by requesting the management node via the data transmission module. During execution, the progress (e.g., "30% complete") is reported to the management node every 30 seconds via gRPC. If an anomaly occurs (e.g., no response from the target, or an error in plugin execution), an alarm is immediately triggered (sent to the management node via SNMPTrap).

[0083] Data transmission is encrypted using the national cryptographic algorithm SM4 (128-bit block length, 128-bit key length), which complies with the "Basic Requirements for Information Security Level Protection in the Power Industry".

[0084] Before tunnel construction, certificate authentication (using a digital certificate based on the national cryptographic algorithm SM2) is performed to prevent man-in-the-middle attacks.

[0085] Real-time monitoring of communication link status (sending heartbeat packets every 10 seconds), automatic reconnection after disconnection (maximum 5 retries, 10-second interval).

[0086] The management node pushes a unified scanning policy to all engine nodes via the POST / policy / sync interface. The policy content includes:

[0087] Vulnerability level thresholds (e.g., only detecting "High" and above vulnerabilities); detection port range (e.g., only detecting ports 1-1024 in the production area, and ports 1-65535 in the test area); scan rate limits (e.g., ≤10 probe packets per second in the production area). After receiving the data, the engine node stores it in a local configuration file ( / etc / policy.json) and uses file permission control (only root user can read and write) to prevent unauthorized modification. The management node checks the policy consistency every hour; if inconsistent, it forces synchronization.

[0088] Version numbers are formatted as "major version, minor version" (e.g., v2.1). Major version updates indicate significant feature changes, while minor version updates indicate bug fixes. Upgrades use a "pilot first, then full" approach: the new version is first pushed to the test engine nodes, and after running for 24 hours without any anomalies (no plugin crashes, no false positive rate ≥5%), it is then pushed to the production nodes. Version rollback is supported: when an anomaly occurs in the new version, the management node triggers a rollback via the POST / version / rollback interface, and the engine nodes load the previous stable version.

[0089] For cross-regional assets with the same origin (such as dual network cards on the same server, with IPs belonging to the production and testing areas respectively), perform hash comparison on the detection results: perform SHA256 hash calculation on the detection results (vulnerability list, compliance items) to generate result fingerprints; calculate the difference rate: difference rate = number of results with different fingerprints / total number of results × 100%. When the difference rate exceeds 5%, automatically trigger a re-inspection (using a backup PoC plugin for verification); if the re-inspection is still inconsistent, mark it as "result abnormal" and notify the administrator for manual review.

[0090] 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 dynamic orchestration method for distributed risk detection tasks in a microgrid isolation environment, characterized in that: include, The modules are decoupled, and the risk detection function is broken down into an asset identification module, a vulnerability scanning module, a baseline check module, a task scheduling module, a data transmission module, and a result aggregation module. Each module communicates through a standardized interface. Containerized execution: The smallest detection task unit is encapsulated into a container of "single PoC plugin + single target" using containerization technology. Each container is adapted to the hardware resources of the microgrid isolation area according to the preset resource configuration. Dynamic scheduling: The task scheduling module allocates tasks to each engine node and monitors their execution status based on multi-dimensional characteristics such as regional load, business priority, asset correlation and network quality, and supports dynamic task migration. Centralized management and control are achieved through a distributed architecture of "first-level management node + N engine nodes". The management node uniformly maintains the vulnerability knowledge base and scanning strategy, while the engine nodes are deployed in various isolated areas to perform detection tasks. The detection data is encrypted and transmitted before being aggregated and analyzed by the result aggregation module.

2. The dynamic orchestration method for distributed risk detection tasks in a microgrid-isolated environment as described in claim 1, characterized in that: In the module decoupling step, the asset identification module outputs asset information including IP, operating system, and service version, and integrates host fingerprinting, domain name discovery, and passive traffic analysis functions; the vulnerability scanning module loads the PoC plugin to perform vulnerability verification and outputs the vulnerability location and severity level; the baseline check module detects system configuration compliance based on the information security template or CIS template and outputs non-compliant items; each module communicates through RESTAPI or RabbitMQ message queue, and module upgrades do not affect the operation of other modules.

3. The dynamic orchestration method for distributed risk detection tasks in a microgrid-isolated environment as described in claim 2, characterized in that: In the containerization execution step, Docker containerization technology is used. Each container is configured with 2C4G resources, loads only the corresponding PoC plugin, and performs detection on the specified port of the target IP. After the task is completed, it is automatically destroyed to release resources.

4. The dynamic orchestration method for distributed risk detection tasks in a microgrid-isolated environment as described in claim 3, characterized in that: The containerization execution steps also include container lifecycle management strategies. Dynamic creation: The task scheduling module automatically creates a corresponding number of containers based on the target quantity; Release: Destroy the container within 30 seconds of task completion; Hot standby upgrade: When the PoC plugin is updated, the new container loads the new version of the plugin, and the old container is destroyed after completing the current task.

5. The dynamic orchestration method for distributed risk detection tasks in a microgrid-isolated environment as described in claim 4, characterized in that: The dynamic scheduling steps include multi-dimensional features such as: regional load dimension: real-time collection of engine node CPU utilization (threshold ≤ 70%), memory usage (threshold ≤ 80%), and network bandwidth (production area ≤ 5Mbps), prioritizing task allocation to low-load nodes; business priority dimension: tasks are divided into emergency tasks (priority 10), regular tasks (priority 5), and low-priority tasks (priority 3), with high-priority tasks able to preempt low-priority task resources; asset association dimension: assets in the same business chain are bound to the same engine node for detection; and network quality dimension: priority is given to assigning tasks to nodes with an ICMP round-trip time (RTT) < 100ms with respect to the target.

6. The dynamic orchestration method for distributed risk detection tasks in a microgrid-isolated environment as described in claim 5, characterized in that: The algorithm flow of the dynamic scheduling step includes: the management node receives the task request and splits it into "PoC+IP" units; Get real-time status by calling the load interface of each engine node; calculate node score according to priority, load, and network quality weight (4:3:3), and assign the most tasks to the node with the highest score; The node status is reassessed every 5 minutes during task execution, and overloaded node tasks are dynamically migrated.

7. The dynamic orchestration method for distributed risk detection tasks in a microgrid-isolated environment as described in claim 6, characterized in that: In the centralized management and control step, the management node is deployed in the headquarters security management area. Its functions include uniformly maintaining the vulnerability knowledge base (including power special protocol vulnerabilities), scanning strategy templates, issuing tasks through the gRPC interface, receiving detection logs and generating global risk reports, monitoring the status of engine nodes and automatically migrating tasks when nodes are offline. Engine nodes are deployed in isolated micronet areas and their functions include receiving tasks and creating container execution units, caching asset fingerprint databases locally, and reporting execution progress and anomaly alarms in real time.

8. The dynamic orchestration method for distributed risk detection tasks in a microgrid-isolated environment as described in claim 7, characterized in that: It also includes a mechanism to ensure consistency of detection standards and policy synchronization: the management node pushes a unified scanning policy to all engine nodes, and the engine nodes are not allowed to modify it without authorization; version control: the PoC plugin and asset fingerprint database versions are uniformly controlled by the management node and are pushed in a "pilot first, then full" manner. Result verification: Hash comparison is performed on the detection results of cross-regional same-source assets, and automatic re-detection is performed when the difference rate exceeds 5%.

9. The dynamic orchestration method for distributed risk detection tasks in a microgrid-isolated environment as described in claim 8, characterized in that: The data transmission module uses the TLS1.3 encryption protocol to transmit detection data across regions, only opens the UDP 5000 port, and uses the national cryptographic SM4 algorithm for data encryption.

10. The dynamic orchestration method for distributed risk detection tasks in a microgrid isolated environment as described in claim 9, characterized in that: When applied to cross-isolation area vulnerability scanning in power monitoring systems, the specific process includes: task creation and parameter configuration: the administrator configures the target scope, detection type, task priority, time window and concurrency limit through the web interface; task splitting and containerization: the management node splits the target scope into multiple "PoC+IP" container units; dynamic task allocation: the score is calculated based on the load of each regional engine node and container tasks are allocated. Container execution and status feedback: Engine nodes create and execute containers, report progress and results in real time, and automatically destroy containers after the task is completed; Results aggregation and report generation: Summarize the detection results from various regions, associate them with the asset fingerprint database to generate a report containing asset ownership, vulnerability details and remediation suggestions, and push it to the OA system.

Images