An isolated dynamic plug-in loading method and system for a network security operation platform

Abstract

The application relates to the technical field of network security, and discloses an isolated dynamic plug-in loading method and system for a network security operation platform. The application comprises the following steps: creating a primary and backup double buffer area to respectively carry new and old version plug-ins; registering plug-in metadata; loading the current version plug-in to the primary buffer area and setting the plug-in to an active state; completing five-dimension integrity verification and preheating of the new version plug-in in the backup buffer area; realizing atomic switching of the primary and backup buffer areas through memory barriers and pointer exchange; uninstalling the old version plug-in and releasing resources; and triggering atomic rollback when an exception is detected. Through the primary and backup double buffer area architecture and the atomic switching mechanism, the application can realize zero-disconnection hot updating of a security detection engine completely transparently, has the ability of second-level rollback and multi-dimension security verification, and effectively guarantees the continuous protection ability of the network security platform.

Description

Technical Field

[0001] This invention relates to the field of navigation and positioning technology, and specifically to an isolated dynamic plugin loading method and system for network security operation platforms. Background Technology

[0002] Cybersecurity operations platforms are the core infrastructure for building cybersecurity defenses, undertaking key functions such as real-time threat detection, signature database matching, and security policy enforcement. As cyberattack methods continue to evolve, the platform needs to dynamically expand its threat signature database, update its detection rule base, and load new security policies through a plug-in mechanism to maintain its ability to protect against the latest threats.

[0003] Among these technologies, dynamic plugin loading is a key technology supporting the continuous evolution of cybersecurity operation platforms. Specifically, when security vendors release new threat signature libraries or updated detection rule packages, the platform needs to load and run the new version of the plugin to enhance its protection capabilities. This process directly affects the platform's ability to continuously provide services.

[0004] However, in existing technologies, plugin updates typically employ a three-stage update model of "stop-replace-start." In this model, the platform first needs to stop and uninstall the running old version plugin, then load the new version plugin into memory, and finally complete initialization and start the new plugin. During this period, the security detection engine cannot function properly, resulting in a significant security protection gap. Because cybersecurity threats are characterized by their suddenness and rapid spread, new attacks emerging during this gap can lead to defense failures and irreparable security consequences. Even if some existing technologies attempt to shorten downtime with hot updates, the lack of an atomic switching guarantee mechanism means that during the transition between the old version plugin stopping service and the new version plugin taking over, issues such as request routing errors, loss or inconsistency of state data may occur, severely impacting system stability and reliability. Furthermore, when anomalies or defects occur after the new version plugin is loaded, existing technologies typically require restarting the entire security platform to roll back to the old version. This rollback process is time-consuming and costly, failing to meet the need for rapid business recovery. Furthermore, existing technologies typically only perform a simple version number comparison before loading plugins, lacking a multi-dimensional verification mechanism for the integrity, authenticity, and security of plugin packages. This may result in maliciously tampered or corrupted plugins being loaded and run, posing potential security risks to network security platforms. Summary of the Invention

[0005] This invention provides an isolated dynamic plugin loading method and system for network security operation platforms, which can effectively solve the technical defects of existing technologies, such as long business interruption time, high switching risk, high rollback cost, and lack of integrity verification caused by plugin updates.

[0006] To achieve the above objectives, according to one aspect of the present invention, an isolated dynamic plugin loading method for a network security operation platform is provided, comprising the following steps: S1: Dual buffer initialization. When the system starts, the plugin loading manager creates two independent memory spaces, a main buffer and a backup buffer, to hold the main version plugin and the new version plugin to be switched, respectively, and allocates independent system resources to each buffer. S2: Plugin metadata registration. After a plugin package is uploaded to the plugin package repository, the system extracts the plugin's metadata information and writes it to the plugin registry. The metadata includes the plugin identifier, version number, SHA256 checksum, dependency declaration array, capability declaration array, loading priority, and valid status flag. S3: Load plugins into the main buffer. Load the currently active version of the plugin into the main buffer, complete the memory mapping of the plugin code segment and data segment, initialize the plugin state machine to the ACTIVE state, and register the plugin entry point with the security detection engine. S4: Background preloading phase. When a new version plugin package is detected to have arrived, the background preloading process is triggered. This includes obtaining the new version plugin package from the plugin package repository, performing package format verification, digital signature verification, and SHA256 integrity verification on the plugin package, parsing the dependency declaration of the new version plugin and checking its compatibility with the current runtime environment, verifying the capability declaration of the new version plugin against the platform security policy, and if all verifications pass, loading the new version plugin into the backup buffer and completing memory allocation and code mapping, triggering the initialization logic of the new version plugin to complete resource preheating, setting the state machine of the backup buffer plugin to the READY state, and registering the health check callback function of the backup buffer plugin with the health monitoring module. S5: Atomic Switching Phase. When the backup buffer plugin reaches the ready state, the dual-buffer scheduler performs an atomic switch. Specifically, this includes executing the first memory barrier to ensure that all previous write operations are visible to subsequent reads, freezing the active plugin of the main buffer and stopping receiving new requests, waiting for the main buffer plugin to finish processing all current in-transit requests, swapping the pointer references of the main buffer and backup buffer, updating the state machine of the backup buffer plugin to the ACTIVE state, updating the state machine of the main buffer plugin to the STANDBY state, updating the global routing table to route the security detection engine's requests to the new active plugin, executing the second memory barrier to ensure that the switching operation is visible to all threads, and updating the health check object of the active plugin to the health monitoring module. S6: Old version cleanup phase. After the switch is completed, perform a safe cleanup of the old version plugins. Specifically, this includes uninstalling the old version plugins in the main buffer, releasing the system resources occupied by the old version plugins, resetting the state machine of the plugins in the main buffer to the IDLE state, and updating the metadata in the plugin registry to update the new version information to the current valid record. S7: Rollback mechanism. When the health monitoring module detects that an active plugin has failed a preset number of consecutive health checks, or the plugin actively reports a fatal error, or the resource usage exceeds a preset threshold, or the security module detects abnormal behavior in the plugin, an automatic rollback is triggered. The rollback process adopts the same atomic switching mechanism as step S5, which swaps the roles of the main buffer and the backup buffer, restoring the old version plugin to the role of actively providing services.

