Strategy distribution method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a strategy distribution method and device, electronic equipment and a storage medium, and the method comprises the steps: receiving first recognition data, sent by different network equipment, of different recognition algorithms, carrying out the normalization processing of the first recognition data, obtaining second recognition data, and employing an artificial intelligence algorithm to carry out the normalization processing of the second recognition data; and performing feature association and fusion on the second identification data to obtain confidence coefficients corresponding to different identification algorithms, further obtaining execution strategies corresponding to different network devices in combination with a device capability registry, and sending the execution strategies to the network devices, so that multi-source application identification results are normalized, fused and associated with the AI, and the accuracy of the multi-source application identification results is improved. And intelligent strategy issuing is carried out in combination with the equipment capability.

Description

Technical Field

[0001] This application relates to the field of network security technology, and more specifically, to a policy distribution method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the continuous development of network devices, each device has different hardware functions, supports different protocols, and can support different applications. Therefore, the identification of traffic data also varies. Currently, traffic data identification relies on a single identification algorithm. For example, Deep Packet Inspection (DPI) can parse application protocols, but its identification rate for encrypted traffic is low. Domain name / URL databases depend on static libraries and are updated slowly. Heuristic identification based on ports or protocols has limited accuracy. Although machine learning-based classifiers have generalization capabilities, they are prone to errors in small samples or obfuscated traffic. Single engines often suffer from insufficient identification coverage and low accuracy. At the same time, different network devices (access points, gateways, switches, home routers, etc.) have different processing capabilities and support different signature types, making it difficult for existing solutions to achieve unified policy distribution and globally consistent application management. Summary of the Invention

[0003] The purpose of some embodiments of this application is to provide a policy distribution method, apparatus, electronic device, and storage medium. Through the technical solutions of the embodiments of this application, first identification data sent by different network devices is received. This first identification data is obtained based on different identification algorithms, including at least the DPI algorithm, URL parsing algorithm, port protocol identification algorithm, and ML classification algorithm. The first identification data is then normalized to obtain processed second identification data. A hierarchical weighted voting fusion algorithm is used to perform feature association and fusion on the second identification data to obtain the confidence levels corresponding to different identification algorithms of different network devices. The hierarchical weighted voting fusion algorithm includes engine-level weighted voting and category-level voting. Based on the confidence levels corresponding to the different identification algorithms and a pre-established device capability registry, the execution policy corresponding to different network devices is determined and distributed to… The network device sends the execution policy, and based on the signature support type and resource threshold recorded in the device capability registry, it trims unsupported identification algorithm rules to generate a differentiated execution policy package. The execution policy includes at least one or more of the following: DPI algorithm, URL parsing algorithm, port protocol identification algorithm, and ML classification algorithm. In this embodiment, the first identification data of different identification algorithms sent by different network devices is received and normalized to obtain the second identification data. Then, an artificial intelligence algorithm is used to perform feature association and fusion on the second identification data to obtain the confidence level corresponding to different identification algorithms. Then, combined with the device capability registry, the execution policy corresponding to different network devices is obtained and the execution policy is sent to the network device. In this way, the identification results of multi-source applications are normalized, fused and associated with AI, and the policy is intelligently distributed in combination with device capabilities.

[0004] Firstly, some embodiments of this application provide a strategy distribution method, including: Receive first identification data sent by different network devices. The first identification data is obtained based on different identification algorithms. The different identification algorithms include at least the DPI algorithm, the URL parsing algorithm, the port protocol identification algorithm, and the ML classification algorithm. The first identification data is normalized to obtain the processed second identification data; A hierarchical weighted voting fusion algorithm is used to perform feature association and fusion on the second identification data to obtain the confidence scores corresponding to different identification algorithms for different network devices. The hierarchical weighted voting fusion algorithm includes engine-level weighted voting and category-level voting. Based on the confidence levels corresponding to the different identification algorithms and the pre-established device capability registry, the execution strategies corresponding to different network devices are determined, and the execution strategies are sent to the network devices. Based on the signature support types and resource thresholds recorded in the device capability registry, unsupported identification algorithm rules are trimmed to generate a differentiated execution strategy package. The execution strategies include at least one or more of the following: DPI algorithm, URL parsing algorithm, port protocol identification algorithm, and ML classification algorithm.

[0005] Some embodiments of this application receive first identification data from different network devices using different identification algorithms, and standardize the first identification data to obtain second identification data. Then, artificial intelligence algorithms are used to perform feature association and fusion on the second identification data to obtain the confidence levels corresponding to different identification algorithms. Then, combined with the device capability registry, execution policies corresponding to different network devices are obtained, and execution policies are sent to the network devices. In this way, the identification results of multi-source applications are standardized, fused, and associated with AI, and the policies are intelligently distributed in combination with device capabilities.

[0006] Optionally, the step of normalizing the first identification data to obtain the processed second identification data includes: Obtain the pattern matching result determined by the DPI algorithm, the URL parsing result determined by the URL parsing algorithm, the port data determined by the port protocol identification algorithm, and the field information in the feature vector determined by the ML classification algorithm; A pre-set mapping rule table is used to map the field information to standard fields; Based on the standard fields, the processed second identification data is determined, and the second identification data includes at least a timestamp, a 5-tuple identifier stream, the source of the identification engine, and the self-reported confidence of the identification algorithm.

[0007] Some embodiments of this application achieve real-time conversion of multi-source recognition results through adapters. Each recognition engine corresponds to a dedicated adapter with a built-in mapping rule table, which maps the original output fields to a unified application recognition event structure, ensuring that subsequent modules such as normalization, AI association, and telemetry stitching can directly consume the data without secondary parsing.

[0008] Optionally, the step of using a hierarchical weighted voting fusion algorithm to perform feature association and fusion on the second identification data to obtain the confidence levels corresponding to different identification algorithms for different network devices includes: Obtain the feature vector from the second identification data, wherein the feature vector includes at least enumerated features, text features, and sequence features; Based on the stream identifier and time window, the feature vector is subjected to context-enhanced association concatenation processing to obtain a concatenated multidimensional feature vector; A confidence-weighted and dynamic weight adaptive algorithm is used to perform hierarchical voting on the concatenated multidimensional feature vector to obtain the confidence scores corresponding to different recognition algorithms for different network devices.

[0009] Some embodiments of this application utilize artificial intelligence algorithms (such as logistic regression, random forest, and deep learning models) to perform feature association and voting fusion on the results of multiple engines, thereby obtaining the confidence levels corresponding to different recognition algorithms. This not only resolves conflicts between engines but also discovers clustering features of potential unknown applications.

[0010] Optionally, the step of employing a confidence-weighted and dynamic weight adaptive algorithm to perform hierarchical voting processing on the concatenated multidimensional feature vectors to obtain the confidence levels corresponding to different recognition algorithms for different network devices includes: An engine-level weighted voting algorithm is used to process the concatenated multidimensional feature vector to obtain the fused label and the first confidence score; Based on the weights of different identification algorithms in historical data, as well as the fused label and the first confidence level, the confidence levels corresponding to different identification algorithms for different network devices are determined.

[0011] Some embodiments of this application combine the historical accuracy, output confidence, and traffic characteristics of each engine to generate a comprehensive confidence score for application identification. This not only resolves conflicts between engines but also discovers clustering characteristics of potential unknown applications.

[0012] Optionally, determining the execution strategy for different network devices based on the confidence levels corresponding to the different identification algorithms and a pre-established device capability registry includes: Using the pre-established device capability registry, the signature type of each network device is determined, wherein the signature type includes at least DPI signature, domain name list, SNI mode, and HTTP Host matching; Based on the confidence level, signature adaptation matrix, and policy mapping engine corresponding to the different recognition algorithms, the system performs matching in the pre-established device capability registry to determine the execution policy corresponding to different network devices.

[0013] Some embodiments of this application maintain a "device capability registry" that describes the signature types supported by each device (DPI signature, domain name list, SNI mode, HTTP Host matching, etc.); and generate differentiated signature / policy bundles based on device capabilities to ensure that lightweight devices are not issued overly heavy rules.

[0014] Optionally, sending the execution policy to the network device, based on the signature support types and resource thresholds recorded in the device capability registry, trims unsupported identification algorithm rules and generates a differentiated execution policy package, including: Based on the preset intent information, determine the pre-set network topology, device labels of network devices, and role mappings; The execution strategy is encapsulated according to the pre-set encapsulation rules to obtain the encapsulated execution strategy; The encapsulated execution policy is sent to the corresponding network device.

[0015] Some embodiments of this application customize signature distribution based on the capabilities of different network devices, and determine different execution strategies for different network devices to reduce resource consumption.

[0016] Optionally, the method further includes: Acquire historical remote sensing data from various network devices; The normalization process is updated based on the historical remote sensing data.

[0017] Some embodiments of this application are based on an AI feedback mechanism using telemetry data, which can continuously optimize the recognition process.

