Elastic safety detection system in industrial control Internet of Things scene

Abstract

The invention discloses an elastic security detection system in an industrial control Internet of Things scene, which belongs to the technical field of network security and big data analysis, and comprises a security detection node and a platform management component, the security detection node is responsible for protocol identification, behavior analysis and threat detection, and a general detection module, a special detection module, a shared database and a virtual exchange facility are integrated in the security detection node; the platform management assembly is responsible for global control and operation and maintenance management of the whole system and comprises a detection function arrangement management module, a detection function life cycle management module, a virtual facility management module and a monitoring alarm module; according to the invention, a detachable and loosely-coupled system architecture is realized, and the problem of insufficient flexibility caused by a single software architecture is avoided; the traffic acquisition, identification, processing and intelligent detection capabilities oriented to the Internet of Things industrial control scene are realized; the security threat detection capability of on-demand customization and dynamic deployment is provided, and the diversity and flexibility of system functions are greatly improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of network security and big data analysis, and specifically relates to a flexible security detection system in an industrial control Internet of Things scenario. Background Art

[0002] To meet the intrusion detection needs in industrial control IoT scenarios, domestic and foreign security vendors have developed a variety of dedicated intrusion detection hardware devices. These devices typically have the ability to deeply analyze industrial protocols, support the analysis of industrial control IoT traffic such as ModBus, DNP3, OPC, S7, and BACnet, support the establishment of behavioral baselines for network communications, and identify attack behaviors such as illegal command injection, unauthorized access, lateral scanning, and abnormal communication cycles. These products are widely used in key scenarios such as smart manufacturing, electric power, rail transit, and water conservancy systems. Typical products include Nozomi Guardian, Claroty CTD, Qi'anxin Industrial Security Monitoring System, and Venustech Industrial Control Audit Platform, which have become an important technical foundation for network intrusion detection in industrial IoT environments. These devices are usually deployed as industrial-grade hardware platforms, with customized traffic analysis and detection capabilities for specific business scenarios.

[0003] Although this type of dedicated hardware equipment has advantages such as high reliability and powerful detection performance, it also has disadvantages such as high usage cost, inflexible deployment, poor elasticity, and high equipment upgrade and management costs. It cannot meet the diverse detection needs in industrial control IoT scenarios.

[0004] Currently, the most commonly used open-source NIDS software includes Snort, Suricata, and Zeek. These software packages offer comprehensive detection and alerting capabilities and are widely used in network security practices. In terms of software architecture, these are all developed and deployed as standalone software. The following uses Snort and QNSM as examples to briefly describe the architecture of this type of software-based NIDS.

[0005] Snort is a well-known lightweight, open-source NIDS software. Its functionality can be divided into two parts: network sniffing, which collects data traffic from hardware devices on deployed nodes; and intrusion detection, which matches the collected traffic against content patterns based on configured rules. Depending on the deployment platform, Snort uses Libpcap or Winpcap to capture packets.

[0006] Among the main functional modules, the Sniffer collects network traffic and parses it (to the transport layer). The Preprocessor performs anomaly checks and reassembles data packets. The Preprocessor has many functions, so Snort designed it as a plug-in that can start or stop certain preprocessing plug-in functions according to the needs of the actual environment. In addition, some application layer protocols such as HTTP and Telnet are also parsed in this part. The Detection Engine detects whether a data packet contains attack behavior based on specified rules. Alerts / Logging outputs alarm information to log files or databases.

[0007] Snort is a single-threaded software. Nowadays, network transmission speed has increased significantly and traffic volume has increased. NIDS also needs to handle the increasing number of transmission protocols, which requires a NIDS with higher detection efficiency and flexibility.

[0008] The iQIYI Network Security Monitor (QNSM), an open-source, full-flow, real-time, high-performance network security monitoring system developed based on DPDK, is a key component of NIDS. While not positioned as a NIDS, QNSM possesses the key data collection and traffic processing capabilities of NIDS and can be considered a subset of a complete NIDS. QNSM, developed based on DPDK, effectively improves message processing efficiency and provides certain general detection capabilities.

