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

Abstract

The invention provides a network security protection method and system applied to regional digital and intelligent asset businesses, and the method comprises the steps: collecting asset data flows of a plurality of asset business nodes in a target region, carrying out the threat feature extraction of the asset data flows based on a preset threat knowledge graph, and obtaining a threat feature extraction result; generating a dynamic threat feature vector corresponding to the asset service node; inputting the dynamic threat feature vector into a pre-trained dynamic protection model, and outputting a real-time protection strategy adaptive to the asset service node through a multi-layer decision network in the dynamic protection model; performing strategy execution on the network flow of the asset service node based on the real-time protection strategy, generating a strategy execution result and feeding back the strategy execution result to the dynamic protection model; and performing adaptive optimization on decision parameters of the dynamic protection model according to a strategy execution result, and generating an updated dynamic protection model for a protection decision of a next round of asset business nodes.

Description

Technical Field

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

[0002] With the acceleration of the regional digital intelligence process, the key asset service nodes in fields such as finance, energy, and government affairs (such as intelligent terminals, cloud servers, and edge computing devices) have gradually become the core targets of network attacks. These nodes carry highly sensitive service data (such as real-time transaction information and user privacy data), and once attacked, it may lead to service interruption, data leakage, and even systemic risks. To cope with such threats, network security protection technologies are usually used to monitor network traffic of asset service nodes in real time and intercept threats. However, existing solutions have shown significant limitations in complex and changing business environments. In the prior art, the mainstream protection methods can be divided into two categories: Threat interception based on a static rule library: Pattern matching is performed on network traffic through predefined malicious IP blacklists, protocol feature libraries, or attack behavior signature libraries. For example, when it is detected that the protocol field of a data packet matches a known attack feature (such as a specific port scanning behavior), the traffic blocking rule is directly triggered. Anomaly detection based on a single-dimensional machine learning model: Classification models are trained using isolated features (such as traffic rate and connection frequency) to identify network behaviors that deviate from the normal baseline. For example, by statistically analyzing the time distribution law of historical traffic, sudden high-frequency requests are determined as DDoS attacks and a speed limit policy is generated.

[0003] The above methods have the following technical defects: First, the threat detection dimensions are fragmented, making it difficult to capture composite attacks. Traditional solutions only focus on isolated features at the network layer or transport layer, while ignoring the relevance between the business operation semantics, data interaction patterns, and asset attributes of asset service nodes. For example, an attacker can achieve covert data theft through a legal combination of low-risk interfaces, and traditional methods cannot identify such attacks due to the lack of business logic correlation analysis. Second, the policy generation is disconnected from the business resource status, resulting in a decline in protection effectiveness. The static rule library relies on manual updates and is difficult to adapt to the dynamic changes of asset service nodes; while the policies generated by single-dimensional models often conflict with real-time resource loads. Third, the protection model is rigid and cannot cope with the evolution of new threats. Existing solutions mostly use offline training models or fixed rule libraries and lack a dynamic optimization mechanism based on actual protection effects (such as false interception events and resource consumption indicators). For example, when a new Internet of Things device is connected to an asset service node, the original model may miss detecting tampering attacks on device control instructions because it has not learned new protocol features (such as MQTT protocol instructions).

[0004] The above-mentioned deficiencies have led to problems such as low detection accuracy, frequent policy conflicts, and lagging model iteration in the traditional protection solutions for the regional digital intelligence asset business scenarios. Therefore, there is an urgent need for a protection method that can accurately identify composite attacks, ensure business continuity, and continuously adapt to the complex and changeable threat environment. Summary of the Invention

[0005] In view of this, the embodiments of the present invention provide a network security protection method and system applied to the regional digital intelligence asset business. The technical solution of the embodiments of the present invention is realized as follows: On the one hand, the embodiments of the present invention provide a network security protection method applied to the regional digital intelligence asset business. The method includes: collecting the asset data streams of multiple asset business nodes in the target area, where the asset data streams include business operation behavior characteristics, data interaction characteristics, and asset attribute characteristics; based on a preset threat knowledge graph, extracting threat characteristics from the asset data streams to generate dynamic threat feature vectors corresponding to the asset business nodes; inputting the dynamic threat feature vectors into a pre-trained dynamic protection model, and outputting real-time protection policies adapted to the asset business nodes through a multi-layer decision network in the dynamic protection model; performing policy execution on the network traffic of the asset business nodes based on the real-time protection policies, 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 to generate an updated dynamic protection model for the next round of protection decisions of the asset business nodes.

[0006] On the other hand, the embodiments of the present invention provide a network security protection system, including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor implements the steps in the above method when executing the program.

[0007] The network security protection method for regional digital intelligence asset business provided by the present invention collects multi-dimensional asset data streams of asset business nodes in real time, combines the context association ability of the threat knowledge graph, and dynamically generates threat feature vectors reflecting the risks of the current business scenario; based on the branching processing of threat features by a multi-layer decision network, a set of real-time protection strategies adapted to the resource status and threat level of business nodes is generated, and the model parameters are optimized through the execution feedback closed-loop, forming a dynamic protection ability adaptable to the complex environment of regional business. Specifically, by integrating business operation behavior features, data interaction features, and asset attribute features, it is possible to depict the complete attack surface of asset business nodes from multiple dimensions of business logic, interaction mode, and asset attributes, solve the problem of incomplete threat coverage caused by traditional methods relying on single network traffic features, and thus significantly improve the detection accuracy of advanced persistent threats and internal abuse behaviors. Based on the dynamic threat feature extraction mechanism of the threat knowledge graph, the abnormal behaviors in the real-time data stream are semantically associated with known attack patterns and vulnerability exploitation paths, generating dynamic threat feature vectors containing business scenario semantics, so that the threat features not only include protocol-level anomalies but also can reflect potential risks at the business logic level, thereby enhancing the context understanding ability of new attacks. Through the branching strategy generation mechanism of the multi-layer decision network, fine-grained protection strategies can be generated for different threat dimensions, and at the same time, the execution priority of the strategies is dynamically adjusted based on the real-time resource occupancy rate, solving the problems of protection delay or service interruption caused by policy conflicts or resource contention in traditional methods, and then achieving the balance between security protection and business continuity. Based on the closed-loop optimization mechanism of policy execution results, the policy effectiveness indicators are associated and analyzed with security event logs, driving the continuous iterative optimization of the dynamic protection model parameters, enabling the model to adapt to changes in the regional business environment and the evolution of new attack patterns, thus avoiding the problem of degradation of the protection ability of traditional static rule libraries or offline training models.

[0008] In summary, through the synergistic effect of multi-dimensional data fusion, threat feature generation driven by business semantics, resource-aware real-time policy decision-making, and closed-loop feedback optimization mechanism, the present invention significantly improves the accuracy, real-time performance, and environmental adaptability of network security protection in the regional digital intelligence asset business scenario, and is particularly suitable for the dynamic protection requirements of large-scale asset nodes in high-sensitivity business fields such as finance and energy. Brief Description of the Drawings

[0009] Figure 1 It is a schematic diagram of the implementation process of a network security protection method for regional digital intelligence asset business provided by an embodiment of the present invention.

[0010] Figure 2 It is a schematic diagram of the hardware entity of a network security protection system provided by an embodiment of the present invention. Detailed Implementation Modes

[0011] An embodiment of the present invention provides a network security protection method for regional digital intelligence asset services, which can be executed by a processor of a network security protection system. Among them, the network security protection system can refer to devices with data processing capabilities such as servers, laptops, tablets, desktop computers, mobile devices (such as mobile phones, portable video players, personal digital assistants, dedicated messaging devices, portable game devices), etc.

[0012] Figure 1 FIG. is a schematic diagram of the implementation process of a network security protection method for regional digital intelligence asset services provided by an embodiment of the present invention. As Figure 1 shown, the method includes: Step S100: Collect the asset data streams of multiple asset service nodes in the target area. The asset data streams include business operation behavior characteristics, data interaction characteristics, and asset attribute characteristics.

[0013] In an optional example, the target area refers to the geographical or logical network range where a digital intelligence asset management system is deployed. Its asset service nodes include but are not limited to core server clusters, edge computing devices, data transfer gateways, and terminal service interfaces. The asset data stream is a set of structured or unstructured data generated during the network transmission of each node. The collection process needs to cover the complete 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 authentications, file read / 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 depict the behavior baseline of the node. The data interaction characteristics include the protocol type of communication between nodes, the packet size distribution, the session duration, and the traffic burst mode, which are extracted from the transport layer metadata through deep packet inspection technology and reflect the dynamic characteristics of data exchange between nodes. The 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 node with an asset detection tool or passively listening to the node broadcast information. To achieve efficient collection, the system needs to dynamically adjust the data capture frequency according to the node type. For example, a millisecond-level sampling interval is used for the core server cluster, while a second-level interval is used for the edge computing device to ensure the integrity of critical business traffic. After all the feature data is aligned through a time window, a set of asset data streams containing unified timestamp marks is formed, and the noise data caused by network jitter or device anomalies is removed through an outlier detection algorithm. Finally, a standardized asset data stream is generated for subsequent processing.

[0014] Step S200: Based on a preset threat knowledge graph, extract threat characteristics from the asset data stream to generate a dynamic threat feature vector corresponding to the asset service node.

[0015] In an alternative example, the preset threat knowledge graph is a pre-constructed graph-structured database. Its node entities include known attack pattern nodes, vulnerability exploitation path nodes, and threat behavior pattern nodes. The edge relationships represent the logical associations and evolution paths among attack techniques. The attack pattern nodes store the characteristics of typical attack chains, such as the traffic pulse pattern of a distributed denial-of-service attack (DDoS) and the lateral movement strategy of an advanced persistent threat (APT). The vulnerability exploitation path nodes record the exploitable defects existing in specific device firmware or software versions and their penetration paths. The threat behavior pattern nodes define the spatio-temporal characteristics of abnormal operation sequences, such as the high-frequency data export behavior during non-working hours. In the threat feature extraction stage, the business operation behavior features are pattern-matched with the threat behavior pattern nodes to identify potential threat operation sequences containing unconventional command sequences or privilege escalation operations. For example, a high-risk mark is generated when an unauthorized database bulk export operation is detected. The data interaction features can be associated with the vulnerability exploitation path nodes through a graph traversal algorithm to calculate the vulnerability exposure probability of the nodes under the current network topology. For example, when an edge device communicates using an unencrypted Modbus protocol, its exposure probability is significantly increased due to the vulnerability of the protocol. The asset attribute features are mapped and matched with the 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. After the above three types of outputs are normalized, they are vectorized and spliced according to the threat dimension to form a dynamic threat feature vector with time series evolution characteristics. Its dimension space covers the operation anomaly index, the vulnerability risk level, and the attack surface exposure coefficient, realizing the digital representation of the multi-dimensional threat situation.

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

[0017] For example, the dynamic protection model is a multi-task learning architecture based on a deep neural network. Its multi-layer decision network includes a feature distribution layer and parallel traffic blocking branches, access control branches, and data encryption branches. The feature distribution layer decouples the dimensions of the dynamic threat feature vector, assigns the operation anomaly index to the traffic blocking branch, maps the vulnerability risk level to the access control branch, and directs the attack surface exposure coefficient to the data encryption branch. For example, the traffic blocking branch can use a convolutional neural network to deeply analyze the protocol of abnormal traffic features, identify hidden attack payloads in the transport layer payload, such as detecting an SQL injection attack disguised as a legitimate HTTP request based on protocol field offsets, and generate a traffic filtering rule set including source IP blacklists, traffic shaping thresholds, and protocol filtering rules. The access control branch dynamically verifies user permission features through a recurrent neural network, combines the life cycle of the session token with the access context, and generates an access control list based on the principle of least privilege, such as restricting a temporary account to only access specified API endpoints during a specific time period. The data encryption branch uses a reinforcement learning algorithm to match sensitive data features with an encryption algorithm library, selects encryption strength parameters according to the data processing latency tolerance, such as using the AES-128-GCM algorithm for real-time video streams to balance security and transmission efficiency, and simultaneously generates a key distribution strategy that rotates hourly. After the outputs of each branch are analyzed by the rule interaction relationship diagram, the execution priority is dynamically adjusted according to the resource occupancy rate, and finally aggregated into a set of real-time protection policies including weighted execution sequences to ensure that the policies of high-threat level nodes are executed first.

[0018] Step S400: Execute the policy on the network traffic of the asset business node based on the real-time protection policy, generate a policy execution result, and feedback it to the dynamic protection model.