[0018] Secondly, some embodiments of this application provide a strategy distribution apparatus, including: The receiving module is used to receive first identification data sent by different network devices. The first identification data is obtained based on different identification algorithms, and the different identification algorithms include at least the DPI algorithm, the URL parsing algorithm, the port protocol identification algorithm, and the ML classification algorithm. The processing module is used to perform normalization processing on the first identification data to obtain the processed second identification data; The fusion module is used to perform feature association and fusion on the second identification data using a hierarchical weighted voting fusion algorithm to obtain the confidence scores corresponding to different identification algorithms for different network devices. The hierarchical weighted voting fusion algorithm includes engine-level weighted voting and category-level voting. The sending module is used to determine the execution strategy corresponding to different network devices based on the confidence level corresponding to the different identification algorithms and the pre-established device capability registry, and send the execution strategy to the network devices. Based on the signature support type and resource threshold recorded in the device capability registry, it trims unsupported identification algorithm rules and generates a differentiated execution strategy package. The execution strategy includes at least one or more of the following: DPI algorithm, URL parsing algorithm, port protocol identification algorithm, and ML classification algorithm.

[0019] Some embodiments of this application receive first identification data from different network devices using different identification algorithms, and standardize the first identification data to obtain second identification data. Then, artificial intelligence algorithms are used to perform feature association and fusion on the second identification data to obtain the confidence levels corresponding to different identification algorithms. Then, combined with the device capability registry, execution policies corresponding to different network devices are obtained, and execution policies are sent to the network devices. In this way, the identification results of multi-source applications are standardized, fused, and associated with AI, and the policies are intelligently distributed in combination with device capabilities.

[0020] Optionally, the processing module is configured to: Obtain the pattern matching result determined by the DPI algorithm, the URL parsing result determined by the URL parsing algorithm, the port data determined by the port protocol identification algorithm, and the field information in the feature vector determined by the ML classification algorithm; A pre-set mapping rule table is used to map the field information to standard fields; Based on the standard fields, the processed second identification data is determined, and the second identification data includes at least a timestamp, a 5-tuple identifier stream, the source of the identification engine, and the self-reported confidence of the identification algorithm.

[0021] Some embodiments of this application achieve real-time conversion of multi-source recognition results through adapters. Each recognition engine corresponds to a dedicated adapter with a built-in mapping rule table, which maps the original output fields to a unified application recognition event structure, ensuring that subsequent modules such as normalization, AI association, and telemetry stitching can directly consume the data without secondary parsing.

[0022] Optionally, the fusion module is used for: Obtain the feature vector from the second identification data, wherein the feature vector includes at least enumerated features, text features, and sequence features; Based on the stream identifier and time window, the feature vector is subjected to context-enhanced association concatenation processing to obtain a concatenated multidimensional feature vector; A confidence-weighted and dynamic weight adaptive algorithm is used to perform hierarchical voting on the concatenated multidimensional feature vector to obtain the confidence scores corresponding to different recognition algorithms for different network devices.

[0023] Some embodiments of this application utilize artificial intelligence algorithms (such as logistic regression, random forest, and deep learning models) to perform feature association and voting fusion on the results of multiple engines, thereby obtaining the confidence levels corresponding to different recognition algorithms. This not only resolves conflicts between engines but also discovers clustering features of potential unknown applications.

[0024] Optionally, the fusion module is used for: An engine-level weighted voting algorithm is used to process the concatenated multidimensional feature vector to obtain the fused label and the first confidence score; Based on the weights of different identification algorithms in historical data, as well as the fused label and the first confidence level, the confidence levels corresponding to different identification algorithms for different network devices are determined.

[0025] Some embodiments of this application combine the historical accuracy, output confidence, and traffic characteristics of each engine to generate a comprehensive confidence score for application identification. This not only resolves conflicts between engines but also discovers clustering characteristics of potential unknown applications.

[0026] Optionally, the sending module is configured to: Using the pre-established device capability registry, the signature type of each network device is determined, wherein the signature type includes at least DPI signature, domain name list, SNI mode, and HTTP Host matching; Based on the confidence level, signature adaptation matrix, and policy mapping engine corresponding to the different recognition algorithms, the system performs matching in the pre-established device capability registry to determine the execution policy corresponding to different network devices.

[0027] Some embodiments of this application maintain a "device capability registry" that describes the signature types supported by each device (DPI signature, domain name list, SNI mode, HTTP Host matching, etc.); and generate differentiated signature / policy bundles based on device capabilities to ensure that lightweight devices are not issued overly heavy rules.

[0028] Optionally, the sending module is configured to: Based on the preset intent information, determine the pre-set network topology, device labels of network devices, and role mappings; The execution strategy is encapsulated according to the pre-set encapsulation rules to obtain the encapsulated execution strategy; The encapsulated execution policy is sent to the corresponding network device.

[0029] Some embodiments of this application customize signature distribution based on the capabilities of different network devices, and determine different execution strategies for different network devices to reduce resource consumption.

[0030] Optionally, the receiving module is configured to: Acquire historical remote sensing data from various network devices; The normalization process is updated based on the historical remote sensing data.

[0031] Some embodiments of this application are based on an AI feedback mechanism using telemetry data, which can continuously optimize the recognition process.

[0032] Thirdly, some embodiments of this application provide an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, can implement the policy distribution method as described in any embodiment of the first aspect.

[0033] Fourthly, some embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can implement the policy distribution method as described in any embodiment of the first aspect.

[0034] Fifthly, some embodiments of this application provide a computer program product, the computer program product including a computer program, wherein the computer program, when executed by a processor, can implement the policy distribution method as described in any embodiment of the first aspect. Attached Figure Description

[0035] To more clearly illustrate the technical solutions of some embodiments of this application, the accompanying drawings used in some embodiments of this application will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 A flowchart illustrating a strategy distribution method provided in an embodiment of this application; Figure 2 A standardized flowchart provided for embodiments of this application; Figure 3 A schematic diagram of the feature fusion process provided for embodiments of this application; Figure 4 A schematic diagram of the voting fusion process provided in this application embodiment; Figure 5 A schematic diagram illustrating the process of generating a strategy package provided in an embodiment of this application; Figure 6 A schematic diagram of the strategy distribution process provided in the embodiments of this application; Figure 7 This is a schematic diagram illustrating the processing of remote sensing data provided in an embodiment of this application; Figure 8 A flowchart illustrating the distribution strategy provided in an embodiment of this application; Figure 9 A flowchart illustrating yet another strategy distribution method provided in an embodiment of this application; Figure 10A schematic diagram illustrating the application identification process provided in this application embodiment; Figure 11 A schematic diagram of the basic application record data provided in the embodiments of this application; Figure 12 This is a schematic diagram of the configuration interface of the global strategy abstraction layer provided in an embodiment of this application; Figure 13 A schematic diagram illustrating the processing of the telemetry collection and AI enhancement module provided in an embodiment of this application; Figure 14 This is a schematic diagram of the structure of a strategy distribution device provided in an embodiment of this application; Figure 15 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0037] The technical solutions of some embodiments of this application will now be described with reference to the accompanying drawings.

[0038] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0039] like Figure 1 As shown, an embodiment of this application provides a policy distribution method, the method comprising: S101. Receive first identification data sent by different network devices. The first identification data is obtained based on different identification algorithms. The different identification algorithms include at least DPI algorithm, URL parsing algorithm, port protocol identification algorithm and ML classification algorithm. Specifically, the terminal device acquires first identification data sent by different network devices, which include at least access points, gateways, switches, home routers, etc. These different network devices use different identification algorithms to identify the same traffic data and obtain the first identification data. For example, the access point device uses different application engines to identify the same traffic data. That is, different application engines correspond to different identification algorithms, and different identification algorithms are used to identify the same traffic data and obtain the first identification data.

[0040] S102. The first identification data is normalized to obtain the processed second identification data; Specifically, to obtain data in a unified format, the terminal device performs standardization processing on the obtained first identification data, that is, it uses different adapters to achieve real-time conversion of multi-source identification results. Each identification engine corresponds to a dedicated adapter with a built-in mapping rule table, which maps the original output fields in the first identification data (such as the pattern_id of DPI, the URL of the domain name database, and the dst_port of the port heuristic) to a unified application identification event structure, i.e., the second identification data. Based on the second identification data, a "basic application record" is established. The second identification data conforms to the AIEv (Application IdentificationEvent, AIEv, unified application identification event structure) JSON Schema JSON data format. This structure includes: a five-tuple stream identifier, engine source information, standardized application identifier, original feature vector, and extensible metadata. This structure design ensures that subsequent modules such as standardization, AI association, and telemetry stitching can directly consume the data without secondary parsing.

