Industrial control system security auditing method and system

Abstract

This invention relates to the field of security auditing technology, specifically to a method and system for security auditing industrial control systems (ICS). The method includes the following steps: collecting data on cycle time, start timestamp, completion timestamp, CPU time slice usage, and peak memory usage for critical control, communication, and security tasks of a real-time operating system (RTOS). This invention collects data on cycle time, timestamps, CPU usage, and memory usage of critical ROS tasks, sets task execution time boundaries and resource consumption envelopes, and then uses historical data statistics and logical rule deduction to construct a set of expected relationship rules between task timing and resource consumption. Simultaneously, it specifies the key length for symmetric and asymmetric encryption, initialization vector generation, hash algorithm selection, key derivation parameters, and encryption operation context, thereby establishing a comprehensive and specific baseline for ICS behavioral norms.

Description

Technical Field

[0001] This invention relates to the field of security auditing technology, and in particular to a security auditing method and system for industrial control systems. Background Technology

[0002] In the field of security audit technology, within industrial control systems (ICS), real-time operating systems (RTOS), and embedded systems environments, the focus is on the systematic examination and evaluation of system activities, configurations, and data flows to verify compliance with established security policies and industry standards.

[0003] Current security auditing technologies primarily focus on monitoring isolated events or parameters, lacking in-depth analysis of multi-dimensional data, especially the intrinsic correlation between task execution timing and resource consumption. For example, a task timeout might be logged, but crucial contextual information such as abnormally low CPU utilization or a sudden surge in memory usage at the time of the timeout may be overlooked. This makes it difficult to accurately determine whether it's a normal system fluctuation or potential malicious interference, such as an unauthorized task suspension or the initial stage of a resource exhaustion attack. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a method and system for security auditing of industrial control systems.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a security audit method for an industrial control system, comprising the following steps:

[0006] For critical control, communication, and security tasks of the real-time operating system, data on cycle time, start timestamp, completion timestamp, CPU time slice usage, and peak memory usage are collected. Worst-case execution time, best-case execution time, scheduling jitter range, CPU utilization range, and memory usage limit are set. Historical data statistics and logical rule deduction are used to construct a rule set on the relationship between task timing characteristics and expected resource consumption. At the same time, the lower limit of symmetric encryption key length, initialization vector generation method, hash algorithm selection standard, lower limit of key derivation function iteration number, lower limit of asymmetric encryption key length, elliptic curve cryptosystem curve parameters, and encryption operation call process and code location are set to establish ICS behavior specifications.

[0007] Based on the aforementioned ICS behavior specifications, the system continuously acquires the real-time start timestamp, completion timestamp, CPU time slice usage, and memory usage of critical tasks. It also uses a function entry point replacement mechanism to intercept application programming interface (API) call events of the encryption function library, parses the API call parameters, extracts the algorithm identifier, key handle, key length, initialization vector, salt value, encryption mode, and input data digest, and generates a monitoring operation parameter set.

[0008] Preferably, the method further includes:

[0009] Based on the monitoring operation parameter set and the ICS behavior specification, the actual execution time of the task is compared with the worst execution time and the deadline. The CPU consumption and memory consumption of the task are compared with the preset envelope. The encrypted application programming interface call parameters are verified, specifically the key length, initialization vector randomness, salt reuse, encryption mode security level and hash algorithm strength. At the same time, the order of application programming interface calls and the location of the calling process code are checked. The timing resource association rules are applied to determine whether there is an unexpected combination between the task execution time and the CPU utilization rate, and a list of detected anomalies is generated.

[0010] Based on the detected anomaly list, multiple anomaly records are aggregated and compared with a preset local intrusion feature library, which includes resource exhaustion attack mode and task scheduling interference mode. It is determined whether a local intrusion event has occurred, and the abnormal task status information and resource usage values ​​are recorded. The priority values ​​of affected critical control tasks are adjusted, the CPU allocation quota for suspicious tasks is limited, and the process of suspicious tasks is terminated. For cases where critical control loops are affected, the device is triggered to a preset fault-safe state or a controlled restart procedure is executed, and an activated response configuration is established.

[0011] Preferably, the steps for obtaining the ICS behavioral specifications are as follows:

[0012] For critical control, communication, and security tasks in a real-time operating system, periodic data is directly read through kernel hooks. The start timestamp and completion timestamp of each task scheduling are captured using timers. The CPU time slice values ​​are obtained by querying system performance counters. Peak memory usage data during dynamic allocation and release of memory during task execution is recorded. The collected data is organized and archived. The execution time boundaries of each task are defined, including the worst execution time and the best execution time, as well as the allowable range of jitter in the scheduling cycle. The upper and lower limits of CPU utilization and the upper limit of memory usage are set to generate a set of basic task parameters.

[0013] Based on the historical period, start timestamp, completion timestamp, CPU time slice, and peak memory usage data recorded in the task basic parameter set, a stable correspondence pattern between the timing characteristics and resource consumption of the task under different load conditions is identified. This pattern is then deduced and solidified into a set of rules for the expected relationship between the timing characteristics and resource consumption of the task. Simultaneously, the minimum bit length of the key for the symmetric encryption algorithm is determined, the initialization vector must be generated by the target random number generator, a list of secure hash algorithms is specified, the minimum number of iterations and salt length of the key derivation function are set, the minimum bit length of the key for the asymmetric encryption algorithm and the standard curve parameters that must be used in the elliptic curve cryptosystem are defined, and a baseline strategy set is obtained.

[0014] Based on the task basic parameter set, which includes the worst execution time, best execution time, scheduling jitter range, CPU utilization range, and memory usage limit for each task, and integrating the task timing characteristics and expected resource consumption relationship rule set constructed in the baseline policy set, as well as the set of symmetric encryption key length lower limit, initialization vector generation method, hash algorithm selection standard, key derivation function iteration number lower limit, asymmetric encryption key length lower limit, elliptic curve cryptosystem curve parameters, and encryption operation call process and code location, the ICS behavior specification is jointly established.

[0015] Preferably, the step of obtaining the monitoring operation parameter set is as follows:

[0016] Based on the list of critical tasks defined in the ICS behavior specification, a continuous monitoring process is initiated. For each task in the list, the start timestamp is obtained in real time through the operating system scheduler interface, the completion timestamp is captured when the task is completed, and the cumulative value of the time slice allocated to the task by the central processing unit is read. At the same time, the memory manager is queried to obtain the total amount of memory currently occupied by the task, forming a real-time task data stream.

[0017] Based on the encryption function library and interface information determined in the ICS behavior specification, the original entry address of the target encryption application programming interface is replaced with the preset audit function address by modifying the global offset table entries of the target function library. When the critical process calls the encryption interface, the audit function is triggered, intercepts the encryption function library application programming interface call event, and completely copies all parameter values ​​passed to the interface during the call to obtain the original encryption call data.

[0018] The task context information provided by the real-time task data stream is integrated, and the raw encrypted call data is processed. From the intercepted application programming interface call parameters, the parameters are parsed one by one according to the parameter order and type to extract the algorithm identifier value, key handle pointer, key length value, initialization vector byte sequence, salt value byte sequence, encryption mode option code, and hash digest value of input data block. The extracted parameters are associated with the corresponding task execution information to generate a monitoring operation parameter set.

[0019] Preferably, the step of obtaining the list of detected anomalies is as follows:

[0020] Based on the real-time task start timestamp, completion timestamp, CPU time slice, and memory usage in the monitoring operation parameter set, and compared with the worst execution time, deadline, CPU utilization range, and memory usage limit set in the ICS behavior specification, the execution time of each task is compared to see if it exceeds the worst execution time, whether it is completed before the deadline, and whether the CPU consumption and memory consumption of the task exceed the preset upper and lower limit envelope range. All cases that exceed the specified range are recorded to form a single-point deviation record.