[0019] In an alternative example, during the policy execution process, a lightweight proxy module is injected at the network interface layer. This proxy module parses the rule priorities in the real-time protection policy set, and implements protection actions in sequence according to the weight sorting. 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 simultaneously records the hash fingerprints of the intercepted packets for auditing. The access control list inserts dynamic permission verification logic during the session token verification phase by rewriting the policy engine of the identity authentication microservice. For example, when a privilege escalation access attempt is detected, the session is forcibly terminated and a security alert is generated. The key rotation policy is integrated into the password management middleware, triggers a key update event within a preset time window, and adopts a double-buffer mechanism to avoid interruption of the encryption service. During the period when the policy is in effect, the system captures the real-time change characteristics of network traffic, including the decline rate of the number of requests per second, the number of abnormal session terminations, and the encryption algorithm switching delay, and simultaneously collects the attack type tags and handling status in the security event log. The policy effectiveness indicator is obtained by calculating the weighted harmonic mean of the policy response delay and the threat interception success rate. For example, when the traffic filtering rule intercepts 90% of malicious requests within 50 milliseconds, its effectiveness level is determined to be optimal. The finally generated policy execution result includes rule hit statistics, resource consumption distribution, and correction suggestion tags, and is fed back to the parameter optimization module of the dynamic protection model through an asynchronous message queue.

[0020] 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 decisions for asset business nodes.

[0021] In an alternative example, the adaptive optimization process may adopt an incremental learning mechanism. For example, first parse the correction suggestion tags in the policy execution result to locate the decision branch network to be optimized. For the traffic blocking branch, adjust the time span of the protocol parsing window according to the policy response delay. For example, shorten the initial 200-millisecond window to 150 milliseconds to reduce the detection delay, and at the same time update the determination logic of the blocking threshold based on the threat interception success rate. For example, dynamically adjust the abnormal traffic ratio threshold from 5% to 3%. The access control branch optimizes the session token verification frequency based on the resource occupancy rate. For example, when the CPU usage rate exceeds 70%, change the real-time permission verification to an asynchronous batch processing mode, and reconstruct the matching algorithm of the access control list, using a Bloom filter instead of full traversal to improve efficiency. The data encryption branch reselects the algorithm library according to the balance curve of the encryption strength parameter and the processing delay. For example, in the scenario where the edge node resources are limited, replace the SHA-256 digest algorithm with SHA3-224 to reduce the computing overhead. After the optimized branch parameters are synchronized by gradients, an updated model for version iteration is generated, and its stability is verified through a shadow deployment environment: inject historical attack samples and new attack variants into the simulated business nodes, and monitor whether the false interception rate and the missed detection rate are lower than the preset thresholds. The model that passes the verification is marked as a stable version, replaces the online model through the hot deployment mechanism, and at the same time retains the historical version snapshot to support emergency rollback, finally forming a closed-loop self-evolving protection system.

[0022] As an implementation manner, step S100, collecting the asset data streams of multiple asset business nodes in the target area, may include: Step S110: Obtain the business-level classification information of the asset business node, where the business-level classification information includes a core asset node, an edge asset node, and a transit asset node.

[0023] In an optional example, the business-level classification information is a node type identification system divided based on the network topology structure and business criticality, and is used to guide the formulation of differentiated data collection strategies. Core asset nodes refer to infrastructure entities that carry core business logic or store sensitive data, such as the main server cluster where the key database is deployed, the application service nodes that process financial transactions, and the cloud storage nodes that store user privacy information. The interruption of their services will cause regional-level service paralysis. Edge asset nodes refer to terminal devices located at the network edge and undertaking lightweight computing tasks, such as industrial Internet of Things sensors, intelligent terminal gateways, and mobile access devices. Their functions are concentrated on data collection and preliminary processing. Transit asset nodes refer to intermediate devices that undertake data forwarding or protocol conversion in the network path, such as load balancers, VPN gateways, and protocol conversion proxy servers. Their core role is to maintain network connectivity and data transmission efficiency. The acquisition of business-level classification information is achieved by parsing network architecture design documents, asset registration databases, and dynamic topology scan results. For example, the service ports and running status of devices are actively queried through the SNMP protocol, and the node types are automatically marked in combination with the business dependency relationship graph.

[0024] Step S120: According to the business-level classification information, set the first collection frequency for core asset nodes, the second collection frequency for edge asset nodes, and the third collection frequency for transit asset nodes respectively, where the first collection frequency is greater than the second collection frequency, and the second collection frequency is greater than the third collection frequency.

[0025] In an optional example, the differential configuration of the collection frequency is dynamically set according to the node business importance and data timeliness requirements. The first collection frequency uses a millisecond-level data sampling interval for core asset nodes. For example, all packets of the network interface are captured every 50 milliseconds to ensure real-time monitoring of fine-grained operation characteristics in high-frequency trading or high-concurrency access scenarios. The second collection frequency for edge asset nodes is set to a second-level interval. For example, lightweight telemetry data uploaded by sensors is collected every 2 seconds to balance resource consumption and data integrity requirements. The third collection frequency for transit asset nodes is set to a minute-level interval. For example, a traffic statistics summary is captured every 5 minutes, focusing on monitoring bandwidth utilization and connection stability indicators. The frequency parameters are dynamically sent to the data collection agent through the configuration management interface and support elastic adjustment based on the node load status. For example, when the CPU usage rate of the core node exceeds 80%, the first collection frequency is temporarily relaxed from 50 milliseconds to 100 milliseconds to reduce the performance impact. A strict gradient relationship of core > edge > transit is followed among the frequency parameters to ensure the collection priority of key business data.

[0026] 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 parsing on the original data packets to extract business operation behavior features, data interaction features, and asset attribute features.

[0027] In an optional example, the capture of the original data packets is implemented through mirror port or bypass packet capture technology, and the capture action is triggered according to the preset collection frequency. For example, for the core asset node, the complete payload data of the TCP / IP protocol stack is captured at intervals of 50 milliseconds, including the Ethernet frame header, IP packet header, and application layer protocol content. The protocol parsing process uses a deep packet parsing engine to strip the protocol headers layer by layer and extract structured features: the 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; the data interaction features are extracted from the transport layer and network layer headers, including the source / destination IP and port combination, the change trend of the TCP window size, and the distribution of ICMP message types; the asset attribute features are obtained by parsing device fingerprint information, such as the MAC address vendor code, the organization identifier in the TLS certificate, and the SSH service version number. The parsed feature data is encapsulated in JSON format and appended with the collection timestamp and node type label to form the original feature record set.

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

[0029] In an optional example, the time window is defined as a fixed-duration interval synchronized with the system clock. For example, with a window length of 1 second, to ensure the time correlation of cross-node data. The space-time alignment process first calibrates the system clocks of each node's collection agent through the NTP protocol to uniformly convert the timestamps of the feature records into the standard time coordinate system. For cross-window data caused by network latency, a sliding window mechanism is used for dynamic attribution adjustment. For example, the data packets sent by a certain edge node 10 milliseconds before the end of the window are classified into the current window instead of the next window. The aligned data is sorted according to the millisecond-level timestamp, and the feature values of the missing time points are filled with null or default values. For example, when a certain transit node has no data transmission during a certain collection period, mark its data interaction feature as "silent state". The finally generated set of asset data streams is a multi-dimensional time series matrix, whose row dimension represents the timestamp, and the column dimension covers all node feature types, ensuring the time series consistency for subsequent analysis.

[0030] Step S150: Filter out noise and remove outliers from the set of asset data streams to generate a standardized set of asset data streams.

[0031] In an alternative example, noise filtering can adopt a dual mechanism based on a rule engine and a statistical model. The rule engine defines protocol compliance check policies, such as discarding malformed request packets that do not conform to the HTTP / 1.1 specification and filtering out illegal source address data in ICMP redirect messages. The statistical model identifies outliers by calculating the Z-score distribution of feature values. For example, when the TCP window size of a certain core node suddenly increases to more than 3 standard deviations above the historical average, it is determined as an anomaly caused by network congestion and is excluded. For missing value processing, linear interpolation or forward filling methods are used to complete continuous features. For example, the port usage rate of the previous time series point is used to fill the current missing value. The data normalization process maps heterogeneous features to a unified dimension. For example, the port number is converted into a normalized value in the range of 0-1, and the packet size is compressed in distribution range by logarithmic transformation. The processed set of asset data streams meets the requirements of unified format, no redundant noise, and coherent time series, and is input into the downstream threat analysis module.

[0032] As an implementation manner, in step S200, 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, which may include: Step S210: Load the node relationship topology in the threat knowledge graph. The node relationship topology includes known attack pattern nodes, vulnerability exploitation path nodes, and threat behavior pattern nodes.

[0033] The node relationship topology of the threat knowledge graph is a pre-constructed graph structure data model, and its node entities and edge relationships are generated through attack chain analysis, vulnerability database association, and behavior pattern mining in the field of network security. The known attack pattern nodes store the feature fingerprints of typical attack techniques, such as the traffic pulse pattern of distributed denial of service attack (DDoS), the email payload characteristics of spear phishing attack, and the file encryption behavior sequence of ransomware. Each node contains attributes such as attack stage division, dependent resources, and historical impact scope. The vulnerability exploitation path nodes record the defect exploitation methods corresponding to the common vulnerability disclosure (CVE) numbers, such as the log injection path of CVE-2021-44228 vulnerability, the privilege escalation chain of CVE-2020-1472 vulnerability, and the unauthorized access interface of specific Internet of Things device firmware. The possibility of serial exploitation of vulnerabilities is represented by directed edges between nodes. The threat behavior pattern nodes define the spatio-temporal characteristics of abnormal operation sequences, such as high-frequency data export operations during non-working hours, unauthorized port scanning behaviors across security domains, and repeated communication attempts with known malicious IP addresses. The node relationship topology is loaded into memory through a graph database, and a multi-hop association index between entities is established to provide a structured reasoning basis for subsequent threat feature extraction.

[0034] Step S220: Perform pattern matching between the business operation behavior characteristics in the asset data stream and the threat behavior pattern nodes to identify potential threat operation sequences.

[0035] The business operation behavior characteristics include the set of operation instructions triggered by the node user in the application layer protocol, such as the execution frequency of database query statements, the directory paths of file read and write operations, and the combination patterns of API call parameters. The pattern matching process can adopt a graph traversal algorithm based on temporal similarity to align and compare the feature sequence with the standard behavior template of the threat behavior pattern nodes. For example, when it is detected that a certain core asset node continuously initiates more than 500 database query operations of SELECT *FROM user_table within 10 minutes, the similarity threshold between this sequence and the "data bulk leakage probing behavior" template in the threat behavior pattern node reaches 85%, and it is marked as a high-risk potential threat operation sequence. The matching algorithm also considers the operation context environment. For example, when it is identified that an edge asset node periodically uploads encrypted compressed files to an external IP address through the FTP protocol, it is determined that it violates the data exfiltration policy in combination with the business role of this node, and a medium-risk threat operation sequence is generated. All matching results are sorted by confidence level and appended with the operation timestamp, protocol type, and associated vulnerability numbers to form a weighted threat operation record set.

[0036] Step S230: Calculate the vulnerability exposure probability of each asset business node according to the correlation degree between the data interaction characteristics and the vulnerability exploitation path nodes.

[0037] The data interaction characteristics cover the protocol type, session duration, packet payload distribution, and traffic burstiness metrics shown by the node during network communication. The correlation degree calculation can be achieved through graph embedding technology, mapping the data interaction characteristics into the vector space of the vulnerability exploitation path nodes and calculating the cosine similarity between the two. For example, a certain transit asset node continuously communicates with external devices using the unencrypted Modbus TCP protocol, and its protocol type is directly associated with the "industrial protocol unauthorized access vulnerability (CVE-2018-5407)" in the vulnerability exploitation path node. The part of the session duration that exceeds 2 standard deviations of the historical baseline value triggers the time dimension weight, and finally the vulnerability exposure probability of this node is calculated to be 0.92 (range 0 - 1). For a core asset node, if it is detected that it establishes a TLS connection with an old version of the OpenSSL server known to have the Heartbleed vulnerability (CVE-2014-0160), the vulnerability exposure probability is dynamically adjusted to 0.78 based on the version identification in the protocol handshake stage and the heartbeat packet sending frequency. The calculation results are normalized according to the node type and the historical mean is updated through a sliding window mechanism to ensure the timeliness of the probability value.

[0038] Step S240: Generate the attack surface evaluation parameters of the asset business node by combining the mapping relationship between the asset attribute characteristics and the attack pattern nodes.

