Industrial switch firmware security protection system, method and storage medium

Abstract

The application relates to the technical field of communication network security, and particularly discloses an industrial switch firmware security protection system and method and a storage medium. The system is deployed on an embedded hardware platform and comprises a hardware monitoring module, a policy analysis and arbitration module and a security event processing module. The hardware monitoring module bypasses and monitors a memory bus through FPGA logic, detects and intercepts illegal access to a key memory area of the firmware in real time according to programmable rules. The policy analysis and arbitration module intelligently analyzes and evaluates the confidence degree of a violation event based on a dynamic behavior baseline, and matches a multi-level response strategy. The security event processing module atomically executes a processing instruction, realizes a hierarchical response from log recording to controlled system reset, and backs up a system state when necessary to guarantee business continuity. The system realizes independent operating system, low overhead, high real-time and accurate adaptive industrial switch firmware security protection.

Description

Technical Field

[0001] This invention belongs to the field of communication network security technology, and specifically relates to an industrial switch firmware security protection system, method and storage medium. Background Technology

[0002] In the field of industrial automation and intelligent manufacturing, industrial switches serve as the core hub of network communication, and their stability and security are of paramount importance. With the deepening development of the Industrial Internet, network attacks targeting industrial control systems are increasing. Attacks on switch firmware are particularly dangerous because they directly threaten the underlying hardware. Therefore, the security protection of industrial switch firmware has become a key link in the industrial network security system.

[0003] Runtime security protection of industrial switch firmware is a core technological direction for ensuring its continuous and stable operation. This technology aims to monitor the firmware execution process on the embedded hardware platform in real time, especially controlling access to critical memory areas to prevent malicious code tampering or execution, thereby ensuring that the switch's control logic and data forwarding functions are not compromised.

[0004] Existing technologies primarily achieve memory protection through software-level security modules, such as deploying security enhancement tools at the operating system level. However, this approach has significant drawbacks: the software monitoring mechanism itself runs on top of the operating system, and the execution of its detection logic relies on frequent context switching, which introduces unacceptable performance overhead and latency in the high real-time requirements of industrial switches.

[0005] Furthermore, software-level monitoring is easily bypassed or directly disabled by malicious code with higher privileges, leading to protection failure. More critically, existing software tools, due to insufficient detection granularity and real-time performance, struggle to accurately and seamlessly intercept unauthorized writes to core memory areas such as the interrupt vector table during firmware operation. This makes them highly susceptible to false positives or false negatives in complex industrial real-time traffic processing scenarios, thus failing to effectively defend against targeted attacks against the firmware's underlying layers. Therefore, how to achieve reliable and efficient detection and protection against unauthorized access to critical firmware memory areas without affecting the real-time performance of industrial switches is a pressing technical challenge that needs to be addressed. Summary of the Invention

[0006] The purpose of this invention is to provide an industrial switch firmware security protection system, method, and storage medium to solve the technical contradictions of existing software-level security protection mechanisms, which rely on the operating system, introduce high performance overhead, are easily bypassed, and lack real-time and accuracy in detecting illegal access to key memory areas at the firmware level.

[0007] This invention provides an industrial switch firmware security protection system. The system is deployed on the embedded hardware platform of the industrial switch and works in conjunction with the switch's central processing unit, system memory and peripheral bus.

[0008] The system includes a hardware monitoring module, a policy parsing and arbitration module, and a security incident handling module.

[0009] The hardware monitoring module is implemented using field-programmable gate array (FPGA) logic circuits and is directly mounted on the system memory bus.

[0010] This module is used for uninterrupted bypass monitoring of all read and write transactions on the system memory bus. The hardware monitoring module has a built-in programmable address range register set and access attribute register.

[0011] The address range register group is used to configure the physical start and end addresses of the critical memory regions that need to be protected. These critical memory regions include at least the memory segment where the interrupt vector table is located, the firmware code segment, and the critical configuration data area.

[0012] The access attribute register is used to define the legal access modes for the above-mentioned protected areas. The legal access modes include the allowed access types, allowed access source identifiers, and allowed access time windows.

[0013] The hardware monitoring module's listening logic continuously compares the target address of a memory bus transaction with the address range register group, and compares the transaction's access attributes with the valid patterns defined in the access attribute register.

[0014] When a target address is detected to fall into a protected area and its access attributes do not match any of the legal patterns, the hardware monitoring module immediately generates a hardware anomaly event signal. This signal contains detailed information about the violation and simultaneously freezes the current violation memory bus cycle through its built-in hardware latch.

[0015] The policy parsing and arbitration module runs in an independent and protected secure kernel on the central processing unit. This secure kernel is loaded by the root of trust at system startup and has greater privileges than the general operating system of the switch.

[0016] The strategy parsing and arbitration module is used to receive and parse hardware abnormal event signals reported by the hardware monitoring module.

[0017] This module maintains a dynamic behavior baseline database and a multi-level response strategy library.

[0018] The dynamic behavior baseline database is built by learning the firmware operation mode of industrial switches under normal operating conditions through machine learning algorithms. Its recorded content includes the frequency, sequence and data pattern characteristics of different functional modules accessing specific memory areas within a specific time window.

[0019] The multi-level response strategy library defines a sequence of instructions for handling different types and confidence levels of violation events.

[0020] The workflow of the strategy analysis and arbitration module is as follows: First, based on the detailed information of the violation in the hardware anomaly event signal, query the dynamic behavior baseline database, calculate the deviation of the current violation from the historical normal baseline, and generate a confidence score.

[0021] Subsequently, by combining the confidence score with the type of violation, a multi-level response strategy library was queried to match the corresponding sequence of handling instructions.

[0022] The security incident handling module also runs within the aforementioned security kernel and interacts directly with the policy parsing and arbitration module and the hardware monitoring module.

[0023] The security incident handling module is used to execute the sequence of handling instructions issued by the policy parsing and arbitration module.

[0024] This module has the ability to dynamically reconfigure the registers of the hardware monitoring module, as well as the ability to perform controlled writes to some registers of the system memory and the central processing unit.

[0025] The sequence of instructions includes, but is not limited to, the following atomic operations: instructing the hardware monitoring module to temporarily expand or shrink the protection scope of a specific memory region; The instruction hardware monitoring module can impose access bans on specific access sources; Write a complete record of the violation event to the preset security log area in system memory; Trigger the controlled system watchdog reset signal, which takes effect after the critical state backup is completed; Injecting breakpoints into specific debug registers of the central processing unit redirects execution flow to audit routines in the secure kernel.