[0009] Common open-source NIDS and related systems differ in functionality, packet acquisition methods, deployment methods, and 5G traffic processing capabilities. Existing open-source NIDS software also has the following issues and flaws:

[0010] (1) Currently, mainstream open source NIDS software still has a monolithic program structure, and each functional module cannot be deployed separately.

[0011] (2) In addition, software-based NIDS uses a rule-based abnormal traffic detection method, which has high rule maintenance costs and aging rules are prone to false positives and missed positives.

[0012] (3) Monolithic software architecture does not have the ability to independently deploy specific types of security issues.

[0013] (4) It does not support ModBus, GOOSE, SV and other IoT industrial control protocols, cannot meet the traffic protocol requirements in IoT industrial control scenarios, and cannot fully support common IoT industrial control protocols. Based on the above analysis, the above software-based NIDS cannot meet the needs of efficient and flexible traffic detection in IoT industrial control scenarios.

[0014] Furthermore, in IoT industrial control networks, where device resources are limited, evaluating the trust status of devices based on traffic monitoring is highly valuable. However, traditional NIDS and firewalls are typically deployed as dedicated hardware. Once data traffic passes the security perimeter, it enters the trusted zone, where no further authentication or inspection is performed. Consequently, traditional hardware-based network security devices struggle to meet the demands for flexible deployment and scalability, and they struggle to address the dynamic demands of traffic authentication and trust assessment. Summary of the Invention

[0015] In response to the problems mentioned in the background technology, the present invention proposes a flexible security detection system for industrial control Internet of Things scenarios, which splits the functions of the single NIDS software into three parts: network traffic processing, message queue and security threat detection. It avoids the problems of the existing single NIDS software system architecture and insufficient flexibility, and greatly improves the flexibility and scalability of system deployment.

[0016] Technical solution: In order to solve the above technical problems, the technical solution adopted by the present invention is as follows:

[0017] A flexible security detection system for industrial control IoT scenarios, including security detection nodes and platform management components;

[0018] Security detection node: responsible for protocol identification, behavior analysis, and threat detection. It integrates general detection modules, dedicated detection modules, a shared database, and virtual switching facilities.

[0019] Platform management component: responsible for the global control and operation and maintenance management of the entire system, including the detection function orchestration management module, the detection function lifecycle management module, the virtual facility management module, and the monitoring and alarm module.

[0020] As a preferred option, the general detection module is responsible for network traffic analysis, including:

[0021] Session management statistics: Identify and count all types of sessions in the network;

[0022] Message header parsing: parse the header fields of TCP, UDP and ICMP protocols;

[0023] Application protocol parsing: Identify and parse the header fields of the application protocol;

[0024] Payload parsing: implements parsing of the payload information carried by the application protocol, including string restoration and file restoration.

[0025] Preferably, application protocol analysis: identification and analysis of application layer protocols, specifically including:

[0026] Application layer protocol identification: Identify the application layer protocol based on the protocol port or the first two characters of the protocol name;

[0027] Application layer protocol parsing: Call the registered parsing callback function to parse the protocol.

[0028] As a preference, a dedicated detection function module: expands and deploys a variety of detection functions for different attack types, used to identify different types of attack behaviors or threat characteristics, with modular and pluggable capabilities, including a threat initial screening layer and a fine-grained threat analysis layer.

[0029] As a preferred option, the initial threat screening layer: cluster detection based on LSTM and aggregation models, including:

[0030] Traffic feature encoding: Network traffic features are used as input, pre-processed and standardized, and then input into the LSTM model to obtain a high-dimensional vector representation of the time series features;

[0031] Aggregation model and cluster analysis: Utilize the aggregation model to analyze the output of the LSTM model and use an unsupervised clustering algorithm to group similar attack behaviors.

[0032] Unknown threat processing mechanism: The clustering results are judged. If a sample deviates from the center of any cluster, it is determined to be an unknown threat and stored in the feature library.