[0039] In an optional example, the asset attribute characteristics include, for example, static configuration information such as device model, operating system version, open port list, and deployed patch status. The generation of the attack surface evaluation parameters is achieved through a multi-dimensional weighted scoring model. Among them, the compatibility score between the device model and the attack pattern node is calculated based on the vendor's vulnerability disclosure frequency. For example, since an industrial control device has 10 high-risk vulnerabilities in history, its model weight coefficient is set to 0.3. The open port list is associated with the service exposure score of the attack pattern node. For example, a server has opened ports such as 135, 139, and 445 that are known to be vulnerable to lateral movement attacks, and each high-risk port increases the exposure coefficient by 0.1. The patch status score is accumulated based on the CVSS score of the unpatched vulnerabilities. For example, if a node has 3 unpatched vulnerabilities with a CVSS score above 9.0, then 0.27 points are deducted in the patch dimension (0.09 points are deducted for each vulnerability). The final parameter is calibrated by linearly combining the scores of each dimension and introducing the node business level weight (the weight of the core node is 1.0, the edge node is 0.6, and the transit node is 0.3) to generate the attack surface evaluation parameter in the range of 0 to 10. The higher the value, the greater the attack risk faced by the node.

[0040] Step S250: Vectorize and splice the potential threat operation sequence, vulnerability exposure probability, and attack surface evaluation parameters to generate a dynamic threat feature vector containing multi-dimensional threat dimensions.

[0041] In an optional example, the vectorization process can adopt a strategy of dimension-by-dimension normalization and sequential splicing. The potential threat operation sequence is encoded as a binary vector, and each bit represents the matching status of a threat behavior pattern node (for example, the 5th bit being 1 indicates that a SQL injection probing behavior is detected), and the bit value is adjusted by confidence weighting. The vulnerability exposure probability is linearly scaled to a floating-point number with 8-bit precision in the range of 0 - 1. After the attack surface evaluation parameter is mapped to the range of 0 - 1 through Min-Max normalization, it is converted into a 16-bit fixed-point number format. The three types of data are spliced into a unified feature vector in the dimension order. For example, when the threat knowledge graph contains 200 threat behavior pattern nodes, the first 200 dimensions of the vector are the operation sequence encoding, the subsequent 1 dimension is the vulnerability exposure probability, and the last 1 dimension is the attack surface evaluation parameter. To enhance the temporal correlation, a time decay factor is added to the vector. For example, the weight of the threat operation sequence in the current time window is 1.0, and the weight of the previous time window is reduced to 0.8, forming a dynamic threat feature vector with the characteristics of a time sliding window. This vector is used as the standard input format for the downstream dynamic protection model for real-time decision-making analysis.

[0042] As an implementation manner, in step S300, the dynamic threat feature vector is input into a pre-trained dynamic protection model, and a real-time protection policy adapted to the asset business node is output through a multi-layer decision network in the dynamic protection model, which may specifically include: Step S310: Invoke the feature distribution layer in the dynamic protection model to split the dynamic threat feature vector into multiple sub-feature segments according to threat dimensions.

[0043] In an optional example, the feature distribution layer is a pre-processing module of the dynamic protection model, and its core function is to perform dimension decoupling and directional allocation based on the multi-dimensional structure of the dynamic threat feature vector. The dynamic threat feature vector includes threat indicators in multiple dimensions such as the threat behavior sequence encoding generated by step S250, the vulnerability exposure probability value, and the attack surface evaluation parameter. The feature distribution layer splits the sub-fields related to protocol anomalies in the threat behavior sequence encoding (such as the HTTP request method anomaly flag, the TCP flag bit anomaly combination) into traffic blocking sub-feature segments through a preset dimension mapping rule, splits the user privilege overstep operation identifier and the session token verification status into access control sub-feature segments, and splits the encryption algorithm identifier and the key life cycle parameter into data encryption sub-feature segments. For example, when the dynamic threat feature vector contains a binary sequence bit indicating an SQL injection attempt, this sequence bit and its associated protocol type identifier (such as HTTP / 1.1) are completely extracted and encapsulated as a traffic blocking sub-feature segment to ensure that the subsequent decision branch network can focus on in-depth analysis of specific threat dimensions.

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

[0045] In an alternative example, the decision branch network is a dedicated neural network structure deployed in parallel in the dynamic protection model. Each branch performs directional processing based on the threat dimension type of the sub-feature segments. After receiving the traffic blocking sub-feature segments, the traffic blocking branch can activate a protocol parsing engine based on a convolutional neural network to perform cross-layer correlation analysis on protocol fields from the network layer to the application layer. For example, it can analyze the collaborative anomaly between the abnormal mutation pattern of the User-Agent field in the HTTP header and 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 of user-resource-operation. For example, it can perform real-time association reasoning on the role identifier in the session token and the API endpoint access record. The data encryption branch can process the data encryption sub-feature segments through a reinforcement learning algorithm and match an algorithm combination that meets the current business scenario in the encryption algorithm library. For example, it can select ChaCha20-Poly1305 instead of AES-GCM according to the computing power of the edge node to reduce the CPU load. The input and output interfaces of each branch network are seamlessly docked through a standardized data format to ensure the efficient flow and processing of sub-feature segments.

[0046] Step S330: Deeply parse the protocol of the abnormal traffic characteristics through the traffic blocking branch to generate traffic filtering rules and blocking thresholds.

[0047] In an alternative example, the deep protocol parsing process can adopt a multi-level feature extraction strategy to separate protocol header fields (such as IP fragmentation offset, HTTP content type identifier) from the traffic blocking sub-feature segments, and then model the temporal dependence relationship between protocol fields through a bidirectional long short-term memory network (Bi-LSTM). For example, when it is detected that consecutive URL parameters containing the ".. / " path traversal feature appear in the HTTP requests of a certain core asset node, the protocol parsing engine will associate its co-occurrence pattern with the abnormal jump of the TCP sequence number and determine it as a directory traversal attack attempt. On this basis, the traffic blocking branch generates traffic filtering rules containing five-tuple filtering conditions (source IP address, destination port number, protocol type) and sets a dynamic blocking threshold based on the traffic peak distribution of historical attack samples. For example, when the number of abnormal requests per unit time exceeds 500 times per second, full-port blocking is triggered. The generated rule set is appended with protocol compliance verification tags and an effective time window to ensure compatibility with existing firewall policies.

[0048] Step S340: Dynamically verify the user permission characteristics through the access control branch to generate an access control list based on the session token.

[0049] In an alternative example, the dynamic verification mechanism can be implemented based on the 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 segment, and constructs a dynamic permission relationship graph through a graph neural network. For example, when it is detected that a temporary account attempts to access the sensitive table structure of the core database during non-working hours, the branch network will associate the session token issuance time of the account (such as only taking effect during working hours) with the historical access records (such as only allowing SELECT operations), and generate a fine-grained access control entry including "deny DDL statement execution". The generated access control list adopts an attribute-based encryption (ABE) policy, dynamically binding the metadata of the session token (such as device fingerprint, geographical location) to the resource access permission. For example, only sessions initiated from the internal network IP segment are allowed to access the financial system API. The list entries are sorted by risk level, and high-risk entries are preferentially loaded into the policy enforcement agent.

[0050] Step S340: Dynamically verify the user permission characteristics through the access control branch, and generate an access control list based on the session token.

[0051] In an alternative example, the dynamic verification mechanism is implemented based on the 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 segment, and constructs a dynamic permission relationship graph through a graph neural network. For example, when it is detected that a temporary account attempts to access the sensitive table structure of the core database during non-working hours, the branch network will associate the session token issuance time of the account (such as only taking effect during working hours) with the historical access records (such as only allowing SELECT operations), and generate a fine-grained access control entry including "deny DDL statement execution". The generated access control list adopts an attribute-based encryption (ABE) policy, dynamically binding the metadata of the session token (such as device fingerprint, geographical location) to the resource access permission. For example, only sessions initiated from the internal network IP segment are allowed to access the financial system API. The list entries are sorted by risk level, and high-risk entries are preferentially loaded into the policy enforcement agent.

[0052] Step S350: Match the encryption algorithm for the sensitive data characteristics through the data encryption branch, and generate a key rotation policy and encryption strength parameters.

[0053] In an alternative example, the encryption algorithm matching process comprehensively considers data type sensitivity, processing latency constraints, and node computing capabilities. The data encryption branch parses sensitive data features from the data encryption sub-feature segments, such as the field structure of financial transaction records, and selects the optimal algorithm combination from a predefined encryption algorithm library through a reinforcement learning agent. For example, for high-throughput video stream transmission scenarios, the AES-128-CTR mode is selected to balance encryption speed and security; for patient privacy data stored on edge nodes, the AES-256-XTS mode is selected to provide full-disk encryption protection. The key rotation policy is triggered based on two factors: the number of key uses and time. For example, the session key is automatically rotated every 1 GB of encrypted data or every 24 hours, and seamless updates are achieved through a Key Distribution Center (KDC). The encryption strength parameter is dynamically adjusted according to the node resource status. For example, when the CPU usage exceeds 70%, the encryption mode is switched from CBC to the lighter ECB mode to reduce the computational overhead.

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

[0055] In an alternative example, the rule aggregation process can adopt 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 policies formulated by the data encryption branch are first converted into a unified policy description language (such as JSON format), and then their execution dependencies and resource competition relationships are analyzed through a rule interaction relationship graph. For example, when the traffic blocking rule requires intercepting all connections to a certain IP address, while there is an exception allowing entry for this IP address in the access control list, the policy aggregation engine will assign a higher priority to the traffic blocking rule based on the threat confidence level (such as the vulnerability exposure probability associated with the interception rule is 0.95). The priority weights are dynamically adjusted according to the real-time resource occupancy rate of each branch network. For example, when the memory usage exceeds the threshold, the execution priority of the data encryption policy is reduced to avoid the risk of OOM (Out of Memory). The finally generated set of real-time protection policies includes an execution sequence with weight tags, rollback conditions, and monitoring metric collection rules. For example, traffic filtering for high-risk ports is preferentially executed, followed by role-based access control, and finally the key rotation operation is triggered to form a hierarchical protection system.

[0056] As an implementation, step S360, aggregating the output rules of each decision branch network to generate a set of real-time protection policies including priority weights, includes: Step S361: Extract the protocol parsing results in the traffic filtering rules generated by the traffic blocking branch, identify the protocol types and traffic directions corresponding to the abnormal traffic features in the protocol parsing results, and generate protocol type identifiers and traffic direction identifiers.

[0057] In an optional example, the protocol parsing result is the structured analysis data output after the traffic blocking branch performs deep packet inspection on network data packets, including the field decoding information of protocols from the transport layer to the application layer. The abnormal traffic feature refers to the protocol field combination pattern that significantly deviates from the normal service traffic baseline. For example, the undefined method type continuously appears in the HTTP request header (such as "G3T" instead of "GET"), or the abnormal combination of TCP flag bits (such as SYN and FIN being set simultaneously). The protocol type identifier is standardized and encoded according to the protocol numbers 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 security domains within the node is marked as "LATERAL direction identifier (0x02)". The identifier generation process is implemented through a protocol fingerprint library and a traffic direction decision tree to ensure the accurate mapping of abnormal traffic features and identifiers.

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

[0059] In an optional example, the session token verification result is the permission status data output after the access control branch dynamically authenticates the user identity credentials. For example, it includes the token issuing authority, validity period, role claim, and resource access claim. The user permission level identifier is generated based on the hierarchical structure in the role claim. 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 according to the accessible API endpoints, database tables, or file paths declared in the token. For example, the allowed finance system API group is marked as " / api / v1 / finance resource scope identifier (R001)", and the customer information table in the core database is marked as "db.customer_info resource scope identifier (R005)". The identifier generation process combines the resource naming specification and the principle of least privilege. For example, by using regular expressions to match the resource path pattern in the claim and converting it into a unique identifier in the form of a hash value.

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

[0061] In an optional example, the encryption algorithm identifier is encoded according to the naming rules of the NIST standard cipher suite. For example, the AES-256-GCM algorithm is marked as "AES256GCM Algorithm Identifier (0xA1)", and the ChaCha20-Poly1305 algorithm is marked as "CHACHA20POLY1305 Algorithm Identifier (0xB3)". The encryption strength parameter is calculated by quantifying the key length, the algorithm's anti-attack ability, and the performance overhead. For example, the strength parameter of AES-256-GCM is 9.8 (in the range of 0-10), while that of AES-128-CBC is 8.5. The data type of the sensitive data feature is defined according to the data classification strategy. For example, personal identity information (PII) is marked as "PII Data Type Identifier (D01)", and medical and health information (PHI) is marked as "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 encrypting PHI data using AES-256-GCM, the "D02-A1 Encryption Association Identifier" is generated to ensure an exact match between the encryption policy and the data sensitivity.

[0062] Step S364: Construct a rule interaction relationship graph 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 graph represent the rule execution conditions corresponding to each identifier, and the edges represent the dependency or conflict relationship between different rules.

