An information security risk early warning and cooperative defense system for resource optimization allocation in an industrial control environment

Abstract

The application discloses an information security risk early warning and cooperative defense system for resource optimization distribution in an industrial control environment, and relates to the field of information security.The application comprises a central control scheduling module, a risk early warning module, a resource optimization distribution module and a cooperative defense module, wherein the central control scheduling module is connected with the risk early warning module, the resource optimization distribution module and the cooperative defense module through industrial Ethernet bidirectional communication.The central control scheduling module is the core hub in the application, receives risk data every 100 ms, receives resource data every 200 ms and receives defense state data every 300 ms, generates control instructions based on the data, and iteratively optimizes the control instructions in the order of "risk early warning-resource optimization-cooperative defense", retries twice if no feedback is received, and re-schedules if the execution result is inconsistent, thereby meeting the triple requirements of safety, continuity and resource efficiency of key infrastructures such as power, chemical industry and intelligent manufacturing.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and more specifically, to an information security risk early warning and collaborative defense system for optimizing resource allocation in industrial control environments. Background Technology

[0002] As a core support for critical infrastructure in industries such as power, chemical, and intelligent manufacturing, industrial control systems (ICS) directly determine the continuity and reliability of industrial production through their operational stability, information security, and resource utilization efficiency. With the upgrading of industrial control environments towards networking and intelligence, on the one hand, information security risks such as malicious code injection, unauthorized access across subsystems, and production data tampering are becoming increasingly diverse and complex, requiring real-time risk warnings and cross-domain collaborative defense to ensure system security; on the other hand, computing nodes, communication bandwidth, and storage resources within industrial control environments are all limited resources and must prioritize supporting production operations.

[0003] Chinese patent CN113159615B, "Intelligent Measurement System and Method for Information Security Risks of Industrial Control Systems," proposes to divide the industrial control system into multiple independent security domains through physical partitioning and logical isolation technology, thereby achieving attack isolation between different subsystems. This solution reduces the risk of attacks spreading from a single subsystem to other subsystems after being attacked, ensuring the continuity of core production operations. However, it does not consider the dynamic changes in industrial control environment resources and adopts a fixed partition resource allocation mode. During peak production periods, when the production control subsystem needs additional computing resources to support real-time risk detection, it cannot utilize the idle computing power of the data monitoring subsystem, resulting in both resource idleness and resource shortage. Furthermore, this solution can only passively respond to attacks that have already occurred and lacks a linkage mechanism with the risk warning module, making it unable to identify potential risks in advance and resulting in insufficient defense timeliness.

[0004] Chinese patent CN116366359B discloses an intelligent collaborative self-evolving defense method and system for industrial control networks. This method collects operating parameters of industrial control equipment and constructs a machine learning early warning model to achieve real-time identification of equipment-level anomalies. Compared to traditional threshold-based early warning methods, this solution improves early warning accuracy by over 30% and shortens risk detection time to the second level, reserving a time window for defense response. However, it does not achieve collaborative defense between multiple subsystems. When a complex attack across subsystems is detected, the defense modules of each subsystem respond independently, easily leading to conflicting defense strategies. Furthermore, after the production control subsystem initiates bandwidth limiting to block attacks, early warning data from the data monitoring subsystem cannot be uploaded to the central control platform. In addition, this solution does not integrate resource optimization with the early warning model. The early warning model requires 15%–20% of the industrial control equipment's computing resources during operation, which can crowd out production instruction execution resources during high-load production periods, increasing production equipment response latency by 200–500ms and affecting production accuracy.

[0005] In summary, while the aforementioned security defense method for industrial control systems based on partitioning achieves security domain isolation to block attack spread, it suffers from fixed resource allocation and lacks risk warning linkage. Similarly, the aforementioned real-time risk warning and response method for industrial control equipment achieves real-time risk warning at the device level to shorten risk discovery time, but it lacks collaborative defense and consumes production resources. Neither method addresses the linkage issue of risk warning, resource scheduling, and collaborative defense in the industrial control environment, failing to optimize resource allocation while ensuring information security and thus failing to meet the dual requirements of critical infrastructure for system security and resource utilization.

[0006] Therefore, we have made improvements to this and proposed an information security risk early warning and collaborative defense system for optimizing resource allocation in industrial control environments. Summary of the Invention

[0007] This invention provides the following technical solutions:

[0008] The application is as follows:

[0009] An information security risk early warning and collaborative defense system for optimized resource allocation in industrial control environments includes: a central control scheduling module, a risk early warning module, a resource optimization allocation module, and a collaborative defense module. The central control scheduling module is connected to the risk early warning module, the resource optimization allocation module, and the collaborative defense module via bidirectional communication via industrial Ethernet.

[0010] The central control scheduling module has a built-in industrial control business priority database, which is used to receive the risk level output by the risk warning module, the resource occupancy rate output by the resource optimization allocation module, and the defense status output by the collaborative defense module, and to issue collaborative control commands to the risk warning module, the resource optimization allocation module and the collaborative defense module.

[0011] The risk warning module is used to collect operating parameters of industrial control equipment and output risk levels. It includes a parameter acquisition unit and a multi-dimensional warning model. The operating parameters of industrial control equipment collected by the parameter acquisition unit include CPU utilization, data frame error rate, communication bandwidth fluctuation value, and instruction execution latency. The acquisition frequency is 0.5-1 times / second. The multi-dimensional warning model is trained based on LSTM neural network and integrates four types of operating parameters to output risk levels. The risk levels are divided into low / medium / high / urgent.

[0012] The resource optimization and allocation module is used to dynamically allocate industrial control resources based on risk level and business priority. It has a built-in dynamic scheduling algorithm. The calculation logic of the dynamic scheduling algorithm is as follows: when the risk level is greater than or equal to high, the priority weight of security defense business is increased by 10% to 15%, while reserving 40% to 60% of the CPU computing power required for production business. When the risk level is less than or equal to medium, the priority weight of production business remains unchanged, and the CPU computing power occupied by security defense business is controlled at 15% to 20%.

[0013] The collaborative defense module is used to perform cross-subsystem defense operations based on resource allocation results and control commands, including a defense strategy library and a cross-domain synchronization unit; the defense strategy library stores four types of strategies: command interception, link isolation, data encryption, and interference source location; the command synchronization latency of the cross-domain synchronization unit is ≤100ms.

[0014] In the industrial control business priority database of the central control scheduling module, the baseline priority weight for production control business is 8-9, the baseline priority weight for security defense business is 9-10, and the baseline priority weight for data monitoring business is 7-8.

[0015] The parameter acquisition unit uses industrial-grade sensors and communication gateways. The acquired data is preprocessed by edge computing nodes, outliers are removed, and then uploaded to the multi-dimensional early warning model.

[0016] The industrial control resources allocated by the resource optimization and allocation module include CPU computing power, communication bandwidth, and storage capacity; among them, the communication bandwidth allocation accuracy is 1Mbps, and the storage capacity allocation accuracy is 1GB.

[0017] The specific working steps of the risk warning module are as follows:

[0018] SA1, Begin;

[0019] SA2, Initialization and Deployment Parameter Acquisition Unit;

[0020] SA2.1 Deploy industrial-grade parameter acquisition equipment: Install sensors with an accuracy of ±0.1% and a communication gateway supporting the Profinet protocol on the industrial control equipment to ensure that the physical interface between the acquisition equipment and the industrial control equipment is compatible;

[0021] SA2.2 Configure the acquisition parameters, set the acquisition frequency to 0.5-1 times / second, and set the parameter threshold. The threshold can be customized and adjusted based on the industrial control scenario.

[0022] SA2.3 Test the acquisition link, send test signals to the acquisition unit to verify the integrity of data transmission. If the loss rate exceeds the standard, check the gateway route or replace the communication cable.

[0023] SA3: Collect operating parameters of industrial control equipment;

[0024] SA3.1 Collect four types of core parameters at the set frequency;

