An industrial control network security auxiliary operation method based on a large model drive

Abstract

The application relates to the technical field of industrial control network security, in particular to an industrial control network security auxiliary operation method based on a large model drive, which comprises the following steps: S1, real-time monitoring of CPU occupancy of a control server, calculation of CPU occupancy mutation frequency in a current period; S2, judgment on whether illegal program injection exists, triggering of an illegal program injection detection process when illegal program injection exists; S3, execution of a main thread scheduling investigation process, which is identification and scheduling log information to determine a load operation result condition; S4, execution of small thread behavior characteristic analysis based on a second load operation result; and S5, when small thread behavior abnormal characteristics are detected, corresponding state information is written into a monitoring buffer. Through fusion of illegal program injection identification, thread scheduling structure modeling, calling path analysis and thread behavior characteristic judgment, the detection capability of an industrial control system on hidden abnormal processes is effectively improved.

Description

Technical Field

[0001] This invention relates to the field of industrial control network security technology, and in particular to a large model-driven auxiliary operation method for industrial control network security. Background Technology

[0002] Traditional Industrial Control Systems (ICS) are typically deployed in physically isolated or closed network environments, relying on proprietary communication protocols such as PROFIBUS and Modbus, as well as key equipment such as Programmable Logic Controllers (PLCs), Distributed Control Systems (DCS), and Supervisory Control and Data Acquisition Systems (SCADA). They possess high stability and real-time performance. However, this closed architecture generally lags behind in system upgrades and security mechanisms, making it vulnerable to complex and evolving emerging cyberattacks, particularly zero-day vulnerabilities, protocol tampering, and deeply embedded malicious code.

[0003] As the trend of Industrial Internet becomes increasingly prominent, ICS (Industrial Control System) is gradually breaking down its original boundaries and deeply integrating with enterprise IT environments to achieve functions such as remote control, data uploading, and cloud management. While this trend improves operational efficiency and data visualization capabilities, it also significantly expands the attack surface. The traditional security advantages based on physical isolation are greatly weakened, exposing more cross-domain vulnerabilities and communication entry points, making systems vulnerable to new threats such as remote access attacks, supply chain implantation, and malicious control command injection.

[0004] Against this backdrop, industrial control systems are facing high-risk attacks from multiple dimensions. Attack methods include ransomware, advanced persistent threats (APTs), protocol hijacking, and hardware backdoors. Typical incidents such as Stuxnet, Industroyer, and Triton demonstrate that attackers have the ability to bypass traditional protection mechanisms and directly disrupt physical processes. Attack paths are more covert, and behavioral patterns are more complex, making it difficult for systems to identify and respond in a timely manner.

[0005] Currently, most industrial control system security systems still rely on rule-based intrusion detection, static signature recognition, patch management, and partition isolation strategies. While these mechanisms are effective in identifying known threats, they lack predictive capabilities for unknown attacks, resulting in high false positive and false negative rates. They are unable to adapt to the dynamic evolution and complex coupling of attack behavior patterns, making it difficult to support continuous protection of core production processes.

[0006] International security standards such as NIST SP 800-82 and IEC 62443 have clearly proposed a layered defense-in-depth architecture, advocating means such as zero-trust access control, real-time behavior auditing, and trust assessment between devices. However, in actual deployment, due to problems such as inconsistent data models between heterogeneous devices, lack of cross-domain monitoring capabilities, and insufficient policy intelligent matching capabilities, it is difficult to achieve precise capture of abnormal behaviors and intelligent linkage responses.

[0007] Chinese Patent Publication No.: CN119766482A discloses an industrial host network security operation and maintenance monitoring system, which includes a data acquisition module. The data acquisition module is connected to a data preprocessing module, the data preprocessing module is connected to a dynamic behavior modeling module, the dynamic behavior modeling module is connected to an intelligent correlation analysis module, the intelligent correlation analysis module is connected to a predictive defense module, the predictive defense module is connected to a self-learning defense policy module, the self-learning defense policy module is connected to a distributed monitoring and response module, and the distributed monitoring and response module is connected to an intelligent alarm classification module.

[0008] However, at the same time, existing industrial control network security auxiliary operation technologies only focus on industrial host security. Although the system modules cover links such as acquisition, modeling, prediction, and response, the overall is mainly a static process. Behavior modeling and policy optimization are limited by the rule library and user feedback, lacking cross-node semantic linkage and policy adaptive tuning capabilities, unable to achieve real-time risk propagation tracking and collaborative disposal in the IT-OT fusion environment, and difficult to cope with large-scale complex attack paths or highly concealed composite threats. Summary of the Invention

[0009] Therefore, the present invention provides an industrial control network security auxiliary operation method driven by a large model to solve the problem of low response efficiency caused by the isolation of the alarm methods for the abnormal behavior characteristic information of the main thread and small threads in industrial control network security operation.

[0010] To achieve the above object, the present invention provides an industrial control network security auxiliary operation method driven by a large model, including:

[0011] Real-time monitor the CPU occupancy rate of the control server, and calculate the mutation frequency of the CPU occupancy rate within the current period every time a preset detection period passes;

[0012] Obtain the mutation frequency of the occupancy rate within any preset detection period that has completed detection and its comparison result with the reference value of the occupancy rate mutation frequency, and judge whether there is illegal program injection based on the comparison result;

[0013] When it is determined that there is illegal program injection, trigger the illegal program injection detection process

[0014] The illegal program injection detection process includes main thread scheduling investigation and small thread behavior characteristic analysis;

[0015] The process of performing the main thread scheduling investigation involves identifying scheduling log information to determine the results of load operations.

[0016] The small thread behavior feature analysis is performed based on the result of the second load operation, including:

[0017] Obtain the depth structure of the call stack, and determine whether there is any abnormal behavior in the call path based on the depth structure;

