Intelligent security identification and defense method based on edge-cloud cooperation

Abstract

The application relates to the technical field of intelligent security defense, and discloses an intelligent security identification and defense method based on end-edge-cloud cooperation. The method comprises the following steps: collecting original security data on an end-side device, extracting device running state and environment interaction features, and generating an end-side threat feature vector; an edge node receives the vector, combines a node-level threat knowledge base to complete behavior pattern matching, binds the result with device location information, and generates a threat behavior label group; a cloud platform calls the label group, cooperatively analyzes fusion of multi-edge node historical defense records, generates a threat confidence evaluation value and a cross-layer defense strategy instruction; and the evaluation value triggers the instruction to dynamically configure an end-side device interception rule library and an edge node traffic filtering threshold. The method optimizes data processing through end-edge-cloud cooperation, improves threat identification accuracy, realizes dynamic defense, and is suitable for security protection of multiple terminal devices.

Description

Technical Field

[0001] This invention relates to the field of intelligent security defense technology, specifically to an intelligent security identification and defense method based on edge-cloud collaboration. Background Technology

[0002] With the rapid development of technologies such as the Internet of Things (IoT) and the Industrial Internet, the number of various terminal devices is growing exponentially, and the scale of security data generated during device operation is constantly expanding. Security threats are also becoming more diversified, complex, and capable of spreading across regions. Currently, traditional security identification and defense methods are mostly concentrated on single devices or in the cloud, which has significant limitations.

[0003] At the device level, most terminal devices are limited by hardware resources, with limited computing power and storage capacity, making it difficult to perform in-depth analysis and complex threat identification on the large amounts of raw security data collected. They can usually only perform simple local data filtering and basic security checks. For some highly concealed and multi-dimensionally related security threats, they cannot detect and warn in a timely manner, which can easily lead to the spread of threats at the device level and affect the normal operation of the device.

[0004] In existing security systems, edge nodes often lack efficient collaboration mechanisms with end-device devices, and their own threat knowledge bases are not updated in a timely manner and have limited coverage. After receiving data from the end-device, edge nodes struggle to quickly and accurately match behavioral patterns due to the lack of a unified feature vector parsing standard. Furthermore, edge nodes lack effective data interaction and collaborative analysis capabilities, making it impossible to comprehensively assess security threats across regions and within the coverage area of ​​multiple edge nodes. This significantly reduces the accuracy and timeliness of threat identification, hindering the formation of an effective regional security barrier.

[0005] While cloud platforms possess strong computing and storage capabilities, in traditional models they require receiving large amounts of raw data from edge devices and endpoints. This results in high data transmission volumes, high latency, and a tendency to cause network bandwidth congestion. Furthermore, cloud platforms typically perform isolated analyses based on their own stored historical data, failing to fully integrate real-time threat information and historical defense records from multiple edge nodes. This makes it difficult to comprehensively grasp the dynamic changes and propagation patterns of security threats. When generating defense strategies, they often cannot accurately adapt to the actual operating status of edge devices and endpoints, leading to a lack of specificity and flexibility in defense strategies. This results in an inability to effectively address security threats in different scenarios, and ultimately, poor response speed and protection effectiveness of the overall security defense system. Summary of the Invention

[0006] The purpose of this invention is to provide an intelligent security identification and defense method based on edge-cloud collaboration to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, this invention provides an intelligent security identification and defense method based on edge-cloud collaboration, the method comprising:

[0008] Raw security data is collected from edge devices, and device operating status characteristics and environmental interaction characteristics are extracted to generate edge threat feature vectors.

[0009] The edge node receives the end-side threat feature vector, combines it with the node-level threat knowledge base to perform behavior pattern matching, binds the matching result with the device location information, and generates a threat behavior tag group.

[0010] The threat behavior tagging group is invoked on the cloud platform, and historical defense records from multiple edge nodes are integrated for collaborative analysis to generate threat confidence assessment values ​​and cross-layer defense strategy instructions.

[0011] The cross-layer defense strategy instruction is triggered based on the threat confidence assessment value, and the interception rule base of the end-side device and the traffic filtering threshold of the edge node are dynamically configured.

[0012] Preferably, the step of generating threat behavior tag groups includes:

[0013] The device operating status features in the edge threat feature vector are called up to calculate the deviation of the feature value fluctuation amplitude from the baseline operating range within a continuous time window;

[0014] Based on the deviation, abnormal feature segments are selected, and the frequency distribution pattern of environmental interaction features within the segments is extracted;

[0015] The frequency distribution pattern is compared with the attack pattern sequences stored in the node-level threat knowledge base for similarity.

[0016] When the similarity exceeds the dynamic matching threshold, the corresponding attack pattern code and device physical location coordinates are extracted and bound as a threat behavior tag group.