[0007] Preferably, in step S1, the main buffer and the backup buffer are two completely independent memory spaces, each configured with an independent resource management unit, to ensure that the two buffers are physically completely isolated, and that an abnormality in a plugin in one buffer will not affect the normal operation of a plugin in the other buffer.

[0008] Preferably, the plugin metadata registration in step S2 adopts a hierarchical storage structure, with the plugin identifier as the primary key for fast retrieval, the version number adopts semantic version management and supports multiple versions coexisting, the SHA256 checksum is used for plugin package integrity verification, the dependency declaration array records the system environment and dependency library versions required for the plugin to run, and the capability declaration array records the operation permissions that the plugin can perform.

[0009] Preferably, after the main buffer plugin is loaded in step S3, the plugin state machine transitions from the IDLE state through the LOADING state to the ACTIVE state. Each state transition records a detailed timestamp and event log, providing a complete lifecycle tracking basis for subsequent operation and maintenance management.

[0010] Preferably, the integrity verification in step S4 adopts a five-dimensional verification mechanism: package format verification is used to confirm that the plugin package conforms to the predefined encapsulation specification; digital signature verification is used to confirm the authenticity of the plugin package source and that it has not been tampered with; SHA256 fingerprint comparison is used to verify the integrity of the plugin package data byte by byte; dependency compatibility verification is used to confirm that the plugin's dependency declaration matches the current platform environment; and capability policy verification is used to confirm that the capabilities declared by the plugin meet the platform's security policy requirements.

[0011] Preferably, the resource preheating process in step S4 includes loading plugin configuration data into memory, initializing the plugin's internal data structure, performing plugin self-tests, and preloading frequently used data resources to ensure that the new version plugin has reached its optimal operating state before officially taking over the service.

[0012] Preferably, in step S5, the atomic switching uses a double-locking mechanism in conjunction with a memory barrier to achieve the atomicity of the switching operation. The first memory barrier is located before the switching operation to ensure that all pre-write operations have been completed, and the second memory barrier is located after the switching operation to ensure that the switching result is visible to all threads, effectively avoiding request routing errors or data inconsistency problems during the switching process.

[0013] Preferably, the global routing table update in step S5 adopts an atomic operation method, which seamlessly transfers the request route from the old version plugin to the new version plugin through a one-time pointer switch. The entire switching process is completely transparent to the security detection engine, and the switching time is controlled within a preset time range.

[0014] Preferably, the default threshold for consecutive health check failures in step S7 is a preset number of times. This threshold is a configurable parameter that can be adjusted by maintenance personnel according to actual business needs. When the rollback condition is triggered, the dual-buffer scheduler immediately performs an atomic switch to restore the old version plugin to the role of actively providing services, and the rollback time is controlled within the preset time range.

[0015] Preferably, the plug-in state machine includes eight states: IDLE, LOADING, READY, ACTIVE, STANDBY, UPDATING, FAILED, and ROLLBACK. The state machine accurately tracks the lifecycle stage of each plug-in, providing a clear state view and anomaly alarm capabilities for operation and maintenance management.

