Network security protection method and system applied to regional digital asset business

Abstract

The present invention provides a network security protection method and system applied to regional digital asset business. The method includes: collecting asset data streams of multiple asset business nodes in the target area, extracting threat features of the asset data streams based on a preset threat knowledge graph, and generating a dynamic threat feature vector corresponding to the asset business node; inputting the dynamic threat feature vector into a pre-trained dynamic protection model, and outputting a real-time protection strategy adapted to the asset business node through the multi-layer decision network in the dynamic protection model; executing the strategy on the network traffic of the asset business node based on the real-time protection strategy, generating the strategy execution results and feeding them back to the dynamic protection model; adaptively optimizing the decision parameters of the dynamic protection model according to the strategy execution results, and generating an updated dynamic protection model for the next round of protection decisions for the asset business nodes.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a network security protection method and system applied to regional digital asset business. Background Art

[0002] With the acceleration of regional digitalization, key asset business nodes (such as smart terminals, cloud servers, and edge computing devices) in the fields of finance, energy, and government affairs have gradually become the core targets of cyber attacks. These nodes carry highly sensitive business data (such as real-time transaction information and user privacy data). Once attacked, they may lead to business interruptions, data leakage, and even systemic risks. To address such threats, network security protection technologies are usually used to monitor the network traffic of asset business nodes in real time and intercept threats. However, existing solutions have exposed significant limitations in complex and changing business environments. In existing technologies, mainstream protection methods can be divided into two categories:

[0003] Threat interception based on a static rule base: This system performs pattern matching on network traffic using predefined malicious IP blacklists, protocol feature libraries, or attack behavior signature libraries. For example, when a packet protocol field matches a known attack signature (such as a specific port scan), it directly triggers a traffic blocking rule. Anomaly detection based on a single-dimensional machine learning model: This system uses isolated features (such as traffic rate and connection frequency) to train a classification model to identify network behavior that deviates from the normal baseline. For example, by analyzing the temporal distribution of historical traffic, it can identify sudden high-frequency requests as DDoS attacks and generate a rate limit policy.

[0004] The above-mentioned approaches suffer from the following technical drawbacks: First, threat detection is fragmented, making it difficult to detect complex attacks. Traditional solutions focus solely on isolated features at the network or transport layer, ignoring the correlation between the business operation semantics, data interaction patterns, and asset attributes of asset business nodes. For example, attackers can steal data through legitimate combinations of low-risk interfaces, but traditional approaches, lacking business logic correlation analysis, are unable to identify such attacks. Second, policy generation is disconnected from business resource status, resulting in reduced protection effectiveness. Static rule bases rely on manual updates and struggle to adapt to the dynamic changes of asset business nodes. Policies generated by single-dimensional models often conflict with real-time resource loads. Third, protection models are rigid and unable to respond to evolving threats. Existing solutions often rely on offline training models or fixed rule bases, lacking dynamic optimization mechanisms based on actual protection effectiveness (such as false interception events and resource consumption metrics). For example, when new IoT devices are connected to asset business nodes, the existing models, not having learned the new protocol characteristics (such as MQTT protocol commands), may miss tampering attacks targeting device control commands.

[0005] These shortcomings lead to traditional protection solutions facing problems such as low detection accuracy, frequent policy conflicts, and delayed model iteration in regional digital asset business scenarios. Therefore, there is an urgent need for a protection method that can accurately identify complex attacks, ensure business continuity, and continuously adapt to the complex and changing threat environment. Summary of the Invention

[0006] In view of this, an embodiment of the present invention provides a network security protection method and system for regional digital asset services. The technical solution of the embodiment of the present invention is implemented as follows:

[0007] On the one hand, an embodiment of the present invention provides a network security protection method applied to regional digital asset business, the method comprising: collecting asset data streams of multiple asset business nodes in a target area, the asset data streams comprising business operation behavior characteristics, data interaction characteristics and asset attribute characteristics; based on a preset threat knowledge graph, performing threat feature extraction on the asset data streams, and generating a dynamic threat feature vector corresponding to the asset business node; inputting the dynamic threat feature vector into a pre-trained dynamic protection model, and outputting a real-time protection strategy adapted to the asset business node through a multi-layer decision network in the dynamic protection model; performing policy execution on the network traffic of the asset business node based on the real-time protection strategy, generating a policy execution result and feeding it back to the dynamic protection model; adaptively optimizing the decision parameters of the dynamic protection model according to the policy execution result, and generating an updated dynamic protection model for use in the next round of protection decisions for asset business nodes.

[0008] On the other hand, an embodiment of the present invention provides a network security protection system, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and the processor implements the steps in the above method when executing the program.

[0009] The network security protection method applied to regional digital and intelligent asset business provided by the present invention dynamically generates a threat feature vector reflecting the risk of the current business scenario by collecting multi-dimensional asset data streams of asset business nodes in real time and combining the context association capability of the threat knowledge graph; based on the branching processing of threat features by the multi-layer decision network, a real-time protection strategy set adapted to the resource status and threat level of the business node is generated, and the model parameters are optimized by executing a feedback closed loop to form a dynamic protection capability that adapts to the complex environment of the regional business. Specifically, by integrating business operation behavior characteristics, data interaction characteristics and asset attribute characteristics, the complete attack surface of the asset business node can be portrayed from multiple dimensions of business logic, interaction mode and asset attribute, solving the problem of incomplete threat coverage caused by traditional methods relying on a single network traffic feature, thereby significantly improving the detection accuracy of advanced persistent threats and internal abuse. Based on the dynamic threat feature extraction mechanism of the threat knowledge graph, the abnormal behavior in the real-time data stream is semantically associated with the known attack mode and vulnerability exploitation path to generate a dynamic threat feature vector containing the semantics of the business scenario, so that the threat feature not only contains protocol-level anomalies, but also reflects the potential risks at the business logic level, thereby enhancing the contextual understanding capability of new attacks. Through the branching policy generation mechanism of the multi-layer decision network, fine-grained protection policies can be generated for different threat dimensions. At the same time, policy execution priorities are dynamically adjusted based on real-time resource utilization, resolving protection delays or business interruptions caused by policy conflicts or resource contention in traditional approaches, thereby achieving a balance between security protection and business continuity. A closed-loop optimization mechanism based on policy execution results correlates and analyzes policy effectiveness indicators with security event logs, driving the continuous iterative optimization of dynamic protection model parameters. This allows the model to adapt to changes in the regional business environment and the evolution of new attack patterns, thereby avoiding the degradation of protection capabilities associated with traditional static rule bases or offline training models.

[0010] In summary, the present invention significantly improves the accuracy, real-time performance and environmental adaptability of network security protection in regional digital asset business scenarios through the synergistic effect of multi-dimensional data fusion, business semantics-driven threat feature generation, resource-aware real-time policy decision-making and closed-loop feedback optimization mechanism. It is particularly suitable for the dynamic protection needs of large-scale asset nodes in highly sensitive business fields such as finance and energy. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 A schematic diagram of the implementation flow of a network security protection method applied to regional digital asset business provided in an embodiment of the present invention.

[0012] Figure 2 A schematic diagram of the hardware entity of a network security protection system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0013] An embodiment of the present invention provides a network security protection method for regional digital asset services, which can be executed by a processor of a network security protection system. The network security protection system can refer to a server, laptop, tablet computer, desktop computer, mobile device (e.g., mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device), or other device with data processing capabilities.

[0014] Figure 1 A schematic diagram of the implementation process of a network security protection method for regional digital asset business provided by an embodiment of the present invention is shown as follows: Figure 1 As shown, the method includes:

[0015] Step S100: Collect asset data streams of multiple asset business nodes in the target area. The asset data streams include business operation behavior characteristics, data interaction characteristics, and asset attribute characteristics.

[0016] In the optional example, the target area refers to the geographical or logical network range where the digital asset management system is deployed, and its asset business nodes include but are not limited to core server clusters, edge computing devices, data transit gateways and terminal business interfaces. The asset data stream is a set of structured or unstructured data generated by each node during network transmission, and its collection process must cover the entire business cycle. The business operation behavior characteristics are specifically manifested as a set of operation sequences of node users, such as the number of login authentication times, file read and write commands, database query statements and API call frequencies. These characteristics can be obtained by parsing the operation logs in the network transport layer payload and are used to characterize the behavioral baseline of the node. Data interaction characteristics include the protocol type, data packet size distribution, session duration and traffic burst pattern of communication between nodes. They are extracted from the transport layer metadata through deep packet inspection technology to reflect the dynamic characteristics of data exchange between nodes. Asset attribute characteristics cover the static configuration information of the node, such as device model, operating system version, open port list, installed patch status and security policy version number. These characteristics are obtained by actively scanning the asset detection tool or passively monitoring the node broadcast information. To achieve efficient data collection, the system dynamically adjusts the data capture frequency based on node type. For example, core server clusters use millisecond sampling intervals, while edge computing devices use second-level intervals to ensure the integrity of critical business traffic. After all feature data is aligned within time windows, a collection of asset data streams with unified timestamps is formed. An outlier detection algorithm is then used to remove noise data caused by network jitter or device anomalies, ultimately generating a standardized asset data stream for subsequent processing.

[0017] Step S200: Based on the preset threat knowledge graph, threat features are extracted from the asset data stream to generate a dynamic threat feature vector corresponding to the asset business node.

[0018] In an optional example, the preset threat knowledge graph is a pre-built graph-structured database whose nodes include known attack pattern nodes, vulnerability exploitation path nodes, and threat behavior pattern nodes. Edge relationships represent the logical connections and evolutionary paths between attack techniques. Attack pattern nodes store typical attack chain characteristics, such as the traffic pulse patterns of distributed denial of service (DDoS) attacks and the lateral movement strategies of advanced persistent threats (APTs). Vulnerability exploitation path nodes record exploitable flaws and their penetration paths in specific device firmware or software versions. Threat behavior pattern nodes define the spatiotemporal characteristics of abnormal operation sequences, such as high-frequency data export during non-working hours. During the threat feature extraction phase, business operation behavior features are pattern-matched against threat behavior pattern nodes to identify potentially threatening operation sequences involving unusual command sequences or permission violations. For example, a high-risk flag is generated when unauthorized database batch export operations are detected. Data interaction features can be associated with vulnerability exploitation path nodes using a graph traversal algorithm to calculate the vulnerability exposure probability of the node in the current network topology. For example, when edge devices communicate using the unencrypted Modbus protocol, their exposure probability increases significantly due to protocol vulnerabilities. Asset attribute characteristics are mapped and matched with attack pattern nodes to generate quantitative attack surface assessment parameters, such as the weighted sum of the number of open high-risk ports and the weight of unpatched vulnerabilities. These three types of output are normalized and then vectorized according to threat dimensions to form a dynamic threat feature vector that incorporates temporal evolution. Its dimensional space encompasses the operational anomaly index, vulnerability risk level, and attack surface exposure coefficient, achieving a digital representation of the multi-dimensional threat landscape.

[0019] Step S300: Input the dynamic threat feature vector into the pre-trained dynamic protection model, and output a real-time protection strategy adapted to the asset business node through the multi-layer decision network in the dynamic protection model.

[0020] For example, the dynamic protection model is a multi-task learning architecture built on a deep neural network. Its multi-layer decision network includes a feature distribution layer and parallel traffic blocking, access control, and data encryption branches. The feature distribution layer decouples the dynamic threat feature vector, assigning an operational anomaly index to the traffic blocking branch, mapping vulnerability risk levels to the access control branch, and directing the attack surface exposure coefficient to the data encryption branch. The traffic blocking branch, for example, can use convolutional neural networks to perform deep protocol analysis on abnormal traffic features, identifying hidden attack payloads in transport layer payloads. For example, it can detect SQL injection attacks disguised as legitimate HTTP requests based on protocol field offsets and generate a traffic filtering rule set containing source IP blacklists, traffic shaping thresholds, and protocol filtering rules. The access control branch dynamically verifies user permission characteristics through a recursive neural network. Combining the session token lifecycle with access context, it generates an access control list based on the principle of least privilege, for example, restricting temporary accounts to access only specified API endpoints during a specific time period. The data encryption branch uses reinforcement learning algorithms to match sensitive data features with a library of encryption algorithms. It selects encryption strength parameters based on data processing latency tolerance. For example, it uses the AES-128-GCM algorithm for real-time video streams to balance security and transmission efficiency. It also generates a key distribution policy that rotates hourly. The outputs of each branch are analyzed using a rule interaction graph, and execution priorities are dynamically adjusted based on resource utilization. Ultimately, this is aggregated into a set of real-time protection policies consisting of a weighted execution sequence, ensuring that policies for nodes with high threat levels take precedence.

[0021] Step S400: executing the policy on the network traffic of the asset business node based on the real-time protection policy, generating the policy execution result and feeding it back to the dynamic protection model.

[0022] In an optional example, the policy execution process injects a lightweight proxy module into the network interface layer. This proxy module parses the rule priorities in the real-time protection policy set and implements protection actions in order of weight. For traffic filtering rules, the proxy module mounts a filtering hook at the network card driver layer, performs millisecond-level traffic blocking based on five-tuple information and protocol characteristics, and records the hash fingerprint of the intercepted data packet for audit purposes. The access control list rewrites the policy engine of the authentication microservice to insert dynamic permission verification logic during the session token verification phase. For example, it can forcibly terminate the session and generate a security alert when an unauthorized access attempt is detected. The key rotation policy is integrated into the password management middleware to trigger key update events within a preset time window and use a double buffer mechanism to avoid interruption of encryption services. During the policy's effectiveness, the system captures network traffic changes in real time, including the rate of decrease in the number of requests per second, the number of abnormal session terminations, and the delay in switching encryption algorithms, and simultaneously collects attack type labels and handling status from the security event log. Policy effectiveness is calculated by taking the weighted harmonic mean of policy response latency and threat interception success rate. For example, when a traffic filtering rule intercepts 90% of malicious requests within 50 milliseconds, its effectiveness is considered optimal. The resulting policy execution results, including rule hit statistics, resource consumption distribution, and remediation suggestion tags, are fed back to the dynamic protection model's parameter optimization module via an asynchronous message queue.