[0021] Based on the algorithm identifier, key length, initialization vector, salt value, encryption mode, and input data digest extracted from the monitoring operation parameter set, and referring to the lower limit of symmetric encryption key length, initialization vector generation method, and hash algorithm selection standards set in the ICS code of conduct, the system verifies whether the key length used meets the lower limit requirement, evaluates its randomness by checking the repeatability and distribution characteristics of the initialization vector sequence, determines whether the salt value is improperly reused, verifies whether the selected encryption mode is the recommended security level, verifies whether the hash algorithm is within the selection standard list, and compares whether the actual order of calling the encryption application programming interface conforms to the standard process, and whether the calling process and code position are consistent with expectations, thus obtaining the encryption compliance verification result.

[0022] Preferably, the step of obtaining the list of detected anomalies further includes:

[0023] Combining the task execution time deviations and resource consumption exceedances identified in the single-point deviation records, and referring to the encryption parameter usage issues or context mismatches discovered in the encryption compliance verification results, the rule set of task timing characteristics and expected resource consumption relationships defined in the ICS behavior specification is applied to determine whether there are abnormal task execution times but abnormal CPU utilization, or whether the CPU utilization of the task is consistently too high during normal execution time, and a list of detected anomalies is generated.

[0024] Preferably, the step of obtaining the activated response configuration is as follows:

[0025] Based on the individual and related anomaly information collected in the detected anomaly list, time series and logical correlation analysis are performed on multiple anomaly records to aggregate them into anomaly event patterns. The patterns are then matched one by one with the resource exhaustion attack pattern feature vector and task scheduling interference pattern time series graph preset in the local intrusion feature library. Based on the matching similarity and the number of rules that are met, it is determined whether the current system state constitutes a local intrusion event, and the intrusion event determination conclusion is output.

[0026] The occurrence of a local intrusion event is verified based on the intrusion event determination conclusion. The status information of the abnormal tasks associated with the event is retrieved from the list of detected anomalies, including the task identifier, the timestamp of the anomaly occurrence, the anomaly description, and the recorded resource usage values. The priority values ​​of the affected critical control tasks in the operating system scheduling queue are then adjusted to a higher level. At the same time, the CPU time slice allocation quota is restricted for tasks determined to be suspicious, forming a preliminary set of response actions.

[0027] Preferably, the step of obtaining the activated response configuration further includes:

[0028] Based on the severity level assessment of the intrusion event determination conclusion and the feedback on the execution effect of the preliminary response action set, if it is determined to be malicious code activity and the preliminary resource restrictions fail to contain it, an instruction is sent to the operating system kernel to terminate the process execution of the suspicious task. If the real-time performance of the critical control loop has been severely affected, the device is immediately triggered to switch to a predefined fault-safe operating state and an activated response configuration is established.

[0029] This invention also provides an industrial control system security audit system, comprising:

[0030] The data collection and specification construction module collects data on the cycle, start timestamp, completion timestamp, CPU time slice, and peak memory usage for critical control, communication, and security tasks of the real-time operating system. It sets the worst-case execution time, best-case execution time, scheduling jitter range, CPU utilization range, and memory usage limit for each task. It also uses historical data statistics and logical rule deduction to construct a rule set on the relationship between task timing characteristics and expected resource consumption. In addition, it sets the lower limit for symmetric encryption key length, initialization vector generation method, hash algorithm selection standard, lower limit for key derivation function iteration count, lower limit for asymmetric encryption key length, elliptic curve cryptosystem curve parameters, and encryption operation call process and code location to establish ICS behavior specifications.

[0031] The real-time monitoring and parameter extraction module, based on the ICS behavior specification, continuously acquires the real-time start timestamp, completion timestamp, CPU time slice, and memory usage of key tasks. It also uses a function entry point replacement mechanism to intercept application programming interface (API) call events of the encryption function library, parses the API call parameters, extracts the algorithm identifier, key handle, key length, initialization vector, salt value, encryption mode, and input data digest, and generates a monitoring operation parameter set.

[0032] The anomaly comparison and auditing module, based on the monitoring operation parameter set and the ICS behavior specification, compares the actual execution time of the task with the worst execution time and the deadline, compares the CPU consumption and memory consumption of the task with the preset envelope, and verifies the encrypted application programming interface call parameters, specifically the key length, initialization vector randomness, salt reuse, encryption mode security level and hash algorithm strength. At the same time, it checks the application programming interface call order and the location of the calling process code, and applies time-series resource association rules to determine whether there is an unexpected combination between the task execution time and CPU utilization, and generates a list of detected anomalies.

[0033] The intrusion response and handling module, based on the detected anomaly list, aggregates multiple anomaly records, compares them with a preset local intrusion feature library, which includes resource exhaustion attack mode and task scheduling interference mode, determines whether a local intrusion event has occurred, records the abnormal task status information and resource usage values, adjusts the priority values ​​of affected critical control tasks, limits the CPU allocation quota for suspicious tasks, terminates the process of suspicious tasks, and, for cases where critical control loops are affected, triggers the device to a preset fault-safe state or executes a controlled restart procedure, and establishes an activated response configuration.

[0034] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0035] This invention collects data on the cycle, timestamps, CPU usage, and memory consumption of critical tasks in a real-time operating system (ICS). It sets task execution time boundaries and resource consumption envelopes, and then uses historical data statistics and logical rule deduction to construct a set of rules predicting the relationship between task timing and resource consumption. Simultaneously, it specifies key lengths for symmetric and asymmetric encryption, initialization vector generation, hash algorithm selection, key derivation parameters, and encryption operation contexts, thereby establishing a comprehensive and specific baseline for ICS behavior specifications. This deep modeling approach enables the continuous acquisition of real-time execution data of critical tasks and the interception and parsing of encrypted API call parameters through a function entry point replacement mechanism, generating a highly correlated set of monitoring operation parameters. Based on this, by comparing real-time monitoring data with ICS behavior specifications in multiple dimensions, it can not only identify individual task execution timeouts and resource exceedances but also verify the security of encryption parameters, such as whether the key length meets the requirements, whether the initialization vector has sufficient randomness, whether the salt value is improperly reused, whether the encryption mode and hash algorithm comply with current security standards, and the compliance of API call order and location. More importantly, it can apply time-series resource correlation rules to identify more subtle anomalies, such as slightly abnormal task execution time with abnormally low CPU utilization, or tasks with 100% CPU utilization throughout normal execution time. This approach, combining task timing auditing with resource consumption auditing and incorporating runtime auditing with the context of encryption primitive usage and parameter security, and then using correlation analysis, significantly improves the accuracy and depth of detection. It can uncover local intrusion behaviors that are difficult to reveal using traditional auditing methods, such as subtly affecting real-time system performance and resource allocation, or performing degradation attacks at the encryption application level. Finally, it aggregates multiple anomaly records and compares them against a local intrusion signature database containing resource exhaustion attack patterns and task scheduling interference patterns for judgment, triggering tiered local countermeasures including adjusting task priorities, limiting resources, terminating processes, and even secure restarts. This provides a more effective and proactive local security protection mechanism for industrial control system environments with extremely high real-time and security requirements, enhancing the system's ability to resist complex local intrusions. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of the steps of the present invention. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0038] Please see Figure 1This invention provides a technical solution, a method for security auditing of industrial control systems, comprising the following steps:

[0039] For critical control, communication, and security tasks of the real-time operating system, data on cycle time, start timestamp, completion timestamp, CPU time slice usage, and peak memory usage are collected. Worst-case execution time, best-case execution time, scheduling jitter range, CPU utilization range, and memory usage limit are set. Historical data statistics and logical rule deduction are used to construct a rule set on the relationship between task timing characteristics and expected resource consumption. At the same time, the lower limit of symmetric encryption key length, initialization vector generation method, hash algorithm selection standard, lower limit of key derivation function iteration number, lower limit of asymmetric encryption key length, elliptic curve cryptosystem curve parameters, and encryption operation call process and code location are set to establish ICS behavior specifications.

[0040] Based on the ICS behavior specification, the system continuously acquires the real-time start timestamp, completion timestamp, CPU time slice, and memory usage of critical tasks. It also uses a function entry point replacement mechanism to intercept application programming interface (API) call events of the encryption function library, parses the API call parameters, extracts the algorithm identifier, key handle, key length, initialization vector, salt value, encryption mode, and input data digest, and generates a set of monitoring operation parameters.