[0017] Preferably, the step of generating the threat confidence assessment value includes:

[0018] Call the attack pattern code in the threat behavior tag group to retrieve the false alarm rate data of the same type of attack in the historical defense records stored in the cloud platform;

[0019] Obtain the spatiotemporal distribution density of the threat behavior tag groups reported by multiple edge nodes, and calculate the regional threat aggregation intensity;

[0020] Based on the false alarm rate data and the regional threat aggregation intensity, a weighted collaborative confidence assessment value for threat behavior labeling groups is calculated.

[0021] When the collaborative confidence assessment value exceeds the level threshold, a cross-layer defense strategy instruction containing end-side interception priority and edge traffic filtering coefficient is generated.

[0022] Preferably, the step of dynamically configuring the interception rule base of the end-side device includes:

[0023] Based on the end-side interception priority in the cross-layer defense strategy instruction, select the device identifier set to be updated;

[0024] Extract the environmental interaction features corresponding to the device identifier set from the threat behavior tag group, and generate a feature matching rule template;

[0025] The feature matching rule template is compared with the current interception rule base for redundancy detection. After removing duplicate rules, it is written into the new rule queue.

[0026] The newly added rule queue is loaded according to the resource utilization rate of the terminal device and the order of interception priority.

[0027] Preferably, the step of configuring the traffic filtering threshold of the edge node includes:

[0028] The edge traffic filtering coefficient in the cross-layer defense strategy instruction is invoked to calculate the dynamic scaling ratio of the node traffic baseline value;

[0029] Obtain the spatiotemporal distribution density variation gradient of the threat behavior marker group within the coverage area of ​​the edge node;

[0030] Based on the dynamic scaling ratio and the gradient of spatiotemporal distribution density change, a real-time adjustment step size for the flow filtering threshold is generated.

[0031] When the feature dimension of a node traffic packet matches the threat behavior tag group, the traffic filtering threshold is updated using the real-time adjustment step size.

[0032] Preferably, the method further includes:

[0033] After the new rule queue is executed on the edge device, the interception trigger frequency and false interception event data are collected, and a rule activation feedback log is generated.

[0034] The rule activation feedback log is sent back to the edge node for verification against the matching results of the node-level threat knowledge base;

[0035] If the number of incident data intercepted by mistake exceeds the fault tolerance limit, a rule backtracking instruction will be generated and sent to the cloud platform.

[0036] Preferably, the method further includes:

[0037] The cloud platform receives the rule backtracking instruction and retrieves the associated cross-layer defense strategy instruction generation record;

[0038] Extract the time sequence of the false blocking event data from the rule activation feedback log;

[0039] Based on the false alarm rate change curve of the same type of strategy in historical defense records, the calculation weight of threat confidence assessment value is adjusted;

[0040] The updated collaborative confidence assessment value is output to the cross-layer defense strategy instruction generation process.

[0041] Preferably, the method further includes:

[0042] The edge node monitors the node load status after the traffic filtering threshold is updated, and collects resource utilization and attack interception success rate.

[0043] When resource utilization exceeds a safety threshold, the edge traffic filtering coefficient is reduced and cloud-based collaborative reallocation is triggered.

[0044] The attack interception success rate is compared with the edge rule activation feedback log to calculate the defense strategy execution deviation value;

[0045] If the deviation value of the defense strategy execution exceeds the tolerance range, a strategy calibration request is sent to the cloud platform.

[0046] Preferably, the method further includes:

[0047] The cloud platform responds to the policy calibration request by calling the defense policy execution deviation value reported by multiple edge nodes;

[0048] Recalculate the spatiotemporal weighting coefficients in the regional threat aggregation intensity;

[0049] Based on the updated regional threat aggregation strength and collaborative confidence assessment values, incremental cross-layer defense strategy instructions are generated.

[0050] The incremental cross-layer defense strategy instructions are distributed to target edge nodes and end-side devices for incremental coverage.

[0051] Preferably, the method further includes:

[0052] After receiving the incremental cross-layer defense strategy instruction, the edge device checks the version identifier of the current interception rule base;

[0053] If the version identifier does not match the incremental instruction, the interception rule base will be traced back to the most recent valid version.

[0054] Synchronously perform version rollback operations on traffic filtering thresholds at edge nodes;

[0055] Send a version conflict report to the cloud platform to trigger a full policy refactoring process.

[0056] Compared with the prior art, the beneficial effects of the present invention are:

[0057] By collecting raw security data from edge devices and extracting features to generate threat feature vectors, the local data processing advantages of edge devices can be fully utilized. Security information can be initially screened and features can be extracted at the source of data, avoiding the transmission of a large amount of useless raw data and reducing the data processing pressure on subsequent edge nodes and cloud platforms. At the same time, edge devices can achieve preliminary threat perception based on the features they extract, thus improving the security awareness of the devices themselves.