[0041] S103. The hierarchical weighted voting fusion algorithm is used to perform feature association and fusion on the second identification data to obtain the confidence level corresponding to different identification algorithms of different network devices. The hierarchical weighted voting fusion algorithm includes engine-level weighted voting and category-level voting. Specifically, the terminal device extracts features from the received second identification data to obtain multi-dimensional feature vectors, concatenates these multi-dimensional feature vectors, and combines them with contextual information to obtain model input data. The artificial intelligence algorithm is then used to fuse the model input data, resulting in confidence scores for different identification algorithms on different network devices. This process constructs a unified feature input through multi-dimensional feature vector concatenation and contextual association, enabling semantic-level association across engines. A hierarchical weighted voting fusion algorithm (HWVF) is used to perform feature association and result fusion on multiple fused model input data. When labels conflict, the conflict is pushed up to the application category layer, and a pre-trained XGBoost model is used to map the data to the final application, thereby obtaining confidence scores for different identification algorithms on different network devices.

[0042] S104. Based on the confidence level corresponding to different identification algorithms and the pre-established device capability registry, determine the execution policy corresponding to different network devices and send the execution policy to the network devices. The execution policy includes at least one or more of the following: DPI algorithm, URL parsing algorithm, port protocol identification algorithm and ML classification algorithm.

[0043] Specifically, a device capability registry is pre-established and stored on the terminal device. This registry includes preset confidence levels, device ID, device type, DPI, SNI, HTTP Host, domain name filtering, CPU, and memory. The device capability registry is searched based on the confidence levels corresponding to different identification algorithms. The preset confidence levels and the confidence levels corresponding to different identification algorithms are compared. Based on the comparison results, the device type corresponding to the confidence level of each identification algorithm is obtained. Then, based on the device type, the corresponding execution strategy is determined. For example, the execution strategy includes at least one or more of the following: DPI algorithm, URL parsing algorithm, port protocol identification algorithm, and ML classification algorithm. The corresponding execution strategy is then sent to the corresponding network device, thus achieving resource allocation and avoiding resource waste.

[0044] Some embodiments of this application receive first identification data from different network devices using different identification algorithms, and standardize the first identification data to obtain second identification data. Then, artificial intelligence algorithms are used to perform feature association and fusion on the second identification data to obtain the confidence levels corresponding to different identification algorithms. Then, combined with the device capability registry, execution policies corresponding to different network devices are obtained, and execution policies are sent to the network devices. In this way, the identification results of multi-source applications are standardized, fused, and associated with AI, and the policies are intelligently distributed in combination with device capabilities.

[0045] Another embodiment of this application further supplements the description of the strategy distribution method provided in the above embodiments.

[0046] Optionally, the first identification data is normalized to obtain the processed second identification data, including: Obtain the pattern matching results determined by the DPI algorithm, the URL parsing results determined by the URL parsing algorithm, the port data determined by the port protocol identification algorithm, and the field information in the feature vector determined by the ML classification algorithm; A pre-defined mapping rule table is used to map field information to standard fields; Based on the standard fields, the processed second identification data is determined. The second identification data includes at least the timestamp, the five-tuple identifier stream, the source of the identification engine, and the self-reported confidence of the identification algorithm.

[0047] Because the output formats of various engines in the existing technology are inconsistent and cannot be directly associated, context information (such as original confidence and features) is lost, and the same traffic cannot be concatenated across engines. Subsequent modules need to parse it repeatedly. Based on this, the embodiments of this application force a unified schema to facilitate downstream AI integration, retain all fields, support traceability, and realize flow-level association with flow_key + event_id. It can be converted once and used multiple times to improve system efficiency.

[0048] Specifically, the terminal device is equipped with a multi-source identification access module, which connects to multiple identification sources through a vendor adapter: DPI engine, domain name / URL database, port protocol heuristic detection, machine learning classifier, reputation database, etc. Using the above-mentioned various identification sources, i.e. different applications, the same traffic data is identified to obtain identification results from different manufacturers and in different formats, and the identification results are converted into a unified data structure.

[0049] The multi-source identification access module achieves real-time conversion from heterogeneous identification engines to a unified data structure through a vendor adapter. The specific conversion process is as follows: 1. Raw data intake; In this embodiment, the real-time conversion of multi-source identification results is achieved through a vendor adapter. Each identification engine corresponds to a dedicated adapter with a built-in mapping rule table, which maps the raw output fields (such as pattern_id of DPI, url of domain name database, and dst_port of port heuristic) to a unified application identification event structure (Application Identification Event, AIEv).

[0050] Each engine outputs the recognition results in the original format; For example: DPI engine: outputs the pattern matching results of the first 5 to 7 packets (pattern_id: 1201, app: "Dropbox"); Domain / URL Database (CSI type): Outputs URL resolution results (url: "cloud_storage", category: "cloud_storage"); Port protocol heuristic: output (src_port: 443, dst_port: 80, protocol: HTTPS); 2. Adapter parsing: Each engine corresponds to a dedicated adapter plugin; The adapter uses a predefined mapping rule table to map raw fields to standard fields. For example: pattern_id → app_id; url → domain; protocol → transport; 3. Feature extraction and structuring; Extract key features and fill in a unified structure; The adapter extracts comparable atomic features (such as domain name, SNI, HTTP Host, packet length sequence, TLS fingerprint, etc.) and appends engine metadata (source, confidence level, timestamp). 4. Unified output structure; all engines that convert to a unified application recognition event structure ultimately output the same JSON Schema; Its JSON Schema is as follows: { "event_id": "UUID", / / Globally unique event ID; "timestamp": "2025-04-05T10:23:11Z", / / UTC timestamp; "flow_key": {Group identifier stream (used for subsequent concatenation); "src_ip": "192.168.1.10", "dst_ip": "104.28.12.34", "src_port": 54321, "dst_port": 443, "protocol": "TCP }, "source": { / / Source of the identification engine "engine_type": "DPI | URL_DB | PORT_HEURISTIC | ML_CLASSIFIER", "vendor": "SKSpruce|IDL| Local_Rule", "engine_confidence": 0.65 / / Engine self-reported confidence level [0.0, 1.0] "identification": { / / Identification result (may conflict with multiple engines); "app_id": "dropbox", / Standardized application ID (lowercase, no spaces) "domain": "cloud drive", / / DNS server address (if applicable) "sni": "cloud drive", / / TLS SNI (if applicable) "http_host": "www.clouddisk", / / HTTP Host header (if present) "category": "cloud_file_sharing", / / Standard category "raw_pattern": "1201", / / DPI raw pattern ID (preserved for traceability) "features": { / / Optional feature vectors (for use by the AI ​​module) "pkt_sizes_first_5": [66, 122, 1455, 1455, 300], "tls_version": "TLS1.3", "ja3": "abc123..."}}, "metadata": { / / Extended fields "site_id": "HN-Campus", "device_id": "GW-01", "policy_scope": "global"}} All transformed results conform to the AIEv JSON Schema, which includes: a 5-tuple stream identifier, engine source information, a standardized application identifier, the original feature vector, and extensible metadata. This structure ensures that subsequent modules such as normalization, AI correlation, and telemetry stitching can directly consume the data without secondary parsing.

[0051] For example, when the DPI engine recognizes that traffic matches the Dropbox pattern (pattern_id=1201), the adapter converts it to: json { "source": {"engine_type": "DPI", "engine_confidence": 0.65}, "identification": {"app_id": "dropbox", "raw_pattern": "1201"}} At the same time, the domain name database recognizes the cloud drive and converts it to: json { "source": {"engine_type": "URL_DB", "engine_confidence": 0.92}, "identification": {"app_id": "dropbox", "domain": "Network Disk"}} The two are linked via flow_key, and subsequent modules are merged into a single Base Application Record. like Figure 2 As shown, it includes: Step 201: Input multiple unified application identification event structure events, i.e., the same flow-key; Step 202: Alias ​​normalization, that is, unifying the naming format, for example, lowercase + removing spaces / special characters: "cloud drive" → "dropbox"; Step 203: Semantic comparison, i.e., cross-engine association, such as domain alias database (cloud storage). (dbx.io), Levenshtein distance < 0.2, regular expression pattern matching; Step 204: Conflict arbitration to resolve contradictory indicators, for example, by using confidence-weighted voting: final_confidence = Σ(weight_i × conf_i); Step 205: Remove duplicates and insert them into the database to ensure uniqueness. For example, use app_id + domain as the primary key and a hash index. Step 206: Output the Base Application Record, which includes: {"app_id": "dropbox", / / (Primary key) Standardized application ID (unique) "canonical_name": "Dropbox", / / Human-readable name "aliases": [ / / Collection of aliases (after deduplication)] "Cloud storage", "dbx.io", "dropboxapi.com" ], "categories": [ / / Standard categories (multiple categories allowed)] "cloud_file_sharing", "saas", "productivity"], "confidence": 0.94, / / AI fusion confidence "source_engines": [ / / List of contributed engines] {"type": "DPI", "conf": 0.65, "pattern": "1201"}, {"type": "URL_DB", "conf": 0.92, "domain": "cloud storage"}, {"type": "SNI", "conf": 0.88}], "domains": [ / / Associated domains (deduplicated)] "cloud storage", "dropboxapi.com", "dbx.io"], "ports": [443, 80], / / Common ports "protocols": ["HTTPS", "HTTP"], / / Transport protocols "features": { / / Feature fingerprint (for subsequent AI use) "dpi_patterns": ["1201", "1202"], "tls_ja3": "abc123...", "http_user_agents": ["DropboxClient / .*"]}, "metadata": {"first_seen": "2025-01-10T08:00:00Z", "last_updated": "2025-04-05T12:00:00Z", "update_source": "telemetry_feedback", "risk_score": 6, / / 0-100 (from the reputation database) "is_shadow_it": false} In this embodiment, a unified application identification event structure event stream is received from the multi-source identification access module. Semantic standardization processing is performed on multiple identification results of the same traffic (associated through flow_key) or within a time window to finally generate a unique base application record.