[0033] As a priority, the fine-grained threat analysis layer: Based on accurate detection of multiple models, fine-grained classification is achieved, including:

[0034] Feature enhancement module: extracts features for different threat types, including malicious file detection, protocol abuse detection, and abnormal traffic pattern detection;

[0035] Dedicated detection model module: implements fine-grained classification based on a dedicated detection model.

[0036] As a preference, the security detection node has a built-in shared database for information synchronization and collaborative analysis between modules, and is equipped with traffic preprocessing and virtual switching mechanisms to ensure data input and output.

[0037] As the preferred option, the detection function orchestration management module is responsible for the strategic deployment, loading and unloading of various detection functions;

[0038] Detection function lifecycle management module: supports version updates, start and stop control, and configuration distribution of functional modules;

[0039] Virtual facility management module: Unified control of underlying network switching strategies, traffic distribution, and virtualization capabilities;

[0040] Monitoring and alarm module: real-time summary of the operating status and alarm information of each detection node, providing the system with visual monitoring and security situation awareness capabilities.

[0041] Preferably, the security detection node implements load balancing management, and selects load balancing of general detection functions or load balancing of dedicated detection functions to process traffic according to the scale of traffic and the load of related general detection functions.

[0042] Beneficial effects: Compared with the prior art, the present invention has the following advantages:

[0043] (1) In view of the resource-limited characteristics of IoT industrial control scenarios and the challenges posed to application security threats by diverse attack methods, the present invention proposes a microservice-based security threat detection software system architecture that supports artificial intelligence security detection, which meets the requirements of lightweight, high resource utilization, flexible functions, and easy deployment of application security threat detection systems in IoT industrial control network environments.

[0044] (2) The present invention proposes a detachable and loosely coupled system architecture, which splits the functions of the single NIDS software into three parts: network traffic processing, message queue and security threat detection. This avoids the problems of the existing single NIDS software system architecture being single and inflexible, and greatly improves the flexibility and scalability of system deployment.

[0045] (3) The present invention can meet the diverse and dynamic application security requirements of IoT industrial control scenarios by virtualizing security threat detection functions and orchestrating and managing virtualized security functions, providing on-demand customized and dynamically deployed security threat detection capabilities, greatly improving the diversity and flexibility of system functions.

[0046] (4) The present invention proposes a multi-level threat detection based on artificial intelligence. First, the LSTM+clustering threat screening layer is used to aggregate similar network attacks and discover unknown attacks. Then, a fine-grained classification method is used according to the specific attack scenario.

[0047] (5) The present invention implements a shardable, loosely coupled system architecture, avoiding the inflexibility issues associated with a monolithic software architecture. It also implements traffic collection, identification, processing, and intelligent detection capabilities for IoT industrial control scenarios. It also virtualizes security detection functions and orchestrates and deploys virtualized security functions. Based on these capabilities, it provides intelligent security threat detection capabilities for IoT industrial control scenarios, enabling customized and dynamically deployed security threat detection capabilities tailored to the diverse and dynamic security detection needs of IoT industrial control. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 This is a schematic diagram of the flexible security detection framework for IoT industrial control scenarios of the present invention;

[0049] Figure 2 It is the Snort architecture diagram of the present invention;

[0050] Figure 3 It is a schematic diagram of the message structure of the present invention. DETAILED DESCRIPTION

[0051] The present invention will be further illustrated below with reference to specific examples. The examples are implemented based on the technical solutions of the present invention. It should be understood that these examples are only used to illustrate the present invention and are not used to limit the scope of the present invention.

[0052] The elastic security detection system in the industrial control Internet of Things scenario provided in this embodiment has a system architecture including several security detection nodes and platform management components.

[0053] Security detection node: Mainly responsible for core functions such as protocol identification, behavior analysis and threat detection, it integrates general detection modules, special detection modules, shared databases and virtual switching facilities.