[0058] After receiving the threat feature vector from the edge node, it performs behavioral pattern matching by combining it with a node-level threat knowledge base. The matching results are then bound to device location information to generate threat behavior tag groups. This approach allows edge nodes to quickly focus on key threat information and efficiently identify edge threats based on their own knowledge base. Simultaneously, the binding of device location information gives threat behavior clear spatial attributes, facilitating precise control over the threat's propagation range and regional distribution. This provides a clear threat location basis for subsequent regional security protection, and the localized processing by edge nodes significantly reduces threat identification latency, allowing threats to receive timely attention and initial handling closer to the edge.

[0059] The cloud platform invokes threat behavior tagging groups and integrates historical defense records from multiple edge nodes for collaborative analysis to generate threat confidence assessment values ​​and cross-layer defense strategy instructions, fully leveraging the powerful computing capabilities and massive data processing advantages of the cloud. The integration of historical defense records from multiple edge nodes allows the cloud to acquire more comprehensive threat data, including not only real-time threat behavior information but also past defense experience and threat evolution patterns. This enables multi-dimensional and in-depth threat analysis, and the generated threat confidence assessment values ​​more accurately reflect the severity and credibility of the threat, providing a scientific standard for triggering subsequent defense strategies. The generation of cross-layer defense strategy instructions breaks through the limitations of traditional single-level defense, achieving a comprehensive consideration of protection needs at the endpoint, edge, and cloud levels.

[0060] Based on threat confidence assessment values, cross-layer defense strategy commands are triggered, dynamically configuring the interception rule base of edge devices and the traffic filtering thresholds of edge nodes. This allows defense measures to be flexibly adjusted according to the actual threat situation. When the threat confidence is high, the interception rules on the edge devices and the traffic filtering of edge nodes can be strengthened in a timely manner to effectively prevent the further spread of the threat. When the threat confidence is low or the threat is eliminated, the relevant configurations can be appropriately relaxed to avoid over-defense affecting the normal operation of devices and network transmission. This dynamic configuration method gives the entire defense system good adaptability and flexibility, enabling it to adjust protection strategies in real time according to changes in threats. This ensures that edge devices and edge nodes are in the optimal protection state under different threat scenarios, achieving close collaboration between edge, cloud, and end-device layers, forming a comprehensive and three-dimensional intelligent security defense system, and effectively improving the accuracy and effectiveness of overall security protection. Attached Figure Description

[0061] Figure 1 This is a schematic diagram illustrating the working principle of the intelligent security identification and defense method based on edge-cloud collaboration described in this invention.

[0062] Figure 2 Flowchart generated for threat behavior tagging groups;

[0063] Figure 3 Flowchart for configuring the endpoint interception rule base;

[0064] Figure 4 A flowchart for cloud-based rule backtracking processing;

[0065] Figure 5 A flowchart for cloud-based policy calibration and incremental instruction generation. Detailed Implementation

[0066] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0067] Please see Figure 1 This invention provides an intelligent security identification and defense method based on edge-cloud collaboration, the method comprising:

[0068] At the edge devices, the system continuously collects raw security data, including various operational status characteristics of the devices and their interaction characteristics with the environment. Through in-depth analysis and refinement of this raw data, representative edge threat feature vectors are generated. These vectors are then transmitted to edge nodes, where the system, in conjunction with a node-level threat knowledge base, performs detailed behavioral pattern matching on the received threat feature vectors. During matching, the system closely correlates the matching results with the device's geographical location information, thereby generating a detailed set of threat behavior tags. At the cloud platform level, the system calls upon the generated threat behavior tag set and performs deep fusion and collaborative analysis with the historical defense records of multiple edge nodes. Through this multi-dimensional comprehensive analysis, the system can generate accurate threat confidence assessment values ​​and formulate corresponding cross-layer defense strategy instructions accordingly. Finally, based on the specific status of the threat confidence assessment values, the system triggers corresponding cross-layer defense strategy instructions, dynamically configures the interception rule base of the edge devices, and adjusts the traffic filtering thresholds of the edge nodes to effectively improve the overall security protection capabilities of the system.