[0041] Based on the monitoring operation parameter set and ICS behavior specifications, the actual execution time of the task is compared with the worst execution time and the deadline. The CPU consumption and memory consumption of the task are compared with the preset envelope. The encrypted application programming interface call parameters are verified, specifically the key length, initialization vector randomness, salt reuse, encryption mode security level and hash algorithm strength. At the same time, the order of application programming interface calls and the location of the calling process code are checked. The timing resource association rules are applied to determine whether there is an unexpected combination between the task execution time and CPU utilization, and a list of detected anomalies is generated.

[0042] Based on the detected anomaly list, multiple anomaly records are aggregated and compared with the preset local intrusion signature database, which includes resource exhaustion attack mode and task scheduling interference mode. The database determines whether a local intrusion event has occurred, records the status information and resource usage values ​​of the abnormal tasks, adjusts the priority values ​​of the affected critical control tasks, limits the CPU allocation quota of suspicious tasks, terminates the process of suspicious tasks, and, for cases where critical control loops are affected, triggers the device to a preset fault-safe state or executes a controlled restart procedure, and establishes an activated response configuration.

[0043] The steps to obtain the ICS code of conduct are as follows:

[0044] For critical control, communication, and security tasks in a real-time operating system, periodic data is directly read through kernel hooks. The start timestamp and completion timestamp of each task scheduling are captured using timers. The CPU time slice values ​​are obtained by querying system performance counters. Peak memory usage data during dynamic allocation and release of memory during task execution is recorded. The collected data is organized and archived. The execution time boundaries of each task are defined, including the worst execution time and the best execution time, as well as the allowable range of jitter in the scheduling cycle. The upper and lower limits of CPU utilization and the upper limit of memory usage are set to generate a set of basic task parameters.

[0045] Based on the historical cycle, start timestamp, completion timestamp, CPU time slice, and peak memory usage data recorded in the task's basic parameter set, a stable correspondence pattern between the task's timing characteristics and resource consumption under different load conditions is identified. This pattern is then deduced and solidified into a set of rules for the expected relationship between the task's timing characteristics and resource consumption. Simultaneously, the minimum bit length of the key for symmetric encryption algorithms is determined, the initialization vector must be generated by the target random number generator, a list of secure hash algorithms is specified, the minimum number of iterations and salt length for the key derivation function operation are set, the minimum bit length of the key for asymmetric encryption algorithms and the standard curve parameters that must be used in elliptic curve cryptography are defined, resulting in a baseline strategy set.

[0046] Based on the task's basic parameter set, which includes the worst-case execution time, best-case execution time, scheduling jitter range, CPU utilization range, and memory usage limit for each task, and integrating the task timing characteristics and expected resource consumption relationship rule set constructed in the baseline policy set, as well as the set of symmetric encryption key length lower limit, initialization vector generation method, hash algorithm selection standard, key derivation function iteration number lower limit, asymmetric encryption key length lower limit, elliptic curve cryptosystem curve parameters, and encryption operation call process and code location, the ICS behavior specification is jointly established.

[0047] Specifically, for critical control, communication, and security tasks in a real-time operating system, in practice, for periodic data, probes are inserted into pre-configured hook functions in the real-time operating system kernel, such as on critical paths where the task scheduler performs context switching (e.g., context_switch) or task state changes (e.g., from ready to running). This non-intrusive method captures and records the preset execution cycle of each monitored task (e.g., motor control task MotorCtrl_T1, sensor data acquisition task SensorAcq_T2, encrypted communication task SecureComm_T3). If the task is periodic, its cycle value is typically within a certain range. The period of a task is defined in the system configuration or task properties when it is created. For example, the period of MotorCtrl_T1 is 10 milliseconds. Using a high-precision hardware timer, such as a timestamp counter (TimeStampCounter, TSC) or a processor-specific period counter, the precise timestamp at the moment the task control block (TCB) is selected by the scheduler and about to be executed is recorded as the start timestamp. Before the task finishes execution, relinquishes the processor, or enters a suspended state, the timer is read again to obtain the completion timestamp. This is done by querying the system performance counters provided by the operating system or directly reading the processor timer associated with the task. The CPU time slice actually used by the task in this scheduled execution is obtained from the CPU time slice register. For example, MotorCtrl_T1 consumed 1.2 milliseconds of CPU time in this execution. Simultaneously, throughout the entire lifecycle of the task, by monitoring the calls to memory allocation functions (such as malloc and calloc) and deallocation functions (such as free), or periodically querying the operating system's memory manager's memory usage statistics (such as resident set size RSS) for the task, the peak values ​​of dynamic memory allocation and deallocation are continuously tracked and updated. For example, SensorAcq_T2's memory usage reached a maximum of 512KB during execution. All collected data are recorded. The task's periodic data, start timestamp sequence, completion timestamp sequence, CPU time slice sequence, and peak memory usage data are structured, stored, and indexed according to task identifiers and acquisition times. Based on this historical archived data, the maximum observed execution time for each task is calculated as the worst-case execution time. For example, if MotorCtrl_T1's maximum execution time in 1000 observations is 1.8 milliseconds, its worst-case execution time can be set to 1.8 milliseconds, or, considering a safety margin, 1.8 milliseconds multiplied by 1.1, i.e., 1.98 milliseconds. The minimum observed execution time is calculated as the best-case execution time; for example, MotorCtrl_T1's minimum execution time is 0.8 milliseconds are used to analyze the deviation between the actual and theoretical start times of a task (scheduling jitter), and its allowable range is set. For example, for MotorCtrl_T1 with a period of 10 milliseconds, if the 99th percentile of the historical data on the deviation between its actual start time and the theoretical scheduling point is 0.5 milliseconds, then the scheduling jitter range can be set to ±0.5 milliseconds. Based on the historical CPU time slices and task cycle, the CPU utilization rate (time slice / cycle) of the task is calculated, and its upper and lower limits are set. For example, the average CPU utilization rate of MotorCtrl_T1 is... The CPU utilization rate is 1.2 milliseconds / 10 milliseconds = 12%. If its historical utilization rate standard deviation is 2%, then the range can be set to (12% minus 3 multiplied by 2%) = 6%, and to (12% plus 3 multiplied by 2%) = 18%, i.e., [6%, 18%]. The upper limit of memory usage is set based on historical peak memory usage data. For example, if the historical peak memory usage of SensorAcq_T2 is a maximum of 512KB, then its memory upper limit can be set to 512KB multiplied by 1.2 = 614.4KB. A task base parameter set containing these definitions is then generated.