[0026] Furthermore, the programmable address range register set of the hardware monitoring module supports the parallel definition of multiple sets of protection regions.

[0027] Each set of protected area configurations is associated with an independent priority identifier.

[0028] When the address ranges of multiple protection zones overlap, the arbitration logic of the hardware monitoring module determines the access control rules that apply to the overlapping zone based on the priority identifier, with the rule with higher priority overriding the rule with lower priority.

[0029] This design allows for differentiated, fine-grained protection of the same physical memory region based on different security contexts.

[0030] Furthermore, the access source identifier defined in the access attribute register of the hardware monitoring module is directly mapped to the current execution privilege level of the central processing unit, the current process identifier, and the specific hardware controller identifier that initiated the access.

[0031] By unifying the encoding of the software execution context with the hardware initiator, precise tracing of the source of memory access behavior is achieved, effectively distinguishing between normal scheduling by the operating system kernel, legitimate operations by firmware drivers, and illegal behavior by potentially malicious code.

[0032] Furthermore, the process of establishing the dynamic behavior baseline database in the strategy analysis and arbitration module is as follows.

[0033] During the deployment and learning phase of the industrial switch, the hardware monitoring module was configured to listen but not intercept, continuously collecting memory access stream data.

[0034] The collected data is sent to the policy parsing and arbitration module, which uses a density-based clustering algorithm to perform unsupervised learning on the access flow, automatically identify multiple memory access pattern clusters corresponding to different working states of the switch, and extract the core feature vector and boundary threshold for each pattern cluster to form an initial behavior baseline.

[0035] During normal operation, the database employs an incremental learning mechanism to smoothly update baseline parameters for access behaviors that conform to existing baseline patterns, and to carefully evaluate and conditionally include emerging new patterns.

[0036] Furthermore, the multi-level response strategy library of the strategy parsing and arbitration module is organized using a tree-like decision structure.

[0037] The root node of the tree-like decision-making structure represents the type of violation event, the child nodes represent the confidence score range, and the leaf nodes represent the specific sequence of handling instructions.

[0038] This architecture supports dynamic loading and updating of policies. The update process is driven by a digitally signed policy configuration file and takes effect after verification within the secure kernel.

[0039] This design enables the system's response strategy to adapt to changes in different security threat situations, and the update process itself is secure and controllable.

[0040] Furthermore, the process of the security incident handling module executing the sequence of handling instructions is atomic and cannot be interrupted by the general operating system.

[0041] Before performing any operation that may affect the continuity of the system, such as triggering a controlled reset, this module must first complete a preset state saving process.

[0042] The on-site data storage process includes encrypting and storing the current critical network connection status information, pointers to unforwarded data packets, and the contents of critical configuration registers in a battery-powered static random access memory. This ensures that the system can quickly reconstruct the pre-interruption business state after recovery, minimizing the impact of security incidents on the real-time services of industrial switches.

[0043] This invention also provides a method for protecting the firmware of industrial switches applied to the above-mentioned system. The method utilizes the aforementioned industrial switch firmware security protection system to achieve firmware security protection for industrial switches, and includes the following steps: Step 1: System initialization.

[0044] After the industrial switch is powered on, the root of trust first loads and runs the security kernel, and initializes the policy parsing and arbitration module and the security event handling module.

[0045] Subsequently, the security kernel loads the protected memory region configuration and initial security policy from the encrypted storage medium, and programs them into the address range register group and access attribute register of the hardware monitoring module through the security event handling module.

[0046] After configuration is complete, the hardware monitoring module releases the freeze on the memory bus cycle, and the switch enters normal operation and protection mode.

[0047] Step 2, Real-time Monitoring and Violation Detection. The hardware monitoring module continuously bypasses and listens to the system memory bus during switch operation.

[0048] For each memory access transaction, the hardware monitoring module compares its target address with the address range of all configured protected regions.

[0049] If the target address is not within any protected area, the transaction is allowed.

[0050] If the target address falls into a protected area, the access type, access source identifier, and timestamp of the transaction are further compared to see if they match any of the valid patterns defined in the access attribute register for that area.

[0051] If the match is found, the request is allowed; if the match is not found, a hardware exception event signal is immediately generated, and the current bus cycle is latched.

[0052] Step 3: Event analysis and strategy arbitration.

[0053] The hardware monitoring module transmits hardware abnormal event signals to the policy parsing and arbitration module through a dedicated hardware interrupt signal.

[0054] The strategy analysis and arbitration module analyzes event details, queries the dynamic behavior baseline database, calculates the deviation of the current violation from the historical normal pattern, and generates a confidence score based on predefined rules.

[0055] Subsequently, using violation type and confidence score as indexes, the multi-level response strategy library is queried to match the corresponding sequence of handling instructions.

[0056] Step 4, safety procedures and system recovery.

[0057] The strategy parsing and arbitration module issues a sequence of handling instructions to the security incident handling module.

[0058] The security incident handling module executes this sequence atomically.

[0059] For minor violations that only require recording or adjusting monitoring policies, after performing operations such as logging or dynamically reconfiguring the hardware monitoring module registers, the hardware monitoring module is notified to release the latched bus cycle, and the system continues to run.

[0060] For serious violations that are deemed highly suspicious or confirmed as attacks, the security incident handling module initiates a site preservation process, backing up critical operational states to persistent storage, and then performs a controlled system reset or boots into deep audit mode.

[0061] During the system recovery phase, the security kernel prioritizes checking the status of the backup and restores services accordingly, ensuring that the impact of protection actions on real-time services is minimized.

[0062] Furthermore, the confidence score calculation process in step 3 adopts a weighted scoring mechanism.

[0063] This mechanism assigns different weights to multiple dimensions of the violation's characteristics, including but not limited to: Whether the access source is appearing in the protected area for the first time, whether the access occurs outside the time window when the area is usually active, and whether the access data pattern is significantly different from the historical pattern recorded in the baseline.

[0064] The strategy analysis and arbitration module integrates the matching results of various dimensions and preset weights, and calculates the final confidence score through weighted summation. The score range is from 0 to 100, and the higher the value, the greater the possibility that the violation is a malicious attack.