[0023] Step S500: Adaptively optimize the decision parameters of the dynamic protection model according to the policy execution result, and generate an updated dynamic protection model for the next round of protection decision making for asset business nodes.

[0024] In an optional example, the adaptive optimization process can employ an incremental learning mechanism. For example, it can first parse the correction suggestion labels in the policy execution results to locate the decision-branch network that needs optimization. For the traffic blocking branch, the time span of the protocol parsing window is adjusted based on the policy response latency, for example, shortening the initial 200 millisecond window to 150 milliseconds to reduce detection latency. At the same time, the blocking threshold judgment logic is updated based on the threat interception success rate, for example, dynamically adjusting the abnormal traffic ratio threshold from 5% to 3%. The access control branch optimizes the frequency of session token verification based on resource utilization. For example, when CPU utilization exceeds 70%, real-time permission verification is changed to asynchronous batch processing mode, and the access control list matching algorithm is restructured, using Bloom filters instead of full traversal to improve efficiency. The data encryption branch reselects the algorithm library based on the balance curve between encryption strength parameters and processing latency. For example, in scenarios where edge node resources are limited, the SHA-256 digest algorithm is replaced with SHA3-224 to reduce computational overhead. After gradient synchronization of optimized branch parameters, an updated model is generated for version iteration. Its stability is verified through a shadow deployment environment: historical attack samples and new attack variants are injected into simulated business nodes to monitor whether the false interception rate and missed detection rate are below preset thresholds. Models that pass verification are marked as stable versions and replaced with the online model through a hot deployment mechanism. Historical version snapshots are retained to support emergency rollbacks, ultimately forming a closed-loop, self-evolving protection system.

[0025] As an implementation method, step S100, collecting asset data streams of multiple asset business nodes in a target area, may include:

[0026] Step S110: Acquire business level classification information of asset business nodes, where the business level classification information includes core asset nodes, edge asset nodes, and transit asset nodes.

[0027] In an optional example, business-level classification information is a node type identification system based on network topology and business criticality, used to guide the development of differentiated data collection strategies. Core asset nodes refer to infrastructure entities that carry core business logic or store sensitive data, such as primary server clusters hosting critical databases, application service nodes processing financial transactions, and cloud storage nodes storing user privacy information. A disruption to their services would paralyze regional services. Edge asset nodes refer to terminal devices located at the edge of the network and performing lightweight computing tasks, such as industrial IoT sensors, smart terminal gateways, and mobile access devices. Their functions focus on data collection and preliminary processing. Transit asset nodes refer to intermediate devices in the network path that perform data forwarding or protocol conversion, such as load balancers, VPN gateways, and protocol conversion proxy servers. Their core role is to maintain network connectivity and data transmission efficiency. Business-level classification information is obtained by parsing network architecture design documents, asset registration databases, and dynamic topology scan results. For example, by proactively querying device service ports and operating status through the SNMP protocol and automatically labeling node types based on business dependency maps.

[0028] Step S120: According to the business level classification information, set the first collection frequency of the core asset node, the second collection frequency of the edge asset node, and the third collection frequency of the transit asset node respectively, wherein the first collection frequency is greater than the second collection frequency, and the second collection frequency is greater than the third collection frequency.

[0029] In an optional example, differentiated collection frequency configurations are dynamically set based on the business importance of the node and data timeliness requirements. The first collection frequency for core asset nodes uses millisecond-level data sampling intervals, for example, capturing full data packets from the network interface every 50 milliseconds to ensure real-time monitoring of fine-grained operational characteristics in high-frequency trading or high-concurrency access scenarios. The second collection frequency for edge asset nodes is set at second-level intervals, for example, collecting lightweight telemetry data uploaded by sensors every 2 seconds, balancing resource consumption with data integrity requirements. The third collection frequency for transit asset nodes is set at minute-level intervals, for example, capturing traffic statistics summaries every 5 minutes, focusing on monitoring bandwidth utilization and connection stability. Frequency parameters are dynamically distributed to the data collection agent through the configuration management interface and support flexible adjustment based on node load. For example, if the CPU utilization of a core node exceeds 80%, the first collection frequency can be temporarily increased from 50 milliseconds to 100 milliseconds to reduce performance impact. The frequency parameters strictly follow a gradient of core > edge > transit to ensure the collection priority of critical business data.

[0030] Step S130: For each asset business node, capture the original data packets in its network transmission protocol according to the corresponding collection frequency, and perform protocol analysis on the original data packets to extract business operation behavior characteristics, data interaction characteristics and asset attribute characteristics.

[0031] In the optional example, raw data packet capture is achieved through mirrored ports or bypass packet capture technology, and the capture action is triggered according to the preset collection frequency. For example, the complete payload data of the TCP / IP protocol stack is captured for core asset nodes within 50 millisecond intervals, including the Ethernet frame header, IP packet header, and application layer protocol content. The protocol parsing process uses a deep packet parsing engine to peel off the protocol header layer by layer and extract structured features: business operation behavior features are parsed from the application layer payload, such as the API endpoint call sequence in the HTTP request, the SQL query statement structure, and the metadata of the file upload operation; data interaction features are extracted from the transport layer and network layer headers, including the source / destination IP and port combination, the TCP window size change trend, and the ICMP message type distribution; asset attribute features are obtained by parsing device fingerprint information, such as the MAC address manufacturer code, the organization identifier in the TLS certificate, and the SSH service version number. The parsed feature data is encapsulated in JSON format, and the collection timestamp and node type label are attached to form the original feature record set.

[0032] Step S140: aligning the feature data of multiple asset business nodes collected within the same time window in time and space to generate a set of asset data streams with consistent timestamps.

[0033] In the optional example, the time window is defined as a fixed time interval for system clock synchronization, such as a window length of 1 second, to ensure the temporal correlation of data across nodes. The spatiotemporal alignment process first calibrates the system clock of each node's collection agent through the NTP protocol, and uniformly converts the timestamps of feature records into a standard time coordinate system. For cross-window data caused by network delays, a sliding window mechanism is used for dynamic attribution adjustment. For example, a data packet sent by an edge node 10 milliseconds before the end of the window is attributed to the current window rather than the next window. The aligned data is sorted by millisecond timestamps, and the feature values ​​of missing time points are filled with empty or default values. For example, when a transit node has no data transmission within a certain collection cycle, its data interaction feature is marked as "silent state". The final generated asset data stream set is a multi-dimensional time series matrix, whose row dimension represents the timestamp and the column dimension covers the feature types of all nodes, ensuring that subsequent analysis has temporal consistency.

[0034] Step S150: filtering the asset data stream set for noise and removing outliers to generate a standardized asset data stream.

[0035] In an alternative example, noise filtering can employ a dual mechanism based on a rules engine and statistical models. The rules engine defines protocol compliance checking policies, such as discarding malformed request packets that do not conform to the HTTP / 1.1 specification and filtering out invalid source addresses in ICMP redirect messages. The statistical model identifies outliers by calculating the Z-score distribution of feature values. For example, if the TCP window size of a core node suddenly increases by more than three standard deviations of its historical average, this is identified as an anomaly caused by network congestion and removed. For missing value handling, linear interpolation or forward filling is used to complete continuous features, for example, using the port usage rate at the previous time point to fill in missing values. Data normalization maps heterogeneous features to a unified dimension, such as converting port numbers to normalized values ​​between 0 and 1 and applying a logarithmic transformation to reduce the distribution range of packet sizes. The processed asset data streams meet the requirements of uniform format, no redundant noise, and temporal coherence, and are then fed into the downstream threat analysis module.

[0036] As an implementation method, step S200, based on a preset threat knowledge graph, extracting threat features from the asset data stream to generate a dynamic threat feature vector corresponding to the asset business node, may include:

[0037] Step S210: Loading the node relationship topology in the threat knowledge graph, where the node relationship topology includes known attack pattern nodes, vulnerability exploitation path nodes, and threat behavior pattern nodes.

[0038] The node relationship topology of the threat knowledge graph is a pre-built graph-structured data model. Its node entities and edge relationships are generated through attack chain analysis, vulnerability library association, and behavioral pattern mining in the cybersecurity field. Known attack pattern nodes store characteristic fingerprints of typical attack techniques, such as the traffic pulse patterns of distributed denial of service (DDoS) attacks, email payload characteristics of spear phishing attacks, and file encryption behavior sequences of ransomware. Each node includes attack phase classification, dependent resources, and historical impact range attributes. Vulnerability exploitation path nodes record vulnerability exploitation methods corresponding to Common Vulnerabilities and Exposures (CVE) numbers, such as the log injection path for CVE-2021-44228, the privilege escalation chain for CVE-2020-1472, and unauthorized access interfaces in specific IoT device firmware. Directed edges between nodes represent the potential for cascading vulnerability exploitation. Threat behavior pattern nodes define the spatiotemporal characteristics of abnormal operation sequences, such as frequent data export operations during non-working hours, unauthorized port scanning across security domains, and repeated communication attempts with known malicious IP addresses. The node relationship topology is loaded into memory through the graph database, and a multi-hop association index is established between entities, providing a structured reasoning basis for subsequent threat feature extraction.

[0039] Step S220: Pattern matching is performed on the business operation behavior characteristics in the asset data stream and the threat behavior pattern nodes to identify potential threat operation sequences.

[0040] Business operation behavior signatures include sets of operational instructions triggered by node users within application-layer protocols, such as the frequency of database query statements, directory paths for file read and write operations, and the combined patterns of API call parameters. The pattern matching process can employ a graph traversal algorithm based on temporal similarity to align signature sequences with standard behavioral templates within threat behavior pattern nodes. For example, if a core asset node is detected to have initiated more than 500 consecutive SELECT * FROM user_table database queries within 10 minutes, and this sequence meets an 85% similarity threshold with the "bulk data leakage attempt behavior" template within the threat behavior pattern node, it is marked as a high-risk potential threat operation sequence. The matching algorithm also considers the operational context. For example, if an edge asset node is identified as periodically uploading encrypted compressed files to an external IP address via FTP, the node's business role is considered to indicate a violation of the data outbound policy and generate a medium-risk threat operation sequence. All matching results are sorted by confidence and appended with the operation timestamp, protocol type, and associated vulnerability ID to form a weighted set of threat operation records.

[0041] Step S230: Calculate the vulnerability exposure probability of each asset business node based on the correlation between the data interaction characteristics and the vulnerability exploitation path nodes.

[0042] Data interaction characteristics encompass the protocol type, session duration, packet load distribution, and traffic burstiness exhibited by nodes during network communication. Graph embedding technology can be used to calculate correlation, mapping data interaction characteristics to the vector space of vulnerability path nodes and calculating the cosine similarity between the two. For example, a transit asset node continuously communicates with external devices using the unencrypted Modbus TCP protocol. This protocol type is directly associated with the "Industrial Protocol Unauthorized Access Vulnerability (CVE-2018-5407)" vulnerability path node. The trigger time dimension weight for sessions exceeding two standard deviations of the historical baseline is calculated, resulting in a calculated vulnerability exposure probability of 0.92 (range 0-1). For core asset nodes, if a TLS connection is detected with an older OpenSSL server known to be vulnerable to the Heartbleed vulnerability (CVE-2014-0160), the vulnerability exposure probability is dynamically adjusted to 0.78 based on the version identifier and heartbeat packet frequency during the protocol handshake phase. The calculated results are normalized by node type, and the historical mean is updated using a sliding window mechanism to ensure the timeliness of the probability values.

[0043] Step S240: Generate attack surface assessment parameters for the asset business node based on the mapping relationship between the asset attribute characteristics and the attack pattern nodes.

[0044] In an optional example, asset attribute characteristics include static configuration information such as device model, operating system version, open port list, and deployed patch status. Attack surface assessment parameters are generated using a multi-dimensional weighted scoring model, where the compatibility score between the device model and the attack pattern node is calculated based on the frequency of vulnerability disclosure by the manufacturer. For example, an industrial control device with 10 historically high-risk vulnerabilities has its model weight coefficient set to 0.3. The open port list is associated with the service exposure score of the attack pattern node. For example, if a server opens ports 135, 139, and 445, which are known to be vulnerable to lateral movement attacks, the exposure coefficient is increased by 0.1 for each high-risk port. The patch status score is based on the cumulative CVSS score of unpatched vulnerabilities. For example, if a node has three unpatched vulnerabilities with a CVSS score of 9.0 or higher, the patch dimension will be deducted by 0.27 points (0.09 for each vulnerability). The final parameter is calibrated by linearly combining the scores of each dimension and introducing the node business level weight (core node weight is 1.0, edge node weight is 0.6, and transit node weight is 0.3) to generate an attack surface assessment parameter in the range of 0 to 10. The higher the value, the greater the risk of attack faced by the node.

[0045] Step S250: vectorize and concatenate the potential threat operation sequence, vulnerability exposure probability, and attack surface assessment parameters to generate a dynamic threat feature vector containing multi-dimensional threat dimensions.