[0018] When there is no abnormal behavior in the call path, obtain the small thread scheduling table, identify the scheduling frequency and analyze the time slice offset of the suspicious thread groups marked in the small thread scheduling table, and generate small thread behavior feature analysis results.

[0019] When abnormal behavior of a small thread is detected, the corresponding status information is written to the monitoring buffer.

[0020] The abnormal behavior of the call path includes abnormal nesting level failures and unauthorized module calls.

[0021] Furthermore, the step of obtaining the frequency of CPU utilization fluctuations within any preset detection period after the detection is completed includes:

[0022] The CPU utilization rate data stream within a preset sliding time window under normal operating conditions of the industrial control system is obtained, the average fluctuation value of the data stream is calculated, and the average fluctuation value is set as the utilization rate reference value.

[0023] Within any preset detection period, obtain the real-time occupancy rate value, and obtain the comparison result between the real-time occupancy rate value and the occupancy rate reference value;

[0024] When the first utilization rate value comparison result is obtained, the sudden event is determined based on the comparison result of the CPU utilization rate change magnitude and the CPU utilization rate change reference threshold.

[0025] Specifically, when the real-time occupancy rate is greater than the reference occupancy rate, the first occupancy rate value comparison result is obtained.

[0026] Furthermore, the steps for determining abrupt events based on the comparison between the magnitude of CPU utilization changes and a reference threshold for CPU utilization changes include:

[0027] CPU utilization is continuously collected at fixed time intervals within any preset detection period.

[0028] Calculate the change in CPU utilization rate between adjacent data collection time points based on the CPU utilization rate.

[0029] When the change in CPU utilization exceeds the reference threshold for CPU utilization changes, it is marked as a sudden event;

[0030] Count the number of mutation events within any preset detection period and output the CPU utilization mutation frequency within the current period.

[0031] The set reference value for CPU utilization and the reference threshold for CPU utilization change are used as the criteria for judging the mutation event.

[0032] Furthermore, the steps for performing the main thread scheduling check include:

[0033] Obtain scheduling log information within any preset detection period, and identify the process identifier and execution record of the main thread in the scheduling log information;

[0034] The process identifier is compared with a preset whitelist of processes:

[0035] If the process identifier is in the preset whitelist process library, analyze its corresponding load operation status, and determine the load operation result status based on the analysis results.

[0036] If the process ID corresponding to the main thread is not in the preset whitelist process library, the second load operation result is obtained;

[0037] If the load operation corresponding to the process identifier of the main thread is a high load operation, the first load operation result is obtained.

[0038] If the load operation corresponding to the process identifier of the main thread is not a high load operation, the second load operation result is obtained.

[0039] Furthermore, the steps to determine whether there is abnormal behavior in the call path include:

[0040] Execution of nested fault diagnosis:

[0041] Obtain system call stack information within any preset detection period, and construct a nested hierarchical feature sequence based on the system call stack information;

[0042] The nesting level is compared with a nesting level reference threshold, and an abnormal nesting level result is obtained when the nesting level is greater than the nesting level reference threshold.

[0043] If a non-nested level exception result is obtained, extract the identity identifier of each module in the call stack and compare it with the list of authorized modules. If there is a module identifier that is not in the list of authorized modules, obtain an unauthorized module call exception result.

[0044] Specifically, all nested levels within any preset detection period are sorted by timestamp to generate a nested level feature sequence.

[0045] Furthermore, the steps for analyzing unauthorized module calls include:

[0046] Obtain call stack information within a preset detection period, extract the identity identifiers of each level of the call module in the call stack information, and construct a module identifier sequence based on the identity identifiers; compare each module identifier in the module identifier sequence with the authorized module list to determine whether there are any module identifiers that are not in the authorized module list;

[0047] If any module identifier is detected not to be registered in the authorized module list, it is determined that there is an unauthorized module call exception, and the corresponding status information is written to the monitoring buffer.

[0048] If all module identifiers are registered in the authorized module list, it is determined that there are no non-authorized module call exceptions.

[0049] Specifically, the identity identifiers are sorted according to the call timestamp to generate the module identifier sequence.

[0050] Furthermore, the step of scheduling frequency identification includes:

[0051] Obtain the scheduling table of small threads and the scheduling records of the target small thread group within the preset detection period;

[0052] The preset detection period is divided into several fixed-length scheduling monitoring cycles. The number of scheduling triggers of the target small thread group in each scheduling monitoring cycle is counted to construct a scheduling frequency sequence.

[0053] The scheduling frequency sequence is compared with the normal thread behavior template;

[0054] If the scheduling frequency in any scheduling monitoring period is greater than the frequency reference threshold, an abnormal scheduling frequency result is obtained, and the corresponding status information is written into the monitoring buffer.

[0055] If the scheduling frequency is greater than the frequency reference threshold in all scheduling monitoring cycles, the target small thread group is marked as a small thread group to be detected, and time slice offset analysis is triggered.

[0056] The target thread group is the marked suspicious thread group.

[0057] Furthermore, the steps of time slice offset analysis include:

[0058] Obtain the scheduling time slice distribution data of the small thread group to be detected in each scheduling monitoring period, and construct the corresponding time slice distribution sequence;

[0059] The time slice offset values ​​of adjacent thread tasks are calculated based on the time slice distribution sequence, and the average time slice offset value and the corresponding time slice offset value are statistically analyzed to obtain the time slice offset feature parameters.

[0060] The offset feature parameters are compared with the time slice offset threshold in the normal thread scheduling model;

[0061] If the offset feature parameter is greater than the time slice offset threshold, it is determined that there is a time slice offset anomaly, and the corresponding status information is written into the monitoring buffer.

