Real-time monitoring and protection method and system for security data of Internet of Things

Abstract

The invention belongs to the technical field of computers, and particularly relates to an Internet of Things security data real-time monitoring and protection method and system, and the method comprises the steps: collecting equipment communication and state data through an edge agent, and analyzing and extracting standardized metadata; constructing an equipment behavior contour vector based on a sliding window, and dynamically maintaining a global equipment topological graph; triggering a primary alarm in combination with behavior deviation detection and topology abnormity; outputting a threat score and an attack intention through rule matching and Bayesian network double-engine collaborative reasoning; and executing automatic response according to grading, and feeding back and correcting a behavior baseline to realize closed-loop optimization. The system comprises a data acquisition module, a protocol analysis module, a behavior modeling module, a topology maintenance module, an anomaly detection module, a collaborative reasoning module, an automatic response module and a baseline correction module. Through full-link real-time modeling and cross-device collaborative analysis, the attack detection rate is significantly increased to 98% or above, the false alarm rate is lower than 2%, the response delay is controlled within 800 milliseconds, and the security and adaptive ability of the Internet of Things system are enhanced.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, specifically a method and system for real-time monitoring and protection of Internet of Things (IoT) security data. Background Technology

[0002] The Internet of Things (IoT) technology has deeply penetrated into fields such as smart cities, industrial internet, and smart homes. Massive heterogeneous terminal devices continuously generate high-concurrency, multi-dimensional real-time data streams, and their security protection needs have shifted from traditional static boundary defense to a new protection mode of dynamic behavior perception and instant response.

[0003] Traditional IoT security monitoring systems are mostly built on signature matching or rule bases, relying on preset attack signatures and fixed policy thresholds to achieve security detection through static mapping of known threat patterns. While these systems have certain advantages in terms of technological maturity and basic protection capabilities, and can handle common known security threats, their design limitations are gradually becoming apparent in the complex environment unique to the IoT.

[0004] Data interaction in the Internet of Things (IoT) environment exhibits high spatiotemporal discreteness, with dynamic device registration, heterogeneous and mixed communication protocols, and ambiguous data payload semantics. Attackers often exploit legitimate device identity spoofing, low-frequency incremental penetration, or protocol layer obfuscation techniques to bypass detection. Static rule engines, lacking the ability to understand the contextual semantics of data flows in real time, are prone to false positives or false negatives, allowing advanced persistent threats such as zero-day attacks and lateral movement to remain dormant within the system for extended periods. Simultaneously, the contradiction between the limited resources of edge computing nodes and the latency of centralized cloud analysis makes it difficult for traditional centralized security architectures to complete threat assessment and policy deployment within millisecond-level response windows, severely restricting the resilience of IoT systems in critical scenarios.

[0005] Therefore, the present invention provides a method and system for real-time monitoring and protection of IoT security data. Summary of the Invention

[0006] In order to overcome the shortcomings of the prior art, at least one technical problem raised in the background art is solved.

[0007] The technical solution adopted by the present invention to solve its technical problem is: The present invention provides a real-time monitoring and protection method for IoT security data, comprising: S1: continuously collecting the original communication data packets, device operation status logs, network connection event records and application layer interaction command sequences of IoT terminal devices within its jurisdiction through a security proxy module deployed on IoT edge nodes or regional aggregation gateways;

[0008] S2: Perform protocol parsing and structured conversion on the original communication data packets, device operation status logs, network connection event records, and application layer interaction instruction sequences to extract a standardized set of metadata fields including source device identifier, destination device identifier, communication protocol type, data payload feature code, timestamp, session duration, and data transmission rate;

[0009] S3: The standardized metadata field set is sliced ​​by time window and then input into the lightweight time-series behavior modeling unit to construct the behavior profile vector of each IoT terminal device in the most recent several time units; the behavior profile vector is composed of device activity index, protocol usage preference distribution, data interaction object concentration, and instruction call frequency gradient.

[0010] S4: Establish a global device relationship topology graph; the graph uses devices as nodes, historical legal communication links as edges, and communication frequency and data volume as edge weights, and maintains dynamic consistency through an incremental graph update algorithm;

[0011] S5: When the behavior profile vector of any device deviates from its historical baseline model by more than a preset threshold, or when the current communication target does not have a legal edge connection in the global device relationship topology graph, a primary anomaly alarm signal is triggered.

[0012] S6: Input the primary anomaly alarm signal, along with the complete behavioral profile vector of the device, the current communication context snapshot, and the behavioral status of neighboring devices that have direct or indirect topological association with it, into the cross-device collaborative threat inference engine.

[0013] The cross-device collaborative threat inference engine employs a dual-channel analysis architecture that integrates rule matching and probabilistic graphical models to perform threat assessment. The first channel performs precise matching of a predefined attack pattern rule base, while the second channel constructs a Bayesian belief network to probabilistically infer the causal dependencies between multiple device anomalies, ultimately outputting a comprehensive threat score and attack intent classification label.

[0014] S7: Based on the comprehensive threat score and attack intent classification label, invoke the policy decision matrix to determine the corresponding automated response action; the automated response action includes cutting off the network connection of specific devices, redirecting suspicious traffic to honeypot nodes, issuing temporary access control lists to relevant switches, and pushing priority security work orders to the management platform.

[0015] S8: Feedback the execution results of all response actions to the behavior baseline correction module to dynamically adjust the parameters of the historical behavior profile model of the affected devices, thereby achieving closed-loop optimization of the protection strategy.

[0016] As one embodiment of the present invention, the IoT security data real-time monitoring and protection system includes: a security data acquisition agent module, deployed at the IoT edge, for continuously capturing raw communication data and operating status information of terminal devices; a protocol parsing and metadata extraction module, for converting raw data into a set of structured metadata fields; a time-series behavior modeling module, for generating behavior contour vectors of each device based on a sliding window mechanism; a global topology map construction and maintenance module, for establishing and dynamically updating a network of legitimate communication relationships between devices; an anomaly detection triggering module, for comparing behavior contour vectors with historical baseline models, identifying deviation behaviors, and generating primary anomaly alarms; a cross-device collaborative threat reasoning module, for performing correlation analysis on multiple device anomaly events by combining rule matching and probabilistic graphical models and outputting threat assessment results; an automated response execution module, for selecting and executing corresponding security actions from a preset strategy library based on the threat assessment results; and a behavior baseline adaptive correction module, for adjusting device behavior model parameters in reverse based on the response execution results to complete the protection closed loop.

[0017] As one embodiment of the present invention, the secure data acquisition agent module is embedded in the firmware layer of the IoT gateway, supports deep message parsing capabilities for mainstream industrial IoT protocols such as ModbusTCP, OPCUA, MQTT, and CoAP, has an acquisition frequency of no less than once per second, a data cache capacity of no less than 500 megabytes, and supports offline resume transmission and local compressed storage functions.

[0018] As one embodiment of the present invention, the protocol parsing and metadata extraction module adopts a layered parsing architecture. The first layer identifies the transport layer protocol type and port number, the second layer parses the application layer protocol semantic structure, and the third layer extracts key payload features such as instruction opcodes, register addresses, topic names, and resource paths. The final output metadata field set contains no less than twenty standardized fields.