[0025] CPU utilization: Real-time value is read through the resource monitoring interface built into the industrial control equipment;

[0026] Data frame error rate: Read the number of error frames from the "Frame Error Statistics" register of the communication gateway and calculate "Number of error frames / Total number of frames × 100%";

[0027] Communication bandwidth fluctuation value: The peak and valley values ​​of bandwidth are collected within 10 seconds using traffic monitoring tools, and the "peak value - valley value" is calculated.

[0028] Command execution delay: Record the difference between the "central control command issuance time" and the "industrial control equipment command execution completion feedback time";

[0029] SA3.2 If the acquisition of a certain parameter fails, the local cache is triggered to read the average parameter value within the last 10 seconds. At the same time, an "acquisition anomaly alarm" is sent to the central control scheduling module, and the acquisition is retried. The acquisition is retried once every 500ms, for a total of 3 times.

[0030] SA4, Preprocess the acquired data;

[0031] SA4.1 Remove outliers from the collected data. Use the 3σ principle to filter outliers. If a parameter value exceeds the range of "mean ± 3 × standard deviation", it is determined to be an outlier. Then remove the outlier and replace it with 60% of the previous value.

[0032] SA4.2 Standardize the collected data and convert the four types of parameters into standardized values ​​of 0-100 to eliminate the impact of parameter dimension differences on the model;

[0033] SA4.3. Compress the collected data. Use wavelet transform algorithm to compress the standardized time series data, retain key features, reduce the amount of data by 50%, and improve the efficiency of subsequent model calculations.

[0034] SA5, Multi-dimensional risk assessment and result output;

[0035] SA5.1 Load the pre-trained LSTM neural network model. The LSTM neural network model is trained based on 100,000 sets of industrial control security sample data. The samples include normal equipment operation data and data on common attack scenarios such as malicious code injection, link interference, and data frame tampering.

[0036] SA5.2 Input the preprocessed standardized data into the model. The model outputs the risk probability and classifies the risk level according to the probability: 0% to 20% is "low risk", 21% to 50% is "medium risk", 51% to 80% is "high risk" and 81% to 100% is "emergency risk". At the same time, the risk type is also output.

[0037] SA5.3 Package the "risk level + risk type + early warning confidence level" into a package and send it to the central control and dispatch module via industrial Ethernet. The sending frequency is consistent with the data acquisition frequency.

[0038] SA6, End.

[0039] The specific working steps of the resource optimization and allocation module are as follows:

[0040] SB1, Begin;

[0041] SB2, Real-time monitoring of resource status;

[0042] SB2.1 Establish resource monitoring links with each industrial control subsystem, including the production control subsystem, data monitoring subsystem, and security defense subsystem. Read real-time resource data from each subsystem via the SNMP protocol.

[0043] CPU computing power: Read the "number of idle cores × single-core frequency" of the CPU in the subsystem;

[0044] Communication bandwidth: Read the port traffic data of the industrial switch and calculate "total bandwidth - used bandwidth";

[0045] Storage capacity: Read the storage server's "Total capacity - Used capacity";

[0046] SB2.2 Update resource monitoring data every 150ms, generate a "Subsystem Resource Status Table", and synchronize it to the central control and scheduling module. The "Subsystem Resource Status Table" includes subsystem ID, resource type, idle amount, and used amount.

[0047] SB3, Calculate resource requirements based on dynamic scheduling algorithm;

[0048] SB3.1 Receive the "risk level + business priority weight" issued by the central control scheduling module to determine the priority of resource allocation: If the risk level is "urgent / high": security defense business priority weight = base weight × (1 + 10% ~ 15%), production business priority weight remains at the base value, and data monitoring business priority weight is reduced by 10%; If the risk level is "medium / low": production business priority weight remains at the base value, security defense business priority weight = base weight × (0.8 - 0.9), and data monitoring business is allocated according to the base weight;

[0049] SB3.2 Calculate the resource requirements of each service: CPU computing power requirement = basic computing power of the service × priority weight coefficient; communication bandwidth requirement = service data transmission rate × redundancy coefficient. The redundancy coefficient can be set based on the communication stability requirements of the industrial control scenario. The typical value range is 1.1-1.3 to ensure that burst data transmission is not lost; storage capacity requirement = log generation rate × storage duration.

[0050] SB3.3 Determine resource gap: Compare "demand" with "subsystem idle resources". If a subsystem has insufficient idle resources, it is marked as "resource gap" and cross-subsystem resource scheduling is triggered.

[0051] SB4, Perform dynamic resource allocation;

[0052] SB4.1, Generate resource allocation strategy:

[0053] No gap scenario: Directly allocate the required resources from the current subsystem's idle resources;

[0054] Scenarios with gaps: Calling idle resources from lower-priority subsystems;

[0055] SB4.2. Issue resource allocation instructions: Send resource allocation instructions to the target subsystem via the industrial bus, specifying the resource type, allocation quantity, and effective time, wherein the effective time takes effect immediately;

[0056] SB4.3 Verify the allocation result. Within 100ms after issuing the instruction, receive the "resource allocation confirmation" receipt from the subsystem. At the same time, reread the resource status of the subsystem to verify whether the allocated resource usage meets expectations. If not, recalculate and issue the instruction.

[0057] SB5. Conduct resource recycling and dynamic adjustments;

[0058] SB5.1 Trigger resource reclamation: Receive a "defense complete signal" or "risk level decrease signal" from the central control and dispatch module, and initiate resource reclamation.

[0059] SB5.2. The recycling strategy is implemented by recycling resources in the order of "low priority business first, then high priority business", and ensuring that production business resources are not lower than the baseline demand during the recycling process.

[0060] SB5.3 Dynamic adjustment: Recalculate resource requirements every 300ms. If the resource utilization rate of a certain business is lower than 50%, the excess resources will be automatically reclaimed to avoid resource waste.

[0061] SB6, End.

[0062] The specific working steps of the collaborative defense module are as follows:

[0063] SC1, Start;

[0064] SC2. Initialize and update the defense strategy library;

[0065] SC2.1 Loads four preset core defense strategies and triggering conditions, and stores them in the defense strategy library:

[0066] Command interception policy: Trigger condition "Risk type = Malicious command injection", policy content "Intercept command packets sent by abnormal IPs and record interception logs";

[0067] Link isolation policy: Trigger condition "risk level = emergency", policy content "disconnect the physical link between the attacked subsystem and other subsystems";

[0068] Data encryption policy: Trigger condition "Risk type = Link interference", policy content "Enable SSL / TLS protocol to encrypt communication data between subsystems, and update the key every 10 minutes";

[0069] Interference source location strategy: Triggering condition "Risk type = link interference and risk level ≥ medium", strategy content "Scan the workshop wireless signal with a spectrum analyzer to locate the interference source";

[0070] SC2.2 Policy Update Mechanism: The latest defense policies are synchronized from the cloud security database every month. Before updating, the policy compatibility is verified in the test environment. The old policy is replaced only after the verification is passed.

[0071] SC3, Defense Strategy Matching and Command Generation;

[0072] SC3.1 receives the "risk level + risk type + resource allocation result" issued by the central control and scheduling module, and matches the optimal strategy from the strategy library;

[0073] SC3.2 Generate defense execution command: The command includes "target subsystem ID, policy type, execution parameters, and timeout time, with a default timeout of 5 seconds".

[0074] SC4. Cross-domain policy synchronization and execution;

[0075] SC4.1 Activate the cross-domain synchronization unit and send a synchronization request to the "target subsystem + adjacent subsystem" via industrial Ethernet to establish a synchronization communication link and ensure that the synchronization delay is ≤100ms;

[0076] SC4.2 Strategy instructions are issued synchronously using a "broadcast + confirmation" mechanism. First, the defense instructions are broadcast to all target subsystems, and then confirmation receipts are received one by one. If a subsystem does not respond within 300ms, the instructions are resent. The maximum number of retries is 2. If the retry fails, it is marked as "synchronization abnormal" and an alarm is sent to the central control and scheduling module.