[0069] Example 1: See Figure 2 At edge nodes, after receiving the threat feature vector on the receiving end, the device's operating status features are invoked to calculate the deviation of the feature value fluctuation amplitude within a continuous time window from the baseline operating interval. The baseline operating interval is obtained through statistical learning of historical normal data, such as based on the sliding window mean or percentile range. The deviation calculation uses statistical difference measures, such as calculating the standard deviation ratio or absolute deviation sum of the current feature sequence and the baseline interval. If the deviation exceeds a preset threshold, the time window is marked as an abnormal feature segment. Subsequently, the frequency distribution pattern of environmental interaction features is extracted from the abnormal segment, including the number of occurrences of specific protocol types per unit time, the concentration index of target addresses, or the distribution pattern of packet size. The node-level threat knowledge base stores known attack pattern sequences, such as the traffic surge pattern of distributed denial-of-service attacks, the continuous connection request pattern of port scanning, or the command and control communication characteristics of malware. The extracted frequency distribution pattern is compared with the attack pattern sequences in the knowledge base using sequence matching algorithms, such as dynamic time warping or cosine similarity calculation. The dynamic matching threshold is adjusted according to the real-time network status, such as adaptively changing based on recent attack frequency or node load level. When the similarity exceeds a threshold, the system extracts the corresponding attack pattern code and device physical location coordinates, and binds them to generate a threat behavior tag group. The attack pattern code uniquely identifies the attack type, and the device physical location coordinates are used for geospatial analysis.

[0070] On the cloud platform, by invoking attack pattern codes within pre-defined threat behavior tagging groups, a systematic retrieval and analysis is performed on false positive rate data of attack events of the same or similar types as the current attack pattern in historical defense records. These historical defense records store detailed past attack events reported by multiple edge nodes and their processing results, while the false positive rate data is obtained by accurately calculating the ratio of the number of erroneously intercepted events to the total number of intercepted events in the defense logs. Furthermore, the system synchronously acquires the distribution density information of threat behavior tagging groups reported by multiple edge nodes within a specific spatiotemporal range. Specifically, this involves calculating the frequency of threat behavior tagging groups appearing within a unit geographical area per unit time, and visualizing this data to create intuitive heatmaps or density distribution maps. Based on this spatiotemporal distribution density data, a weighted aggregation method is further used to calculate the threat aggregation intensity of each region. The weighting factors comprehensively consider multiple key factors such as the severity level of the attack and the coverage density of nodes to ensure the accuracy and comprehensiveness of the assessment results.

[0071] When assessing the collaborative confidence level of threat behavior tagging groups, a weighted calculation method based on false positive rate data and regional threat aggregation strength is adopted. The core of this method is to comprehensively assess the actual probability of a threat occurrence by assigning different weights to different false positive rates and threat aggregation strength data. In the weight allocation process, the historical stability of the false positive rate and the spatial correlation of the aggregation strength are fully considered. For example, attack types with high historical false positive rates are assigned lower weights, while regions with high spatial aggregation strength are assigned higher weights. This collaborative confidence level assessment quantifies the actual probability of a threat occurrence. When this value exceeds a preset level threshold, the system automatically generates cross-layer defense strategy instructions. These instructions cover edge-side interception priority and edge traffic filtering coefficients. Edge-side interception priority is mainly used to guide the loading order of rules, ensuring that the most likely threats are intercepted first; the edge traffic filtering coefficient is used to adjust the traffic threshold, thereby more accurately identifying and intercepting potential threats.

[0072] Example 2: See Figure 3After the cloud platform generates cross-layer defense policy instructions, these instructions include key parameters such as endpoint interception priority and edge traffic filtering coefficient. Endpoint interception priority is a numerical indicator used to identify the urgency and importance level of rule updates required for different devices or device groups. Edge traffic filtering coefficient is an adjustment parameter used to quantify the intensity changes of edge node traffic processing policies. During the dynamic configuration of the endpoint device's interception rule base, the system first parses the cross-layer defense policy instructions and extracts the endpoint interception priority value. Based on this priority value, the system filters out a set of device identifiers from all connected endpoint devices that require immediate rule updates. The selection criteria for the device identifier set include not only the priority value but also factors such as device type, current security posture, and network environment. For example, devices located in high-risk network areas or those that have previously suffered similar attacks are prioritized for inclusion in the identifier set.

[0073] The system extracts environmental interaction features corresponding to the device identifier set from the generated threat behavior tag set. These features include network protocol type, packet size distribution, communication frequency pattern, and target address characteristics. Based on these features, the system generates a feature matching rule template. This template uses logical expressions and pattern matching statements to accurately describe the abnormal network behavior characteristics that need to be intercepted. For example, for a specific port scanning attack, the template may include frequency thresholds for continuous access to multiple ports and combination conditions for protocol types.