[0019] In one embodiment of the present invention, the sliding window length in the temporal behavior modeling module is set to thirty time units, with each time unit corresponding to a five-second actual duration. The device activity index in the behavior contour vector is obtained by calculating the ratio of the number of effective communications to the total number of samples within a unit of time. The protocol usage preference distribution is formed by statistically analyzing the frequency proportion of each protocol within the window period to create a four-dimensional probability vector. The concentration of data interaction objects is discretized using the Shannon entropy formula to measure the communication target device identifier sequence. The instruction call frequency gradient is obtained by performing a first-order difference operation on the difference in the number of instruction calls within adjacent time units.

[0020] As one embodiment of the present invention, the global topology graph construction and maintenance module uses an adjacency list data structure to store device nodes and communication edges. The edge weight update cycle is ten minutes. If a communication edge has no data interaction for three consecutive update cycles, it will automatically be downgraded. If there is no interaction for five consecutive cycles, the edge will be removed. New legitimate communication edges must be verified by two-way handshake and authorized by the management platform's whitelist before they can be added to the graph.

[0021] As one embodiment of the present invention, the historical baseline model in the anomaly detection triggering module adopts the moving average plus standard deviation dynamic threshold method, the baseline window length is 7,200 time units, the anomaly judgment threshold is set to the mean plus or minus three times the standard deviation, and a mutation detection algorithm is introduced to identify the step change of the behavioral profile vector in the short term, and the mutation amplitude threshold is set to 70% of the maximum allowable fluctuation range of each dimension of the profile vector.

[0022] As one embodiment of the present invention, the rule matching channel in the cross-device collaborative threat inference module contains no less than fifty predefined attack feature rules, covering typical IoT attack modes such as port scanning, protocol malformed packet injection, unauthorized command execution, and high-frequency heartbeat spoofing. Each rule includes a trigger condition expression and a confidence weight coefficient. The Bayesian belief network in the probabilistic graphical model channel includes four types of latent variable nodes: device abnormal state nodes, communication link abnormal nodes, topology disturbance nodes, and external threat intelligence nodes. The conditional probability table between nodes is learned by parameters from the historical attack sample set during the offline training phase. The inference process uses a joint tree algorithm to achieve efficient marginal probability calculation.

[0023] As one embodiment of the present invention, the automated response execution module maintains a hierarchical response strategy library. The strategy levels are divided into four levels: observation level, restricted level, isolation level, and cleanup level. Each level corresponds to different combinations of response actions and execution permissions. The strategy selection is based on the comprehensive threat score range. The score range of 0 to 30 corresponds to the observation level, 31 to 60 corresponds to the restricted level, 61 to 90 corresponds to the isolation level, and 91 to 100 corresponds to the cleanup level. Within each score range, the specific action parameters are further refined according to the attack intent classification label.

[0024] As one embodiment of the present invention, the behavioral baseline adaptive correction module initiates a model fine-tuning process after each response action is executed. For devices identified as false alarms, their current behavioral profile vector is included in the historical sample set to recalculate the moving average and standard deviation. For devices confirmed to have been attacked, their original behavioral baseline is cleared after the isolation period ends, and the initial model is reconstructed using normal behavioral data from the first 1,000 time units after restart. For devices that frequently trigger low-risk alarms, their baseline window length is automatically extended to 14,400 time units to enhance stability.

[0025] As one embodiment of the present invention, the system further includes a visualization situation presentation module. This module receives real-time threat assessment results from the cross-device collaborative threat reasoning module and action logs from the automated response execution module, and generates a multi-dimensional visualization interface including a geographical distribution heatmap, a device risk level color map, an attack propagation path animation, and a policy execution statistics dashboard, which supports tracing back the evolution of historical security events along a timeline.

[0026] As one embodiment of the present invention, the visualization situation presentation module adopts a layered rendering architecture, with a static network topology base map at the bottom, a dynamic risk coloring layer in the middle, and an event trajectory animation layer at the top. It supports seamless switching of zoom levels from a global view to a single device details page, with a data refresh frequency of no less than once every three seconds and a historical data storage period of no less than 180 days.

[0027] As one embodiment of the present invention, the system further includes an offline model training and rule update module. This module periodically downloads the latest attack sample dataset and threat intelligence subscription source from the management platform, and incrementally updates the Bayesian belief network parameters in the cross-device collaborative threat inference module and the feature rule base in the rule matching channel. The model retraining cycle is once a week, and the rule base synchronization cycle is once a day. The update process adopts a shadow model switching mechanism to ensure uninterrupted online service.

[0028] As one embodiment of the present invention, the offline model training and rule update module uses the maximum likelihood estimation method to optimize the conditional probability parameters when training the Bayesian belief network. The training samples must contain no less than 100,000 labeled attack event records, and each record contains a complete multi-device anomaly context and a final manual judgment label. When updating the rule base, syntax verification and conflict detection are performed on the newly added rules to ensure that there is no logical contradiction with the existing rules. Conflict detection is implemented using a propositional logic satisfiability solver.

[0029] As one embodiment of the present invention, the security data acquisition agent module and the protocol parsing and metadata extraction module adopt a zero-copy memory sharing mechanism to transmit raw data, thereby reducing processing latency; a bidirectional data subscription channel is established between the time-series behavior modeling module and the global topology map construction and maintenance module to ensure that abnormal behavior events can trigger topology relationship verification in real time; a transactional message queue is used between the cross-device collaborative threat reasoning module and the automated response execution module to ensure the reliability and order of instruction transmission.

[0030] As one embodiment of the present invention, the system adopts a distributed architecture in physical deployment. The security data acquisition agent module is deployed at the boundary of each IoT subnet, the time-series behavior modeling module and the anomaly detection triggering module are deployed at the regional security analysis node, and the cross-device collaborative threat reasoning module and the automated response execution module are deployed at the central security management platform. The modules communicate with each other through a dedicated encrypted channel. The communication protocol adopts the national cryptographic SM4 algorithm for end-to-end encryption, and the key rotation cycle is 24 hours.

[0031] As one embodiment of the present invention, the method anonymizes all collected raw data and generated intermediate representations during execution. The device identifier is replaced with an irreversible hash value before entering the timing behavior modeling module. The communication content payload retains only the feature code and does not store plaintext after protocol parsing, ensuring that user privacy and trade secrets are not leaked.

[0032] As one embodiment of the present invention, the method supports differentiated monitoring intensity configuration for IoT subnets with different security levels. High-security-level subnets enable full data collection and millisecond-level behavior modeling, medium-security-level subnets enable sampling collection and second-level modeling, and low-security-level subnets enable key event-triggered collection and minute-level modeling. The resource allocation ratio is dynamically allocated according to the number of devices and business importance within the subnet.

[0033] As one embodiment of the present invention, the system provides an open application programming interface (API) for third-party security management platforms to call. The API functions include real-time threat data subscription, historical event query, policy template distribution, device whitelist management, and model performance monitoring. The API authentication adopts a role-based access control model, with permission granularity refined to a single device and a single policy.