[0054] General detection module: covers functions such as session management statistics, message header analysis, application protocol analysis and payload analysis. The general detection function adopts a microservice architecture. Each general function can be deployed independently and can also be flexibly expanded or reduced according to the current load situation, thereby supporting more flexible scheduling strategies and providing multi-dimensional traffic data analysis support for dedicated detection modules.

[0055] Dedicated detection module: It can be expanded to deploy a variety of detection functions for different attack types to identify different types of attack behaviors or threat characteristics, and has modular and pluggable capabilities.

[0056] Security detection nodes feature a built-in shared database for information synchronization and collaborative analysis across modules. Traffic preprocessing and virtual switching mechanisms ensure high-performance data input and output. The system supports the coordinated deployment of multiple detection nodes, building a distributed, horizontally scalable, multi-node detection system.

[0057] The security detection node has three functions: network traffic analysis, threat event detection, and load balancing management.

[0058] The network traffic parsing function is completed by the general detection function. The general detection function collects network traffic, counts session information, and obtains the protocol data XDR (Extended Detection and Response) of the IoT industrial control traffic through the analysis of the message header and application protocol. For file transfer traffic, the payload carried in the traffic is extracted and parsed. The protocol data XDR output by the general detection function will be stored in the database for use by the upper-layer detection logic.

[0059] In this embodiment, the following 12 types of protocol traffic are supported for identification / parsing: IPv4 (Internet Protocol version 4), TCP (Transmission Control Protocol), UDP (User Datagram Protocol), ModBus (serial communication protocol), PFCP (Packet Forwarding Control Protocol), GTP-U (Tunneling Protocol for the data plane of mobile communication networks), DNS (Domain Name System), HTTP (Hypertext Transfer Protocol), COAP (Constrained Application Protocol), MQTT (Message Queue Telemetry Transport), GOOSE (General Object-Oriented Substation Event Protocol), and SV (Sampled Measurement Value Protocol).

[0060] Session management and statistics:

[0061] The present invention performs session statistics and management for TCP, UDP, and ICMP (Internet Control Message Protocol). It uses a timer to manage the session lifecycle. When one of these three protocols is recognized, the timer is initialized while a new session is created. When the timer expires, the storage space for the current session information (e.g., TCP connection) is released. Therefore, if you want to collect statistical information for a complete session, you need to do so before the session is released to ensure that the collected information is complete information for a completed session.

[0062] Message header parsing: parse the header fields of the three basic protocols TCP, UDP, and ICMP.

[0063] Mobile network protocol identification and parsing: Mobile network protocol identification refers to the identification of the GTP-U protocol. Mobile network data packets are encapsulated in the GTP-U protocol. Therefore, GTP-U must be identified and parsed before data packet parsing can be completed.

[0064] This paper redevelops the open-source software QNSM to support IoT industrial control protocols such as PFCP, MQTT, and CoAP. On the mobile network data plane, a GTP-U tunnel is placed over the data packet. The GTP-U protocol sits above the mobile network IP and UDP. Beyond the original IP packet, specific information includes version, protocol type, flag value, length, and TEID (Tunnel Endpoint Identifier). To support traffic parsing in mobile network environments, this paper also supports the GTP-U protocol.

[0065] In order to parse the GTP-U data packet, when the data packet is received, the outer GTP-U tunnel needs to be stripped and the tunnel information needs to be parsed accordingly. In addition, the present invention optimizes the protocol type extraction function in the DPDK (Data Plane Development Kit) so that the function supports identifying the GTP-U tunnel protocol based on the port number. In the case of a tunnel, the protocol identification and parsing module points the pointer to the inner network layer protocol packet header, thereby achieving the purpose of stripping the tunnel. Subsequently, the data packet inside the tunnel is parsed according to the definition of different protocol data.

[0066] Application protocol analysis: identification and analysis of application layer protocols.

[0067] When the present invention parses a specific application layer data packet, the parsing process can be divided into two steps:

[0068] (1) Application layer protocol identification, specifically using the protocol port (i.e., port-based protocol identification) or the first two characters of the protocol name (such as H and T in HTTP, D and N in DNS, i.e., signature-based protocol identification) to match and identify the application layer protocol.