[0065] Furthermore, the on-site preservation process in step 4 specifically includes: The security incident handling module first saves the contents of the register group related to the currently active network session in the central processing unit to the backup area through direct memory access; Subsequently, the network packet processing engine is paused, and a snapshot of the packet queue descriptors to be processed is saved. Finally, the complete register status of the current violation event is saved in the hardware monitoring module.

[0066] All saved data is encrypted using a key held by the secure kernel and accompanied by a message authentication code to ensure the integrity and confidentiality of the backup data.

[0067] The present invention also provides a storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described industrial switch firmware security protection method.

[0068] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention employs a hardware monitoring module implemented using a field-programmable gate array (FPGA) and directly mounts it onto the memory bus for bypass monitoring, achieving nanosecond-level real-time detection and interception of memory access behavior. This module is independent of the operating system, requires no context switching, eliminates the performance overhead and latency associated with software solutions, and meets the high real-time requirements of industrial switches. Furthermore, the hardware-implemented protection logic cannot be disabled or bypassed by any software running on the processor, providing a higher level of security.

[0069] 2. This invention elevates security protection from simple rule matching to intelligent behavior analysis and decision-making by constructing a policy parsing and arbitration module running on an independent security kernel, and introducing a dynamic behavior baseline database based on machine learning and a tree-structured multi-level response policy library. The system can distinguish between accidental misoperations and intentional attacks, and take tiered response measures based on event confidence levels. This reduces the risk of business interruption due to false alarms while ensuring security, and enhances the accuracy and adaptability of protection.

[0070] 3. The security incident handling module designed in this invention possesses atomic execution and state backup and recovery capabilities. This module can fully save the critical state of the system before performing aggressive actions such as reset, and quickly reconstruct services after recovery. This mechanism enables the system to achieve the most thorough security isolation and recovery at the cost of minimal service interruption time when facing severe attacks, ensuring the service continuity requirements of industrial switches as the core hub of the network, and resolving the inherent contradiction between security protection and high availability. Attached Figure Description

[0071] Figure 1 This is an overall architecture diagram of the industrial switch firmware security protection system proposed in this invention; Figure 2 This is a schematic diagram of the internal structural framework of the hardware monitoring module in this invention; Figure 3 This is a schematic diagram of the internal structure framework of the strategy parsing and arbitration module in this invention; Figure 4 This is the execution flowchart of the security incident handling module in this invention; Figure 5 This is a diagram showing the collaborative operation of system modules in this invention. Detailed Implementation

[0072] This embodiment details a specific implementation of an industrial switch firmware security protection system. Please refer to the appendix. Figures 1 to 5 The system is deployed on an embedded hardware platform of an industrial switch, and its core components include a hardware monitoring module, a policy parsing and arbitration module, and a security incident handling module.

[0073] These three modules work together, closely integrated with the switch's central processing unit, system memory, and peripheral bus, to jointly build a complete protection loop from hardware-level monitoring to intelligent policy decision-making and atomic security handling.

[0074] First, the system's hardware foundation and initialization process will be described in detail.

[0075] The embedded hardware platform of an industrial switch typically includes one or more central processing units (CPUs), system memory, field-programmable gate arrays (FPGAs), various peripheral buses, and application-specific integrated circuits (ASICs) for network packet switching. In this system, the FPGA is specifically used to implement the hardware monitoring module.

[0076] The system memory is a dynamic random access memory, and its physical address space is pre-planned, including the memory segment where the interrupt vector table is located, the firmware code segment, and critical configuration data areas that require special protection.

[0077] After the system is powered on and started, the trusted root embedded in the hardware platform will start first.

[0078] The root of trust verifies and loads an independent and protected security kernel into a reserved, physically isolated area in the system memory, and ensures that the security kernel runs on the central processing unit with the highest privilege level, with privileges greater than the general operating system of the switch that will be loaded later.

[0079] The physical isolation, permission isolation, startup timing, and mutual exclusion mechanisms of the security kernel are implemented in the following ways: Physical memory isolation: The physical address space of system memory is pre-divided into secure and insecure zones at the hardware level. The secure zone is a reserved physical memory area accessible only to the secure kernel, with a capacity of no less than 15% of the total system memory. Access control for this zone is implemented by the hardware security extension mechanism of the memory management unit. Read and write operations can only be performed on the secure zone memory when the central processing unit is in the highest privilege level of security state. The general-purpose operating system runs in the insecure zone. Any access request it initiates to the secure zone memory will be directly intercepted and rejected by the memory management unit, and it cannot access the secure kernel's code, data, and runtime stack space.

[0080] Privilege level isolation: The central processing unit (CPU) adopts the exception level division mechanism of the ARM architecture or the privilege ring mechanism of the x86 architecture. The secure kernel runs at the highest privilege level (EL3 level of the ARM architecture, and the secure submode of the Ring 0 ring of the x86 architecture), the general-purpose operating system kernel runs at the second highest privilege level (EL2 level of the ARM architecture, and the insecure submode of the Ring 0 ring of the x86 architecture), and the user-mode processes of the general-purpose operating system run at the lowest privilege level. The secure kernel has full configuration permissions for all system control registers, memory management unit, interrupt controller and peripheral bus of the CPU. It can directly intercept, block or redirect privileged operations initiated by the general-purpose operating system. The general-purpose operating system cannot modify or access the privilege configuration of the secure kernel, nor can it elevate its own privilege level to the level of the secure kernel, ensuring that the privileges of the secure kernel are always higher than those of the general-purpose operating system.

[0081] Booting sequence and mutual exclusion switching mechanism: The system adopts a chained trusted boot sequence. The specific process is as follows: After power-on reset, the CPU's instruction pointer first points to the solidified code entry point of the root of trust. After the root of trust completes its self-verification, the root of trust verifies the integrity of the secure kernel image using the SM3 algorithm and verifies the digital signature of the secure kernel image using the SM2 algorithm. Only when both integrity verification and signature verification pass will the secure kernel be loaded into the secure area memory, and the control of the CPU be transferred to the secure kernel. After the secure kernel completes its own initialization, policy parsing and arbitration module initialization, security event handling module initialization, and hardware monitoring module configuration, it will then perform integrity verification and signature verification on the image of the general operating system. After the signature verification passes, only the non-secure state control of the CPU is transferred to the general operating system, which will then complete the subsequent boot process. During the entire boot process, if any verification or signature verification fails, the root of trust or the secure kernel will immediately terminate the boot process and trigger hardware-level security locking to prevent the execution of untrusted images. During operation, the security kernel and the general-purpose operating system employ an exclusive context switching mechanism triggered by hardware interrupts. Only when the security kernel receives a high-priority hardware interrupt from the hardware monitoring module or when the preset security audit trigger conditions are met will it preempt control of the central processing unit, suspend all execution flows of the general-purpose operating system, enter the security state to execute security analysis and handling logic, and then resume the execution flow of the general-purpose operating system. The general-purpose operating system cannot actively trigger the switch to the security state, nor can it interfere with, suspend, or tamper with the execution process of the security kernel, thus achieving mutual exclusion and isolation between the two processes and ensuring that the high-privilege execution logic of the security kernel cannot be bypassed by the general-purpose operating system.