[0077] SC4.3 Policy Execution Monitoring: Receives the policy execution status of the subsystem in real time, updates the execution progress every 200ms, and triggers policy parameter adjustment if the execution progress is lower than expected.

[0078] SC5. Verification of defense effectiveness and feedback of results;

[0079] SC5.1, Effectiveness Verification Indicators:

[0080] Security Indicators: Attack Propagation Rate: Whether adjacent subsystems have the same risk, required to be ≤0%; Interception Success Rate: Required to be ≥90%; Risk Level Change: Whether the risk level decreases after defense, such as from high to medium.

[0081] Business metrics: Production latency, resource utilization;

[0082] SC5.2 After the defense is executed, the above indicator data is collected and compared with the preset threshold. If all indicators meet the standards, the defense is deemed "effective"; if they do not meet the standards, the "strategy upgrade" is triggered. The preset threshold is set according to the actual situation.

[0083] SC5.3 Feedback Results: Package the "defense effect + indicator data + execution log" and send it to the central control and scheduling module. At the same time, store the logs locally and back them up in the cloud for easy subsequent security auditing.

[0084] SC6. Defense strategy cancellation and system recovery;

[0085] SC6.1, Cancel Trigger: Receive the "Risk Relief Signal" issued by the central control and dispatch module, and initiate the policy cancellation process;

[0086] SC6.2 Policy revocation execution: Issue revocation commands in the order of "adjacent subsystems first - target subsystem" to ensure that each subsystem is restored to its normal configuration before defense. Verify the business status of the subsystem after revocation.

[0087] SC6.3 System recovery confirmation: Collect the "service recovery status" of the subsystem, confirm the recovery to the pre-defense level, and send a "system recovery complete" signal to the central control and scheduling module to end this defense process;

[0088] SC7, End.

[0089] The specific working steps of the central control and dispatch module are as follows:

[0090] SD1, Start;

[0091] SD2: Load the built-in industrial control business priority database, read the preset parameters, and fine-tune the weights based on the industrial control scenario; among them, the baseline priority weight for production control business is 8-9, the baseline priority weight for security defense business is 9-10, and the baseline priority weight for data monitoring business is 7-8.

[0092] SD3. Establish industrial Ethernet communication connections with the risk warning module, resource optimization and allocation module, and collaborative defense module. Complete the communication handshake through the Modbus / Profinet protocol and verify the communication latency of each module. The latency should be ≤50ms. If the latency exceeds the limit, trigger the retry mechanism. If the retry fails after 3 attempts, output a module offline alarm.

[0093] SD4. Initialize the "Command Log Storage Unit", set the log retention period and backup path to ensure that commands are traceable. The default log retention period is 30 days, and the backup path includes local server + off-site cloud backup.

[0094] SD5 receives risk level data and warning confidence level output from the risk warning module every 100ms;

[0095] SD6 receives resource usage data output by the resource optimization and allocation module every 200ms. The resource usage data includes CPU utilization, communication bandwidth utilization, and remaining storage capacity of each subsystem.

[0096] SD7 receives defense status data output by the collaborative defense module every 300ms. The defense status data includes policy execution progress, interception success rate, and subsystem synchronization status.

[0097] SD8. Determine resource and defense priorities based on risk level: If the risk level is "urgent / high", increase the priority weight of security defense business by 10% to 15%, while locking the resources required for core production business; if the risk level is "medium / low", maintain the baseline priority of production business and limit the resource consumption of security defense business.

[0098] SD9. Determine if there is a resource conflict by combining resource usage data: If the target subsystem has insufficient resources, trigger the "cross-subsystem resource scheduling instruction"; if resources are sufficient, directly generate the "defense resource allocation instruction".

[0099] SD10, Adjustment instructions based on defense status data: If the collaborative defense module reports "policy synchronization failed", generate a "retry synchronization instruction" and increase the synchronization timeout threshold; if it reports "interception success rate < 90%", trigger a "policy upgrade instruction".

[0100] SD11. Issue instructions in the order of "Risk Warning Module - Resource Optimization Allocation Module - Collaborative Defense Module". After each instruction is issued, wait 100ms to receive a confirmation receipt. If no receipt is received, reissue the instruction. The maximum number of retry attempts is 2.

[0101] SD12 receives the execution results from the risk warning module, resource optimization and allocation module, and collaborative defense module, and stores the results in association with the instruction log;

[0102] SD13. If the execution result does not meet expectations, re-enter the "data reception-instruction generation" process and iteratively optimize the instruction;

[0103] SD14, End.

[0104] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0105] 1. The risk warning module of this invention collects four types of core operating parameters at a frequency of 0.5-1 times / second. Combined with an LSTM neural network model trained on 100,000 sets of industrial control security samples, it can accurately identify common attack scenarios such as malicious code injection and link interference. Compared with traditional threshold warning methods, the warning accuracy is improved by more than 30%, and the risk detection time is shortened to the second level, avoiding the defect of "passive response after the attack has occurred". Furthermore, it removes outliers by using the 3σ principle and replaces them with 60% of the previous time, eliminates dimensional differences by 0-100 standardization, and reduces the data volume by 50% by wavelet transform compression, which ensures the accuracy of the input model data and improves the computational efficiency, adapting to the real-time requirements of the industrial control environment.

[0106] 2. This invention flexibly allocates resource priorities based on risk levels. When the risk level is high or higher, the priority weight of security defense services is increased by 10% to 15%, while reserving 40% to 60% of CPU computing power for production services. When the risk level is medium or lower, the weight of production services remains unchanged, and the CPU usage of security defense is controlled at 15% to 20%. This solves the problems of "fixed resource allocation leading to both idle and strained resources" and "early warning models crowding out production resources." Resource allocation covers CPU computing power, communication bandwidth, and storage capacity. Resource status is updated every 150ms via the SNMP protocol. Combined with the mechanisms of "scheduling idle resources across subsystems" and "automatic recycling when utilization is below 50%", resource waste rate is reduced by more than 40%, ensuring stable response latency for production services during high-load periods.

[0107] 3. The defense strategy library of this invention has 4 built-in strategies. The cross-domain synchronization unit realizes instruction synchronization through the "broadcast + confirmation" mechanism, which solves the problem of "strategy conflict caused by independent defense of multiple subsystems". The defense effect is verified by security indicators such as "attack diffusion rate ≤ 0% and interception success rate ≥ 90%" and business indicators such as production business latency and resource utilization. If the target is not met, "strategy upgrade" is triggered to ensure that the defense is effective and does not affect production continuity. The attack diffusion range is reduced to a single subsystem.

[0108] 4. The central control and scheduling module of this invention serves as the core hub, receiving risk data every 100ms, resource data every 200ms, and defense status data every 300ms. Based on the data, it dynamically generates control commands and issues them in the order of "risk warning - resource optimization - collaborative defense" and iteratively optimizes them. If no response is received, it will retry twice. If the execution result is inconsistent, it will reschedule. It is adapted to the triple requirements of "safety, continuity and resource efficiency" for key infrastructures such as power, chemical industry and intelligent manufacturing. Attached Figure Description

[0109] Figure 1 This is a schematic diagram of the overall system structure of this application;

[0110] Figure 2 This is a schematic diagram of the workflow of the risk warning module in this application;

[0111] Figure 3 This is a schematic diagram of the workflow of the resource optimization and allocation module in this application;

[0112] Figure 4 This is a schematic diagram of the collaborative defense module workflow in this application;

[0113] Figure 5 This is a schematic diagram of the workflow of the central control and scheduling module in this application;

[0114] Figure 6 This is a schematic diagram of the system collaboration workflow of this application. Detailed Implementation

[0115] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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 embodiments of the present invention, and not all embodiments.

[0116] Therefore, the following detailed description of embodiments of the present invention is not intended to limit the scope of the claimed invention, but merely illustrates some embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0117] It should be noted that, unless otherwise specified, the embodiments and features and technical solutions in the present invention can be combined with each other.