[0069] (2) Application layer protocol parsing. The parsing parts of different protocols are implemented in the callback function of the protocol itself (such as the parsing part of the HTTP protocol is located in the src / protos / http.c / http_parse() function, and the parsing part of the DNS protocol is located in the src / protos / dns.c / dns_parse() function). The main process of the parsing part is: parse each field of the protocol in the corresponding callback function of the protocol and register it as the corresponding parsing callback function.

[0070] Faced with the diverse application layer communication protocols in industrial control IoT scenarios, the present invention first identifies the protocol based on the port or feature code, and then calls the registered parsing callback function to parse the protocol.

[0071] Payload parsing: implements parsing of the payload information carried by the application protocol, including string restoration and file restoration.

[0072] Based on specific protocol features, such as HTTP file upload, FTP (File Transfer Protocol) data channel, SMB (Server Message Block) file copy or configuration file transfer in industrial control protocols, the boundary of the session content is identified and data is extracted. Combined with the MIME (Multipurpose Internet Mail Extensions) type, Content-Length field, magic number or file end marker, the file boundary is accurately identified and data restoration is completed.

[0073] The restored file content is analyzed based on its type (e.g., executable file, document, script, compressed package, or PLC configuration file) using corresponding parsing methods for structural analysis and behavioral detection, including macro command extraction, AST syntax parsing, script decoding, and PLC program structure inspection. It also integrates virus signature libraries, sandbox simulation, and other mechanisms to identify potential malicious behavior and generate analysis results such as file summaries, propagation paths, and behavioral characteristics, enabling comprehensive file-level detection and intelligent response capabilities within the network.

[0074] Dedicated detection function module: responsible for threat event detection, including the initial threat screening layer and the fine-grained threat analysis layer.

[0075] Threat event detection is completed by dedicated detection functions, using a hierarchical detection architecture. The threat screening component performs preliminary detection on threat events and determines the type of threat, such as Trojans / vulnerability exploits / viruses. Dedicated detection functions detect specific types of threat events, such as deploying dedicated detection functions for worm-like viruses, thereby improving the granularity of threat detection.

[0076] To achieve efficient and accurate threat detection in industrial IoT scenarios, this paper employs a hierarchical attack detection architecture, comprising a primary threat screening layer and a fine-grained threat analysis layer. This two-tiered detection mechanism dynamically collaborates to address the dual needs of discovering unknown threats and accurately identifying known threats, significantly improving the system's responsiveness to complex attack behaviors.

[0077] Initial threat screening layer: Cluster detection based on LSTM and aggregation models.

[0078] The threat screening process includes:

[0079] (1) Traffic feature coding.

[0080] The initial threat screening layer takes network traffic features as input, including time-series traffic statistics (such as traffic rate, session duration, and packet size distribution), protocol field features (such as ModBus function codes and HTTP request methods), and payload features (such as file hashes and instruction sequence patterns). These features are normalized by the preprocessing module and then input into the LSTM (Long Short-Term Memory) model. Due to its unique gating mechanism, LSTM can effectively capture the temporal dependencies of traffic data. Specifically, the model uses a three-layer LSTM structure, with a dropout layer to prevent overfitting, ultimately outputting a high-dimensional vector representation of the temporal features.

[0081] LSTM for the current input x t The processing process is:

[0082] f t =σ(Wf ·[h t-1 ,x t ]+b f )

[0083] i t =σ(W i ·[h t-1 ,x t ]+b i )

[0084] o t =σ(W o ·[h t-1 ,x t ]+b o )

[0085]

[0086] h t =o t *tanh(c t )

[0087] Among them, f t 、i t 、o t Respectively represent the forget gate, input gate, and output gate; c t Represents the state of the memory unit, h t represents the hidden state output of the current time step; σ(·) represents the Sigmoid activation function, tanh(·) represents the hyperbolic tangent activation; W f 、W i 、W o 、W c 、b f 、b i 、b o 、b c Both represent the learnable parameters of the LSTM network. Indicates the current state of the memory unit; h t-1 represents the hidden state of the previous moment; c t-1 Represents the state of the memory unit at the previous moment; σ represents the Sigmoid activation function.