[0048] Based on the historical cycles, start timestamps, completion timestamps, CPU time slices, and peak memory usage data of each key control, communication, and security task recorded in the task baseline parameter set, this data is first preprocessed, for example, by removing atypical data points collected during the initial system startup or known maintenance windows. Then, for each task, the relationship between its timing characteristics (such as execution time and response time) and resource consumption (CPU utilization and memory usage) under different system loads (e.g., the number of other concurrent tasks, network traffic intensity, I / O operation frequency, etc., which can be obtained from the system's global monitoring data) is analyzed. Statistical analysis methods are used, such as calculating the mean and variance of each parameter under different load levels, or regression analysis is employed (e.g., using CPU utilization as the dependent variable and the amount of task input data or the total system CPU load as the independent variable). (Perform linear or nonlinear regression) to identify stable time-series and resource consumption patterns that recur under specific load conditions. For example, it was found that the SensorAcq_T2 task has an average execution time of 0.5 milliseconds, a CPU utilization of 5%, and a peak memory usage of 200KB under low network load (below 1Mbps); while under high network load (above 10Mbps), its average execution time increases to 0.8 milliseconds, the CPU utilization rises to 8%, and the peak memory usage slightly increases to 220KB. These statistically significant patterns will be solidified to form a set of rules for the relationship between task timing characteristics and expected resource consumption, such as the rule: "IFTaskIDISSensorAcq_T2ANDNetworkLoadISLowTHENExpectedExecTime_MAX=0.""6ms AND Expected CPU_MAX = 6%" Meanwhile, at the security policy level, based on currently recognized cryptographic standards and industry security guidelines (such as NIST SP800 series, IEC 62443), the minimum bit length of the key for symmetric encryption algorithms (such as AES) is determined, for example, set to 128 bits. The initialization vector (IV) must be generated by a cryptographically secure pseudo-random number generator (CSPRNG) provided by the operating system or certified, prohibiting the use of fixed IVs or predictable IV generation methods. A list of secure hash algorithms is specified, such as including SHA-256, SHA-384, and SHA-512, while excluding algorithms known to have vulnerabilities such as MD5 and SHA-1. The key derivation function (KD) is also defined. F, such as the minimum number of iterations and minimum salt length for operations like PBKDF2 or Argon2, for example, for PBKDF2, the minimum number of iterations is set to 100,000, and the minimum salt length is 16 bytes. This is to increase the difficulty of brute-force attacks. This number of iterations is set based on benchmark results showing that the target hardware completes the operation with an acceptable latency (e.g., within 50 milliseconds). Define the minimum key bit length for asymmetric encryption algorithms (e.g., RSA or ECC), for example, the minimum key length for RSA is 2048 bits. Also define the standard curve parameters that must be used for elliptic curve cryptography (ECC), such as specifying the use of extensively security-reviewed curves like NISTP-256 or Curve 25519. This results in a set of baseline strategies that include these specific security configuration requirements.

[0049] Based on the task's fundamental parameter set, which includes the worst-case execution time (e.g., 1.98 ms for MotorCtrl_T1), best-case execution time (e.g., 0.8 ms for MotorCtrl_T1), allowable scheduling jitter range (e.g., ±0.5 ms for MotorCtrl_T1), upper and lower limits of CPU utilization (e.g., [6%, 18%] for MotorCtrl_T1), and upper limits of memory usage (e.g., 614.4 KB for SensorAcq_T2), determined in previous steps for each critical control, communication, and security task. This integrates a set of rules governing the relationship between task timing characteristics and expected resource consumption built within the baseline policy set (e.g., rule: "IFTaskIDISSensorAcq_T2ANDNetworkLoadISLowTHENExpectedExecTime_MAX=0.6msANDExpectedCPU_MAX=6%), as well as previously set specific security configuration parameters, including the lower limit of the symmetric encryption key length (e.g., 128 bits for AES), the specific method for generating the initialization vector (e.g., it must be generated using CSPRNG), and the hash algorithm. The following criteria must be specified: a list of encryption methods (e.g., allowing SHA-256, SHA-384, SHA-512), a minimum bound on the number of iterations for the key derivation function (e.g., 100,000 for PBKDF2), a minimum salt length (e.g., minimum 16 bytes), a minimum bound on the length of the asymmetric encryption key (e.g., 2048 bits for RSA), and the standard curve parameters that must be used in elliptic curve cryptography (e.g., NISTP-256). Furthermore, the name or ID of the authorized calling process performing the encryption operation must be explicitly recorded (e.g., process SecureComm_Daemon or task Crypto_). The task and the specific location information of these encryption function calls in the code, which usually refers to the function name or the starting address of the code segment (for example, the function encrypt_data_AES is located at address 0x1004A8B0 in module libsecure.so), are obtained during the system deployment and baseline establishment phases through static analysis of source code, disassembly of binary files, or dynamic debugging in a controlled environment. All these task execution characteristics, resource consumption boundaries, timing resource association rules, and detailed encryption operation specifications are integrated together to form a comprehensive Industrial Control System (ICS) behavior specification.

[0050] The steps for obtaining the monitoring operation parameter set are as follows:

[0051] Based on the list of critical tasks defined in the ICS behavior specification, a continuous monitoring process is initiated. For each task in the list, the start timestamp is obtained in real time through the operating system scheduler interface, the completion timestamp is captured when the task is completed, and the cumulative value of the time slice allocated to the task by the central processing unit is read. At the same time, the memory manager is queried to obtain the total amount of memory currently occupied by the task, forming a real-time task data stream.

[0052] Based on the encryption function library and interface information defined in the ICS behavior specification, the original entry address of the target encryption application programming interface is replaced with the preset audit function address by modifying the global offset table entries of the target function library. When a critical process calls the encryption interface, the audit function is triggered, intercepts the encryption function library application programming interface call event, and completely copies all parameter values ​​passed to the interface during the call to obtain the original encryption call data.

[0053] Integrate the task context information provided by the real-time task data stream and process the raw encrypted call data. From the intercepted application programming interface call parameters, parse them item by item according to the parameter order and type to extract the algorithm identifier value, key handle pointer, key length value, initialization vector byte sequence, salt value byte sequence, encryption mode option code and hash digest value of input data block. Associate the extracted parameters with the corresponding task execution information to generate a monitoring operation parameter set.

[0054] Specifically, based on the critical task list explicitly defined in the ICS behavior specification (e.g., including tasks such as MotorCtrl_T1, SensorAcq_T2, and SecureComm_T3), an uninterrupted continuous monitoring process is initiated. This process, for each task marked as critical in the list, calls the task scheduler interface functions provided by the real-time operating system (e.g., sched_getparam under POSIX or APIs specific to RTOS such as VxWorks' taskInfoGet). Each time a task is activated by the scheduler and transitions from the ready state to the running state, its precise start timestamp is obtained in real time. For example, when MotorCtrl_T1 starts execution, the timestamp T_start_MotorCtrl_T1 is recorded. When the task completes its current execution cycle, is about to release CPU control, or enters a blocked / suspended state, its completion timestamp is captured again through operating system callbacks or probes, for example, T_end_MotorCtrl_T. 1. The system reads the cumulative time slice value allocated to the task by the central processing unit (CPU) since the last start from the operating system's process or task management subsystem. This can be achieved by reading the cumulative CPU time field in the task control block or querying performance counters. For example, it can obtain that MotorCtrl_T1 consumed 1.1 milliseconds of CPU time during this execution. At the same time, it obtains the total amount of physical memory currently actually occupied by the task and the peak memory usage during this execution cycle by querying the operating system's memory manager interface (e.g., reading VmRSS and VmPeak in / proc / [pid] / status, or calling the RTOS's memory information function). For example, it can obtain that SensorAcq_T2 currently occupies 300KB of memory and has a peak memory usage of 350KB. These real-time collected start timestamps, completion timestamps, cumulative CPU time slice values, and current memory usage data are associated with the corresponding task identifiers to form a continuous real-time task data stream with time-series characteristics.

[0055] Based on the target cryptographic function library (e.g., libcrypto.so or system-defined secure_api.dll) and its contained application programming interface (API) information (e.g., the names, parameter lists, and expected callers of functions AES_encrypt, RSA_sign, and SHA256_hash) previously identified in the ICS code of conduct, calls to these cryptographic APIs can be intercepted through a function entry point substitution mechanism. Specifically, in a Linux environment, for example, an auditing library can be loaded using the LD_PRELOAD mechanism of dynamic link libraries, or the Global Offset Table (GOT) or Procedure Linkage Table (PLT) entries of the target function library in memory can be directly modified to change the original entry memory address of the target cryptographic API (such as AES_encrypt). The entry address of a pre-defined audit function (audit_AES_encrypt) is replaced. When code within a critical process (such as SecureComm_Daemon specified in the ICS behavior specification) attempts to call the original AES_encrypt function, the execution flow actually jumps to the audit function audit_AES_encrypt because the entry address has been replaced. After the audit function is triggered, it is first responsible for completely copying all the actual parameter values ​​passed to the encryption interface during the call. For example, for the AES_encrypt(data_in, data_out, key_handle, iv, mode) call, the audit function will save the pointer or content digest of data_in, the value of key_handle, the actual byte sequence of iv, and the option value of mode. These parameter values ​​constitute a data snapshot of the original encryption call, thus obtaining the original encryption call data.

[0056] Integrate the task context information (e.g., the ID of the currently executing task, such as SecureComm_T3, the task's start timestamp, CPU usage, etc.) provided by the real-time task data stream generated through continuous monitoring in previous steps. Then, meticulously process the original encrypted call data intercepted and copied through the function entry point replacement mechanism. From the actual call parameters of the intercepted encrypted function library application programming interface (API), strictly follow the parameter definition order and expected data type recorded in the ICS behavior specification, parsing and extracting each item. For example, if the intercepted data is for an encrypted function such as Unified_Crypto_Process(operati... If the functions `on_id`, `key_material_ptr`, `key_len_val`, `iv_bytes`, `salt_bytes`, `mode_option`, `data_buffer`, and `data_len` are called, the auditing program will extract the following: the integer algorithm identifier value (`operation_id`, e.g., 1 for AES-128-CBC, 2 for SHA-256`), the pointer type key handle pointer (`key_material_ptr`), the numeric key length value (`key_len_val`, e.g., 128 bits or 2048 bits), and the byte sequence type initialization vector (`iv_bytes`). The encrypted operation parameters are: _bytes (e.g., a 16-byte array), a byte sequence type salt value (salt_bytes, e.g., an 8-byte array, if the current operation is key derivation or requires a salt for the encryption mode), an enumerated or integer type encryption mode option code (mode_option, e.g., 1 for CBC, 2 for GCM), and a hash digest value calculated from the input data block (the first data_len bytes of the data_buffer) (e.g., using SHA-256 to calculate the digest of the input data instead of transmitting the entire data block to reduce overhead). These extracted encryption operation-related parameters are then compared with the real-time execution information of the task to which the encryption API call belongs. Information such as task ID, execution time, and resource consumption is closely linked to form a structured record. For example, the record may contain: {TaskID: SecureComm_T3, CryptoAPI: AES_encrypt, Timestamp: T_call, AlgorithmID: AES, KeyLength: 128, IV: [0xAB, ..., 0xCD], Mode: CBC, InputDataDigest: 0x123...DEF, CPU_at_call: 15%, Mem_at_call: 400KB}, which is eventually aggregated into a set of monitoring operation parameters.

[0057] The steps to obtain the list of detected anomalies are as follows:

[0058] Based on the real-time task start timestamp, completion timestamp, CPU time slice, and memory usage in the monitoring operation parameter set, and compared with the worst execution time, deadline, CPU utilization range, and memory usage limit set in the ICS behavior specification, the execution time of each task is compared to see if it exceeds the worst execution time, whether it is completed before the deadline, and whether the CPU consumption and memory consumption of the task exceed the preset upper and lower limit envelope range. All cases that exceed the specified range are recorded to form a single-point deviation record.

[0059] Based on the algorithm identifier, key length, initialization vector, salt value, encryption mode, and input data digest extracted from the monitoring operation parameter set, and referring to the lower limit of symmetric encryption key length, initialization vector generation method, and hash algorithm selection standards set in the ICS code of conduct, the system verifies whether the key length used meets the lower limit requirement, evaluates its randomness by checking the repeatability and distribution characteristics of the initialization vector sequence, determines whether the salt value is improperly reused, verifies whether the selected encryption mode is the recommended security level, verifies whether the hash algorithm is within the selection standard list, and compares whether the actual order of calling the encryption application programming interface conforms to the standard process, and whether the calling process and code position are consistent with expectations, thus obtaining the encryption compliance verification result.

[0060] By combining the task execution time deviations and resource consumption exceedances identified in the single-point deviation records, and referring to the encryption parameter usage issues or context mismatches discovered in the encryption compliance verification results, the rule set of task timing characteristics and expected resource consumption relationships defined in the ICS behavior specification is applied to determine whether there are tasks with abnormal execution times but abnormal CPU utilization, or tasks with persistently high CPU utilization during normal execution time, and a list of detected anomalies is generated.

[0061] Specifically, based on the real-time start timestamp, completion timestamp, CPU time slice consumed by the task instance, and peak memory usage during task execution data provided by the monitoring operation parameter set for each task (e.g., critical control task PLC_Scan_Task), and comparing this with the worst-case execution time explicitly set for each task such as PLC_Scan_Task in the previously established ICS behavior specification (e.g., the worst-case execution time for PLC_Scan_Task is set to 5 milliseconds, a value obtained based on a safety factor of 1.1 times the maximum execution time observed in historical data statistics), and the absolute deadline that the task must complete (e.g., if PLC_Scan_Task... The period of k is 20 milliseconds and it is a hard real-time task. Its deadline may be set to its start timestamp plus 20 milliseconds. The system will also implement a preset normal range for CPU utilization (e.g., the CPU utilization range of PLC_Scan_Task is set to [8%, 15%], based on a historical average utilization of 10% and its standard deviation of 1.5%, using the mean plus or minus three times the standard deviation, i.e., 10% ± 3 * 1.5%, and adjusted to a reasonable 8% to 15%) and a hard upper limit for memory usage (e.g., the memory usage limit of PLC_Scan_Task is set to 256KB, based on a safety factor of 1.2 times the historical peak memory usage). The system will rigorously check each item. The comparison process begins by calculating the actual execution time of the task, which is the completion timestamp minus the start timestamp. Then, it checks if this actual execution time exceeds the worst-case execution time (e.g., if a PLC_Scan_Task actually executes for 5.2 milliseconds, it exceeds its worst-case execution time of 5 milliseconds). Next, it verifies if the task's completion timestamp is later than its specified deadline (e.g., if a PLC_Scan_Task completes 0.1 milliseconds after its due time, it is considered to have missed the deadline). Finally, it converts the CPU time slice consumed by the task in the current execution instance into the actual CPU utilization (e.g., if a PLC_Scan_Task completes in 20 millisecond cycles...). If a 3.5-millisecond CPU time slice is used during the period, the utilization rate is 17.5%. The system checks whether this utilization rate falls outside the preset range of [8%, 15%] (in this example, 17.5% exceeds the upper limit of 15%). Finally, the actual peak memory usage of the task is compared with its memory usage limit (for example, if PLC_Scan_Task actually uses 280KB of memory, it exceeds the upper limit of 256KB). Any situation in all these comparisons that exceeds the specified range or fails to meet the conditions will be recorded in detail, including the task identifier, the time of occurrence, the specific parameter name that exceeds the limit, the actual observed value, and the threshold or range set in the specification, forming a single-point deviation record.

[0062] Based on the monitoring operation parameter set, the algorithm identifier (e.g., indicating the use of AES or SHA-256), the actual key length used (e.g., 128 bits or 256 bits), the intercepted initialization vector (IV) byte sequence, the salt byte sequence used (if applicable), the selected encryption mode (e.g., CBC, GCM, or ECB), and the hash digest value of the input data are extracted for each cryptographic function library application programming interface (API) call event. This is done in accordance with the various security benchmarks predefined for cryptographic operations in the ICS Code of Conduct, including the minimum allowed key length for symmetric encryption algorithms (such as AES) (e.g., the lower limit for AES key length is set at 128 bits, this standard comes from NIST SP800-13). The system will perform a series of checks, including industry guidelines such as 1A, the correct method for generating initialization vectors (IVs) (e.g., specifying that IVs must be generated using the cryptographically secure pseudo-random number generator CSPRNG provided by the operating system, and that a new IV is used for each encryption operation), and a list of recommended and prohibited hash algorithms (e.g., the list includes SHA-256 and SHA-384, and explicitly prohibits MD5 and SHA-1; this list is based on current known cryptanalysis results and security recommendations). First, for symmetric encryption operations, the system will verify whether the actual key length used is not less than the lower limit set in the ICS code of conduct (e.g., if AES is used, the actual key length is 96 bits, while the code requires at least 1...). 28 bits (if recorded as non-compliant), secondly, by continuously collecting and analyzing the initialization vector sequences used under the same key, check for the existence of reused IVs, and assess whether their randomness complies with the requirements of the ICS Code of Conduct regarding IV generation methods through statistical tests (e.g., frequency testing or run-length testing on the collected IV samples to preliminarily assess whether they deviate from a uniform distribution). (e.g., if the same IV is used in three consecutive encryption operations, or if the IV sequence fails the basic randomness test, it is considered non-compliant). Thirdly, determine whether there is inappropriate reuse of the salt value (if the salt value is used in the current operation such as the key derivation function call). For example, for password-based key derivation, the same password should not be reused. If such reuse is detected using the same salt value, a violation is recorded. Next, it is verified whether the actual encryption mode used falls within the list of recommended security levels in the ICS Code of Conduct (e.g., if the ECB mode, considered insecure, is used, while the code recommends GCM or CBC modes, it is recorded as non-compliance). The system also verifies whether the hash algorithm used (whether directly calling a hash function or used to generate the input data digest) is within the list of selection criteria set by the ICS Code of Conduct (e.g., if the MD5 algorithm is used, but the code has disabled it, it is recorded as non-compliance). Simultaneously, the system will compare the actual order of the encryption API calls to the specified flow defined in the ICS Code of Conduct for a particular security protocol or operation (e.g., ...).A secure session establishment process might stipulate that the key negotiation interface must be called first, followed by the data encryption interface; reversing this order is non-compliant. Finally, the process identifier and code execution location initiating the encryption API call are verified against the authorized caller information pre-registered in the ICS code of conduct (for example, the code at address 0x00401F8A of the process secure_channel.exe may be allowed to call the encrypt_payload function; if the actual call originates from another process or location, it is considered non-compliant). The results of all these verification steps are combined to obtain the encryption compliance verification result.

[0063] Combining the task execution time deviations (e.g., task DataLogger_T timed out by 20 milliseconds) and resource consumption exceeding limits (e.g., task AlarmChecker_T's CPU utilization reached 35%, exceeding the preset 20% limit) identified in the previously generated single-point deviation records, and referring to encryption parameter usage issues (e.g., task SecureComm_T3 used an insufficiently long symmetric encryption key) or encryption operation context mismatches (e.g., an unauthorized process attempted to call an encryption function) revealed in the encryption compliance verification results, the system further applies the task timing characteristics and resource consumption defined in the ICS behavior specification. An expected set of rules (based on historical data statistical analysis; for example, rule R1: "If the input data volume of task SensorFusion_T is 'high' (e.g., exceeding 1000 data points / second, where 'high' is defined based on the 90th percentile of historical data distribution), then its expected maximum execution time is 15 milliseconds, and the expected peak CPU utilization is 25%"). The "high" data volume threshold of 1000 points / second is set based on the 90th percentile of the input data volume distribution in historical statistics, while 15 milliseconds and 25% are derived by adding a certain margin to the historical performance under this load.) is used for deeper anomaly detection, specifically... The discrimination logic includes checking for tasks with abnormally long execution times (e.g., SensorFusion_T actually executes for 25 milliseconds, far exceeding the expected 15 milliseconds) but whose corresponding CPU utilization is unexpectedly low (e.g., SensorFusion_T's CPU utilization is only 5%, while rule R1 expects CPU utilization to be close to 25% during longer execution times). This combination of "high execution time and low CPU utilization" may indicate potential problems such as task blocking or waiting for external resources. Another discrimination is to check whether the CPU utilization of a task during its normal, non-timeout execution time is consistently significantly higher than that under the current load conditions. The expected level of the relationship between task timing characteristics and expected resource consumption is determined by the rule set (for example, task ControlLoop_T1 completes normally within 5 milliseconds, but its CPU utilization averages 30% for 5 consecutive cycles, while the rule set stipulates that its CPU utilization should not exceed 18% under this load, where "persistence" is defined as exceeding 3 consecutive cycles, and "significantly higher" is defined as exceeding the expected upper limit by more than 50%, i.e., 18%*1.5=27%, so 30% constitutes an anomaly). All anomalies analyzed and identified through such association rules, together with the original single-point deviations and encryption non-compliance items, are collected and organized to generate a list of detected anomalies.

[0064] The steps to obtain the activated response configuration are as follows:

[0065] Based on the information of individual and related anomalies collected in the detected anomaly list, time series and logical correlation analysis are performed on multiple anomaly records to form anomaly event patterns. The patterns are then matched one by one with the feature vectors of resource exhaustion attack patterns and the time series graphs of task scheduling interference patterns in the local intrusion feature library. Based on the matching similarity and the number of rules that are met, it is determined whether the current system state constitutes a local intrusion event, and the intrusion event determination conclusion is output.

[0066] Based on the intrusion event determination conclusion, the occurrence of the local intrusion event is verified, and the status information of the abnormal tasks associated with the event in the detected anomaly list is retrieved, including the task identifier, the timestamp of the anomaly occurrence, the anomaly description, and the recorded resource usage values. Then, the priority values ​​of the affected critical control tasks in the operating system scheduling queue are adjusted to a higher level, and the CPU time slice allocation quota is restricted for tasks determined to be suspicious, forming a preliminary response action set.

[0067] Based on the severity assessment of the intrusion incident and the feedback on the execution effect of the initial response action set, if it is determined to be malicious code activity and the initial resource restrictions have failed to contain it, an instruction is sent to the operating system kernel to terminate the execution of the suspicious task process. If the real-time performance of the critical control loop has been severely affected, the device is immediately triggered to switch to a predefined fault-safe operating state and an activated response configuration is established.

[0068] Specifically, based on the individual anomalies gathered in the detected anomaly list (e.g., Task_A CPU utilization consistently at 95%) and the composite anomaly information obtained through rule-based correlation analysis (e.g., Task_B execution timeout and its dependent Task_C memory usage anomaly), the system initiates a deep analysis process of the time series and logical correlation of multiple anomaly records. First, multiple anomaly records that are temporally close (e.g., occurring within the same 5-second window) and logically potentially related (e.g., anomalies affecting tasks that share the same critical control loop or the same resource) are aggregated to form one or more specific anomaly event patterns, such as an aggregation pattern. The description states: "Within 5 seconds (T to T+5), the CPU utilization of task Comm_Handler suddenly increased from 10% to 70%, while the critical task Safety_Monitor missed its deadline three times consecutively, and the system log recorded multiple failed network connection attempts from unknown IP addresses." Subsequently, these dynamically generated abnormal event patterns were matched against known attack patterns pre-built and stored in a local intrusion signature database. This database was populated by analyzing known ICS attack cases, conducting red team drills, and referencing standard attack patterns (such as ATT & CK for ICS), and includes, for example, data... The feature vector of the source exhaustion attack pattern (e.g., a vector defined as: [Avg_CPU_Util_Sys>85%for30s, Peak_Mem_Util_Sys>90%for30s, Critical_Task_Deadline_Miss_Rate>10%for30s], where the thresholds of 85%, 90%, 10%, and 30 seconds are determined based on historical baselines and attack simulation experiments to distinguish normal fluctuations from attack behavior) and the temporal graph of the task scheduling interference pattern (e.g., a graph described as: "High-priority critical task Ctrl_Loop1 in 1 The message states, "Within 00 milliseconds, the task was preempted more than 5 times by the low-priority task Unknown_TaskX, and subsequently, the execution time jitter of Ctrl_Loop1 increased by more than 200%." ​​The thresholds for 5 preemptions and 200% jitter increase are based on analysis of normal scheduling behavior and known scheduling attack methods. The matching process employs a specific similarity calculation method. For example, for feature vector matching, weighted cosine similarity can be used. The weights are set according to the importance of the feature to the attack indication (e.g., CPU utilization weight 0.4, memory utilization weight 0.3, critical task deadline miss rate weight 0.3), and a similarity threshold is set, such as 0.The threshold of 75 was obtained through testing and optimization on labeled datasets containing known attacks and normal behavior to balance detection rate and false positive rate. For time series graph matching, a sequence matching algorithm based on edit distance or a Markov model of event sequences is used for consistency evaluation. The matching is judged based on the length of the matched subsequence or the number of matching rule nodes (e.g., if a time series graph contains 5 key event sequences and the observed pattern matches at least 4 of them, it is considered a match). Whether the calculated matching similarity exceeds a preset threshold or whether the number of matching attack rules reaches a preset number is comprehensively determined to determine whether the overall state of the current system constitutes one or more local intrusion events, and an intrusion event determination conclusion is output.

[0069] Based on the intrusion event determination conclusion output in the previous step (e.g., determined to be "resource exhaustion attack, caused by task Anomaly_Process_XYZ, affecting critical task Safety_Critical_Task_A"), the occurrence of the local intrusion event is first confirmed. Immediately, all abnormal task status information directly related to the determined event is retrieved from the list of detected anomalies. This information includes, but is not limited to, the unique identifier of the suspicious or affected task (e.g., Anomaly_Process_XYZ, Safety_Critical_Task_A), the precise timestamp of the first detection of the anomaly, a textual description of the abnormal behavior (e.g., "CPU utilization consistently above 90% for over 60 seconds," "five consecutive missed execution deadlines"), and recorded specific resource usage values ​​(e.g., Anomaly_Process_XYZ's average CPU utilization is 92%, peak memory usage is 500MB). Based on this information, the system immediately initiates predefined preliminary response measures. For the identified affected critical control task (e.g., Safety_Critical_Task_A), control commands are sent to the operating system scheduler to adjust its scheduler. The priority values ​​in the priority queue are dynamically adjusted to a higher level. For example, if the operating system priority range is 0 to 255, and the normal priority of Safety_Critical_Task_A is 200, its priority can be increased to 240 to ensure its execution. This increase (e.g., adding 40 points or increasing to the second highest priority allowed by the system) is preset in the response strategy based on the criticality of the task. At the same time, for tasks that are judged to be suspicious and cause intrusion events (such as Anomaly_Process_XYZ), the system will impose strict CPU time slice allocation limits on them. For example, through the resource control mechanisms provided by the operating system (such as Linux cgroups' CPU quota or the task-level resource budget function of a specific RTOS), the upper limit of the CPU time they can use is forcibly set to a low percentage, such as no more than 2% of the total CPU capacity of the system. The principle of this limit (e.g., 2%) is to significantly weaken its activity while avoiding system instability that may be caused by completely depriving it of CPU (unless the task is known to be purely malicious). These actions of adjusting priority and limiting CPU quota are recorded together to form an initial set of response actions.

[0070] Based on the severity level assessment included in the previously obtained intrusion event judgment conclusions (e.g., an intrusion event that causes the failure of critical security functions is rated as "critical," while an event that only affects non-core data logging tasks is rated as "moderate," this level is determined by the potential impact pre-associated with each feature pattern in the intrusion feature database; for example, any event matching the "critical control loop interference" feature pattern is automatically set to "high" or "critical") and continuous monitoring and feedback on the execution effect of the initial response action set already executed (e.g., after increasing the priority of Safety_Critical_Task_A and limiting the CPU quota of Anomaly_Process_XYZ, the system will, within the next 60 seconds, collect the execution time and resource usage data of Safety_Critical_Task_A again to determine whether it has returned to normal operation; for example, whether its deadline compliance rate has rebounded to above 99%, where 99% is the preset recovery target threshold). The observation window is 60 seconds, which is also the preset evaluation period. If, after comprehensive evaluation, the root cause of the current intrusion event is determined to be malicious code activity (this determination is based on the labeling of specific attack patterns in the intrusion signature database, for example, a certain feature pattern is marked as "known ransomware behavior"), and the previously applied preliminary resource restriction measures (such as CPU quota restrictions) have failed to effectively curb the abnormal behavior of the suspicious task after the set evaluation period (such as 60 seconds) (for example, Anomaly_Process_XYZ is still trying to bypass the restrictions in other ways, or the performance index of the critical task Safety_Critical_Task_A has not yet recovered to more than 99% of the recovery target threshold), then the system will execute a more aggressive response, that is, send an explicit instruction to the operating system kernel through standard system calls or direct kernel interfaces to forcibly terminate the execution of the process identified as a suspicious task (Anomaly_Process_XYZ) (for example, executing kill-SIGKILL in a Linux system). <pid>On the other hand, if monitoring data shows that the real-time performance of critical control loops (e.g., the actual completion time of the periodic task MainCtrlLoop of the main control loop consistently exceeds its worst execution time by 30%, and the control accuracy deviation exceeds the allowable range by 5%, where 30% and 5% are preset severe impact thresholds set based on system security requirements and failure mode analysis) has been severely affected and cannot be quickly corrected by the initial response, or if the initial severity level of the intrusion event is assessed as "critical" and directly threatens core security functions, then the system will no longer wait for the full evaluation cycle of the initial response, but will immediately trigger the device to switch to a predefined, safe failsafe operating state (e.g., for a motion control device, this includes stopping all motor movement, activating all brakes, and recording the system status as "emergency shutdown"; this state and switching procedure have been clearly defined in the system design phase), or execute a controlled restart procedure aimed at restoring the system to a known safety baseline. These actions, such as escalating and executing termination processes, entering failsafe states, or controlled restarts as appropriate, are recorded and managed together with the previous initial response to establish an activated response configuration.

[0071] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.< / pid>

Claims

1. A method for security auditing of an industrial control system, characterized in that, Includes the following steps: For critical control, communication, and security tasks of the real-time operating system, data on cycle time, start timestamp, completion timestamp, CPU time slice usage, and peak memory usage are collected. Worst-case execution time, best-case execution time, scheduling jitter range, CPU utilization range, and memory usage limit are set. Historical data statistics and logical rule deduction are used to construct a rule set on the relationship between task timing characteristics and expected resource consumption. At the same time, the lower limit of symmetric encryption key length, initialization vector generation method, hash algorithm selection standard, lower limit of key derivation function iteration number, lower limit of asymmetric encryption key length, elliptic curve cryptosystem curve parameters, and encryption operation call process and code location are set to establish ICS behavior specifications. Based on the aforementioned ICS behavior specifications, the system continuously acquires the real-time start timestamp, completion timestamp, CPU time slice, and memory usage of critical tasks. It also uses a function entry point replacement mechanism to intercept application programming interface (API) call events of the encryption function library, parses the API call parameters, extracts the algorithm identifier, key handle, key length, initialization vector, salt value, encryption mode, and input data digest, and generates a set of monitoring operation parameters. Based on the monitoring operation parameter set and the ICS behavior specification, the actual execution time of the task is compared with the worst execution time and the deadline. The CPU consumption and memory consumption of the task are compared with the preset envelope. The encrypted application programming interface call parameters are verified, specifically the key length, initialization vector randomness, salt reuse, encryption mode security level and hash algorithm strength. At the same time, the order of application programming interface calls and the location of the calling process code are checked. The timing resource association rules are applied to determine whether there is an unexpected combination between the task execution time and the CPU utilization rate, and a list of detected anomalies is generated. Based on the detected anomaly list, multiple anomaly records are aggregated and compared with a preset local intrusion feature library, which includes resource exhaustion attack mode and task scheduling interference mode. It is determined whether a local intrusion event has occurred, and the abnormal task status information and resource usage values ​​are recorded. The priority values ​​of affected critical control tasks are adjusted, the CPU allocation quota for suspicious tasks is limited, and the process of suspicious tasks is terminated. For cases where critical control loops are affected, the device is triggered to a preset fault-safe state or a controlled restart procedure is executed, and an activated response configuration is established.

2. The industrial control system security audit method according to claim 1, characterized in that, The steps for obtaining the ICS behavioral guidelines are as follows: For critical control, communication, and security tasks in a real-time operating system, periodic data is directly read through kernel hooks. The start timestamp and completion timestamp of each task scheduling are captured using timers. The CPU time slice values ​​are obtained by querying system performance counters. Peak memory usage data during dynamic allocation and release of memory during task execution is recorded. The collected data is organized and archived. The execution time boundaries of each task are defined, including the worst execution time and the best execution time, as well as the allowable range of jitter in the scheduling cycle. The upper and lower limits of CPU utilization and the upper limit of memory usage are set to generate a set of basic task parameters. Based on the historical period, start timestamp, completion timestamp, CPU time slice, and peak memory usage data recorded in the task basic parameter set, a stable correspondence pattern between the timing characteristics and resource consumption of the task under different load conditions is identified. This pattern is then deduced and solidified into a set of rules for the expected relationship between the timing characteristics and resource consumption of the task. Simultaneously, the minimum bit length of the key for the symmetric encryption algorithm is determined, the initialization vector must be generated by the target random number generator, a list of secure hash algorithms is specified, the minimum number of iterations and salt length of the key derivation function are set, the minimum bit length of the key for the asymmetric encryption algorithm and the standard curve parameters that must be used in the elliptic curve cryptosystem are defined, and a baseline strategy set is obtained. Based on the task basic parameter set, which includes the worst execution time, best execution time, scheduling jitter range, CPU utilization range, and memory usage limit for each task, and integrating the task timing characteristics and expected resource consumption relationship rule set constructed in the baseline policy set, as well as the set of symmetric encryption key length lower limit, initialization vector generation method, hash algorithm selection standard, key derivation function iteration number lower limit, asymmetric encryption key length lower limit, elliptic curve cryptosystem curve parameters, and encryption operation call process and code location, the ICS behavior specification is jointly established.

3. The industrial control system security audit method according to claim 1, characterized in that, The steps for obtaining the monitoring operation parameter set are as follows: Based on the list of critical tasks defined in the ICS behavior specification, a continuous monitoring process is initiated. For each task in the list, the start timestamp is obtained in real time through the operating system scheduler interface, the completion timestamp is captured when the task is completed, and the cumulative value of the time slice allocated to the task by the central processing unit is read. At the same time, the memory manager is queried to obtain the total amount of memory currently occupied by the task, forming a real-time task data stream. Based on the encryption function library and interface information determined in the ICS behavior specification, the original entry address of the target encryption application programming interface is replaced with the preset audit function address by modifying the global offset table entries of the target function library. When the critical process calls the encryption interface, the audit function is triggered, intercepts the encryption function library application programming interface call event, and completely copies all parameter values ​​passed to the interface during the call to obtain the original encryption call data. The task context information provided by the real-time task data stream is integrated, and the raw encrypted call data is processed. From the intercepted application programming interface call parameters, the parameters are parsed one by one according to the parameter order and type to extract the algorithm identifier value, key handle pointer, key length value, initialization vector byte sequence, salt value byte sequence, encryption mode option code, and hash digest value of input data block. The extracted parameters are associated with the corresponding task execution information to generate a monitoring operation parameter set.

4. The industrial control system security audit method according to claim 1, characterized in that, The steps for obtaining the list of detected anomalies are as follows: Based on the real-time task start timestamp, completion timestamp, CPU time slice, and memory usage in the monitoring operation parameter set, and compared with the worst execution time, deadline, CPU utilization range, and memory usage limit set in the ICS behavior specification, the execution time of each task is compared to see if it exceeds the worst execution time, whether it is completed before the deadline, and whether the CPU consumption and memory consumption of the task exceed the preset upper and lower limit envelope range. All cases that exceed the specified range are recorded to form a single-point deviation record. Based on the algorithm identifier, key length, initialization vector, salt value, encryption mode, and input data digest extracted from the monitoring operation parameter set, and referring to the lower limit of symmetric encryption key length, initialization vector generation method, and hash algorithm selection standards set in the ICS code of conduct, the system verifies whether the key length used meets the lower limit requirement, evaluates its randomness by checking the repeatability and distribution characteristics of the initialization vector sequence, determines whether the salt value is improperly reused, verifies whether the selected encryption mode is the recommended security level, verifies whether the hash algorithm is within the selection standard list, and compares whether the actual order of calling the encryption application programming interface conforms to the standard process, and whether the calling process and code position are consistent with expectations, thus obtaining the encryption compliance verification result.

5. The industrial control system security audit method according to claim 4, characterized in that, The steps for obtaining the list of detected anomalies also include: Combining the task execution time deviations and resource consumption exceedances identified in the single-point deviation records, and referring to the encryption parameter usage issues or context mismatches discovered in the encryption compliance verification results, the rule set of task timing characteristics and expected resource consumption relationships defined in the ICS behavior specification is applied to determine whether there are abnormal task execution times but abnormal CPU utilization, or whether the CPU utilization of the task is consistently too high during normal execution time, and a list of detected anomalies is generated.

6. The industrial control system security audit method according to claim 1, characterized in that, The steps for obtaining the activated response configuration are as follows: Based on the individual and related anomaly information collected in the detected anomaly list, time series and logical correlation analysis are performed on multiple anomaly records to aggregate them into anomaly event patterns. The patterns are then matched one by one with the resource exhaustion attack pattern feature vector and task scheduling interference pattern time series graph preset in the local intrusion feature library. Based on the matching similarity and the number of rules that are met, it is determined whether the current system state constitutes a local intrusion event, and the intrusion event determination conclusion is output. The occurrence of a local intrusion event is verified based on the intrusion event determination conclusion. The status information of the abnormal tasks associated with the event is retrieved from the list of detected anomalies, including the task identifier, the timestamp of the anomaly occurrence, the anomaly description, and the recorded resource usage values. The priority values ​​of the affected critical control tasks in the operating system scheduling queue are then adjusted to a higher level. At the same time, the CPU time slice allocation quota is restricted for tasks determined to be suspicious, forming a preliminary set of response actions.

7. The industrial control system security audit method according to claim 6, characterized in that, The step of obtaining the activated response configuration also includes: Based on the severity level assessment of the intrusion event determination conclusion and the feedback on the execution effect of the preliminary response action set, if it is determined to be malicious code activity and the preliminary response action set fails to contain it, an instruction is sent to the operating system kernel to terminate the execution of the suspicious task process. If the real-time performance of the critical control loop has been severely affected, the device is immediately triggered to switch to a predefined fault-safe operating state and an activated response configuration is established.

8. The industrial control system security audit system according to any one of claims 1-7, characterized in that, include: The data collection and specification construction module collects data on the cycle, start timestamp, completion timestamp, CPU time slice, and peak memory usage for critical control, communication, and security tasks of the real-time operating system. It sets the worst-case execution time, best-case execution time, scheduling jitter range, CPU utilization range, and memory usage limit for each task. It also uses historical data statistics and logical rule deduction to construct a rule set on the relationship between task timing characteristics and expected resource consumption. In addition, it sets the lower limit for symmetric encryption key length, initialization vector generation method, hash algorithm selection standard, lower limit for key derivation function iteration count, lower limit for asymmetric encryption key length, elliptic curve cryptosystem curve parameters, and encryption operation call process and code location to establish ICS behavior specifications. The real-time monitoring and parameter extraction module, based on the ICS behavior specification, continuously acquires the real-time start timestamp, completion timestamp, CPU time slice, and memory usage of key tasks. It also uses a function entry point replacement mechanism to intercept application programming interface (API) call events of the encryption function library, parses the API call parameters, extracts the algorithm identifier, key handle, key length, initialization vector, salt value, encryption mode, and input data digest, and generates a monitoring operation parameter set. The anomaly comparison and auditing module, based on the monitoring operation parameter set and the ICS behavior specification, compares the actual execution time of the task with the worst execution time and the deadline, compares the CPU consumption and memory consumption of the task with the preset envelope, and verifies the encrypted application programming interface call parameters, specifically the key length, initialization vector randomness, salt reuse, encryption mode security level and hash algorithm strength. At the same time, it checks the application programming interface call order and the location of the calling process code, and applies time-series resource association rules to determine whether there is an unexpected combination between the task execution time and CPU utilization, and generates a list of detected anomalies. The intrusion response and handling module, based on the detected anomaly list, aggregates multiple anomaly records, compares them with a preset local intrusion feature library, which includes resource exhaustion attack mode and task scheduling interference mode, determines whether a local intrusion event has occurred, records the abnormal task status information and resource usage values, adjusts the priority values ​​of affected critical control tasks, limits the CPU allocation quota for suspicious tasks, terminates the process of suspicious tasks, and, for cases where critical control loops are affected, triggers the device to a preset fault-safe state or executes a controlled restart procedure, and establishes an activated response configuration.

Images