A security policy-based network security operation method

Abstract

This application discloses a network security operation method based on security policies, aiming to solve the problems of slow response and rigid policies in traditional static defense mechanisms. The method includes: collecting entity behavior data and policy metadata, and constructing a policy tracing graph after preprocessing; training a trust assessment model based on behavioral features, calculating entity trust scores in real time and integrating them into graph nodes; defining a propagation control policy, automatically limiting the propagation range of associated policies to high-risk isolation zones when the trust score is lower than a security threshold; monitoring trust score fluctuations, and triggering tracing analysis if the tolerance is exceeded, and pre-deploying control points along the graph path; by integrating behavioral trust assessment and policy tracing propagation, a shift from passive response to proactive pre-control is achieved, significantly improving threat suppression efficiency and system adaptive defense capabilities.

Description

Technical Field

[0001] This invention relates to the field of computer network security technology, and in particular to a network security operation method based on security policies. Background Technology

[0002] Current cybersecurity operations generally employ static policy-based defense mechanisms, the core of which involves filtering and controlling network traffic through predefined security rules. This traditional approach relies heavily on the fixed policy configurations of security devices (such as firewalls and intrusion detection systems), lacking the ability to dynamically perceive entity behavior. In practical applications, it has been found that static policies struggle to adapt to increasingly complex network attack methods, particularly lagging behind in scenarios such as zero-day vulnerabilities and advanced persistent threats. Because policy updates depend on manual intervention, response delays often occur, leading to time windows of vulnerability in security protection. Furthermore, existing technologies lack systematic modeling of the relationships between policies, making it impossible to effectively track the propagation paths of security incidents. This results in protective measures often remaining at a single-point level, failing to form a systematic security protection capability.

[0003] On the other hand, existing network security operation systems have significant shortcomings in handling policy propagation and resource allocation. Most systems employ triggering mechanisms based on fixed thresholds, lacking the ability to adapt to dynamic changes in the network environment. When faced with large-scale concurrent policy execution, resource contention issues easily arise, causing critical security policies to fail to take effect in a timely manner. Simultaneously, traditional methods for trust assessment of entity behavior are relatively simple, typically based on single-dimensional indicators, failing to comprehensively consider the multi-dimensional characteristics of behavioral features. This assessment method has limited accuracy, is prone to misjudgments, and consequently affects the effectiveness of security policy execution. Furthermore, existing technologies lack effective policy attribution mechanisms, making it difficult to provide complete decision-making basis for security incident analysis, thus hindering further improvements in security operation efficiency. Summary of the Invention

[0004] This application provides a network security operation method based on security policies, which realizes the transformation from passive response to proactive prevention and control, and significantly improves threat suppression efficiency and system adaptive defense capabilities.

[0005] This application provides a network security operation method based on security policies, including:

[0006] S1: Collect entity behavior data and policy metadata in a given network system, extract behavioral features after standardized preprocessing, and transform the policy metadata into a node and edge format that can be recognized by the policy tracing graph.

[0007] S2, Based on the extracted behavioral features, train a trust assessment model to construct a policy tracing graph and calculate the trust score of each user entity in real time; integrate the trust score as a node attribute into the graph and associate it with the corresponding policy node;

[0008] S3 defines a propagation control strategy. When an entity's trust score is lower than the security threshold, a control mechanism is automatically triggered to limit the propagation scope of the entity's associated strategy, allowing it to propagate only to high-risk isolation areas.

[0009] S4 monitors the fluctuation of trust scores. If the fluctuation exceeds the preset tolerance, it triggers propagation calculation. It traces the accident path according to the strategy source map and pre-deploys control points along the source path.

[0010] Preferably, the association of corresponding policy nodes specifically includes: using extracted behavioral features as training data, constructing a trust evaluation model using a supervised learning algorithm; initializing a directed graph model based on the node and edge structure after policy metadata transformation; wherein nodes represent policy instances, edges represent dependencies, and edge weights are calculated based on historical co-occurrence frequencies; inputting real-time collected user entity behavior data into the trained trust evaluation model, and calculating the trust score of each entity through forward propagation; adding a trust score attribute to each policy node according to the mapping relationship between user entities and policy nodes, and updating the node attribute table of the graph.

[0011] Preferably, the trust score includes: a trust score calculation formula employing a linear weighted model, based on the aggregation of behavioral characteristics deviating from a benchmark; the formula is defined as:

[0012]

[0013] The trust score represents the entity, with a value range of [0,1]; k is the number of behavioral features; Let be the current observation value of the i-th feature; Let be the mean of the i-th feature in the historical dataset, representing the baseline of normal behavior; Let be the standard deviation of the i-th feature in the historical dataset, used to measure the range of feature fluctuation; The weight of the i-th feature is determined through model training, reflecting the importance of this feature in trust assessment, and satisfies... .

[0014] Preferably, the pre-deployment of control points along the tracing path specifically includes: real-time collection of the trust score sequence of each entity; calculation of short-term fluctuation indicators using sliding window technology; setting the monitoring frequency to a high-frequency interval and setting a fluctuation tolerance threshold, wherein the tolerance is twice the standard deviation of the score or a dynamic threshold based on percentiles; when the fluctuation indicator exceeds the tolerance for multiple consecutive monitoring periods, it is determined to be an abnormal fluctuation event; after confirming an abnormal fluctuation event, calling the propagation calculation engine, taking the policy tracing graph as input, and starting the path analysis algorithm to calculate the potential risk propagation path starting from the policy node associated with the abnormal entity; traversing the graph nodes and edges to identify all reachable paths, and prioritizing paths with high edge weights or frequent historical vulnerabilities; generating a directed subgraph from the path tracing results, and marking key nodes and propagation directions; and deploying virtual control points at the policy dependency intersection points of the path according to the tracing results.