[0046] In an optional example, the vectorization process can employ a dimension-wise normalization and sequential concatenation strategy. Potential threat operation sequences are encoded as binary vectors, with each bit representing the matching status of a threat behavior pattern node (for example, a 5th bit of 1 indicates a detected SQL injection attempt). Bit values ​​are adjusted using confidence weighting. Vulnerability exposure probabilities are linearly scaled to 8-bit floating-point precision within the 0-1 range. Attack surface assessment parameters are mapped to the 0-1 range using Min-Max normalization and then converted to 16-bit fixed-point format. The three types of data are concatenated into a unified feature vector in dimensional order. For example, if the threat knowledge graph contains 200 threat behavior pattern nodes, the first 200 dimensions of the vector encode the operation sequence, the next dimension represents the vulnerability exposure probability, and the final dimension represents the attack surface assessment parameter. To enhance temporal correlation, a time decay factor is added to the vector. For example, if the threat operation sequence in the current time window has a weight of 1.0, the weight of the previous time window is reduced to 0.8, forming a dynamic threat feature vector with a time sliding window characteristic. This vector serves as a standard input format for real-time decision analysis by downstream dynamic protection models.

[0047] As an implementation method, step S300 inputs the dynamic threat feature vector into a pre-trained dynamic protection model, and outputs a real-time protection strategy adapted to the asset business node through the multi-layer decision network in the dynamic protection model. Specifically, the strategy may include:

[0048] Step S310: calling the feature distribution layer in the dynamic protection model to split the dynamic threat feature vector into multiple sub-feature segments according to the threat dimension.

[0049] In an optional example, the feature distribution layer serves as a pre-processing module for the dynamic protection model. Its core function is to perform dimensional decoupling and targeted allocation based on the multidimensional structure of the dynamic threat feature vector. The dynamic threat feature vector contains threat indicators from multiple dimensions, including the threat behavior sequence code generated in step S250, vulnerability exposure probability values, and attack surface assessment parameters. Using pre-set dimensional mapping rules, the feature distribution layer splits subfields related to protocol anomalies in the threat behavior sequence code (e.g., HTTP request method anomaly flags, TCP flag bit anomaly combinations) into traffic blocking sub-feature segments, splits user permission violation operation flags and session token verification status into access control sub-feature segments, and splits encryption algorithm identifiers and key lifecycle parameters into data encryption sub-feature segments. For example, when the dynamic threat feature vector contains a binary sequence bit indicating a SQL injection attempt, the sequence bit and its associated protocol type identifier (e.g., HTTP / 1.1) are fully extracted and encapsulated as a traffic blocking sub-feature segment, ensuring that the subsequent decision-branch network can focus on in-depth analysis of specific threat dimensions.

[0050] Step S320: Input each sub-feature segment into a corresponding decision branch network, where the decision branch network includes a traffic blocking branch, an access control branch, and a data encryption branch.

[0051] In an optional example, the decision-making branch network is a dedicated neural network structure deployed in parallel within the dynamic protection model. Each branch performs targeted processing based on the threat dimension type of the sub-feature segment. After receiving the traffic blocking sub-feature segment, the traffic blocking branch can initiate a convolutional neural network-based protocol parsing engine to perform cross-layer correlation analysis on protocol fields from the network layer to the application layer. For example, this can analyze the abnormal variation patterns of the User-Agent field in the HTTP header and the coordinated anomalies of the TCP window scaling factor. The access control branch can use a graph attention mechanism to process the access control sub-feature segments and construct a dynamic permission relationship graph for users, resources, and operations. For example, this can be achieved by performing real-time correlation and inference between the role identifiers in the session token and API endpoint access records. The data encryption branch can use a reinforcement learning algorithm to process the data encryption sub-feature segments, matching the encryption algorithm library with the algorithm combination that meets the current business scenario. For example, based on the computing power of the edge node, ChaCha20-Poly1305 can be selected instead of AES-GCM to reduce CPU load. The input and output interfaces of each branch network are seamlessly connected through standardized data formats, ensuring the efficient flow and processing of sub-feature segments.

[0052] Step S330: Perform deep protocol analysis on abnormal traffic features through the traffic blocking branch to generate traffic filtering rules and blocking thresholds.

[0053] In an alternative example, the protocol deep parsing process can employ a multi-level feature extraction strategy to separate protocol header fields (such as IP fragment offset and HTTP content type identifier) ​​from traffic blocking sub-feature fragments. A bidirectional long short-term memory (Bi-LSTM) network is then used to model the temporal dependencies between these fields. For example, when detecting the repeated occurrence of URL parameters containing the ".. / " path traversal feature in HTTP requests from a core asset node, the protocol parsing engine will correlate these parameters with unusual TCP sequence number jumps and identify them as directory traversal attack attempts. Based on this, the traffic blocking branch generates traffic filtering rules containing a five-tuple filter condition (source IP address, destination port number, and protocol type). Dynamic blocking thresholds are set based on the traffic peak distribution of historical attack samples. For example, a full port blocking threshold is triggered when the number of unusual requests exceeds 500 per second. The generated rule set is supplemented with a protocol compliance verification tag and an effective time window to ensure compatibility with existing firewall policies.

[0054] Step S340: Dynamically verify the user's authority characteristics through the access control branch and generate an access control list based on the session token.

[0055] In an optional example, a dynamic authentication mechanism can be implemented based on real-time session context and the principle of least privilege. The access control branch extracts user role identification, resource access path, and operation timestamp from the access control sub-feature fragment, and constructs a dynamic permission relationship graph through a graph neural network. For example, when a temporary account is detected attempting to access a sensitive table structure of the core database during non-working hours, the branch network will associate the account's session token issuance time (e.g., valid only during working hours) with historical access records (e.g., only SELECT operations are allowed) to generate a fine-grained access control entry containing "deny DDL statement execution." The generated access control list uses an attribute-based encryption (ABE) strategy to dynamically bind the metadata of the session token (e.g., device fingerprint, geographic location) to resource access permissions. For example, only sessions initiated from intranet IP segments are allowed to access the financial system API. List entries are sorted by risk level, and high-risk entries are loaded first into the policy execution agent.

[0056] Step S340: Dynamically verify the user's authority characteristics through the access control branch and generate an access control list based on the session token.

[0057] In an optional example, the dynamic verification mechanism is implemented based on real-time session context and the principle of least privilege. The access control branch extracts the user role identifier, resource access path, and operation timestamp from the access control sub-feature fragment, and constructs a dynamic permission relationship graph through a graph neural network. For example, when a temporary account is detected attempting to access a sensitive table structure of the core database during non-working hours, the branch network will associate the account's session token issuance time (e.g., only valid during working hours) with historical access records (e.g., only SELECT operations are allowed) to generate a fine-grained access control entry containing "deny DDL statement execution." The generated access control list uses an attribute-based encryption (ABE) strategy to dynamically bind the metadata of the session token (e.g., device fingerprint, geographic location) to resource access permissions. For example, only sessions initiated from intranet IP segments are allowed to access the financial system API. List entries are sorted by risk level, and high-risk entries are loaded first into the policy execution agent.

[0058] Step S350: Match the encryption algorithm to the sensitive data features through the data encryption branch to generate a key rotation strategy and encryption strength parameters.

[0059] In an optional example, the encryption algorithm matching process comprehensively considers data type sensitivity, processing latency constraints, and node computing power. The data encryption branch analyzes sensitive data features, such as the field structure of financial transaction records, from data encryption sub-feature fragments and selects the optimal algorithm combination from a predefined encryption algorithm library through a reinforcement learning agent. For example, for high-throughput video streaming scenarios, AES-128-CTR mode is selected to balance encryption speed and security; for private patient data stored on edge nodes, AES-256-XTS mode is used to provide full-disk encryption protection. Key rotation policies are triggered based on a dual factor of key usage count and time. For example, session keys are automatically rotated every 1GB of data encrypted or every 24 hours, and updates are seamlessly implemented through a key distribution center (KDC). Encryption strength parameters are dynamically adjusted based on node resource status. For example, when CPU utilization exceeds 70%, the encryption mode is switched from CBC to the lighter ECB mode to reduce computational overhead.

[0060] Step S360: Aggregate the output rules of each decision branch network to generate a real-time protection policy set including priority weights.

[0061] In an optional example, the rule aggregation process can employ a multi-dimensional conflict resolution and resource-aware scheduling mechanism. The traffic filtering rules generated by the traffic blocking branch, the access control lists output by the access control branch, and the key rotation policy developed by the data encryption branch are first converted into a unified policy description language (e.g., JSON format). Their execution dependencies and resource contention are then analyzed using a rule interaction graph. For example, if a traffic blocking rule requires blocking all connections from a specific IP address, and an exception entry exists in the access control list that allows access for that IP address, the policy aggregation engine will prioritize the traffic blocking rule based on the threat confidence (e.g., a vulnerability exposure probability of 0.95 associated with the blocking rule). Priority weights are dynamically adjusted based on the real-time resource utilization of each branch network. For example, if memory usage exceeds a threshold, the execution priority of the data encryption policy is lowered to prevent out-of-memory (OOM) risks. The resulting real-time protection policy set includes a weighted execution sequence, rollback conditions, and monitoring metric collection rules. For example, traffic filtering on high-risk ports is prioritized, followed by role-based access control, and finally triggering key rotation, forming a hierarchical protection system.

[0062] As an implementation method, step S360 aggregates the output rules of each decision branch network to generate a real-time protection policy set including priority weights, including:

[0063] Step S361: extract the protocol analysis result in the traffic filtering rule generated by the traffic blocking branch, identify the protocol type and traffic direction corresponding to the abnormal traffic characteristics in the protocol analysis result, and generate a protocol type identifier and a traffic direction identifier.

[0064] In the optional example, the protocol parsing result is the structured analysis data output by the traffic blocking branch after deep packet inspection of the network data packet, which includes the field decoding information of the transport layer to the application layer protocol. Abnormal traffic characteristics refer to the protocol field combination pattern that deviates significantly from the normal business traffic baseline, such as the continuous appearance of undefined method types in the HTTP request header (such as "G3T" instead of "GET"), and abnormal TCP flag bit combinations (such as SYN and FIN set at the same time). The protocol type identifier is standardized according to the protocol number registered by IANA, for example, the detected abnormal traffic is mapped to "HTTP / 1.1 protocol type identifier (80)" or "Modbus TCP protocol type identifier (502)". The traffic direction identifier is generated based on the source / destination IP address of the data packet and the preset security domain configuration of the node network topology, for example, the inbound traffic from the external Internet is marked as "INBOUND direction identifier (0x01)", and the lateral traffic across the security domain within the node is marked as "LATERAL direction identifier (0x02)". The identifier generation process is implemented through the protocol fingerprint library and the traffic direction decision tree to ensure the accurate mapping of abnormal traffic characteristics and identifiers.

[0065] Step S362: extract the session token verification result in the access control list generated by the access control branch, parse the user authority level and resource access scope in the session token verification result, and generate an authority level identifier and a resource scope identifier.

[0066] In an optional example, the session token verification result is the permission status data output by the access control branch after dynamically authenticating the user's identity credentials. For example, it includes the token issuing authority, expiration date, role declaration, and resource access declaration. The user permission level identifier is generated based on the hierarchical structure in the role declaration. For example, the system administrator role is encoded as "ADMIN Permission Level Identifier (L3)" and the ordinary user role is encoded as "USER Permission Level Identifier (L1)." The resource access scope identifier is generated based on the accessible API endpoints, database tables, or file paths declared in the token. For example, the permitted access to the finance system API group is marked as " / api / v1 / finance Resource Scope Identifier (R001)" and the customer information table of the core database is marked as "db.customer_info Resource Scope Identifier (R005)." The identifier generation process combines resource naming conventions with the principle of least privilege. For example, regular expressions are used to match the resource path pattern in the declaration and convert it into a unique identifier in the form of a hash value.

[0067] Step S363: extract the encryption algorithm identifier and encryption strength parameter in the key rotation policy generated by the data encryption branch, associate the encryption algorithm identifier with the data type of the sensitive data feature, and generate an encryption association identifier.

[0068] In the optional example, the encryption algorithm identifier is encoded according to the NIST standard cipher suite naming convention. For example, the AES-256-GCM algorithm is labeled "AES256GCM Algorithm Identifier (0xA1)" and the ChaCha20-Poly1305 algorithm is labeled "CHACHA20POLY1305 Algorithm Identifier (0xB3)." The encryption strength parameter is calculated by quantifying the key length, the algorithm's attack resistance, and performance overhead. For example, the strength parameter of AES-256-GCM is 9.8 (on a scale of 0-10), while that of AES-128-CBC is 8.5. The data type of sensitive data features is defined according to the data classification policy. For example, personally identifiable information (PII) is labeled "PII Data Type Identifier (D01)" and healthcare information (PHI) is labeled "PHI Data Type Identifier (D02)." The encryption association identifier combines the algorithm identifier and the data type identifier through a mapping table. For example, when AES-256-GCM is used to encrypt PHI data, the "D02-A1 encryption association identifier" is generated to ensure that the encryption policy accurately matches the data sensitivity.

[0069] Step S364: Construct a rule interaction relationship diagram based on the protocol type identifier, traffic direction identifier, permission level identifier, resource scope identifier and encryption association identifier. The nodes in the rule interaction relationship diagram represent the rule execution conditions corresponding to each identifier, and the edges represent the dependency or conflict relationship between different rules.

[0070] In an optional example, the rule interaction relationship graph is a directed weighted graph structure, in which the nodes are composed of the combination conditions of the five types of identifiers, for example, "HTTP / 1.1 protocol type identifier (80) + INBOUND direction identifier (0x01)" represents the filtering condition node for inbound HTTP traffic. The construction of the edge relationship is based on the causal analysis of the policy execution logic: the dependency edge indicates that a rule must be executed after another rule takes effect, for example, "enable data encryption (D02-A1 encryption association identifier) ​​first and then allow access to PHI data (R005 resource scope identifier)" generates a positive dependency edge; the conflict relationship edge indicates that there are mutually exclusive conditions between the rules, for example, "block all inbound traffic (protocol type identifier 80 + direction identifier 0x01)" and "allow administrators to access inbound API (ADMIN authority level identifier L3 + resource scope identifier R001)" generate a conflict edge due to overlapping conditions. The edge weight is obtained through statistics of historical policy execution logs. For example, when the execution success rate of the dependency relationship is 95%, the edge weight is set to 0.95, and when the false interception rate of the conflict relationship is 10%, the edge weight is set to 0.10.