[0088] (2) Aggregation model and cluster analysis.

[0089] The feature vectors output by the LSTM are further input into the aggregation model, which uses an unsupervised clustering algorithm to group similar attack behaviors. The aggregation model uses an improved DBSCAN algorithm combined with a dynamic density threshold adjustment mechanism to adapt to the dynamic changes in traffic distribution in industrial control scenarios. The specific process is as follows:

[0090] Feature dimensionality reduction: The t-distributed Stochastic Neighbor Embedding (t-SNE) algorithm is used to map high-dimensional features into a two-dimensional space while retaining local structural information for easy visualization and cluster analysis.

[0091] Density clustering: Based on the adaptive neighborhood radius (Eps) and the minimum number of samples (MinPts), high-density areas are identified as attack clusters while filtering out noise points. This method uses the Euclidean distance to measure the similarity between two samples. The formula is as follows:

[0092]

[0093] Among them, x i and x j are two m-dimensional data points, x ik and x jk They are x i 、x j The value in the kth dimension, d(x i ,x j ) is the Euclidean distance between them; DBSCAN judges x i and x j Whether it is a neighbor condition: d(x i ,x j )≤ε, that is, as long as the distance is less than or equal to the given ε, they are considered neighbors.

[0094] In the DBSCAN model, a core point refers to a sample point whose ε neighborhood contains at least MinPts points; a border point refers to a point that is not a core point but is located in the ε neighborhood of a core point; a noise point refers to an isolated point that is neither a core point nor belongs to the ε neighborhood of any core point.

[0095] Cluster labeling and evaluation: This paper verifies the clustering quality by using the Silhouette Score. Clusters with a Silhouette Score lower than 0.5 are manually reviewed to ensure the rationality of the classification. The Silhouette Score calculation process for any point i is as follows:

[0096] Calculate the average distance a within the same cluster i ;

[0097] Calculate the average distance b from this point to the points in the nearest other clusters i ;

[0098] Calculate the silhouette coefficient s i , specifically:

[0099]

[0100] (3) Unknown threat handling mechanism:

[0101] If a sample is marked as a noise point in the clustering results, it will trigger a manual analysis process, requiring further manual evaluation to determine whether it is an unknown threat. Unknown threat signatures confirmed by manual analysis will be stored in the signature library and trigger incremental model training to continuously optimize detection capabilities.

[0102] Fine-grained threat analysis layer: Accurate detection based on multi-model fusion to achieve fine-grained classification, including feature enhancement modules and dedicated detection models.

[0103] Known threat clusters will enter the second layer of detection, where fine-grained classification is achieved through a multi-model fusion strategy. The core modules of this layer include:

[0104] (1) Feature enhancement module:

[0105] Extract specialized features for different threat types, such as:

[0106] Malicious file detection: For this type of attack, static features (file entropy, PE header information) and dynamic sandbox behavior logs (API call sequence, process tree) can be combined to form dedicated features to help accurately identify malicious files.

[0107] Protocol abuse detection: Analyze industrial control protocol instruction sequences (such as ModBus write operation frequency), record operations within a time window, and construct a state transition probability matrix.

[0108] Abnormal traffic pattern detection: Analyzing sudden changes in traffic distribution based on information entropy helps identify DDoS attacks or scanning behaviors.

[0109] (2) Dedicated detection model module:

[0110] Deploy dedicated detection models for specific attacks to achieve fine-grained classification. For example, use a random forest classifier to quickly screen high-confidence threats (such as known malicious IP addresses and rule-matching attacks); and use a deep residual network (ResNet) to perform graphical feature extraction and classification on complex payload content (such as obfuscated scripts and encrypted communications).

[0111] Load balancing management: refers to selecting appropriate general detection functions and special detection functions to process traffic based on the scale of traffic and the load of related general detection functions.