[0015] Preferably, the step of tracing the incident path based on the strategy source map specifically includes: S41, by real-time monitoring of network resource usage status and establishing a resource demand prediction model, quantifying the resource consumption characteristics of each strategy propagation path, and constructing a basic scheduling model under resource constraints; S42, based on the strategy criticality level and real-time entity trust score, dynamically generating scheduling weights using a weighted calculation model; S43, designing a distributed event-driven scheduler architecture, performing real-time path priority ranking and resource allocation based on resource constraints and dynamic weights, and executing scheduling decisions through API commands.

[0016] Preferably, step S43 further includes: constructing a hierarchical distributed scheduling framework, which includes a master scheduling node for global coordination and local schedulers deployed at the edge, and activating the scheduling process using an event-driven model; when resource contention or new path requests are detected, prioritizing policy paths based on dynamic weights and allocating resources to high-priority paths through a resource allocation algorithm; when resources are insufficient, borrowing or delaying mechanisms are used for low-priority paths, and scheduling decisions are converted into network control commands through API instructions and issued.

[0017] Preferably, the distributed event-driven scheduler architecture includes: S employing distributed resource monitoring and load forecasting technology, deploying lightweight agents and time-series models to perceive the resource status of the entire network in real time and predict load trends; dividing the network into multiple scheduling domains, dynamically electing a dominant scheduler based on load status; each local scheduler generating a resource allocation proposal based on local resource status and forecast data, and reaching a consensus allocation scheme through a coordination protocol; synchronizing the consensus allocation scheme to all schedulers through a version control mechanism, with the schedulers caching the scheme locally and preparing for execution; defining an elastic scaling threshold, dynamically adjusting resource allocation based on load forecast results to achieve elastic scaling.

[0018] Preferably, the consensus allocation scheme reached through the collaborative protocol specifically involves: dividing the global network into multiple independent scheduling domains based on the network topology and business logic boundaries, with each scheduling domain covering a group of nodes with close resource dependencies; each scheduling domain periodically collecting load status indicators of nodes within the domain, calculating health scores based on real-time load data of nodes, and selecting a dominant scheduler; after the election, the local scheduler integrates predicted load trends and real-time monitoring indicators to analyze the resource supply and demand situation of its domain; entering the collaborative consensus phase, the dominant scheduler is responsible for coordinating the review of proposals within the domain; after the consensus scheme is generated, the dominant scheduler synchronizes the final allocation result to all nodes within the domain.

[0019] Preferably, dividing the network into multiple scheduling domains includes: collecting policy metadata from each domain to establish a multi-domain policy feature library; collecting key events of policy propagation across scheduling domains in real time; preprocessing the heterogeneous data collected from each domain, associating records from different data sources pointing to the same policy or the same entity to form a complete propagation chain; using trust scores as confounding variable nodes in the propagation chain, and automatically constructing an initial causal graph based on historical propagation data using a causal discovery algorithm; when a security event is detected, automatically capturing the complete context of the event and extracting relevant data within a time window before the event occurs, extracting relevant subgraphs from the global causal graph based on the context of the security event; performing counterfactual analysis on each candidate cause node in the subgraph to determine the root cause node, determining the location of the root cause node in the policy tracing graph, confirming the node as a cross-domain problem node, and generating targeted optimization strategies.

[0020] Preferably, identifying the node as a cross-domain problem node specifically includes: performing counterfactual analysis on each candidate cause node in the subgraph to first construct the actual observed propagation path; for each candidate cause, simulating a counterfactual scenario if the cause did not occur, and recalculating the probability of the security event by intervening in the causal graph; comparing the difference between the actual probability and the counterfactual probability to calculate the causal effect value of the candidate cause; the node with the largest causal effect value is identified as the root cause node; based on the position and attributes of the root cause node in the strategy tracing graph, automatically determining its type, identifying the node as a cross-domain problem node, and generating a targeted optimization strategy.

[0021] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0022] By integrating behavioral trust assessment with policy attribution and propagation mechanisms, this method upgrades cybersecurity operations from passive response to proactive prevention. It dynamically senses entity behavioral risks, automatically triggers precise policy propagation control, and effectively curbs threat spread. Simultaneously, through quantitative assessment and closed-loop optimization, it significantly improves defense efficiency, reduces false alarm rates, and enhances the system's adaptability to new threats, providing efficient and intelligent security for complex network environments.

[0023] By introducing a resource-aware fair scheduling framework, the resource contention problem during concurrent execution of multiple policy propagation paths is effectively solved, based on accurate risk path tracing. Resources are dynamically allocated according to policy criticality and real-time trust scores, significantly improving the propagation efficiency of high-priority policies. Simultaneously, a fairness guarantee mechanism prevents resource starvation on low-trust paths, achieving synergistic optimization of network resource utilization and security protection effectiveness, and enhancing the system's stability and adaptability under complex, high-load scenarios.

[0024] By constructing a distributed collaborative scheduling and elastic scaling mechanism, this solution effectively addresses the bottlenecks of multi-regional resource contention and single-point scheduling in large-scale network environments. Based on load prediction and dynamic thresholds, the scheme achieves intelligent elastic scaling of resources, significantly optimizing resource utilization efficiency. A distributed consensus protocol ensures collaborative decision-making among multiple schedulers, resolving consistency issues in resource allocation. Combined with elastic resource pool management and state transition technology, it effectively guarantees the continuity of policy propagation. This method demonstrates excellent adaptability in complex network environments, significantly improves fault recovery capabilities, and effectively enhances the overall robustness and operational efficiency of the security operation system.