[0062] If the offset feature parameter is less than or equal to the time slice offset threshold, it is determined that there is no time slice offset anomaly, and the process corresponding to the small thread group to be detected is updated to the legal whitelist.

[0063] Furthermore, the steps for processing the fault information include:

[0064] Obtain status information of abnormal behavior within the monitoring buffer;

[0065] Based on the pre-established fault response adjustment library, abnormal behaviors are matched with corresponding adjustment measures according to a one-to-one mapping relationship and then executed;

[0066] Fault information is stored in a fault information database and alarms are pushed out.

[0067] Furthermore, storing fault information in a fault information database and sending alarms includes:

[0068] Real-time acquisition of fault status information, and writing of the corresponding status information into the monitoring buffer and fault information database:

[0069] Fault information is transmitted to the operation management terminal and monitoring terminal through a message push mechanism.

[0070] Compared with existing technologies, the beneficial effects of this invention are as follows: by acquiring the frequency of CPU utilization fluctuations within a preset detection period and comparing it with a set reference value, potential illegal program injection behaviors can be identified in a timely manner, enhancing the initial identification capability against sudden load-type threats; when suspicious behavior is identified, the system will automatically execute the illegal program injection detection process, sequentially completing the main thread scheduling investigation and small thread behavior analysis to further locate the specific source of the anomaly; among them, the main thread investigation confirms the legality of the process through a whitelist mechanism and screens high-frequency, high-load operations, effectively avoiding false alarms; if no anomalies are found, the call path is further analyzed, and by constructing a nested level feature sequence of the call path and comparing it with a set threshold, nested level anomalies are identified; if the nested level is normal, the module identifier sequence is compared with the list of authorized modules to identify unauthorized modules. Accurate identification of module call behavior; if the path call behavior is normal, the system switches to small thread behavior identification, extracting the scheduling features of the small thread group based on two dimensions: scheduling frequency and time slice offset, and comparing them with the normal thread model. By identifying cases of time slice offset exceeding limits or abnormal scheduling frequency, it is determined whether there are any hidden thread behavior anomalies. All the above abnormal status information is uniformly written into the monitoring buffer to build a centralized status monitoring mechanism. The system completes the one-to-one mapping and automatic execution of anomalies and corresponding adjustment measures according to the preset fault information adjustment library. Finally, the fault information is reported to the operation management terminal through real-time alarm push. While ensuring the high availability of the industrial control system, it significantly improves the accuracy of abnormal behavior identification, the degree of automation of response, and the overall efficiency of safe operation, and has good application prospects and promotion value.

[0071] Furthermore, by accurately determining abnormal behavior in the industrial control system's call path, effective identification of abnormal nested level faults and unauthorized module calls can be achieved; monitoring based on nested level thresholds can promptly detect call stack anomalies, prevent system crashes and scheduling blockage risks, and significantly enhance the stability and security of the industrial control network. Attached Figure Description

[0072] Figure 1 This is a flowchart illustrating the industrial control network security auxiliary operation method based on a large model driven according to an embodiment of the present invention.

[0073] Figure 2 This is a logic diagram for main thread scheduling and troubleshooting in an embodiment of the present invention;

[0074] Figure 3 This is a logic decision diagram for analyzing unauthorized module calls in an embodiment of the present invention;

[0075] Figure 4 This is a logic decision diagram for time slice offset analysis in an embodiment of the present invention. Detailed Implementation

[0076] To make the objectives and advantages of the present invention clearer, the present invention will be further described below with reference to embodiments; it should be understood that the specific embodiments described herein are merely for explaining the present invention and are not intended to limit the present invention.

[0077] Preferred embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0078] It should be noted that in the description of this invention, the terms "upper", "lower", "left", "right", "inner", "outer", etc., which indicate directions or positional relationships, are based on the directions or positional relationships shown in the accompanying drawings. This is only for the convenience of description and is not intended to indicate or imply that the device or element must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, it should not be construed as a limitation of this invention.

[0079] Furthermore, it should be noted that, in the description of this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0080] Please see Figure 1 The diagram shown is a flowchart illustrating an industrial control network security auxiliary operation method based on a large model driven by the present invention. The present invention provides an industrial control network security auxiliary operation method based on a large model driven by the present invention, comprising:

[0081] Step S1: Monitor and control the CPU utilization rate of the server in real time, and calculate the frequency of CPU utilization rate fluctuations in the current period after each preset detection period.

[0082] Step S2: Obtain the frequency of occupancy rate mutations within any preset detection period after the detection is completed and its comparison result with the reference value of occupancy rate mutation frequency; determine whether there is illegal program injection based on the comparison result.

[0083] When an illegal injection is detected, the illegal injection detection process is triggered.

[0084] The illegal program injection detection process includes main thread scheduling investigation and small thread behavior characteristic analysis;

[0085] Step S3, the process of performing the main thread scheduling investigation is to identify scheduling log information to determine the results of load operations;

[0086] Step S4, perform the small thread behavior feature analysis based on the second load operation result, including:

[0087] Obtain the depth structure of the call stack, and determine whether there is any abnormal behavior in the call path based on the depth structure;

[0088] When there is no abnormal behavior in the call path, obtain the small thread scheduling table, identify the scheduling frequency and analyze the time slice offset of the suspicious thread groups marked in the small thread scheduling table, and generate small thread behavior feature analysis results.

[0089] Step S5: When abnormal behavior of a small thread is detected, the corresponding status information is written to the monitoring buffer.

[0090] The abnormal behavior of the call path includes abnormal nesting level failures and unauthorized module calls.

[0091] In this embodiment, the multi-source heterogeneous data is a collection of data from diverse sources with different formats and types, used to comprehensively perceive the operating status of the industrial control system.