[0034] As one embodiment of the present invention, the automated response execution module automatically sends a secondary confirmation request to the designated administrator before executing isolation-level and cleanup-level actions, with a waiting time limit of thirty seconds. If no response is received within the time limit, the preset default strategy will be executed. All manual intervention records and system automatic decision logs are written to the anti-tampering audit database and retained for no less than three years.

[0035] As one embodiment of the present invention, the behavioral baseline adaptive correction module introduces a forgetting factor mechanism during the model fine-tuning process, assigning weights to historical samples that decay over time. The decay function adopts an exponential form, and the half-life is set to 3,600 time units, ensuring that the model can progressively adapt to the long-term evolution trend of device behavior without being disturbed by short-term noise.

[0036] As one embodiment of the present invention, the cross-device collaborative threat inference module performs pruning optimization on the joint tree algorithm, which consumes a lot of computing resources, during the probabilistic graphical model inference stage. The pruning threshold is dynamically adjusted according to the current system load. When the CPU utilization exceeds 80%, the coarse-grained approximate inference mode is enabled, sacrificing some accuracy in exchange for response speed, so as to ensure that real-time requirements can still be maintained in high-concurrency attack scenarios.

[0037] As one embodiment of the present invention, the global topology graph construction and maintenance module adopts a sharded storage and parallel computing architecture when processing large-scale IoT networks. It divides device nodes into different graph shards according to geographical location or business domain, establishes cross-shard indexes through communication edges between shards, and implements graph traversal query operations through a distributed graph computing framework, supporting sub-second path search performance at a scale of tens of millions of nodes.

[0038] As one embodiment of the present invention, when generating the behavior contour vector, the time-series behavior modeling module performs normalization processing on the two dimensions of device activity index and instruction call frequency gradient. The normalization benchmark value is taken from the statistical median of the same type of device group to avoid model deviation caused by differences in device type. The protocol usage preference distribution dimension is smoothed by Laplace to prevent zero probability events from affecting the stability of subsequent probability calculations.

[0039] As one embodiment of the present invention, when the security data acquisition agent module is running on a resource-constrained embedded device, it enables a lightweight acquisition mode, which only acquires control plane data and key telemetry indicators, abandons in-depth analysis of high-volume data planes, and reduces the acquisition frequency to once every five seconds, keeping memory usage below 50 megabytes to ensure that the main business functions of the device are not affected.

[0040] As one embodiment of the present invention, the method performs an initialization learning phase during the initial deployment, which lasts for seventy-two hours. During this period, only data is collected and no alarms are triggered. This phase is used to establish the initial behavioral baseline model and global topology map of each device. After initialization, the method automatically switches to the formal monitoring mode. Historical data is retained for subsequent model retraining.

[0041] As one embodiment of the present invention, the system supports a multi-tenant management mode, where different tenants have independent device namespaces, policy configuration libraries, model parameter sets and visualization views, data between tenants are completely isolated, resource quotas are allocated according to tenant subscription levels, and the highest-level tenant can exclusively occupy dedicated analysis nodes and customized threat inference models.

[0042] As one embodiment of the present invention, the offline model training and rule update module adopts a hybrid mode of online learning and batch learning when updating the parameters of the Bayesian belief network. It performs online gradient updates on small batches of new samples that come in in real time, and performs full retraining on large batches of samples that are periodically summarized, thus balancing the timeliness and accuracy of the model.

[0043] As one embodiment of the present invention, when the automated response execution module issues the access control list, it prioritizes intelligent switches that support flow table hardware acceleration as policy execution points, and the policy activation delay is controlled within 500 milliseconds; for traditional devices that do not support hardware acceleration, the proxy module implements software-level traffic filtering, and the latency tolerance is relaxed to two seconds.

[0044] As one embodiment of the present invention, the visualization situation presentation module supports voice interactive query function. Users can obtain information such as the security status of a specific device, the historical trend of a certain type of attack, and the current highest risk area through natural language commands. The voice recognition engine has a built-in domain-specific dictionary to ensure accurate understanding of Internet of Things terms.

[0045] As one embodiment of the present invention, when a new unknown attack mode is detected, the method automatically extracts attack feature fragments and submits them to the offline model training and rule update module, triggering a semi-supervised learning process. It uses a small number of labeled samples and a large number of unlabeled data to jointly train new detection rules. After manual review, the new rules are added to the formal rule base to achieve continuous accumulation of attack knowledge.

[0046] As one embodiment of the present invention, at the physical security level, all core modules of the system are deployed in a dedicated security server with electromagnetic shielding and tamper-proof enclosure. The server room implements biometric access control and 24-hour video surveillance. The data storage medium uses a self-encrypting hard drive, and the key is uniformly managed by the hardware security module, which meets the requirements of the third level of the national information security level protection.

[0047] As one embodiment of the present invention, the cross-device collaborative threat reasoning module generates an interpretability report when outputting a comprehensive threat score. The report includes the specific rule number that was triggered, the probability contribution value of the critical path in the Bayesian network, a list of affected devices and their risk levels, to assist security analysts in manual review and strategy optimization.

[0048] As one embodiment of the present invention, when the behavior baseline adaptive correction module reconstructs the initial model of the attacked device, it forces the device to complete firmware integrity verification and configuration item compliance checks. Only devices that pass all security baseline checks are allowed to reconnect to the monitoring system, preventing infected devices from introducing risks again.

[0049] As one embodiment of the present invention, the method supports linkage with physical security systems. When an advanced persistent threat to critical infrastructure is detected, it automatically sends an area blockade command to the access control system, a key area recording and saving command to the video surveillance system, and pushes an emergency response task to the security personnel terminal, thereby achieving collaborative defense between the digital world and the physical world.

[0050] The beneficial effects of this invention are as follows:

[0051] This invention discloses a real-time monitoring and protection method and system for IoT security data. By constructing a full-chain real-time protection system covering data acquisition, behavior modeling, topology association, collaborative reasoning, automatic response, and closed-loop optimization, it solves the technical defects of existing IoT security solutions, such as coarse-grained monitoring, isolated threat analysis, sluggish response, and rigid and ineffective strategies. Specifically, this invention achieves fine-grained dynamic profiling of IoT terminal device behavior, capturing millisecond-level abnormal fluctuations; establishes a global topology view of communication relationships between devices, revealing hidden lateral movement paths; integrates rule matching and probabilistic reasoning dual engines to improve the accuracy of identifying complex attack chains; implements a hierarchical automated response mechanism to curb threat spread while ensuring business continuity; and introduces adaptive model correction capabilities to continuously optimize protection strategies as the network environment evolves. Real-world testing shows that in industrial IoT scenarios with tens of millions of devices, this invention can increase the attack detection rate to over 98%, control the false alarm rate to below 2%, and shorten the average response latency to within 800 milliseconds, significantly enhancing the overall security and resilience of the IoT system. Attached Figure Description

[0052] The invention will now be further described with reference to the accompanying drawings.

[0053] Figure 1 This is a flowchart of a method for real-time monitoring and protection of IoT security data in this invention;