[0074] Before writing the feature matching rule template to the edge device, the system performs a redundancy detection process. This process compares the newly generated rule template with each existing rule in the device's current interception rule base. The comparison process uses a combination of hash value comparison and semantic analysis to identify completely duplicated or functionally overlapping rule entries. Rule templates marked as redundant are removed, ensuring that only newly added, non-duplicate rules enter the write queue. The filtered rule templates are written to the new rule queue in sequence, with the queue order optimized based on rule complexity and estimated resource consumption. The system loads the new rule queue according to the real-time resource utilization of the edge device, prioritizing interception. Resource utilization is comprehensively evaluated by monitoring the device's CPU utilization, memory usage, and network processing load. High-priority rules are loaded and executed first, while low-priority rules are deployed gradually when system resources are idle. The entire loading process uses an incremental update mechanism to avoid sudden performance drops or service interruptions caused by batch updates.

[0075] During the configuration of traffic filtering thresholds for edge nodes, the system invokes the edge traffic filtering coefficient from the cross-layer defense strategy instructions. This coefficient is a floating-point parameter used to adjust the traffic processing intensity of the edge nodes. The system first calculates the dynamic scaling ratio of the node's traffic baseline value, which is determined by the functional relationship between the traffic filtering coefficient and the node's current load state. The traffic baseline value is a benchmark level derived by analyzing the statistical characteristics of the node's historical traffic data, including average traffic rate, peak traffic patterns, and normal traffic fluctuation range. The system obtains the gradient of the spatiotemporal distribution density of threat behavior marker groups within the edge node's coverage area. This gradient value is calculated by analyzing the rate of change in the frequency of threat marker occurrences in different time periods and geographical areas, reflecting the spread speed and aggregation degree of threat behavior. Combining the dynamic scaling ratio and the spatiotemporal distribution density gradient, the system generates a real-time adjustment step size for the traffic filtering threshold. This step size is a dynamically changing parameter that can smoothly adjust the threshold level according to real-time changes in the network environment, avoiding the false blocking of normal traffic due to sudden threshold changes.

[0076] During edge node monitoring, when characteristic dimensions of traffic packets are captured, and these characteristics closely match the feature descriptions within pre-defined threat behavior marker groups, the system immediately initiates a real-time adjustment mechanism. This mechanism updates the traffic filtering thresholds by precisely calculating step sizes. This feature dimension matching process involves multi-layered, meticulous comparisons, such as protocol type identification, statistical analysis of packet size distribution, and regularity detection of request frequency patterns, to comprehensively assess traffic characteristics from multiple dimensions. The updated traffic filtering thresholds take effect quickly, directly impacting the edge node's traffic filtering engine. This enables dynamic blocking or reasonable rate limiting of suspicious traffic, effectively curbing the spread of potential threats. The entire threshold adjustment process strictly adheres to a closed-loop control mechanism. The system not only continuously monitors the actual effectiveness of traffic filtering but also closely monitors changes in node performance indicators. By continuously collecting feedback data, it precisely optimizes and adjusts parameters, aiming to ensure network security protection while maximizing network performance stability and efficiency, achieving an ideal balance between security and performance.

[0077] Example 3: See Figure 4The logs employ a hierarchical storage format, comprising a rule execution summary layer and a detailed event log layer. The summary layer records the overall execution statistics for each rule, including the total number of triggers, time distribution characteristics, and resource consumption indicators. The detailed event layer stores the original network packet samples, protocol parsing results, and system state snapshots for each interception event. After log generation, the logs are transmitted to edge nodes via an encrypted channel for initial processing. Upon receiving the rule activation feedback logs, the edge nodes initiate a verification process with the node-level threat knowledge base. The verification process consists of two stages: pattern consistency checking and false positive source analysis. Pattern consistency checking compares the interception trigger patterns in the logs with the attack feature sequences stored in the knowledge base, calculating the degree of matching of behavioral patterns. False positive source analysis focuses on analyzing false interception event data, identifying key characteristic factors leading to misjudgments by reproducing the network environment and operating status at the time of interception. The verification results generate a verification report, including pattern matching confidence and false positive root cause analysis conclusions.

[0078] The system employs a dynamically adjusted fault tolerance cap mechanism, based on a comprehensive assessment of device type, network environment, and historical false alarm rate. When the statistical indicators of false blocking event data exceed the fault tolerance cap, edge nodes generate a rule rollback instruction. This instruction includes a list of rule identifiers requiring rollback, a suggested rollback time range, and alternative protection scheme suggestions. The rule rollback instruction is transmitted to the cloud platform via a secure link, triggering the policy adjustment process. Upon receiving the rule rollback instruction, the cloud platform immediately initiates a related data retrieval program. This program first retrieves the original cross-layer defense policy instruction generation record associated with the rollback instruction, including the threat assessment data referenced during policy decision-making, the list of edge nodes involved in the calculation, and the policy generation algorithm parameters. Simultaneously, the platform extracts the time sequence of false blocking event data distribution from the rule activation feedback log. This time sequence data includes the occurrence time series of false blocking events, geographical distribution characteristics, and device type distribution patterns.