[0092] In this embodiment, the reference value for CPU utilization fluctuation frequency is set to 2 times per minute. By obtaining the CPU utilization fluctuation frequency within a preset detection period and comparing it with the set reference value, potential illegal program injection behavior can be identified in a timely manner, enhancing the initial identification capability against sudden load-type threats. When suspicious behavior is identified, the system will automatically execute the illegal program injection detection process, sequentially completing the main thread scheduling investigation and small thread behavior analysis to further locate the specific source of the anomaly. Among them, the main thread investigation confirms the legality of the process through a whitelist mechanism and screens high-frequency and high-load operations, effectively avoiding false alarms. If there is no anomaly, the call path is further analyzed. By constructing the nested level feature sequence of the call path and comparing it with a set threshold, nested level anomalies are identified. If the nested level is normal, the module identifier sequence is compared with the authorized module list. Yes, it achieves accurate identification of unauthorized module call behavior; if the path call behavior is normal, it switches to small thread behavior discrimination, extracts the scheduling features of the small thread group based on two dimensions: scheduling frequency and time slice offset, and compares them with the normal thread model. By identifying time slice offset exceeding the limit or scheduling frequency abnormality, it can determine whether there are hidden thread behavior abnormalities. All the above abnormal status information will be uniformly written into the monitoring buffer to build a centralized status monitoring mechanism. The system will complete the one-to-one mapping and automatic execution of abnormalities and corresponding adjustment measures according to the preset fault information adjustment library. Finally, the fault information will be reported to the operation management terminal through real-time alarm push. While ensuring the high availability of the industrial control system, it significantly improves the accuracy of abnormal behavior identification, the degree of automation of response, and the overall efficiency of safe operation, and has good application prospects and promotion value.

[0093] Specifically, the steps for obtaining the frequency of CPU utilization fluctuations within any preset detection period after the detection is completed include:

[0094] The CPU utilization rate data stream within a preset sliding time window under normal operating conditions of the industrial control system is obtained, the average fluctuation value of the data stream is calculated, and the average fluctuation value is set as the utilization rate reference value.

[0095] Within any preset detection period, obtain the real-time occupancy rate value, and obtain the comparison result between the real-time occupancy rate value and the occupancy rate reference value;

[0096] When the first utilization rate value comparison result is obtained, the sudden event is determined based on the comparison result of the CPU utilization rate change magnitude and the CPU utilization rate change reference threshold.

[0097] Specifically, when the real-time occupancy rate is greater than the reference occupancy rate, the first occupancy rate value comparison result is obtained.

[0098] In this embodiment, the real-time occupancy rate value is compared with the occupancy rate reference value;

[0099] If the real-time utilization rate is greater than the reference utilization rate, the first utilization rate value comparison result is obtained. At this time, the real-time utilization rate of the industrial control system is abnormal under normal operation. Further calculation of the CPU utilization rate change range under adjacent fixed time intervals is performed to determine whether the abnormal real-time utilization rate is caused by a sudden event.

[0100] If the real-time occupancy rate is less than or equal to the reference occupancy rate, a second occupancy rate comparison result is obtained, and the real-time occupancy rate is normal.

[0101] The frequency of CPU utilization fluctuations within the preset detection period includes:

[0102] An Edge-Box2201 edge processing device is set up for data acquisition and computation. It has an embedded Linux system and a performance monitoring module. The system is set to run multiple industrial control tasks periodically, such as data acquisition, communication, and PLC instruction execution. The average fluctuation of CPU utilization during its operation is statistically analyzed by the monitoring module based on a sliding time window. The preset sliding time window length is 60 seconds, that is, a 60-second sliding window is used as the preset detection period. The sampling period is 5 seconds, that is, the adjacent fixed time interval is 5 seconds. The average absolute difference method is used to calculate the average fluctuation of CPU utilization within the window.

[0103] For example, the average fluctuation of CPU utilization rate within a preset sliding time window under normal operating conditions of an industrial control system is 4.2%, and this value is taken as the reference value for utilization rate.

[0104] During the preset detection period, the system continuously collects CPU utilization data at the same 5-second time intervals.

[0105] The reference threshold for CPU utilization change is set at 0.1;

[0106] For two adjacent sampling points, calculate the difference in their CPU utilization. If the difference is greater than the reference threshold for CPU utilization change, then the data corresponding to the next sampling point is recorded as a mutation event. At this time, the real-time utilization value is abnormal due to the mutation event.

[0107] The total number of mutation events is counted within a complete detection cycle.

[0108] By setting a sliding time window and a fixed sampling interval, and using the mean absolute difference method to dynamically obtain the average CPU utilization fluctuation as a reference value, the baseline adaptability of utilization change monitoring is improved. It can effectively identify system load fluctuations caused by malicious programs, abnormal scheduling, or sudden computing tasks, enhance the sensitivity of perception of changes in the operating status of industrial control systems and the accuracy of abnormal behavior discrimination, and is suitable for real-time performance anomaly detection needs in lightweight edge deployment scenarios.

[0109] Specifically, the steps for determining abrupt events based on a comparison between the magnitude of CPU utilization changes and a reference threshold for CPU utilization changes include:

[0110] CPU utilization is continuously collected at fixed time intervals within any preset detection period.

[0111] Calculate the change in CPU utilization rate between adjacent data collection time points based on the CPU utilization rate.

[0112] When the change in CPU utilization exceeds the reference threshold for CPU utilization changes, it is marked as a sudden event;

[0113] Count the number of mutation events within any preset detection period and output the CPU utilization mutation frequency within the current period.

[0114] The set reference value for CPU utilization and the reference threshold for CPU utilization change are used as the criteria for judging the mutation event.

[0115] See Figure 2 As shown, it is a logic decision diagram for performing main thread scheduling and troubleshooting in an embodiment of the present invention;