[0025] By constructing a unified modeling and causal reasoning mechanism for cross-domain policies, this solution effectively addresses the challenges of policy coordination and security event diagnosis in heterogeneous network environments. The scheme achieves semantic alignment and lossless transformation of cross-domain policies, significantly improving policy execution consistency. Through causal graph construction and counterfactual analysis, it enables precise location and automated diagnosis of the root causes of security events, greatly improving fault handling efficiency. The system possesses adaptive optimization capabilities, dynamically adjusting policy parameters based on diagnostic results to enhance the overall intelligence and reliability of security protection. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a network security operation method based on a security policy, according to an embodiment of the present invention. Detailed Implementation

[0027] To facilitate understanding of the present invention, a more complete description of this application will be given below with reference to the accompanying drawings, which illustrate preferred embodiments of the invention. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to enable a more thorough and complete understanding of the disclosure of the present invention.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains; the terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to limit the invention; the term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0029] Example 1: Figure 1 This is a flowchart illustrating a network security operation method based on a security policy according to an embodiment of the present invention.

[0030] like Figure 1 As shown, a network security operation method based on security policies includes the following steps:

[0031] S1 collects entity behavior data and policy metadata in a given network system, performs standardized preprocessing to extract behavioral features, and transforms the policy metadata into a node and edge format that can be recognized by the policy tracing graph.

[0032] Entity behavior data refers to the sequence of behavior records of entities (user accounts, device identifiers) in the network system, including login timestamps, resource access paths, API call frequencies, network traffic patterns, etc. Policy metadata refers to descriptive information about security policies, including policy identifiers, rule conditions (allowed IP ranges), dependencies (policy A requires policy B to be enabled first), and effective time periods. Entity behavior data and policy metadata are collected from the network system's log server, security devices (firewalls, intrusion detection systems), and policy configuration library. Behavioral data is obtained in the form of event streams, and metadata is exported through the policy management interface.

[0033] Statistical and temporal features are extracted from the preprocessed behavioral data. The mean, variance, and entropy of the behavioral sequences are calculated. The policy metadata is mapped to a directed graph structure, where nodes represent policy instances and edges represent dependencies between policies. Node attributes (policy ID, rule content) are defined, and edge attributes are weighted based on dependency strength using the following formula:

[0034]

[0035] in, Let i be the edge weight from policy i to policy j. This represents the number of times both functions have been active simultaneously in history. The final graph G=(V,E) is constructed, where V is the set of nodes and E is the set of edges.

[0036] S2: Based on the extracted behavioral features, a trust assessment model is trained to construct a strategy tracing graph, and the trust score of each user entity is calculated in real time. The trust score is integrated into the graph as a node attribute and associated with the corresponding strategy node.

[0037] Specifically, extracted behavioral features are used as training data, and a supervised learning algorithm is employed to construct a trust assessment model. The model training process includes parameter initialization, loss function optimization, and iterative updates until it converges to a stable state, generating a prediction function that can output trust scores.

[0038] A directed graph model is initialized based on the node and edge structure transformed from policy metadata. Nodes represent policy instances, edges represent dependencies, and edge weights are calculated based on historical co-occurrence frequencies. Graph construction includes topological sorting and connectivity verification to ensure the acyclicity and integrity of dependencies.

[0039] Real-time collected user entity behavior data is input into a trained trust assessment model, and a trust score for each entity is calculated through forward propagation. The score range is [0,1], where 0 represents completely untrustworthy and 1 represents highly trustworthy. A sliding time window mechanism is introduced in the calculation process to consider only recent behavior data to maintain timeliness.

[0040] The calculated trust score is associated as an attribute with the corresponding policy node. Specifically, based on the mapping relationship between user entities and policy nodes (the policy to which the entity belongs), a trust score attribute is added to each policy node, and the node attribute table of the graph is updated. After integration, the graph nodes contain policy metadata and real-time trust status.

[0041] The trust score calculation formula employs a linear weighted model, based on the aggregation of behavioral characteristics' deviations from the baseline. The formula is defined as follows:

[0042]

[0043] The trust score represents the entity, with a value range of [0,1]; k is the number of behavioral features; Let be the current observation value of the i-th feature; Let be the mean of the i-th feature in the historical dataset, representing the baseline of normal behavior; Let be the standard deviation of the i-th feature in the historical dataset, used to measure the range of feature fluctuation; The weight of the i-th feature is determined through model training, reflecting the importance of this feature in trust assessment, and satisfies... .

[0044] S3 defines a propagation control strategy. When an entity's trust score is lower than the security threshold, a control mechanism is automatically triggered to limit the propagation scope of the entity's associated strategy, allowing it to propagate only to high-risk isolation areas.

[0045] Specifically, a security threshold for trust scoring is defined based on the distribution of historical behavioral data and risk tolerance. The trust score stream for each entity is acquired in real time, and an event monitoring mechanism ensures timely score updates. The monitoring process employs a sliding window technique to calculate the average or trend of recent scores, avoiding interference from momentary fluctuations.

[0046] When the trust score falls below the security threshold, a propagation control strategy is automatically triggered. Based on the policy origination graph, all policy nodes associated with the entity are identified. By modifying graph edge weights or adding virtual boundaries, the propagation path is restricted to a local area. Specifically, only policy changes or risk signals are allowed to propagate to predefined high-risk isolation zones (logical partitions within the network); other paths are temporarily blocked.

[0047] The security threshold is set based on the historical distribution of trust scores and business risk appetite. Typically, the threshold range is set in the lower percentile of the trust score range; for example, if the trust score range is [0,1], the security threshold can be set between 0.2 and 0.4. The specific value is calculated using statistical methods, such as using the 10th percentile (P10) of historical score data or the mean minus 1.5 times the standard deviation (μ-1.5σ), to ensure that the threshold covers most abnormal situations.