[0082] Once the security kernel is loaded, the policy parsing and arbitration module and the security event handling module running within it are immediately initialized.

[0083] The initialization process includes allocating dedicated memory space for the two modules, setting up internal data structures, and establishing queue and semaphore mechanisms for inter-module communication.

[0084] Subsequently, the system enters the security configuration loading phase.

[0085] The security kernel reads the initial security policy configuration file from an encrypted storage medium through the security event handling module.

[0086] The configuration file is protected for integrity using a digital signature, and the secure kernel must verify its signature before loading.

[0087] The configuration file mainly consists of two parts: The first is a list defining the physical address ranges of the protected critical memory regions, and the second is the initial legal access pattern rules for these regions.

[0088] The security incident handling module parses the configuration file and, through a dedicated, high-bandwidth, low-latency configuration bus, programs the address range information into the address range register group inside the hardware monitoring module and programs the access rules into the access attribute register.

[0089] The address range register set consists of multiple register pairs, each containing a start address register and an end address register, used to define a contiguous physical memory protection region.

[0090] For example, the first set of registers can be configured as the start and end addresses of the firmware code segment, and the second set of registers can be configured as the start and end addresses of the interrupt vector table region.

[0091] The access attribute register is more complex, as it associates one or more combination access mode entries with each configured protection zone.

[0092] Each valid access pattern entry contains three core fields: The allowed access type field, whose value is either read or write or read and write; Allowed access source identifier field, which is a composite encoding; The allowed access time window field can be a wildcard that is always allowed, or it can be a specific time period definition.

[0093] The encoding mechanism of the access source identifier is the key to the system's accurate traceability.

[0094] This encoding is directly mapped to the source identifier signal carried in the system memory bus transaction, which is automatically attached by the central processing unit or direct memory access controller when an access is initiated.

[0095] The encoding rule is to combine and hash the privilege level currently being executed by the central processing unit, the identifier of the currently active process or thread, and the identifier of the specific hardware controller that initiated this access to generate a unique access source identifier code.

[0096] For example, the access source identifiers generated when the operating system kernel accesses memory at privilege level 0 will be completely different from those of a user-mode process accessing memory at privilege level 3, or when a data transfer access is initiated by the direct memory access controller.

[0097] After all register programming is completed, the security event handling module sends an enable command to the hardware monitoring module. The hardware monitoring module then releases its default freeze state on the system memory bus cycle, and the system enters normal operation and real-time protection state.

[0098] Next, we will provide a detailed explanation of the working principle of the hardware monitoring module.

[0099] Please refer to the appendix. Figure 2 The hardware monitoring module is implemented by the logic circuit inside the field-programmable gate array, and it is physically connected directly to the system memory bus through a set of high-speed signal lines.

[0100] This mounting method is a bypass monitoring mode, which means that the hardware monitoring module will not interfere with or delay the normal memory access transaction flow, but only observe and analyze it without interruption.

[0101] The hardware monitoring module contains several key sub-units: The system includes a bus transaction capture unit, an address comparison unit, an attribute comparison unit, an arbitration logic unit, and an exception event generation and latching unit.

[0102] The bus transaction capture unit samples the control signals, address signals, and data signals on the memory bus in each system clock cycle and parses them into structured memory access transaction descriptors.

[0103] This descriptor contains the target physical address, access type, access source identifier, timestamp, and data payload.

[0104] The address comparison unit receives the transaction descriptor and performs a parallel comparison between the target physical address and all enabled protected area ranges in the address range register group.

[0105] The comparison logic determines whether the target address is greater than or equal to the start address of a certain region and less than or equal to the end address of that region.

[0106] If all comparison results are mismatched, the address comparison unit generates a release signal.

[0107] If at least one match exists, the address comparison unit will record the identifier of the matching protection zone and send the transaction descriptor along with the identifier to the attribute comparison unit.

[0108] The attribute comparison unit indexes the list of valid access pattern entries in the access attribute register associated with the matched region based on the region identifier.

[0109] It compares the access type, access source identifier, and timestamp of the current transaction with each entry in the list in turn.

[0110] The comparison rule is that a transaction is considered to conform to the legal pattern only if the access type of the current transaction is a subset of the access types allowed in the entry, the access source identifier of the current transaction is exactly the same as the access source identifier allowed in the entry, and the timestamp of the current transaction falls within the time window allowed in the entry.

[0111] The attribute comparison unit traverses the entire list, and if it finds at least one completely matching entry, it generates a release signal. If no match is found after the traversal is completed, a violation signal is generated.

[0112] The arbitration logic unit receives signals from the address comparison unit and the attribute comparison unit.

[0113] When a clearance signal is received, the arbitration logic unit does not perform any operation, and the current memory bus transaction is completed normally.

[0114] Upon receiving a violation signal, the arbitration logic unit immediately activates the exception event generation and latching unit. This unit first generates a hardware exception event signal.

[0115] The signal is a data structure that contains the complete descriptor of the violation, the matching protected area identifier, and the specific attribute mismatch that triggered the violation.

[0116] At the same time, the unit sends a hold request signal to the memory bus controller through its built-in set of hardware latches. This signal temporarily freezes the currently ongoing illegal memory bus cycle to prevent illegal access operations from being actually executed.

[0117] Hardware exception signals are immediately placed in a first-in-first-out queue and an interrupt request is sent to the policy parsing and arbitration module running in the secure kernel via a dedicated, high-priority hardware interrupt line.

[0118] Now, we will delve into the intelligent analysis and decision-making process of the strategy analysis and arbitration module.

[0119] Please refer to the attached document. Figure 3 This module runs as a resident service in the security kernel. Its internal structure can be divided into an event receiving and parsing submodule, a dynamic behavior baseline query and scoring submodule, a multi-level response strategy matching submodule, and an instruction sequence assembly and distribution submodule.