[0071] Step S365: traverse the rule interaction relationship graph, detect node groups with dependency relationships and node groups with conflict relationships, and assign an initial priority weight to each node group based on the connection density of the node group and the historical strategy execution success rate.

[0072] In an alternative example, graph traversal can use a depth-first search and backtracking algorithm to identify groups of nodes that meet dependency or conflict conditions. The connection density of a dependent node group is determined by calculating the average in-and-out degree of the nodes within the group. For example, a group consisting of five nodes and having 10 dependency edges has a connection density of 2.0. The historical policy execution success rate is calculated based on the threat interception rate and false positive rate of the node group over the past 30 days. For example, a dependent group that successfully intercepted 98% of SQL injection attacks with a false positive rate of 1% would have a success rate score of 0.97. The initial priority weight is generated by linearly combining the connection density (weight 0.6) and the success rate (weight 0.4). For example, the initial weight for a group with a connection density of 2.5 and a success rate of 0.97 is (2.5 × 0.6 + 0.97 × 0.4) = 1.888. The priority weights of conflicting node groups are assigned based on the inverse proportion of the false positive rate of the conflicting edges. For example, conflicting edge false positive rates of 0.10 and 0.20 correspond to weights of 0.90 and 0.80, respectively.

[0073] Step S366: Dynamically adjust the initial priority weight according to the real-time resource occupancy of the traffic blocking branch, the access control branch, and the data encryption branch to generate a dynamic priority weight.

[0074] In this optional example, real-time resource utilization is obtained through the system performance monitoring interface, including CPU usage (e.g., traffic blocking branch utilization of 45%), memory usage (e.g., access control branch utilization of 120MB), and network bandwidth utilization (e.g., data encryption branch utilization of 30Mbps) for each branch. The dynamic adjustment formula is: dynamic weight = initial weight × (1 - branch resource utilization / resource threshold). For example, if the CPU utilization of the traffic blocking branch is 45% and the threshold is 70%, the dynamic weight of its association rule is adjusted to the initial value: 1.888 × (1 - 45 / 70) = 1.888 × 0.357 ≈ 0.674. If a branch's resource utilization exceeds the threshold (e.g., access control branch memory usage exceeds 150MB), its association rule is penalized, for example, by multiplying its weight by 0.5 to lower its execution priority. The adjusted weights are normalized and mapped to the range 0-1, forming a dynamic priority weight matrix.

[0075] Step S367: re-arrange the rule execution order of the node groups with conflicting relationships based on the dynamic priority weights to generate a rule execution sequence after the conflict is resolved.

[0076] In an alternative example, conflict resolution can employ a greedy algorithm, prioritizing rules with high dynamic weights. For example, when "blocking inbound HTTP traffic (weight 0.85)" conflicts with "allowing administrator access to the API (weight 0.75)," the blocking rule is executed first. For conflicting rules with similar weights (e.g., 0.80 vs. 0.78), a time decay factor is introduced to prioritize the most recently successfully blocked rule. After the execution sequence is generated, logical consistency is verified in a sandbox environment. For example, conflicting traffic is replayed in a simulator to verify that administrators are still allowed to access the API through the whitelist mechanism after the blocking rule is executed. The final sequence is sorted in descending order of weight, forming a linear execution chain, such as "Rule A (0.92) → Rule B (0.85) → Rule C (0.78)."

[0077] Step S368: The rule execution sequence is integrated with the node group with dependency relationships into a policy path to generate a real-time protection policy set including execution path branches and priority weights.

[0078] In an optional example, policy path fusion is implemented through a directed acyclic graph (DAG) topological sort, splitting dependency node groups into parallel execution subpaths. For example, the dependency group "Encrypt PHI data (D02-A1) → Allow access to db.customer_info (R005)" generates an independent subpath that is processed in parallel with other rules in the main execution chain. Execution path branches are divided based on the resource isolation requirements of the node group. For example, traffic filtering rules with high CPU usage are assigned to dedicated computing threads, while access control rules with low latency requirements are assigned to a fast processing queue. The final policy set is encapsulated in JSON format and contains each rule's execution conditions, dynamic weights, path branches to which it belongs, and timeout fallback policies, such as setting a traffic filtering rule to automatically downgrade to coarse filtering mode if it fails to complete within 50 milliseconds. The policy set is ensured to have integrity and traceability through version control tags and digital signatures, and is then loaded and implemented by the policy execution agent.

[0079] As an implementation method, step S400 performs policy execution on the network traffic of the asset service node based on the real-time protection policy, generates policy execution results and feeds them back to the dynamic protection model, which may specifically include:

[0080] Step S410: sorting the execution order of the traffic filtering rules, access control lists and key rotation policies according to the priority weights in the real-time protection policy set.

[0081] Priority weights are numerical execution priority identifiers generated by the dynamic protection model in the aforementioned embodiments based on rule conflict resolution and resource status assessment. These weights typically range from 0 to 1, with higher values ​​indicating greater urgency for policy execution. Traffic filtering rules include source IP address blacklists, protocol type filtering conditions, and traffic rate limit thresholds. For example, the associated rules for core asset nodes that detect distributed denial of service (DDoS) attack traffic are assigned a priority weight of 0.95. Access control list entries encompass user role permission mappings, resource access time window restrictions, and session token lifecycle policies. For example, entries that allow temporary accounts to access sensitive APIs during non-business hours are assigned a weight of 0.8. Key rotation policies include key update trigger conditions, encryption algorithm switching rules, and key distribution path configuration. For example, key policies for edge nodes storing user privacy data are assigned a weight of 0.7. The sorting process utilizes a max-heap data structure, sorting the policy execution sequence in descending order of weight to ensure that high-weighted rules are loaded into the execution queue first. For example, when traffic filtering rules (0.95), access control list entries (0.8) and key rotation policies (0.7) exist at the same time, the system will generate an execution sequence chain of "blocking abnormal IP → restricting temporary account permissions → triggering key updates" in sequence.

[0082] Step S420: injecting a policy execution agent into the network interface layer of the asset business node, and the policy execution agent sequentially implements traffic filtering, permission verification and data encryption operations according to the execution order.

[0083] In an alternative example, the network interface layer refers to the protocol stack layer within the operating system kernel that handles network packet forwarding. The policy enforcement agent is a lightweight kernel module or user-mode daemon embedded between the network card driver and the protocol stack via a hook mechanism. Traffic filtering is implemented by registering Netfilter hook functions. For example, during the PREROUTING phase, a filter function is mounted to drop SYN packets from blacklisted IP addresses based on a five-tuple rule, while also limiting outbound traffic of specific protocol types during the POSTROUTING phase. Permission verification is integrated into the authentication microservice. For example, a dynamic policy engine is inserted into the API gateway's authentication interceptor to verify in real time whether the role identifier in the session token matches the resource scope in the access control list. Data encryption is implemented by hijacking the application-layer socket read and write functions. For example, when sensitive data characteristics are detected, the OpenSSL library is called to encrypt the plaintext data into AES-256-GCM ciphertext according to the key rotation policy. The agent module uses atomic operations to ensure the atomicity of policy enforcement, such as using spinlocks to ensure data consistency during key updates and avoid encryption state conflicts.

[0084] Step S430: monitor the execution status of the policy execution agent in real time, and capture the network traffic change characteristics and security event logs during the policy effectiveness period.

[0085] In an optional example, execution status monitoring is implemented through kernel probes (Kprobes) and performance counters (Perf Events), collecting real-time CPU usage, memory usage, and interrupt latency metrics of the policy execution agent. Network traffic characteristics include changes in inbound / outbound packet rates, TCP retransmission rates, and protocol type distribution. For example, after traffic filtering rules take effect, the packet loss rate for abnormal IP addresses increases from 90% to 99% using sFlow sampling technology. Security event logs record details of policy-triggered events. For example, interception logs contain attack type tags (such as SQL injection), source IP addresses, destination ports, and rule hit timestamps, while encryption logs contain key IDs, algorithm identifiers, and encrypted data block hash values. Monitoring data is temporarily stored in a ring buffer and uploaded to the analysis engine in batches according to preset time windows (e.g., every second), ensuring a balance between real-time performance and system overhead.

[0086] Step S440: extracting the policy response delay, threat interception success rate and resource occupancy rate from the network traffic change characteristics to generate a policy effectiveness index.

[0087] In an optional example, policy response latency refers to the time interval from policy loading to the first rule taking effect. For example, the latency from the injection of a traffic filtering rule to the dropping of the first malicious packet must be less than 10 milliseconds. The threat interception success rate is calculated as the ratio of successfully intercepted threat events to the total number of detections. For example, if 98 SQL injection attack attempts were intercepted out of 100, the success rate is 98%. Resource utilization is normalized by CPU, memory, and bandwidth usage. For example, the CPU utilization of the traffic filtering proxy is mapped from 15% to 0.15 (on a scale of 0-1). Performance metrics are generated using a multi-dimensional weighted scoring model. For example, a weight of 0.4 is assigned to response latency, 0.5 to interception success rate, and 0.1 to resource utilization. The final score is (latency score × 0.4 + success rate score × 0.5 + resource score × 0.1). Metric data is stored as continuous records in a time series database (TSDB), supporting sliding window aggregation queries.

[0088] Step S450: Perform correlation analysis on the security event log and the policy effectiveness indicator to generate a policy execution result including policy modification suggestions.

[0089] In an optional example, correlation analysis can employ a timestamp-based event-metric alignment algorithm. For example, this involves performing a sliding window match between attack interception time points in security event logs and response latency curves in performance metrics to calculate the average latency deviation during the attack peak period. Causal strength analysis uses transfer entropy to quantify the correlation between event types and metric fluctuations. For example, when a distributed denial of service (DDoS) attack occurs, if resource utilization increases by more than 0.3 and the interception success rate decreases by 5%, a strong causal relationship is determined. Policy correction recommendations are generated based on correlation pattern matching based on a predefined optimization rule base. For example, when the response latency of a traffic filtering rule exceeds 20 milliseconds and the CPU utilization exceeds 0.25, the "Optimize rule matching algorithm" and "Enable hardware offload" recommendations are triggered. Execution results are fed back to the dynamic protection model in the form of a structured report, including raw data references, a summary of the analysis process, and a sequence of corrective actions, such as "Reduce traffic filtering rule complexity → Replace regular expression matching with a DFA state machine → Enable NIC SR-IOV virtualization acceleration."

[0090] As an implementation method, the above step S450, performing correlation analysis on the security event log and the policy effectiveness indicator to generate a policy execution result including a policy modification suggestion, includes:

[0091] Step S451: extracting the event type identifier, event triggering timestamp and event impact range from the security event log to generate a security event log feature set.

[0092] In an optional example, the security event log is standardized audit data recorded by the policy enforcement agent during the protection process. Its event type identifiers are coded according to the MITRE ATT&CK attack framework. For example, SQL injection attacks are tagged with "TA0001-T1190 Event Type Identifier" and distributed denial of service attacks are tagged with "TA0048-T1498 Event Type Identifier." Event trigger timestamps are recorded with millisecond accuracy in the ISO 8601 extended format (e.g., "2023-08-25T14:30:45.789Z") and synchronized with an NTP server to ensure cross-node time consistency. The impact of an event is quantified by the number of affected asset business nodes, the magnitude of the data breach, and the duration of service disruption. For example, an attack that caused three core servers to downtime for two hours is labeled "Impact Level L3 (number of nodes ≥ 3, duration ≥ 1 hour)." Feature collections are indexed and stored by event unique identifiers, forming a structured dataset consisting of a triplet of event type identifier, timestamp, and impact score.

[0093] Step S452: extracting the indicator type identifier, indicator collection timestamp and indicator value range from the strategy effectiveness indicator to generate a strategy effectiveness indicator feature set.

[0094] In some examples, policy effectiveness indicators include quantitative parameters such as threat interception success rate, policy response latency, and resource utilization. Indicator type identifiers are categorized and coded by performance dimension, such as "Threat Interception Success Rate Identifier (KPI-001)" and "CPU Usage Identifier (KPI-005)." Indicator collection timestamps and event trigger timestamps are aligned using the same time source to ensure the accuracy of time series correlation analysis. Indicator value intervals are generated using sliding window statistics. For example, the average CPU utilization of an edge node between 10:00 and 10:05 (45%-52%) is mapped to the interval identifier "KPI-005:45-52." Feature sets are stored as records in a time series database. Each record contains the indicator type identifier, collection time window, and upper and lower bounds of the value, supporting efficient range queries and aggregate calculations.

[0095] Step S453: Based on the time window overlap relationship between the event triggering timestamp and the indicator collection timestamp, the security event log feature set and the policy effectiveness indicator feature set are time-aligned to generate a spatiotemporal correlation feature pair.

[0096] In an alternative example, time window overlap analysis can use a sliding window matching algorithm. A correlation window is defined as ΔT (e.g., ±30 seconds) before and after the event trigger timestamp. All performance metrics collected within this window are then filtered. For example, if a SQL injection attack event is triggered at 10:00:00, the correlation window is 09:59:30 to 10:00:30. During this period, metrics such as "Threat Interception Success Rate (KPI-001): 92%-95%" and "CPU Usage (KPI-005): 48%-53%" are extracted. Spatiotemporal correlation feature pairs are associated using a combination of event type identifiers and metric type identifiers. For example, "TA0001-T1190 event type identifier + KPI-001 metric type identifier" represents the correlation pair for the attack event and the interception success rate metric. The aligned feature pairs are then assigned a temporal overlap ratio parameter (e.g., 85% data coverage within the window) for subsequent causal strength calculations.