[0116] Specifically, the steps for performing the main thread scheduling check include:

[0117] Obtain scheduling log information within any preset detection period, and identify the process identifier and execution record of the main thread in the scheduling log information;

[0118] The process identifier is compared with a preset whitelist of processes:

[0119] If the process identifier is in the preset whitelist process library, analyze its corresponding load operation status, and determine the load operation result status based on the analysis results.

[0120] If the process ID corresponding to the main thread is not in the preset whitelist process library, the second load operation result is obtained;

[0121] If the load operation corresponding to the process identifier of the main thread is a high load operation, the first load operation result is obtained.

[0122] If the load operation corresponding to the process identifier of the main thread is not a high load operation, the second load operation result is obtained.

[0123] In this embodiment, the main thread scheduling investigation is performed based on the system log management module deployed on the industrial master station server. It obtains all scheduling log information within the preset detection period and parses the fields related to the main thread task scheduling in the log, including timestamp, thread ID, process ID and CPU scheduling event type.

[0124] Based on the main thread identifier rules, the process identifiers corresponding to the core scheduling threads set in the current industrial control system are filtered out, and all corresponding scheduling records are extracted.

[0125] Set up a whitelist process library, which contains system process identifiers and their operation types that have been verified by the industrial control platform and have legitimate scheduling permissions, including periodic read and write operations, standard I / O transfer, control logic scheduling, etc.

[0126] The process identifier associated with the main thread is compared. If the process identifier exists in the whitelist, its load operation type is further analyzed to determine whether it is a high load operation. The judgment criteria include CPU usage continuously higher than 70%, peak memory usage greater than a set threshold, frequent file I / O operations or large-scale data cache writing. If any of the above conditions are met, it is determined to be the first load operation result; otherwise, it is the second load operation result.

[0127] If the process identifier is not in the whitelist, it is directly determined as the result of the second load operation, and the abnormal identifier is recorded to indicate its source and scheduling priority for subsequent abnormal event analysis module to call.

[0128] By calling the system log management module, precise auditing of the main thread scheduling process is achieved. Combined with the comparison mechanism between process identifiers and the whitelist database, the ability to identify illegally scheduled processes is significantly improved. By setting multi-dimensional judgment criteria for high-load operations, fine-grained classification of potential abnormal load behaviors is achieved, enhancing the accuracy of identifying malicious resource occupation or disguised legitimate behavior. When a process does not match the whitelist, abnormal information is automatically marked and associated with scheduling priority, providing prior evidence for subsequent multi-threaded behavior abnormal correlation analysis, improving the overall operational status perception capability and abnormal event tracing efficiency of the industrial control system.

[0129] Specifically, the steps to determine whether there is abnormal behavior in the call path include:

[0130] Execution of nested fault diagnosis:

[0131] Obtain system call stack information within any preset detection period, and construct a nested hierarchical feature sequence based on the system call stack information;

[0132] The nesting level is compared with a nesting level reference threshold, and an abnormal nesting level result is obtained when the nesting level is greater than the nesting level reference threshold.

[0133] If a non-nested level exception result is obtained, extract the identity identifier of each module in the call stack and compare it with the list of authorized modules. If there is a module identifier that is not in the list of authorized modules, obtain an unauthorized module call exception result.

[0134] Specifically, all nested levels within any preset detection period are sorted by timestamp to generate a nested level feature sequence.

[0135] In this embodiment, the nesting level refers to the call depth between functions or modules in the system call stack. By traversing the call stack information, the number of call chain levels formed by each thread in a single call is counted. That is, during program execution, whenever a function calls another function, the system pushes the call stack once, forming a call level. The call level is the nesting level at the corresponding moment.

[0136] Based on the call monitoring module deployed on the industrial control server, the system call stack information of the main thread and child threads is collected within a preset detection period to obtain a complete call stack record of each process in its current running state; the system constructs a nested hierarchical feature sequence based on the call depth between functions or modules at all levels;

[0137] The nesting level reference threshold is set to 15 levels. The system analyzes the call stack of all threads within the preset detection period. If the nesting level of any thread is greater than the reference threshold, it is identified as an abnormal nesting level result, and the fault type is determined to be an abnormal nesting level fault.

[0138] The status information includes the corresponding thread ID, module path, nesting depth value, and trigger time, and the status information is written into the monitoring buffer.

[0139] If no nested level anomaly is detected, the system continues to perform analysis of unauthorized module calls;

[0140] Extract the identity identifiers of each module in the call stack from the call stack information, including fields such as module file path, module loading method, and module digital signature digest, and construct a module identifier sequence;

[0141] The module identifier sequence is compared with the preset list of authorized modules;

[0142] If any module identifier is detected not in the list, it is determined to be an unauthorized module call exception, the corresponding fault type is determined to be an unauthorized module call exception, and the status information is written to the monitoring buffer.

[0143] By accurately determining abnormal behavior in the call path of the industrial control system, it is possible to effectively identify abnormal nested level faults and unauthorized module calls; monitoring based on nested level thresholds can promptly detect call stack anomalies, prevent system crashes and scheduling blockage risks, and significantly enhance the stability and security of the industrial control network.

[0144] See Figure 3 As shown, it is the logic decision diagram for the analysis of unauthorized module calls in this invention;

[0145] Specifically, the steps for analyzing unauthorized module calls include:

[0146] Obtain call stack information within a preset detection period, extract the identity identifiers of each level of the call module in the call stack information, and construct a module identifier sequence based on the identity identifiers; compare each module identifier in the module identifier sequence with the authorized module list to determine whether there are any module identifiers that are not in the authorized module list;

[0147] If any module identifier is detected not to be registered in the authorized module list, it is determined that there is an unauthorized module call exception, and the corresponding status information is written to the monitoring buffer.