[0063] In an optional example, the rule interaction relationship graph is, for example, a directed weighted graph structure. The nodes are composed of the combined conditions of the five types of identifiers. For example, "HTTP / 1.1 Protocol Type Identifier (80) + INBOUND Direction Identifier (0x01)" represents a 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 certain rule can be executed only after another rule takes effect. For example, "Enable data encryption first (D02-A1 Encryption Association Identifier) and then allow access to PHI data (R005 Resource Scope Identifier)" generates a positive dependency edge; the conflict edge indicates that there are mutually exclusive conditions between rules. For example, "Block all inbound traffic (Protocol Type Identifier 80 + Direction Identifier 0x01)" and "Allow administrators to access the inbound API (ADMIN Permission Level Identifier L3 + Resource Scope Identifier R001)" generate a conflict edge due to overlapping conditions. The edge weight is obtained by statistically analyzing the 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.

[0064] Step S365: Traverse the rule interaction relationship graph, detect node groups with dependency relationships and node groups with conflict relationships, and assign initial priority weights to each node group based on the connection density of the node group and the historical policy execution success rate.

[0065] In an optional example, graph traversal can use depth-first search and backtracking algorithms to identify node groups that meet the dependency or conflict conditions. The connection density of a dependent node group is determined by calculating the average in-degree and out-degree of the nodes within the group. For example, a group containing 5 nodes with 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 alarm rate of the node group in the past 30 days. For example, if a dependent group successfully intercepts 98% of SQL injection attacks and has a false alarm rate of 1%, the success rate score is 0.97. The initial priority weight is generated through a linear combination of the connection density (weight 0.6) and the success rate (weight 0.4). For example, a group with a connection density of 2.5 and a success rate of 0.97 has an initial weight of (2.5×0.6 + 0.97×0.4) = 1.888. The priority weight of a conflict node group is inversely allocated based on the misinterception rate of the conflict edges. For example, the weights corresponding to misinterception rates of 0.10 and 0.20 for conflict edges are 0.90 and 0.80 respectively.

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

[0067] In an optional example, the real-time resource occupancy rate is obtained through the system performance monitoring interface, including the CPU usage rate of each branch (such as the traffic blocking branch occupying 45%), the memory occupancy (such as the access control branch occupying 120MB), and the network bandwidth utilization rate (such as the data encryption branch occupying 30Mbps). The dynamic adjustment formula is: Dynamic weight = Initial weight × (1 - Branch resource occupancy rate / Resource threshold). For example, when the CPU occupancy rate of the traffic blocking branch is 45% and the threshold is 70%, the dynamic weight of its associated rule is adjusted to the initial value 1.888 × (1 - 45 / 70) = 1.888 × 0.357 ≈ 0.674. If the resource occupancy of a certain branch exceeds the threshold (such as the memory occupancy of the access control branch exceeding 150MB), a weight reduction penalty is imposed on its associated rule. For example, the weight is multiplied by 0.5 to reduce the execution priority. The adjusted weights are mapped to the 0-1 interval through normalization processing to form a dynamic priority weight matrix.

[0068] Step S367: Rearrange the rule execution order of the node groups with conflict relationships based on the dynamic priority weights to generate a rule execution sequence after conflict resolution.

[0069] In an alternative example, conflict resolution can adopt a greedy algorithm to preferentially execute rules with high dynamic weights. For example, when there is a conflict between "block inbound HTTP traffic (weight 0.85)" and "allow administrators to access the API (weight 0.75)", the blocking rule is executed first. For conflicting rules with similar weights (such as 0.80 vs 0.78), a time decay factor is introduced to preferentially execute the rule that was successfully intercepted most recently. After the execution sequence is generated, the logical consistency is verified through a sandbox environment. For example, the conflicting traffic is replayed in a simulator to verify whether administrators can still access the API through the whitelist mechanism after the blocking rule is executed. The final sequence is sorted in descending order of weights to form a linear execution chain such as "Rule A (0.92) → Rule B (0.85) → Rule C (0.78)".

[0070] Step S368: Integrate the rule execution sequence with the node group having a dependency relationship to generate a real-time protection policy set including execution path branches and priority weights.

[0071] In an alternative example, the policy path integration is achieved through topological sorting of a directed acyclic graph (DAG), and the dependency relationship node group is split into parallel execution sub-paths. For example, the dependency group "encrypt PHI data (D02-A1) → allow access to db.customer_info (R005)" generates independent sub-paths and is processed in parallel with other rules in the main execution chain. The execution path branches are divided according to the resource isolation requirements of the node group. For example, traffic filtering rules with high CPU occupancy 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 includes the execution conditions, dynamic weights, belonging path branches, and timeout fallback policies of each rule. For example, it is set that the traffic filtering rule automatically degrades to a rough filtering mode when it is not completed within 50 milliseconds. The policy set ensures integrity and traceability through version control tags and digital signatures for the policy execution agent to load and implement.

[0072] As an implementation manner, in step S400, based on the real-time protection policy, the network traffic of the asset business node is executed for the policy to generate a policy execution result and feedback it to the dynamic protection model, which may specifically include: Step S410: Sort 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.

[0073] The priority weight is the numerical execution priority identifier generated by the dynamic protection model based on rule conflict resolution and resource state assessment in the foregoing embodiments. Its numerical range is usually set from 0 to 1. The higher the value, the stronger the urgency of policy execution. The traffic filtering rules include the source IP address blacklist, protocol type filtering conditions, and traffic rate limit thresholds. For example, for the core asset node that detects distributed denial of service (DDoS) traffic, its associated rule is given a priority weight of 0.95. The access control list entries cover user role permission mapping, resource access time window restrictions, and session token lifecycle policies. For example, an entry for a temporary account accessing a sensitive API during non-working hours is given a weight of 0.8. The key rotation policy includes key update trigger conditions, encryption algorithm switching rules, and key distribution path configurations. For example, a key policy for an edge node storing user privacy data is given a weight of 0.7. The sorting process uses a max heap data structure to arrange the policy execution sequence in descending order of weight values, ensuring that high-weight rules are preferentially loaded into the execution queue. For example, when the traffic filtering rule (0.95), access control list entry (0.8), and key rotation policy (0.7) exist simultaneously, the system will sequentially generate an execution order chain of "block abnormal IP → restrict temporary account permissions → trigger key update".

[0074] Step S420: Inject a policy execution agent at 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.

[0075] In an optional example, the network interface layer refers to, for example, the protocol stack level in the operating system kernel that processes network packet forwarding. The policy execution agent is a lightweight kernel module or a user-space daemon process, and is embedded between the network card driver and the protocol stack through a hook mechanism. The traffic filtering operation is implemented by registering a Netfilter hook function. For example, a filtering function is mounted in the PREROUTING stage to discard SYN packets of blacklisted IPs based on five-tuple rules, and at the same time, the outbound traffic of specific protocol types is rate-limited in the POSTROUTING stage. The permission verification operation is integrated into the identity authentication microservice. For example, a dynamic policy engine is inserted into the authentication interceptor of the API gateway to verify in real time whether the role identifier in the session token matches the resource scope in the access control list. The data encryption operation is implemented by hijacking the read and write functions of the application layer socket (Socket). For example, when sensitive data features are detected, the OpenSSL library is called to encrypt the plaintext data into AES-256-GCM ciphertext according to the key rotation policy. The proxy module uses atomic operations to ensure the atomicity of policy execution. For example, a spinlock is used to ensure data consistency during key update and avoid encryption state conflicts.

[0076] 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 period when the policy takes effect.

[0077] In an optional example, the execution status monitoring is implemented through kernel probes (Kprobe) and performance counters (Perf Event), and the CPU usage rate, memory occupancy, and interrupt latency metrics of the policy execution agent are collected in real time. The network traffic change characteristics include the inbound / outbound packet rate, TCP retransmission rate, and changes in protocol type distribution. For example, after the traffic filtering rule takes effect, the packet loss rate of abnormal IP addresses is increased from 90% to 99% through sFlow sampling technology. The security event logs record the details of policy trigger events. For example, the interception logs contain attack type tags (such as SQL injection), source IP addresses, target ports, and rule hit timestamps, and the encryption logs contain key IDs, algorithm identifiers, and encrypted data block hash values. The monitoring data is temporarily stored in a ring buffer and uploaded to the analysis engine in batches according to a preset time window (such as every second) to ensure the balance between real-time performance and system overhead.

[0078] Step S440: Extract the policy response latency, threat interception success rate, and resource occupancy rate from the network traffic change characteristics to generate policy effectiveness metrics.

[0079] In an optional example, the policy response latency refers to the time interval from policy loading to the first rule taking effect. For example, the latency from injecting to discarding the first malicious packet of the traffic filtering rule should be less than 10 milliseconds. The threat interception success rate is calculated as the ratio of the number of successfully intercepted threat events to the total number of detections. For example, 98 out of 100 SQL injection attack attempts are intercepted, and the success rate is 98%. The resource occupancy rate is obtained by normalizing the CPU, memory, and bandwidth usage. For example, the CPU occupancy rate of the traffic filtering agent is mapped from 15% to 0.15 (range 0-1). The generation of effectiveness metrics uses a multi-dimensional weighted scoring model. For example, the weight of the response latency is 0.4, the weight of the interception success rate is 0.5, and the weight of the resource occupancy rate is 0.1. The final score is (latency score × 0.4 + success rate score × 0.5 + resource score × 0.1). The metric data is stored as continuous records in a time series database (TSDB), supporting sliding window aggregation queries.

[0080] Step S450: Perform correlation analysis on the security event logs and the policy effectiveness metrics to generate a policy execution result containing policy correction suggestions.

[0081] In an alternative example, association analysis can adopt a timestamp-based event-metric alignment algorithm. For example, the attack interception time point in the security event log is matched with the response delay curve in the performance metric through a sliding window, and the average delay deviation during the attack peak period is calculated. Causal strength analysis quantifies the correlation between event types and metric fluctuations through transfer entropy. For example, when a distributed denial-of-service (DDoS) attack event occurs, if the resource occupancy rate increases by more than 0.3 and the interception success rate decreases by 5%, it is determined that there is a strong causal association between the two. The policy correction suggestion is generated based on the association pattern matching a predefined optimization rule library. For example, when the response delay of the traffic filtering rule exceeds 20 milliseconds and the CPU occupancy rate is higher than 0.25, the "optimization rule matching algorithm" and the "enable hardware offloading" suggestion items are triggered. The execution result is fed back to the dynamic protection model in the form of a structured report, including the original data reference, the analysis process summary, and the correction action sequence. For example, "reduce the complexity of the traffic filtering rule → replace regular expression matching with a DFA state machine → enable network card SR-IOV virtualization acceleration".

[0082] As an implementation manner, in step S450 above, the security event log is associated with the policy performance metric to generate a policy execution result including a policy correction suggestion, including: Step S451: Extract the event type identifier, event trigger timestamp, and event impact scope from the security event log to generate a security event log feature set.

[0083] In an alternative example, the security event log is standardized audit data recorded by the policy execution agent during the protection process. Its event type identifier is classified and encoded according to the MITRE ATT&CK attack framework. For example, a SQL injection attack is marked as the "TA0001-T1190 event type identifier", and a distributed denial-of-service attack is marked as the "TA0048-T1498 event type identifier". The event trigger timestamp is accurate to the millisecond level and is recorded in the ISO 8601 extended format (such as "2023-08-25T14:30:45.789Z"), and is synchronized with the NTP server to ensure cross-node time consistency. The event impact scope is quantified by the number of affected asset business nodes, the magnitude of data leakage, and the service interruption duration. For example, if a certain attack causes 3 core servers to go down for 2 hours, it is marked as "impact scope level L3 (number of nodes ≥ 3, duration ≥ 1h)". The feature set is stored indexed by the event unique identifier, forming a structured data set including the event type identifier, the timestamp triple, and the impact scope score.

[0084] Step S452: Extract the metric type identifier, metric collection timestamp, and metric value range from the policy performance metric to generate a policy performance metric feature set.

[0085] In an alternative example, policy effectiveness metrics include, for example, quantitative parameters such as threat interception success rate, policy response latency, and resource occupancy rate. The metric type identifiers are classified and encoded according to performance dimensions, such as "Threat Interception Success Rate Identifier (KPI-001)" and "CPU Occupancy Rate Identifier (KPI-005)". The metric collection timestamp is aligned with the event trigger timestamp using the same time source to ensure the accuracy of time series correlation analysis. The metric value range is generated by sliding window statistics. For example, the average CPU occupancy rate (45%-52%) of a certain edge node in the time period from 10:00 to 10:05 is mapped to the range identifier "KPI-005:45-52". The feature set is stored as a record in the time series database, and each record contains the metric type identifier, the collection time window, and the upper and lower bounds of the value, supporting efficient range queries and aggregation calculations.

[0086] Step S453: Based on the time window overlap relationship between the event trigger timestamp and the metric collection timestamp, align the security event log feature set and the policy effectiveness metric feature set in time to generate spatio-temporal correlation feature pairs.