[0097] Step S454: Construct an association relationship graph based on the mapping relationship between the event type identifier and the indicator type identifier. The nodes in the association relationship graph represent event features or indicator features in the spatiotemporal association feature pairs, and the edges represent the causal strength and synchronization parameters between the event features and the indicator features.

[0098] In this optional example, the association graph is a weighted directed graph with nodes divided into event feature nodes (such as TA0001-T1190) and indicator feature nodes (such as KPI-001). Edge weights are calculated using a combination of causal strength and synchronicity parameters. Causal strength quantifies the information contribution of an event to indicator fluctuations using transfer entropy. For example, if a SQL injection attack causes a 5% decrease in interception success rate, the causal strength is 0.78 (range 0-1). The synchronicity parameter calculates the time-lagged correlation between event and indicator changes. For example, if CPU usage increases 5 seconds after an attack, the synchronicity parameter is 0.65. Edge direction indicates the causal flow. For example, "TA0001-T1190 → KPI-005" indicates that the attack event caused an increase in CPU usage. The graph is constructed using an incremental update mechanism, merging new association pairs and adjusting edge weights after each analysis cycle.

[0099] Step S455: traverse the association relationship graph, detect the node groups connected by edges with high causal strength, and identify the key association node groups based on the coverage relationship between the event impact range and the indicator value interval.

[0100] In this optional example, assuming a high causal strength threshold of 0.7, the traversal process filters association pairs with edge weights ≥ 0.7. For example, the causal strength of the edge "TA0048-T1498 (DDoS attack) → KPI-005 (CPU usage)" is 0.85, and the event impact level L4 (number of nodes ≥ 10) highly overlaps with the CPU usage range of 75%-90%, making it a critical association node group. Coverage relationships are calculated using Jaccard similarity. For example, if the similarity between the attack-affected node set and the high CPU usage node set is 0.8, the coverage coefficient is set to 0.8. The comprehensive score for the critical node group is a linear combination of the causal strength (weight 0.6) and the coverage coefficient (weight 0.4), for example, 0.85 × 0.6 + 0.8 × 0.4 = 0.83. Groups above the threshold of 0.75 are marked as critical associations.

[0101] Step S456: extracting the event type identifier, indicator type identifier and historical modification record corresponding to the key association node group, and generating association pattern features.

[0102] In this optional example, the association pattern feature is a triplet structure consisting of an event type identifier, an indicator type identifier, and a historical corrective action hash. For example, the key association group "TA0001-T1190 + KPI-001" historically triggered "Optimize SQL Filtering Rules (Action Hash A1B2)" and "Increase WAF Thread Count (Action Hash C3D4)." Feature generation is achieved using association rule mining algorithms, such as the Apriori algorithm, which identifies frequently co-occurring event-indicator-action combinations. Each pattern feature is assigned support (e.g., the combination occurs at a 30% rate) and confidence (e.g., the probability that the corrective action effectively improves the indicator is 85%), resulting in a feature entry such as "TA0001-T1190 → KPI-001: support 0.3, confidence 0.85, action [A1B2, C3D4]."

[0103] Step S457: calling the pre-trained correction rule library, matching the associated pattern features with the rule conditions in the correction rule library, and screening out candidate correction rules that meet the matching threshold.

[0104] In an optional example, the correction rule base is, for example, an if-then rule set generated based on historical operation and maintenance experience and machine learning. Each rule contains a trigger condition (such as "KPI-001<90%&TA0001-T1190 appears") and a correction action (such as "Optimize the regular expression engine"). The matching process uses fuzzy logic reasoning to calculate the similarity between the associated pattern features and the rule conditions: complete match of the event type identifier (weight 0.5), indicator interval inclusion relationship (such as the current KPI-001 is 85%-90% matching the "<90%" condition in the rule, weight 0.3), and historical action hash matching (weight 0.2). For example, if the similarity between a pattern feature and a rule condition reaches 0.85 (threshold 0.8), it is determined to be a candidate rule. The selected candidate rules are sorted in descending order of confidence, and rules that conflict with the node resource status are eliminated (such as excluding correction actions that require high memory when memory is insufficient).

[0105] Step S458: Based on the correction action type and priority parameters in the candidate correction rule and in combination with the resource status of the current policy execution agent, a policy correction suggestion including a correction action sequence and an execution order is generated.

[0106] In the optional example, corrective action types are categorized as immediate (e.g., blocking an IP address) or gradual optimization (e.g., adjusting model parameters). Priority is calculated based on rule confidence and urgency. For example, a rule with a confidence of 0.9 and an impact range of L3 has a priority of P0 (highest). Resource status is obtained through the real-time monitoring interface. For example, if the current available memory is 2GB, the "Upgrade Detection Engine" action, which requires 1.8GB of memory, is excluded. Action sequence generation uses topological sorting to ensure that dependent actions are executed in order (e.g., "Expand Memory" before "Enable Deep Learning Model"). The final recommended format is a JSON array, such as "[{'action':'update_regex','priority':0.9,'resource_needs':{'cpu':'30%','mem':'500MB'}}, ...]," for invocation by the dynamic protection model parameter optimization module.

[0107] Step S459: Verify the effectiveness of the policy correction suggestions and policy effectiveness indicators, eliminate correction actions that conflict with the current network environment, and generate optimized policy execution results.

[0108] In an optional example, validity verification can be achieved by replaying historical traffic and attack samples in a sandbox environment. For example, after applying the "Optimize Regular Expression Engine" corrective action in the simulator, replay the traffic containing SQL injection attacks in the past 24 hours to verify whether the interception success rate has increased from 85% to 92%. Conflict detection is based on network topology policy compatibility checks. For example, when the corrective action requires enabling IPv6 filtering but the current node only supports IPv4, the action is marked as a conflict. The optimized policy execution results include a list of effective actions, a list of conflicting actions, and verification indicator comparison data, such as "KPI-001 increased by 7% after action A took effect, and action B was eliminated due to insufficient resources." The result data is digitally signed to ensure integrity and is persistently stored in the audit database for compliance review.

[0109] As an implementation method, step S500 adaptively optimizes the decision parameters of the dynamic protection model based on the policy execution result to generate an updated dynamic protection model for the next round of protection decision making for asset service nodes, including:

[0110] Step S510: Analyze the policy modification suggestions in the policy execution results, and extract the decision branch network identifiers and parameter adjustment directions that need to be optimized.

[0111] The policy execution result is a structured report generated in step S450, containing multi-dimensional correlation analysis data. Its policy correction suggestion field stores a set of optimization instructions for each decision branch of the dynamic protection model. The parsing process utilizes a semantic template-based recursive descent analysis method. First, the natural language suggestions in the report are converted into machine-readable JSON-formatted action instructions. For example, "Reduce the protocol parsing depth of the traffic blocking branch to shorten response latency" is converted to {"branch":"traffic blocking branch","action":"reduce_parsing_depth","param":"protocol_layer"}. The decision branch network identifier is extracted by matching predefined network topology labels. For example, when the correction suggestion involves "Inefficient access control list matching," it is automatically associated with the unique identifier of the access control branch, "ACL_Branch_001." The parameter adjustment direction is derived from the action type and target parameter fields in the instruction. For example, for the suggestion "Increase encryption algorithm matching speed," the extracted parameter direction is "encryption_algorithm_selection_latency" and the optimization target is marked as "Reduce by 20%." The analysis results form an optimization task list containing branch identifiers, parameter paths, and expected value ranges, providing input for subsequent targeted tuning.

[0112] Step S520: For the traffic blocking branch, adjust the traffic detection window size according to the policy response delay, and update the blocking threshold decision logic according to the threat interception success rate.

[0113] In an optional example, the traffic detection window size can be the length of the time interval used to cache network packets during deep protocol parsing. Adjustment is based on a historical correlation curve between policy response latency and window size. For example, if the average response latency of core asset nodes increases from 15 milliseconds to 25 milliseconds, the system calculates, using a sliding window regression model, that the optimal window size should be reduced from 200 milliseconds to 150 milliseconds to reduce context switching overhead. The blocking threshold decision logic is updated based on a Bayesian probability model of the threat interception success rate. For example, if the interception success rate for SQL injection attacks drops from 92% to 85%, the abnormal request count threshold in the decision logic is dynamically adjusted from 500 to 300 per second, and the protocol field anomaly matching mode is switched from exact matching to fuzzy matching (the similarity threshold is reduced from 95% to 90%). The parameter adjustment process utilizes an online learning mechanism, verifying the effectiveness of the new thresholds through real-time injection of synthetic attack traffic to ensure improved response speed without compromising interception accuracy.

[0114] Step S530: For the access control branch, dynamically adjust the verification frequency of the session token based on the resource occupancy rate, and optimize the matching algorithm of the access control list.

[0115] In an optional example, the session token verification frequency refers to the number of permission reviews for the same token per unit time. Its adjustment strategy is dynamically calculated based on the CPU and memory usage of the access control branch. For example, when the memory usage of the edge node exceeds 75%, the verification frequency is reduced from 100 to 50 times per second, and the verification interval for high-scoring tokens (such as sessions from trusted IP segments) is extended to 2 seconds through the token trust scoring mechanism. The access control list matching algorithm is optimized using a data structure reconstruction strategy. For example, the original linear traversal matching is replaced with a fast pre-screening mechanism based on Bloom filters, reducing the matching time complexity from O(n) to O(1). At the same time, cache hot path optimization is introduced, and independent hash indexes are established for frequently accessed API endpoints (such as " / api / v1 / transaction"), reducing the permission verification delay from 5 milliseconds to 1 millisecond. The optimized algorithm is verified through A / B testing to ensure that there are no false positives or missed detections in 99% of request scenarios.

[0116] Step S540: for the data encryption branch, reselect the target algorithm in the encryption algorithm library according to the balance between the encryption strength parameter and the data processing delay.

[0117] In an optional example, the encryption strength parameter is comprehensively assessed based on the algorithm's key length, encryption mode, and quantum attack resistance. For example, the strength parameter for the AES-256-GCM algorithm is 9.8 (on a scale of 0-10), while that for the ChaCha20-Poly1305 algorithm is 9.5. Data processing latency includes both encryption operation time and key distribution latency. For example, in IoT edge node scenarios, the encryption latency for AES-256-GCM is 8 milliseconds / KB, while that for ChaCha20-Poly1305 is 5 milliseconds / KB. The trade-off is determined through Pareto front analysis. For example, when the node CPU utilization threshold is set at 70%, ChaCha20-Poly1305 is selected as the primary algorithm to reduce latency by 3 milliseconds / KB, while simultaneously reducing the strength parameter tolerance by 0.3. The algorithm switching process utilizes a double buffering mechanism, running the old and new algorithms in parallel during the key rotation cycle until the new algorithm passes integrity verification and is fully switched, avoiding service interruption.

[0118] Step S550: synchronize the parameters of the optimized decision branch networks, generate an updated dynamic protection model with version iteration, and write the update log into the model version library.

[0119] In an optional example, parameter synchronization utilizes a distributed gradient aggregation strategy. First, the protocol parsing depth parameters for the traffic blocking branch, the Bloom filter bit array for the access control branch, and the algorithm selection weights for the data encryption branch are uploaded to the parameter server. A consistent hashing algorithm is used to ensure that each node has the latest copy of the parameters. During version iterations, the network weights of the dynamic protection model are incrementally updated to incorporate optimization results. For example, the Adam optimizer is used to adjust the learning rate of the traffic blocking branch from 0.001 to 0.0005. Historical weight snapshots are retained to support rollbacks. The update log records parameter comparisons before and after the adjustment, performance benchmark results, and compatibility verification status, such as "Traffic detection window: 150ms ← 200ms (33% latency reduction) | Blocking threshold: 300 times / second ← 500 times / second (3% success rate increase)." Log entries are sorted by ISO 8601 timestamp and stored in the model repository. The log is integrated with the Git version control system, supporting multi-dimensional search and difference analysis by node type, time range, or optimization type.

[0120] As an implementation method, the pre-training process of the dynamic protection model may specifically include the following steps:

[0121] Step S10: Construct a training data set of historical asset service nodes, where the training data set includes normal service traffic samples, known attack traffic samples, and mixed traffic samples.

[0122] In this optional example, the training dataset for historical asset business nodes is constructed using real-world business environment data collected over a period of at least 12 months, covering all business scenarios across core, edge, and transit asset nodes. Normal business traffic samples are extracted from security-audited business logs and include standard protocol interactions (e.g., HTTP / 1.1 GET / POST request sequences and full connection records for the TCP three-way handshake) and compliant operational behaviors (e.g., database transaction commit logs and file system read and write operation records). Known attack traffic samples are derived from public vulnerability databases (e.g., CVE and NVD) and attack payloads generated by penetration testing tools. These samples cover typical attack patterns, such as UDP floods for distributed denial of service (DDoS) attacks, malformed request parameters for structured query language injection (SQL injection), and malicious script payloads for cross-site scripting (XSS). Hybrid traffic samples are generated by proportionally blending normal business traffic with known attack traffic. For example, five SQL injection probe requests per minute are inserted into a one-hour core node access log to simulate a covert attack scenario in a real-world environment. All samples are classified and stored by node type, protocol type and time window to form a structured dataset with metadata labels.

[0123] Step S20: Perform feature enhancement processing on the training data set to generate an enhanced data set containing spatiotemporal disturbance features.