[0054] Figure 2 This is a structural framework diagram of an IoT security data real-time monitoring and protection system according to the present invention. Detailed Implementation

[0055] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0056] like Figure 1As shown in the embodiment of the present invention, a method for real-time monitoring and protection of IoT security data includes S1: continuously collecting raw communication data packets, device operation status logs, network connection event records, and application layer interaction command sequences of IoT terminal devices within their jurisdiction through a security proxy module deployed on IoT edge nodes or regional aggregation gateways;

[0057] S2: Perform protocol parsing and structured conversion on the original communication data packets, device operation status logs, network connection event records, and application layer interaction instruction sequences to extract a standardized set of metadata fields including source device identifier, destination device identifier, communication protocol type, data payload feature code, timestamp, session duration, and data transmission rate;

[0058] S3: The standardized metadata field set is sliced ​​by time window and then input into the lightweight time-series behavior modeling unit to construct the behavior profile vector of each IoT terminal device in the most recent several time units; the behavior profile vector is composed of device activity index, protocol usage preference distribution, data interaction object concentration, and instruction call frequency gradient.

[0059] S4: Establish a global device relationship topology graph; the graph uses devices as nodes, historical legal communication links as edges, and communication frequency and data volume as edge weights, and maintains dynamic consistency through an incremental graph update algorithm;

[0060] S5: When the behavior profile vector of any device deviates from its historical baseline model by more than a preset threshold, or when the current communication target does not have a legal edge connection in the global device relationship topology graph, a primary anomaly alarm signal is triggered.

[0061] S6: Input the primary anomaly alarm signal, along with the complete behavioral profile vector of the device, the current communication context snapshot, and the behavioral status of neighboring devices that have direct or indirect topological association with it, into the cross-device collaborative threat inference engine.

[0062] The cross-device collaborative threat inference engine employs a dual-channel analysis architecture that integrates rule matching and probabilistic graphical models to perform threat assessment. The first channel performs precise matching of a predefined attack pattern rule base, while the second channel constructs a Bayesian belief network to probabilistically infer the causal dependencies between multiple device anomalies, ultimately outputting a comprehensive threat score and attack intent classification label.

[0063] S7: Based on the comprehensive threat score and attack intent classification label, invoke the policy decision matrix to determine the corresponding automated response action; the automated response action includes cutting off the network connection of specific devices, redirecting suspicious traffic to honeypot nodes, issuing temporary access control lists to relevant switches, and pushing priority security work orders to the management platform.

[0064] S8: Feedback the execution results of all response actions to the behavior baseline correction module to dynamically adjust the parameters of the historical behavior profile model of the affected devices, thereby achieving closed-loop optimization of the protection strategy.

[0065] like Figure 2As shown, in the above-mentioned real-time monitoring and protection method for IoT security data, step S1 involves continuously collecting raw communication data packets, device operation status logs, network connection event records, and application layer interaction command sequences generated by IoT terminal devices through a security proxy module. It is understood that the IoT environment is characterized by a wide variety of terminal devices, encompassing heterogeneous entities such as industrial sensors, smart meters, video cameras, environmental monitors, and building controllers, with significant differences in communication protocols, data formats, sampling frequencies, and resource capabilities. Traditional security solutions often rely on centralized traffic mirroring or boundary firewall logs, which cannot cover fine-grained behavior at the edge, making it difficult to detect covert penetrations initiated by attackers exploiting protocol vulnerabilities or device firmware defects in a timely manner. Therefore, in the technical solution of this application, the security proxy module is deployed embedded in the IoT gateway firmware layer or an independent edge computing node, supporting deep packet analysis capabilities for mainstream industrial IoT protocols such as ModbusTCP, OPCUA, MQTT, and CoAP. Its collection frequency is no less than once per second, its data cache capacity is no less than 500 megabytes, and it supports offline resume and local compressed storage functions. Specifically, after startup, the security proxy module first completes its own initialization configuration, loads the pre-built protocol parsing plugin library and device whitelist, and then enters continuous monitoring mode to indiscriminately capture all data frames flowing through the local network segment. For each data frame, the security proxy module first records its physical layer reception timestamp, source MAC address, destination MAC address, VLAN tag, and other basic information. Then, based on the port number and protocol signature, it determines the protocol stack layer to which the frame belongs. If it is an application layer protocol carried by TCP or UDP, it further calls the corresponding protocol parser to extract semantic content. For example, for the ModbusTCP protocol, the parser needs to identify the transaction identifier, protocol identifier, length field, and unit identifier, and deeply parse key operation parameters such as function code, starting address, and number of registers; for the MQTT protocol, it needs to extract the client identifier, topic name, quality of service level, reserved flag, and payload content summary. In addition to communication data, the security proxy module synchronously collects device operation status logs, including operating system-level metrics such as CPU utilization, memory usage, process list, system call sequence, and file access records, as well as network connection event records, such as new connections, connection closures, port scan attempts, and abnormal retransmission counts. All collected data is temporarily stored in a circular buffer as a raw binary stream. Once a preset batch size or time interval is reached, it is packaged, compressed, and pushed to the next processing stage. To ensure data integrity, the security proxy module has a built-in verification mechanism that calculates a cyclic redundancy check code for each batch of data and automatically retryes in case of transmission failure, with a maximum of three retries and a timeout threshold of five seconds.In addition, the security proxy module supports adaptive resource adjustment. When it detects that its own CPU utilization exceeds 80% for ten consecutive seconds, it automatically reduces the collection frequency to once every two seconds and suspends the collection of non-critical logs to ensure that the main business communication performance is not affected.

[0066] In the aforementioned method for real-time monitoring and protection of IoT security data, step S2 involves protocol parsing and structural transformation of the collected raw data to extract a standardized set of metadata fields. It is understood that the raw collected data exhibits high heterogeneity, with different protocols having different data structures, encoding methods, and semantic meanings. Directly using this data for subsequent analysis would lead to feature dimension explosion and model training failure. Therefore, in the technical solution of this application, the protocol parsing and metadata extraction module adopts a layered parsing architecture. The first layer identifies the transport layer protocol type and port number; the second layer parses the application layer protocol semantic structure; and the third layer extracts key payload features such as instruction opcodes, register addresses, topic names, and resource paths. The final output set of metadata fields contains no fewer than twenty standardized fields. Specifically, the protocol parsing process begins with transport layer header analysis. The module first reads the protocol fields in the IP packet header, distinguishing between TCP, UDP, ICMP, and other types. Then, it parses the source and destination ports in the TCP / UDP header and, combined with a pre-set port-protocol mapping table, preliminarily determines the application layer protocol category. If the protocol is identified as a known protocol, such as ModbusTCP corresponding to port 502, the corresponding parser is loaded. If the port is unknown, the protocol fingerprinting engine is activated, and a secondary determination is made by comparing the feature pattern library of the first few bytes of the data payload. Once the protocol type is confirmed, the module enters the semantic parsing stage, extracting structured information field by field according to the protocol specification. Taking the OPCUA protocol as an example, the parser needs to decode the binary encoded message header, identify the message type such as read request, write response, and subscription notification, and then parse fields such as node identifier, attribute identifier, data value type, and timestamp precision, and classify and store floating-point data values, string node paths, and boolean quality flags respectively. For the MQTT protocol, the parser extracts the topic hierarchy structure in the published message, such as factory / zoneA / sensor01 / temperature, parses the QoS level value, calculates the payload hash digest as a feature code, and records and retains the flag status. All extracted fields are mapped to a unified metadata model, which defines the following core fields: source device unique identifier, destination device unique identifier, communication protocol enumeration value, data payload feature code hexadecimal string, timestamp with microsecond precision, session identifier, session duration in milliseconds, average data transmission rate in bytes per second, peak data transmission rate in bytes per second, instruction opcode integer encoding, destination register starting address, number of destination registers, topic name hierarchical path, quality of service level value, reserved flag boolean value, response latency in milliseconds, retransmission count, error code enumeration value, authentication status boolean value, encryption algorithm identifier, and data integrity verification result boolean value. To ensure field consistency, the module fills missing fields with preset default values ​​(e.g., zero for unknown protocols) and performs truncation or rounding on illegal fields (e.g., using the current system time if the timestamp is out of range).The structured metadata is organized in key-value pairs, with each record corresponding to a complete communication transaction or status event, and is accompanied by batch and acquisition agent identifiers for easy traceability. The metadata output format uses a compact binary serialization protocol with a compression rate of no less than 50% and transmission latency controlled within ten milliseconds.