[0118] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0119] In the description of this invention, it should be noted that the terms "upper," "lower," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product of this invention is in use, or the orientation or positional relationship commonly understood by those skilled in the art. These terms are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention. In addition, the terms "first," "second," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0120] This invention provides the following technical solutions:

[0121] Please refer to Figures 1-6 An information security risk early warning and collaborative defense system for optimized resource allocation in industrial control environments includes: a central control scheduling module, a risk early warning module, a resource optimization allocation module, and a collaborative defense module. The central control scheduling module is connected to the risk early warning module, the resource optimization allocation module, and the collaborative defense module via bidirectional communication via industrial Ethernet.

[0122] The central control scheduling module has a built-in industrial control business priority database, which is used to receive the risk level output by the risk warning module, the resource occupancy rate output by the resource optimization allocation module, and the defense status output by the collaborative defense module, and to issue collaborative control commands to the risk warning module, the resource optimization allocation module and the collaborative defense module.

[0123] The risk warning module is used to collect operating parameters of industrial control equipment and output risk levels. It includes a parameter acquisition unit and a multi-dimensional warning model. The operating parameters of industrial control equipment collected by the parameter acquisition unit include CPU utilization, data frame error rate, communication bandwidth fluctuation value, and instruction execution latency. The acquisition frequency is 0.5-1 times / second. The multi-dimensional warning model is trained based on LSTM neural network and integrates four types of operating parameters to output risk levels. The risk levels are divided into low / medium / high / urgent.

[0124] The resource optimization and allocation module is used to dynamically allocate industrial control resources based on risk level and business priority. It has a built-in dynamic scheduling algorithm. The calculation logic of the dynamic scheduling algorithm is as follows: when the risk level is greater than or equal to high, the priority weight of security defense business is increased by 10% to 15%, while reserving 40% to 60% of the CPU computing power required for production business. When the risk level is less than or equal to medium, the priority weight of production business remains unchanged, and the CPU computing power occupied by security defense business is controlled at 15% to 20%.

[0125] The collaborative defense module is used to perform cross-subsystem defense operations based on resource allocation results and control commands, including a defense strategy library and a cross-domain synchronization unit; the defense strategy library stores four types of strategies: command interception, link isolation, data encryption, and interference source location; the command synchronization latency of the cross-domain synchronization unit is ≤100ms.

[0126] In the industrial control business priority database of the central control scheduling module, the baseline priority weight for production control business is 8-9, the baseline priority weight for security defense business is 9-10, and the baseline priority weight for data monitoring business is 7-8.

[0127] The parameter acquisition unit uses industrial-grade sensors and communication gateways. The acquired data is preprocessed by edge computing nodes, outliers are removed, and then uploaded to the multi-dimensional early warning model.

[0128] The industrial control resources allocated by the resource optimization and allocation module include CPU computing power, communication bandwidth, and storage capacity; among them, the communication bandwidth allocation accuracy is 1Mbps, and the storage capacity allocation accuracy is 1GB.

[0129] The specific working steps of the risk warning module are as follows:

[0130] SA1, Begin;

[0131] SA2, Initialization and Deployment Parameter Acquisition Unit;

[0132] SA2.1 Deploy industrial-grade parameter acquisition equipment: Install sensors with an accuracy of ±0.1% and a communication gateway supporting the Profinet protocol on the industrial control equipment to ensure that the physical interface between the acquisition equipment and the industrial control equipment is compatible;

[0133] SA2.2 Configure the acquisition parameters, set the acquisition frequency to 0.5-1 times / second, and set the parameter threshold. The threshold can be customized and adjusted based on the industrial control scenario.

[0134] SA2.3 Test the acquisition link, send test signals to the acquisition unit to verify the integrity of data transmission. If the loss rate exceeds the standard, check the gateway route or replace the communication cable.

[0135] SA3: Collect operating parameters of industrial control equipment;

[0136] SA3.1 Collect four types of core parameters at the set frequency;

[0137] CPU utilization: Real-time value is read through the resource monitoring interface built into the industrial control equipment;

[0138] Data frame error rate: Read the number of error frames from the "Frame Error Statistics" register of the communication gateway and calculate "Number of error frames / Total number of frames × 100%";

[0139] Communication bandwidth fluctuation value: The peak and valley values ​​of bandwidth are collected within 10 seconds using traffic monitoring tools, and the "peak value - valley value" is calculated.

[0140] Command execution delay: Record the difference between the "central control command issuance time" and the "industrial control equipment command execution completion feedback time";

[0141] SA3.2 If the acquisition of a certain parameter fails, the local cache is triggered to read the average parameter value within the last 10 seconds. At the same time, an "acquisition anomaly alarm" is sent to the central control scheduling module, and the acquisition is retried. The acquisition is retried once every 500ms, for a total of 3 times.

[0142] SA4, Preprocess the acquired data;

[0143] SA4.1 Remove outliers from the collected data. Use the 3σ principle to filter outliers. If a parameter value exceeds the range of "mean ± 3 × standard deviation", it is determined to be an outlier. Then remove the outlier and replace it with 60% of the previous value.

[0144] SA4.2 Standardize the collected data and convert the four types of parameters into standardized values ​​of 0-100 to eliminate the impact of parameter dimension differences on the model;

[0145] SA4.3. Compress the collected data. Use wavelet transform algorithm to compress the standardized time series data, retain key features, reduce the amount of data by 50%, and improve the efficiency of subsequent model calculations.

[0146] SA5, Multi-dimensional risk assessment and result output;

[0147] SA5.1 Load the pre-trained LSTM neural network model. The LSTM neural network model is trained based on 100,000 sets of industrial control security sample data. The samples include normal equipment operation data and data on common attack scenarios such as malicious code injection, link interference, and data frame tampering.

[0148] SA5.2 Input the preprocessed standardized data into the model. The model outputs the risk probability and classifies the risk level according to the probability: 0% to 20% is "low risk", 21% to 50% is "medium risk", 51% to 80% is "high risk" and 81% to 100% is "emergency risk". At the same time, the risk type is also output.

[0149] SA5.3 Package the "risk level + risk type + early warning confidence level" into a package and send it to the central control and dispatch module via industrial Ethernet. The sending frequency is consistent with the data acquisition frequency.

[0150] SA6, End.

[0151] The specific working steps of the resource optimization and allocation module are as follows:

[0152] SB1, Begin;

[0153] SB2, Real-time monitoring of resource status;

[0154] SB2.1 Establish resource monitoring links with each industrial control subsystem, including the production control subsystem, data monitoring subsystem, and security defense subsystem. Read real-time resource data from each subsystem via the SNMP protocol.

[0155] CPU computing power: Read the "number of idle cores × single-core frequency" of the CPU in the subsystem;

[0156] Communication bandwidth: Read the port traffic data of the industrial switch and calculate "total bandwidth - used bandwidth";

[0157] Storage capacity: Read the storage server's "Total capacity - Used capacity";

[0158] SB2.2 Update resource monitoring data every 150ms, generate a "Subsystem Resource Status Table", and synchronize it to the central control and scheduling module. The "Subsystem Resource Status Table" includes subsystem ID, resource type, idle amount, and used amount.

[0159] SB3, Calculate resource requirements based on dynamic scheduling algorithm;

[0160] SB3.1 Receive the "risk level + business priority weight" issued by the central control scheduling module to determine the priority of resource allocation: If the risk level is "urgent / high": security defense business priority weight = base weight × (1 + 10% ~ 15%), production business priority weight remains at the base value, and data monitoring business priority weight is reduced by 10%; If the risk level is "medium / low": production business priority weight remains at the base value, security defense business priority weight = base weight × (0.8 - 0.9), and data monitoring business is allocated according to the base weight;