[0016] According to another aspect of the present invention, an isolated dynamic plug-in loading system for a network security operation platform is provided, comprising: The double buffer module is used to create two independent memory spaces: a primary buffer and a backup buffer. The plugin loading manager is connected to both the main buffer and the backup buffer, and is used to perform plugin loading and unloading operations. The plugin registry module connects to the plugin loading manager and is used to store and manage plugin metadata. The integrity verification module, connected to the plugin registry module, is used to perform five-dimensional verification on the plugin package; The dual-buffer scheduler module is connected to the dual-buffer module and the integrity verification module respectively, and is used to control the role switching between the main buffer and the backup buffer. The health monitoring module, connected to the double-buffered scheduler module, is used to monitor the running status of active plugins and trigger rollback in case of an anomaly. The security detection engine, connected to the double-buffered scheduler module, is used to receive external requests and invoke active plugins for processing.

[0017] Preferably, the dual-buffer module configures an independent resource management unit for each buffer, including an independent memory allocator, thread pool, and resource handle table, to ensure that the two buffers are isolated at the resource management level.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention employs a primary-backup dual-buffer architecture. During the preloading and warm-up of the new version plugin in the background, the old version plugin continues to provide services. The entire switching process is completely transparent to the security detection engine, achieving zero-disruption hot updates and effectively solving the technical defect of long business interruption time. The atomicity of buffer switching is ensured through dual-check locks and memory barrier mechanisms, avoiding request routing errors or data inconsistencies during the switching process, effectively solving the technical defect of high switching risk. When the new version plugin encounters an anomaly, it can be rolled back to the old version within a preset time. The rollback process itself is also an atomic operation, ensuring the system quickly recovers to a stable state, effectively solving the technical defect of high rollback cost. Before plugin loading, five-dimensional security checks are performed: package format verification, digital signature verification, SHA256 integrity verification, dependency compatibility verification, and capability policy verification, preventing malicious or damaged plugins from being loaded and running, effectively solving the technical defect of lacking integrity guarantees. The plugin state machine accurately tracks the lifecycle state of each plugin, providing a clear state view and anomaly alarm capabilities for operation and maintenance management. Attached Figure Description

[0019] Figure 1 This is a flowchart of the steps of the present invention; Figure 2 This is a schematic diagram illustrating the core principle framework of the atomic switching mechanism controlled by the double-buffered scheduler in this invention. Detailed Implementation

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

[0021] Example 1

[0022] This embodiment applies to a scenario where the threat signature database plugin of a network security operations platform is hot-updated. In this scenario, the network security operations platform undertakes core functions such as real-time threat detection, signature database matching, and security policy execution, and needs to dynamically expand the threat signature database and update the detection rule base through a plugin mechanism. Assume that the platform is currently running threat signature database plugin version V1.0, which has identified 100,000 threat rules. Now, it receives a V1.1 version update notification, which adds identification rules for new types of ransomware.

[0023] First, the scenario deploys a system architecture that includes a dual buffer module, a plugin loading manager, a plugin registry module, an integrity verification module, a dual buffer scheduler module, a health monitoring module, and a security detection engine.

[0024] The dual-buffer module is configured with two independent memory spaces: a primary buffer and a backup buffer. The primary buffer hosts the currently active plugin V1.0, continuously responding to feature matching requests initiated by the security detection engine, providing uninterrupted security protection for the platform. The backup buffer serves as a pre-loading area for the new version plugin V1.1, and is physically completely isolated from the primary buffer. An anomaly in a plugin in either buffer will not affect the normal operation of plugins in the other buffer. The dual-buffer module configures an independent resource management unit for each buffer, including an independent memory allocator, thread pool, and resource handle table, ensuring that the two buffers are also isolated at the resource management level.

[0025] The plugin loader manager is located at the boundary between the system kernel space and user space, and is responsible for loading, unloading, and managing the lifecycle of plugins. During system startup, the plugin loader manager executes step S1, creating two independent memory spaces: a primary buffer and a backup buffer. It allocates independent system resources to each buffer, including virtual memory address space, file descriptor sets, and signal handling queues. Internally, the plugin loader manager maintains a state control block for each buffer, recording the currently hosted plugin identifier, version number, memory base address, and load timestamp.

[0026] The plugin registry module employs a hierarchical storage structure, using the plugin identifier as the primary key for rapid retrieval. The metadata stored in the plugin registry module includes: a plugin identifier to uniquely identify each plugin instance; a version number using semantic versioning and supporting multiple versions coexisting; a SHA256 checksum for plugin package integrity verification; a dependency declaration array recording the system environment and dependent library versions required for plugin operation; a capability declaration array recording the operation permissions the plugin can perform; a loading priority determining the activation order of plugins when multiple versions coexist; and a valid status flag indicating the plugin's current availability. When a plugin package is uploaded to the plugin package repository, the plugin registry module extracts the plugin's metadata information and writes it to the registry, completing the plugin metadata registration described in step S2.