[0120] When an interrupt request arrives from the hardware monitoring module, the event receiving and parsing submodule of the policy parsing and arbitration module is activated.

[0121] This submodule first reads hardware abnormal event signals from the first-in-first-out queue of the hardware monitoring module and parses them into internal event objects.

[0122] The event object contains information such as the source identifier of the unauthorized access, the target address, the access type, the data pattern, the timestamp, and the type of protected area.

[0123] Subsequently, the dynamic behavior baseline query and scoring submodule began to work.

[0124] This submodule maintains a dynamic behavior baseline database. The creation of this database involves two phases: The learning phase consists of an offline learning phase and an online update phase.

[0125] During the learning phase following the initial deployment of an industrial switch or a major firmware upgrade, the system will enter a monitored learning mode.

[0126] At this time, the hardware monitoring module is configured to listen but not intercept, and the security event handling module will dynamically and temporarily set the protection policy of all memory regions to allow all access.

[0127] The strategy parsing and arbitration module continuously collects all memory access stream data reported by the hardware monitoring module, and this data is sliced ​​in units of time windows.

[0128] Access stream data within each time window, such as 1 millisecond, is represented as a high-dimensional feature vector, with features including but not limited to: The frequency of different access source identifiers, the sequence pattern of accessing specific address regions, the ratio of read and write operations, and the statistical distribution of accessed data values.

[0129] This submodule employs a density-based clustering algorithm to perform unsupervised learning on these feature vectors.

[0130] In this embodiment, the density-based clustering algorithm specifically adopts the DBSCAN algorithm, and its specific input features, parameter settings, and iteration method are as follows: Input features: The algorithm's input is an 8-dimensional feature vector corresponding to the memory access stream data within a 1-millisecond time window. The features of each dimension are as follows: The number of different access source identifiers appearing within this time window; The percentage of read operations on the protected memory region within this time window relative to the total number of accesses; The percentage of write operations to the protected memory region within this time window relative to the total number of accesses; The continuity of accessed addresses within this time window, i.e., the proportion of consecutive address accesses to the total number of accesses; The entropy value of the privilege level distribution corresponding to the access source identifier within this time window; The average length of a single data block accessed within this time window; The standard deviation of the time interval between access operations within this time window; The variance of the numerical distribution of write operations within this time window; all input features are normalized to min-max before the algorithm is executed, and mapped to the [0,1] interval to eliminate the influence of different units on the clustering results.

[0131] The core parameters of the algorithm are set as follows: the clustering neighborhood radius ε is set to 0.35, and the minimum number of neighborhood samples (MinPts) of the core object is set to 15; the clustering boundary threshold is set as follows: the maximum threshold for the Euclidean distance between a sample point and the cluster center is 0.6. When the Euclidean distance between a sample point and the cluster centers of all identified clusters is greater than 0.6, the sample point is judged as an outlier and is not included in the normal pattern cluster; the noise point filtering threshold is set as follows: during a single clustering process, discrete clusters with a sample ratio of less than 0.5% are directly judged as noise clusters and are not included in the behavioral baseline database.

[0132] Iteration Method: The algorithm adopts a two-stage iterative mode combining batch iteration and incremental iteration. The initial baseline establishment stage adopts the batch iteration method, specifically: all sample data collected in the learning stage are divided into 10 batches in chronological order, with each batch containing no less than 10,000 feature vector samples. DBSCAN full clustering is performed on the first batch of samples to identify the initial normal pattern clusters and calculate the cluster center and boundary threshold of each cluster. For each subsequent batch of samples, pre-classification is first performed based on the identified cluster centers. For the sample set that fails to be classified, DBSCAN clustering is performed again to identify new pattern clusters and update the cluster centers and boundary thresholds. The convergence condition of batch iteration is: in the clustering results of three consecutive batches, the number of newly added pattern clusters is 0, and the cluster center offset of each cluster is less than 0.05. At this time, the establishment of the initial behavioral baseline is completed. During the incremental learning process in the normal operation phase, a sliding window incremental iteration method is adopted. The sliding window size is set to 1000 samples and the sliding step size is set to 100 samples. After each sliding window sample collection is completed, for samples in the window that conform to the existing baseline pattern, the cluster center and boundary threshold of the corresponding cluster are updated using the exponential moving average method. The update weight is set to 0.02 to ensure smooth baseline updates and avoid the impact of sudden traffic fluctuations on baseline stability.

[0133] The core principle of the algorithm is to find high-density regions separated by low-density regions in the feature space, with each high-density region corresponding to a normal firmware operating mode cluster.

[0134] For each identified pattern cluster, the algorithm calculates the mean of its core feature vector as the cluster center and calculates the maximum distance from the samples in the cluster to the cluster center as the boundary threshold of the cluster.

[0135] Cluster centers and boundary thresholds together constitute the behavioral baseline entries for this pattern. For example, the system might identify memory access pattern clusters when the switch is normally forwarding packets, pattern clusters when performing configuration updates, and pattern clusters when performing system self-tests. During normal system operation, the database employs an incremental learning mechanism.

[0136] For newly occurring access behavior, the policy parsing and arbitration module will calculate the distance between its feature vector and the existing cluster centers of each pattern cluster.

[0137] If the distance is less than the boundary threshold of the corresponding cluster, the behavior is considered to be a known normal mode, and the cluster center and boundary threshold parameters of the cluster are smoothly updated based on the data of this behavior to achieve adaptive fine-tuning of the baseline.

[0138] If the distance is consistently greater than the boundary threshold of all known clusters, and the new pattern repeats a certain number of times during the observation period, the system will carefully evaluate and may create a new pattern cluster and incorporate it into the baseline database, but this process is subject to strict security policy constraints.

[0139] When handling violation incidents, the Dynamic Behavior Baseline Query and Scoring submodule uses the characteristic information of the current incident as input to query the baseline database.

[0140] It first determines the main normal mode clusters to be referenced based on the current working status of the system, such as load rate and active services.

[0141] Then, it calculates the degree of deviation of the current violation from the baseline from multiple dimensions.

[0142] These dimensions include: From the perspective of the access source, check whether the access source identifier has accessed this target area in the past. If it is the first access, the deviation is high. In terms of time dimension, check whether the time of this visit is outside the active time window in which the target area is usually visited in the historical baseline. If it is outside the window, the deviation is high. At the behavioral sequence dimension, check whether this access violates the fixed access sequence pattern that the access source identifier usually follows; In terms of data pattern, if it is a write operation, check whether the written data value has a significant statistical difference from the numerical pattern that usually appears at that position in the historical baseline.