[0048] S4 monitors the fluctuation of trust scores. If the fluctuation exceeds the preset tolerance, it triggers propagation calculation. It traces the accident path according to the strategy source map and pre-deploys control points along the source path.

[0049] Specifically, the trust score sequence for each entity is collected in real time, and a sliding window technique is used to calculate a short-term volatility index (the monitoring frequency is set to a high-frequency interval (every 30 seconds)). A tolerance is set at twice the standard deviation of the score or a dynamic threshold based on percentiles. When the volatility index exceeds the tolerance value for three consecutive monitoring periods, it is determined to be an abnormal volatility event.

[0050] Once the abnormal fluctuation is confirmed, the propagation calculation engine is invoked. This engine takes the policy tracing graph as input and initiates a path analysis algorithm (breadth-first search) to calculate potential risk propagation paths originating from the policy nodes associated with the abnormal entity. It traverses the graph nodes and edges, identifies all reachable paths, and prioritizes high-risk paths (paths with high edge weights or frequent historical vulnerabilities). The path tracing results generate a directed subgraph, labeling key nodes and propagation directions.

[0051] Based on the tracing results, virtual control points are automatically deployed at key nodes where policy dependencies converge along the path. This includes inserting temporary access rules or traffic detection probes. Control point configuration is based on the path's risk level to ensure coverage of all potential spread directions.

[0052] The technical solutions described in the embodiments of this application have at least the following technical effects or advantages:

[0053] By integrating behavioral trust assessment with policy attribution and propagation mechanisms, this method upgrades cybersecurity operations from passive response to proactive prevention. It dynamically senses entity behavioral risks, automatically triggers precise policy propagation control, and effectively curbs threat spread. Simultaneously, through quantitative assessment and closed-loop optimization, it significantly improves defense efficiency, reduces false alarm rates, and enhances the system's adaptability to new threats, providing efficient and intelligent security for complex network environments.

[0054] Example 2: In Example 1, adaptive operation of security policies based on risk perception was achieved through dynamic evaluation of entity behavior trust and precise control of policy tracing paths. However, when multiple policy propagation paths need to be executed simultaneously in large-scale complex networks, this method mainly relies on behavior trust scores and policy criticality for priority ranking, failing to fully consider the actual carrying capacity and competition status of underlying network resources (such as bandwidth and computing resources). When multiple high-weight paths are concurrent, resource contention may lead to delays in the execution of critical policies or system overload, thereby affecting the real-time performance of risk control and overall operational efficiency. Furthermore, a unified path processing mechanism is difficult to differentiate scheduling based on the resource requirements of different paths under resource-constrained conditions, resulting in potential bottlenecks such as uneven resource allocation and limited system throughput.

[0055] In some embodiments, step S4 further includes tracing the incident path based on the strategy source map:

[0056] S41, by monitoring the network resource usage status in real time and establishing a resource demand prediction model, quantifies the resource consumption characteristics of each strategy propagation path, and constructs a basic scheduling model under resource constraints.

[0057] Specifically, a lightweight monitoring agent (based on the SNMP protocol) is deployed to monitor network resource usage in real time, continuously collecting key resource data, including metrics such as bandwidth, CPU utilization, memory usage, and latency. The monitoring agent periodically collects resource usage data and compares it with the total capacity to calculate the utilization percentage. All data is stored in a time-series database to support real-time queries and historical trend analysis.

[0058] After data collection, the next phase is the resource demand analysis of the strategy propagation path. For each strategy propagation path execution record in the historical data, key attributes such as path length, data packet size, and execution frequency are extracted. A resource demand prediction model is built using regression analysis. By analyzing the correlation between resource consumption and path characteristics during historical execution, a prediction function is constructed. For newly emerging propagation paths, their characteristic parameters are substituted into the trained model to output the expected resource demand estimate.

[0059] In terms of quantifying resource consumption characteristics, multi-dimensional statistical analysis is required for each strategy propagation path. The average resource consumption during path execution should be calculated to reflect its typical resource demand level. Peak resource usage should be analyzed to identify potential sudden resource demands.

[0060] Based on the above analysis, the physical constraints of network infrastructure are transformed into mathematical constraints, establishing a linear programming model framework. The capacity limits for various resources are defined, and the value ranges of resource allocation variables are set. A set of inequality constraints is constructed to ensure that the resource allocation scheme meets practical feasibility requirements. Finally, the model is validated and tested; its applicability is evaluated through backtesting with historical data and stress testing, completing the construction of the basic scheduling model.

[0061] S42 uses a weighted calculation model to dynamically generate scheduling weights based on the policy criticality level and real-time trust score of entities.

[0062] Specifically, in the criticality assessment phase of the initiation strategy, a criticality evaluation index system is constructed based on the value importance of the assets protected by the strategy and the functional level of the strategy type. For the security strategies associated with each strategy propagation path, a criticality score is calculated using a multi-factor weighted analysis method. Linear normalization is then applied to map the score to a continuous numerical range of zero to one, ensuring the comparability of the criticality levels of different strategies. The criticality score is calculated through a weighted sum:

[0063]

[0064] Assuming the asset value importance score is V, its value is calculated using an asset valuation model and normalized to [0,1], where 1 represents the highest asset value. The strategy type function level score is F, with a predefined level mapping based on the strategy type (e.g., blocking strategy assigned a value of 1, monitoring strategy assigned a value of 0.5, and alarm strategy assigned a value of 0.3), and normalized to the range of [0,1]. and These are the weighting coefficients for the importance of asset value and the functional level of strategy type, respectively, satisfying... (Usually set according to business needs, such as) , (This emphasizes the dominant role of asset value). C is the calculated criticality score, ranging from [0,1]. A higher score indicates a stronger strategic criticality.