[0079] The correction process uses the false positive rate change curve of the same type of strategy in historical defense records as a reference benchmark. This curve is derived through time series analysis of historical data and reflects the false positive performance of different strategy types under different environments. The weight correction algorithm adjusts the contribution ratio of each factor in the evaluation formula, reducing the weight of feature factors that have shown high false positive rates in history.

[0080] The revised weights are applied to the calculation of the threat confidence assessment value, generating an updated collaborative confidence assessment value. The formula for calculating this assessment value is:

[0081]

[0082] Where: C new w′ represents the updated collaborative confidence assessment value. if represents the weight coefficient of the i-th feature factor after correction. i (x) represents the quantization function of the i-th feature factor, α is the time decay coefficient, and R t This represents the real-time environmental risk adjustment factor. Weighting coefficient w′ i The correction is based on a comprehensive analysis of historical false alarm rate curves and the current distribution of false interception events. The time decay coefficient α ensures that recent data receives higher importance, and the real-time environmental risk adjustment factor R... t This reflects the overall security posture of the current network environment. The updated collaborative confidence assessment value is output to the cross-layer defense policy instruction generation process, serving as the core input for the next round of policy formulation. This value directly affects the parameter settings in the subsequently generated cross-layer defense policy instructions, including the adjustment range of the endpoint interception priority and the value range of the edge traffic filtering coefficient. Through this feedback adjustment mechanism, the system can gradually reduce the false alarm rate and improve the accuracy of threat identification.

[0083] Example 4: See Figure 5 The edge nodes' built-in status acquisition module collects these metric data at a fixed frequency and performs preliminary preprocessing. Resource utilization data is smoothed to eliminate interference from instantaneous peaks and obtain stable trend data. Attack interception success rate data is stored in association with timestamps, traffic characteristics, and attack type tags to form detailed performance records. When resource utilization exceeds a security threshold, the system automatically triggers an adjustment mechanism. The security threshold is dynamically calculated based on node hardware configuration, historical load patterns, and the current network environment; the threshold settings differ for different node types and deployment locations. When the security threshold is exceeded, the edge node performs two parallel operations: reducing the edge traffic filtering coefficient and sending a collaborative reallocation request to the cloud platform. The adjustment of the traffic filtering coefficient adopts a gradual reduction strategy to avoid drastic changes in traffic processing strategies caused by sudden coefficient changes. The collaborative reallocation request contains detailed node status data, current traffic processing strategies, and resource demand predictions, which help the cloud platform comprehensively understand the operational status of the edge nodes.

[0084] The system performs a deep comparison between attack interception success rate data and rule activation feedback logs received from edge devices. The comparison process employs multi-dimensional correlation analysis, considering time synchronization, event type matching, and consistency of handling effects. The system calculates a defense strategy execution deviation value, which quantifies the difference between the actual defense effect and the expected target. The deviation value is calculated based on multiple factors, including interception time delay, rule matching accuracy, and handling completeness. If the defense strategy execution deviation value exceeds the tolerance range, the edge node generates a strategy calibration request and sends it to the cloud platform. The tolerance range is dynamically adjusted based on the strategy type, network environment risk level, and historical performance.

[0085] Upon receiving a policy calibration request, the cloud platform immediately initiates a multi-source data aggregation and analysis process. By utilizing defense policy execution deviation data from multiple edge nodes, the platform constructs a comprehensive global performance view. This data undergoes detailed classification and aggregation based on node groups, geographical regions, and policy types to more accurately identify overall execution patterns and potential anomalies. Based on the classification and aggregation results, the platform further recalculates the spatiotemporal weighting coefficients in the regional threat aggregation intensity. In adjusting these coefficients, the platform comprehensively considers factors such as the propagation characteristics of threat behavior, the coverage density of each node, and the changing trends of environmental risks. This adjustment aims to make the threat assessment results more aligned with reality, thereby improving the effectiveness and accuracy of defense strategies. Through this series of complex analyses and calculations, the platform can provide users with more reliable and real-time security protection recommendations.

[0086] Table 1: Edge node load status monitoring data.

[0087] Node identifier Resource utilization rate (%) Safety threshold (%) Interception success rate (%) Deviation value Trigger Action EN-2047 78.2 75.0 92.5 0.12 Reduce coefficient EN-3091 82.5 80.0 88.7 0.18 reallocation EN-4156 71.3 75.0 95.2 0.09 No action EN-5223 86.8 80.0 84.3 0.21 Calibration Request EN-6389 79.6 80.0 90.1 0.15 Reduce coefficient