[0143] Each dimension has a preset weight coefficient, which reflects the importance of that dimension in judging malicious behavior.

[0144] For example, the data pattern dimension may have a greater weight than the time dimension.

[0145] The submodule integrates the matching results of each dimension with preset weights and calculates the confidence score by weighted summation.

[0146] The rating ranges from 0 to 100, and the calculation formula is described in plain text below: The confidence score is equal to the source deviation multiplied by the weight coefficient A, plus the time window deviation multiplied by the weight coefficient B, plus the sequence pattern deviation multiplied by the weight coefficient C, plus the data pattern deviation multiplied by the weight coefficient D, where the sum of the weight coefficients A, B, C, and D is 1. Each deviation value is mapped to a sub-score from 0 to 100 according to a preset rule.

[0147] In this embodiment, the specific fixed settings for each weight coefficient are as follows: weight coefficient A (access source deviation) is 0.35, weight coefficient B (time window deviation) is 0.15, weight coefficient C (sequence pattern deviation) is 0.2, weight coefficient D (data pattern deviation) is 0.3, and the sum of all weight coefficients is 1; the sub-score mapping rules for each dimension deviation are as follows: Access Source Deviation Sub-Score: If the number of times the access source identifier has accessed the target protected area in history accounts for ≥1% of the total number of historical accesses to the area, the sub-score is 0; if the proportion is 0.1%-1%, the sub-score is 50; if the proportion is <0.1% or it is the first time accessing the area, the sub-score is 100. Time window deviation sub-score: If the access time is within the normal active time window of this region in the historical baseline, the sub-score is 0; if the access time is outside the active time window but within the device's preset normal operation period, the sub-score is 50; if the access time is outside the device's preset silent maintenance period, the sub-score is 100. Sequence pattern deviation sub-score: If the access sequence to which this access belongs matches the fixed access sequence of the corresponding scenario in the historical baseline with a matching degree ≥ 90%, the sub-score is 0; if the matching degree is 60%-90%, the sub-score is 50; if the matching degree is < 60%, the sub-score is 100. Data pattern deviation sub-score: If this is a write operation, and the KL divergence between the numerical distribution of the written data and the regular numerical distribution at this address in the historical baseline is <0.2, then the sub-score is 0; if the KL divergence is 0.2-0.8, then the sub-score is 50; if the KL divergence is >0.8, then the sub-score is 100; if this is a read operation, the sub-score for this dimension is 0 by default.

[0148] By using the above mapping rules, the deviation of each dimension is quantified into a standard sub-score of 0-100, and then the final confidence score is obtained by weighted summation, ensuring that the scoring results are quantifiable and reproducible, and providing a clear basis for subsequent multi-level response strategy matching.

[0149] The higher the value, the greater the likelihood that the current violation is a malicious attack.

[0150] Next, the multi-level response strategy matching submodule begins to operate.

[0151] This module maintains a multi-level response strategy library organized using a tree-like decision-making structure.

[0152] The root node of the policy tree is the violation event type, such as illegal code segment write, illegal interrupt vector table read, and illegal configuration area access. Under each event type node, it is divided into multiple sub-interval nodes based on the confidence score. For example, 0 to 30 is the low confidence interval, 31 to 70 is the medium confidence interval, and 71 to 100 is the high confidence interval.

[0153] Each confidence interval node serves as a leaf node, associated with a specific sequence of action instructions. The sequence of action instructions consists of a series of atomic operation instruction codes.

[0154] The policy matching submodule takes the parsed violation type and the calculated confidence score as input, traverses the policy tree, finds the matching leaf node, and obtains the corresponding sequence of disposal instructions.

[0155] The instruction sequence assembly and distribution submodule encapsulates the sequence into a task, places it in the instruction queue that communicates with the security incident handling module, and notifies the security incident handling module that it is ready.

[0156] Finally, the atomic execution and state recovery mechanism of the security incident handling module are described in detail.

[0157] Please refer to the appendix. Figure 4 The security incident handling module is the component with the highest execution privileges in the security kernel. Its code execution flow cannot be preempted by any interruption or scheduling of the general operating system, ensuring the atomicity of the handling actions.

[0158] After retrieving the sequence of disposal instructions from the instruction queue, this module begins to interpret and execute them one by one. The sequence of disposal instructions contains various types of atomic operations.

[0159] The first type of operation is logging and policy fine-tuning.

[0160] For violations with low confidence scores, the instruction sequence may only contain operations that write records to a security log area in system memory that is exclusively managed by the security kernel.

[0161] The log record has a fixed format and includes a timestamp, a unique event identifier, violation details, a confidence score, and a handling action code.

[0162] The write process uses direct memory access to ensure high efficiency.

[0163] Another fine-tuning operation is to dynamically reconfigure the hardware monitoring module.

[0164] For example, the instruction sequence might include an instruction that requires the security incident handling module to modify the access attribute register of a certain protected area in the hardware monitoring module via the configuration bus, temporarily prohibiting all access to that area by a specific access source identifier for a period of time in the future.

[0165] Alternatively, the protection scope of a certain area can be temporarily expanded to cover adjacent memory spaces that may be exploited.

[0166] After performing such an operation, the security incident handling module sends a command to the hardware monitoring module to release the latch. The hardware monitoring module then unfreezes the violation bus cycle, which is either canceled or redirected according to the security kernel's instructions, and the system continues to run.

[0167] The second type of operation is proactive defense and state preservation.

[0168] For serious violations with high confidence scores, the instruction sequence will trigger a more stringent handling process.

[0169] The security incident handling module first initiates the scene preservation process, which is crucial for ensuring business continuity. The scene preservation process specifically includes the following uninterrupted steps.

[0170] Step 1: Save the processor context.

[0171] The security incident handling module obtains the values ​​of all general-purpose registers, program counter, stack pointer, and critical system control registers by reading the control register group of the central processing unit.

[0172] Step 2: Save the network session state.

[0173] The core function of industrial switches is packet forwarding.

[0174] The security incident handling module obtains the status table, traffic statistics, and quality of service policy configurations for all currently active network connections by accessing the internal registers of the network processing application-specific integrated circuit or the memory-mapped area shared with it.

[0175] Step 3: Save the data packet queue state.