[0065] After completing the criticality assessment, the real-time trust score integration phase begins. The latest trust score of the source entity triggering the current propagation path is obtained from step S2, and an adjustable parameter λ is introduced to balance the weight of the strategy's own importance and the current risk urgency in the decision-making process. In the dynamic scheduling weight calculation stage, a weighted fusion model is used to process the criticality score and trust score. The calculation formula is as follows: .

[0066] A fairness guarantee mechanism is implemented. By monitoring the path scheduling history, when a certain type of path is detected to have not been scheduled for a long time, a fairness factor is automatically introduced to temporarily increase its weight, so as to prevent uneven resource allocation and ensure that all paths have the opportunity to be executed.

[0067] S43 designs a distributed event-driven scheduler architecture that performs real-time path priority sorting and resource allocation based on resource constraints and dynamic weights, and executes scheduling decisions through API commands.

[0068] Specifically, the scheduler architecture was designed, constructing a layered distributed scheduling framework consisting of a global master scheduler node and multiple regional local schedulers. The master scheduler node is responsible for overall coordination and maintaining a global resource view, while the local schedulers are deployed at the network edge to handle resource allocation tasks within specific regions. The architecture adopts an event-driven pattern, activating the scheduling process by listening for resource state changes, weight update events, or path trigger signals.

[0069] When the scheduler detects a resource contention event (such as resource utilization exceeding a threshold) or a new path execution request, it initiates a decision generation process. First, it assesses the current network resource status, including real-time data on key indicators such as bandwidth and CPU utilization. Next, based on the dynamic scheduling weights calculated in step S42, all pending policy propagation paths are sorted in descending order to determine their priority. Subsequently, a resource allocation algorithm is applied, allocating available resources to high-priority paths while meeting resource constraints; if resources are insufficient, borrowing or delay mechanisms are used to handle the resource requests of low-priority paths, ensuring that critical paths are executed first.

[0070] After the decision is generated, the scheduler sends the resource allocation results to the execution layer via API commands. Specifically, the scheduling decision is translated into actionable network control commands, such as adjusting flow table priorities through a software-defined network controller or configuring resource queue parameters through a device management interface. Atomicity and consistency are ensured during command issuance to avoid inconsistencies caused by partial execution failures. Finally, the scheduler integrates monitoring and feedback mechanisms to track the effectiveness of decision execution in real time. The effectiveness of the scheduling decision is evaluated by collecting metrics such as path execution latency and changes in resource utilization; when anomalies (abnormal weighting or resource status) are detected, a rescheduling process is automatically triggered.

[0071] The technical solutions described in the embodiments of this application have at least the following technical effects or advantages:

[0072] By introducing a resource-aware fair scheduling framework, the resource contention problem during concurrent execution of multiple policy propagation paths is effectively solved, based on accurate risk path tracing. Resources are dynamically allocated according to policy criticality and real-time trust scores, significantly improving the propagation efficiency of high-priority policies. Simultaneously, a fairness guarantee mechanism prevents resource starvation on low-trust paths, achieving synergistic optimization of network resource utilization and security protection effectiveness, and enhancing the system's stability and adaptability under complex, high-load scenarios.

[0073] Example 3: In Example 2, by introducing a resource-aware fair scheduling framework, dynamic resource allocation based on policy criticality and entity trust scores for policy propagation paths effectively alleviated resource contention within a single region. However, this framework still falls short in handling large-scale distributed network environments. First, its hierarchical architecture of global master scheduler-local scheduler suffers from centralized dependency, with the master node potentially becoming a performance bottleneck and a single point of failure. Second, resource allocation based on static thresholds and linear programming models is ill-suited to sudden fluctuations in network load and dynamic differences in resource status between regions. Furthermore, the lack of efficient coordination mechanisms among local schedulers can lead to global-level decision conflicts or resource fragmentation when multiple scheduling domains simultaneously initiate resource requests.

[0074] In some embodiments, step S43, which designs the distributed event-driven scheduler architecture, further includes:

[0075] S431 employs distributed resource monitoring and load forecasting technology. By deploying lightweight agents and time-series models, it can perceive the status of network resources in real time and predict load trends.

[0076] Specifically, a lightweight monitoring agent is deployed across network nodes (including edge devices and cloud servers) to achieve distributed resource data collection. The agent collects local resource data at fixed intervals (every 10 seconds), covering core metrics such as bandwidth utilization, CPU utilization, memory usage, and network latency. The collected data is encapsulated in a standardized format, with timestamps and node identifiers appended to ensure traceability and consistency. The agent design adheres to low-power principles to minimize the impact on network performance.

[0077] After data collection is complete, the data aggregation and global status synchronization phase begins. The monitoring agent sends local data to regional aggregators, each responsible for covering multiple nodes within a specific physical or logical region. The aggregators utilize Distributed Hash Table (DHT) technology to achieve rapid data synchronization and consistency maintenance across regions. The aggregators periodically (every 30 seconds) perform data aggregation calculations, generating regional-level resource metrics (average bandwidth utilization, peak load), and persistently storing the aggregation results in a time-series database, forming a global resource status view.

[0078] Based on accumulated historical resource data, a load forecasting model was trained. A lightweight time-series forecasting algorithm (such as exponential smoothing) was employed to model resource usage trends. The model predicts resource demand changes for a specific future time period (5 to 10 minutes) by analyzing the periodicity and trend characteristics of indicators (such as bandwidth utilization). Model parameters are automatically updated every 24 hours based on the latest data to ensure predictive capabilities adapt to dynamic network changes. The load forecasting results generated during training are broadcast to all local schedulers in the network via an efficient message queue (MQTT protocol). Data compression technology is used to reduce network overhead during distribution, and a verification mechanism is introduced to ensure data transmission integrity.