[0088] Based on the updated regional threat aggregation strength and collaborative confidence assessment values, the cloud platform generates incremental cross-layer defense policy instructions. These incremental instructions only contain the policy parameters and rule entries that need adjustment, avoiding the network overhead and processing burden of distributing the full policy. The instruction generation process employs a difference analysis algorithm to identify the minimum set of changes between the current policy and the ideal state, ensuring the accuracy and efficiency of the adjustment. The incremental cross-layer defense policy instructions are transmitted to target edge nodes and end-devices via a secure distribution mechanism. The distribution process uses priority scheduling, prioritizing policy update instructions for high-load nodes and high-risk areas. After receiving the instructions, the target nodes perform incremental overwrite operations, updating only the policy parts that need modification while maintaining the stability of other policy entries. The entire update process uses a transaction mechanism to ensure the atomicity and consistency of policy changes, avoiding inconsistencies in policy states due to partial updates.

[0089] Example 5: The secure transmission channel receives incremental cross-layer defense strategy instructions from the cloud platform. Instruction transmission uses encrypted data packets, including a metadata segment in the instruction header and a strategy parameter segment in the body. The metadata segment records control information such as the instruction version identifier, generation timestamp, applicable device scope, and policy activation conditions. The strategy parameter segment contains the specific rule entries to be updated, filter threshold adjustment values, and execution priority parameters. After receiving the instruction, the edge device first parses the instruction header metadata to extract the version identifier information. The version identifier uses a hierarchical encoding structure, including a major version number, minor version number, and revision sequence number, which uniquely identifies the generation batch and update order of the strategy instruction. The device maintains a local version registry, recording the version identifiers of all currently loaded strategy instructions and their associated relationships. The system compares and verifies the received instruction version identifier with the currently valid version recorded in the local registry.

[0090] When a version identifier mismatch is detected with the incremental command, the system triggers a version rollback mechanism. The rollback operation is first performed on the edge device, which uses locally stored version history logs to revert to the most recent valid version of the interception rule base. The rollback process employs transactional operations to ensure the consistency of the rule base state. The system restores the corresponding version's rule configuration data, including rule entries, matching conditions, and execution parameters, from local cache or secure backup storage. After rollback, the device re-verifies the integrity and validity of the rule base to ensure normal operation of the defense function. On the edge node side, the system synchronously performs a version rollback operation for the traffic filtering threshold. The edge node maintains version management records of the traffic processing strategy, recording the execution effect and resource consumption of different version threshold configurations. During rollback, the node retrieves historical threshold configurations based on the version identifier and restores the filtering strategy that matches the edge device's rule base. Threshold rollback uses a gradual adjustment method to avoid drastic fluctuations in traffic processing strategies and maintain network service stability. After the rollback operation is completed, the edge node verifies the consistency between the traffic filtering function and the edge-side rule execution.

[0091] After the rollback operation is completed, the edge device generates a version conflict report. This report records detailed contextual information about the conflict event, including the received command version identifier, the local current version identifier, the conflict detection time, and the rollback operation result. The report also includes device operating status data, network environment indicators, and recent defense event statistics. The version conflict report is transmitted to the cloud platform via an encrypted channel, serving as input to trigger the full policy reconfiguration process. Upon receiving the version conflict report, the cloud platform initiates the full policy reconfiguration process. This process first analyzes the version mismatch reasons recorded in the conflict report to identify the root causes of the version divergence. The platform retrieves historical policy generation records, comparing the differences and evolution trajectories between different policy versions. Based on the analysis results, the platform reassesses the current network threat landscape and defense requirements, and formulates a new policy generation scheme.

[0092] The full policy reconfiguration process employs a novel policy calculation algorithm, comprehensively considering multi-dimensional information such as feedback from edge devices, edge node status, and global threat intelligence. The newly generated policy instructions contain a complete rule set and configuration parameters, ensuring complete consistency of policy versions across all components. The reconfigured policy instructions are transmitted to all relevant edge devices and nodes via a secure distribution mechanism, achieving synchronized updates of global policies. All version management operations are recorded in a security log, including instruction reception time, version verification results, rollback operation details, and conflict report content. Log data is stored using tamper-proof technology, providing a reliable basis for system auditing and troubleshooting. Version identifier generation and verification utilize a cryptographic signature mechanism.

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

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

Claims