[0176] The security incident handling module suspends the enqueueing operation of the network packet processing engine, but does not affect packets that are currently being transmitted.

[0177] Then, it takes a snapshot of the descriptor list of the queue of packets to be processed, saving information such as the address, length, and port of each packet in memory.

[0178] Step 4: Save the status of the hardware monitoring module.

[0179] The contents of all registers related to the current violation event in the hardware monitoring module are fully read, including the address range register, access attribute register, and the status of the exception event latch.

[0180] All the original data saved above is stream-encrypted using a unique encryption key of the secure kernel before being written to the backup storage area, and a message authentication code is generated and appended to each encrypted data.

[0181] Backup storage typically uses a battery-powered static random access memory (SRAM) that is physically independent of the main system memory, ensuring that data is not lost even if the main system loses power.

[0182] After the scene is saved, the security incident handling module executes the final handling action according to the instruction sequence.

[0183] Typical actions include triggering a controlled system watchdog reset signal.

[0184] Unlike a regular watchdog timeout reset, this signal is actively and precisely triggered by the security event handling module.

[0185] Before being triggered, it sets a flag in the backup storage area to indicate that this reset is a safe disposal reset.

[0186] Another approach is to inject a hardware breakpoint into the CPU's debug register, with the breakpoint's address pointing to an auditing routine within the secure kernel.

[0187] When the CPU execution flow passes through this address again, it will fall into a debug exception at the highest privilege level, and control will be forcibly transferred to the audit routine of the security kernel, thereby enabling in-depth tracing and analysis of the attack chain without immediately resetting the system.

[0188] The system recovery phase occurs after a controlled reset.

[0189] Upon system power-on or reset, the vector is redirected to the secure kernel. The secure kernel first checks the secure dispose reset flag in the backup storage area.

[0190] If the flag is valid, the recovery process will be initiated.

[0191] The recovery process is the reverse of the save process.

[0192] The secure kernel uses its key to decrypt backup data and verifies message authentication codes to ensure data integrity and tamper-proof.

[0193] Subsequently, it gradually restored the central processing unit register context, the internal state of the network application-specific integrated circuit, the packet queue descriptor, and reprogrammed the hardware monitoring module to the configuration state before the violation.

[0194] Finally, the secure kernel restores the program counter and stack pointer to their saved states and executes a special return instruction, causing the system to jump back to the interrupted general operating system or firmware code to continue execution.

[0195] Because the network session state and packet queues have been restored, the service interruption time is compressed to an extremely short time, usually only the time required for resetting and initializing the hardware, thus maximizing the service continuity of industrial switches.

[0196] Please refer to the attached document. Figure 5 The three modules mentioned above work together in a multi-level collaborative manner, with clear and unambiguous data and instruction flows.

[0197] The hardware monitoring module, acting as the perception layer, provides real-time, raw signals of violations.

[0198] The strategy parsing and arbitration module acts as the decision-making layer, intelligently analyzing events and matching strategies. The security incident handling module acts as the execution layer, atomically completing the entire series of actions from log recording to system recovery.

[0199] The three layers interact efficiently and securely through hardware interrupts, shared memory queues, and configuration buses, forming an automated security protection closed loop from detection to decision-making and handling.

[0200] This embodiment further details the priority arbitration mechanism of the address range register group in the hardware monitoring module.

[0201] This module supports defining multiple protection zones simultaneously. In addition to the start address, end address, and access attributes, each zone configuration also includes a priority identifier field, which is an integer value. The larger the value, the higher the priority.

[0202] When the physical address ranges of two or more protection zones overlap, the arbitration logic unit of the hardware monitoring module will perform multiple address comparisons simultaneously when processing memory access transactions for the overlapping zone.

[0203] If multiple regions are found to match simultaneously, the arbitration logic unit will compare the priority identifiers of these regions.

[0204] Ultimately, only the access attribute rules of the highest priority region are used to determine the validity of this transaction.

[0205] Rules for lower priority areas were ignored during this visit.

[0206] This design allows the system to implement a sophisticated, layered protection strategy.

[0207] For example, a basic protection region can be defined for the entire firmware code segment, with a priority of 5 and a rule that only write operations from trusted firmware loaders are allowed.

[0208] At the same time, a smaller, fully enclosed protected region can be defined for a critical function table in the code segment, with a priority of 10 and a rule that prohibits any write operations and read operations from non-core interrupt service routines.

[0209] When the access target is the function table, the priority 10 rule takes effect, providing stronger protection; when the access target is other parts of the code segment, the priority 5 rule takes effect.

[0210] This enables differentiated management of the same physical memory space based on its security importance.

[0211] Furthermore, the multi-level response policy library in the policy resolution and arbitration module supports dynamic updates. The update source is a digitally signed policy configuration file.

[0212] When a policy needs to be updated, the administrator transfers the configuration file to the switch's temporary storage area via a secure out-of-band management interface.

[0213] A dedicated verification routine within the secure kernel is triggered, which uses a pre-configured public key to verify the digital signature of the configuration file.

[0214] The configuration file will only be decrypted and parsed after the signature verification passes. The parsing process checks the syntactic correctness and logical consistency of the new policy, such as ensuring the legality of the sequence of disposal instructions.

[0215] Verification and parsing are both completed within the secure kernel, which is imperceptible and uninterrupted by general-purpose operating systems.

[0216] Once verified, the new policy tree will safely replace or merge into the existing multi-level response policy library in memory.

[0217] The entire update process is atomic, ensuring that the policy library is in a consistent and effective state at all times.

[0218] This allows the system to quickly adapt to new attack patterns, adjust confidence score ranges or response measures, without having to reboot the device or update the entire firmware.

[0219] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0220] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A firmware security protection system for industrial switches, characterized in that, An embedded hardware platform deployed in industrial switches works in conjunction with the switch's central processing unit, system memory, and peripheral bus, including: The hardware monitoring module, implemented by field-programmable gate array logic circuits and directly mounted on the system memory bus, is used to perform uninterrupted bypass monitoring of all read and write transactions on the system memory bus; the policy parsing and arbitration module runs in an independent and protected security kernel on the central processing unit, and is used to receive and parse hardware abnormal event signals reported by the hardware monitoring module. The security incident handling module also runs in the security kernel and interacts directly with the policy parsing and arbitration module and the hardware monitoring module to execute the sequence of handling instructions issued by the policy parsing and arbitration module.