[0161] SB3.2 Calculate the resource requirements of each service: CPU computing power requirement = basic computing power of the service × priority weight coefficient; communication bandwidth requirement = service data transmission rate × redundancy coefficient. The redundancy coefficient can be set based on the communication stability requirements of the industrial control scenario. The typical value range is 1.1-1.3 to ensure that burst data transmission is not lost; storage capacity requirement = log generation rate × storage duration.

[0162] SB3.3 Determine resource gap: Compare "demand" with "subsystem idle resources". If a subsystem has insufficient idle resources, it is marked as "resource gap" and cross-subsystem resource scheduling is triggered.

[0163] SB4, Perform dynamic resource allocation;

[0164] SB4.1, Generate resource allocation strategy:

[0165] No gap scenario: Directly allocate the required resources from the current subsystem's idle resources;

[0166] Scenarios with gaps: Calling idle resources from lower-priority subsystems;

[0167] SB4.2. Issue resource allocation instructions: Send resource allocation instructions to the target subsystem via the industrial bus, specifying the resource type, allocation quantity, and effective time, wherein the effective time takes effect immediately;

[0168] SB4.3 Verify the allocation result. Within 100ms after issuing the instruction, receive the "resource allocation confirmation" receipt from the subsystem. At the same time, reread the resource status of the subsystem to verify whether the allocated resource usage meets expectations. If not, recalculate and issue the instruction.

[0169] SB5. Conduct resource recycling and dynamic adjustments;

[0170] SB5.1 Trigger resource reclamation: Receive a "defense complete signal" or "risk level decrease signal" from the central control and dispatch module, and initiate resource reclamation.

[0171] SB5.2. The recycling strategy is implemented by recycling resources in the order of "low priority business first, then high priority business", and ensuring that production business resources are not lower than the baseline demand during the recycling process.

[0172] SB5.3 Dynamic adjustment: Recalculate resource requirements every 300ms. If the resource utilization rate of a certain business is lower than 50%, the excess resources will be automatically reclaimed to avoid resource waste.

[0173] SB6, End.

[0174] The specific working steps of the collaborative defense module are as follows:

[0175] SC1, Start;

[0176] SC2. Initialize and update the defense strategy library;

[0177] SC2.1 Loads four preset core defense strategies and triggering conditions, and stores them in the defense strategy library:

[0178] Command interception policy: Trigger condition "Risk type = Malicious command injection", policy content "Intercept command packets sent by abnormal IPs and record interception logs";

[0179] Link isolation policy: Trigger condition "risk level = emergency", policy content "disconnect the physical link between the attacked subsystem and other subsystems";

[0180] Data encryption policy: Trigger condition "Risk type = Link interference", policy content "Enable SSL / TLS protocol to encrypt communication data between subsystems, and update the key every 10 minutes";

[0181] Interference source location strategy: Triggering condition "Risk type = link interference and risk level ≥ medium", strategy content "Scan the workshop wireless signal with a spectrum analyzer to locate the interference source";

[0182] SC2.2 Policy Update Mechanism: The latest defense policies are synchronized from the cloud security database every month. Before updating, the policy compatibility is verified in the test environment. The old policy is replaced only after the verification is passed.

[0183] SC3, Defense Strategy Matching and Command Generation;

[0184] SC3.1 receives the "risk level + risk type + resource allocation result" issued by the central control and scheduling module, and matches the optimal strategy from the strategy library;

[0185] SC3.2 Generate defense execution command: The command includes "target subsystem ID, policy type, execution parameters, and timeout time, with a default timeout of 5 seconds".

[0186] SC4. Cross-domain policy synchronization and execution;

[0187] SC4.1 Activate the cross-domain synchronization unit and send a synchronization request to the "target subsystem + adjacent subsystem" via industrial Ethernet to establish a synchronization communication link and ensure that the synchronization delay is ≤100ms;

[0188] SC4.2 Strategy instructions are issued synchronously using a "broadcast + confirmation" mechanism. First, the defense instructions are broadcast to all target subsystems, and then confirmation receipts are received one by one. If a subsystem does not respond within 300ms, the instructions are resent. The maximum number of retries is 2. If the retry fails, it is marked as "synchronization abnormal" and an alarm is sent to the central control and scheduling module.

[0189] SC4.3 Policy Execution Monitoring: Receives the policy execution status of the subsystem in real time, updates the execution progress every 200ms, and triggers policy parameter adjustment if the execution progress is lower than expected.

[0190] SC5. Verification of defense effectiveness and feedback of results;

[0191] SC5.1, Effectiveness Verification Indicators:

[0192] Security Indicators: Attack Propagation Rate: Whether adjacent subsystems have the same risk, required to be ≤0%; Interception Success Rate: Required to be ≥90%; Risk Level Change: Whether the risk level decreases after defense, such as from high to medium.

[0193] Business metrics: Production latency, resource utilization;

[0194] SC5.2 After the defense is executed, the above indicator data is collected and compared with the preset threshold. If all indicators meet the standards, the defense is deemed "effective"; if they do not meet the standards, the "strategy upgrade" is triggered. The preset threshold is set according to the actual situation.

[0195] SC5.3 Feedback Results: Package the "defense effect + indicator data + execution log" and send it to the central control and scheduling module. At the same time, store the logs locally and back them up in the cloud for easy subsequent security auditing.

[0196] SC6. Defense strategy cancellation and system recovery;

[0197] SC6.1, Cancel Trigger: Receive the "Risk Relief Signal" issued by the central control and dispatch module, and initiate the policy cancellation process;

[0198] SC6.2 Policy revocation execution: Issue revocation commands in the order of "adjacent subsystems first - target subsystem" to ensure that each subsystem is restored to its normal configuration before defense. Verify the business status of the subsystem after revocation.

[0199] SC6.3 System recovery confirmation: Collect the "service recovery status" of the subsystem, confirm the recovery to the pre-defense level, and send a "system recovery complete" signal to the central control and scheduling module to end this defense process;

[0200] SC7, End.

[0201] The specific working steps of the central control and dispatch module are as follows:

[0202] SD1, Start;

[0203] SD2: Load the built-in industrial control business priority database, read the preset parameters, and fine-tune the weights based on the industrial control scenario; among them, the baseline priority weight for production control business is 8-9, the baseline priority weight for security defense business is 9-10, and the baseline priority weight for data monitoring business is 7-8.

[0204] SD3. Establish industrial Ethernet communication connections with the risk warning module, resource optimization and allocation module, and collaborative defense module. Complete the communication handshake through the Modbus / Profinet protocol and verify the communication latency of each module. The latency should be ≤50ms. If the latency exceeds the limit, trigger the retry mechanism. If the retry fails after 3 attempts, output a module offline alarm.

[0205] SD4. Initialize the "Command Log Storage Unit", set the log retention period and backup path to ensure that commands are traceable. The default log retention period is 30 days, and the backup path includes local server + off-site cloud backup.

[0206] SD5 receives risk level data and warning confidence level output from the risk warning module every 100ms;

[0207] SD6 receives resource usage data output by the resource optimization and allocation module every 200ms. The resource usage data includes CPU utilization, communication bandwidth utilization, and remaining storage capacity of each subsystem.

[0208] SD7 receives defense status data output by the collaborative defense module every 300ms. The defense status data includes policy execution progress, interception success rate, and subsystem synchronization status.

[0209] SD8. Determine resource and defense priorities based on risk level: If the risk level is "urgent / high", increase the priority weight of security defense business by 10% to 15%, while locking the resources required for core production business; if the risk level is "medium / low", maintain the baseline priority of production business and limit the resource consumption of security defense business.

[0210] SD9. Determine if there is a resource conflict by combining resource usage data: If the target subsystem has insufficient resources, trigger the "cross-subsystem resource scheduling instruction"; if resources are sufficient, directly generate the "defense resource allocation instruction".

[0211] SD10, Adjustment instructions based on defense status data: If the collaborative defense module reports "policy synchronization failed", generate a "retry synchronization instruction" and increase the synchronization timeout threshold; if it reports "interception success rate < 90%", trigger a "policy upgrade instruction".