[0124] In an optional example, feature augmentation aims to improve the model's adaptability to dynamic changes in the business environment and adversarial attacks. Temporal and spatial perturbation features are injected by applying a random offset of [-5%, +5%] to the timestamps of normal business traffic samples to simulate traffic fluctuations during different peak hours. For example, HTTP request logs originally evenly distributed between 9:00 and 18:00 are expanded to cover the bursty access patterns during the morning peak. Noise packets that conform to protocol specifications (such as filling invalid TCP option fields or adding redundant HTTP header parameters) are inserted into known attack traffic samples to generate adversarial samples with obfuscated features. For example, 10% of legitimate SELECT statements are mixed into SQL injection attack payloads to evade simple regular expression detection. Protocol field mutation is performed on mixed traffic samples, modifying key application layer protocol fields (such as changing the HTTP method type from GET to G3T or randomly converting JSON key names to upper and lower case). This generates protocol compatibility test samples to verify the model's robustness to non-standard protocol implementations. The augmented dataset undergoes time window alignment and protocol semantic verification to ensure that the perturbation operation does not compromise the business logic integrity of the original data.

[0125] As an implementation method, step S20 performs feature enhancement processing on the training dataset to generate an enhanced dataset containing spatiotemporal disturbance features, which may specifically include:

[0126] Step S21: adding random time offsets to normal business traffic samples to simulate traffic fluctuations during different business peak periods.

[0127] In an alternative example, time offsetting can utilize a sliding window resampling technique, imposing a random Poisson-distributed delay on each packet's timestamp while preserving the original business operation sequence. For example, the original time interval for database transaction logs on a core asset node is 100 ± 20 milliseconds. By adding a uniformly distributed offset of [-10ms, +10ms], the interval becomes irregularly distributed, ranging from 90 to 110 milliseconds, simulating the processing latency variations caused by server load fluctuations. The offset range is dynamically adjusted based on node type, with a narrow offset (±5%) for core nodes to maintain business continuity and a wide offset (±15%) for edge nodes to enhance adaptability to intermittent connections. The offset samples undergo causality verification to ensure the order of the operation sequence remains unchanged, avoiding transaction logic conflicts caused by time misalignment.

[0128] Step S22: inserting noise data packets into the known attack traffic sample to generate an adversarial sample with obfuscation features.

[0129] In an alternative example, a noise packet insertion strategy is implemented using protocol fuzzing techniques, injecting random noise into key fields of the attack payload. For example, an invalid comparison operator is inserted into the WHERE clause of a SQL injection attack (e.g., 1' OR '1'='1' becomes 1' OR %% '1'='1'), or redundant padding bytes are added to the UDP payload of a DDoS attack to increase its length beyond the MTU limit. The noise injection ratio is controlled within a range of 5%-15% to ensure that attack signatures remain detectable while requiring the model to have higher generalization capabilities. After adversarial samples are generated, a protocol compliance checker is used to filter out malformed packets (e.g., checksum errors, length violations) caused by the noise injection. Samples that comply with transport layer specifications but exhibit semantic anomalies at the application layer are retained to form a high-quality adversarial training set.

[0130] Step S23: Perform protocol field mutation on the mixed traffic sample to generate a protocol compatibility test sample.

[0131] In an alternative example, protocol field mutation can employ a syntax tree-based deep mutation strategy. After parsing the abstract syntax tree (AST) of the application layer protocol, specific nodes are replaced with equivalent semantics. For example, the User-Agent field value in the HTTP request header can be mutated from "Mozilla / 5.0" to "Mozi11a / 5.O", or the Boolean value true in the JSON payload can be changed to 1. For binary protocols (such as Modbus TCP), sub-function codes can be randomly adjusted while maintaining the legal value range of the function code field (for example, mutating the read holding register function code 0x03 to 0x83). The mutated samples are verified for network layer compatibility using protocol conformance testing frameworks (such as Packetdrill) to ensure that they can be parsed by standard protocol stacks, effectively training the model to recognize unconventional but legal protocol implementations.

[0132] Step S24: Combine the normal samples, adversarial samples and protocol variation samples after time shift to generate an enhanced data set.

[0133] In an optional example, the sample combination process uses a stratified sampling method to ensure that the enhanced dataset covers all node types and attack scenarios. For example, in the core asset node data subset, time-shifted normal samples, SQL injection adversarial samples, and HTTP protocol variant samples are mixed in a ratio of 6:2:2; in the edge node subset, normal samples, DDoS adversarial samples, and Modbus protocol variant samples are mixed in a ratio of 5:3:2. The temporal relationship and causal dependency of the original data are preserved during combination, for example, the TCP sequence number continuity of the previous and next packets is maintained at the location where the adversarial sample is inserted. The final enhanced dataset associates the original samples with the enhanced operation records through a unique hash identifier to support traceability analysis of the training process.

[0134] Step S25: Label each sample in the enhanced dataset with a multi-dimensional threat label and a recommended protection strategy label.

[0135] In an optional example, multi-dimensional threat labels can be vectorized annotations based on the threat knowledge graph, including attack type (e.g., DDoS, SQL injection), associated vulnerabilities (e.g., CVE numbers), attack phase (e.g., reconnaissance, penetration), and impact level (score of 0-10). Recommended protection policy labels are generated based on historical response records, for example, labeling a SQL injection sample with a multi-step policy sequence of "block source IP | enable parameterized query detection | trigger database audit." This labeling process utilizes a semi-automated toolchain: a threat intelligence platform automatically matches attack samples with CVE numbers and mitigation measures, followed by review and supplemental fine-grained policy recommendations by security experts. Label data is stored in JSON-LD format and indexed with the sample data's timestamp, protocol type, and node type fields, enabling the model's multi-task learning framework to access it.

[0136] Step S30: Initialize the network weights of the dynamic protection model and set the multi-task learning objective function, which includes threat classification loss, strategy generation loss and resource consumption loss.

[0137] In an optional example, network weights can be initialized using the He normal distribution method, with different initial variances set for convolutional and fully connected layers. For example, convolution kernel weights are initialized using a fan-in pattern to adapt to the input dimensions of the feature distribution layer. The multi-task learning objective function integrates three subtask losses through a weighted summation: the threat classification loss uses a focal loss to address class imbalance, for example, assigning higher weights to rare attack types (such as APTs); the policy generation loss uses an edit distance algorithm to calculate the difference between the recommended and predicted policy sequences, for example, comparing the positional deviation between "block IP → enable detection" and the predicted "enable detection → block IP"; and the resource consumption loss uses an L1 regularization term to constrain the predicted CPU and memory usage during model inference, for example, limiting the memory usage of the access control branch to no more than 50MB. The loss weights are dynamically adjusted based on task importance. Initially, the threat classification loss weights are set to 0.6, the policy generation loss weights to 0.3, and the resource consumption loss weights to 0.1. These weights are then gradually balanced as the model converges.

[0138] Step S40: adopt a phased training strategy, first freeze the parameters of the decision branch network and train the feature distribution layer, and then unfreeze the decision branch network for end-to-end joint training.

[0139] For example, the phased training strategy can achieve parameter freezing through a gradient mask mechanism. In the first phase, only the convolution kernel parameters and attention mechanism weights of the feature distribution layer are updated. For example, when training the feature distribution layer, the neural network parameters of the traffic blocking branch, access control branch, and data encryption branch are locked, forcing the model to prioritize learning the ability to decouple features across threat dimensions. When the validation set accuracy of the feature distribution layer reaches 85%, all decision branch parameters are unfrozen, and an adaptive learning rate strategy (such as cosine annealing) is used for end-to-end optimization. Adversarial training technology is introduced in the joint training phase, and the adversarial samples generated in step S22 are mixed into the training batch at a ratio of 15% to improve the model's ability to discriminate against obfuscated features. The training process uses mixed precision calculations. The feature distribution layer uses FP32 precision to maintain numerical stability, and the decision branch network uses FP16 precision to accelerate calculations.

[0140] Step S50: Determine the final model parameters through the early stopping mechanism and cross-validation to generate a pre-trained dynamic protection model.

[0141] In the optional example, the early stopping mechanism monitors the multi-task loss function on the validation set and terminates training when the loss decreases by less than 0.5% for 10 consecutive epochs to prevent overfitting. Cross-validation uses a stratified K-fold strategy (K=5) to ensure that each data subset maintains the original attack type distribution. For example, in each fold of validation, the enhanced dataset is divided into five mutually exclusive subsets, one of which is selected as the validation set, and the rest are used as the training set. Training is repeated until the validation indicators of each fold are stable. The final model parameters are selected from the checkpoint with the highest threat classification F1-score and resource consumption below the threshold in cross-validation. The weights of the optimal models in each fold are integrated using parameter averaging. The pre-trained dynamic protection model is exported in ONNX format, with a model card document containing training hyperparameters, data version, and performance indicators to ensure the reproducibility of the deployment environment.

[0142] As an implementation manner, the method provided in the embodiment of the present invention further includes a process of performing dual-channel verification during policy execution, which may specifically include:

[0143] Step S600: while the local protection agent of the asset service node executes the real-time protection policy, it sends a policy verification request to the cloud verification server.

[0144] In an optional example, the local protection agent is a lightweight security component deployed in the kernel or user space of the asset business node's operating system. Its core functions include real-time loading of protection policies generated by dynamic protection models, performing traffic filtering, permission verification, and data encryption. Policy verification requests are sent using an asynchronous duplex communication mechanism. While the local policy is in effect, policy metadata (such as the five-tuple conditions of traffic filtering rules, role-resource mappings in access control lists, and the algorithm identifier of the key rotation policy) and context characteristics (such as node type, protocol distribution, and resource utilization) are encapsulated in a JSON-formatted request body via HTTPS and uploaded in real time to the cloud-based verification server. For example, when a core asset node executes the rule "block all TCP connections from source IP address 192.168.1.100," the local protection agent simultaneously sends a verification request to the cloud containing the rule, the node identifier, and the current CPU utilization (e.g., 45%). This ensures that the cloud-based verification process does not affect the real-time execution of the local policy.

[0145] Step S700: The cloud verification server performs compliance verification on the real-time protection policy based on the global threat intelligence library and generates a policy modification instruction.