[0052] Unlike the aforementioned "conversion process," which only unifies fields and structures, standardization focuses on semantic merging and deduplication. Different expressions such as "cloud drive", "dropbox inc", and "dbx.io" are merged through alias normalization (lowercase, removing spaces), domain alias database mapping, Levenshtein distance comparison and other methods. A confidence-weighted voting mechanism is used to arbitrate conflicts (e.g., if DPI identifies it as "file_transfer" while the URL database identifies it as "cloud_storage", the higher confidence level or preset priority is used). Use app_id as the primary key to ensure global uniqueness and avoid duplicate records.

[0053] The data structure of the Base Application Record, each Base Application Record contains the following core fields (see JSON structure for details): app_id: Standardized application identifier (primary key); aliases and domains: a collection of deduplicated aliases and domain names; confidence: the overall confidence level after the fusion of multiple engines; source_engines: Records the contributions of each engine for auditing and optimization; Features: Retain the original feature fingerprint for use by the AI ​​module or signature generation; metadata: Includes dynamic attributes such as first discovery time and risk score, and supports Shadow IT detection.

[0054] For example, suppose the same traffic triggers three unified application-identified event structures: DPI: app: "Dropbox", conf: 0.65 URL library: url: "cloud drive", conf: 0.92 SNI: sni: "dbx.io", conf: 0.88 Standardized module execution: Alias ​​normalization → All mapped to app_id: "dropbox" Domain merging → domains: ["cloud drive", "dbx.io"] Confidence score calculation → final_confidence = 0.3×0.65 + 0.4×0.92 + 0.3×0.88 = 0.94 Output a unique Base Application Record and store it in the application directory for global policy reference.

[0055] In this embodiment, fields in the first identification data are mapped through semantic merging, deduplication, and conflict arbitration. Semantic normalization and deduplication algorithms are used for standardization to obtain basic application records, including app_id, alias, domain name, confidence level, engine contribution, feature fingerprint, and metadata (complete JSON provided). String matching, semantic comparison, and domain name alias mapping are used to merge multiple identifiers of the same application.

[0056] Some embodiments of this application achieve real-time conversion of multi-source recognition results through adapters. Each recognition engine corresponds to a dedicated adapter with a built-in mapping rule table, which maps the original output fields to a unified application recognition event structure, ensuring that subsequent modules such as normalization, AI association, and telemetry stitching can directly consume the data without secondary parsing.

[0057] Optionally, a hierarchical weighted voting fusion algorithm is used to perform feature association and fusion on the second identification data to obtain the confidence levels corresponding to different identification algorithms for different network devices, including: Obtain the feature vector from the second recognition data. The feature vector includes at least enumerated features, text features, and sequence features. Based on the stream identifier and time window, the feature vector is subjected to context-enhanced association concatenation processing to obtain a concatenated multidimensional feature vector; A confidence-weighted and dynamic weight adaptive algorithm is used to perform hierarchical voting on the concatenated multidimensional feature vectors to obtain the confidence scores corresponding to different recognition algorithms for different network devices.

[0058] Specifically, in this embodiment, artificial intelligence algorithms (such as logistic regression, random forest, and deep learning models) are used to perform feature association and voting fusion on the results of multiple engines; the AI ​​association module receives multiple Base Application Record candidates (which may come from different engines or the same traffic) output by the normalization module, and constructs a unified feature input through multi-dimensional feature vector concatenation and context association to achieve semantic-level association across engines.

[0059] Feature association process diagram, such as Figure 3 As shown, it includes: Step 301: Input multiple Base Records (with the same flow-key); Step 302: Feature vector extraction. Extract quantifiable features from each Base Record. Structured features: confidence, risk_score; Enumerated features: engine_type, category; Text features: domain → TF-IDF vector; Sequence features: pkt_sizes_first_5 → normalized array. Step 303: Context association, enhance association using flow-level context, time alignment: only merge records within Δt ≤ 5s - Session binding: flow_key + session_id (if any) - Topology awareness: prioritize merging records with the same site_id / device_id; Step 304: Vector concatenation to construct a unified input vector, with final dimensions: N_engines × F_features (dynamic). Step 305: Output the fused feature vector.

[0060] Some embodiments of this application utilize artificial intelligence algorithms (such as logistic regression, random forest, and deep learning models) to perform feature association and voting fusion on the results of multiple engines, thereby obtaining the confidence levels corresponding to different recognition algorithms. This not only resolves conflicts between engines but also discovers clustering features of potential unknown applications.

[0061] Optionally, a confidence-weighted and dynamic weight adaptive algorithm is used to perform hierarchical voting on the concatenated multidimensional feature vectors to obtain the confidence levels corresponding to different recognition algorithms for different network devices, including: An engine-level weighted voting algorithm is used to process the concatenated multidimensional feature vectors to obtain the fused label and the first confidence score; Based on the weights of different recognition algorithms in historical data, as well as the fused labels and first confidence level, the confidence levels corresponding to different recognition algorithms for different network devices are determined.

[0062] For example, the F1-score of each identification algorithm is dynamically calculated based on the same type of traffic over the past 7 days.

[0063] Specifically, such as Figure 4 As shown, the embodiments of this application employ a hierarchical weighted voting fusion algorithm (HWVF) with "confidence weighting and dynamic weight adaptation," which consists of two levels of fusion: Algorithm Overview: HWVF (Hierarchical Weighted Voting Fusion) like Figure 4 As shown, it includes: Step 401: Multi-engine candidate tags; Step 402, Level-1: Engine-level weighted voting (resolving conflicting tags); Input: Identification results of the same traffic from n engines; Output: Preliminary fused label + confidence score.

[0064] ; Where: L represents the candidate application tag (e.g., "dropbox" or "box"); w i Dynamic weights for the engine; C i This represents the engine's original confidence level. This is an indicator function (label matching is 1).

[0065] Step 403, Level-2: Category-level voting (resolving semantic conflicts) If the conflict persists at the engine level (e.g., DPI is identified as "file_transfer", URL is identified as "cloud_storage"), then push it up to the category level: ；

[0066] in: Historical accuracy, i.e., the F1-score (telemetry feedback update) of the engine on similar traffic over the past 7 days. For context enhancement, encrypted traffic corresponds to DPI weight, plaintext URLs correspond to URL-DB weight, and high-risk domains correspond to reputation database weight. For example, the historical DPI accuracy is 0.68, and the current TLS traffic has w_DPI=0.7; URL-DB historical accuracy is 0.92, and domain name clarity w_URL = 0.9; The pre-trained categories are then input into the application mapping model (XGBoost), which outputs the final application type app_id.

[0067] Step 404: Finally, we obtain app-id+confidence.

[0068] Specifically, the pseudocode implementation is as follows: def hwvf_fusion(base_records): # Level-1: Engine-level voting votes = {} total_weight = 0 for rec in base_records: label = rec['app_id'] w = calculate_dynamic_weight(rec) # History + context c = rec['source_engines'][0]['conf'] votes[label] = votes.get(label, 0) + w * c total_weight += w fused_label = max(votes, key=votes.get) conf1 = votes[fused_label] / total_weight # Level-2: In case of conflict, class voting if len(set(r['app_id'] for r in base_records))>1: fused_label, conf1 = category_level_fusion(base_records) return { "final_app_id": fused_label, "final_confidence": round(conf1, 3), "fusion_level": 1 if conf1>0.8 else 2} This application embodiment uses a hierarchical weighted voting fusion algorithm (HWVF) to perform feature association and result fusion on multiple Base ApplicationRecords. First, multiple recognition records are associated with the flow_key and time window (Δt ≤ 5s), and structured, text, and sequence features are extracted and concatenated into a unified input vector.

[0069] The voting fusion algorithm is executed in two stages: Engine-level weighted voting: ; The weight wi is dynamically calculated based on historical accuracy and traffic context. 2. Category-level voting: When labels conflict, they are pushed up to the application category layer and mapped to the final application using a pre-trained XGBoost model.

[0070] For example, a certain traffic triggers the three-engine identification: DPI: dropbox (conf=0.65) URL_DB: dropbox (conf=0.92) Port heuristic: cloud_storage (conf=0.70) Dynamic weights: w_DPI=0.7, w_URL=0.9, w_HEUR=0.5 Engine-level voting: Dropbox votes = 0.7 × 0.65 + 0.9 × 0.92 = 1.283 → Winning final confidence score: 1.283 / (0.7 + 0.9 + 0.5) = 0.94 Output: final_app_id: "dropbox", confidence: 0.94 This application embodiment combines the historical accuracy, output confidence, and traffic characteristics of each engine to generate a comprehensive confidence score for application identification; this AI algorithm can not only resolve conflicts between engines, but also discover clustering characteristics of potential unknown applications.