[0212] SD11. Issue instructions in the order of "Risk Warning Module - Resource Optimization Allocation Module - Collaborative Defense Module". After each instruction is issued, wait 100ms to receive a confirmation receipt. If no receipt is received, reissue the instruction. The maximum number of retry attempts is 2.

[0213] SD12 receives the execution results from the risk warning module, resource optimization and allocation module, and collaborative defense module, and stores the results in association with the instruction log;

[0214] SD13. If the execution result does not meet expectations, re-enter the "data reception-instruction generation" process and iteratively optimize the instruction;

[0215] SD14, End.

[0216] Example 1:

[0217] 1. Application Background

[0218] A large chemical enterprise's No. 2 reactor production line undertakes high-temperature and high-pressure chemical reactions. Production interruption would lead to raw material waste and safety hazards. It is necessary to ensure continuous production while defending against malicious command injection attacks. Existing technologies are prone to increased reactor control delays due to resource constraints. After adopting this patented system, the operation flow of each module is as follows:

[0219] 2. System operation process

[0220] Step 1: Risk warning module identifies threats

[0221] Deploy industrial sensors with an accuracy of ±0.1% and a Profinet protocol communication gateway to collect parameters at a rate of 1 time per second:

[0222] CPU utilization - Reactor controller real-time value: suddenly increased from 30% to 75%;

[0223] Data frame error rate: increased from 0.1% to 12%, read from the communication gateway's "frame error statistics" register;

[0224] Communication bandwidth fluctuation values: peak value 100Mbps, valley value 40Mbps, fluctuation 60Mbps within 10 seconds;

[0225] Command execution delay: increased from 50ms to 200ms, the difference between the issuance and feedback of central control commands.

[0226] After data preprocessing, the data is input into the LSTM model, which outputs a risk probability of 92%, determines it as an "emergency risk", identifies the risk type as "malicious instruction injection", and packages the data to send to the central control and scheduling module.

[0227] Step 2: Resource optimization and allocation module schedules resources.

[0228] The central control unit issues a "critical risk + business weight" allocation, and the resource modules execute according to a dynamic scheduling algorithm:

[0229] Security defense business weight: Baseline 10 × (1 + 15%) = 11.5;

[0230] The production operations retain 60% of the CPU computing power, and the reactor controller has a total of 8 CPU cores, of which 4.8 cores are reserved for temperature and pressure control;

[0231] Communication bandwidth: 20Mbps for defensive data transmission rate, redundancy factor 1.3, allocation 26Mbps, precision 1Mbps;

[0232] Storage capacity: Based on a log generation rate of 500MB / hour and a storage time of 72 hours, allocate 36GB with a precision of 1GB.

[0233] Due to insufficient idle bandwidth in the defense subsystem, 10Mbps of idle bandwidth was allocated from the data monitoring subsystem, and the data monitoring weight was reduced by 10% to 6.3-7.2.

[0234] Step 3: The collaborative defense module executes the defense.

[0235] Receive "emergency risk + malicious command injection + resource allocation result", and match the "command interception + link isolation" strategy:

[0236] Command interception: Intercept command packets sent by abnormal IPs and record the interception log;

[0237] Link isolation: Disconnect the physical links between the No. 2 reactor subsystem and other subsystems to prevent the attack from spreading;

[0238] Cross-domain synchronization: Send instructions to subsystem #2 and adjacent subsystems #1 and #3, with a synchronization delay of 85ms, and receive all acknowledgments within 300ms.

[0239] Step 4: Effect Verification and System Recovery

[0240] Post-defense verification indicators: attack spread rate 0% - no anomalies in adjacent subsystems, interception success rate 98%, reactor control latency dropped back to 60ms; production business CPU utilization stabilized at 55%, the risk was eliminated after 1 hour, and the data monitoring subsystem 10Mbps bandwidth was recovered according to the "adjacent subsystems first - then subsystem #2" cancellation strategy, and the resource utilization was restored to the pre-defense level.

[0241] 3. Implementation Results

[0242] Malicious instruction injection was successfully blocked, and no production interruption occurred.

[0243] The maximum increase in production latency is ≤10ms, which is far lower than the 200-500ms of existing technologies;

[0244] Security and defense resources are used in a controllable manner, with no waste of resources.

[0245] Example 2:

[0246] 1. Application Background

[0247] A smart manufacturing workshop for automotive parts has 10 assembly robots divided into 3 subsystems. On a daily basis, there is a problem of wireless signal interference causing data transmission errors. Existing technology is prone to communication conflicts between subsystems due to independent defense responses.

[0248] 2. System operation process

[0249] Step 1: Risk warning module identifies threats

[0250] Deploy industrial-grade sensors to collect parameters at a rate of 0.5 times per second:

[0251] Data frame verification error rate: 5% for robot subsystem #2, normal ≤2%;

[0252] Communication bandwidth fluctuation values: peak value 50Mbps, valley value 30Mbps, fluctuation 20Mbps within 10 seconds;

[0253] There were no obvious abnormalities in CPU utilization and instruction execution latency.

[0254] The LSTM model outputs a risk probability of 35%, classifies it as "medium risk," and identifies the risk type as "link interference," which is then sent to the central control unit.

[0255] Step 2: Resource optimization and allocation module schedules resources.

[0256] The central control system issues a "medium risk + business weight" allocation, which is then executed by the resource module.

[0257] Production operations will maintain a weight of 8.5, with robot assembly as the core, and CPU operations will retain 50%.

[0258] Security defense weight: baseline 9 × 0.85 = 7.65, CPU usage controlled at 18%;

[0259] Communication bandwidth: Defensive data transmission rate 10Mbps, redundancy factor 1.1, allocation 11Mbps;

[0260] There is no resource shortage, so resources are directly allocated from the idle resources of subsystem #2.

[0261] Step 3: The collaborative defense module executes the defense.

[0262] Matching the "data encryption + interference source location" strategy:

[0263] Data encryption: Enable SSL / TLS protocol to encrypt communication between subsystem #2 and the central control unit, with the key updated every 10 minutes;

[0264] Interference source location: By scanning the wireless signals in the workshop with a spectrum analyzer, the interference source was located as a temporary WiFi device 50m outside the workshop;

[0265] Cross-domain synchronization: Synchronizes encrypted commands to 3 subsystems with a synchronization latency of 90ms and no synchronization anomalies.

[0266] Step 4: Effect Verification and System Recovery

[0267] Post-defense verification: Data frame verification error rate reduced to 1.2%, interception success rate 92%, robot assembly accuracy error ≤0.02mm. After removing the interference source, the central control sends a "risk removed" signal, cancels the encryption strategy in sequence, recovers defense resources, and reduces the CPU usage of security defense to 15%.

[0268] 3. Implementation Results

[0269] The link interference problem was resolved, and the data transmission error rate returned to normal.

[0270] The robot's assembly precision did not decrease, and its production efficiency remained above 95%.

[0271] The defense consumes minimal resources and does not affect the operation of other subsystems.

[0272] To enable those skilled in the art to better understand the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0273] It should be noted that, unless otherwise specified, the embodiments and features and technical solutions in the present invention can be combined with each other.

[0274] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0275] The above embodiments are only used to illustrate the present invention and are not intended to limit the technical solutions described herein. Although the present invention has been described in detail with reference to the above embodiments, the present invention is not limited to the specific embodiments described above. Therefore, any modifications or equivalent substitutions to the present invention, as well as all technical solutions and improvements that do not depart from the spirit and scope of the invention, are covered within the scope of the claims of the present invention.

Claims