[0067] In the aforementioned method for real-time monitoring and protection of IoT security data, step S3 involves slicing the standardized metadata field set into time windows and inputting it into a lightweight temporal behavior modeling unit to construct a behavior profile vector for each IoT terminal device. It is understood that IoT device behavior has a strong temporal dependence; instantaneous anomalies may mask long-term trends, and fluctuations in a single indicator are insufficient to characterize a real threat. Traditional methods based on static thresholds or isolated event detection are prone to generating numerous false alarms and cannot capture the gradual, progressive behavioral patterns of attackers. Therefore, in the technical solution of this application, the temporal behavior modeling module generates behavior profile vectors for each device based on a sliding window mechanism. These behavior profile vectors consist of four core dimensions: device activity index, protocol usage preference distribution, data interaction object concentration, and instruction call frequency gradient. The sliding window length is set to thirty time units, with each time unit corresponding to five seconds of actual duration, meaning each window covers one hundred and fifty seconds of historical data. The module maintains a circular queue in memory for each device, with a queue depth of thirty. Each slot stores the accumulated raw event counts and statistical characteristics within that time unit. Whenever a new metadata record arrives, the module first routes it to the corresponding queue based on the source device identifier, updates the counters for the current slot: the total number of communication events is incremented, the counters for each protocol type are incremented according to the protocol enumeration value, the counters for each instruction opcode are incremented according to the opcode field, and the data interaction target device identifier is added to a temporary set. When the time unit changes, the module freezes the data in the current slot, moves it to the history window, and clears the current slot to prepare for receiving data from the next cycle. The calculation of the behavior profile vector is triggered at the end of each time unit, and the specific calculation formula is as follows:

[0068]

[0069] Protocol usage preference distribution = ,

[0070] in

[0071] Data interaction object concentration = ,in The summation is calculated to determine the frequency percentage of the i-th target device within the window, covering all targets with non-zero frequencies.

[0072]

[0073] To improve model robustness, the module normalizes the device activity index and command call frequency gradient dimensions. The normalization baseline is taken from the statistical median of a group of devices of the same type to avoid model bias caused by differences in device type. Laplace smoothing is applied to the protocol usage preference distribution dimension to prevent zero-probability events from affecting the stability of subsequent probability calculations; the smoothing coefficient is set to 0.01. After calculation, the behavior profile vector is output as a four-dimensional floating-point array, appended with the device identifier and timestamp, and pushed to the anomaly detection triggering module. Simultaneously, the module maintains a global device type mapping table, automatically classifying devices based on the model information or protocol characteristics reported upon initial access, ensuring dynamic updates to the normalization baseline. For newly accessed devices, behavior profile vectors are not generated until five complete windows of data have been accumulated; only raw statistics are recorded for subsequent baseline initialization.

[0074] In the aforementioned method for real-time monitoring and protection of IoT security data, step S4 involves establishing and dynamically maintaining a global device relationship topology graph. It is understood that IoT attacks often manifest as lateral movement; after an attacker controls one device, they will attempt to scan and penetrate other devices within the same network, forming a propagation chain. Focusing only on single-point anomalies will fail to identify such coordinated attacks. Therefore, in the technical solution of this application, the global topology graph construction and maintenance module uses an adjacency list data structure to store device nodes and communication edges. The edge weight update cycle is ten minutes. If a communication edge has no data interaction for three consecutive update cycles, its weight is automatically reduced; if there is no interaction for five consecutive cycles, the edge is removed. New legitimate communication edges must undergo two-way handshake verification and management platform whitelist authorization before being added to the graph. Specifically, the module maintains a hash mapping in memory, where the key is the device's unique identifier and the value is a list of adjacent devices. Each adjacency entry includes the target device identifier, the last communication timestamp, the cumulative number of communications, the average data volume, and the floating-point edge weight. Whenever a new metadata record indicates that device A has initiated communication with device B, the module first checks whether A and B are already registered in the graph. If not, a new node is created. Next, it checks if an edge from A to B exists. If it exists, the last communication time is updated to the current timestamp, the cumulative number of communications is incremented, and the average data volume is updated using a moving average formula. If no edge exists, the edge creation process is triggered. The edge creation process first verifies the legality of the communication: the module sends a reverse probe packet to device B, requiring B to reply with a confirmation message within five seconds. If no reply is received within the time limit, it is considered a one-way scan, and the edge is not created. If a reply is received, the module further queries the management platform's whitelist to confirm whether A and B are allowed to establish a communication relationship. If there is no record in the whitelist, manual approval is required before adding it. The edge weight is initially set to one, and after each successful communication, it is updated according to the formula... Update, where α is the forgetting factor. ΔT represents the amount of data transmitted in this communication. This represents the historical average data volume for this edge. Edges with weights below 0.1 are marked as pending cleanup and are permanently deleted after five consecutive update cycles without interaction. The graph supports fast query operations; given a device identifier, it returns all its adjacent devices and edge weights for topology validity verification in subsequent anomaly detection. To handle large-scale networks, the module adopts a sharded storage architecture, allocating devices to different memory shards based on hash value modulo operations. Shards are coordinated through a global index to ensure query latency of less than 50 milliseconds even with tens of millions of nodes.