[0071] Some embodiments of this application combine the historical accuracy, output confidence, and traffic characteristics of each engine to generate a comprehensive confidence score for application identification. This not only resolves conflicts between engines but also discovers clustering characteristics of potential unknown applications.

[0072] Optionally, based on the confidence levels corresponding to different identification algorithms and a pre-established device capability registry, the execution strategy corresponding to different network devices is determined, including: The signature type of each network device is determined by using a pre-established device capability registry. The signature type includes at least DPI signature, domain name list, SNI mode, and HTTP Host matching. Based on the confidence level, signature adaptation matrix, and policy mapping engine corresponding to different recognition algorithms, a matching process is performed in a pre-established device capability registry to determine the execution policy corresponding to different network devices.

[0073] The terminal device stores a "device capability registry" that describes the signature types supported by each device (DPI signature, domain name list, SNI mode, HTTP Host matching, etc.); and generates differentiated signature / policy bundles based on device capabilities to ensure that lightweight devices are not issued overly heavy rules.

[0074] In this embodiment, a normalization and deduplication module is used to determine the base application record (Base ApplicationRecord), the "authoritative archive" (semantic layer) of the application identity, which is used to identify globally unique, indexable, and for AI fusion and strategy reference, with rich data granularity (including aliases, history, features, and confidence). The generated signature / policy package is executed by the device capability awareness and signature generation module. The application identifies the "execution instructions" (syntax layer), which are used to reflect the device's executable, lightweight, and hardware-adaptive capabilities, with concise data granularity (containing only matching rules + metadata).

[0075] Furthermore, this application embodiment also provides a method for generating heterogeneous device capability-aware policy packages, including: obtaining global application identification results and unified policy intents; querying a pre-established device capability registry, wherein the registry records the signature support capabilities and resource thresholds of each device; automatically pruning identification rules that are not supported or have high overhead according to the resource thresholds, disabling DPI signatures when the device CPU < 2 cores or memory < 2GB, and retaining only the SNI mode and domain name list; encapsulating the pruned rules and policy intents into a lightweight capability-aware policy package; and issuing the Bundle to the corresponding network device to achieve optimal resource execution of the unified policy on heterogeneous devices.

[0076] Example of a signed bundle structure {"bundle_id": "BUNDLE-DROPBOX-20250405-v3", "target_device_types": ["gateway", "branch_router"], "signatures": { "dpi": [ / / Only send to devices that support DPI] {"pattern_id": 1201, "offset": 0, "mask": "FFFF"}, {"pattern_id": 1202, "offset": 2}], "sni": ["*.clouddisk"], / / Send to lightweight devices "http_host": ["cloud drive", "dbx.io"], "domain_list": ["cloud storage", "dropboxapi.com"]}, "policy_rules": [ {"action": "block", "scope": "role:contractor", "time": "business_hours", "app_id": "dropbox"}], "metadata": {"version": 3, "size_kb": 12, "generated_at": "2025-04-05T12:00:00Z", "valid_until": "2025-04-12T12:00:00Z"}} This application embodiment achieves automated, on-demand, and lightweight Bundle generation through "device capability registry + signature adaptation matrix + policy mapping engine".

[0077] like Figure 5 As shown, it includes: Step 501: Input global policy + BaseRecord; Step 502: Query the device capability registry; read the target device capabilities. Registry example: Enterprise Gateway GW-01 → {dpi: true, sni: true, cpu: 4core} Branch router BR-05 → {dpi: false, sni: true, cpu: 1core}; Step 503: Match signature type and select supported identification methods. Supported types: DPI signature, SNI mode, HTTP Host, domain name list, port protocol; Step 504: Trim redundant rules and remove unsupported / high-overhead rules. For low-end devices: Remove DPI signatures and keep only SNI + domain name. Step 505: Merge policy instructions, inject global policy, and globally "disable Dropbox" → device-level ACL; Step 506: Output a differentiated Bundle, serialized and versioned, in JSON / YAML format, with a checksum, and supporting incremental updates.

[0078] Device capability registration is represented as shown in Table 1: Table 1

[0079] Examples of differentiated bundle generation are shown in Table 2: Table 2

[0080] In this embodiment, the device capability awareness and signature generation module receives the AI-fused BaseApplication Record and global policy, and combines them with the device capability registry to automatically generate a differentiated signature / policy bundle, ensuring that lightweight devices do not experience performance degradation due to excessively heavy rules.

[0081] The Base Application Record is a semantically authoritative description of the application, containing rich information such as aliases, confidence levels, and features, used for global indexing and AI analysis. The Capability-aware Bundle, on the other hand, is a set of execution instructions for the application, containing only device-parseable matching rules (such as DPI modes and SNI regular expressions) and policy instructions, with a compact size and controllable version. These are not the same thing; the former is for the system to "think," while the latter is for the device to "execute."

[0082] The specific process of the differentiation generation mechanism is as follows: Capability query: Obtain the signature types and resource limits supported by the target device through the device registry; Signature matching: Extract the corresponding rules (such as DPI mode ID, domain name list) from the features field of the Base Record. Rule trimming: For devices that do not support DPI, automatically remove the DPI signature and only retain the SNI and domain name matching; Policy injection: Mapping global abstract policies (such as "prohibit high-risk applications during working hours") to device-level ACLs; Bundle encapsulation: Serializes to JSON, adds version number and expiration date, supports incremental updates and rollback.

[0083] For example, a global policy requires "Disable Dropbox".

[0084] For the high-end gateway GW-01: Distribute a complete Bundle, including DPI signature (pattern 1201), SNI mode, and HTTPHost matching; For the low-end branch route BR-05: only SNI mode (*.cloud drive) and domain blacklist are issued, and the bundle size is only 1 / 5 of the former.

[0085] This mechanism, through its registry query capabilities, signature matching, rule pruning, policy injection, and Bundle encapsulation, ensures policy consistency while minimizing resource consumption, making it particularly suitable for edge computing scenarios.

[0086] Some embodiments of this application maintain a "device capability registry" that describes the signature types supported by each device (DPI signature, domain name list, SNI mode, HTTP Host matching, etc.); and generate differentiated signature / policy bundles based on device capabilities to ensure that lightweight devices are not issued overly heavy rules.

[0087] Optionally, an enforcement policy is sent to the network device, including: Based on the preset intent information, determine the pre-set network topology, device labels of network devices, and role mappings; The execution strategy is encapsulated according to the pre-set encapsulation rules to obtain the encapsulated execution strategy; The encapsulated execution policy is sent to the corresponding network device.

[0088] In this embodiment, the policy distribution module on the terminal device intelligently selects target devices and distributes corresponding signatures and rules based on the global policy definition and network topology. It is responsible for accurately pushing the global abstract policy (administrator intent) and differentiated signature packages (Bundles) to the target network devices, achieving unified application management across devices and scenarios. It is not merely a simple rule distribution mechanism, but an automated distribution engine with intelligent selection, topology awareness, version control, and rollback protection.

[0089] The complete definition of policy distribution includes: the first layer is intent parsing, which includes administrators defining high-level policies, such as "prohibiting the engineering department from using high-risk cloud storage during working hours"; the second layer is target positioning, which intelligently selects controlled devices based on network topology, device tags, and role mapping; the third layer is rule encapsulation, which injects differentiated bundles and automatically matches device capabilities to generate lightweight rule packages; and the fourth layer is secure distribution, which includes versioned push and rollback, supporting incremental updates, verification, and failure rollback.

[0090] Distribution flowchart, such as Figure 6 As shown, it includes: Step 601: The administrator defines the global policy; Step 602: Policy parser, intent language → executable rule, using Policy Description Language (PDL): WHEN role=engineer AND time=09:00-18:00 THEN block app_category=high_risk_storage; Step 603, Topology Engine (Target Device Discovery), Topology-Aware Distribution, Maintaining Network Topology Tree (Site → Gateway → AP) - Tag Matching: site:SJ-Campus, role:contractor - Dynamic Discovery: Automatic Registration of Devices Upon Online Access; Step 604, Bundle Binding (Capability Adaptation): According to the capability injection rules, refer to the Capability-awareBundle mentioned above: High-end gateway → DPI+SNI, low-end AP → Domain Name Only; Step 605: Versioned distribution (incremental, full). The Bundle includes version and checksum, and only incremental rules (diff algorithm) are distributed. Canary release is supported (first 10% of devices). Step 606: Confirmation and Rollback. The device reports apply_status - failure exceeds threshold → automatically rollback to v-1.