1. An information security risk early warning and collaborative defense system for resource optimization allocation in an industrial control environment, characterized in that, Comprise: Central control scheduling module, risk early warning module, resource optimization allocation module and collaborative defense module, the central control scheduling module is respectively connected with risk early warning module, resource optimization allocation module, collaborative defense module through industrial ethernet two-way communication connection; The central control scheduling module is built-in industrial control business priority database, for receiving the risk level output by the risk early warning module, the resource occupation rate output by the resource optimization allocation module, the defense state output by the collaborative defense module, and issuing collaborative control instructions to the risk early warning module, resource optimization allocation module and collaborative defense module; The risk early warning module is used for collecting industrial control equipment operating parameters and outputting risk level, including parameter acquisition unit and multi-dimensional early warning model, the industrial control equipment operating parameters collected by the parameter acquisition unit include CPU utilization, data frame error rate, communication bandwidth fluctuation value, instruction execution time delay, the collection frequency is 0.5-1 times / second, the multi-dimensional early warning model is based on LSTM neural network training, and the risk level is output by fusing four kinds of operating parameters, wherein the risk level is divided into low / medium / high / urgent; The resource optimization allocation module is used for dynamically allocating industrial control resources based on risk level and business priority, and is built-in dynamic scheduling algorithm, and the calculation logic of the dynamic scheduling algorithm is: when the risk level is greater than or equal to high, the priority weight of the security defense business is adjusted by 10% to 15%, and at the same time, 40% to 60% CPU computing power required for production control business is reserved, when the risk level is less than or equal to medium, the priority weight of the production control business is maintained unchanged, and the CPU computing power occupied by the security defense business is controlled to be 15% to 20%; The collaborative defense module is used for executing cross-subsystem defense operations based on resource allocation results and control instructions, including defense strategy library and cross-domain synchronization unit;The defense strategy library stores four types of strategies of instruction interception, link isolation, data encryption and interference source positioning;The instruction synchronization delay of the cross-domain synchronization unit is less than or equal to 100ms; The central control scheduling module is specifically used for: Determine the resource and defense priority based on the risk level: if the risk level is "urgent / high", the priority weight of the security defense business is adjusted by 10% to 15%, and at the same time, the resources required for core production business are locked;If the risk level is "medium / low", the baseline priority of the production business is maintained, and the resource occupation of the security defense business is limited; Determine whether there is resource conflict combined with resource occupation data: if the target subsystem resource is insufficient, trigger "cross-subsystem resource scheduling instruction"; if the resource is sufficient, directly generate "defense resource allocation instruction"; Adjust the instruction based on the defense state data: if the collaborative defense module feedback "strategy synchronization fails", generate "retry synchronization instruction" and increase the synchronization timeout threshold;If the feedback "interception success rate < 90%", trigger "strategy upgrade instruction".

2. The information security risk early warning and collaborative defense system for resource optimization allocation in an industrial control environment according to claim 1, characterized in that, In the industrial control business priority database of the central control scheduling module, the baseline priority weight of the production control business is 8-9, the baseline priority weight of the security defense business is 9-10, and the baseline priority weight of the data monitoring business is 7-8.

3. The information security risk early warning and collaborative defense system for resource optimization allocation in an industrial control environment according to claim 1, characterized in that, The parameter acquisition unit adopts industrial-grade sensors and communication gateways, the collected data is preprocessed through edge computing nodes, and after removing outliers, it is uploaded to the multi-dimensional early warning model.

4. The information security risk early warning and collaborative defense system for resource optimization allocation in an industrial control environment according to claim 1, characterized in that, The industrial control resources allocated by the resource optimization allocation module include CPU computing power, communication bandwidth and storage capacity. The communication bandwidth allocation accuracy is 1 Mbps, and the storage capacity allocation accuracy is 1 GB.

5. The information security risk early warning and collaborative defense system for resource optimization allocation in an industrial control environment according to claim 1, characterized in that, The specific working steps of the risk early warning module are as follows: SA1, start; SA2, initialize and deploy the parameter acquisition unit; SA2.1, deploy industrial-grade parameter acquisition equipment: install sensors with an accuracy of ±0.1% and communication gateways supporting Profinet protocol on the industrial control equipment to ensure that the acquisition equipment and the industrial control equipment are physically compatible; SA2.2, configure the acquisition parameters and set the acquisition frequency to 0.5-1 times per second. Set the parameter threshold, which can be adjusted based on the industrial control scene; SA2.3, test the acquisition link, send test signals to the parameter acquisition unit, verify the data transmission integrity, if the loss rate is out of standard, check the gateway routing or replace the communication cable; SA3, collect the operating parameters of the industrial control equipment; SA3.1, collect four types of core parameters according to the set frequency; CPU utilization: read the real-time value through the resource monitoring interface built-in the industrial control equipment; Data frame error rate: read the number of error frames from the "frame error statistics" register of the communication gateway, and calculate "error frame number / total frame number x 100%"; Communication bandwidth fluctuation value: collect the peak and valley values of bandwidth within 10 seconds through the flow monitoring tool, and calculate "peak value-valley value"; Instruction execution delay: record the "central control instruction issuing time" and "industrial control equipment instruction execution completion feedback time", the difference is the delay; SA3.2, if the acquisition of a parameter fails, trigger the local cache call to read the average parameter value within the last 10 seconds, send an "acquisition exception alarm" to the central control scheduling module, and start retrying the acquisition, retrying every 500ms for a total of 3 times; SA4, preprocess the collected data; SA4.1, remove the abnormal values of the collected data, use the 3σ principle to filter abnormal data, if the parameter value is out of the range of "mean value ± 3 x standard deviation", it is determined as an abnormal value, then the abnormal value is removed and replaced with 60% of the previous time; SA4.2, standardize the collected data, convert the four types of parameters to standardized values of 0-100 to eliminate the influence of parameter dimension difference on the model; SA4.3, compress the collected data, use wavelet transform algorithm to compress the standardized time series data, retain key features, reduce data volume by 50%, and improve subsequent model operation efficiency; SA5, multi-dimensional risk judgment and result output; SA5.1, load the pre-trained LSTM neural network model, the LSTM neural network model is trained based on 100,000 sets of industrial control safety sample data, including device normal operation data and malicious code injection, link interference, data frame tampering; SA5.2, input the preprocessed standardized data into the model, the model outputs the risk probability, and divides the risk level according to the probability: 0%-20% is "low risk", 21%-50% is "medium risk", 51%-80% is "high risk", and 81%-100% is "emergency risk", and outputs the risk type. SA5.3, Pack "Risk Level + Risk Type + Early Warning Confidence" and send it to the central control dispatching module through industrial Ethernet, the sending frequency is consistent with the data acquisition frequency; SA6, End.