[0027] The integrity verification module implements the five-dimensional verification mechanism in step S4. The first dimension is package format verification. The integrity verification module parses the plugin package's encapsulation header, verifying that the package format conforms to predefined encapsulation specifications, including file header identifiers, version fields, and boundary markers for the metadata area and payload area. The second dimension is digital signature verification. The integrity verification module uses the plugin publisher's public key to decrypt the plugin package's digital signature, verifying the authenticity of the plugin package's origin and its lack of tampering. The third dimension is SHA256 fingerprint comparison. The integrity verification module calculates the SHA256 hash value of the plugin package payload and compares it byte-by-byte with the checksum stored in the plugin registry to confirm the integrity of the plugin package data. The fourth dimension is dependency compatibility verification. The integrity verification module parses the dependency declaration array of the new version plugin, reads the system library version list of the current runtime environment, and checks the matching degree between the dependency declarations and the platform environment. The fifth dimension is capability policy verification. The integrity verification module reads the capability declaration array of the new version plugin and compares it against the whitelist rules in the platform's security policy database to verify that the plugin's declared capabilities meet the platform's security policy requirements.

[0028] The double-buffered scheduler module is the core control unit of the entire hot update process, responsible for coordinating the role switching sequence of the primary and backup buffers. The double-buffered scheduler module employs a double-locking mechanism in conjunction with memory barriers to ensure the atomicity of the switching operation. During the execution of step S5, the double-buffered scheduler module first executes the first memory barrier to ensure that all previous write operations are visible to subsequent reads; then, it freezes the active plugins of the primary buffer, stopping the acceptance of new requests; after the primary buffer plugins have processed all currently en route requests, it swaps the pointer references of the primary and backup buffers; it updates the state machine of the backup buffer plugin to the ACTIVE state and updates the state machine of the primary buffer plugin to the STANDBY state; it updates the global routing table to route the security detection engine's requests to the new active plugin; it executes the second memory barrier to ensure that the switching operation is visible to all threads; and finally, it updates the health check object of the active plugin to the health monitoring module.

[0029] The health monitoring module performs periodic health checks on active plugins. It maintains a timer queue and sends health probe requests to active plugins according to a preset detection period. Each health probe request includes a plugin self-check instruction, requiring the plugin to return runtime metrics such as current memory usage, CPU utilization, thread status, and error count. The health monitoring module determines the plugin's health status based on its probe responses. When N consecutive health check failures are detected, an automatic rollback is triggered, where N is a configurable parameter with a default value of 3. The health monitoring module also receives error status information proactively reported by plugins. When a plugin detects a fatal error or resource usage exceeding a preset threshold, it sends an error report message to the health monitoring module, triggering the rollback process.

[0030] The security detection engine is a core business module of the network security operations platform. It is responsible for receiving incoming network traffic data and calling plugins to perform threat signature matching. The security detection engine locates the entry point of currently active plugins through a global routing table and distributes traffic data to the processing queues of these active plugins. Throughout the entire hot update process, the security detection engine is completely transparent to buffer switching, with the switching time controlled within 100 milliseconds, ensuring the engine is unaware of any service interruption.

[0031] The workflow of this system is as follows.

[0032] During system startup, the plug-in loader manager executes step S1 to create two independent memory spaces: a primary buffer and a backup buffer. The plug-in loader manager allocates an independent resource management unit to each buffer, including a memory page allocator, a thread handle table, and a set of file descriptors, ensuring that the two buffers are physically completely isolated.

[0033] Subsequently, the system enters the plugin metadata registration phase in step S2. After the threat signature library plugin package V1.1 is uploaded to the plugin package repository, the plugin registry module extracts the plugin's metadata information. This metadata information includes the plugin identifier "threat-lib-v1.1", version number "1.1.0", SHA256 checksum "a1b2c3d4...", dependency declaration array ["libssl1.1", "libjson-c2"], capability declaration array ["network-monitor", "pattern-match"], load priority value "10", and validity status flag "REGISTERED". The plugin registry module writes the above metadata into the registry database, completing the plugin registration process.

[0034] In the main buffer plugin loading phase of step S3, the plugin loading manager loads the currently valid version V1.0 plugin into the main buffer. The plugin loading manager reads the code and data segments of the V1.0 plugin package and performs memory mapping according to the ELF format specification. The code segment is mapped to the read-only execution area of ​​the main buffer, and the data segment is mapped to the read-write data area. The plugin loading manager initializes the plugin state machine, transitioning the state from IDLE through the LOADING state to the ACTIVE state. Each state transition records a detailed timestamp and event log, including the timestamp of the state transition, the previous state value, the target state value, and the triggering event type. The plugin loading manager registers the plugin entry point with the security detection engine and writes the feature matching function address of the V1.0 plugin into the global routing table, completing step S3.