[0091] For example, an administrator sets a policy "Disable Dropbox use in all branches nationwide (during working hours)," and the distribution process is as follows: Parsing: Convert to internal rule block app_id=dropbox when time=09:00-17:00 and site_tag=branch; Location: Topology scan revealed 127 branch routers (tagged "branch"). Binding: All devices only support SNI → Generate a lightweight bundle; json { "sni": ["*.clouddisk"], "action": "block", "schedule": "09:00-17:00"} Distribution: Version v17, incremental update (only 1 new SNI added), push success rate 99.2%. Confirmed: 1 device failed due to firmware error → Automatic rollback to v16.

[0092] Some embodiments of this application customize signature distribution based on the capabilities of different network devices, and determine different execution strategies for different network devices to reduce resource consumption.

[0093] The splicing process is as follows Figure 7 As shown, it includes: Step 701: The equipment transmits telemetry data back. Step 702: Standardize the input, unify the telemetry format, and have all devices send back Telemetry Event (TEv): json; Step 703: Multidimensional key matching to establish flow association. Primary key: 5-tuple (src_ip, dst_ip, src_port, dst_port, protocol). Secondary keys: SNI, HTTP Host, session_id (if any). Step 704: Time window merging, tolerating clock skew, the same flow_key is considered to be in the same flow within Δt ≤ 30s; Step 705: Feature fingerprint verification to prevent mis-spelling; compare pkt_sizes_first_5 and TLS JA3 similarity (cosine > 0.9); Step 706: The stitching is completed and AI analysis is performed. The stitched data is a Stitched Flow Record, which includes all engine matching results and unknown packet samples.

[0094] The example of the splicing result of telemetry segments is shown below:

[0095] After splicing: {"stitched_flow_id": "SF-20250405-001", "flow_key": "...", "timeline": ["GW-01@10:00:01", "AP-05@10:00:03", "BR-03@10:00:05"], "matched": { "DPI": "dropbox@0.65", "SNI": "cloud storage", "HTTP": "dbx.io"}, "unknown_samples": [[66,122,1455,...]], / / For AI clustering "ai_insight": "New subdomain dbx.io → Update Base Record"} AI Enhancements: Domain Clustering (DBSCAN) → dbx.io merged into Dropbox, discovering new aliases; Unknown Packet Sequences → Automatically extract DPI patterns and generate new signatures; Multi-Engine Comparison → Reduce DPI weights to correct misjudgments; Unknown Flow Clustering → Marked as is_shadow_it: true for Shadow IT detection.

[0096] The telemetry collection and AI enhancement module achieves continuous evolution of the application identification library through stream-level telemetry stitching and AI-driven adaptive optimization. It collects matching results and unknown traffic samples returned by devices; verifies the actual effect of signature packets and identifies engine blind spots; and uses AI to analyze the stitched complete stream to dynamically update the BaseApplication Record and signature library.

[0097] The specific steps for stream-level splicing, using the MKTS algorithm, are executed in the following order: Standardized intake: The device reverts to a traditional Telemetry Event structure; Multidimensional key matching: using the 5-tuple as the primary key and SNI / HTTP Host as the secondary key; Time window merging: Events within Δt ≤ 30s are grouped into the same stream; Feature fingerprint verification: The similarity between the packet length sequence and the JA3 fingerprint is >0.9; Output spliced ​​stream: contains full-link recognition results and unknown samples, for AI module clustering and feature extraction.

[0098] For example, some unknown traffic is marked as "unknown" by the DPI at the gateway, and its SNI is captured as "dbx.io" at the AP. After concatenation, the AI ​​module discovers: dbx.io has a highly similar packet length distribution to cloud storage (cosine similarity 0.96). Automatically add dbx.io to the Dropbox aliases field; Generate a new SNI signature and distribute it to all supported devices.

[0099] This closed-loop mechanism increases application identification coverage by 2-5% per week and enables Shadow IT to be automatically discovered.

[0100] Each device returns matching results, unknown traffic samples, and statistical information; the terminal device uses AI algorithms to perform "telemetry stitching" on telemetry data from multiple devices and engines to identify engine omissions and misjudgments; application aliases are dynamically updated, new features are generated, and the application identification library is continuously optimized.

[0101] Some embodiments of this application are based on an AI feedback mechanism using telemetry data, which can continuously optimize the recognition process.

[0102] Automatic mapping from intent to device rules (core mechanism), such as Figure 8 As shown, it includes: Step 801, High-level Intent Strategy; Step 802, Policy Parser; Step 803, Role / Time Mapping; Step 804: Expand application categories; Step 805, Bundle Generator (Capability Awareness); Step 806, Distribution Engine.

[0103] Example mapping: High level: block high_risk_storage for contractors Expand: [dropbox, onedrive_personal, wetransfer, mega] Gateway: DPI pattern 1201 + 4501 Router: SNI *.wetransfer.com The global policy abstraction layer provides an intent-based policy configuration interface, allowing administrators to define high-level policies by subject (role / user), time (schedule), and application category (category / risk), without needing to concern themselves with device type and signature format.

[0104] High-level abstraction strategies include the following elements: Main components: role, group, device_tag, and other identity identifiers; Time: Predefined (e.g., business_hours) or custom time period; Target: Application attributes such as app_category, risk_score, and app_id; Actions: block, allow, throttle, log, quarantine.

[0105] For example, if an administrator sets: "Outsourced personnel are prohibited from using high-risk cloud storage during working hours", the system will automatically resolve this to block app_category=high_risk_storage when role=contractor and time=09:00-18:00; Expanded into 12 applications (including Dropbox and WeTransfer); Generate 3 types of Bundles (gateway / AP / router) and distribute them to 127 devices; Policy changes require only one line of configuration modification and will take effect across the entire network within 1 minute.

[0106] This abstraction layer enables "one-time configuration, network-wide effect", significantly improving the efficiency of enterprise-level application management and control, and automatically mapping abstract policies into executable signatures and rules for each device.

[0107] Figure 9 This is a system architecture diagram of an embodiment of this application, showing the data flow and control flow relationships between the multi-source identification engine, the application intelligence engine modules, network devices, and administrators.

[0108] The multi-source recognition access module is used to receive recognition results from multiple heterogeneous application recognition engines; The normalization and deduplication module is used to merge different recognition results into basic application records; The AI ​​association and confidence calculation module is used to perform feature association and fusion on the recognition results of multiple engines through artificial intelligence algorithms, and output a comprehensive confidence score. The device capability awareness module is used to maintain the device capability registry. The signature generation and policy distribution module is used to generate and distribute differentiated signature and policy packages based on device capabilities; The telemetry collection and AI enhancement module is used to receive telemetry data transmitted back from the device, and use AI algorithms to stitch the results and enhance the model, thereby dynamically updating the application recognition library.

[0109] The application's intelligent engine allows administrators to define global policies by role / time / category and automatically map them to device-level rules.

[0110] Specifically, this application embodiment also provides a hierarchical weighted voting fusion method for multi-source application identification results, including receiving raw identification results from multiple identification engines such as DPI, URL parsing, SNI, port protocol, and ML; standardizing the results and extracting multi-dimensional feature vectors; and processing them using a hierarchical weighted voting fusion algorithm (HWVF), including: the first layer using engine-level weighted voting, with voting weight w i = α × historical 7-day F1-score + β × current traffic context enhancement factor; when there is still conflict at the engine level, enter the second-level category-level voting and output the final application ID through the pre-trained mapping model; output the fused application label and comprehensive confidence.

[0111] like Figure 10 As shown, the application identification flowchart (identification access → standardization → AI fusion → signature generation → distribution → telemetry feedback → optimization) illustrates the complete data processing link from multi-source access to AI closed-loop optimization.

[0112] Figure 11 It is the data model of the Base Application Record, showing its field structure, data types, and relationships.

[0113] In this application, the multi-source identification access module (conversion) unifies the original heterogeneous output into an intermediate format. The original results of each engine (different fields, formats, and names) are processed using field mapping and structured methods to obtain a unified application identification event structure event stream (with original confidence and features). For example, DPI outputs pattern_id:1201 → AIEv app_id:"dropbox"; This application embodiment transforms multiple unified application identification event structure events into a single, deduplicated BaseApplication Record. Multiple unified application identification event structure events (within the same flow_key or time window) are semantically merged, conflict resolved, and deduplicated. The multi-source identification results are standardized to establish a "Base Application Record" (the Base Application Record is unique, authoritative, and indexable).

[0114] For example, the three unified application identification event structure events (DPI, URL, SNI) all refer to Dropbox and are merged into one Base.

[0115] The embodiments of this application employ "syntactic normalization" to resolve the issue of inconsistent formats, and "semantic normalization" to resolve the issue of the same application being named in different ways.