2. The industrial switch firmware security protection system according to claim 1, characterized in that, The hardware monitoring module has a built-in programmable address range register set and access attribute register. The address range register group is used to configure the physical start and end addresses of the critical memory regions that need to be protected; The access attribute register is used to define the legal access patterns to the protected area. The legal access patterns include allowed access types, allowed access source identifiers, and allowed access time windows. The monitoring logic of the hardware monitoring module continuously compares the target address of the memory bus transaction with the address range register group, and compares the access attributes of the transaction with the legal patterns defined in the access attribute register. When a target address is detected to fall into a protected area and its access attributes do not match any legal mode, the hardware monitoring module immediately generates a hardware anomaly event signal and simultaneously freezes the current unauthorized memory bus cycle through its built-in hardware latch.

3. The industrial switch firmware security protection system according to claim 2, characterized in that, The strategy parsing and arbitration module maintains a dynamic behavior baseline database and a multi-level response strategy library; The dynamic behavior baseline database is established by learning the firmware operation mode of industrial switches under normal operating conditions through machine learning algorithms. The multi-level response strategy library defines a sequence of instructions for handling different types and confidence levels of violation events; The workflow of the strategy parsing and arbitration module is as follows: First, based on the detailed information of the violation in the hardware anomaly event signal, query the dynamic behavior baseline database, calculate the deviation of the current violation from the historical normal baseline, and generate a confidence score. Subsequently, by combining the confidence score with the violation type, the multi-level response strategy library is queried to match the corresponding sequence of handling instructions.

4. The industrial switch firmware security protection system according to claim 3, characterized in that, The security incident handling module has the ability to dynamically reconfigure the registers of the hardware monitoring module, as well as the ability to perform controlled writing to some registers of the system memory and the central processing unit. The sequence of instructions includes instructing the hardware monitoring module to temporarily expand or shrink the protection range of a specific memory region, instructing the hardware monitoring module to implement access bans on specific access sources, writing complete violation event records to a preset security log area in system memory, triggering a controlled system watchdog reset signal that takes effect after critical state backup is completed, and injecting breakpoints into specific debug registers of the central processing unit to guide the execution flow to the audit routine of the security kernel.

5. The industrial switch firmware security protection system according to claim 1, characterized in that, The programmable address range register group of the hardware monitoring module supports the parallel definition of multiple protection regions; Each set of protected area configurations is associated with an independent priority identifier; When the address ranges of multiple protection zones overlap, the arbitration logic of the hardware monitoring module determines the access control rules that apply to the overlapping zone based on the priority identifier, with the higher priority rule overriding the lower priority rule.

6. The industrial switch firmware security protection system according to claim 5, characterized in that, The access source identifier defined in the access attribute register of the hardware monitoring module is directly mapped to the current execution privilege level of the central processing unit, the current process identifier, and the specific hardware controller identifier that initiated the access.

7. The industrial switch firmware security protection system according to claim 6, characterized in that, The process of establishing the dynamic behavior baseline database in the strategy parsing and arbitration module is as follows: During the deployment and learning phase of the industrial switch, the hardware monitoring module is configured to listen but not intercept in a continuous manner, collecting memory access stream data. The collected data is sent to the policy parsing and arbitration module. This module uses a density-based clustering algorithm to perform unsupervised learning on the access flow, automatically identify multiple memory access pattern clusters corresponding to different working states of the switch, and extract the core feature vector and boundary threshold for each pattern cluster to form an initial behavior baseline. During normal operation, the database employs an incremental learning mechanism to smoothly update baseline parameters for access behaviors that conform to existing baseline patterns.

8. The industrial switch firmware security protection system according to claim 7, characterized in that, The multi-level response strategy library of the strategy parsing and arbitration module is organized using a tree-like decision structure; The root node of the tree-like decision structure is the type of violation event, the child nodes are the confidence score intervals, and the leaf nodes are the specific sequence of handling instructions. The structure supports dynamic loading and updating of policies. The update process is driven by a digitally signed policy configuration file and takes effect after verification within the secure kernel.

9. A firmware security protection method for industrial switches, characterized in that, Using the industrial switch firmware security protection system according to any one of claims 1 to 8 to implement industrial switch firmware security protection includes the following steps: Step 1, System Initialization; After the industrial switch is powered on, the root of trust first loads and runs the security kernel, initializing the policy parsing and arbitration module and the security event handling module; Subsequently, the security kernel loads the protected memory region configuration and initial security policy from the encrypted storage medium, and programs them into the address range register group and access attribute register of the hardware monitoring module through the security event handling module; After configuration is complete, the hardware monitoring module releases the freeze on the memory bus cycle, and the switch enters normal operation and protection mode. Step 2, Real-time monitoring and violation detection; The hardware monitoring module continuously bypasses and listens to the system memory bus during switch operation. For each memory access transaction, the hardware monitoring module compares its target address with the address range of all configured protected regions; If the target address is not in any protected area, the transaction is allowed. If the target address falls into a protected area, the access type, access source identifier, and timestamp of the transaction are further compared to see if they match any of the valid patterns defined in the access attribute register for that area. If they match, proceed; if they do not match, immediately generate a hardware exception signal and latch the current bus cycle. Step 3: Event Analysis and Strategy Arbitration; The hardware monitoring module transmits hardware abnormal event signals to the policy parsing and arbitration module through a dedicated hardware interrupt signal; The strategy analysis and arbitration module analyzes event details, queries the dynamic behavior baseline database, calculates the deviation of the current violation from the historical normal pattern, and generates a confidence score based on predefined rules. Subsequently, using the violation type and confidence score as indexes, the multi-level response strategy library is queried to match the corresponding sequence of handling instructions; Step 4, Safety procedures and system recovery; The strategy parsing and arbitration module issues a sequence of handling instructions to the security incident handling module; The security incident handling module executes this sequence atomically; For minor violations that only require recording or adjusting the monitoring policy, after performing operations such as logging or dynamically reconfiguring the hardware monitoring module registers, the hardware monitoring module is notified to release the latched bus cycle, and the system continues to run. For serious violations that are deemed highly suspicious or confirmed as attacks, the security incident handling module initiates the on-site preservation process, backs up the critical operational status to the persistent storage area, and then performs a controlled system reset or boots into deep audit mode. During the system recovery phase, the security kernel first checks the status of the backup and restores services accordingly.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the industrial switch firmware security protection method as described in claim 9.

Images