[0148] If all module identifiers are registered in the authorized module list, it is determined that there are no non-authorized module call exceptions.

[0149] Specifically, the identity identifiers are sorted according to the call timestamp to generate the module identifier sequence.

[0150] In this embodiment, the fault judgment of nested abnormal levels is based on the joint execution of the call stack acquisition module and the abnormal judgment module deployed in the industrial control system host.

[0151] The call stack acquisition module obtains call stack information during both the normal operation of the industrial control system and within a preset detection period:

[0152] Under normal operating conditions, the system collects the complete call stack of the main thread and key sub-threads every 30 seconds, continuously collecting no less than 120 sets to obtain the basic nested level dataset;

[0153] Within the preset detection period, the system call paths of all active threads are collected at a sampling period of 5 seconds. The nesting depth of module / function calls in each path is extracted to construct a nesting level feature sequence.

[0154] Among them, for behavioral modeling of system call path structure, dynamic stack analysis and nesting depth statistics methods are used to structure the module or function call path of each thread.

[0155] Subsequently, the system obtains a nesting level reference threshold based on the statistical analysis of historical data under normal operating conditions. For example, the mean plus twice the standard deviation is taken as the threshold setting value. If the value is 15 levels, then 15 is regarded as the nesting level reference threshold of the industrial control system.

[0156] During the judgment phase, the nested hierarchical feature sequences within the preset detection period are compared one by one with the reference threshold;

[0157] If the nesting depth of any thread is greater than 15 levels, it is immediately marked as an abnormal nesting level fault, and its corresponding status information is written to the monitoring buffer.

[0158] By using tracing tools, the system collects thread call stack information in real time during system operation, and performs path parsing on each function or module in the call stack according to the order of call, restoring it into a complete function call sequence. Based on the nesting relationship between functions in the call path, the system calculates the nesting level depth corresponding to each path, that is, the effective call level contained in each call chain, thereby improving the accuracy of judgment.

[0159] Specifically, the scheduling frequency identification step includes:

[0160] Obtain the scheduling table of small threads and the scheduling records of the target small thread group within the preset detection period;

[0161] The preset detection period is divided into several fixed-length scheduling monitoring cycles. The number of scheduling triggers of the target small thread group in each scheduling monitoring cycle is counted to construct a scheduling frequency sequence.

[0162] The scheduling frequency sequence is compared with the normal thread behavior template;

[0163] If the scheduling frequency in any scheduling monitoring period is greater than the frequency reference threshold, an abnormal scheduling frequency result is obtained, and the corresponding status information is written into the monitoring buffer.

[0164] If the scheduling frequency is greater than the frequency reference threshold in all scheduling monitoring cycles, the target small thread group is marked as the target small thread group to be detected, and time slice offset analysis is triggered.

[0165] The target thread group is the marked suspicious thread group.

[0166] In this embodiment, based on the thread scheduling monitoring module deployed in the industrial control server, the system first obtains the small thread scheduling table and thread group information within the preset detection period, and extracts all scheduling records of the thread group.

[0167] The system divides the preset detection period into several fixed-length scheduling monitoring cycles, counts the number of scheduling triggers of the target small thread group in each scheduling monitoring cycle, and then constructs a scheduling frequency sequence.

[0168] The system pre-sets a frequency reference threshold and identifies abnormal scheduling frequency situations by comparing the scheduling frequency sequence with a normal thread behavior template.

[0169] The frequency reference threshold is 50 scheduling times per cycle.

[0170] The scheduling and monitoring cycle is set to 30 seconds.

[0171] When the scheduling frequency in any scheduling monitoring period is greater than the frequency reference threshold, the system determines that the scheduling frequency is abnormal and writes the corresponding status information into the monitoring buffer.

[0172] If the scheduling frequency is greater than the frequency reference threshold in all scheduling monitoring periods, the system further determines that the scheduling frequency is normal, marks the target thread group as the target thread group to be detected, and starts the time slice offset analysis module to continuously monitor the offset changes of its scheduling time slice in order to accurately judge the abnormal behavior of the thread in the future.

[0173] By comparing the scheduling frequency sequence with a normal thread behavior template and combining it with a fixed scheduling monitoring period and frequency reference threshold, threads with abnormal scheduling frequency can be accurately identified, significantly improving the ability to detect abnormal thread behavior in the early stages. Furthermore, based on the result of consistently high frequency throughout the entire cycle, suspicious thread groups are automatically updated into target thread groups to be detected, and time slice offset analysis is triggered in conjunction with this, enhancing the system's ability to continuously track covert scheduling anomalies and improving the completeness and timeliness of abnormal thread identification.

[0174] See Figure 4As shown, it is a logic decision diagram for time slice offset analysis in an embodiment of the present invention;

[0175] Specifically, the steps of time slice offset analysis include:

[0176] Obtain the scheduling time slice distribution data of the small thread group to be detected in each scheduling monitoring period, and construct the corresponding time slice distribution sequence;

[0177] The time slice offset values ​​of adjacent thread tasks are calculated based on the time slice distribution sequence, and the average time slice offset value and the corresponding time slice offset value are statistically analyzed to obtain the time slice offset feature parameters.

[0178] The offset feature parameters are compared with the time slice offset threshold in the normal thread scheduling model;

[0179] If the offset feature parameter is greater than the time slice offset threshold, it is determined that there is a time slice offset anomaly, and the corresponding status information is written into the monitoring buffer.

[0180] If the offset feature parameter is less than or equal to the time slice offset threshold, it is determined that there is no time slice offset anomaly, and the process corresponding to the small thread group to be detected is updated to the legal whitelist.

[0181] In this embodiment, the time slice offset threshold is determined to be 6.0ms based on historical scheduling data;