6. The information security risk early warning and collaborative defense system for resource optimization allocation in an industrial control environment according to claim 1, characterized in that, The specific working steps of the resource optimization allocation module are as follows: SB1, Start; SB2, Real-time monitoring of resource state; SB2.1, Establish resource monitoring link with each industrial control subsystem, including production control subsystem, data monitoring subsystem, and security defense subsystem, read real-time resource data of the subsystem through SNMP protocol: CPU computing power: read "idle core number x single core frequency" of the CPU of the subsystem; Communication bandwidth: read port flow data of the industrial switch, calculate "total bandwidth - used bandwidth"; Storage capacity: read "total capacity - used capacity" of the storage server; SB2.2, Update resource monitoring data every 150ms, generate "subsystem resource state table", and synchronize to the central control dispatching module, wherein "subsystem resource state table" contains subsystem ID, resource type, free amount, and used amount; SB3, Calculate resource demand based on dynamic scheduling algorithm; SB3.1, Receive "risk level + business priority weight" issued by the central control dispatching module, determine resource allocation priority: if the risk level is "urgent / high", the security defense business priority weight = baseline weight x (1+10%-15%), the production control business priority weight maintains the baseline value, and the data monitoring business priority weight is reduced by 10%; if the risk level is "medium / low", the production control business priority weight maintains the baseline value, the security defense business priority weight = baseline weight x (0.8-0.9), and the data monitoring business is allocated according to the baseline weight; SB3.2, Calculate resource demand of each business: CPU computing power demand = business basic computing power x priority weight coefficient; communication bandwidth demand = business data transmission rate x redundancy coefficient, the redundancy coefficient can be set based on the communication stability requirement of the industrial control scene, the value range is 1.1-1.3, to ensure that burst data transmission is not lost; storage capacity demand = log generation rate x storage duration; SB3.3, Judge resource gap: compare "demand amount" with "subsystem idle resource amount", if the idle resource of a subsystem is insufficient, mark it as "resource gap" and trigger cross-subsystem resource scheduling; SB4, Execute dynamic resource allocation; SB4.1, Generate resource allocation strategy: No gap scenario: directly allocate demand resource from the idle resource of the current subsystem; Gap scenario: call idle resource from lower priority subsystem; SB4.2, Issue resource allocation instruction, send resource allocation instruction to target subsystem through industrial bus, specify resource type, allocation amount, and effective time, wherein the effective time is effective immediately; SB4.3, Verify allocation result, receive "resource allocation confirmation" reply from the subsystem within 100ms after issuing the instruction, and read the subsystem resource state again to verify whether the resource usage after allocation meets the expectation, if not, recalculate and issue the instruction; SB5, Resource recycling and dynamic adjustment; SB5.1, Trigger resource recycling, receive the "defense completion signal" or "risk level down signal" issued by the central control scheduling module, start resource recycling; SB5.2, Recycle strategy execution, recycle resources in the order of "low priority service first-high priority service second", ensure that the production control service resource is not less than the baseline demand during the recycling process; SB5.3, Dynamic adjustment, recalculate resource demand every 300ms, if the resource utilization rate of a certain service is less than 50%, automatically recycle excess resources to avoid waste of resources; SB6, End.

7. The information security risk early warning and collaborative defense system for resource optimization allocation in an industrial control environment according to claim 1, characterized in that, The specific working steps of the cooperative defense module are as follows: SC1, Start; SC2, Initialize and update the defense strategy library; SC2.1, Load the preset four types of core defense strategies and trigger conditions, and store them in the defense strategy library: Instruction interception strategy: trigger condition "risk type = malicious instruction injection", strategy content "intercept instruction packets sent by abnormal IP, record interception log"; Link isolation strategy: trigger condition "risk level = emergency", strategy content "disconnect the physical link between the attacked subsystem and other subsystems"; Data encryption strategy: trigger condition "risk type = link interference", strategy content "enable SSL / TLS protocol to encrypt communication data between subsystems, and update the key every 10 minutes"; Interference source positioning strategy: trigger condition "risk type = link interference and risk level ≥ medium", strategy content "scan the workshop wireless signal through the spectrum analyzer to locate the interference source"; SC2.2, Strategy update mechanism: synchronize the latest defense strategies from the cloud security database every month, update the strategy compatibility in the test environment before updating, and replace the old strategy after verification; SC3, Defense strategy matching and instruction generation; SC3.1, Receive the "risk level + risk type + resource allocation result" issued by the central control scheduling module, and match the optimal strategy from the strategy library; SC3.2, Generate defense execution instructions: instructions include "target subsystem ID, strategy type, execution parameters, timeout time, and the default timeout time is 5 seconds; SC4, Cross-domain strategy synchronization and execution; SC4.1, Start the cross-domain synchronization unit, send a synchronization request to "target subsystem + adjacent subsystem" through industrial Ethernet, establish a synchronization communication link, and ensure that the synchronization delay is ≤100ms; SC4.2, Strategy instruction synchronization issuance, using "broadcast + confirmation" mechanism, first broadcast the defense instruction to all target subsystems, then receive the confirmation return one by one, if a subsystem does not feedback within 300ms, resend the instruction, at most retry 2 times, if the retry fails, mark it as "synchronization exception" and alarm to the central control scheduling module; SC4.3, Strategy execution monitoring: real-time receive the strategy execution status of the subsystem, update the execution progress every 200ms, if the execution progress is lower than expected, trigger the strategy parameter adjustment; SC5, Defense effect verification and result feedback; SC5.1, Effect verification index: Safety indicators include: attack spread rate, interception success rate, risk level change and business indicators; Among them, the definition of attack spread rate is: whether the adjacent subsystems have the same risk, which requires ≤0%; The required interception success rate is ≥90%. The definition of risk level change is: whether the risk level decreases after the defense is implemented; Among them, the business indicators are defined as: production control business latency and resource utilization rate; SC5.2 After the defense is completed, the above indicator data is collected and compared with the preset threshold. If all indicators meet the standards, the defense is deemed "effective"; otherwise, the "strategy upgrade" is triggered. The preset threshold is set according to the actual situation. SC5.3 Feedback Results: Package the "defense effect + indicator data + execution log" and send it to the central control and scheduling module. At the same time, store the logs locally and back them up in the cloud for easy subsequent security auditing. SC6. Defense strategy cancellation and system recovery; SC6.1, Cancel Trigger: Receives a "risk clearance signal" from the central control and dispatch module and initiates the policy cancellation process; SC6.2 Policy revocation execution: Issue revocation commands in the order of "adjacent subsystems first - target subsystem" to ensure that each subsystem is restored to its normal configuration before defense. Verify the business status of the subsystem after revocation. SC6.3 System recovery confirmation: Collect the "service recovery status" of the subsystem, and after confirming that the system has recovered to the pre-defense level, send a "system recovery complete" signal to the central control and scheduling module to end this defense process; SC7, End.

8. The information security risk early warning and collaborative defense system for resource optimization allocation in an industrial control environment according to claim 1, characterized in that, The specific working steps of the central control and dispatch module are as follows: SD1, Start; SD2: Load the built-in industrial control business priority database, read the preset parameters, and fine-tune the weights based on the industrial control scenario; among them, the baseline priority weight for production control business is 8-9, the baseline priority weight for security defense business is 9-10, and the baseline priority weight for data monitoring business is 7-8. SD3. Establish industrial Ethernet communication connections with the risk warning module, resource optimization and allocation module, and collaborative defense module. Complete the communication handshake through the Modbus / Profinet protocol and verify the communication latency of each module. The latency should be ≤50ms. If the latency exceeds the limit, trigger the retry mechanism. If the retry fails after 3 attempts, output a module offline alarm. SD4. Initialize the "Command Log Storage Unit", set the log retention period and backup path to ensure that commands are traceable. The default log retention period is 30 days, and the backup path includes local server + off-site cloud backup. SD5 receives risk level data and warning confidence level output from the risk warning module every 100ms; SD6 receives resource usage data output by the resource optimization and allocation module every 200ms. The resource usage data includes CPU utilization, communication bandwidth utilization, and remaining storage capacity of each subsystem. SD7 receives defense status data output by the collaborative defense module every 300ms. The defense status data includes policy execution progress, interception success rate, and subsystem synchronization status. SD8, determine resource and defense priority based on risk level: if the risk level is "urgent / high", the security defense business priority weight is increased by 10%-15%, and the resources required for core production control business are locked; if the risk level is "medium / low", the production control business baseline priority is maintained, and the security defense business resource occupation is limited; SD9, determine whether there is resource conflict based on resource occupation data: if the target subsystem resource is insufficient, trigger "cross-subsystem resource scheduling instruction"; if the resource is sufficient, directly generate "defense resource allocation instruction"; SD10, adjust the instruction based on the defense state data: if the cooperative defense module feedback "strategy synchronization failure", generate "retry synchronization instruction" and increase the synchronization timeout threshold; if the feedback "interception success rate <90%", trigger "strategy upgrade instruction"; SD11, issue instructions in the order of "risk warning module-resource optimization allocation module-cooperative defense module", wait for 100ms to receive confirmation after each step of instruction issuance, and reissue if no reply is received, with a maximum of 2 retries; SD12, receive the execution results of the risk warning module, resource optimization allocation module and cooperative defense module, and store the results in association with the instruction log; SD13, if the execution result does not meet the expectation, re-enter the "data receiving-instruction generation" process for iterative optimization of the instruction; SD14, end.

Images