[0146] In an optional example, the global threat intelligence library is a distributed knowledge graph that aggregates threat data from multiple sources (such as the CVE vulnerability library, the MITRE ATT&CK attack pattern library, and industry compliance standards). Its verification process is implemented through a graph pattern matching and rule inference engine. Compliance verification includes policy validity verification (e.g., whether blocking rules cover the latest attack variants), policy conflict detection (e.g., whether filtering rules conflict with existing firewall policies), and compliance review (e.g., compliance with GDPR data encryption requirements). For example, if the cloud detects that a rule set by an edge node to "allow all ICMPv6 packets through" could be exploited for NDP protocol spoofing attacks, it generates a remediation instruction containing the restriction of ICMPv6 packets of types 135-136. The remediation instruction is digitally signed to ensure integrity and is accompanied by a priority tag (e.g., high-risk instructions must respond within 5 seconds) and execution conditions (e.g., only takes effect when the node's memory usage is below 70%), forming a structured set of policy remediation instructions.

[0147] Step S800: If the local protection agent detects an execution result that conflicts with the policy modification instruction, it triggers the protection policy rollback mechanism and loads the previous version of the dynamic protection model.

[0148] In an alternative example, conflict detection can be achieved by comparing local policy execution results (such as threat interception logs and resource consumption metrics) with the expected effects of cloud-based remediation instructions. For example, when the local policy "blocking RDP protocol connections on port 3389" is executed, if cloud-based verification finds that this rule disrupts legitimate operations and maintenance channels (based on the whitelisted IP addresses in the global intelligence library), a policy conflict is identified. After the rollback mechanism is initiated, the local protection agent pauses the current policy engine and initiates a version search request to the model repository, filtering compatible historical model versions based on node type, policy hash value, and time range. For example, for core asset nodes, the three most recent stable versions (such as v2.1.3, v2.1.2, and v2.1.1) are searched, excluding historical versions applicable only to edge nodes (such as v2.0.5-edge). Model switching utilizes hot reloading technology. While ensuring uninterrupted network connectivity, the network weights of the dynamic protection model are replaced from the current version parameters (such as the weight matrix containing the latest blocking threshold logic) to the parameter snapshot of the historical version. The policy execution agent is then restarted to load the rolled-back model instance.

[0149] In step S800, the protection policy rollback mechanism is triggered to load the previous version of the dynamic protection model, which may specifically include:

[0150] Step S810: Retrieve a historical model version compatible with the current asset business node from the model version library.

[0151] In an optional example, the model version library is a tamper-proof storage system built based on blockchain technology. Each historical version contains the model network weights, training data set fingerprints, and compatibility metadata (such as supported node types, protocol types, and operating system versions). The retrieval process uses semantic version number matching and dependency resolution algorithms. For example, when the current node is running in the Linux kernel 5.4.0 environment, only model versions marked as compatible with "Linux ≥ 5.4" are retrieved. Compatibility verification is achieved by replaying historical traffic samples in a sandbox environment. For example, the rollback candidate model is loaded into a simulation environment, and a copy of the node's network traffic in the past 24 hours is injected to verify whether it can correctly generate protection actions consistent with historical policies. Versions that pass the compatibility test are arranged in reverse order by timestamp for subsequent fitness evaluation and selection.

[0152] Step S820: Compare the decision parameters of the historical model version with the adaptability of the current environment characteristics and select the optimal rollback version.

[0153] In an optional example, fitness assessment uses a multi-objective optimization model to quantify the degree of fit between historical versions across various dimensions. Decision parameter fitness uses cosine similarity to calculate the similarity between the current environment's feature vectors (such as threat vector distribution and resource utilization) and the training data features of historical versions. Policy execution effectiveness fitness uses replay testing to compare the interception success rates of historical and current versions (e.g., version v2.1.3 achieved a 95% interception rate in testing, while the current version achieved an 88% interception rate). Resource consumption fitness assesses whether the CPU / memory usage of historical versions matches the available resources of the current node. For example, if a node currently has 2GB of available memory, historical versions requiring more than 1.8GB of memory (such as v2.1.0-memheavy) are excluded, and version v2.1.2, which uses 1.2GB of memory and has an interception rate of 90% or higher, is selected as the optimal rollback target. The evaluation results generate a fitness score matrix, which is sorted by weighted total score and the highest-scoring version is selected.

[0154] Step S830: Pause the current policy execution process and switch the network weights of the dynamic protection model to the parameters of the optimal rollback version.

[0155] In an optional example, the suspension of the policy execution process can be achieved through atomic operations. For example, a SIGSTOP signal is first sent to the policy execution agent to suspend all threads, and then the model weight area in the shared memory is marked as read-only to prevent concurrent modifications during the switching process. The network weight switching uses memory-mapped file technology to load the optimal rollback version of the weight file (such as v2.1.2.weights.bin) into a pre-allocated continuous memory area, and redirect the model inference function to the new weight address through pointer redirection. After the switch is completed, a SIGCONT signal is sent to the agent to resume thread execution. For example, a core node completed the weight switch from v2.1.3 to v2.1.2 within 10 milliseconds, and the policy execution delay caused by thread suspension during this period did not exceed 3 milliseconds, ensuring that business continuity was not significantly affected.

[0156] Step S840: Reinitialize the policy execution agent and generate an alternative protection policy based on the model parameters after the rollback.

[0157] In an optional example, the reinitialization process may include clearing the current policy cache, resetting the policy engine state, and loading the rollback model parameters. The initialization script of the policy execution agent configures the runtime parameters based on the rollback version metadata, such as allocating a dedicated memory pool for version v2.1.2 and setting a matching number of concurrent threads. The generation of alternative protection policies is achieved through real-time reasoning of the current threat feature vector by the rollback model. For example, based on the decision logic of the historical model v2.1.2, the original "block all ICMPv6 messages" policy is adjusted to "only filter ICMPv6 router solicitation messages of type 133". The new policy is gradually implemented through a grayscale release mechanism, first applied to 10% of the traffic samples and monitoring the effect, and then expanded to all traffic after confirming that there are no conflicts.

[0158] Step S850: After the alternative protection policy takes effect, a rollback completion notification is sent to the cloud verification server, and a model difference analysis task is started to locate the cause of the original policy conflict.

[0159] In an optional example, the rollback completion notification can include the rollback version number, the switch timestamp, and preliminary performance indicators (e.g., an increase in interception rate to 92%), which the cloud server then updates the node status dashboard accordingly. The model difference analysis task uses gradient backpropagation and feature attribution techniques to compare the decision differences between the rollback model and the conflict model. For example, Class Activation Map (CAM) visualization revealed that the original model misclassified legitimate traffic due to its excessive focus on the TCP window size feature, while the rollback model placed greater emphasis on payload content analysis. The analysis results generate a root cause report (e.g., "Weight offset in the feature distribution layer leads to protocol parsing anomalies"), which triggers a model retraining task to fix the defect.

[0160] Step S900: When the verification results of the local protection agent and the cloud verification server are consistent, the local policy cache is updated and the current protection policy is confirmed to be valid.

[0161] In the optional example, the consistency judgment of the verification result must meet the following conditions: the set of correction instructions returned by the cloud verification is an empty set, and the local policy execution indicators (such as threat interception rate and resource utilization) are within the reasonable range preset by the cloud (such as interception rate ≥ 90%, CPU utilization ≤ 60%). The cache update uses a copy-on-write mechanism to mark the current policy set as a stable version and store it persistently on the local SSD, while updating the version number and hash check value of the memory cache. For example, after three consecutive verifications, an edge node upgrades the policy cache version from v1.0.5 to v1.0.6, and simultaneously updates the hash value to ensure policy integrity. The confirmation information is reported to the cloud through a heartbeat message, and the global policy effectiveness status database is updated to complete the dual-channel verification closed loop.

[0162] As an implementation manner, in step S500, after generating the updated dynamic protection model, the method provided by the embodiment of the present invention may further include:

[0163] Step S501: Load the updated dynamic protection model into the shadow deployment environment, which includes simulated service nodes and simulated traffic that are consistent with the current asset service node network topology.

[0164] In an optional example, a shadow deployment environment can be constructed using virtualization technology to accurately replicate the network topology of the target asset's business nodes, including the load balancing configuration of the core server cluster, the gateway policy of the edge device, and the routing table rules of the transit node. The simulated business nodes are instantiated using containerization technology, such as using Docker containers to simulate business nodes with the same operating system version, service port, and middleware configuration. Simulated traffic is generated using a traffic replay tool, such as historical business traffic packets captured based on tcpdump, replayed according to the original timestamp and protocol distribution characteristics, and 10%-20% noise packets are injected to simulate network jitter. The dynamic protection model loading process uses a hot deployment mechanism to push the model weight file (such as model_v2.1.3.weights) to the policy engine in the shadow environment through the API gateway to ensure zero-downtime switching.

[0165] Step S502: inject historical attack traffic samples and new attack traffic samples not covered by the current protection strategy into the shadow deployment environment to generate mixed test traffic.

[0166] In the optional example, historical attack traffic samples are selected from the internal threat intelligence library, for example, a pcap file containing CVE-2021-44228 vulnerability exploitation traffic, and annotated SQL injection attack request sequence. New attack traffic samples are generated through red team simulation tools, such as using the Metasploit framework to construct an APT attack payload based on a zero-day vulnerability, or generating adversarial escape traffic through a GAN network. The mixed test traffic combines normal business traffic, historical attack traffic, and new attack traffic in a ratio of 7:2:1. For example, 700Mbps normal traffic, 200Mbps known attack traffic, and 100Mbps new attack traffic are injected into 1Gbps simulated traffic to ensure that the test covers comprehensive threat scenarios.

[0167] Step S503: Perform protection decision processing on the mixed test traffic using the updated dynamic protection model, and capture the policy response behavior and decision delay data of the simulated service node.

[0168] In an optional example, during the protection decision-making process, the policy engine in the shadow environment applies the updated model parameters in real time to perform protocol parsing, permission verification, and data encryption operations on inbound traffic. Policy response behavior records include rule hit logs (such as blocking malicious IP lists and releasing whitelist sessions), anomaly detection events (such as buffer overflow attempt markings), and resource allocation status (such as thread pool usage). Decision delay data is collected using high-precision timestamps to measure the time interval from the arrival of the data packet to the effectiveness of the policy, such as counting the P50 (50 milliseconds), P95 (120 milliseconds), and P99 (200 milliseconds) quantiles of the HTTP request processing delay. All data is aggregated through a distributed log system to form a timestamped tracking chain.

[0169] Step S504: extracting the misinterception events, missed interception events and delay exceeding limit events in the policy response behavior, and generating a model defect feature set.

[0170] In the optional examples, a false interception event is defined as an instance where legitimate business traffic is mistakenly blocked, for example, a normal user login request is intercepted due to a misjudgment of a protocol field; a missed interception event refers to an instance where attack traffic goes undetected, such as a new type of DDoS attack that bypasses threshold detection rules; and a latency limit event marks an anomaly where policy execution time exceeds the preset SLA (e.g., HTTP request processing latency >150ms). The defect feature set is constructed using feature engineering methods: false interception event features include the hash value of the misjudged protocol field, traffic direction, and node type; missed interception event features extract the entropy distribution of the attack payload and the protocol anomaly index; and latency limit events record thread scheduling delays and peak CPU usage. The feature set is stored as a vector matrix using standardized encoding for subsequent root cause analysis.

[0171] Step S505: performing correlation analysis on the model defect feature set and the decision parameters of the updated dynamic protection model to locate the decision branch network and weight distribution abnormal nodes that cause the defect.

[0172] In an optional example, association analysis can use gradient attribution and decision tree decomposition. For example, gradient attribution calculates the gradient contribution of each decision branch when a defect event occurs. For example, the convolution kernel weight of the traffic blocking branch contributes 0.65 to a certain false interception, indicating that it is the main influencing factor. Decision tree decomposition maps the model reasoning path into a rule tree, identifying nodes corresponding to high-frequency defect paths. For example, it was found that 80% of missed interception events flowed through a specific fully connected layer in the access control branch. Weight distribution anomaly nodes are detected through KL divergence, comparing the weight distribution differences between the normal model and the updated model. For example, if the weight distribution deviation of a certain LSTM layer exceeds 3σ, it is marked as an anomaly. The analysis results generate a defect topology map, annotating the coordinates of the problematic branches and nodes.

[0173] Step S506: Based on the abnormal type of the decision branch network, the corresponding parameter tuning rule is matched from the correction rule library to generate a shadow environment tuning instruction.

[0174] In an optional example, the correction rule base is a structured document storage system. Each rule includes a trigger condition (such as "traffic blocking branch false interception rate > 5%), an anomaly type code (such as F001 - protocol misjudgment), and a tuning action (such as "reduce the convolution kernel learning rate by 20%"). The matching process uses a multi-stage filtering process: first, candidate rule sets are retrieved based on the anomaly type code; for example, F001 corresponds to 10 relevant rules. Then, decision parameter range constraints are used to filter, for example, only rules applicable to the LSTM layer are retained. Finally, based on historical tuning performance scores, rules with a confidence level ≥ 90% are selected to generate tuning instructions. The instructions are formatted as a JSON instruction set, for example, {"action": "adjust_learning_rate", "target_layer": "conv_block_3","value": "-20%"}.

[0175] Step S507: executing the shadow environment tuning instruction in the shadow deployment environment, performing secondary optimization on the decision parameters of the updated dynamic protection model, and generating a tuned dynamic protection model.

[0176] In an optional example, parameter tuning can be implemented through an online learning framework, such as using TensorFlow's Keras API to dynamically modify model layer parameters. For convolution kernel learning rate adjustment, an exponential decay strategy is used to reduce the initial learning rate from 0.001 to 0.0008. For nodes with abnormal weight distribution, L2 regularization constraints are applied to bring them closer to the baseline distribution. After secondary optimization, the model is verified through lightweight retraining, such as using 5% mixed test traffic for rapid fine-tuning (50 epochs) and verifying the effect on the remaining traffic. The tuned model is exported as an optimized weight file (such as model_v2.1.3_tuned.weights), with a tuning log recording the parameter change details.

[0177] Step S508: reload the tuned dynamic protection model into the shadow deployment environment for iterative verification until the number of false interception events, missed interception events, and delay exceeding limit events is lower than a preset threshold.

[0178] In an optional example, iterative verification uses a progressive testing strategy. For example, the first verification uses 20% mixed traffic. If the false interception rate is ≤2%, the missed interception rate is ≤1%, and the P99 delay is ≤150ms, it is expanded to full traffic testing. Thresholds are set based on business SLA requirements. For example, financial core nodes require a false interception rate of ≤0.5% and a missed interception rate of ≤0.1%. If the standards are not met, a second tuning cycle is triggered. For example, when the missed interception rate is still 1.2%, supplementary rules (such as "increasing the proportion of adversarial training samples") are retrieved from the correction rule base, new tuning instructions are generated, and steps S506-S507 are repeated. After verification, a test report is generated, recording the defect convergence curve and final performance indicators of each iteration.

[0179] Step S509: Mark the verified and optimized dynamic protection model as a stable version and synchronize it to the local protection agent of the asset business node to replace the previous version of the dynamic protection model.

[0180] In an optional example, version tagging can be achieved through digital signatures and blockchain-based notarization, attaching metadata tags containing hash values, timestamps, and test metrics to the tuned model files. The synchronization process uses a differential update mechanism, transmitting only the changed weight parameter blocks (e.g., 50KB of data for the conv_block_3 layer), reducing network bandwidth consumption. After receiving the update package, the local protection agent first verifies the digital signature and hash value, then atomically replaces the old version of the model file in transactional storage. A double-buffering mechanism is enabled during the replacement to ensure uninterrupted policy execution. For example, the new model is loaded into a spare memory area, and traffic processing is instantly taken over via a hot-swap instruction.

[0181] As an implementation manner, in step S509, after synchronization to the local protection agent of the asset service node, the method provided by the embodiment of the present invention may further include:

[0182] Step S5010: monitor the resource status of the asset business node in real time. The resource status includes CPU usage, memory usage, and network bandwidth utilization.

[0183] Resource monitoring is typically achieved through operating system-level performance counters and hardware sensors. For example, CPU utilization measures the percentage of usr / sys / iowait threads per logical core; memory utilization measures process RSS (resident set size) and swap usage; and network bandwidth utilization measures network interface card throughput (rx_bytes / tx_bytes) and packet loss rate. Data is collected at a granularity of one second, and a moving average is calculated using a sliding window (e.g., a 10-second window). For example, a 1-minute average of 45% CPU utilization and a 5-minute peak of 75% can be calculated. Monitoring data is stored as a time series, supporting real-time visualization and threshold alarm triggering.

[0184] Step S5011: Identify the resource load level and resource bottleneck type of the asset service node based on the dynamic changes in resource status.

[0185] In an optional example, resource load levels can be categorized based on multiple metrics, such as low load (CPU < 30%, memory < 50%, bandwidth < 40%), medium load (30% ≤ CPU < 70%, 50% ≤ memory < 80%, 40% ≤ bandwidth < 70%), and high load (CPU ≥ 70%, memory ≥ 80%, bandwidth ≥ 70%). Resource bottleneck types are determined through dominant factor analysis. For example, if a node's CPU utilization reaches 85% and its memory utilization is 60%, it is labeled "CPU bottleneck." If bandwidth utilization reaches 90% and the TCP retransmission rate increases, it is labeled "bandwidth bottleneck." This identification results form a resource profile, such as "Edge Node E23: High Load - Bandwidth Bottleneck," to guide subsequent optimization strategy development.

[0186] Step S5012: extract the mapping relationship between the decision parameters and resource consumption of the tuned dynamic protection model, and build a model resource adaptation rule library.

[0187] In an alternative example, a mapping relationship can be established through multivariate regression analysis. For example, a linear model can be established between the number of convolution kernels (X1), the LSTM hidden layer dimension (X2), and CPU utilization (Y): Y = 0.3X1 + 0.5X2 + ε. The resource adaptation rule library stores these relationships and constraints. For example, rule R102 defines "When the CPU is a bottleneck, the hidden layer dimension must be ≤ 128." The rule generation process combines experimental data with theoretical derivation. In a controlled environment, model parameters are gradually reduced (for example, reducing the number of neurons in the fully connected layer from 256 to 128). Resource consumption curves are recorded, and critical points are extracted as constraints. The rule library is indexed by resource type (CPU / memory / bandwidth) and node type (core / edge / transit).

[0188] Step S5013: Based on the resource load level and resource bottleneck type, the decision parameter constraint conditions that adapt to the current resource status are selected from the model resource adaptation rule library.

[0189] In an alternative example, the filtering logic can employ hierarchical matching. For example, a subset of applicable rules is first selected based on node type (e.g., edge node), then corresponding constraints are selected based on resource bottleneck type (e.g., bandwidth bottleneck), and finally, constraint thresholds are adjusted based on load level (e.g., high load). For example, for high-load bandwidth-bottleneck edge nodes, rule R205 is applied: "When bandwidth utilization ≥ 70%, limit the encryption algorithm to AES-128-GCM (bandwidth consumption ≤ 5Mbps / session)." Constraints are dynamically combined to generate a parameter adjustment space, such as the allowed number of convolution kernels in the range [64, 128] and the LSTM step size range [5, 10].

[0190] Step S5014: performing resource-aware parameter compression on the decision branch network of the optimized dynamic protection model according to the decision parameter constraints to generate a lightweight dynamic protection model.

[0191] In an optional example, parameter compression can employ a hybrid strategy of structured pruning and quantization. For example, channel pruning is applied to the convolutional layers of the traffic blocking branch, removing filters with a contribution below 10%. Weight sharing is implemented in the LSTM layers of the access control branch, quantizing 32-bit floating-point parameters to 8-bit fixed-point numbers. Knowledge distillation is used in the reinforcement learning policy network of the data encryption branch to transfer the output probabilities of the complex policy network (teacher model) to a lightweight network (student model). The compressed model is tested on adversarial examples to verify its performance retention. For example, the pruned model's threat detection F1-score on the test set dropped from 0.92 to 0.89, meeting the minimum requirement of ≥0.85. Finally, a lightweight model file (e.g., model_v2.1.3_lite.weights) is generated, reducing the size to 40% of the original model.

[0192] Step S5015: Create a resource isolation sandbox in the local protection agent of the asset business node, and load the lightweight dynamic protection model into the resource isolation sandbox.

[0193] In an optional example, a resource-isolated sandbox can be implemented based on cgroups and namespace technologies, allocating dedicated CPU cores (such as cores 0-1), memory ranges (such as 512MB-1GB), and network bandwidth quotas (such as 50Mbps) to lightweight models. The sandbox file system is built using OverlayFS and contains lightweight model files, dependent libraries, and a minimized runtime environment. After the model is loaded, the process in the sandbox runs as a non-privileged user, with restricted system call permissions (such as disabling execve), and high-risk operations are intercepted through seccomp filters. The sandbox resource view is isolated from the host machine. For example, the number of CPU cores visible in the sandbox is 2, which is decoupled from the actual physical cores.

[0194] Step S5016: Execute the protection strategy of the lightweight dynamic protection model through the resource isolation sandbox, and collect resource usage fluctuation data and strategy stability indicators during the strategy execution process.

[0195] In an optional example, resource usage fluctuation data includes the CPU core utilization (e.g., 75% core 0 utilization), memory page fault rate (e.g., 200 per second), and network packet processing rate (e.g., 8000 pps) of the sandboxed process. Policy stability indicators are calculated using control charts. For example, the moving range (MR) of the number of false intercepts per hour is calculated. When three consecutive points exceed the 2σ control limit, the process is considered unstable. Data collection utilizes eBPF probe technology, capturing system calls and resource events of the sandboxed process in real time in kernel mode, avoiding the performance overhead of user-mode collection. For example, the bpftrace script tracks the number of mmap / munmap calls made by memory allocators (e.g., jemalloc).

[0196] Step S5017: If the resource usage fluctuation data exceeds the preset safety threshold of the resource isolation sandbox, a resource expansion request is triggered to dynamically allocate additional resources to the resource isolation sandbox.

[0197] In an optional example, safety thresholds can be set based on resource type, such as 90% for CPU core utilization, 95% for memory usage, and 85% for network bandwidth. If the CPU usage of a sandboxed process exceeds 90% for 10 seconds, the resource scheduler dynamically increases the CPU core quota (for example, from 2 to 3 cores) through an API call, with this increase taking effect in real time through cgroups. Capacity expansion follows the principle of minimum increments, for example, increasing by 0.5 cores at a time (implemented through the CPU share ratio) until resource usage returns to the safe zone. Historical capacity expansion records form a resilient policy library, for example, if an edge node requires a stable allocation of 3.5 CPU cores during peak business hours.

[0198] Step S5018: Adjust the parameter compression ratio of the lightweight dynamic protection model according to the policy stability index, generate a resource-adaptive final protection model, and close the resource isolation sandbox to release redundant resources.

[0199] In an optional example, the parameter compression ratio can be dynamically adjusted using a PID controller. For example, when a policy stability metric (such as the variance of the false intercept rate) exceeds a threshold, the compression constraint is gradually relaxed (for example, allowing the LSTM hidden layer dimension to recover from 128 to 192), while simultaneously monitoring resource consumption to see if it exceeds the expansion capacity. The final model version selects the configuration that meets stability requirements and minimizes resource usage, such as a combination of 160 hidden layer dimensions, 8-bit quantization, and a 30% pruning rate. After the model is solidified, the sandbox process terminates gracefully, releasing occupied CPU cores and memory resources, and log files are archived to the audit database. The final protection model is deployed to all asset business nodes through the official release process, completing the resource adaptation closed loop.

[0200] Figure 2 A schematic diagram of the hardware entity of a network security protection system provided by an embodiment of the present invention is shown as follows: Figure 2 As shown, the hardware entity of the network security protection system 1000 includes: a processor 1001 and a memory 1002, wherein the memory 1002 stores a computer program that can be run on the processor 1001, and when the processor 1001 executes the program, the steps in the method of any of the above embodiments are implemented.

[0201] The above description is only an embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with this technical field can easily think of changes or replacements within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A network security protection method applied to regional digital asset business, characterized in that: The method comprises: Collect asset data streams from multiple asset business nodes within the target area, including business operation behavior characteristics, data interaction characteristics, and asset attribute characteristics; Based on a preset threat knowledge graph, threat features are extracted from the asset data stream to generate a dynamic threat feature vector corresponding to the asset business node; Invoking a feature distribution layer in a dynamic protection model to split the dynamic threat feature vector into multiple sub-feature segments according to threat dimensions; Inputting each of the sub-feature fragments into a corresponding decision branch network, wherein the decision branch network includes a traffic blocking branch, an access control branch, and a data encryption branch; Performing in-depth protocol analysis on abnormal traffic features through the traffic blocking branch to generate traffic filtering rules and blocking thresholds; Dynamically verifying user authority characteristics through the access control branch and generating an access control list based on the session token; The encryption algorithm is matched to the sensitive data features through the data encryption branch to generate a key rotation strategy and encryption strength parameters; Aggregating the output rules of each of the decision-making branch networks to generate a real-time protection strategy set including priority weights; Sorting the execution order of the traffic filtering rules, access control lists and key rotation strategies according to the priority weights in the real-time protection strategy set; Injecting a policy execution agent into the network interface layer of the asset business node, the policy execution agent sequentially performs traffic filtering, permission verification and data encryption operations according to the execution order; Monitor the execution status of the policy execution agent in real time, and capture network traffic change characteristics and security event logs during the policy implementation period; Extracting the policy response delay, threat interception success rate, and resource occupancy rate from the network traffic change characteristics to generate policy effectiveness indicators; Correlation analysis is performed on the security event log and the policy effectiveness indicator to generate a policy execution result including a policy correction suggestion; Analyze the strategy correction suggestions in the strategy execution results, and extract the decision branch network identifiers and parameter adjustment directions that need to be optimized; For the traffic blocking branch, adjusting the traffic detection window size according to the policy response delay, and updating the blocking threshold determination logic according to the threat interception success rate; For the access control branch, dynamically adjust the verification frequency of the session token based on the resource occupancy rate, and optimize the matching algorithm of the access control list; For the data encryption branch, reselect a target algorithm from the encryption algorithm library based on a balance between encryption strength parameters and data processing delay; The parameters of the optimized decision branch networks are synchronized to generate an updated dynamic protection model with version iteration, and the update log is written into the model version library.

2. The method according to claim 1, characterized in that The asset data streams of multiple asset business nodes within the target area are collected, including: Obtaining business level classification information of the asset business node, the business level classification information including core asset nodes, edge asset nodes, and transit asset nodes; According to the business level classification information, a first collection frequency for core asset nodes, a second collection frequency for edge asset nodes, and a third collection frequency for transit asset nodes are set respectively, wherein the first collection frequency is greater than the second collection frequency, and the second collection frequency is greater than the third collection frequency; For each asset business node, capture the original data packets in its network transmission protocol according to the corresponding collection frequency, and perform protocol analysis on the original data packets to extract the business operation behavior characteristics, data interaction characteristics and asset attribute characteristics; Performing spatiotemporal alignment on the feature data of multiple asset business nodes collected within the same time window to generate a set of asset data streams with consistent timestamps; Noise filtering and outlier removal are performed on the asset data stream set to generate a standardized asset data stream.

3. The method according to claim 2, characterized in that The extracting threat features of the asset data stream based on the preset threat knowledge graph to generate a dynamic threat feature vector corresponding to the asset business node includes: Loading a node relationship topology in the threat knowledge graph, wherein the node relationship topology includes known attack pattern nodes, vulnerability exploitation path nodes, and threat behavior pattern nodes; Performing pattern matching on the business operation behavior characteristics in the asset data stream and the threat behavior pattern nodes to identify potential threat operation sequences; Calculating the vulnerability exposure probability of each asset business node based on the correlation between the data interaction feature and the vulnerability exploitation path node; Combining the mapping relationship between the asset attribute characteristics and the attack mode nodes, generating attack surface assessment parameters for the asset business node; The potential threat operation sequence, vulnerability exposure probability and attack surface assessment parameters are vectorized and spliced ​​to generate a dynamic threat feature vector containing multi-dimensional threat dimensions.

4. The method according to claim 1, wherein The pre-training process of the dynamic protection model includes the following steps: Constructing a training data set of historical asset service nodes, wherein the training data set includes normal service traffic samples, known attack traffic samples, and mixed traffic samples; Performing feature enhancement processing on the training data set to generate an enhanced data set containing spatiotemporal disturbance features; Initializing the network weights of the dynamic protection model and setting a multi-task learning objective function, wherein the multi-task learning objective function includes a threat classification loss, a strategy generation loss, and a resource consumption loss; A phased training strategy is adopted, where the parameters of the decision branch network are first frozen and the feature distribution layer is trained, and then the decision branch network is unfrozen for end-to-end joint training; The final model parameters are determined through the early stopping mechanism and cross-validation to generate a pre-trained dynamic protection model.

5. The method according to claim 4, characterized in that The performing feature enhancement processing on the training data set to generate an enhanced data set containing spatiotemporal disturbance features includes: Adding random time offsets to the normal business traffic samples to simulate traffic fluctuations during different business peak periods; Inserting noise data packets into the known attack traffic sample to generate an adversarial sample with obfuscation characteristics; Performing protocol field mutation on the mixed traffic sample to generate a protocol compatibility test sample; Combining the normal samples, adversarial samples and protocol variation samples after the time shift to generate the enhanced data set; A multi-dimensional threat label and a recommended protection strategy label are labeled for each sample in the enhanced dataset.

6. The method according to claim 1, characterized in that The method also includes a process of performing dual-channel verification during policy execution, including: While the local protection agent of the asset business node executes the real-time protection policy, it sends a policy verification request to the cloud verification server; The cloud verification server performs compliance verification on the real-time protection policy based on the global threat intelligence library and generates a policy modification instruction; If the local protection agent detects an execution result that conflicts with the policy modification instruction, it triggers a protection policy rollback mechanism and loads the previous version of the dynamic protection model; When the verification results of the local protection agent and the cloud verification server are consistent, the local policy cache is updated and the current protection policy is confirmed to be valid; The triggering of the protection policy rollback mechanism and loading of the previous version of the dynamic protection model include: Retrieving a historical model version compatible with the current asset business node from the model version library; Comparing the compatibility of the decision parameters of the historical model version with the current environment characteristics, and selecting the optimal rollback version; Pause the current policy execution process and switch the network weights of the dynamic protection model to the parameters of the optimal rollback version; Reinitialize the policy execution agent and generate an alternative protection policy based on the rolled-back model parameters; After the alternative protection strategy takes effect, a rollback completion notification is sent to the cloud verification server, and a model difference analysis task is started to locate the cause of the original strategy conflict.

7. A network security protection system comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor executes the program, the steps in the method according to any one of claims 1 to 6 are implemented.

Images