[0182] Based on the thread scheduling monitoring module deployed in the industrial control server, after the system completes the scheduling frequency identification and marks the small thread group as the small thread group to be detected, it obtains the scheduling time slice distribution data of the thread group in each scheduling monitoring period. For each thread task, it calculates the time slice offset value between it and the adjacent thread tasks, and counts all offset values ​​and their average value to form time slice offset feature parameters, thereby constructing a complete time slice distribution sequence.

[0183] The time slice distribution sequence is a set of records arranged in chronological order, indicating the start and end times of each thread task scheduling;

[0184] Based on this sequence, the system performs a step-by-step comparison of the time slices between adjacent thread tasks and calculates the time slice offset between every two consecutive tasks, i.e., the time difference or overlap difference between adjacent scheduling time points.

[0185] The system sequentially counts the time slice offsets within all scheduling cycles to form a complete list of offsets, and then calculates the mean of these offsets, which is the arithmetic mean of all offsets.

[0186] This mean is the time slice offset feature parameter, which is used to characterize the time stability or degree of abnormality of the thread group scheduling behavior, and has the ability to reflect whether the thread group scheduling pattern deviates from the normal model.

[0187] The offset feature parameter is compared with the time slice offset threshold in the preset normal thread scheduling model;

[0188] If the offset feature parameter is greater than the time slice offset threshold, it is identified as an abnormal time slice offset, indicating that the thread group has abnormal scheduling behavior, and the system writes the corresponding status information into the monitoring buffer.

[0189] If the offset feature parameter is less than or equal to the time slice offset threshold, the scheduling behavior of the thread group is considered stable and is determined to be non-time slice offset anomaly. The system updates the process corresponding to the small thread group to be detected in the thread group to the legal whitelist to avoid subsequent repeated detection.

[0190] By constructing time slice offset feature parameters based on time slice distribution sequences and comparing these parameters with normal thread scheduling models, it is possible to quantitatively judge the stability of small thread group scheduling behavior; when the offset feature parameters are greater than a threshold, it is possible to accurately identify abnormal scheduling behavior; when the offset feature parameters are reasonable, it is possible to automatically update the whitelist of legitimate processes, reducing the risk of false alarms and false negatives.

[0191] Specifically, the steps for processing fault information include:

[0192] Obtain status information of abnormal behavior within the monitoring buffer;

[0193] Based on the pre-established fault response adjustment library, abnormal behaviors are matched with corresponding adjustment measures according to a one-to-one mapping relationship and then executed;

[0194] Fault information is stored in a fault information database and alarms are pushed out.

[0195] In this embodiment, the mapping relationships in the fault response adjustment library include: mapping short-cycle surges in CPU utilization to triggering time slice reassignment measures; mapping sudden changes in thread scheduling frequency to thread priority reconstruction and scheduling policy adjustment measures; mapping abnormal call path behavior to path blocking and dynamic transfer mechanisms; mapping thread blocking coupling behavior to scheduling group reorganization measures; and if a joint anomaly of scheduling frequency and time slice offset is detected, the system performs scheduler refresh and runtime context reload.

[0196] After implementing the corresponding adjustment measures, the system writes the fault information and its handling results into the fault information database, and sends the alarm information to the operation and maintenance personnel interface and email platform through the integrated alarm push module. At the same time, it generates event tags and level classification identifiers for subsequent analysis and strategy training, ensuring that the abnormal response closed loop is completed in a timely manner and improving the robustness and recoverability of the system operation.

[0197] Specifically, storing fault information in a fault information database and sending alarms includes:

[0198] Real-time acquisition of fault status information, and writing of the corresponding status information into the monitoring buffer and fault information database:

[0199] Fault information is transmitted to the operation management terminal and monitoring terminal through a message push mechanism.

[0200] In this embodiment, alarm methods support multiple channels, including system interface, SMS and email.

[0201] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A network security assisted operation method for industrial control systems based on a large model, characterized in that, include: The CPU utilization of the control server is monitored in real time, and the frequency of CPU utilization fluctuations within the current time period is calculated after each preset detection period. Obtain the frequency of occupancy rate mutations within any preset detection period after the detection is completed, and compare it with the reference value of occupancy rate mutation frequency. Based on the comparison results, determine whether there is any illegal program injection. When an illegal injection is detected, the illegal injection detection process is triggered. The illegal program injection detection process includes main thread scheduling investigation and small thread behavior characteristic analysis; The process of performing the main thread scheduling investigation involves identifying scheduling log information to determine the results of load operations. Specifically, if the process ID corresponding to the main thread is in the preset whitelist process library and the corresponding load operation is a non-high load operation, the second load operation result is obtained; if the process ID corresponding to the main thread is not in the preset whitelist process library, the second load operation result is obtained. The small thread behavior feature analysis is performed based on the result of the second load operation, including: Obtain the depth structure of the call stack, and determine whether there is any abnormal behavior in the call path based on the depth structure; When there is no abnormal behavior in the call path, obtain the small thread scheduling table, identify the scheduling frequency and analyze the time slice offset of the suspicious thread groups marked in the small thread scheduling table, and generate small thread behavior feature analysis results. When abnormal behavior of a small thread is detected, the corresponding status information is written to the monitoring buffer. The abnormal behavior of the call path includes abnormal nesting level failures and unauthorized module calls.

2. The industrial control network security auxiliary operation method based on large model-driven operation according to claim 1, characterized in that, The steps for obtaining the frequency of CPU utilization fluctuations within any preset detection period after the detection is completed include: The CPU utilization rate data stream within a preset sliding time window under normal operating conditions of the industrial control system is obtained, the average fluctuation value of the data stream is calculated, and the average fluctuation value is set as the utilization rate reference value. Within any preset detection period, obtain the real-time occupancy rate value, and obtain the comparison result between the real-time occupancy rate value and the occupancy rate reference value; When the first utilization rate value comparison result is obtained, the sudden event is determined based on the comparison result of the CPU utilization rate change magnitude and the CPU utilization rate change reference threshold. Specifically, when the real-time occupancy rate is greater than the reference occupancy rate, the first occupancy rate value comparison result is obtained.

