Evidence-driven network intrusion detection method and system based on category autoencoder
Patent Information
- Application Number
- CN202611108372.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-24
- Publication Date
- 2026-10-13
AI Technical Summary
为缓解流量采集、检测扩展、告警证据不足和自动处置风险等问题,本发明提供了一种基于类别自编码器与类别自编码器的证据驱动型网络入侵检测方法及系统
(1)本发明依托P4数据平面可编程能力近源提取关键包级字段,在控制平面完成窗口特征构建,有效减少全量流量回传与中心化处理压力,显著提升流量感知效率;
Smart Images

Figure CN122908962A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of network information security technology, and relates to a network intrusion detection method and system. Specifically, it relates to an evidence-driven network intrusion detection method and system based on P4 programmable data plane, incremental detection by category autoencoder, category autoencoder analysis, and human-machine collaborative security execution. Background Technology
[0002] With the development of campus networks, edge access networks, and virtualized service environments, network traffic exhibits characteristics of multi-protocol, multi-directional, and multi-service parallelism. Abnormal behaviors such as denial-of-service attacks, scanning and probing, credential brute-force attacks, vulnerability exploitation, covert tunneling, and lateral movement continue to emerge. Existing research reviews on network intrusion detection indicate that deep learning methods can improve the ability to extract complex traffic features, but still face problems such as imbalanced samples, model generalization, deployment costs, and insufficient interpretability (Reference 1).
[0003] The P4 programmable data plane provides a new foundation for traffic awareness and security control. By defining packet parsing logic, matching action tables, and metadata reporting mechanisms in P4, key field extraction, basic forwarding, and entry matching can be completed at the switch side. Through P4Runtime, the control plane can dynamically manage data plane entries. Research on network defense using programmable data planes demonstrates that offloading some observation and execution capabilities to the data plane helps reduce the pressure on bypass mirroring and centralized processing (References 2 and 3).
[0004] However, due to limitations in storage space, computing resources, and the number of entries, complex detection models on P4 switches typically still need to be completed in the controller or backend services. Existing research on P4-NIDS has shown that P4 is suitable for high-performance monitoring and packet-level feature extraction tasks, but model inference, threshold calibration, attack category expansion, and handling orchestration still require cooperation from the control plane or application plane (Reference 4).
[0005] In terms of detection algorithms, autoencoders can learn low-dimensional representations of input features and identify samples that deviate from the training distribution based on reconstruction errors, making them suitable for anomaly detection and feature compression. Existing autoencoder-based intrusion detection schemes can achieve good results on specific datasets, but single models often tend to favor binary classification of normal / abnormal. When faced with new attack categories, known attack subdivisions, and unknown traffic rejection, they are prone to problems such as high model retraining costs, inflexible category expansion, and weakened capabilities of existing categories (References 5 and 6).
[0006] In the response phase, the scores, labels, or alarm fields output by the model cannot be directly equated with executable network control rules. Especially after bidirectional stream unified representation, time window aggregation, or field sorting processing, the source and destination fields in the detected event may not express the true attack direction; if the system directly issues blocking rules based on the detected event fields, there may be risks of reversed direction, excessively broad blocking scope, or accidental damage to protected services.
[0007] In recent years, large language models and multi-agent systems have begun to be used for alarm summarization, log analysis, intent parsing, and action suggestion generation. These agents can assist in multi-step security assessments; however, in cybersecurity scenarios, agent output should not bypass evidence verification, access control, and manual review before being directly written to network devices (Reference 7). Correspondingly, zero-trust architecture emphasizes continuous verification, least privilege, explicit authorization, and audit traceability, setting necessary boundaries for automated security actions (Reference 8).
[0008] Therefore, there is still a need for a network intrusion detection method and system that can simultaneously achieve low-overhead traffic perception, incremental anomaly detection, directional evidence tracing, agent-assisted judgment, human-machine collaborative auditing, and P4 security execution closed loop, in order to reduce deployment and model update costs and improve the reliability, controllability, and traceability between detection conclusions and handling actions.
[0009] Reference 1: Su Shubin, Xiao Limin, Li Shupan, Huang Xingwang, Xie Shutong, Wu Bo. A review of research on network intrusion detection based on deep learning [J]. Journal of Information Security, 2026, 11(1): 79-101. Reference 2: Hu Yuxiang, Pan Fan, Cui Pengshuai, et al. A review of network defense technology based on programmable data plane [J]. Chinese Journal of Computers, 2025, 48(8): 1943-1975. Document 3: Hauser F, Häberle M, Merling D, et al. A survey on data planeprogramming with P4: Fundamentals, advances, and applied research[J]. Journal of Network and Computer Applications, 2023, 212: 103561. Document 4: Chen Y, Layeghy S, Manocchio LD, et al. P4-NIDS: High-Performance Network Monitoring and Intrusion Detection in P4[C] / / IntelligentComputing-Proceedings of the Computing Conference. Cham: Springer NatureSwitzerland, 2025: 355-373. Document 5: Berahmand K, Daneshfar F, Salehi ES, et al. Autoencoders and their applications in machine learning: a survey[J]. Artificial Intelligence Review, 2024, 57(2): 28. Document 6: Félix BAH, Victoire KE, Pacôme B, et al. Intrusion Detection for Edge-IoT Using LSTM-Autoencoder[J]. Open Journal of Applied Sciences, 2025, 15(9): 2638-2647. Document 7: Xi Z, Chen W, Guo X, et al. The rise and potential of large language model based agents: a survey[J]. Science China Information Sciences, 2025, 68(2): 121101. Document 8: Rose S, Borchert O, Mitchell S, et al. Zero trust architecture[J]. NIST Special Publication, 2020, 800(207): 1-52. Summary of the Invention To alleviate problems such as traffic collection, detection expansion, insufficient alarm evidence, and risks of automatic handling, this invention provides an evidence-driven network intrusion detection method and system based on category autoencoders.
[0010] The technical solution adopted by the method of the present invention is: an evidence-driven network intrusion detection method based on category autoencoders, comprising the following steps: Step 1: When network traffic arrives at the programmable switch, the network data packets are parsed through the P4 data plane, basic forwarding and access control matching are performed, and packet-level metadata is reported. Step 2: Aggregate the packet-level metadata according to the normalized bidirectional quintuple and time window to generate traffic window features; Step 3: Input the traffic window features into the pre-trained category autoencoder, calculate the reconstruction error corresponding to each category, select candidate categories, and output the detection events corresponding to normal traffic, known attack traffic, or unknown traffic according to the candidate category threshold. Step 3: Input the traffic window features into multiple pre-trained class autoencoders and calculate the reconstruction error for each class. First, filter candidate classes based on the threshold of each class, and then select the class with the smallest original reconstruction error from the candidate classes that pass the threshold as the selected class. When no class passes the threshold, output an unknown event. When the selected class is normal, output a normal event; otherwise, output a known attack event. Step 4: When the detected event is an abnormal event or an unknown event, associate the detected event with the original packet-level observation record, parse the true communication direction of the abnormal traffic and generate direction evidence to obtain the evidence set S. e Dominant direction d and confidence level of evidence; Step 5: Combine evidence confidence, directional evidence, security policies, and user intent to generate risk statements and candidate rule plans, forming a manual review package that includes abnormal events, directional evidence, risk statements, candidate rule plans, unknowns, and suggested actions, and receive the manual review results; Step 6: After manual review and approval and the P4 security-deployed access control meets the preset policy requirements, write the precise five-tuple control rules to the programmable switch through the unified P4 security-deployment service; Step 7: Record the P4 operation results, audit logs, and rollback basis, and display the abnormal events, directional evidence, audit status, P4 issuance status, audit records, and rollback status.
[0011] As a preferred embodiment, step 2 includes the following sub-steps: Step 2.1: Normalize the source and destination endpoints into bidirectional flow identifiers K. i It also records the orientation identifier d of each packet relative to the normalization direction. i The normalization process is represented as: ; In the formula, a i and bi Let K represent the endpoint pairs consisting of the source and destination ends, respectively. i For the normalized bidirectional stream identifier, d i This serves as the directional identifier for packet-level observation records relative to the normalized direction. , These represent the original source address, source port, destination address, and destination port of the record, respectively. For protocols without ports, the port value is recorded as 0. Endpoints In this total order, less than or equal to the endpoints When the original source endpoint is located at the first end of the normalized flow identifier. ,otherwise ; Indicates the first i The IP protocol number recorded in the packet-level metadata digest record; Step 2.2: Based on the packet timestamp t i and window length Determine the window number and form a window sample set by combining the same bidirectional flow identifier and the packet-level observation records within the same time window:
[0012] In the formula, This represents the traffic characteristic record corresponding to the i-th data packet; Representing records Timestamps under a unified time base; Δ indicates the window length using the same time unit; Indicates rounding down; Indicates the window number where the record is located; K and b These represent the target normalized flow identifier and the target window number, respectively. This represents the set of traffic characteristics for all data packets within the same network flow and the same time window. Step 2.3: Calculate the duration, number of packets, total number of bytes, direction count, TCP flag count, arrival time interval, and protocol encoding within the statistical window to form a fixed-dimensional traffic window feature vector x. {K,b} ; ; ; In the formula, T is the window duration; N and L are the total number of packets and the total number of bytes, respectively; These represent the number of normalized forward packets, the number of normalized reverse packets, the number of normalized forward bytes, and the number of normalized reverse bytes, respectively. These are the minimum, maximum, and average package lengths, respectively. Each of the six TCP flags—SYN, ACK, RST, FIN, PSH, and URG—corresponds to a specific number of records in which the corresponding flag is set. The mean and maximum intervals between adjacent records are represented by a single packet window, both of which are set to 0. These represent the indices of the TCP, UDP, and ICMP protocols, respectively. Representing records The packet length; I() represents the indicative function; i Indicates the record index in the collection; Indicates the TCP flag mask; m This represents the bitmask of the TCP flags to be counted; where & represents bitwise AND, not logical conjunction. These represent the maximum and minimum timestamp values recorded within the window, respectively.
[0013] Preferably, in step 3, the category autoencoder consists of an encoder and a decoder; For each traffic window feature x to be detected, its reconstruction error on each type of autoencoder is calculated to form an error set. Among them, R c (x) represents the reconstruction error of the category c autoencoder, where C is the set of categories already existing in the model library of the current category autoencoder; , , , ;in, d =21; and They represent the first j Original features and normalized features; and The shared normalized parameters fitted using only the training set are frozen during the validation and online phases; ε is the zero-span protection factor. ()and () represent the encoder and decoder of category c autoencoder, respectively; This represents the reconstructed value of the j-th dimension of the normalized input; It is the sum of the squared errors of each of the 21 dimensions; Then, the category with the smallest reconstruction error is selected as the candidate category. ; Finally, the detection results are output based on the candidate category threshold. This includes normal test results, abnormal test results, or unknown test results; ; In the formula, τ c The threshold value corresponds to the candidate category; when a candidate category fails the threshold constraint, an unknown result is output. When the candidate category is the normal category and meets the threshold constraint, the output is a normal result. When the candidate category is a non-normal category and meets the threshold constraint, an abnormal result is output. .
[0014] Preferably, in step 4, the source address field, destination address field, source port field, destination port field, protocol type field, and ingress port field observed in the original observation records are extracted to generate directional evidence and obtain the evidence set S. e Dominant direction d The confidence level (conf) is used to ensure that subsequent ACL rules apply in the correct communication direction. The process of generating directional evidence first involves reading the event identifier, normalized flow identifier, and time window; then, querying candidate records in the Digest index running from a specified source; recalculating the normalized flow identifier for each record and excluding mismatched records; restoring the direction identifier based on the original endpoints and normalization order; counting the number of packets and bytes in each direction and determining the dominant direction; extracting the actual observation quintuple and ingress port summary from the dominant direction record; and combining the event hash, query window, direction statistics, sample reference and hash, observation quintuple, evidence status, and confidence level into directional evidence and persistently binding it.
[0015] in, Indicates the first i Each data packet corresponds to a traffic characteristic record; 'e' indicates a detection event. This indicates the primary key of the stream to which the data packet belongs, i.e., the 5-tuple identifier; Indicates the stream identifier corresponding to the target event; , These represent the start and end times of the event window, respectively; δ represents the query time tolerance; if To obtain the initial query set from the Digest index according to the source, event stream identifier, and extended time window, then To The evidence set is formed by recalculating the normalized bidirectional stream identifiers of the records and removing mismatched records. Indicates the number of packets in direction d; for China d The sum of packet lengths, written into the evidence digest of the unidirectional flow in the program as the audit information for the direction bytes, is not included in the d. Selection and calculation of confidence level of evidence; Indicates the dominant direction with the most packets; I() represents the indicator function; For recording Packaging length; ; ; ; ; ;
[0016] in, , , , and These represent sample coverage, quintuple field completeness, target concentration, interaction stability, and inbound port clustering, respectively. I() represents the preset threshold for sufficient baseline samples; I() represents the indicator function. , , , , These represent the determination of the validity, legality, and completeness of the source IP, destination IP, source port, destination port, and transport protocol, respectively. Indicates the total number of messages accessing the dominant target; This represents a unique identifier hash calculated from the message's 5-tuple, payload characteristics, and communication timing. This represents the baseline hash value pre-stored for normal access behavior in the business baseline; This indicates the inbound physical or logical port number of the i-th message entering the detection device; This means iterating through all inbound ports that have seen traffic and taking the maximum percentage as the final indicator; ; in, Indicates the minimum sample threshold; Indicates the minimum threshold for the consistency index; conf cap Set an upper limit for the confidence level; when evidence is insufficient, limit the confidence level (conf) to the upper limit (conf). cap within; The following steps ensure that subsequent ACL rules apply in the correct communication direction: the event normalized flow identifier is consistent with the normalized flow identifier obtained from sample recalculation; the dominant direction is determined according to the number of packets in each direction, and... Calculate the dominance of the direction. Indicates the number of data packets in the dominant traffic direction; This indicates the total number of data packets in the entire bidirectional flow; the source IPv4 address, destination IPv4 address, IP protocol number, source port, and destination port of the candidate rule are consistent with the first observation record in the dominant direction; the directional evidence status is verified or reviewed; the evidence confidence level reaches the risk policy threshold; the candidate rule can only be issued when the above directional evidence conditions are met simultaneously with other deployed access control.
[0017] As a preferred option, in step 5, the action template, target switch, and TTL in the user's intent are first verified; then, based on the detection results, the candidate for viewing only, the blocking candidate, or the rule recovery path is determined; for the blocking candidate, it is verified whether the event is a known attack that has passed the category threshold, and the consistency of the directional evidence status, confidence level, and five-tuple field is verified; after the verification is passed, a candidate rule plan is constructed, and a risk description and manual review package are generated in combination with the risk strategy.
[0018] Preferably, in step 6, the determination rule for P4 securely issuing access control is as follows: ; In the formula, I() represents the indicator function; A This indicates that the operation was initiated by an administrator-privileged account; O This indicates the offline maintenance window period; H Indicates high-priority service traffic; K Indicates the source address of a trusted host on the internal network; E Indicates the emergency response mode for abnormal situations; F This represents a statically predefined whitelist stream; T This indicates that the TTL is positive and does not exceed the policy upper limit; P This indicates a strategy based on protected targets; C This indicates that the number of active rules in the target switch and the table is less than the policy capacity limit; R This indicates that the current workflow has been manually approved; J This indicates that the idempotent key is valid and has not been used in different requests; only when... G Write is allowed when =1. Preferably, in step 7, the application display module displays abnormal events, directional evidence, audit status, P4 issuance status, audit records, and rollback status; As a preferred option, in step 7, the abnormal events, directional evidence, review status, P4 issuance status, audit records and rollback status are displayed through the application display module; The application demonstration module also provides an external tool entry point, which is used to encapsulate backend capabilities for external tools or smart agents to call; however, this entry point is not a new permission system and cannot bypass backend authentication, role-based access control, risk policies, manual review, and P4-issued access control.
[0019] Preferably, the category autoencoder is a trained category autoencoder; the training process includes the following steps: (1) Construct a training sample set and label the traffic window features according to the normal traffic category and the attack traffic category; (2) Normalize the training samples and create category-specific training data for each traffic category; (3) Train a corresponding autoencoder for each traffic category to minimize the error between the input traffic features and the reconstructed traffic features; (4) Generate the corresponding category threshold based on the reconstruction error of the validation set, and add the trained autoencoder model, normalization parameters and category threshold to the model library; when a new attack category appears, only train the autoencoder corresponding to the new attack category and add it to the model library, while the trained category autoencoder remains unchanged.
[0020] The technical solution adopted by the system of the present invention is: an evidence-driven network intrusion detection system based on a category autoencoder, comprising: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, enable the one or more processors to implement the evidence-driven network intrusion detection method based on a category autoencoder.
[0021] The present invention also provides an evidence-driven network intrusion detection product based on a category autoencoder, comprising computer program instructions that, when the computer program instructions are executed on a computer, server, controller, or edge computing device, work in conjunction with a programmable switch running a P4 program to enable the computer, server, controller, or edge computing device to execute the evidence-driven network intrusion detection method based on a category autoencoder.
[0022] Compared with the prior art, the present invention has the following beneficial effects: (1) This invention relies on the programmable capability of the P4 data plane to extract key packet-level fields from near source and completes window feature construction in the control plane, effectively reducing the pressure of full traffic backhaul and centralized processing, and significantly improving traffic perception efficiency; (2) This invention achieves accurate identification of known attack categories, reliable rejection of unknown traffic, and incremental expansion of new attack categories through a category-specific autoencoder model library. New attack categories only need to train the corresponding autoencoder to complete the model update, which greatly reduces the update cost and reduces interference to existing category models, ensuring the stable evolution of the detection system. (3) This invention relies on the original packet-level observation records to restore the real communication direction and calculate the confidence level of the evidence, which can avoid problems such as direction deviation, excessive control scope or accidental damage to protected services caused by issuing blocking rules based solely on the aggregated field, and improve the accuracy of detection and handling. (4) This invention transforms the detection results into an interpretable, auditable, traceable, and rollback-able closed-loop network control process through intelligent agent-assisted judgment, manual review, unified P4 security policy distribution, full-link audit record and policy rollback mechanism, which significantly improves the reliability and controllability of security response and provides a new solution for building an accurate, reliable and evolvable intelligent network protection system. Attached Figure Description
[0023] The technical solutions of the present invention will be further illustrated below using embodiments and specific implementation methods. In addition, some accompanying drawings are used in the description of the technical solutions. Those skilled in the art can obtain other drawings and the intent of the present invention from these drawings without any creative effort.
[0024] Figure 1 This is a flowchart of a method according to an embodiment of the present invention; Figure 2 This is a system framework diagram of an embodiment of the present invention; Figure 3 This is a flowchart of the P4 flow characterization construction module in an embodiment of the present invention; Figure 4 This is a flowchart of the reproducible experimental traffic generation submodule in an embodiment of the present invention; Figure 5 This is a flowchart illustrating the workflow of the P4 data plane traffic sensing submodule in this embodiment of the invention. Figure 6 This is a flowchart illustrating the workflow of the flow window representation construction submodule in an embodiment of the present invention. Figure 7 This is a flowchart of the incremental detection module of the category autoencoder in an embodiment of the present invention; Figure 8 This is a flowchart of the evidence-driven intelligent agent secure execution module in an embodiment of the present invention; Figure 9 This is a schematic diagram of the directional evidence parsing and alarm judgment evidence binding mechanism in an embodiment of the present invention; Figure 10 This is a schematic diagram of the experimental network topology in an embodiment of the present invention. Detailed Implementation
[0025] To facilitate understanding and implementation of the present invention by those skilled in the art, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.
[0026] First, the technical terms used in this embodiment will be explained and described: The P4 data plane is the programmable switch-side processing plane of the P4 program, used to complete packet parsing, basic forwarding, access control matching, and Digest metadata reporting.
[0027] Packet-level observation records: The P4 data plane reports raw records for each individual data packet, including source address, destination address, port, protocol type, packet length, flags, ingress port, and timestamp. These records are used for traffic window characterization construction and directional evidence tracing.
[0028] Normalized bidirectional quintuple: A flow identifier obtained by uniformly sorting the endpoints of the communication, used to avoid splitting the same bidirectional communication into two unrelated unidirectional flows, and to retain packet-level direction identifiers.
[0029] Category autoencoder: An autoencoder model trained separately for normal traffic categories or specified attack traffic categories; the category threshold refers to the decision threshold determined based on the reconstruction error of the corresponding category validation set.
[0030] Directional evidence: The true communication direction and its confidence level recovered from the original packet-level observation records.
[0031] P4 secure access control: A verification mechanism that allows writing to control rules only when permissions, evidence, auditing, table structure, protected targets, and rule capacity all meet the requirements.
[0032] Model training test samples: The sample data selected in this embodiment for model training and effect verification includes three categories: normal traffic, TCP SYN Flood attack traffic, and UDP Flood attack traffic.
[0033] Category autoencoder training dataset: Training and validation sets are divided for the three types of traffic mentioned above, which are used for training the corresponding category models and generating category determination thresholds.
[0034] Normal Recall: The proportion of genuine, legitimate traffic that is correctly identified as legitimate traffic; it measures the system's ability to retain legitimate business traffic.
[0035] Anomaly Recall: The proportion of genuine attack traffic that is correctly identified as anomaly traffic; it measures the system's attack detection capability.
[0036] Unknown Rate: The proportion of samples rejected by the model and labeled as unknown, reflecting the model's handling of unknown traffic and boundary samples.
[0037] False Positive Rate (PPR): The proportion of genuine, normal traffic that is incorrectly identified as abnormal traffic. It is used to measure the degree of false alarms in model decisions.
[0038] Known Attack Precision: The proportion of actual attack samples out of those predicted as attacks by the model; used to measure the accuracy of attack classification results.
[0039] Please see Figure 1 This embodiment provides an evidence-driven network intrusion detection method based on a category autoencoder, which includes the following steps: Step 1: When network traffic arrives at the programmable switch, the network data packets are parsed through the P4 data plane, basic forwarding and access control matching are performed, and packet-level metadata is reported. Step 2: Aggregate the packet-level metadata according to the normalized bidirectional quintuple and time window to generate traffic window features; Step 3: Input the 21-dimensional flow window features constructed in a fixed order into multiple pre-trained category-specific autoencoders and calculate the reconstruction error for each category. First, filter candidate categories based on the threshold of each category, and then select the category with the smallest original reconstruction error from the candidate categories that pass the threshold as the selected category. When no category passes the threshold, output an unknown event. When the selected category is normal, output a normal event; otherwise, output a known attack event. Step 4: When the detected event is an abnormal event or an unknown event, associate the detected event with the original packet-level observation record, parse the true communication direction of the abnormal traffic and generate direction evidence to obtain the evidence set S. e Dominant direction d and confidence level of evidence; Step 5: Combine evidence confidence, directional evidence, security policies, and user intent to generate risk statements and candidate rule plans, forming a manual review package that includes abnormal events, directional evidence, risk statements, candidate rule plans, unknowns, and suggested actions, and receive the manual review results; The "unknown items" refer to evidence gaps, unresolved fields, analytical hypotheses, or operations awaiting confirmation for the current detected event, which differs from "unknown items" formed when all categories fail to pass the threshold. The suggested actions are determined from a preset action template based on the detected event type, category threshold pass status, directional evidence status and confidence level, candidate field consistency, and security policy. These actions can be categorized as simply viewing, precise five-tuple blocking candidates, or restoring deployed rules. No deployable blocking rules are generated for normal events and unknown events; only for known attacks that have passed the category threshold are blocking candidates generated for manual review after directional evidence and policy verification are passed.
[0040] First, the action template, target switch, and TTL in the user intent are verified. Then, based on the detection results, the candidate for viewing only, blocking, or rule recovery path is determined. For blocking candidates, it is verified whether the event is a known attack that has passed the category threshold, and the consistency of the directional evidence status, confidence level, and five-tuple fields is verified. After the verification is passed, a candidate rule plan is constructed, and a risk statement and manual review package are generated in conjunction with the risk strategy. Manual review can approve, modify, or reject. When the workflow generates the review package, P4 writing is not performed directly. Writing is only allowed after approval and re-verification of the entire department's access control through an independent deployment entry point.
[0041] Step 6: After manual review and approval and the P4 security-deployed access control meets the preset policy requirements, write the precise five-tuple control rules to the programmable switch through the unified P4 security-deployment service; The precise 5-tuple control rule refers to a P4 entry that precisely matches the source IPv4 address, destination IPv4 address, IP protocol number, source port, and destination port actually observed in the directional evidence. In one implementation, candidate entries are written into the network intrusion detection access control table of the inbound processing module, an access control drop action is executed, and a positive TTL, directional evidence identifier, and rollback information are associated; candidate fields must be equal to each directional evidence item by item and cannot be supplemented by the model or agent. Precise 5-tuple matching itself is a rule implementation method; the combined features of this embodiment lie in the binding of events and directional evidence, manual review, and the constraints imposed by joint access control on its writing.
[0042] Step 7: Record the P4 operation results, audit logs, and rollback basis, and display the abnormal events, directional evidence, audit status, P4 issuance status, audit records, and rollback status through the application display module.
[0043] Please see Figure 2This embodiment provides an evidence-driven network intrusion detection system based on a category autoencoder, applicable to abnormal traffic detection and security response scenarios in campus network access boundaries, campus experimental networks, or edge access networks. This scenario includes a data plane, a control plane, an application plane, and, as defined in the invention, a P4 traffic characterization construction module, a category autoencoder incremental detection module, an evidence-driven intelligent agent security execution module, and an application display module. When network traffic reaches the programmable switch, the P4 traffic characterization construction module extracts packet-level observation records through the data plane and constructs traffic window features in the control plane; the category autoencoder incremental detection module outputs detection events based on a model library and thresholds; the evidence-driven intelligent agent security execution module binds the detection events with the original Digest evidence, generating directional evidence, risk descriptions, candidate rule plans, and manual review packages; after review is passed and the P4 security-issued access control meets preset policy requirements, the unified P4 security-issued service writes the control rules; the application display module displays the event, evidence, review, P4 operation, audit, and rollback status. The data plane is responsible for protocol parsing, basic forwarding, ACL matching, and Digest metadata reporting of data packets entering the programmable switch; the control plane is responsible for maintaining packet-level observation records, generating traffic window features, loading category autoencoder model libraries, performing online detection, binding evidence, and calling the P4 security delivery service; the application plane is responsible for displaying event, evidence, audit, deployment, and audit information.
[0044] In one implementation, please refer to Figure 3 The P4 traffic characterization construction module includes a reproducible experimental traffic generation submodule, a P4 data plane traffic awareness submodule, and a traffic window characterization construction submodule. The reproducible experimental traffic generation submodule is used to construct the experimental topology and generate normal traffic and attack traffic. The P4 data plane traffic awareness submodule is used to perform packet parsing, basic forwarding, Digest metadata reporting, and five-tuple access control matching. The traffic window characterization construction submodule is used to organize packet-level observation records into traffic window features that can be used by the detection model.
[0045] In one implementation, the process of the reproducible experimental traffic generation submodule is as follows: Figure 4 As shown: First, configure the experimental parameters and build a Mininet topology including the client, server and BMv2 switch. After completing the P4 pipeline loading and connectivity initialization, select normal traffic, SYN Flood attack traffic or UDP Flood attack traffic according to the profile. After being generated with labels and the raw records are collected, they are sent to subsequent processing. Each traffic type corresponds to an independent random seed. The training data is generated from the profile traffic to ensure that the experiment is reproducible.
[0046] In one implementation, please refer to Figure 5The P4 data plane traffic awareness submodule runs the P4 program on the BMv2 programmable switch. After a data packet enters the switch, the P4 parser parses the Ethernet, IPv4, TCP, UDP, or ICMP protocol headers, extracting fields such as source address, destination address, source port, destination port, protocol type, packet length, TCP flags, ingress port, and timestamp. The switch first performs a NIDS ACL table match; if a verified and issued control rule is matched, it drops or rate-limits the packet; otherwise, it continues to the IPv4 basic forwarding table for normal forwarding.
[0047] In one implementation, in addition to forwarding, the P4 data plane traffic awareness submodule also reports key fields to the control plane via a Digest message mechanism. The Digest record, as raw packet-level observation data, is used not only to construct traffic window characteristics but also for subsequent directional evidence analysis and security response auditing. For example, when a switch observes a data packet with source address 10.0.0.2, destination address 10.0.0.4, source port 49152, destination port 80, protocol TCP, length 74 bytes, and SYN flag set, it reports this record, along with the ingress port and timestamp, to the control plane.
[0048] Please see Figure 6 In one implementation, the flow window characterization construction submodule converts packet-level observation records reported from the data plane into flow window features usable by the model. To avoid feature redundancy caused by bidirectional communication, the system first normalizes the source and destination endpoints into bidirectional flow identifiers K. i It also records the orientation identifier d of each packet relative to the normalization direction. i The normalization process can be expressed by the following formula: (1) In the formula, a i and b i Let K represent the endpoint pairs consisting of the source and destination ends, respectively. i For the normalized bidirectional stream identifier, d i This serves as the directional identifier for packet-level observation records relative to the normalized direction. , These represent the original source address, source port, destination address, and destination port of the record, respectively. For protocols without ports, the port value is recorded as 0. Endpoints In this total order, less than or equal to the endpoints When the original source endpoint is located at the first end of the normalized flow identifier. ,otherwise ; Indicates the first i The packet-level metadata digest records the IP protocol number; after comparing the source and destination endpoints... As a standardized bidirectional flow identifier The third component, and does not participate in the comparison of the order of endpoints.
[0049] The system then uses the packet timestamp t i The window number is determined by the window length Δ, and the window sample set is formed by combining the same bidirectional flow identifier and the packet-level observation records within the same time window. The process can be expressed by the following formula: (2) In the formula, Indicates the first i Traffic characteristic records corresponding to each data packet; Representing records Timestamps under a unified time base; Δ indicates the window length using the same time unit; Indicates rounding down; Indicates the window number where the record is located; K and b These represent the target normalized flow identifier and the target window number, respectively. This represents the set of traffic characteristics for all data packets within the same network flow and the same time window.
[0050] Subsequently, the system statistically analyzes fields such as duration, number of packets, number of bytes, direction count, TCP flag count, arrival time interval, and protocol encoding within the statistical window, forming a fixed-dimensional traffic window feature vector. x {K,b} ; (3) (4) In the formula, T is the window duration; N and L are the total number of packets and the total number of bytes, respectively; These represent the number of normalized forward packets, the number of normalized reverse packets, the number of normalized forward bytes, and the number of normalized reverse bytes, respectively. These are the minimum, maximum, and average package lengths, respectively. Each of the six TCP flags—SYN, ACK, RST, FIN, PSH, and URG—corresponds to a specific number of records in which the corresponding flag is set. The mean and maximum intervals between adjacent records are represented by a single packet window, both of which are set to 0. These represent the indices of the TCP, UDP, and ICMP protocols, respectively. Representing records The packet length; I() represents the indicative function; i Indicates the record index in the collection; Indicates the TCP flag mask;m This represents the bitmask of the TCP flags to be counted; where & represents bitwise AND, not logical conjunction. These represent the maximum and minimum timestamp values recorded within the window, respectively.
[0051] Please see Figure 7 In one embodiment, the category autoencoder incremental detection module includes a category autoencoder training submodule and a reconstruction error competition inference submodule. The category autoencoder training submodule receives the traffic window characteristics generated by the traffic window characterization construction submodule, normalizes the data, and divides the training samples according to normal traffic, SYN Flood attack traffic, UDP Flood attack traffic, or other attack categories. The reconstruction error competition inference submodule loads the category autoencoder model library and corresponding thresholds during the online phase, and outputs normal, known attack, or unknown traffic detection events.
[0052] In one implementation, the training process of the category autoencoder training submodule includes the following steps: (1) Construct a training sample set and label the traffic window features according to the normal traffic category and the attack traffic category; (2) Normalize the training samples and create category-specific training data for each traffic category; (3) Train a corresponding autoencoder for each traffic category to minimize the error between the input traffic features and the reconstructed traffic features; (4) Generate the corresponding category threshold based on the reconstruction error of the validation set, and add the trained autoencoder model, normalization parameters and category threshold to the model library; when a new attack category appears, only train the autoencoder corresponding to the new attack category and add it to the model library, while the trained category autoencoder remains unchanged.
[0053] The autoencoder consists of an encoder and a decoder. The encoder maps the input flow features to a low-dimensional latent space, and the decoder recovers the reconstruction result based on the latent representation. The training objective is to minimize the error between the input features and the reconstructed features. In one implementation, the model uses mean squared error as the training loss and generates class thresholds using the quantiles of the reconstruction error on the validation set. The processes of normalization, encoding / decoding, reconstruction error, training objective, threshold generation, and incremental update of the model library are represented as follows: (5) in, d =21; and They represent the first j Original features and normalized features; and The shared normalized parameters fitted using only the training set are frozen during the validation and online phases; ε is the zero-span protection factor. and These are the encoder and decoder for category c autoencoder, respectively; This represents the reconstructed value of the j-th dimension of the normalized input; It is the sum of the squared errors of each of the 21 dimensions.
[0054] (6) In the formula, D c V represents the training sample set of category c. c Let τ represent the set of validation samples for category c. c P is the threshold for category c. 99.5 This represents the 99.5th quantile; M represents the current model library. and These represent the autoencoder and its threshold corresponding to the newly added category, respectively. Indicates that for the first c Class samples, adjust parameters unique to that class. and .
[0055] The reconstruction error competitive inference submodule loads the category autoencoder model library and corresponding thresholds during the online detection phase. For the traffic feature x to be detected, the system calculates its reconstruction error on each category autoencoder, forming an error set; then, it selects the category with the smallest reconstruction error as the candidate category, and outputs the detection result as normal, abnormal, or unknown based on the candidate category threshold. The process of outputting the error set, candidate category, and label can be represented as follows: (7) In the formula, R(x) is the set of reconstruction errors of the input sample under each category autoencoder, C is the set of categories already existing in the current model library, and c The candidate categories are obtained during the online detection phase based on the competition for the minimum reconstruction error.
[0056] Finally, the detection results are output based on the candidate category threshold. This includes normal test results, abnormal test results, or unknown test results; (8) In the formula, τ c d(x) represents the category threshold corresponding to the candidate category, and d(x) represents the detection label output by the category autoencoder incremental detection module. When the candidate category fails the threshold constraint, an unknown result is output; when the candidate category is a normal category and meets the threshold constraint, a normal result is output; when the candidate category is an abnormal category and meets the threshold constraint, an abnormal result is output.
[0057] In one implementation, for example, during the online detection phase, the reconstruction errors of a traffic window sample on the three category models—normal, SYNFlood, and UDPFlood—are 0.135, 0.028, and 0.117, respectively, corresponding to thresholds of 0.090, 0.050, and 0.060. Since the reconstruction error of the SYNFlood category is the smallest and lower than its category threshold, the system outputs an anomaly detection event and marks its candidate category as SYNFlood. If the minimum reconstruction error is still higher than the corresponding category threshold, the system outputs an unknown event and enters the manual review or new category training process.
[0058] In one implementation, when a new attack type appears, the system only needs to collect samples of the new category and train a new category autoencoder, and then add the model and its category threshold to the model library according to equation (6). Existing category models can remain unchanged, thereby reducing the overall retraining overhead and reducing the risk of interference from the training of new categories to the original category recognition ability, significantly improving the flexibility of attack category expansion.
[0059] Please see Figure 8 In one implementation, the evidence-driven intelligent agent security execution module includes a directional evidence parsing and alarm judgment submodule, an intelligent agent strategy orchestration submodule, and a human-machine collaborative security execution submodule. The directional evidence parsing and alarm analysis submodule is used to generate directional evidence based on the detected events and the original packet-level observation records. The intelligent agent policy orchestration submodule is used to generate risk descriptions and handling suggestions based on alarm content, directional evidence and security policy constraints. The human-machine collaborative security execution submodule is used to execute network control actions and save audit records through a unified P4 security delivery service after manual review and approval.
[0060] Please see Figure 9 In one implementation, after the evidence samples are matched, the directional evidence parsing and alarm analysis submodule extracts fields such as the actual observed source address, destination address, source port, destination port, protocol type, and ingress port from the original observation records to generate directional evidence. Since bidirectional flow window aggregation may be used during the online inference phase, the source address and destination address in the detected event may not necessarily correspond to the actual attack direction. Therefore, the directional evidence is used to ensure that subsequent ACL rules are applied in the correct communication direction.
[0061] The process of generating directional evidence involves first reading the event identifier, normalized flow identifier, and time window; then querying candidate records in the Digest index running from a specified source; recalculating the normalized flow identifier for each record and excluding mismatched records; restoring the directional identifier based on the original endpoints and normalization order; counting the number of packets and bytes in each direction and determining the dominant direction; extracting the actual observation quintuple and ingress port summary from the dominant direction record; and persistently binding the event hash, query window, directional statistics, sample references and hashes, observation quintuples, evidence status, and confidence level into directional evidence. This directional evidence is used to verify the handling direction and reduce the risk of mishandling.
[0062] The evidence set, dominant direction, and confidence level can be calculated according to equations (9) and (10).
[0063] (9) in, Indicates the first i Each data packet corresponds to a traffic characteristic record; 'e' indicates a detection event. This indicates the primary key of the stream to which the data packet belongs, i.e., the 5-tuple identifier; Indicates the stream identifier corresponding to the target event; , These represent the start and end times of the event window, respectively; δ represents the query time tolerance; if To obtain the initial query set from the Digest index according to the source, event stream identifier, and extended time window, then To The evidence set is formed by recalculating the normalized bidirectional stream identifiers of the records and removing mismatched records. Indicates the number of packets in direction d; for China d The sum of packet lengths, written into the evidence digest of the unidirectional flow in the program as the audit information for the direction bytes, is not included in the d. Selection and calculation of confidence level of evidence; Indicates the dominant direction with the most packets; I() represents the indicator function; For recording Packaging length; ; ; (10) ; ;
[0064] in, , , , and These represent sample coverage, quintuple field completeness, target concentration, interaction stability, and inbound port clustering, respectively. I() represents the preset threshold for sufficient baseline samples; I() represents the indicator function. , , , , These represent the determination of the validity, legality, and completeness of the source IP, destination IP, source port, destination port, and transport protocol, respectively. Indicates the total number of messages accessing the dominant target; This represents a unique identifier hash calculated from the message's 5-tuple, payload characteristics, and communication timing. This represents the baseline hash value pre-stored for normal access behavior in the business baseline; This indicates the inbound physical or logical port number of the i-th message entering the detection device; This means iterating through all inbound ports that have seen traffic and taking the maximum percentage as the final indicator; (11) in, Indicates the minimum sample threshold; Indicates the minimum threshold for the consistency index; conf cap Set an upper limit for the confidence level; when evidence is insufficient, limit the confidence level (conf) to the upper limit (conf). cap Within.
[0065] The following steps ensure that subsequent ACL rules apply in the correct communication direction: the event normalized flow identifier is consistent with the normalized flow identifier obtained from sample recalculation; the dominant direction is determined according to the number of packets in each direction, and... Calculate the dominance of the direction. Indicates the number of data packets in the dominant traffic direction; This indicates the total number of data packets in the entire bidirectional flow; the source IPv4 address, destination IPv4 address, IP protocol number, source port, and destination port of the candidate rule are consistent with the first observation record in the dominant direction; the directional evidence status is verified or reviewed; the evidence confidence level reaches the risk policy threshold; the candidate rule can only be issued when the above directional evidence conditions are met simultaneously with other deployed access control.
[0066] In one implementation, for example, a SYN Flood detection event is bound to 42 original Digest samples, including 39 forward packets and 3 reverse packets. All fields are complete and the ingress ports are consistent. The directional evidence parsing and alarm analysis submodule determines the forward direction as the dominant direction and calculates an evidence confidence level of 0.86. If the preset evidence threshold is 0.75, the event can proceed to policy orchestration; if the number of samples is insufficient, the directional dominance is low, or key fields are missing, the system only generates a review prompt and does not proceed to the blocking process. This evidence threshold significantly reduces the risk of mishandling caused by ambiguity in aggregated fields.
[0067] In one implementation, the agent policy orchestration submodule orchestrates agent policies based on anomalous events, directional evidence, and security policy constraints. Different functional agents can perform tasks such as alarm summarization, risk analysis, action intent parsing, policy planning, semantic security checks, field validity verification, risk assessment, and report generation. Agents can only generate action suggestions or rule plans; they cannot create events, fields, P4 entries, or actions out of thin air, nor can they directly write to the P4Runtime.
[0068] In one implementation, the human-machine collaborative security execution submodule transforms the candidate disposal plans output by the agent policy orchestration submodule into a manual review package. The review package includes anomaly events, directional evidence, candidate rule plans, risk descriptions, unknowns, and suggested actions. Operators can approve, modify, or reject the disposal plan in the application display module. The system only allows P4 security deployment when the evidence is complete, the policy verification is passed, the disposal target is not a protected object, and the manual review is passed.
[0069] In one implementation, the unified P4 secure delivery service is the system's P4 write access control. All write requests from the front-end, back-end workflows, external tools, or agent interfaces must pass through this service. Before delivery, the system checks user permissions, idempotent keys, switch write permissions, P4 table structure, matching fields, action parameters, TTL, protected targets, and directional evidence; after delivery, the system saves the deployment time, operator identity, rule status, and rollback basis, thereby achieving auditable, traceable, and rollbackable security response processes. The P4 secure delivery access control can be determined according to formula (12).
[0070] (12) In the formula, I() represents the indicator function; A This indicates that the operation was initiated by an administrator-privileged account; O This indicates the offline maintenance window period; H Indicates high-priority service traffic; K Indicates the source address of a trusted host on the internal network; EIndicates the emergency response mode for abnormal situations; F This represents a statically predefined whitelist stream; T This indicates that the TTL is positive and does not exceed the policy upper limit; P This indicates a strategy based on protected targets; C This indicates that the number of active rules in the target switch and the table is less than the policy capacity limit; R This indicates that the current workflow has been manually approved; J This indicates that the idempotent key is valid and has not been used in different requests. Only when... G Write operations are allowed when the value is 1. Discarding actions are prohibited on protected ports.
[0071] In one implementation, the application display module provides a unified human-computer interaction interface, including functions such as login authentication, operation status display, event collection, analysis process viewing, audit processing, P4 operation control, audit log viewing, and rollback entry. Operators can view system operation status, event source status, and recently detected events on the dashboard page; view the abnormal event analysis process, structured results, and final report on the workflow page; centrally review pending handling solutions on the audit page; view switch connection status, P4 table structure, deployment results, and rollback entry on the P4 operation page; and view login, event collection, analysis process, manual review, and P4 distribution records on the audit page.
[0072] The application demonstration module also provides an entry point for external tools, allowing backend capabilities to be encapsulated and invoked by external tools or agents. However, this entry point is not a new permission system and cannot bypass backend authentication, role-based access control, risk policies, manual review, and P4-based access control. Through this module, the detection, evidence, review, execution, and audit statuses within the system can be continuously viewed by operators, forming an interpretable, auditable, and rollback-capable security operation closed loop, significantly improving the transparency of human-machine collaborative processing.
[0073] To further illustrate the synergistic effect of the above methods and system modules, this embodiment provides experimental results and verification: In one implementation, to verify the completeness of steps 1 to 7 of the above method, an experimental environment is built using Mininet, BMv2, P4Runtime, FastAPI backend, and Next.js frontend console. Please refer to [link to relevant documentation]. Figure 10 The experimental network consisted of three client hosts, one server host, and one BMv2 P4 switch. The system used the MS-IDS dataset for training and testing. This dataset was constructed by integrating publicly available network security datasets such as CICIDS-2018, UNSW-NB15, and TON-IoT, and normal traffic, TCP SYN Flood attack traffic, and UDP Flood attack traffic were selected as training and testing samples for the model.
[0074] In the category autoencoder training process in step 3, the sizes of the training set and validation set are shown in the table below. They are used to train three category models, namely the normal category, the SYN Flood category, and the UDP Flood category, and to generate corresponding category thresholds.
[0075]
[0076] In the online detection phase of step 4, after model training and threshold calibration, a full performance evaluation was conducted on a test set containing 724,935 samples, employing a hierarchical decision-making strategy that pits gating against the original error. The detection performance results are shown in the table below.
[0077]
[0078] The detection results show that this embodiment has a high recognition rate for attack traffic, with an abnormal traffic recall rate of 97.05% and a known attack precision rate of 99.95%. The category-specific autoencoder can learn the traffic characteristics of SYN Flood and UDP Flood attacks well and has good distinguishing ability on the test set; the proportion of unknown traffic is 0.01%, and the false positive rate is 4.81%, indicating that the current threshold configuration can control the risk of false positives while maintaining the sensitivity of anomaly detection. The above results show that the category model library can reserve space for subsequent expansion of attack categories while maintaining detection capabilities.
[0079] Regarding system function verification, the experiment completed a closed loop from traffic generation, P4 data plane perception, traffic window representation construction, online detection by category autoencoders, event ingestion, directional evidence parsing, agent analysis, manual review, to P4 ACL policy deployment. Mininet was able to stably generate normal and attack traffic, the BMv2 switch could export digest data, the online inference service could generate predicted events, the backend could create analysis reports and review packets, the directional analysis module could recover the true communication direction from the original digest records, and the control plane could deploy ACL policies through P4DeploymentService. This closed-loop verification demonstrates that the present invention can not only output detection tags but also transform detection conclusions into a network control process with evidence, review, and rollback justification.
[0080] In terms of workflow execution, when large language models are used to assist analysis, alarm triage, intent parsing, and report generation can improve the readability of analysis results. When real-time requirements are higher, the system can use deterministic rule processes to reduce response latency. Regardless of the analysis mode used, all links involving network control use deterministic verification mechanisms and manual review results as the final execution basis, thus balancing the efficiency of intelligent analysis with the security boundaries of key control actions at a macro level.
[0081] This embodiment also provides an evidence-driven network intrusion detection product based on multi-agent collaboration and incremental autoencoder, including computer program instructions. When the computer program instructions are run on a computer, the computer executes the evidence-driven network intrusion detection method based on multi-agent collaboration and incremental autoencoder.
[0082] This invention implements an evidence-driven network intrusion detection scheme based on multi-agent collaboration and incremental autoencoders. On the data plane, it leverages a P4 programmable switch to achieve near-source traffic perception and packet-level observation recording. Combined with standardized bidirectional flow representation and precise five-tuple control rule distribution, it achieves accurate handling of attack traffic, effectively reducing the bandwidth and computing power overhead of full traffic backhaul. Simultaneously, it employs a category-specific autoencoder to construct an incrementally expandable model library. Through a reconstructed error competition mechanism, it completes multi-type traffic discrimination, significantly reducing the training cost of adding new attack categories while ensuring detection accuracy. At the application demonstration level, it combines original directional evidence with multi-agent collaborative orchestration to generate interpretable handling schemes. Supplemented by manual review, access control, full-link auditing, and policy rollback mechanisms, it comprehensively ensures the security and controllability of control actions, significantly improving detection scalability, response reliability, and security operation traceability in complex network environments.
[0083] It should be understood that the embodiments described above are only some, not all, of the embodiments of the present invention. Furthermore, the technical features of the various embodiments or individual embodiments provided by the present invention can be arbitrarily combined to form feasible technical solutions. Such combinations are not constrained by the order of steps and / or structural composition patterns, but must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.
[0084] It should be understood that the above description of the preferred embodiments is quite detailed, but it should not be considered as a limitation on the scope of protection of this invention. Those skilled in the art, under the guidance of this invention, can make substitutions or modifications without departing from the scope of protection of the claims of this invention, and all such substitutions or modifications fall within the scope of protection of this invention. The scope of protection of this invention should be determined by the appended claims.
Claims
1. An evidence-driven network intrusion detection method based on a category autoencoder, characterized in that, Includes the following steps: Step 1: When network traffic arrives at the programmable switch, the network data packets are parsed through the P4 data plane, basic forwarding and access control matching are performed, and packet-level metadata is reported. Step 2: Aggregate the packet-level metadata according to the normalized bidirectional quintuple and time window to generate traffic window features; Step 3: Input the traffic window features into multiple pre-trained class autoencoders and calculate the reconstruction error for each class respectively; First, candidate categories are selected based on the thresholds for each category. Then, the candidate category with the smallest original reconstruction error is selected from the candidate categories that pass the thresholds. When no category passes the threshold, an unknown event is output. If the selected category is normal, output normal events; otherwise, output known attack events. Step 4: When the detected event is an abnormal event or an unknown event, associate the detected event with the original packet-level observation record, parse the true communication direction of the abnormal traffic and generate direction evidence to obtain the evidence set S. e Dominant direction d and confidence level of evidence; Step 5: Combine evidence confidence, directional evidence, security policies, and user intent to generate risk statements and candidate rule plans, forming a manual review package that includes abnormal events, directional evidence, risk statements, candidate rule plans, unknowns, and suggested actions, and receive the manual review results; Step 6: After manual review and approval and the P4 security-deployed access control meets the preset policy requirements, write the precise five-tuple control rules to the programmable switch through the unified P4 security-deployment service; Step 7: Record the P4 operation results, audit logs, and rollback basis, and display the abnormal events, directional evidence, audit status, P4 issuance status, audit records, and rollback status.
2. The evidence-driven network intrusion detection method based on category autoencoders according to claim 1, characterized in that, Step 2 includes the following sub-steps: Step 2.1: Normalize the source and destination endpoints into bidirectional flow identifiers K. i It also records the orientation identifier d of each packet relative to the normalization direction. i The normalization process is represented as: ; In the formula, a i and b i Let K represent the endpoint pairs consisting of the source and destination ends, respectively. i For the normalized bidirectional stream identifier, d i This serves as the directional identifier for packet-level observation records relative to the normalized direction. , These represent the original source address, source port, destination address, and destination port of the record, respectively. For protocols without ports, the port value is recorded as 0. Endpoints Less than or equal to the endpoint in total order When the original source endpoint is located at the first end of the normalized flow identifier. ,otherwise ; Indicates the first i The IP protocol number recorded in the packet-level metadata digest record; Step 2.2: Based on the packet timestamp t i and window length Determine the window number and form a window sample set by combining the same bidirectional flow identifier and the packet-level observation records within the same time window: In the formula, This represents the traffic characteristic record corresponding to the i-th data packet; Representing records Timestamps under a unified time base; Δ indicates the window length using the same time unit; Indicates rounding down; Indicates the window number where the record is located; K and b These represent the target normalized flow identifier and the target window number, respectively. This represents the set of traffic characteristics for all data packets within the same network flow and the same time window. Step 2.3: Calculate the duration, number of packets, total number of bytes, direction count, TCP flag count, arrival time interval, and protocol encoding within the statistical window to form a fixed-dimensional traffic window feature vector x. {K,b} ; ; ; In the formula, T is the window duration; N and L are the total number of packets and the total number of bytes, respectively; These represent the number of normalized forward packets, the number of normalized reverse packets, the number of normalized forward bytes, and the number of normalized reverse bytes, respectively. These are the minimum, maximum, and average package lengths, respectively. Each of the six TCP flags—SYN, ACK, RST, FIN, PSH, and URG—corresponds to a specific number of records in which the corresponding flag is set. The mean and maximum intervals between adjacent records are represented by a single packet window, both of which are set to 0. These represent the indices of the TCP, UDP, and ICMP protocols, respectively. Representing records The packet length; I() indicates the indicator function; i Indicates the record index in the collection; Indicates the TCP flag mask; m This represents the bitmask of the TCP flags to be counted; where & represents bitwise AND, not logical conjunction. These represent the maximum and minimum timestamp values recorded within the window, respectively.
3. The evidence-driven network intrusion detection method based on category autoencoders according to claim 1, characterized in that: In step 3, the category autoencoder consists of an encoder and a decoder; For each traffic window feature x to be detected, its reconstruction error on each type of autoencoder is calculated to form an error set. Among them, R c (x) represents the reconstruction error of the category c autoencoder, where C is the set of categories already existing in the model library of the current category autoencoder; , , , ;in, d =21; and They represent the first j Original features and normalized features; and The shared normalized parameters fitted using only the training set are frozen during the validation and online phases; ε is the zero-span protection factor. ()and () represent the encoder and decoder of category c autoencoder, respectively; This represents the reconstructed value of the j-th dimension of the normalized input; It is the sum of the squared errors of each of the 21 dimensions; Then, the category with the smallest reconstruction error is selected as the candidate category. ; Finally, the detection results are output based on the candidate category threshold. This includes normal test results, abnormal test results, or unknown test results; ; In the formula, τ c The threshold value corresponds to the candidate category; when a candidate category fails the threshold constraint, an unknown result is output. When the candidate category is the normal category and meets the threshold constraint, the output is a normal result. When the candidate category is a non-normal category and meets the threshold constraint, an abnormal result is output. .
4. The evidence-driven network intrusion detection method based on category autoencoder according to claim 1, characterized in that: In step 4, the source address field, destination address field, source port field, destination port field, protocol type field, and ingress port field of the actual observations are extracted from the original observation records to generate directional evidence and obtain the evidence set S. e Dominant direction d The confidence level (conf) is used to ensure that subsequent ACL rules apply in the correct communication direction. The process of generating directional evidence first involves reading the event identifier, normalized flow identifier, and time window; then, querying candidate records in the Digest index running from a specified source; recalculating the normalized flow identifier for each record and excluding mismatched records; restoring the direction identifier based on the original endpoints and normalization order; counting the number of packets and bytes in each direction and determining the dominant direction; extracting the actual observation quintuple and ingress port summary from the dominant direction record; and combining the event hash, query window, direction statistics, sample reference and hash, observation quintuple, evidence status, and confidence level into directional evidence and persistently binding it. in, Indicates the first i Each data packet corresponds to a traffic characteristic record; 'e' indicates a detection event. This indicates the primary key of the stream to which the data packet belongs, i.e., the 5-tuple identifier; Indicates the stream identifier corresponding to the target event; , These represent the start and end times of the event window, respectively; δ represents the query time tolerance; if To obtain the initial query set from the Digest index according to the source, event stream identifier, and extended time window, then To The evidence set is formed by recalculating the normalized bidirectional stream identifiers of the records and removing mismatched records. Indicates the number of packets in direction d; for China d The sum of packet lengths, written into the evidence digest of the unidirectional flow in the program as the audit information for the direction bytes, is not included in the d. Selection and calculation of confidence level of evidence; Indicates the dominant direction with the most packets; I() represents the indicator function; For recording Packaging length; ; ; ; ; ; in, , , , and These represent sample coverage, quintuple field completeness, target concentration, interaction stability, and inbound port clustering, respectively. I() represents the preset threshold for sufficient baseline samples; I() represents the indicator function. , , , , These represent the determination of the validity, legality, and completeness of the source IP, destination IP, source port, destination port, and transport protocol, respectively. Indicates the total number of messages accessing the dominant target; This represents a unique identifier hash calculated from the message's 5-tuple, payload characteristics, and communication timing. This represents the baseline hash value pre-stored for normal access behavior in the business baseline; This indicates the inbound physical or logical port number of the i-th message entering the detection device; This means iterating through all inbound ports that have seen traffic and taking the maximum percentage as the final indicator; ; in, Indicates the minimum sample threshold; Indicates the minimum threshold for the consistency index; conf cap Set an upper limit for the confidence level; when evidence is insufficient, limit the confidence level (conf) to the upper limit (conf). cap within; The handling direction is verified by the following indicators: the normalized flow identifier of the event is consistent with the normalized flow identifier obtained by recalculating the sample; the dominant direction is determined according to the number of packets in each direction and then... Calculate the dominance of the direction. Indicates the number of data packets in the dominant traffic direction; This indicates the total number of data packets in the entire bidirectional flow; the source IPv4 address, destination IPv4 address, IP protocol number, source port, and destination port of the candidate rule must be consistent with the first observation record in the dominant direction; the directional evidence status must be verified or reviewed; and the evidence confidence level must reach the risk policy threshold. A candidate rule can only be issued when the above directional evidence conditions are simultaneously met with other deployed access control measures. The verification is used to reduce the risk of directional misjudgment and does not constitute an absolute guarantee.
5. The evidence-driven network intrusion detection method based on category autoencoder according to claim 1, characterized in that: In step 5, the action template, target switch, and TTL in the user intent are first verified; then, based on the detection results, the candidate for viewing only, blocking, or rule recovery path is determined; for blocking candidates, it is verified whether the event is a known attack that has passed the category threshold, and the consistency of the directional evidence status, confidence level, and quintuple field is verified. After the verification is passed, a candidate rule plan is constructed, and a risk description and manual review package are generated in combination with the risk strategy.
6. The evidence-driven network intrusion detection method based on category autoencoders according to claim 1, characterized in that: In step 6, the determination rule for P4 securely issuing access control is as follows: ; In the formula, I() represents the indicator function; A This indicates that the operation was initiated by an administrator-privileged account; O This indicates the offline maintenance window period; H Indicates high-priority service traffic; K Indicates the source address of a trusted host on the internal network; E Indicates the emergency response mode for abnormal situations; F This represents a statically predefined whitelist stream; T This indicates that the TTL is positive and does not exceed the policy upper limit; P This indicates a strategy based on protected targets; C This indicates that the number of active rules in the target switch and the table is less than the policy capacity limit; R This indicates that the current workflow has been manually approved; J This indicates that the idempotent key is valid and has not been used in different requests; only when... G Writes are allowed when =1.
7. The evidence-driven network intrusion detection method based on category autoencoders according to claim 1, characterized in that: In step 7, the application display module displays abnormal events, directional evidence, review status, P4 distribution status, audit records, and rollback status. The application demonstration module also provides an external tool entry point, which is used to encapsulate backend capabilities for external tools or smart agents to call; however, this entry point is not a new permission system and cannot bypass backend authentication, role-based access control, risk policies, manual review, and P4-issued access control.
8. The evidence-driven network intrusion detection method based on a category autoencoder according to any one of claims 1-7, characterized in that: The category autoencoder is a trained category autoencoder; The training process includes the following steps: (1) Construct a training sample set and label the traffic window features according to the normal traffic category and the attack traffic category; (2) Normalize the training samples and create category-specific training data for each traffic category; (3) Train a corresponding autoencoder for each traffic category to minimize the error between the input traffic features and the reconstructed traffic features; (4) Generate the corresponding category threshold based on the reconstruction error of the validation set, and add the trained autoencoder model, normalization parameters and category threshold to the model library; when a new attack category appears, only train the autoencoder corresponding to the new attack category and add it to the model library, while the trained category autoencoder remains unchanged.
9. An evidence-driven network intrusion detection system based on a category autoencoder, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the evidence-driven network intrusion detection method based on a category autoencoder as described in any one of claims 1 to 8.
10. An evidence-driven network intrusion detection product based on a category autoencoder, comprising computer program instructions, characterized in that: When the computer program instructions are executed on a computer, server, controller, or edge computing device, they work in conjunction with a programmable switch running the P4 program to enable the computer, server, controller, or edge computing device to perform the evidence-driven network intrusion detection method based on a category autoencoder as described in any one of claims 1-8.