[0087] In an alternative example, the time window overlap analysis can use a sliding window matching algorithm. Define the time period ΔT (such as ±30 seconds) before and after the event trigger timestamp as the correlation window, and filter all the effectiveness metrics collected within this window. For example, when a SQL injection attack event is triggered at 10:00:00, the correlation window is from 09:59:30 to 10:00:30, and metrics such as "Threat Interception Success Rate (KPI-001):92%-95%" and "CPU Occupancy Rate (KPI-005):48%-53%" are extracted during this period. The spatio-temporal correlation feature pairs are associated through a composite key of the event type identifier and the metric type identifier. For example, "TA0001-T1190 event type identifier + KPI-001 metric type identifier" represents the association pair between the attack event and the interception success rate metric. The aligned feature pairs are appended with a time overlap ratio parameter (such as 85% data coverage within the window) for subsequent causal strength calculation.

[0088] Step S454: According to the mapping relationship between the event type identifier and the metric type identifier, construct an association graph. The nodes in the association graph represent the event features or metric features in the spatio-temporal correlation feature pairs, and the edges represent the causal strength and synchronization parameters between the event features and the metric features.

[0089] In an alternative example, the association graph is a weighted directed graph, and the nodes are divided into event feature nodes (such as TA0001-T1190) and metric feature nodes (such as KPI-001). The edge weights are calculated by combining the causal strength and the synchronization parameter: the causal strength quantifies the information contribution of the event occurrence to the metric fluctuation through transfer entropy. For example, when a SQL injection attack causes a 5% decrease in the interception success rate, the causal strength is 0.78 (range 0-1); the synchronization parameter calculates the time-lag correlation between the event and the metric change. For example, when the CPU occupancy rate increases 5 seconds after the attack, the synchronization parameter is 0.65. The edge direction represents the causal flow. For example, "TA0001-T1190 → KPI-005" means that the attack event causes the CPU occupancy rate to increase. The construction of the graph adopts an incremental update mechanism, and new association pairs are merged and the edge weights are adjusted after each analysis cycle.

[0090] Step S455: Traverse the association graph, detect the node groups connected by the edges with high causal strength, and identify the key association node groups based on the coverage relationship between the event influence range and the metric value range.

[0091] In an alternative example, assume that the high causal strength threshold is set to 0.7, and the association pairs with edge weights ≥ 0.7 are screened during the traversal. For example, the causal strength of the edge "TA0048-T1498 (DDoS attack) → KPI-005 (CPU occupancy rate)" is 0.85, and the event influence range level L4 (number of nodes ≥ 10) highly overlaps with the CPU occupancy rate range of 75%-90%, which is determined to be a key association node group. The coverage relationship is calculated by Jaccard similarity. For example, when the similarity between the attack influence node set and the high CPU occupancy node set is 0.8, the coverage coefficient is set to 0.8. The comprehensive score of the key node group is generated by the 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, and the groups with a score higher than the threshold of 0.75 are marked as key associations.

[0092] Step S456: Extract the event type identifier, metric type identifier, and historical correction records corresponding to the key association node group to generate the association pattern features.

[0093] In an alternative example, the association pattern feature has a triple structure, including an event type identifier, an indicator type identifier, and a historical correction action hash. For example, the key association group "TA0001-T1190 + KPI-001" triggered "optimize SQL filtering rules (action hash A1B2)" and "increase the number of WAF threads (action hash C3D4)" in the historical record. Feature generation is achieved through an association rule mining algorithm. For example, the Apriori algorithm is used to find frequently co-occurring event-indicator-action combinations. Each pattern feature is attached with support (e.g., the proportion of the occurrence of this combination is 30%) and confidence (e.g., the probability that the correction action effectively improves the indicator is 85%) parameters, forming a feature entry such as "TA0001-T1190→KPI-001: support 0.3, confidence 0.85, action [A1B2,C3D4]".

[0094] Step S457: Invoke the pre-trained correction rule library, match the association pattern feature with the rule conditions in the correction rule library, and filter out candidate correction rules that meet the matching threshold.

[0095] In an alternative example, the correction rule library is, for example, a set of if-then rules 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 association pattern feature and the rule conditions: the event type identifier is completely matched (weight 0.5), the relationship of the indicator interval inclusion (e.g., the current KPI-001 is 85%-90% and matches the "<90%" condition in the rule, weight 0.3), and the matching degree of the historical action hash (weight 0.2). For example, if the similarity between a pattern feature and the rule conditions reaches 0.85 (threshold 0.8), it is determined as a candidate rule. The selected candidate rules are sorted in descending order of confidence, and rules that conflict with the node resource status are excluded (such as excluding correction actions that require high memory when the memory is insufficient).

[0096] Step S458: Based on the correction action type and priority parameter in the candidate correction rule, combined with the resource status of the current policy execution agent, generate a policy correction suggestion including a sequence of correction actions and the execution order.

[0097] In an alternative example, the types of corrective actions are classified into immediate execution types (such as blocking an IP) and progressive optimization types (such as adjusting model parameters). The priority parameter is calculated based on the rule confidence and the degree of urgency. For example, a rule with a confidence of 0.9 and an impact scope of L3 has a priority of P0 (the highest). The resource status is obtained through a real-time monitoring interface. For example, when the current available memory is 2GB, an action of "upgrading the detection engine" that requires 1.8GB of memory is excluded. The action sequence generation uses topological sorting to ensure that dependent actions are executed in order (such as first "expanding memory" and then "enabling the deep learning model"). The final recommendation format is a JSON array, such as "[{'action': 'update_regex', 'priority': 0.9,'resource_needs': {'cpu': '30%','mem': '500MB'}}, ...]", which is called by the dynamic protection model parameter optimization module.

[0098] Step S459: Validate the effectiveness of the policy correction recommendations and the policy effectiveness metrics, eliminate corrective actions that conflict with the current network environment, and generate an optimized policy execution result.

[0099] In an alternative example, the effectiveness validation can be achieved by replaying historical traffic and attack samples in a sandbox environment. For example, after applying the corrective action of "optimizing the regular expression engine" 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%. The conflict detection is based on the compatibility check of the network topology policy. For example, when the corrective action requires enabling IPv6 filtering but the current node only supports IPv4, mark this action as a conflict. The optimized policy execution result includes a list of effective actions, a list of conflicting actions, and comparison data of verification metrics. For example, "KPI-001 has increased by 7% after action A takes effect, and action B is excluded due to insufficient resources". The result data ensures integrity through digital signatures and is persistently stored in the audit database for compliance review.

[0100] As an implementation method, in step S500, adaptively optimize the decision-making parameters of the dynamic protection model according to the policy execution result, and generate an updated dynamic protection model for the next round of asset business node protection decisions, including: Step S510: Parse the policy correction recommendations in the policy execution result, and extract the decision branch network identifiers to be optimized and the parameter adjustment directions.

[0101] The result of policy execution is a structured report containing multi-dimensional correlation analysis data generated by step S450. The policy correction suggestion field stores an optimization instruction set for each decision branch of the dynamic protection model. The parsing process uses a recursive descent analysis method based on semantic templates. First, the natural language suggestions in the report are converted into machine-readable JSON format operation instructions. For example, "Reduce the protocol parsing depth of the traffic blocking branch to shorten the response latency" is converted into {"branch": "traffic blocking branch", "action": "reduce_parsing_depth", "param": "protocol_layer"}. The decision branch network identifier is extracted by matching predefined network topology tags. For example, when the correction suggestion involves "low matching efficiency of access control list", it is automatically associated with the unique identifier "ACL_Branch_001" of the access control branch. The parameter adjustment direction is deduced from the operation type and target parameter field in the instruction. For example, for the suggestion of "improve the matching speed of encryption algorithms", the parameter direction "encryption_algorithm_selection_latency" is extracted and the optimization target is marked as "reduce by 20%". The parsing result forms an optimization task list containing branch identifiers, parameter paths, and expected value intervals, providing input for subsequent targeted optimization.

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

[0103] In an optional example, the traffic detection window size can be the time series interval length used to cache network packets during the protocol in-depth parsing process. Its adjustment is based on the historical correlation curve between the policy response latency and the window size. For example, when the average response latency of the core asset node increases from 15 milliseconds to 25 milliseconds, the system calculates according to the sliding window regression model that the optimal window size should be reduced from 200 milliseconds to 150 milliseconds to reduce the context switching overhead. The update of the blocking threshold determination logic is based on the Bayesian probability model of the threat interception success rate. For example, when the interception success rate for SQL injection attacks drops from 92% to 85%, the abnormal request count threshold in the determination logic is dynamically adjusted from 500 times per second to 300 times, and the protocol field abnormal matching mode is switched from exact match to fuzzy match (similarity threshold drops from 95% to 90%). The parameter adjustment process uses an online learning mechanism to verify the effectiveness of the new threshold by injecting synthetic attack traffic in real time, ensuring that the response speed is improved without reducing the interception accuracy.

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

[0105] In an alternative example, the session token verification frequency refers to the number of times the permissions of the same token are rechecked per unit time, and its adjustment strategy is dynamically calculated based on the CPU and memory occupancy rates of the access control branch. For example, when the memory occupancy rate of the edge node exceeds 75%, the verification frequency is reduced from 100 times per second 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 trustworthiness scoring mechanism. The optimization of the access control list matching algorithm adopts a data structure reconstruction strategy. For example, the original linear traversal matching is replaced with a fast pre-screening mechanism based on the Bloom Filter, reducing the matching time complexity from O(n) to O(1). At the same time, cache hot path optimization is introduced, and an independent hash index is 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 no false positives or misses in 99% of the request scenarios.

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

[0107] In an alternative example, the encryption strength parameter is comprehensively evaluated by the algorithm key length, encryption mode, and quantum resistance ability. For example, the strength parameter of the AES-256-GCM algorithm is 9.8 (range 0 - 10), while that of the ChaCha20-Poly1305 algorithm is 9.5. The data processing delay includes the encryption operation time and the key distribution delay. For example, in the Internet of Things edge node scenario, the encryption delay of AES-256-GCM is 8 milliseconds / KB, and that of ChaCha20-Poly1305 is 5 milliseconds / KB. The balance relationship is determined through Pareto Front analysis. For example, when the node CPU usage threshold is set to 70%, ChaCha20-Poly1305 is selected as the main algorithm to reduce the delay by 3 milliseconds / KB while reducing the strength parameter tolerance by 0.3. The algorithm switching process adopts a double-buffering mechanism, running the old and new algorithms in parallel during the key rotation period until the new algorithm passes the integrity check and is fully switched to avoid service interruption.

[0108] Step S550: Synchronize the parameters of the optimized decision branch networks of each branch to generate an updated dynamic protection model for version iteration, and write the update log into the model version library.

[0109] In an alternative example, parameter synchronization adopts a distributed gradient aggregation strategy. First, the protocol parsing depth parameters of the traffic blocking branch, the Bloom filter bit array of the access control branch, and the algorithm selection weights of the data encryption branch are uploaded to the parameter server, and the latest parameter copies are obtained by each node through the consistent hashing algorithm. During the version iteration process, the network weights of the dynamic protection model are merged and optimized by means of incremental updates. For example, the learning rate of the traffic blocking branch is adjusted from 0.001 to 0.0005 using the Adam optimizer, and at the same time, historical weight snapshots are retained to support rollback. The update log records the parameter comparison before and after the adjustment, the results of the performance benchmark test, and the compatibility verification status, such as "Traffic detection window: 150ms ← 200ms (latency reduced by 33%) | Blocking threshold: 300 times / second ← 500 times / second (success rate +3%)". The log entries are sorted by ISO 8601 standard timestamps and stored in the model version library, and integrated with the Git version control system to support multi-dimensional retrieval and difference analysis by node type, time range, or optimization type.

[0110] As an implementation, the pre-training process of the dynamic protection model may specifically include the following steps: Step S10: Construct a training data set for historical asset business nodes, where the training data set includes normal business traffic samples, known attack traffic samples, and mixed traffic samples.

[0111] In an alternative example, it is assumed that the training data set for historical asset business nodes is constructed by collecting real business environment data with a collection period of not less than 12 months, covering all types of business scenarios of core asset nodes, edge asset nodes, and transit asset nodes. The normal business traffic samples are extracted from the security-audited business logs, including standard protocol interaction processes (such as GET / POST request sequences of HTTP / 1.1, full connection records completed by TCP three-way handshakes) and compliant operation behaviors (such as database transaction commit logs, file system read and write operation records). The known attack traffic samples are sourced from public vulnerability libraries (such as CVE, NVD) and attack payloads generated by penetration testing tools, covering typical attack patterns such as UDP flood packets for distributed denial-of-service attacks (DDoS), malformed request parameters for structured query language injection attacks (SQL Injection), and malicious script payloads for cross-site scripting attacks (XSS). The mixed traffic samples are generated by fusing normal business traffic and known attack traffic in a certain proportion. For example, five SQL injection probe requests are inserted per minute into the 1-hour access log of the core node to simulate a covert attack scenario in the real environment. All samples are classified and stored by node type, protocol type, and time window to form a structured data set with metadata tags.

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