[0112] Both general-purpose and specialized detection microservices support dynamic scaling, meaning the number of detection microservices can be dynamically adjusted based on the current traffic volume, attack situation, and the current load of different detection microservices.

[0113] Load balancing with dedicated detection capabilities:

[0114] To support the above functions, the threat screening component maintains a mapping table that records the processing capabilities, current load, and push addresses of different detection microservices. This ensures that the same session is pushed to the same detection microservice and that detection microservices of the same type are load balanced.

[0115] Load balancing of general detection functions:

[0116] To streamline the processing of common detection functions and support load balancing, this paper splits common detection functions into multiple independently deployable microservice modules. These microservices can be combined to form a microservice chain, each of which implements a complete detection function. Each type of traffic detection is executed according to a predefined microservice chain, with traffic forwarding between containers responsible for different detection tasks.

[0117] Because security applications are network middleware, they typically set the network interface card to promiscuous mode to monitor transmitted traffic, requiring the host network to adopt Layer 2 bridging mode. To schedule different detection units based on traffic type, the present invention utilizes MPLS tunnel labels to identify traffic types in packet headers and implements enhanced virtual switching facilities to implement traffic scheduling.

[0118] The enhanced virtual switching facility processes two types of traffic: one is to receive and forward traffic from the network entrance that has not undergone any detection; the other is to receive and forward traffic sent by other general detection microservices within the detection host that has completed part of the detection process. These two types of traffic are in different detection stages and have different forwarding requirements. The first type of traffic needs to be forwarded to the session statistics management general detection logic. The forwarding strategy is determined by the CPU utilization of multiple session statistics management microservices in the host, and the microservice with the lowest utilization is selected for forwarding. To support the execution of the load balancing strategy, each microservice needs to be encapsulated with a layer of MPLS tunnel header after processing to identify the protocol feature code, the current general microservice type, and the type of the next-hop microservice. The message structure is as follows: Figure 3 shown.

[0119] A tunnel protocol header is encapsulated around the original message and session ID tag. The source MAC and destination MAC address fields in the tunnel header are replaced with a signature code to identify the protocol type. For example, the TCP protocol type is 0x000000000001. The source IP and destination IP fields in the tunnel header are replaced with a detection function type tag to identify the current and next detection modules.

[0120] To support the forwarding of the second type of traffic, a forwarding table needs to be added to the enhanced virtual switching facility in the format of<next_type,next_docker> (next_type indicates the type of the next detection function) table.

[0121] After receiving the traffic, it will first parse the label in the message header to determine the source of the traffic. If it does not match the MPLS label, it will be forwarded to the session statistics management microservice. If it matches the signature code, it means that the traffic is sent from the detection security detection microservice, then query<next_type,next_docker> Get the address of the next security detection microservice, replace next_type with next_docker, and forward according to next_docker.

[0122] The platform management component assumes the global control and operation and maintenance management responsibilities of the entire system, mainly including the orchestration and lifecycle management of detection functions, centralized scheduling of virtual infrastructure, and real-time monitoring and alarming of system operation status.

[0123] The detection function orchestration management module is responsible for the strategic deployment, loading and unloading of various detection functions.

[0124] The lifecycle management module supports version updates, start and stop control, and configuration distribution of functional modules.

[0125] The virtual infrastructure management module centrally controls the underlying network switching strategies, traffic distribution, and virtualization capabilities.

[0126] The monitoring and alarm module summarizes the operating status and alarm information of each detection node in real time, providing the system with visual monitoring and security situation awareness capabilities.

[0127] Comparison of common open-source NIDS and related systems in terms of functionality, message acquisition methods, deployment methods, and 5G traffic processing capabilities.

[0128] Table 1 Comparison of software-based NIDS

[0129] Snort Suricata vNIDS QNSM Message acquisition method libpcap libpcap libpcap DPDK Deployment method Single host single thread Single host multithreading distributed distributed IoT industrial control traffic processing none none none none