[0075] In the aforementioned method for real-time monitoring and protection of IoT security data, step S5 triggers a primary anomaly alarm signal when the behavioral profile vector of any device deviates from its historical baseline model by more than a preset threshold, or when its current communication target does not have a legal edge connection in the global device relationship topology graph. It can be understood that behavioral anomalies and topology anomalies are two complementary threat indicators; the former reflects sudden changes in the device's own state, while the latter reveals illegal lateral movement. Combining the two can significantly improve detection coverage. Therefore, in the technical solution of this application, the anomaly detection triggering module adopts a dual-condition parallel judgment mechanism. The historical baseline model uses a moving average plus standard deviation dynamic threshold method, with a baseline window length of 7,200 time units, i.e., ten hours. The anomaly judgment threshold is set to the mean plus or minus three times the standard deviation. Simultaneously, a mutation detection algorithm is introduced to identify step changes in the behavioral profile vector within a short period, with the mutation amplitude threshold set to 70% of the maximum allowable fluctuation range of each dimension of the profile vector. In practice, the module maintains two data structures for each device: a circular queue of length 7,200 to store historical behavior profile vectors; and four moving averages and standard deviations for activity index, protocol preference entropy, interaction concentration, and instruction gradient. Whenever a new behavior profile vector arrives, the module first calculates its absolute deviation from the historical mean. If any dimension's deviation exceeds three times the standard deviation, it is marked as a statistical anomaly. Next, it calculates the Euclidean distance between the current vector and the previous vector. If the distance exceeds a preset mutation threshold (e.g., 0.3 for the activity index), it is marked as a mutation anomaly. Simultaneously, the module queries the global topology graph to check if the target device for the current communication exists in the source device's adjacency list. If it does not exist and is not a broadcast address authorized by the management platform, it is marked as a topology anomaly. Upon triggering any anomaly flag, the module generates a primary anomaly alarm signal. The signal content includes the device identifier, anomaly type enumeration value, anomaly dimension index, deviation value, a copy of the current behavior profile vector, a set of communication context snapshot metadata records, and a Boolean value for the topology verification result. The alarm signal is encapsulated as a structured message and pushed to the cross-device collaborative threat inference engine. To prevent alarm storms, the module implements rate limiting, allowing the same device to trigger a maximum of one alarm within 60 seconds. Subsequent abnormal events are temporarily stored in a buffer queue and then merged and reported after the cooldown period.

[0076] In the aforementioned method for real-time monitoring and protection of IoT security data, step S6 involves inputting the initial anomaly alarm signal along with relevant context into the cross-device collaborative threat inference engine, outputting a comprehensive threat score and attack intent classification label. It is understood that a single point of failure may be caused by device malfunction or configuration error and does not necessarily represent a real attack; only when multiple device anomalies exhibit spatiotemporal correlation or logical causality do they constitute a high-confidence threat. Therefore, in the technical solution of this application, the cross-device collaborative threat inference module adopts a dual-channel analysis architecture based on the fusion of rule matching and probabilistic graphical models. The first channel performs precise matching on a predefined attack pattern rule base, containing no fewer than fifty rules covering typical IoT attack patterns such as port scanning, protocol malformed packet injection, unauthorized command execution, and high-frequency heartbeat spoofing. Each rule includes a trigger condition expression and a confidence weight coefficient. The second channel constructs a Bayesian belief network to probabilistically infer the causal dependencies between multiple device anomaly events. The network includes four types of latent variable nodes: device anomaly state nodes, communication link anomaly nodes, topology disturbance nodes, and external threat intelligence nodes. The conditional probability table between nodes is learned through parameter learning using historical attack sample sets during offline training. The inference process uses a joint tree algorithm to achieve efficient marginal probability calculation. In specific execution, the module first parses the primary anomaly alarm signal, extracting key fields such as device identifier, anomaly type, and behavior vector, and then starts the rule matching engine. The rule matching engine iterates through all predefined rules, evaluating the conditional expression of each rule. For example, the rule "high-frequency heartbeat spoofing" is defined as follows: if the device activity index changes by more than 0.4, the instruction call frequency gradient remains positive for more than three time units, and the heartbeat protocol accounts for more than 90% of the protocol preference distribution, then it is triggered, with a confidence weight of 0.8. All successfully matched rules are weighted and summed to obtain the rule channel score. In parallel, the module starts the Bayesian inference engine, inputting the state of the current abnormal device and its topologically adjacent devices as evidence nodes into the network, and calculating the posterior probability distribution of the attack intent nodes using the joint tree algorithm. The attack intent classification labels are predefined into five categories: reconnaissance and detection, credential theft, lateral movement, persistent residence, and data leakage, each corresponding to a probability value. The final comprehensive threat score is calculated using the formula... The calculation is performed, where β is the channel weight (0.6), MaxIntentProb is the probability of the highest intent, and the score and tag are encapsulated into a threat assessment result, which is then pushed to the automated response execution module. To ensure real-time performance, the module enables pruning optimization when the system load is too high. When the CPU utilization exceeds 80%, it automatically switches to coarse-grained inference mode, calculating only the probabilities of the top three most likely intents, sacrificing accuracy for speed.

[0077] In the aforementioned method for real-time monitoring and protection of IoT security data, step S7 involves calling a policy decision matrix to determine automated response actions based on a comprehensive threat score and attack intent classification labels. It is understood that different threat levels and attack intents require differentiated responses; overreaction may disrupt services, while insufficient response allows threats to spread. Therefore, in the technical solution of this application, the automated response execution module maintains a hierarchical response policy library. Policy levels are divided into four levels: observation, restriction, isolation, and cleanup. Each level corresponds to different combinations of response actions and execution permissions. Policy selection is based on the comprehensive threat score range: score ranges of 0 to 30 correspond to the observation level, 31 to 60 to the restriction level, 61 to 90 to the isolation level, and 91 to 100 to the cleanup level. Within each score range, specific action parameters are further refined based on attack intent classification labels. For example, when the score is 75 and the intent is lateral movement, the isolation level policy is executed: all network connections of the device are cut off, its traffic is redirected to the honeypot node, a temporary access control list is issued to adjacent devices to prohibit communication with the device, and an emergency security work order is pushed to the management platform. Action execution is achieved by calling the underlying network device APIs, such as calling the OpenFlow interface of a switch to issue flow table rules, calling the REST API of a firewall to update policies, and calling the device management agent to execute network disconnection commands. All actions are encapsulated as atomic transactions, ensuring that either all actions succeed or all actions roll back. Before execution, the module checks the security level of the target device. If it is a critical infrastructure device, a manual confirmation process is automatically triggered, sending an alert SMS and email to the designated administrator and waiting for 30 seconds. If there is no response after the timeout, the preset default policy is executed. The execution result is logged in detail, including action type, target device, execution time, return code, and time taken, and pushed to the behavior baseline correction module.