[0113] In the optional example, feature enhancement processing aims to improve the model's adaptability to dynamic changes in the business environment and adversarial attacks. The spatiotemporal perturbation features are injected in the following ways: a random offset of [-5%, +5%] is applied to the timestamps of normal business traffic samples to simulate traffic fluctuations during different business peak hours, such as extending the HTTP request logs that were originally evenly distributed between 9:00 and 18:00 to 8:30-18:30 to cover the burst access mode during the morning peak. Noise packets that comply with protocol specifications are inserted into known attack traffic samples (such as filling invalid TCP option fields and adding redundant HTTP header parameters) to generate adversarial samples with obfuscation features, such as mixing 10% of legitimate SELECT statements into SQL injection attack payloads to bypass simple regular expression detection. Protocol field mutation is performed on mixed traffic samples, and key fields of the application layer protocol are modified (such as changing the HTTP method type from GET to G3T and randomly converting the upper and lower case of JSON key names), generating protocol compatibility test samples, and verifying the robustness of the model to non-standard protocol implementations. The enhanced data set is aligned with the time window and verified by protocol semantics to ensure that the perturbation operation does not destroy the business logic integrity of the original data.

[0114] As an implementation manner, step S20, performing feature enhancement processing on the training data set to generate an enhanced data set containing spatiotemporal disturbance features, may specifically include: Step S21: Add random time offsets to normal business traffic samples to simulate traffic fluctuations during different business peak periods.

[0115] In the optional example, the time offset operation can use the sliding window resampling technology to apply a random delay that conforms to the Poisson distribution to the timestamp of each data packet while retaining the original business operation sequence. For example, the original time interval of the database transaction log of a core asset node is 100±20 milliseconds. After adding a uniformly distributed offset of [-10ms, +10ms], the interval becomes an irregular distribution of 90-110 milliseconds, simulating the processing delay changes caused by server load fluctuations. The offset range is dynamically adjusted according to the node type. The core node uses a narrow offset (±5%) to maintain the business continuity feature, and the edge node uses a wide offset (±15%) to enhance the adaptability to intermittent connections. The offset samples are causally tested to ensure that the order of the operation sequence remains unchanged and avoid transaction logic conflicts caused by time dislocation.

[0116] Step S22: inserting noise data packets into known attack traffic samples to generate adversarial samples with obfuscation features.