[0130] The present invention realizes a detachable and loosely coupled system architecture, avoiding the lack of flexibility caused by a monolithic software architecture; realizes the traffic collection, identification, processing and intelligent detection capabilities for IoT industrial control scenarios; realizes the virtualization of security detection functions and the orchestration and deployment of virtualized security functions.

[0131] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A flexible safety detection system for industrial control IoT scenarios, characterized by: Includes security detection nodes and platform management components; Security detection node: responsible for protocol identification, behavior analysis, and threat detection. It integrates general detection modules, dedicated detection modules, a shared database, and virtual switching facilities. Platform management component: responsible for the global control and operation and maintenance management of the entire system, including the detection function orchestration management module, the detection function lifecycle management module, the virtual facility management module, and the monitoring and alarm module.

2. The elastic safety detection system in the industrial control Internet of Things scenario according to claim 1 is characterized in that: General detection module: responsible for network traffic analysis, including: Session management statistics: Identify and count all types of sessions in the network; Message header parsing: parse the header fields of TCP, UDP and ICMP protocols; Application protocol parsing: Identify and parse the header fields of the application protocol; Payload parsing: implements parsing of the payload information carried by the application protocol, including string restoration and file restoration.

3. The elastic safety detection system in the industrial control Internet of Things scenario according to claim 2 is characterized in that: Application protocol analysis: Identification and analysis of application layer protocols, including: Application layer protocol identification: Identify the application layer protocol based on the protocol port or the first two characters of the protocol name; Application layer protocol parsing: Call the registered parsing callback function to parse the protocol.

4. The elastic safety detection system in the industrial control Internet of Things scenario according to claim 1 is characterized in that: Dedicated detection function module: Expands and deploys a variety of detection functions for different attack types to identify different types of attack behaviors or threat characteristics. It has modular and pluggable capabilities, including the initial threat screening layer and the fine-grained threat analysis layer.

5. The elastic safety detection system in the industrial control Internet of Things scenario according to claim 4 is characterized in that: Initial threat screening layer: Cluster detection based on LSTM and aggregation models, including: Traffic feature encoding: Network traffic features are used as input, pre-processed and standardized, and then input into the LSTM model to obtain a high-dimensional vector representation of the time series features; Aggregation model and cluster analysis: Utilize the aggregation model to analyze the output of the LSTM model and use an unsupervised clustering algorithm to group similar attack behaviors. Unknown threat processing mechanism: The clustering results are judged. If a sample deviates from the center of any cluster, it is determined to be an unknown threat and stored in the feature library.

6. The elastic safety detection system in the industrial control Internet of Things scenario according to claim 4 is characterized in that: Fine-grained threat analysis layer: Accurate detection based on multi-model fusion, achieving fine-grained classification, including: Feature enhancement module: extracts features for different threat types, including malicious file detection, protocol abuse detection, and abnormal traffic pattern detection; Dedicated detection model module: implements fine-grained classification based on a dedicated detection model.

7. The elastic safety detection system in the industrial control Internet of Things scenario according to claim 1 is characterized in that: The security detection node has a built-in shared database for information synchronization and collaborative analysis between modules, and is equipped with traffic preprocessing and virtual switching mechanisms to ensure data input and output.

8. The elastic safety detection system in the industrial control Internet of Things scenario according to claim 1 is characterized in that: Detection function orchestration management module: responsible for the strategic deployment, loading, and unloading of various detection functions; Detection function lifecycle management module: supports version updates, start and stop control, and configuration distribution of functional modules; Virtual facility management module: Unified control of underlying network switching strategies, traffic distribution, and virtualization capabilities; Monitoring and alarm module: real-time summary of the operating status and alarm information of each detection node, providing the system with visual monitoring and security situation awareness capabilities.

9. The elastic safety detection system in the industrial control Internet of Things scenario according to claim 1 is characterized in that: The security detection node implements load balancing management. According to the scale of traffic and the load of related general detection functions, it selects load balancing of general detection functions or load balancing of special detection functions to process traffic.

Images