[0035] The system enters the background preloading phase, executing step S4. When a new version of the plugin package V1.1 is detected arriving at the plugin package repository, the double-buffered scheduler module triggers the background preloading process. The double-buffered scheduler module first notifies the integrity verification module to perform a five-dimensional verification. The integrity verification module performs package format verification, verifying that the V1.1 plugin package's file header identifier is "PLG2", the version field is "1.1", and the metadata area length is 1024 bytes. After the package format verification passes, the integrity verification module uses a pre-set plugin publisher public key to decrypt and verify the plugin package's digital signature, confirming that the plugin package originates from an official security vendor and has not been tampered with. The integrity verification module calculates the SHA256 hash value of the plugin package payload and compares it with the checksum stored in the registry; the comparison result is a complete match. The integrity verification module parses the dependency declaration array of the V1.1 plugin, reads the library versions installed in the current runtime environment, and confirms that the libssl version is 1.1.4 and the libjson-c version is 2.0, meeting the version requirements of the dependency declaration. The integrity verification module reads the capability declaration array ["network-monitor", "pattern-match", "heuristic-detect"] of the V1.1 plugin and compares it with the whitelist rules in the platform's security policy database to confirm that all declared capabilities are within the whitelist range. After all five dimensions of verification pass, the integrity verification module returns a verification success signal to the double-buffered scheduler module.

[0036] After receiving the successful verification signal, the double-buffered scheduler module executes step S4.5 to load the new version plugin V1.1 into the backup buffer. The plugin loading manager allocates independent memory space for the V1.1 plugin in the backup buffer, including a code segment mapping area, a data segment mapping area, and a heap memory area. The plugin loading manager completes the memory mapping of the code segment and data segment of the V1.1 plugin and sets the state machine of the V1.1 plugin to the LOADING state. The plugin loading manager triggers the initialization logic of the V1.1 plugin and performs resource preheating operations. The resource preheating process includes loading the plugin configuration file into memory, initializing the rule index structure inside the plugin, executing the plugin self-test function, and preloading frequently used feature data into the cache area. The plugin self-test function verifies whether the key function pointers inside the plugin are valid, whether the rule parser is working properly, and whether the custom data structure is complete. After the self-test passes, the plugin loading manager sets the state machine of the backup buffer plugin V1.1 to the READY state and completes step S4.7.

[0037] The double-buffered scheduler module registers the health check callback function of the V1.1 plugin with the health monitoring module. The health monitoring module adds the address of the V1.1 plugin's callback function to the probe queue, setting the detection period to 5 seconds.

[0038] The process proceeds to the atomic switching phase in step S5. Once the backup buffer plugin V1.1 reaches the READY state, the double-buffered scheduler module performs the atomic switching operation. The double-buffered scheduler module first executes the first memory barrier instruction, which ensures that all previous write operations have been completed and are visible to subsequent reads. After the first memory barrier is issued, all CPU cores in the system must flush all write operations prior to this barrier to shared memory to ensure that subsequent reads can obtain the latest data.

[0039] The double-buffered scheduler module freezes the active plugin V1.0 in the main buffer, ceasing the distribution of new feature matching requests to V1.0 plugins. V1.0 plugins continue processing in-transit requests already in the processing queue, and after all in-transit requests have been processed, V1.0 plugins return a processing completion signal to the double-buffered scheduler module. Upon receiving the processing completion signal, the double-buffered scheduler module performs a buffer pointer swap operation. The swapping of the main buffer pointer and the backup buffer pointer is completed at the CPU register level in one step, avoiding the possibility of intermediate states being read by other threads. After the pointer swap is complete, the double-buffered scheduler module updates the state machine of the backup buffer plugin V1.1 to the ACTIVE state, and simultaneously updates the state machine of the main buffer plugin V1.0 to the STANDBY state.

[0040] The double-buffered scheduler module performs a global routing table update operation. The security detection engine obtains the entry point address of the currently active plugin through the global routing table. The double-buffered scheduler module updates the plugin entry point address stored in the global routing table from the feature matching function address of the V1.0 plugin to the feature matching function address of the V1.1 plugin. This update operation uses atomic assignment instructions to complete the pointer replacement in one go, ensuring that no intermediate states occur during the update process. After the routing table update is completed, all new requests entering the security detection engine will be routed to the V1.1 plugin for processing.

[0041] The double-buffered scheduler module executes the second memory barrier instruction, which ensures that the result of the switch operation is visible to all threads. After the second memory barrier is issued, all CPU cores in the system must reread the latest data in shared memory to ensure they can see the results of pointer swapping and routing table updates. The double-buffered scheduler module updates the health check objects of active plugins to the health monitoring module, switching the health probe target from plugin V1.0 to plugin V1.1. The atomic switch process is completed, and the entire switch process is completely transparent to the security detection engine, with the switch time controlled within 100 milliseconds.