[0078] In the aforementioned method for real-time monitoring and protection of IoT security data, step S8 involves feeding back the execution results of all response actions to the behavior baseline correction module, dynamically adjusting the device behavior model parameters. It is understood that security strategies need continuous optimization as the environment evolves; false alarms should have reduced sensitivity, missed alarms should have enhanced detection capabilities, and devices need to rebuild trust after an attack. Therefore, in the technical solution of this application, the behavior baseline adaptive correction module initiates a model fine-tuning process after each response action is executed. For devices identified as false alarms, their current behavior profile vector is incorporated into the historical sample set to recalculate the moving average and standard deviation; for devices confirmed to have been attacked, their original behavior baseline is cleared after the isolation period ends, and the initial model is reconstructed using normal behavior data from the first 1000 time units after restarting; for devices that frequently trigger low-risk alarms, their baseline window length is automatically extended to 14,400 time units to enhance stability. The module introduces a forgetting factor mechanism during model fine-tuning, assigning weights to historical samples that decay over time. The decay function uses an exponential form, and the half-life is set to 3,600 time units, ensuring that the model can progressively adapt to the long-term evolution trend of device behavior without being affected by short-term noise. In practice, the module receives response logs, analyzes the final assessment conclusion for manual review or system confidence level. If the conclusion is a false alarm, it extracts the behavior vector that triggered the alarm from the circular queue, adds it to the historical sample set, and recalculates the movement statistics in four dimensions. If the conclusion is a real attack, after the device is unisolated, its behavior is monitored for the first 1,000 time units without triggering any alarms. After the period expires, the baseline is reconstructed using this data as a seed. If a device triggers more than five observation-level alarms within 24 hours, its baseline window is doubled. All adjustment operations are recorded in audit logs to ensure traceability.

[0079] The aforementioned method for real-time monitoring and protection of IoT security data further includes a visualization situation presentation module, an offline model training and rule update module, an open application programming interface (API), a physical security hardening mechanism, multi-tenant management support, voice interaction query function, a new attack self-learning process, a physical defense linkage interface, interpretable report generation, and firmware compliance mandatory verification, forming a complete, adaptive, and scalable IoT security protection system. Modules communicate via encrypted dedicated channels, employing end-to-end encryption using the national cryptographic SM4 algorithm, with keys rotated 24 hours a day. Data processing is fully anonymized, device identifiers are replaced with irreversible hashes, and only signature codes are retained in communication content. Differential monitoring strength configuration is supported, and resources are allocated according to subnet security levels. Fine-grained access control interfaces are provided for third-party interfaces. All decision logs are stored tamper-proofly for more than three years, meeting the requirements of Level 3 National Information Security Protection. Real-world testing shows that in industrial scenarios with tens of millions of devices, this solution achieves an attack detection rate of over 98%, a false alarm rate of less than 2%, and an average response latency of less than 800 milliseconds, significantly improving the security and resilience of the IoT system.

[0080] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for real-time monitoring and protection of IoT security data, characterized in that, Includes the following steps: S1: Through the security proxy module deployed at IoT edge nodes or regional aggregation gateways, it continuously collects the original communication data packets, device operation status logs, network connection event records and application layer interaction command sequences of IoT terminal devices within its jurisdiction. S2: Perform protocol parsing and structured conversion on the original communication data packets, device operation status logs, network connection event records, and application layer interaction instruction sequences to extract a standardized set of metadata fields including source device identifier, destination device identifier, communication protocol type, data payload feature code, timestamp, session duration, and data transmission rate; S3: The standardized metadata field set is sliced ​​by time window and then input into the lightweight time-series behavior modeling unit to construct the behavior profile vector of each IoT terminal device in the most recent several time units; the behavior profile vector is composed of device activity index, protocol usage preference distribution, data interaction object concentration, and instruction call frequency gradient. S4: Establish a global device relationship topology graph; the graph uses devices as nodes, historical legal communication links as edges, and communication frequency and data volume as edge weights, and maintains dynamic consistency through an incremental graph update algorithm; S5: When the behavior profile vector of any device deviates from its historical baseline model by more than a preset threshold, or when the current communication target does not have a legal edge connection in the global device relationship topology graph, a primary anomaly alarm signal is triggered. S6: Input the primary anomaly alarm signal, along with the complete behavioral profile vector of the device, the current communication context snapshot, and the behavioral status of neighboring devices that have direct or indirect topological association with it, into the cross-device collaborative threat inference engine. The cross-device collaborative threat inference engine employs a dual-channel analysis architecture that integrates rule matching and probabilistic graphical models to perform threat assessment. The first channel performs precise matching of a predefined attack pattern rule base, while the second channel constructs a Bayesian belief network to probabilistically infer the causal dependencies between multiple device anomalies, ultimately outputting a comprehensive threat score and attack intent classification label. S7: Based on the comprehensive threat score and attack intent classification label, invoke the policy decision matrix to determine the corresponding automated response action; the automated response action includes cutting off the network connection of specific devices, redirecting suspicious traffic to honeypot nodes, issuing temporary access control lists to relevant switches, and pushing priority security work orders to the management platform. S8: Feedback the execution results of all response actions to the behavior baseline correction module to dynamically adjust the parameters of the historical behavior profile model of the affected devices, thereby achieving closed-loop optimization of the protection strategy.

2. The method for real-time monitoring and protection of IoT security data according to claim 1, characterized in that, S2 involves protocol parsing and structure conversion of the original communication data packets, device operation status logs, network connection event records, and application layer interaction command sequences to extract a standardized set of metadata fields, including the following steps: A layered parsing architecture is adopted. The first layer identifies the transport layer protocol type and port number, the second layer parses the semantic structure of the application layer protocol, and the third layer extracts the payload features such as instruction opcode, register address, topic name, and resource path. The output should include no fewer than twenty standardized fields, including source device unique identifier, destination device unique identifier, communication protocol enumeration value, data payload feature code hexadecimal string, microsecond-level precision timestamp, session identifier, millisecond-level session duration, average data transfer rate per byte per second, peak data transfer rate per byte per second, instruction opcode integer encoding, destination register starting address, number of destination registers, topic name hierarchical path, quality of service level value, reserved flag boolean value, millisecond-level response latency, retransmission count, error code enumeration value, authentication status boolean value, encryption algorithm identifier, and data integrity verification result boolean value.

3. The method for real-time monitoring and protection of IoT security data according to claim 1, characterized in that, The S3 process involves slicing the standardized metadata field set by time window and inputting it into a lightweight time-series behavior modeling unit to construct a behavior profile vector, including the following steps: Set the sliding window length to thirty time units, with each time unit corresponding to a five-second actual duration. The device activity index is the ratio of the number of valid communications within the current window to the total number of samples taken within the window; The protocol usage preference distribution is a four-dimensional probability vector formed by the proportion of the frequency of each protocol occurrence to the total number of communications within the window. The concentration of data interaction objects is a discrete measure of the Shannon entropy of the communication target device identifier sequence; The instruction call frequency gradient is the result of the first-order difference operation of the difference in the number of instruction calls within adjacent time units; The device activity index and command call frequency gradient were normalized, with the normalization benchmark value taken from the statistical median of the same group of devices; the protocol usage preference distribution was smoothed using Laplace, with the smoothing coefficient set to 0.

01.

4. The method for real-time monitoring and protection of IoT security data according to claim 1, characterized in that, The process of establishing and dynamically maintaining a global device relationship topology map in S4 includes the following steps: An adjacency list data structure is used to store device nodes and communication edges; the edge weight is initially set to 1, and after each successful communication, it is calculated according to the formula: Updated, where α is the forgetting factor of 0.9, and ΔT is the amount of data in this communication. This represents the historical average data volume. If a communication edge has no data interaction for three consecutive update cycles, its weight will be automatically reduced. If it has no interaction for a total of five cycles, the edge will be removed. New legitimate communication edges must undergo two-way handshake verification and whitelist authorization from the management platform before they can be added to the graph.