[0116] Figure 12 This is a schematic diagram of the configuration interface for the global policy abstraction layer, illustrating the interaction method where administrators define intent-based policies by role, time, and category. Administrators define policies through high-level abstractions (defined by role / time / category, such as "Prohibit high-risk cloud storage during working hours"). These policies are manually set by administrators via the Web UI or API, but template-based configuration and AI recommendations are supported. The global policy abstraction layer allows administrators to use intent-based, natural language configurations without needing to worry about underlying device differences. Specifically, it includes 3 dimensions and 5 types of operations: The three dimensions include subject, time, and category / risk (What). The subject includes role, user, group, and device_tag, for example, role: contractor, group: engineering. The time period includes business hours, weekends, and custom, for example, 09:00-18:00, Mon-Fri; Category / Risk (What), including app_category, risk_level, app_id, such as high_risk_storage, dropbox.

[0117] Operations include: block / allow (block or allow); throttle (limit speed, e.g., 1Mbps); log (log only); quarantine (isolate and observe).

[0118] Strategy definition example (PDL syntax): policy_id: P-2025-001 Name: Prohibit Outsourced Personnel from Using High-Risk Cloud Storage when: role: contractor time: business_hours site: branch then: block: - app_category: high_risk_storage - risk_score: ">7" throttle: app_id: dropbox bandwidth: 512kbps log: true The strategy is manually configured by the administrator and supports template import and AI recommendation assistance. Its core functions are: unified intent: transforming natural language requirements into structured instructions; automatic mapping: after system parsing, combining BaseApplication Record and device capabilities to generate differentiated bundles; global consistency: ensuring that thousands of heterogeneous devices execute the same business logic; and simplified operation and maintenance: eliminating device-by-device configuration and reducing human error.

[0119] The specific settings can be entered manually by the administrator or by using a pre-set compliance template (such as GDPR, HIPAA). Based on historical telemetry recommendations: "WeTransfer was detected to be used by 80% of contractors. It is recommended to add blocking."

[0120] Optionally, the method further includes: Acquire historical remote sensing data from various network devices; The standardization process is updated based on historical remote sensing data.

[0121] Figure 13This is a processing example of the telemetry collection and AI enhancement module. It demonstrates the process of automatically updating application records and issuing new signatures after multi-device telemetry segments are spliced ​​at the flow level and clustered by AI. The telemetry splicing uses 5-tuples, SNI, HTTPHost, or session ID for flow level association. The telemetry collection and AI enhancement module collects the actual identification results from the devices, verifies the validity of the signature packets, captures "unknown traffic samples," identifies those missed by the engine, and dynamically generates new features, updates the application library, identifies misjudgments, and automatically optimizes the confidence weights through flow-level splicing and AI analysis. The system upgrades from 'passive identification' to 'active evolution', with each traffic becoming training data.

[0122] This application also provides an adaptive application identification optimization method based on telemetry closed-loop, comprising: receiving telemetry data backed by multiple network devices for the same traffic, wherein the telemetry data includes at least identification engine type, identification result, confidence level, and unknown traffic samples; using a multidimensional key-flow concatenation algorithm (MKTS) based on flow_key and time window to reassemble the telemetry data into a complete concatenated traffic profile; performing AI clustering analysis on the unknown traffic samples to discover new application aliases or subdomains; automatically updating the alias field or category mapping in the Base Application Record; and regenerating a differentiated execution strategy package (Capability-aware Bundle) based on the updated Base Application Record and distributing it to the network devices to achieve continuous adaptive optimization of the application identification library.

[0123] This application proposes a multi-key telemetry stitching (MKTS) algorithm that combines "multi-key + time window + feature fingerprint" to reassemble telemetry fragments scattered across multiple devices into a complete traffic profile.

[0124] In this application embodiment, multi-source identification and AI association significantly improve coverage and accuracy, thereby increasing the recognition rate; customized signature distribution based on device capabilities reduces resource consumption and achieves intelligent adaptation; the AI ​​feedback mechanism based on telemetry data can continuously optimize the identification library; unified policy management is achieved across devices, reducing manual configuration errors; and Shadow IT or unknown applications are promptly discovered through AI clustering and anomaly detection.

[0125] Example 1: Home Router Scenario Home routers only support domain name filtering, and the application's intelligent engine distributes a streamlined URL blacklist based on its capabilities; if telemetry data discovers a new subdomain, the system will automatically add it to the blocking list after AI analysis.

[0126] Example 2: Enterprise SD-WAN Scenario The enterprise gateway has full DPI capabilities, while the edge branch routers only support SNI matching. The intelligent engine generates differentiated signature packets based on these capabilities. The core gateway receives the full DPI signature, while the branch routers only receive the SNI pattern matching rules, ensuring unified policy distribution.

[0127] Example 3: AI Clustering for Discovering Unknown Applications When a certain type of traffic fails to be identified in all engines, the AI ​​module will cluster it based on traffic characteristics (packet length distribution, TLS fingerprint, etc.), alerting the administrator that a new application has appeared, and can be further confirmed through the "pilot release" policy.

[0128] It should be noted that each of the implementable methods in this embodiment can be implemented individually or in any combination without conflict. This application does not limit this.

[0129] Another embodiment of this application provides a strategy distribution apparatus for executing the strategy distribution method provided in the above embodiments.

[0130] like Figure 14 The diagram shown is a structural schematic of a policy distribution device provided in an embodiment of this application. The policy distribution device includes a receiving module 1401, a processing module 1402, a fusion module 1403, and a sending module 1404, wherein: The receiving module 1401 is used to receive first identification data sent by different network devices. The first identification data is obtained based on different identification algorithms. The different identification algorithms include at least the DPI algorithm, URL parsing algorithm, port protocol identification algorithm and ML classification algorithm. Processing module 1402 is used to standardize the first identification data to obtain the processed second identification data; The fusion module 1403 is used to perform feature association and fusion on the second identification data using a hierarchical weighted voting fusion algorithm to obtain the confidence levels corresponding to different identification algorithms of different network devices. The hierarchical weighted voting fusion algorithm includes engine-level weighted voting and category-level voting. The sending module 1404 is used to determine the execution policy corresponding to different network devices based on the confidence level corresponding to different identification algorithms and the pre-established device capability registry, and send the execution policy to the network devices. The execution policy includes at least one or more of the following: DPI algorithm, URL parsing algorithm, port protocol identification algorithm and ML classification algorithm.

[0131] Regarding the apparatus in this embodiment, the specific manner in which each module performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0132] Some embodiments of this application receive first identification data from different network devices using different identification algorithms, and standardize the first identification data to obtain second identification data. Then, artificial intelligence algorithms are used to perform feature association and fusion on the second identification data to obtain the confidence levels corresponding to different identification algorithms. Then, combined with the device capability registry, execution policies corresponding to different network devices are obtained, and execution policies are sent to the network devices. In this way, the identification results of multi-source applications are standardized, fused, and associated with AI, and the policies are intelligently distributed in combination with device capabilities.

[0133] Another embodiment of this application further illustrates the strategy distribution device provided in the above embodiments.

[0134] Optionally, the processing module is used for: Obtain the pattern matching results determined by the DPI algorithm, the URL parsing results determined by the URL parsing algorithm, the port data determined by the port protocol identification algorithm, and the field information in the feature vector determined by the ML classification algorithm; A pre-defined mapping rule table is used to map field information to standard fields; Based on the standard fields, the processed second identification data is determined. The second identification data includes at least the timestamp, the five-tuple identifier stream, the source of the identification engine, and the self-reported confidence of the identification algorithm.

[0135] Some embodiments of this application achieve real-time conversion of multi-source recognition results through adapters. Each recognition engine corresponds to a dedicated adapter with a built-in mapping rule table, which maps the original output fields to a unified application recognition event structure, ensuring that subsequent modules such as normalization, AI association, and telemetry stitching can directly consume the data without secondary parsing.

[0136] Optionally, the fusion module is used for: Obtain the feature vector from the second recognition data. The feature vector includes at least enumerated features, text features, and sequence features. Based on the stream identifier and time window, the feature vector is subjected to context-enhanced association concatenation processing to obtain a concatenated multidimensional feature vector; A confidence-weighted and dynamic weight adaptive algorithm is used to perform hierarchical voting on the concatenated multidimensional feature vectors to obtain the confidence scores corresponding to different recognition algorithms for different network devices.

[0137] Some embodiments of this application utilize artificial intelligence algorithms (such as logistic regression, random forest, and deep learning models) to perform feature association and voting fusion on the results of multiple engines, thereby obtaining the confidence levels corresponding to different recognition algorithms. This not only resolves conflicts between engines but also discovers clustering features of potential unknown applications.

[0138] Optionally, the fusion module is used for: An engine-level weighted voting algorithm is used to process the concatenated multidimensional feature vectors to obtain the fused label and the first confidence score; Based on the weights of different recognition algorithms in historical data, as well as the fused labels and first confidence level, the confidence levels corresponding to different recognition algorithms for different network devices are determined.

[0139] Some embodiments of this application combine the historical accuracy, output confidence, and traffic characteristics of each engine to generate a comprehensive confidence score for application identification. This not only resolves conflicts between engines but also discovers clustering characteristics of potential unknown applications.