[0079] S432 divides the network into multiple scheduling domains and dynamically elects a dominant scheduler based on load status. Each local scheduler generates a resource allocation proposal based on local resource status and prediction data, and reaches a consensus allocation scheme through a coordination protocol.

[0080] Specifically, based on the network topology and business logic boundaries, the global network is divided into multiple independent scheduling domains, each covering a group of nodes with close resource dependencies. Domain partitioning must comprehensively consider factors such as physical location, network latency, and business relevance to ensure optimal communication efficiency within each domain.

[0081] Based on the partitioning results, a dynamic election mechanism for the dominant scheduler is initiated. Each scheduling domain periodically collects load status metrics from nodes within that domain, including CPU utilization, memory usage, and network bandwidth consumption. The election algorithm employs a weighted scoring strategy, calculating a health score based on real-time node load data and selecting the node with the lightest load and most stable performance as the dominant scheduler. The election process is triggered every 5 minutes, and a heartbeat detection mechanism monitors the dominant scheduler's liveness in real time, automatically triggering a re-election in case of failure.

[0082] Following the election, each local scheduler enters the resource allocation proposal generation phase. The local scheduler integrates the resource forecast data and real-time monitoring indicators provided in step S431 to analyze the resource supply and demand situation within its domain. The proposal clearly indicates the type, quantity, and priority weight of the resource requirement, with priority determined by both the policy criticality level and trust score. After generation, a digital signature and timestamp are added to the proposal to ensure data integrity and timeliness.

[0083] Entering the consensus phase, the dominant scheduler is responsible for coordinating the review of proposals within the domain. A modified Paxos protocol is used for multi-round voting negotiation. First, the dominant scheduler initiates the aggregation and distribution of proposals to all participating nodes. Each node verifies the feasibility of the proposal based on local resource constraints and confirms the vote through digital signatures. When the number of valid votes exceeds a preset threshold, a consensus resource allocation scheme is formed. If consensus is not reached, the protocol initiates a backoff and retry mechanism, randomly delaying the process and re-initiating negotiation until agreement is reached.

[0084] After the consensus scheme is generated, the leading scheduler synchronizes the final allocation results to all nodes within the domain. The synchronization process employs version control to ensure that each node obtains the latest and most valid scheme. The scheme includes resource allocation mapping relationships, execution time windows, and rollback contingency plans, providing a complete execution basis for subsequent resource scheduling.

[0085] S433 synchronizes the consensus-reached allocation scheme to all schedulers through a version control mechanism, and the schedulers cache the scheme locally and prepare for execution.

[0086] S434 defines the elastic scaling threshold, which dynamically adjusts resource allocation based on load forecasting results to achieve elastic scaling.

[0087] The elastic scaling threshold is defined based on historical resource usage data and business strategy requirements, with differentiated thresholds set for different resource types. For example, for bandwidth resources, by analyzing historical peak load and business continuity requirements, the expansion threshold is set to 85% (i.e., resource expansion is triggered when bandwidth utilization exceeds 85%), and the contraction threshold is set to 40% (i.e., resource release is triggered when utilization falls below 40%). Threshold settings also need to consider the criticality of the strategy; highly critical strategies (such as real-time defense) use stricter thresholds (e.g., an expansion threshold of 80%) to prioritize resource availability. After defining the thresholds, resource allocation is dynamically adjusted based on the load forecast results from step S431. When the forecast shows an upward trend in load, the system triggers the expansion mechanism in advance, allocating additional resources from the shared resource pool (such as increasing bandwidth quotas or computing instances); conversely, when the forecast shows a decrease in load, the contraction process is automatically initiated, releasing idle resources back to the pool. Resource adjustment decisions incorporate the principle of weighted fairness, prioritizing the needs of high-weight strategy paths and ensuring the continuity of strategy propagation through state transition technology.

[0088] It should be noted that the threshold definition process is calibrated using statistical methods (percentile analysis) and dynamically adjusted in conjunction with a real-time load prediction model to ensure that the threshold can adapt to network changes.

[0089] The technical solutions described in the embodiments of this application have at least the following technical effects or advantages:

[0090] By constructing a distributed collaborative scheduling and elastic scaling mechanism, this solution effectively addresses the bottlenecks of multi-regional resource contention and single-point scheduling in large-scale network environments. Based on load prediction and dynamic thresholds, the scheme achieves intelligent elastic scaling of resources, significantly optimizing resource utilization efficiency. A distributed consensus protocol ensures collaborative decision-making among multiple schedulers, resolving consistency issues in resource allocation. Combined with elastic resource pool management and state transition technology, it effectively guarantees the continuity of policy propagation. This method demonstrates excellent adaptability in complex network environments, significantly improves fault recovery capabilities, and effectively enhances the overall robustness and operational efficiency of the security operation system.

[0091] Example 4: In Example 3, a distributed collaborative scheduling and elastic scaling mechanism was constructed to effectively address the issues of multi-domain resource contention and dynamic load. However, this mechanism still has significant shortcomings when facing complex security operation scenarios across heterogeneous domains: First, its scheduling and scaling decisions are mainly based on resource status and load prediction, without considering the heterogeneity of policy definitions, protocols, and execution environments between different domains, which may lead to semantic ambiguity and execution deviations during cross-domain policy propagation; Second, when a security incident occurs, the system struggles to quickly pinpoint the root cause, which may stem from a single or compound factor among resource contention, policy conversion errors, behavioral trust model biases, or cross-domain dependency defects, lacking a unified causal analysis framework for accurate attribution and diagnosis; Finally, a closed loop is not formed between resource scheduling, policy execution, and problem diagnosis, causing policy optimization to rely on manual experience and preventing automated policy tuning based on root cause analysis.