5. The method for real-time monitoring and protection of IoT security data according to claim 1, characterized in that, The process of triggering a primary anomaly alarm signal in S5 includes the following steps: A historical baseline model was constructed using a moving average plus standard deviation dynamic threshold method. The baseline window length was 7,200 time units, and the anomaly detection threshold was set to the mean plus or minus three times the standard deviation. A mutation detection algorithm is introduced to identify step changes in the behavioral profile vector, and the mutation amplitude threshold is set to 70% of the maximum allowable fluctuation range of each dimension of the profile vector; When the deviation of any dimension of the behavior profile vector exceeds three times the standard deviation, or the Euclidean distance exceeds the preset mutation threshold, or the current communication target does not have a legal edge connection in the global topology graph, a primary anomaly alarm signal is generated. A rate limiting mechanism is implemented, allowing the same device to trigger an alarm at most once within sixty seconds.

6. The method for real-time monitoring and protection of IoT security data according to claim 1, characterized in that, The S6 process performs threat assessment through a cross-device collaborative threat inference engine, including the following steps: The rule matching channel has no fewer than fifty predefined attack feature rules, covering typical IoT attack modes such as port scanning, protocol malformed packet injection, command privilege escalation, and high-frequency heartbeat spoofing. Each rule includes a trigger condition expression and a confidence weight coefficient. The probabilistic graphical model channel constructs a Bayesian belief network, which includes four types of latent variable nodes: device abnormal state nodes, communication link abnormal nodes, topology disturbance nodes, and external threat intelligence nodes. The conditional probability table between nodes is learned by parameters through the historical attack sample set in the offline training phase. The reasoning process uses the joint tree algorithm to calculate the posterior probability distribution of attack intent nodes. The attack intent classification labels are predefined as five categories: reconnaissance and detection, credential theft, lateral movement, persistent residence, and data leakage. The overall threat score is calculated using the following formula: Calculate, where β is the channel weight (0.6) and MaxIntentProb is the highest intent probability.

7. The method for real-time monitoring and protection of IoT security data according to claim 1, characterized in that, The S7 process determines the automated response action by invoking the strategy decision matrix based on the comprehensive threat score and attack intent classification label, including the following steps: Maintain a tiered response strategy library, with strategy levels divided into four levels: observation, restriction, isolation, and cleanup. The scoring range of 0-30 corresponds to the observation level, 31-60 corresponds to the restriction level, 61-90 corresponds to the isolation level, and 91-100 corresponds to the elimination level. Within each scoring range, specific action parameters are refined based on attack intent classification tags; Before execution, check the security level of the target equipment. If it is a critical infrastructure equipment, trigger a manual confirmation process with a waiting time limit of 30 seconds. If there is no response after the time limit, execute according to the preset default policy. All actions are encapsulated into atomic transactions to ensure consistent execution.

8. The method for real-time monitoring and protection of IoT security data according to claim 1, characterized in that, In step S8, the response action execution result is fed back to the behavior baseline correction module to dynamically adjust the model parameters, including the following steps: For devices identified as false alarms, their current behavior profile vectors are included in the historical sample set, and the moving average and standard deviation are recalculated. For devices confirmed to have been attacked, the original behavioral baseline is cleared after the quarantine period ends, and the initial model is reconstructed using normal behavioral data from the first thousand time units after restarting. For devices that frequently trigger low-risk alarms, automatically extend their baseline window length to 14,400 time units. A forgetting factor mechanism is introduced during model fine-tuning, with the decay function in exponential form and the half-life set to 3,600 time units.

9. A real-time monitoring and protection system for IoT security data, applicable to the real-time monitoring and protection method for IoT security data as described in any one of claims 1-8, characterized in that, include: Security data acquisition agent module: This module is used to continuously collect raw communication data packets, device operation status logs, network connection event records, and application layer interaction command sequences from IoT terminal devices within its jurisdiction by security agent modules deployed at IoT edge nodes or regional aggregation gateways. Protocol parsing and metadata extraction module: used to perform protocol parsing and structured conversion on the original communication data packets, device operation status logs, network connection event records and application layer interaction instruction sequences, and extract a standardized set of metadata fields including source device identifier, destination device identifier, communication protocol type, data payload feature code, timestamp, session duration, and data transmission rate; Temporal behavior modeling module: This module is used to slice the standardized metadata field set into time windows and input it into the lightweight temporal behavior modeling unit to construct the behavior profile vector of each IoT terminal device in the most recent several time units; the behavior profile vector is composed of device activity index, protocol usage preference distribution, data interaction object concentration, and instruction call frequency gradient. Global Topology Graph Construction and Maintenance Module: Used to establish a global device relationship topology graph; the graph uses devices as nodes, historical legal communication links as edges, and communication frequency and data volume as edge weights, and maintains dynamic consistency through an incremental graph update algorithm; Anomaly detection trigger module: used to trigger a primary anomaly alarm signal when the behavior profile vector of any device deviates from its historical baseline model by more than a preset threshold, or when the current communication target does not have a legal edge connection in the global device relationship topology graph; Cross-device collaborative threat inference module: This module takes the primary anomaly alarm signal, along with the device's complete behavioral profile vector, current communication context snapshot, and behavioral status of neighboring devices that are directly or indirectly related to it, and inputs them into the cross-device collaborative threat inference engine. The engine then performs threat assessment using a dual-channel analysis architecture that combines rule matching and probabilistic graphical models, and outputs a comprehensive threat score and attack intent classification label. The automated response execution module is used to invoke the policy decision matrix based on the comprehensive threat score and attack intent classification label to determine the corresponding automated response action. The automated response action includes cutting off the network connection of specific devices, redirecting suspicious traffic to honeypot nodes, issuing temporary access control lists to relevant switches, and pushing priority security work orders to the management platform. Behavioral baseline adaptive correction module: This module feeds back the execution results of all response actions to the behavioral baseline correction module, dynamically adjusts the parameters of the historical behavioral profile model of the affected devices, and achieves closed-loop optimization of the protection strategy.

10. The IoT security data real-time monitoring and protection system according to claim 9, characterized in that, The time-series behavior modeling module is specifically used for: Set the sliding window length to thirty time units, with each time unit corresponding to a five-second actual duration. The device activity index is calculated as the ratio of the number of valid communications within the current window to the total number of samples taken within the window. The protocol usage preference distribution is a four-dimensional probability vector formed by the proportion of the frequency of each protocol occurrence to the total number of communications within the window. The concentration of data interaction objects is calculated as the discrete quantification of the Shannon entropy of the communication target device identifier sequence. The gradient of instruction call frequency is calculated as the result of a first-order difference operation on the difference in the number of instruction calls within adjacent time units. The device activity index and command call frequency gradient are normalized, and the normalization benchmark value is taken from the statistical median of the same group of devices. The protocol usage preference distribution was smoothed using Laplace smoothing with a smoothing coefficient of 0.01.

Images