[0042] Proceed to step S6, the old version cleanup phase. After the switch is complete, the plugin loading manager unloads the old version plugin V1.0 from the main buffer. The unloading operation includes unmapping the memory of the V1.0 plugin, closing the file descriptors opened by the V1.0 plugin, and terminating the auxiliary threads created by the V1.0 plugin. The plugin loading manager releases the system resources occupied by the V1.0 plugin, including releasing memory pages, reclaiming heap memory, and unregistering signal handlers. The plugin loading manager resets the state machine of the plugin in the main buffer to the IDLE state, indicating that the buffer is currently idle. The plugin registry module updates the metadata, updating the V1.1 version information to the currently valid record, and changing the valid status flag of the V1.0 version to "DEPRECATED".

[0043] The rollback mechanism in step S7 is under monitoring. The health monitoring module sends health probe requests to the V1.1 plugin every 5 seconds. The probe response returned by the V1.1 plugin includes the current memory usage metric. Assuming a memory leak occurs after the V1.1 plugin has been running for 5 minutes, and the health monitoring module detects three consecutive failed health checks, it determines that this version is abnormal. The health monitoring module triggers the ROLLBACK state and sends a rollback request to the double-buffered scheduler module. The double-buffered scheduler module performs an atomic switch, swapping the roles of the primary and backup buffers. The V1.0 plugin, currently in the STANDBY state, returns to the ACTIVE state and continues to provide security detection services. The V1.1 plugin enters the isolation zone for investigation. After receiving an alarm notification, operations personnel can investigate V1.1 issues while the business is operating normally. The rollback switchover time is controlled within 50 milliseconds, with minimal impact on the business.

[0044] The plugin state machine precisely tracks the lifecycle stages of each plugin throughout the entire process. The state machine includes eight states: IDLE, LOADING, READY, ACTIVE, STANDBY, UPDATING, FAILED, and ROLLBACK. The IDLE state indicates the buffer is empty and no plugins are loaded. The LOADING state indicates the plugin is being loaded into the buffer. The READY state indicates the plugin has completed loading and warming up and can switch to an active state. The ACTIVE state indicates the plugin is currently responding to a security check request. The STANDBY state indicates the plugin has completed switching but is currently inactive. The UPDATING state indicates the plugin is performing a hot update operation. The FAILED state indicates an error occurred during plugin loading or execution. The ROLLBACK state indicates the system is performing a rollback operation. By precisely tracking the lifecycle stages of each plugin through the state machine, a clear state view and anomaly alerting capabilities are provided for operations and maintenance management.

[0045] In the above workflow, the dual-buffer module and the plug-in loading manager exchange data via an intra-process communication mechanism. The dual-buffer module maintains memory handles for each buffer, and the plug-in loading manager holds these handles to perform loading and unloading operations. The plug-in registry module and the integrity verification module exchange metadata verification results through a shared memory area. The dual-buffer scheduler module and the health monitoring module synchronize their states through an event queue. The security detection engine and the dual-buffer module route requests through a global routing table, forming a complete closed loop of data flow.

[0046] Example 2

[0047] This embodiment describes a specific application of the present invention in a scenario involving hot updates of security policy execution plugins. In this scenario, the network security operations platform needs to update its access control policy plugin to address newly discovered high-risk vulnerabilities.

[0048] This scenario deploys the same system architecture as Example 1, including a dual-buffer module, a plugin loading manager, a plugin registry module, an integrity verification module, a dual-buffer scheduler module, a health monitoring module, and a security detection engine. The connection relationships and data interaction methods between the modules are the same as in Example 1.

[0049] During system startup, the plugin loading manager creates a primary buffer and a secondary buffer to hold currently active access control policy plugins and new versions of policy plugins to be loaded, respectively. The plugin registry module records plugin metadata, including plugin identifier, version number, SHA256 checksum, dependency declaration, and capability declaration.

[0050] Once the security policy plugin package arrives at the plugin repository from the policy distribution center, the integrity verification module performs five-dimensional verification. Package format verification confirms the structural integrity of the policy plugin package. Digital signature verification confirms the plugin originates from a trusted policy distribution center. SHA256 fingerprint comparison confirms the plugin package has not been tampered with. Dependency compatibility verification verifies that the system library versions the policy plugin depends on are compatible with the current platform. Capability policy verification verifies that the access control permissions declared by the policy plugin comply with the platform's security policy requirements.

[0051] After all five dimensions of validation pass, the plugin loading manager loads the new version of the strategy plugin into the backup buffer, completing memory allocation and code mapping. The plugin loading manager performs resource warm-up operations, including loading strategy rules into memory, initializing the rule matching engine, and preloading frequently accessed strategy entries. The backup buffer plugin's state machine is set to the READY state. The health monitoring module registers health check callback functions with the backup buffer strategy plugin.