[0092] In some embodiments, step S432, which divides the network into multiple scheduling domains, further includes:

[0093] 2A. Collect policy metadata from each domain to establish a multi-domain policy feature library and collect key events of policy propagation across scheduling domains in real time.

[0094] Specifically, automatic scanning technology is used to collect policy definition metadata for each scheduling domain, including policy language, protocol format, and execution environment characteristics. Natural language processing and pattern recognition technologies are employed to extract core policy elements (such as subject, object, action, and condition), and a multi-domain policy feature library is constructed. This feature library supports standardized indexing and semantic querying of policy elements. Simultaneously, lightweight agents are deployed at key nodes in each domain to monitor and collect key policy propagation events in real time at fixed intervals (e.g., every 10 seconds), including policy issuance events, inter-domain transition events, and policy execution events. Event data is appended with timestamps, domain identifiers, and policy identifiers to ensure data traceability and consistency. The agents employ a low-power design to minimize the impact on network performance.

[0095] 2B involves preprocessing heterogeneous data collected from various domains and then associating records from different data sources that point to the same strategy or entity to form a complete propagation chain.

[0096] Specifically, the collected heterogeneous data (such as logs, metrics, and alarms) is cleaned and normalized to eliminate inconsistencies in format and noisy data. Based on entity resolution technology, records involving the same policy or entity (such as users or devices) from different data sources are associated, and a complete cross-domain policy propagation chain is constructed through unique identifier mapping and similarity calculation.

[0097] 2C uses trust scores as a confounding variable node in the propagation chain and applies a causal discovery algorithm to automatically construct an initial causal graph based on historical propagation data.

[0098] Specifically, the acquired trust scores are integrated into the propagation chain as confounding variable nodes, associating them with relevant users, devices, or session nodes to characterize the potential impact of behavioral risks on policy propagation. Based on historical propagation data, a causal discovery algorithm is applied to automatically construct an initial causal graph. The nodes in the graph include policy event nodes (issuance, transformation, execution), state nodes (such as resource load, network latency), and result nodes (such as security events). Edges represent causal dependencies, and the weights of the edges represent the causal strength.

[0099] In 2D, when a security event is detected, the complete context of the event is automatically captured, and relevant data within a window for a period of time before the event occurs is extracted. Based on the context of the security event, relevant subgraphs are extracted from the global cause-effect graph.

[0100] The complete context includes: event type, occurrence time, affected area, associated policy chain, and related entities (users, devices); related data includes changes in trust scores and resource usage. The subgraph contains nodes and edges directly or indirectly connected to the event, focusing on potential causal paths that may have led to the event.

[0101] 2E: Perform counterfactual analysis on each candidate cause node in the subgraph to determine the root cause node, locate the root cause node in the strategy tracing graph, identify the node as a cross-domain problem node, and generate a targeted optimization strategy.

[0102] Specifically, counterfactual analysis is performed on each candidate cause node in the subgraph: First, the actual observed propagation path is constructed; then, for each candidate cause, a counterfactual scenario is simulated if the cause had not occurred, and the probability of the security event is recalculated by intervening in the causal graph (e.g., deleting a node or modifying a node value); finally, the difference between the actual probability and the counterfactual probability is compared to calculate the causal effect value of the candidate cause. The node with the largest causal effect value is identified as the root cause node. Based on the location and attributes of the root cause node in the policy causal graph, its type is automatically determined (e.g., behavioral trust model bias, policy dependency defect, cross-domain conversion error, or resource contention), and the node is identified as a cross-domain problem node, generating targeted optimization strategies, such as adjusting trust model parameters, modifying policy rules, or reallocating resources.

[0103] The technical solutions described in the embodiments of this application have at least the following technical effects or advantages:

[0104] By constructing a unified modeling and causal reasoning mechanism for cross-domain policies, this solution effectively addresses the challenges of policy coordination and security event diagnosis in heterogeneous network environments. The scheme achieves semantic alignment and lossless transformation of cross-domain policies, significantly improving policy execution consistency. Through causal graph construction and counterfactual analysis, it enables precise location and automated diagnosis of the root causes of security events, greatly improving fault handling efficiency. The system possesses adaptive optimization capabilities, dynamically adjusting policy parameters based on diagnostic results to enhance the overall intelligence and reliability of security protection.

[0105] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. For those skilled in the art, the present invention can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A network security operation method based on a security policy, characterized by, include: S1: Collect entity behavior data and policy metadata in a given network system, extract behavioral features after standardized preprocessing, and transform the policy metadata into a node and edge format that can be recognized by the policy tracing graph. S2, based on the extracted behavioral features, train a trust assessment model to construct a strategy tracing graph and calculate the trust score of each user entity in real time; Trust scores are integrated into the graph as node attributes and associated with corresponding policy nodes; S3 defines a propagation control strategy: when an entity's trust score falls below a security threshold, a control mechanism is automatically triggered; based on the strategy tracing graph, the propagation range of strategy nodes associated with the entity is limited, allowing them to propagate only to high-risk isolation areas; S4. Monitor the fluctuation of trust scores. If the fluctuation exceeds the preset tolerance, trigger propagation calculation. Trace the incident path according to the policy source map and pre-deploy control points along the source path. The tracing of the incident path according to the policy source map specifically includes: quantifying the resource consumption characteristics of each policy propagation path by real-time monitoring of network resource usage status and establishing a resource demand prediction model, and constructing a basic scheduling model under resource constraints; dynamically generating scheduling weights based on the policy criticality level and real-time trust score of the entity using a weighted calculation model; designing a distributed event-driven scheduler architecture, performing real-time path priority ranking and resource allocation based on resource constraints and dynamic weights, and executing scheduling decisions through API commands. The execution of scheduling decisions also includes: constructing a hierarchical distributed scheduling framework, which includes a master scheduling node for global coordination and local schedulers deployed at the edge, and activating the scheduling process using an event-driven mode; when resource contention or new path requests are detected, prioritizing policy paths based on dynamic weights and allocating resources to high-priority paths through a resource allocation algorithm; when resources are insufficient, borrowing or delaying mechanisms are used for low-priority paths, and scheduling decisions are converted into network control commands through API commands.