[0117] In an alternative example, the noise packet insertion strategy is implemented based on protocol fuzzing technology, and random noise is injected into the keyword fields of the attack payload. For example, in the WHERE clause of an SQL injection attack, an invalid comparator is inserted (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 make its length exceed the MTU limit. The noise injection ratio is controlled within the range of 5% - 15% to ensure that the attack characteristics can still be detected but the model needs to have higher generalization ability. After the adversarial samples are generated, the malformed packets caused by noise injection (such as checksum errors and length overrun) are filtered by a protocol compliance checker, and the samples that conform to the transport layer specification but have abnormal application layer semantics are retained to form a high-quality adversarial training set.

[0118] Step S23: Mutate the protocol fields of the mixed traffic samples to generate protocol compatibility test samples.

[0119] In an alternative example, the protocol field mutation can adopt a depth mutation strategy based on the syntax tree. After parsing the abstract syntax tree (AST) of the application layer protocol, equivalent replacements that preserve semantics are made for specific nodes. For example, the value of the User-Agent field in the HTTP request header is mutated from "Mozilla / 5.0" to "Mozi11a / 5.O", or the boolean value true in the JSON payload is modified to 1. For binary protocols (such as Modbus TCP), the sub-function code is randomly adjusted within the legal value range of the function code field (e.g., the read holding register function code 0x03 is mutated to 0x83). The mutated samples are verified for their network layer compatibility through a protocol consistency test framework (such as Packetdrill) to ensure that they can be parsed by the standard protocol stack, thus effectively training the model to recognize unconventional but legal protocol implementations.

[0120] Step S24: Combine the time-offset normal samples, adversarial samples, and protocol mutated samples to generate an enhanced dataset.

[0121] In an alternative example, the sample combination process adopts, for example, 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-offset normal samples, SQL injection adversarial samples, and HTTP protocol mutated samples are mixed in a ratio of 6:2:2; in the edge node subset, normal samples, DDoS adversarial samples, and Modbus protocol mutated samples are mixed in a ratio of 5:3:2. The temporal relationship and causal dependence of the original data are retained during combination. For example, the TCP sequence number continuity of the packets before and after is maintained at the position where the adversarial samples are inserted. The finally generated enhanced dataset is associated with the original samples and the enhanced operation records through a unique hash identifier to support the traceability analysis of the training process.

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

[0123] In an optional example, the multi-dimensional threat labels can be vectorized labels based on a threat knowledge graph, including attack types (such as DDoS, SQL injection), associated vulnerabilities (such as CVE numbers), attack phases (such as reconnaissance, penetration), and impact levels (scored from 0 to 10). The recommended protection strategy labels are generated based on historical handling records. For example, a multi-step strategy sequence of "block source IP | enable parameterized query detection | trigger database audit" is labeled for SQL injection samples. The labeling process is implemented using a semi-automatic toolchain: first, the threat intelligence platform automatically matches the CVE numbers of attack samples with mitigation measures, and then security experts review and supplement fine-grained strategy suggestions. The labeled data is stored in JSON-LD format and forms an associated index with the timestamp, protocol type, and node type fields of the sample data for the multi-task learning framework of the model to call.

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

[0125] In an optional example, the network weight initialization can adopt the He normal distribution method, setting different initialization variances for the convolutional layer and the fully connected layer. For example, the convolutional kernel weights are initialized in the fan_in mode to adapt to the input dimensions of the feature distribution layer. The multi-task learning objective function integrates the losses of the three sub-tasks through weighted summation: the threat classification loss uses the Focal Loss to handle the class imbalance problem. For example, a higher weight is given to rare attack types (such as APT); the policy generation loss calculates the difference between the recommended policy sequence and the predicted sequence through the edit distance algorithm. For example, it compares the position deviation between "block IP → enable detection" and the prediction "enable detection → block IP"; the resource consumption loss uses the L1 regularization term to constrain the predicted values of CPU and memory occupancy rates during model inference. For example, it restricts the memory occupancy of the access control branch to not exceed 50MB. The loss weights are dynamically adjusted according to the importance of the tasks. In the initial training stage, the threat classification loss weight is set to 0.6, the policy generation loss is 0.3, and the resource consumption loss is 0.1, and they are gradually balanced as the model converges subsequently.

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

[0127] Exemplarily, the phased training strategy can implement parameter freezing through a gradient masking mechanism. In the first phase, only the convolution kernel parameters of the feature distribution layer and the weights of the attention mechanism are updated. For example, during the training of 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 first learn the feature decoupling ability 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. In the joint training phase, an adversarial training technique is introduced, and the adversarial samples generated in step S22 are mixed into the training batch at a ratio of 15% to improve the model's discriminative ability for obfuscated features. The training process uses mixed-precision computing. The feature distribution layer uses FP32 precision to maintain numerical stability, and the decision branch network uses FP16 precision to accelerate computing.

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

[0129] In an optional example, the early stopping mechanism monitors the multi-task loss function on the validation set and terminates the training when the loss decrease amplitude is less than 0.5% for 10 consecutive epochs to prevent overfitting. The cross-validation adopts 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 augmented dataset is divided into 5 mutually exclusive subsets, and 1 subset is selected as the validation set in turn, and the rest are used as the training set. The training is repeated until the validation metrics of each fold are stable. The final model parameters select the checkpoint with the highest threat classification F1-score and resource consumption lower than the threshold in the cross-validation, and the weights of the optimal models of each fold are integrated by the parameter averaging method. The pre-trained dynamic protection model is exported in the ONNX format, accompanied by a model card document containing training hyperparameters, data versions, and performance metrics to ensure the reproducibility of the deployment environment.

[0130] As an implementation manner, the method provided in the embodiments of the present invention further includes a process of performing dual-channel verification during the policy execution process, which may specifically include: Step S600: While the local protection agent at the asset business node executes the real-time protection policy, send a policy verification request to the cloud verification server.

[0131] In an alternative example, the local protection agent is a lightweight security component deployed in the operating system kernel or user space of the asset business node. Its core functions include real-time loading of protection policies generated by the dynamic protection model, execution of traffic filtering, permission verification, and data encryption operations. The policy verification request is sent using an asynchronous duplex communication mechanism. While the local policy takes effect, the policy metadata (such as the five-tuple conditions of traffic filtering rules, the role-resource mapping relationship of the access control list, and the algorithm identifier of the key rotation policy) and the context environment characteristics (such as node type, protocol distribution, resource occupancy rate) are encapsulated into a JSON format request body and uploaded to the cloud verification server in real time. For example, when the core asset node executes the rule of "blocking all TCP connections from source IP address 192.168.1.100", the local protection agent synchronously sends a verification request containing the rule, node identifier, and current CPU usage rate (such as 45%) to the cloud to ensure that the cloud verification process does not affect the real-time execution of the local policy.

[0132] 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 correction instruction.

[0133] In an alternative example, the global threat intelligence library is a distributed knowledge graph that aggregates multi-source threat data (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. The compliance verification covers policy effectiveness verification (such as whether the blocking rule covers the latest attack variants), policy conflict detection (such as whether the filtering rule conflicts with the existing firewall policy), and compliance review (such as whether it meets the GDPR data encryption requirements). For example, when the cloud detects that the rule of "allowing all ICMPv6 packets to pass" formulated by a certain edge node may be exploited for NDP protocol spoofing attacks, a correction instruction containing "restricting ICMPv6 packets of types 135-136" is generated. The correction instruction ensures integrity through a digital signature and is attached with a priority label (such as high-risk instructions need to be responded to within 5 seconds) and execution conditions (such as only taking effect when the node memory usage rate is lower than 70%) to form a structured policy correction instruction set.

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

[0135] In an alternative example, conflict detection can be achieved by comparing the results of local policy execution (such as threat interception logs, resource consumption metrics) with the expected effects of cloud correction instructions. For example, when the local execution blocks the RDP protocol connection on port 3389, if the cloud verification finds that this rule causes the interruption of the legitimate operation and maintenance channel (based on the whitelist IP list in the global intelligence library), it is determined as a policy conflict. After the rollback mechanism is started, the local protection agent pauses the current policy engine and sends a version retrieval request to the model version library, and filters out compatible historical model versions according to the node type, policy hash value, and time range. For example, the core asset node retrieves the last 3 stable versions (such as v2.1.3, v2.1.2, v2.1.1) and excludes the historical versions that are only applicable to edge nodes (such as v2.0.5-edge). The model switching uses hot loading technology. On the premise of ensuring that the network connection is not interrupted, 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) with the parameter snapshots of the historical version, and the policy execution agent is restarted to load the rolled-back model instance.

[0136] Among them, in step S800, the protection policy rollback mechanism is triggered to load the dynamic protection model of the previous version, which may specifically include: Step S810: Retrieve the historical model version compatible with the current asset business node from the model version library.

[0137] In an alternative example, the model version library is a tamper-proof storage system built based on blockchain technology. Each historical version includes model network weights, training dataset fingerprints, and compatibility metadata (such as supported node types, protocol types, operating system versions). The retrieval process uses a semantic version number matching and dependency resolution algorithm. For example, when the current node runs in the Linux kernel 5.4.0 environment, only the 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 the simulation environment, and a copy of the network traffic of this node in the past 24 hours is injected to verify whether it can correctly generate protection actions consistent with the historical policy. The versions that pass the compatibility test are sorted in reverse chronological order for subsequent fitness evaluation selection.

[0138] Step S820: Compare the fitness of the decision parameters of the historical model version with the current environmental characteristics and select the optimal rollback version.

[0139] In an alternative example, the adaptability evaluation uses a multi-objective optimization model to quantify the matching degree of historical versions in different dimensions: the adaptability of decision parameters calculates the similarity between the current environmental feature vector (such as threat vector distribution, resource occupancy rate) and the feature of historical version training data through cosine similarity; the adaptability of policy execution effect compares the difference in interception success rate between the historical version and the current version through replay testing (for example, version v2.1.3 reached a 95% interception rate in the test, while the current version is 88%); the adaptability of resource consumption evaluates whether the CPU / memory occupancy rate of the historical version meets the remaining resources of the current node. For example, when the current available memory of the node is 2GB, historical versions that require more than 1.8GB of memory (such as v2.1.0-memheavy) are excluded, and version v2.1.2 with a memory occupancy of 1.2GB and an interception rate ≥ 90% is selected as the optimal rollback target. The evaluation results generate an adaptability score matrix, and the version with the highest score is selected after sorting by the weighted total score.

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

[0141] In an alternative example, the suspension of the policy execution process can be achieved through atomic operations. For example, first send a SIGSTOP signal to the policy execution agent to suspend all threads, and then mark the model weight area in the shared memory as read-only to prevent concurrent modification during the switching process. The network weight switching uses the memory mapping file technology to load the weight file of the optimal rollback version (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 switching is completed, send a SIGCONT signal to the agent to resume thread execution. For example, a certain core node completed the weight switching 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 the business continuity is not significantly affected.

[0142] Step S840: Re-initialize the policy execution agent and generate an alternative protection policy based on the rolled-back model parameters.

[0143] In an alternative example, the rollback 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 runtime parameters according to the rollback version metadata. For example, a dedicated memory pool is allocated for version v2.1.2 and the matching thread concurrency is set. The generation of the alternative protection policy is achieved through real-time inference of the rollback model on the current threat feature vector. For example, based on the decision logic of the historical model v2.1.2, the original policy of "blocking all ICMPv6 packets" is adjusted to "only filtering ICMPv6 router solicitation packets of type 133". The new policy takes effect gradually through the canary release mechanism, first applied to 10% of the traffic samples and the effects are monitored. After confirming no conflicts, it is extended to the full traffic.

[0144] Step S850: After the alternative protection policy takes effect, send a rollback completion notice to the cloud verification server and start a model difference analysis task to locate the cause of the original policy conflict.

[0145] In an alternative example, the rollback completion notice may include the rollback version number, the switching timestamp, and preliminary effect metrics (such as the interception rate increased to 92%). The cloud server 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 conflicting model. For example, through class activation mapping (CAM) visualization, it is found that the original model misjudges legitimate traffic due to overemphasis on the TCP window size feature, while the rollback model pays more attention to payload content analysis. The analysis results generate a root cause report (such as "weight offset in the feature distribution layer leads to abnormal protocol parsing"), triggering a model retraining task to fix the defect.

[0146] Step S900: When the verification results of the local protection agent and the cloud verification server are consistent, update the local policy cache and confirm that the current protection policy is effective.

[0147] In an alternative example, the determination of the verification result consistency needs to meet the following conditions: the correction instruction set returned by the cloud verification is an empty set, and the local policy execution metrics (such as threat interception rate, resource occupancy rate) are within the reasonable range preset by the cloud (such as interception rate ≥ 90%, CPU occupancy ≤ 60%). The cache update adopts the copy-on-write mechanism, marks the current policy set as the stable version and persists it to the local SSD, and at the same time updates the version number and hash check value of the memory cache. For example, after a certain edge node has consistent verification results three times in a row, it upgrades the policy cache version from v1.0.5 to v1.0.6 and synchronously updates the hash value to ensure policy integrity. The confirmation information is reported to the cloud through heartbeat packets, updating the global policy effective status database and completing the dual-channel verification loop.

[0148] As an implementation, after generating the updated dynamic protection model in step S500, the method provided by the embodiments of the present invention may further include: Step S501: Load the updated dynamic protection model into the shadow deployment environment, where the shadow deployment environment includes simulated service nodes and emulated traffic that are consistent with the network topology of the current asset service node.

[0149] In an optional example, the shadow deployment environment can be constructed through virtualization technology to accurately replicate the network topology structure of the target asset service node, 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 service nodes are instantiated using containerization technology. For example, Docker containers are used to simulate service nodes with the same operating system version, service ports, and middleware configuration. The emulated traffic is generated through a traffic replay tool. For example, based on the historical service traffic packets captured by tcpdump, they are replayed according to the original timestamp and protocol distribution characteristics, and 10%-20% of noise data packets are injected to simulate network jitter. The dynamic protection model loading process adopts a hot deployment mechanism, and the model weight file (such as model_v2.1.3.weights) is pushed to the policy engine in the shadow environment through the API gateway to ensure zero-downtime switching.

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

[0151] In an optional example, the historical attack traffic samples are selected from the internal threat intelligence library. For example, a pcap file containing vulnerability exploitation traffic for CVE-2021-44228 and an annotated SQL injection attack request sequence. The new attack traffic samples are generated through red team simulation tools. For example, the Metasploit framework is used to construct APT attack payloads based on zero-day vulnerabilities, or adversarial escape traffic is generated through a GAN network. The mixed test traffic is fused with normal service traffic, historical attack traffic, and new attack traffic in a 7:2:1 ratio. For example, 700 Mbps of normal traffic, 200 Mbps of known attack traffic, and 100 Mbps of new attack traffic are injected into 1 Gbps of emulated traffic to ensure comprehensive threat scenario coverage.

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

[0153] In an alternative 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 the inbound traffic. The policy response behavior records include rule hit logs (such as blocking malicious IP lists and allowing whitelist sessions), anomaly detection events (such as marking buffer overflow attempts), and resource allocation status (such as thread pool utilization rate). The decision latency data is collected through high-precision timestamps to measure the time interval from the arrival of the data packet to the effective implementation of the policy. For example, the P50 (50 milliseconds), P95 (120 milliseconds), and P99 (200 milliseconds) quantiles of the HTTP request processing latency are statistically analyzed. All data is aggregated through a distributed logging system to form a timestamped trace chain.

[0154] Step S504: Extract false interception events, missed interception events, and latency overrun events in the policy response behavior to generate a set of model defect features.

[0155] In an alternative example, a false interception event is defined as an instance where legitimate business traffic is wrongly blocked. For example, a normal user's login request is intercepted due to a misjudgment of the protocol field. A missed interception event refers to an instance where attack traffic is not detected. For example, a new type of DDoS attack bypasses the threshold detection rule. A latency overrun event marks an anomaly where the policy execution time exceeds the preset SLA (such as HTTP request processing latency > 150 ms). The set of defect features is constructed using feature engineering methods: the features of false interception events include the hash value of the misjudged protocol field, traffic direction, and node type; the features of missed interception events are extracted from the entropy value distribution of the attack payload and the protocol anomaly index; the latency overrun event records the thread scheduling latency and the peak CPU occupancy. The feature set is stored as a vector matrix through standardized encoding for subsequent root cause analysis.

[0156] Step S505: Perform correlation analysis between the set of model defect features and the decision parameters of the updated dynamic protection model to locate the decision branch network and the nodes with abnormal weight allocation that cause the defects.

[0157] In an alternative example, correlation analysis can be performed using 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 contribution of the convolutional kernel weight of the traffic blocking branch to a certain false interception is 0.65, indicating that it is the main influencing factor. Decision tree decomposition maps the model inference path to a rule tree to identify the nodes corresponding to the high-frequency defect paths. For example, it is found that 80% of the missed interception events flow through a specific fully connected layer of the access control branch. Nodes with abnormal weight allocation are detected through KL divergence by comparing the weight distribution differences between the normal model and the updated model. For example, when the weight distribution deviation of a certain LSTM layer exceeds 3σ, it is marked as abnormal. The analysis results generate a defect topology map, marking the problem branches and node coordinates.

[0158] Step S506: Based on the anomaly type of the decision branch network, match the corresponding parameter tuning rules from the correction rule library to generate shadow environment tuning instructions.

[0159] In an optional example, the correction rule library is a structured document storage system. Each rule contains a trigger condition (such as "false interception rate of traffic blocking branch > 5%"), an anomaly type code (such as F001 - protocol misjudgment), and a tuning action (such as "reduce the convolutional kernel learning rate by 20%"). The matching process uses multi-level filtering: First, retrieve the candidate rule set according to the anomaly type code. For example, F001 corresponds to 10 related rules. Then, filter by the decision parameter range constraint. For example, only keep the rules applicable to the LSTM layer. Finally, sort based on the historical tuning effect score and select the rules with a confidence level ≥ 90% to generate tuning instructions. The instruction format is a JSON instruction set. For example, {"action": "adjust_learning_rate", "target_layer": "conv_block_3", "value": "-20%"}.

[0160] Step S507: Execute the shadow environment tuning instructions in the shadow deployment environment to perform secondary optimization on the decision parameters of the updated dynamic protection model, and generate a tuned dynamic protection model.

[0161] In an optional example, parameter tuning can be implemented through an online learning framework. For example, use the Keras API of TensorFlow to dynamically modify the model layer parameters. For the adjustment of the convolutional kernel learning rate, adopt an exponential decay strategy to reduce the initial learning rate from 0.001 to 0.0008. For nodes with abnormal weight distribution, apply L2 regularization constraints to make them approach the reference distribution. After secondary optimization, the model is verified through lightweight retraining. For example, use 5% of the mixed test traffic for quick fine-tuning (50 epochs) and verify the effect on the remaining traffic. The tuned model is exported as an optimized weight file (such as model_v2.1.3_tuned.weights), along with a tuning log recording the details of parameter changes.

[0162] 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 latency overrun events is lower than the preset threshold.

[0163] In an alternative example, iterative verification adopts a progressive testing strategy. For example, in the first verification, 20% of the mixed traffic is used. If the false interception rate ≤ 2%, the missed interception rate ≤ 1%, and the P99 latency ≤ 150 ms, it is expanded to full traffic testing. The threshold is set based on the business SLA requirements. For example, for financial core nodes, the false interception rate is required to be ≤ 0.5% and the missed interception rate is required to be ≤ 0.1%. When the standard is not met, a secondary tuning loop 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 library, new tuning instructions are generated, and steps S506 - S507 are repeated. After verification passes, a test report is generated, recording the defect convergence curve and the final performance metrics for each iteration.

[0164] Step S509: Mark the tuned dynamic protection model that has passed verification as the 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.

[0165] In an alternative example, version marking can be achieved through digital signature and blockchain evidence retention. Metadata tags containing hash values, timestamps, and test metrics are attached to the tuned model file. The synchronization process adopts a differential update mechanism, only transmitting the changed weight parameter blocks (such as 50 KB of data in 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, and then atomically replaces the old version model file in the transactional storage. A double buffering mechanism is enabled during replacement to ensure that policy execution is not interrupted. For example, the new model is loaded into the memory standby area and takes over traffic processing instantly through a hot swap instruction.

[0166] As an implementation manner, after synchronizing to the local protection agent of the asset business node in step S509, the method provided by the embodiment of the present invention may further include: Step S5010: Real - time monitor the resource status of the asset business node, where the resource status includes CPU occupancy rate, memory occupancy rate, and network bandwidth utilization rate.

[0167] Exemplarily, resource monitoring is achieved through operating system - level performance counters and hardware sensors. For example, the CPU occupancy rate collects the usr / sys / iowait ratio of each logical core; the memory occupancy rate statistics the process RSS (resident set size) and Swap usage; the network bandwidth utilization rate measures the network card throughput (rx_bytes / tx_bytes) and packet loss rate. Data is collected at a second - level granularity, and the moving average is calculated through a sliding window (such as a 10 - second window). For example, the 1 - minute average value of the CPU occupancy rate is 45%, and the 5 - minute peak value is 75%. The monitoring data is stored as a time series, supporting real - time visualization and threshold alarm triggering.

[0168] Step S5011: Identify the resource load level and resource bottleneck type of asset business nodes according to the dynamic changes in resource status.

[0169] In an optional example, the resource load level can be divided according to multi-dimensional indicators. For example, low load (CPU < 30%, memory < 50%, bandwidth < 40%), medium load (30% ≤ CPU < 70%, 50% ≤ memory < 80%, 40% ≤ bandwidth < 70%), high load (CPU ≥ 70%, memory ≥ 80%, bandwidth ≥ 70%). The resource bottleneck type is determined through principal factor analysis. For example, if the CPU occupancy rate of a certain node reaches 85% and the memory occupancy rate is 60%, it is marked as "CPU bottleneck type"; if the bandwidth utilization rate reaches 90% along with an increase in the TCP retransmission rate, it is marked as "bandwidth bottleneck type". The identification results form a resource portrait, such as "Edge node E23: High load - Bandwidth bottleneck type", to guide the formulation of subsequent optimization strategies.

[0170] Step S5012: Extract the mapping relationship between the decision parameters of the optimized dynamic protection model and resource consumption, and construct a model resource adaptation rule library.

[0171] In an optional example, the mapping relationship can be established through multiple regression analysis. For example, establish a linear model of the number of convolutional kernels (X1), the dimension of the LSTM hidden layer (X2), and the CPU occupancy rate (Y): Y = 0.3X1 + 0.5X2 + ε. The resource adaptation rule library stores such relational expressions and constraint conditions. For example, rule R102 is defined as "When there is a CPU bottleneck, the hidden layer dimension ≤ 128". The rule generation process combines experimental data and theoretical derivation, gradually reducing model parameters (such as reducing the number of neurons in the fully connected layer from 256 to 128) in a controlled environment, recording the resource consumption change curve, and extracting the critical point as a constraint condition. The rule library is classified and indexed according to resource type (CPU / memory / bandwidth) and node type (core / edge / relay).

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

[0173] In an optional example, the screening logic can adopt hierarchical matching. For example, first screen the applicable rule subset according to the node type (such as edge node), then select the corresponding constraint according to the resource bottleneck type (such as bandwidth bottleneck), and finally adjust the constraint threshold in combination with the load level (such as high load). For example, for a high load bandwidth bottleneck type edge node, apply rule R205: "When the bandwidth utilization rate ≥ 70%, limit the encryption algorithm to AES - 128 - GCM (bandwidth consumption ≤ 5 Mbps / session)". The constraint conditions are dynamically combined to generate a parameter adjustment space, such as the allowable range of the number of convolutional kernels [64, 128] and the range of the LSTM step size [5, 10].

[0174] Step S5014: According to the decision parameter constraint conditions, perform resource-aware parameter compression on the decision branch network of the optimized dynamic protection model to generate a lightweight dynamic protection model.

[0175] In an optional example, the parameter compression can adopt a hybrid strategy of structured pruning and quantization. For example, apply channel pruning to the convolutional layer of the traffic blocking branch to remove filters with a contribution degree lower than 10%; implement weight sharing for the LSTM layer of the access control branch and quantize 32-bit floating-point parameters to 8-bit fixed-point numbers; the reinforcement learning policy network of the data encryption branch adopts knowledge distillation to transfer the output probability of the complex policy network (teacher model) to the lightweight network (student model). The effectiveness retention rate of the compressed model is verified through adversarial sample testing. For example, the threat detection F1-score of the pruned model on the test set drops from 0.92 to 0.89, meeting the minimum requirement of ≥0.85. Finally, a lightweight model file (such as model_v2.1.3_lite.weights) is generated, and its volume is reduced to 40% of the original model.

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

[0177] In an optional example, the resource isolation sandbox can be implemented based on cgroups and namespace technologies, and exclusive CPU cores (such as cores 0-1), memory ranges (such as 512MB-1GB), and network bandwidth quotas (such as 50Mbps) are allocated for the lightweight model. The sandbox file system is constructed through OverlayFS and includes the lightweight model file, dependent libraries, and a minimized runtime environment. After the model is loaded, the processes in the sandbox run as non-privileged users, restricting their system call permissions (such as disabling execve), and intercepting high-risk operations through seccomp filters. The resource view of the sandbox is isolated from the host. For example, the number of CPU cores visible in the sandbox is 2, decoupled from the actual physical cores.

[0178] Step S5016: Execute the protection policy of the lightweight dynamic protection model through the resource isolation sandbox and collect the resource occupancy fluctuation data and policy stability indicators during the policy execution process.

[0179] In an alternative example, the resource occupancy fluctuation data includes the CPU core utilization rate of the processes within the sandbox (e.g., the utilization rate of core 0 is 75%), the memory page fault rate (e.g., 200 times per second), and the network packet processing rate (e.g., 8000 pps). The policy stability index is calculated by the control chart method. For example, the moving range (MR) of the number of misinterceptions per hour is statistically analyzed. When three consecutive points exceed the 2σ control limit, it is determined to be unstable. Data collection uses eBPF probe technology to capture system calls and resource events of sandbox processes in the kernel state in real time, avoiding the performance overhead of user-state collection. For example, the mmap / munmap call times of the memory allocator (such as jemalloc) are traced through a bpftrace script.

[0180] Step S5017: If the resource occupancy fluctuation data exceeds the preset security threshold of the resource isolation sandbox, trigger a resource expansion request to dynamically allocate additional resources to the resource isolation sandbox.

[0181] In an alternative example, the security threshold can be set hierarchically based on the resource type. For example, the CPU core utilization rate threshold is set to 90%, the memory occupancy threshold is set to 95% of the allocation upper limit, and the network bandwidth threshold is set to 85% of the quota value. When the CPU usage rate of the processes within the sandbox exceeds 90% and lasts for 10 seconds, the resource scheduler dynamically appends CPU core quotas through API calls (e.g., increasing from 2 cores to 3 cores) and takes effect in real time through cgroups. The expansion follows the principle of minimum increment. For example, each time 0.5 cores are added (implemented through the CPU share ratio) until the resource occupancy drops back to the safe zone. The historical expansion records form an elastic policy library. For example, a certain edge node needs to stably allocate 3.5 cores of CPU during peak business hours.

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

[0183] In an alternative example, the parameter compression ratio can be dynamically adjusted by a PID controller. For example, when the policy stability index (such as the variance of the misinterception rate) exceeds the threshold, the compression constraint is gradually relaxed (e.g., allowing the LSTM hidden layer dimension to recover from 128 to 192), while monitoring whether the resource consumption exceeds the expansion capacity. The final model version selects the configuration that meets the stability requirements and has the lowest resource occupancy. For example, the combination scheme of a hidden layer dimension of 160, 8-bit quantization + pruning rate of 30% is selected. After the model is solidified, the sandbox process terminates gracefully, releasing the occupied CPU cores and memory resources, and the log files are archived to the audit database. The final protection model is deployed to all asset business nodes through the formal release process to complete the resource-adaptive closed loop.

[0184] Figure 2The figure is a schematic diagram of the hardware entity of a network security protection system provided by an embodiment of the present invention. As Figure 2 shown, the hardware entity of the network security protection system 1000 includes: a processor 1001 and a memory 1002. Among them, the memory 1002 stores a computer program that can run on the processor 1001, and when the processor 1001 executes the program, it implements the steps in the method of any of the above embodiments.

[0185] The above is only the implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention can easily think of changes or substitutions, which should all be covered within the protection scope of the present invention.

Claims

1. A network security protection method applied to regional digital intelligence asset business, characterized in that, The method includes: Collecting asset data streams of multiple asset business nodes within a target area, where the asset data streams include business operation behavior characteristics, data interaction characteristics, and asset attribute characteristics; Based on a preset threat knowledge graph, extracting threat characteristics from the asset data streams to generate dynamic threat feature vectors corresponding to the asset business nodes; Inputting the dynamic threat feature vectors into a pre-trained dynamic protection model, and outputting real-time protection policies adapted to the asset business nodes through a multi-layer decision network in the dynamic protection model; Executing policies on the network traffic of the asset business nodes based on the real-time protection policies, generating policy execution results and feeding them back to the dynamic protection model; Adapting and optimizing the decision parameters of the dynamic protection model according to the policy execution results, generating an updated dynamic protection model for the next round of protection decisions of the asset business nodes.

2. The method according to claim 1, wherein The collecting asset data streams of multiple asset business nodes within a target area includes: Obtaining the business level classification information of the asset business nodes, where the business level classification information includes core asset nodes, edge asset nodes, and transit asset nodes; According to the business level classification information, respectively setting a first collection frequency for the core asset nodes, a second collection frequency for the edge asset nodes, and a third collection frequency for the transit asset nodes, where 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 of the asset business nodes, capturing the original data packets in its network transmission protocol according to the corresponding collection frequency, and performing protocol parsing on the original data packets to extract the business operation behavior characteristics, data interaction characteristics, and asset attribute characteristics; Aligning the feature data of multiple asset business nodes collected within the same time window in terms of time and space to generate an asset data stream set with consistent timestamps; Filtering out noise and removing outliers from 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 characteristics from the asset data streams based on a preset threat knowledge graph to generate dynamic threat feature vectors corresponding to the asset business nodes includes: 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; Matching the business operation behavior characteristics in the asset data streams with the threat behavior pattern nodes to identify potential threat operation sequences; Calculating the vulnerability exposure probability of each asset business node according to the correlation degree between the data interaction characteristics and the vulnerability exploitation path nodes; Generating attack surface evaluation parameters of the asset business nodes by combining the mapping relationship between the asset attribute characteristics and the attack pattern nodes; Performing vectorized splicing on the potential threat operation sequences, vulnerability exposure probabilities, and attack surface evaluation parameters to generate dynamic threat feature vectors containing multi-dimensional threat dimensions.

4. The method according to claim 3, wherein Inputting the dynamic threat feature vector into a pre-trained dynamic protection model, and outputting a real-time protection policy adapted to the asset business node through a multi-layer decision network in the dynamic protection model, including: Invoking a feature distribution layer in the dynamic protection model to split the dynamic threat feature vector into multiple sub-feature segments according to threat dimensions; Inputting 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; Performing in-depth protocol analysis on abnormal traffic features through the traffic blocking branch to generate traffic filtering rules and blocking thresholds; Performing dynamic verification on user permission features through the access control branch to generate an access control list based on session tokens; Matching encryption algorithms for sensitive data features through the data encryption branch to generate key rotation strategies and encryption strength parameters; Aggregating the output rules of each decision branch network to generate a set of real-time protection policies including priority weights.

5. The method according to claim 4, characterized in that, Performing policy execution on the network traffic of the asset business node based on the real-time protection policy, generating a policy execution result and feedbacking it to the dynamic protection model, including: Sorting the execution order of the traffic filtering rules, access control list, and key rotation strategy according to the priority weights in the set of real-time protection policies; Injecting a policy execution agent at the network interface layer of the asset business node, and the policy execution agent sequentially performs traffic filtering, permission verification, and data encryption operations according to the execution order; Real-time monitoring the execution status of the policy execution agent, capturing the network traffic change features and security event logs during the policy effectiveness period; Extracting the policy response delay, threat interception success rate, and resource occupancy rate in the network traffic change features to generate policy effectiveness indicators; Performing correlation analysis on the security event logs and the policy effectiveness indicators to generate a policy execution result including policy correction suggestions.

6. The method according to claim 5, characterized in that Adapting and optimizing the decision parameters of the dynamic protection model according to the policy execution result, generating an updated dynamic protection model for the next round of protection decision-making for the asset business node, including: Analyzing the policy correction suggestions in the policy execution result, and extracting the decision branch network identifiers to be optimized and the parameter adjustment directions; 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 adjusting the verification frequency of session tokens based on the resource occupancy rate, and optimizing the matching algorithm of the access control list; For the data encryption branch, reselecting the target algorithm in the encryption algorithm library according to the balance relationship between the encryption strength parameter and the data processing delay; Synchronizing the parameters of each optimized decision branch network to generate an updated dynamic protection model with version iteration, and writing the update log into the model version library.

7. The method according to claim 6, characterized in that The pre-training process of the dynamic protection model includes the following steps: Construct a training dataset for historical asset business nodes, where the training dataset includes normal business traffic samples, known attack traffic samples, and mixed traffic samples; Perform feature enhancement processing on the training dataset to generate an enhanced dataset containing spatio-temporal perturbation features; Initialize the network weights of the dynamic protection model and set a multi-task learning objective function, where the multi-task learning objective function includes threat classification loss, policy generation loss, and resource consumption loss; 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; Determine the final model parameters through an early stopping mechanism and cross-validation to generate a pre-trained dynamic protection model.

8. The method according to claim 7, wherein The performing feature enhancement processing on the training dataset to generate an enhanced dataset containing spatio-temporal perturbation features includes: Add a random time offset to the normal business traffic samples to simulate traffic fluctuations during different business peak periods; Insert noise data packets into the known attack traffic samples to generate adversarial samples with obfuscation features; Mutate the protocol fields of the mixed traffic samples to generate protocol compatibility test samples; Combine the time-offset normal samples, adversarial samples, and protocol-mutated samples to generate the enhanced dataset; Label each sample in the enhanced dataset with multi-dimensional threat labels and recommended protection policy labels.

9. The method according to claim 6, wherein The method further includes a process of performing dual-channel verification during the policy execution process, including: While the local protection agent at the asset business node executes the real-time protection policy, send 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 correction instruction; If the local protection agent detects an execution result conflicting with the policy correction instruction, trigger a protection policy rollback mechanism and load the previous version of the dynamic protection model; When the verification results of the local protection agent and the cloud verification server are consistent, update the local policy cache and confirm that the current protection policy is effective; Among them, the triggering the protection policy rollback mechanism and loading the previous version of the dynamic protection model includes: Retrieve the historical model version compatible with the current asset business node from the model version library; Compare the adaptability of the decision parameters of the historical model version with the current environmental features and select 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; Re-initialize the policy execution agent and generate an alternative protection policy based on the rolled-back model parameters; After the alternative protection policy takes effect, send a rollback completion notice to the cloud verification server and start a model difference analysis task to locate the reason for the original policy conflict.

10. A network security protection system, comprising a memory and a processor, wherein the memory stores a computer program that can run on the processor, characterized in that, When the processor executes the program, it implements the steps in the method according to any one of claims 1 to 9.

Images