[0052] The double-buffered scheduler module performs an atomic switch. The first memory barrier ensures that all previous write operations are visible to subsequent reads. The active policy plugin for the main buffer is frozen, ceasing to accept new policy execution requests. After the active plugin has processed all pending requests, the pointer references of the main and standby buffers are swapped. The state machine of the standby buffer plugin is updated to the ACTIVE state, and the state machine of the main buffer plugin is updated to the STANDBY state. The global routing table is updated to route policy execution requests from the security detection engine to the new active plugin. The second memory barrier ensures the switch operation is visible to all threads. The health check object of the active plugin is updated to the health monitoring module. The atomic switch is complete, with the switch time controlled within 100 milliseconds.

[0053] After the switch is complete, the plugin loading manager unloads the old version of the policy plugin from the main buffer, releasing the system resources it occupies. The plugin registry module updates the metadata, updating the new version information to the currently valid record.

[0054] The health monitoring module continuously monitors the operational status of active policy plugins. When abnormal behavior is detected in a policy plugin, such as unauthorized permission escalation attempts or abnormal rule modification operations, the security module sends an abnormal behavior alarm to the health monitoring module. The health monitoring module determines whether to trigger a rollback based on preset thresholds. When the rollback condition is triggered, the dual-buffer scheduler module immediately performs an atomic switch, swapping the roles of the primary and backup buffers, restoring the old version of the policy plugin to its active service role. The rollback time is controlled within 50 milliseconds to ensure uninterrupted service.

[0055] The difference between this embodiment and Embodiment 1 lies in their application scenarios. Embodiment 1 focuses on updating the threat signature database, while Embodiment 2 focuses on updating security policy plugins. Both embodiments employ the same primary-backup dual-buffer architecture and atomic switching mechanism, verifying the versatility and scalability of the technical solution of this invention.

[0056] Example 3

[0057] This embodiment describes a specific application of the present invention in a scenario of incremental updates to the detection rule base. In this scenario, the network security operations platform needs to incrementally update the detection rule base, adding detection rules targeting specific attack patterns.

[0058] This scenario deploys the same system architecture as the aforementioned embodiments, with consistent collaboration relationships and data flow between modules.

[0059] In the dual-buffer initialization phase of step S1, the plugin loading manager creates an independent loading environment for the detection rule base plugin. The main buffer holds the currently active detection rule base plugins, while the backup buffer serves as a pre-loading area for incremental rule base updates. Unlike other types of plugins, the data segment of the detection rule base plugin is significantly larger than the code segment. Therefore, the plugin loading manager allocates a larger memory space for the data segment of the detection rule base plugin to ensure that it can accommodate the incrementally updated rule data.

[0060] In the plugin metadata registration phase of step S2, the plugin registry module stores special metadata for the detection rule base plugin. In addition to basic fields, the metadata for the detection rule base plugin includes the number of rules, the number of updated rules, a list of threat types covered by the rules, and an array of rule priorities. This special metadata is used for subsequent incremental loading decisions and conflict detection.

[0061] In the background preloading phase of step S4, after the integrity verification module performs five-dimensional verification, the plugin loading manager loads the incremental update rules into the backup buffer. Unlike full plugin updates, the plugin loading manager adopts a differential loading strategy in incremental update scenarios. The differential loading strategy parses the rule change list in the incremental update package, loading only newly added and modified rules, ignoring unchanged rules. The differential loading strategy significantly reduces memory usage and loading time. The plugin loading manager performs resource preheating, including building a fast index structure for incremental rules, precompiling the detection logic for incremental rules, and preloading incremental rules into the rule queue of the detection engine. The state machine of the backup buffer plugin is set to the READY state.

[0062] In the atomic handover phase of step S5, the double-buffered scheduler module performs the atomic handover operation. After the atomic handover is completed, the incremental update rule base plugin begins receiving requests from the security detection engine. During detection, the security detection engine simultaneously traverses both the main rule base and the incremental rule base to achieve detection coverage for new threats.

[0063] In the old version cleanup phase of step S6, the plugin loading manager performs a cleanup operation on the incremental rule base. Due to the incremental update strategy, unmodified rule data from older plugin versions remains in the main buffer. The cleanup operation only requires unloading the change records corresponding to the incremental update package and releasing the memory resources occupied by the incremental rules. The plugin state machine transitions and plugin registry updates are the same as in the previous embodiments.

[0064] This embodiment demonstrates the adaptability of the technical solution of the present invention in incremental update scenarios and verifies the universal support capability of the dual-buffer architecture for updates of different types of plugins.

[0065] 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.

Claims