3. The industrial control network security auxiliary operation method based on large model-driven operation according to claim 2, characterized in that, The steps for determining abrupt events based on the comparison between the magnitude of CPU utilization changes and a reference threshold for CPU utilization changes include: CPU utilization is continuously collected at fixed time intervals within any preset detection period. Calculate the change in CPU utilization rate between adjacent data collection time points based on the CPU utilization rate. When the change in CPU utilization exceeds the reference threshold for CPU utilization changes, it is marked as a sudden event; Count the number of mutation events within any preset detection period and output the CPU utilization mutation frequency within the current period. The set reference value for CPU utilization and the reference threshold for CPU utilization change are used as the criteria for judging the mutation event.

4. The industrial control network security auxiliary operation method based on large model-driven operation according to claim 1, characterized in that, The steps for performing the main thread scheduling check include: Obtain scheduling log information within any preset detection period, and identify the process identifier and execution record of the main thread in the scheduling log information; The process identifier is compared with a preset whitelist of processes: If the process identifier is in the preset whitelist process library, analyze its corresponding load operation status, and determine the load operation result status based on the analysis results. If the process ID corresponding to the main thread is not in the preset whitelist process library, the second load operation result is obtained; If the load operation corresponding to the process identifier of the main thread is a high load operation, the first load operation result is obtained. If the load operation corresponding to the process identifier of the main thread is not a high load operation, the second load operation result is obtained.

5. The industrial control network security auxiliary operation method based on large model-driven operation according to claim 1, characterized in that, The steps to determine if there is abnormal behavior in the call path include: Execution of nested fault diagnosis: Obtain system call stack information within any preset detection period, and construct a nested hierarchical feature sequence based on the system call stack information; The nesting level is compared with a nesting level reference threshold, and an abnormal nesting level result is obtained when the nesting level is greater than the nesting level reference threshold. If a non-nested level exception result is obtained, extract the identity identifier of each module in the call stack and compare it with the list of authorized modules. If there is a module identifier that is not in the list of authorized modules, obtain an unauthorized module call exception result. Specifically, all nested levels within any preset detection period are sorted by timestamp to generate a nested level feature sequence.

6. The industrial control network security auxiliary operation method based on large model-driven operation according to claim 5, characterized in that, The steps for analyzing unauthorized module calls include: Obtain call stack information within a preset detection period, extract the identity identifiers of each level of the call module in the call stack information, and construct a module identifier sequence based on the identity identifiers; compare each module identifier in the module identifier sequence with the authorized module list to determine whether there are any module identifiers that are not in the authorized module list; If any module identifier is detected not to be registered in the authorized module list, it is determined that there is an unauthorized module call exception, and the corresponding status information is written to the monitoring buffer. If all module identifiers are registered in the authorized module list, it is determined that there are no non-authorized module call exceptions. Specifically, the identity identifiers are sorted according to the call timestamp to generate the module identifier sequence.

7. The industrial control network security auxiliary operation method based on large model-driven operation according to claim 1, characterized in that, The steps for identifying the scheduling frequency include: Obtain the scheduling table of small threads and the scheduling records of the target small thread group within the preset detection period; The preset detection period is divided into several fixed-length scheduling monitoring cycles. The number of scheduling triggers of the target small thread group in each scheduling monitoring cycle is counted to construct a scheduling frequency sequence. The scheduling frequency sequence is compared with the normal thread behavior template; If the scheduling frequency in any scheduling monitoring period is greater than the frequency reference threshold, an abnormal scheduling frequency result is obtained, and the corresponding status information is written into the monitoring buffer. If the scheduling frequency is greater than the frequency reference threshold in all scheduling monitoring cycles, the target small thread group is marked as a small thread group to be detected, and time slice offset analysis is triggered. The target thread group is the marked suspicious thread group.

8. The industrial control network security auxiliary operation method based on large model-driven operation according to claim 7, characterized in that, The steps of time slice offset analysis include: Obtain the scheduling time slice distribution data of the small thread group to be detected in each scheduling monitoring period, and construct the corresponding time slice distribution sequence; The time slice offset values ​​of adjacent thread tasks are calculated based on the time slice distribution sequence, and the average time slice offset value and the corresponding time slice offset value are statistically analyzed to obtain the time slice offset feature parameters. The offset feature parameters are compared with the time slice offset threshold in the normal thread scheduling model; If the offset feature parameter is greater than the time slice offset threshold, it is determined that there is a time slice offset anomaly, and the corresponding status information is written into the monitoring buffer. If the offset feature parameter is less than or equal to the time slice offset threshold, it is determined that there is no time slice offset anomaly, and the process corresponding to the small thread group to be detected is updated to the legal whitelist.

9. The industrial control network security auxiliary operation method based on large model-driven operation according to claim 1, characterized in that, The steps for processing fault information include: Obtain status information of abnormal behavior within the monitoring buffer; Based on the pre-established fault response adjustment library, abnormal behaviors are matched with corresponding adjustment measures according to a one-to-one mapping relationship and then executed; Fault information is stored in a fault information database and alarms are pushed out.

10. The industrial control network security auxiliary operation method based on large model-driven operation according to claim 9, characterized in that, Storing fault information in a fault information database and sending alarms includes: Real-time acquisition of fault status information, and writing of the corresponding status information into the monitoring buffer and fault information database: Fault information is transmitted to the operation management terminal and monitoring terminal through a message push mechanism.

Images