[0140] Optionally, the sending module is used for: The signature type of each network device is determined by using a pre-established device capability registry. The signature type includes at least DPI signature, domain name list, SNI mode, and HTTP Host matching. Based on the confidence level, signature adaptation matrix, and policy mapping engine corresponding to different recognition algorithms, a matching process is performed in a pre-established device capability registry to determine the execution policy corresponding to different network devices.

[0141] Some embodiments of this application maintain a "device capability registry" that describes the signature types supported by each device (DPI signature, domain name list, SNI mode, HTTP Host matching, etc.); and generate differentiated signature / policy bundles based on device capabilities to ensure that lightweight devices are not issued overly heavy rules.

[0142] Optionally, the sending module is used for: Based on the preset intent information, determine the pre-set network topology, device labels of network devices, and role mappings; The execution strategy is encapsulated according to the pre-set encapsulation rules to obtain the encapsulated execution strategy; The encapsulated execution policy is sent to the corresponding network device.

[0143] Some embodiments of this application customize signature distribution based on the capabilities of different network devices, and determine different execution strategies for different network devices to reduce resource consumption.

[0144] Optionally, the receiving module is used for: Acquire historical remote sensing data from various network devices; The standardization process is updated based on historical remote sensing data.

[0145] Some embodiments of this application are based on an AI feedback mechanism using telemetry data, which can continuously optimize the recognition process.

[0146] Regarding the apparatus in this embodiment, the specific manner in which each module performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0147] It should be noted that each of the implementable methods in this embodiment can be implemented individually or in any combination without conflict. This application does not limit this.

[0148] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, can implement the operation of any of the methods corresponding to the policy distribution methods provided in the above embodiments.

[0149] This application also provides a computer program product, which includes a computer program, wherein when the computer program is executed by a processor, it can implement the operation of any of the methods corresponding to the policy distribution methods provided in the above embodiments.

[0150] like Figure 15 As shown, some embodiments of this application provide an electronic device 1500, which includes: a memory 1510, a processor 1520, and a computer program stored on the memory 1510 and executable on the processor 1520, wherein when the processor 1520 reads the program from the memory 1510 via a bus 1530 and executes the program, it can implement the method of any embodiment of the strategy distribution method described above.

[0151] Processor 1520 can process digital signals and can include various computing architectures. For example, it can be a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements multiple instruction set combinations. In some examples, processor 1520 can be a microprocessor.

[0152] Memory 1510 can be used to store instructions executed by processor 1520 or data related to the execution of instructions. These instructions and / or data may include code for implementing some or all of the functions of one or more modules described in the embodiments of this application. Processor 1520 of this disclosure embodiment can be used to execute instructions in memory 1510 to implement the methods shown above. Memory 1510 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memories well known to those skilled in the art.

[0153] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0154] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0155] 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 a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A strategy distribution method, characterized in that, The method includes: Receive first identification data sent by different network devices. The first identification data is obtained based on different identification algorithms. The different identification algorithms include at least the DPI algorithm, the URL parsing algorithm, the port protocol identification algorithm, and the ML classification algorithm. The first identification data is normalized to obtain the processed second identification data; A hierarchical weighted voting fusion algorithm is used to perform feature association and fusion on the second identification data to obtain the confidence scores corresponding to different identification algorithms for different network devices. The hierarchical weighted voting fusion algorithm includes engine-level weighted voting and category-level voting. Based on the confidence levels corresponding to the different identification algorithms and the pre-established device capability registry, the execution strategies corresponding to different network devices are determined, and the execution strategies are sent to the network devices. Based on the signature support types and resource thresholds recorded in the device capability registry, unsupported identification algorithm rules are trimmed to generate a differentiated execution strategy package. The execution strategies include at least one or more of the following: DPI algorithm, URL parsing algorithm, port protocol identification algorithm, and ML classification algorithm.

2. The strategy distribution method according to claim 1, characterized in that, The process of normalizing the first identification data to obtain the processed second identification data includes: Obtain the pattern matching result determined by the DPI algorithm, the URL parsing result determined by the URL parsing algorithm, the port data determined by the port protocol identification algorithm, and the field information in the feature vector determined by the ML classification algorithm; A pre-set mapping rule table is used to map the field information to standard fields; Based on the standard fields, the processed second identification data is determined, and the second identification data includes at least a UTC timestamp, a 5-tuple identifier stream, the identification engine source, and the self-reported confidence level of the identification algorithm.

3. The strategy distribution method according to claim 2, characterized in that, The step of using a hierarchical weighted voting fusion algorithm to perform feature association and fusion on the second identification data to obtain the confidence levels corresponding to different identification algorithms for different network devices includes: Obtain the feature vector from the second identification data, wherein the feature vector includes at least enumerated features, text features, and sequence features; Based on the stream identifier and time window, the feature vector is subjected to context-enhanced association concatenation processing to obtain a concatenated multidimensional feature vector; A confidence-weighted and dynamic weight adaptive algorithm is used to perform hierarchical voting on the concatenated multidimensional feature vector to obtain the confidence scores corresponding to different recognition algorithms for different network devices.

4. The strategy distribution method according to claim 3, characterized in that, The method employs a confidence-weighted and dynamic weight adaptive algorithm to perform hierarchical voting processing on the concatenated multidimensional feature vector, obtaining the confidence levels corresponding to different recognition algorithms for different network devices, including: An engine-level weighted voting algorithm is used to process the concatenated multidimensional feature vector to obtain the fused label and the first confidence score; Based on the weights of different identification algorithms in historical data, as well as the fused label and the first confidence level, the confidence levels corresponding to different identification algorithms for different network devices are determined.

5. The strategy distribution method according to claim 4, characterized in that, The step of determining the execution strategy for different network devices based on the confidence levels corresponding to the different identification algorithms and the pre-established device capability registry includes: Using the pre-established device capability registry, the signature type of each network device is determined, wherein the signature type includes at least DPI signature, domain name list, SNI mode, and HTTP Host matching; Based on the confidence level, signature adaptation matrix, and policy mapping engine corresponding to the different recognition algorithms, the system performs matching in the pre-established device capability registry to determine the execution policy corresponding to different network devices.

6. The strategy distribution method according to claim 1, characterized in that, The step of sending the execution policy to the network device involves, based on the signature support types and resource thresholds recorded in the device's capability registry, trimming unsupported identification algorithm rules and generating a differentiated execution policy package, including: Based on the preset intent information, determine the pre-set network topology, device labels of network devices, and role mappings; The execution strategy is encapsulated according to the pre-set encapsulation rules to obtain the encapsulated execution strategy; The encapsulated execution policy is sent to the corresponding network device.

7. The strategy distribution method according to claim 1, characterized in that, The method further includes: Acquire historical remote sensing data from various network devices; The normalization process is updated based on the historical remote sensing data.

8. A strategy distribution device, characterized in that, The device includes: The receiving module is used to receive first identification data sent by different network devices. The first identification data is obtained based on different identification algorithms, and the different identification algorithms include at least the DPI algorithm, the URL parsing algorithm, the port protocol identification algorithm, and the ML classification algorithm. The processing module is used to perform normalization processing on the first identification data to obtain the processed second identification data; The fusion module is used to perform feature association and fusion on the second identification data using a hierarchical weighted voting fusion algorithm to obtain the confidence scores corresponding to different identification algorithms for different network devices. The hierarchical weighted voting fusion algorithm includes engine-level weighted voting and category-level voting. The sending module is used to determine the execution strategy corresponding to different network devices based on the confidence level corresponding to the different identification algorithms and the pre-established device capability registry, and send the execution strategy to the network devices. Based on the signature support type and resource threshold recorded in the device capability registry, it trims unsupported identification algorithm rules and generates a differentiated execution strategy package. The execution strategy includes at least one or more of the following: DPI algorithm, URL parsing algorithm, port protocol identification algorithm, and ML classification algorithm.

9. The strategy distribution device according to claim 8, characterized in that, The processing module is used for: Obtain the pattern matching result determined by the DPI algorithm, the URL parsing result determined by the URL parsing algorithm, the port data determined by the port protocol identification algorithm, and the field information in the feature vector determined by the ML classification algorithm; A pre-set mapping rule table is used to map the field information to standard fields; Based on the standard fields, the processed second identification data is determined, and the second identification data includes at least a UTC timestamp, a 5-tuple identifier stream, the identification engine source, and the self-reported confidence level of the identification algorithm.

10. The strategy distribution device according to claim 9, characterized in that, The fusion module is used for: Obtain the feature vector from the second identification data, wherein the feature vector includes at least enumerated features, text features, and sequence features; Based on the stream identifier and time window, the feature vector is subjected to context-enhanced association concatenation processing to obtain a concatenated multidimensional feature vector; A confidence-weighted and dynamic weight adaptive algorithm is used to perform hierarchical voting on the concatenated multidimensional feature vector to obtain the confidence scores corresponding to different recognition algorithms for different network devices.

11. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it can implement the policy distribution method as described in any one of claims 1-7.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, characterized in that, when the program is executed by a processor, it can implement the policy distribution method according to any one of claims 1-7.

Images