2. The security policy-based network security operation method of claim 1, wherein, The association of corresponding policy nodes specifically includes: using extracted behavioral features as training data, constructing a trust assessment model using a supervised learning algorithm; initializing a directed graph model based on the node and edge structure transformed from policy metadata; wherein nodes represent policy instances, edges represent dependencies, and edge weights are calculated based on historical co-occurrence frequencies; inputting real-time collected user entity behavior data into the trained trust assessment model, calculating the trust score for each entity through forward propagation; adding a trust score attribute to each policy node according to the mapping relationship between user entities and policy nodes, and updating the node attribute table of the graph.

3. The network security operation method based on security policy according to claim 2, wherein, The trust score includes: a linear weighted model used in the trust score calculation formula, based on the aggregation of behavioral characteristics' deviations from the baseline; the formula is defined as: The trust score represents the entity, with a value range of [0,1]; k is the number of behavioral features; Let be the current observation value of the i-th feature; Let be the mean of the i-th feature in the historical dataset, representing the baseline of normal behavior; Let be the standard deviation of the i-th feature in the historical dataset, used to measure the range of feature fluctuation; The weight of the i-th feature is determined through model training, reflecting the importance of this feature in trust assessment, and satisfies... .

4. The security policy-based network security operation method of claim 1, wherein, The pre-deployment of control points along the tracing path specifically includes: real-time collection of the trust score sequence of each entity; calculation of short-term fluctuation indicators using sliding window technology; setting the monitoring frequency to a high-frequency interval and setting a fluctuation tolerance threshold, wherein the tolerance is twice the standard deviation of the score or a dynamic threshold based on percentiles; when the fluctuation indicator exceeds the tolerance for multiple consecutive monitoring periods, it is determined to be an abnormal fluctuation event; after confirming an abnormal fluctuation event, calling the propagation calculation engine, taking the policy tracing graph as input, and starting the path analysis algorithm to calculate the potential risk propagation path starting from the policy node associated with the abnormal entity; traversing the graph nodes and edges to identify all reachable paths, and prioritizing paths with high edge weights or frequent historical vulnerabilities; generating a directed subgraph from the path tracing results, and marking key nodes and propagation directions; and deploying virtual control points at the policy dependency intersection points of the path based on the tracing results.

5. The security policy-based network security operation method of claim 1, wherein, The designed distributed event-driven scheduler architecture includes: employing distributed resource monitoring and load prediction technologies, deploying lightweight agents and time-series models to perceive the overall network resource status and predict load trends in real time; dividing the network into multiple scheduling domains and dynamically electing a dominant scheduler based on load status; each local scheduler generating resource allocation proposals based on local resource status and prediction data, and reaching a consensus allocation scheme through a coordination protocol; synchronizing the consensus allocation scheme to all schedulers through a version control mechanism, with schedulers caching the scheme locally and preparing for execution; defining an elastic scaling threshold to dynamically adjust resource allocation based on load prediction results, achieving elastic scaling.

6. The network security operation method based on security policy as described in claim 5, characterized in that, The consensus allocation scheme achieved through the collaborative protocol is as follows: based on the network topology and business logic boundaries, the global network is divided into multiple independent scheduling domains, each scheduling domain covering a group of nodes with close resource dependencies; each scheduling domain periodically collects the load status indicators of nodes within the domain, and calculates the health score based on the real-time load data of the nodes to select the dominant scheduler; After the election, the local scheduler integrates predicted load trends with real-time monitoring indicators to analyze the supply and demand of resources in the local domain. Upon entering the consensus-building phase, the leading scheduler is responsible for coordinating the review of proposals within the domain. After the consensus scheme is generated, the dominant scheduler will synchronize the final allocation results to all nodes in the domain.

7. The security policy-based network security operation method of claim 5, wherein, The process of dividing the network into multiple scheduling domains includes: collecting policy metadata from each domain to establish a multi-domain policy feature library; collecting key events of policy propagation across scheduling domains in real time; preprocessing heterogeneous data collected from each domain and associating records from different data sources pointing to the same policy or entity to form a complete propagation chain; using trust scores as confounding variable nodes in the propagation chain and automatically constructing an initial causal graph based on historical propagation data using a causal discovery algorithm; automatically capturing the complete context of a security event when it is detected, extracting relevant data within a time window before the event, and extracting relevant subgraphs from the global causal graph based on the context of the security event; performing counterfactual analysis on each candidate cause node in the subgraph to determine the root cause node, determining the location of the root cause node in the policy tracing graph, identifying the node as a cross-domain problem node, and generating targeted optimization strategies.

8. The security policy-based network security operation method of claim 7, wherein, The process of identifying the node as a cross-domain problem node specifically includes: performing counterfactual analysis on each candidate cause node in the subgraph to first construct the actual observed propagation path; for each candidate cause, simulating a counterfactual scenario where the cause did not occur, and recalculating the probability of the security event by intervening in the causal graph; comparing the difference between the actual probability and the counterfactual probability to calculate the causal effect value of the candidate cause; the node with the largest causal effect value is identified as the root cause node; based on the position and attributes of the root cause node in the strategy tracing graph, automatically determining its type, identifying the node as a cross-domain problem node, and generating a targeted optimization strategy.

Images