1. An intelligent security identification and defense method based on end-edge-cloud collaboration, characterized in that, include: Raw security data is collected from edge devices, and device operating status characteristics and environmental interaction characteristics are extracted to generate edge threat feature vectors. The edge node receives the end-side threat feature vector, combines it with the node-level threat knowledge base to perform behavior pattern matching, binds the matching result with the device location information, and generates a threat behavior tag group. The threat behavior tagging group is invoked on the cloud platform, and historical defense records from multiple edge nodes are integrated for collaborative analysis to generate threat confidence assessment values ​​and cross-layer defense strategy instructions. The cross-layer defense strategy instruction is triggered based on the threat confidence assessment value, and the interception rule base of the end-side device and the traffic filtering threshold of the edge node are dynamically configured. The step of generating threat behavior tag groups includes: The device operating status features in the edge threat feature vector are called up to calculate the deviation of the feature value fluctuation amplitude from the baseline operating range within a continuous time window; Based on the deviation, abnormal feature segments are selected, and the frequency distribution pattern of environmental interaction features within the segments is extracted; The frequency distribution pattern is compared with the attack pattern sequences stored in the node-level threat knowledge base for similarity. When the similarity exceeds the dynamic matching threshold, the corresponding attack pattern code and device physical location coordinates are extracted and bound as a threat behavior tag group. The steps for generating the threat confidence assessment value include: Call the attack pattern code in the threat behavior tag group to retrieve the false alarm rate data of the same type of attack in the historical defense records stored in the cloud platform; Obtain the spatiotemporal distribution density of the threat behavior tag groups reported by multiple edge nodes, and calculate the regional threat aggregation intensity; Based on the false alarm rate data and the regional threat aggregation intensity, a weighted collaborative confidence assessment value for threat behavior labeling groups is calculated. When the collaborative confidence assessment value exceeds the level threshold, a cross-layer defense strategy instruction containing end-side interception priority and edge traffic filtering coefficient is generated.

2. The method of claim 1, wherein, The steps for dynamically configuring the interception rule base of the end-side device include: Based on the end-side interception priority in the cross-layer defense strategy instruction, select the device identifier set to be updated; Extract the environmental interaction features corresponding to the device identifier set from the threat behavior tag group, and generate a feature matching rule template; The feature matching rule template is compared with the current interception rule base for redundancy detection. After removing duplicate rules, it is written into the new rule queue. The newly added rule queue is loaded according to the resource utilization rate of the terminal device and the order of interception priority.

3. The method according to claim 2, characterized in that, The steps for configuring the traffic filtering threshold of the edge node include: The edge traffic filtering coefficient in the cross-layer defense strategy instruction is invoked to calculate the dynamic scaling ratio of the node traffic baseline value; Obtain the spatiotemporal distribution density variation gradient of the threat behavior marker group within the coverage area of ​​the edge node; Based on the dynamic scaling ratio and the gradient of spatiotemporal distribution density change, a real-time adjustment step size for the flow filtering threshold is generated. When the feature dimension of a node traffic packet matches the threat behavior tag group, the traffic filtering threshold is updated using the real-time adjustment step size.

4. The method according to claim 3, characterized in that, The method further includes: After the new rule queue is executed on the edge device, the interception trigger frequency and false interception event data are collected, and a rule activation feedback log is generated. The rule activation feedback log is sent back to the edge node for verification against the matching results of the node-level threat knowledge base; If the number of incident data intercepted by mistake exceeds the fault tolerance limit, a rule backtracking instruction will be generated and sent to the cloud platform.

5. The method according to claim 4, characterized in that, The method further includes: The cloud platform receives the rule backtracking instruction and retrieves the associated cross-layer defense strategy instruction generation record; Extract the time sequence of the false blocking event data from the rule activation feedback log; Based on the false alarm rate change curve of the same type of strategy in historical defense records, the calculation weight of threat confidence assessment value is adjusted; The updated collaborative confidence assessment value is output to the cross-layer defense strategy instruction generation process.

6. The method according to claim 5, characterized in that, The method further includes: The edge node monitors the node load status after the traffic filtering threshold is updated, and collects resource utilization and attack interception success rate. When resource utilization exceeds a safety threshold, the edge traffic filtering coefficient is reduced and cloud-based collaborative reallocation is triggered. The attack interception success rate is compared with the edge rule activation feedback log to calculate the defense strategy execution deviation value; If the deviation value of the defense strategy execution exceeds the tolerance range, a strategy calibration request is sent to the cloud platform.

7. The method according to claim 6, characterized in that, The method further includes: The cloud platform responds to the policy calibration request by calling the defense policy execution deviation value reported by multiple edge nodes; Recalculate the spatiotemporal weighting coefficients in the regional threat aggregation intensity; Based on the updated regional threat aggregation strength and collaborative confidence assessment values, incremental cross-layer defense strategy instructions are generated. The incremental cross-layer defense strategy instructions are distributed to target edge nodes and end-side devices for incremental coverage.

8. The method according to claim 7, characterized in that, The method further includes: After receiving the incremental cross-layer defense strategy instruction, the edge device checks the version identifier of the current interception rule base; If the version identifier does not match the incremental instruction, the interception rule base will be traced back to the most recent valid version. Synchronously perform version rollback operations on traffic filtering thresholds at edge nodes; Send a version conflict report to the cloud platform to trigger a full policy refactoring process.

Images