1. An isolated dynamic plugin loading method for network security operation platforms, characterized in that, Includes the following steps: S1: Dual buffer initialization: The plugin loading manager creates two independent memory spaces, a main buffer and a backup buffer, to hold the main version plugin and the new version plugin to be switched, respectively, and allocates independent system resources to each buffer; S2: Plugin metadata registration. After a plugin package is uploaded to the plugin package repository, the system extracts the plugin's metadata information and writes it to the plugin registry. S3: Load plugins into the main buffer. Load the currently active version of the plugin into the main buffer, complete the memory mapping of the plugin code segment and data segment, initialize the plugin state machine to the ACTIVE state, and register the plugin entry point with the security detection engine. S4: Background preloading phase. When a new version plugin package is detected to have arrived, the background preloading process is triggered. The new version plugin package is retrieved from the plugin package repository and the package format, digital signature, and SHA256 integrity are verified. The dependency declaration of the new version plugin is parsed and its compatibility with the current runtime environment is checked. The capability declaration of the new version plugin is verified against the platform security policy. If all verifications pass, the new version plugin is loaded into the backup buffer and memory allocation and code mapping are completed. The initialization logic of the new version plugin is triggered to complete resource preheating. The state machine of the backup buffer plugin is set to the READY state. S5: Atomic Switching Phase. When the backup buffer plugin reaches the ready state, the double buffer scheduler performs an atomic switch, executes the first memory barrier to ensure that all previous write operations are visible to subsequent reads, freezes the active plugin of the main buffer and stops receiving new requests, waits for the main buffer plugin to finish processing all current in-transit requests, swaps the pointer references of the main buffer and backup buffer, updates the state machine of the backup buffer plugin to the ACTIVE state, updates the state machine of the main buffer plugin to the STANDBY state, updates the global routing table to route the security detection engine's requests to the new active plugin, and executes the second memory barrier to ensure that the switching operation is visible to all threads. S6: Old version cleanup phase. After the switch is completed, perform a safe cleanup of the old version plugins, unload the old version plugins in the main buffer, release the system resources occupied by the old version plugins, and reset the state machine of the main buffer plugins to the IDLE state. S7: Rollback mechanism. When the health monitoring module detects that an active plugin has failed a preset number of consecutive health checks or that the plugin has actively reported a fatal error, it triggers an automatic rollback. The rollback process uses the same atomic switching mechanism as step S5.

2. The method according to claim 1, characterized in that, In step S1, the main buffer and the backup buffer are two completely independent memory spaces, each configured with an independent resource management unit to ensure that the two buffers are physically completely isolated.

3. The method according to claim 1, characterized in that, The metadata in step S2 includes plugin identifier, version number, SHA256 checksum, dependency declaration array, capability declaration array, loading priority, and valid status flag.

4. The method according to claim 1, characterized in that, The integrity verification in step S4 adopts a five-dimensional verification mechanism, including packet format verification, digital signature verification, SHA256 fingerprint comparison, dependency compatibility verification, and capability policy verification.

5. The method according to claim 1, characterized in that, The resource preheating process in step S4 includes loading plugin configuration data into memory, initializing the plugin's internal data structure, performing plugin self-test, and preloading frequently used data resources.

6. The method according to claim 1, characterized in that, In step S5, the atomic switching uses a double-checked locking mechanism in conjunction with a memory barrier to ensure the atomicity of the switching operation.

7. The method according to claim 1, characterized in that, In step S5, the global routing table is updated using an atomic operation, which transfers the request route from the old version of the plugin to the new version of the plugin through a one-time pointer switch.

8. The method according to claim 1, characterized in that, The plug-in state machine includes eight states: IDLE, LOADING, READY, ACTIVE, STANDBY, UPDATING, FAILED, and ROLLBACK.

9. An isolated dynamic plug-in loading system for network security operation platforms, characterized in that, include: The double buffer module is used to create two independent memory spaces: a primary buffer and a backup buffer. The plugin loading manager is connected to both the main buffer and the backup buffer, and is used to perform plugin loading and unloading operations. The plugin registry module connects to the plugin loading manager and is used to store and manage plugin metadata. The integrity verification module, connected to the plugin registry module, is used to perform five-dimensional verification on the plugin package; The dual-buffer scheduler module is connected to the dual-buffer module and the integrity verification module respectively, and is used to control the role switching between the main buffer and the backup buffer. The health monitoring module, connected to the double-buffered scheduler module, is used to monitor the running status of active plugins and trigger rollback in case of an anomaly. The security detection engine, connected to the double-buffered scheduler module, is used to receive external requests and invoke active plugins for processing.

10. The system according to claim 9, characterized in that, The dual-buffer module configures an independent resource management unit for each buffer, including an independent memory allocator, thread pool, and resource handle table, to ensure that the two buffers are isolated at the resource management level.

Images