A computer network security protection method and system based on big data

Abstract

The application relates to the technical field of computer network security, and discloses a computer network security protection method and system based on big data, which comprises the following steps: capturing the flow data between Internet of Things devices in real time, removing low-frequency irrelevant interactions to obtain a simplified flow data set; analyzing the communication frequency and connection density of the data set to construct an initial device communication relationship graph; calculating the node centrality and communication path length in the graph to determine a key communication cluster; extracting a cluster abnormal node marker to determine an abnormal communication mode; tracing a risk path and comparing historical data to obtain an attack clue sequence; calculating a node trust score to mark a high-risk node and adjusting an edge weight to determine a threat core path; updating the communication relationship graph and verifying the decision to obtain an optimized protection decision basis. The method realizes whole-process management and control of the Internet of Things network security, improves threat identification accuracy and protection response efficiency, and provides support for edge network security protection.

Description

Technical Field

[0001] This invention relates to the field of computer network security technology, and in particular to a computer network security protection method and system based on big data. Background Technology

[0002] The accuracy and real-time performance of computer network security protection directly affect the operational security of IoT devices and the effectiveness of data privacy protection. Efficient IoT intrusion detection and abnormal communication identification are key to ensuring the stable operation of edge networks and reducing losses from malicious attacks, and are of great significance to improving network security protection capabilities in IoT scenarios.

[0003] In one existing technology, network security protection mainly adopts a static detection mode based on a fixed rule base. It formulates protection schemes by pre-setting abnormal features, performs local intrusion investigation by combining single device log data, and makes simple records of information such as communication relationships between devices and dynamic threat patterns.

[0004] However, static detection modes operate based on preset rules, rely on fixed feature libraries and single data feedback, and cannot leverage big data technology to deeply mine and correlate intrusion clues in massive traffic data. They also cannot adapt in real-time to the dynamically changing communication relationships and covert attack patterns between IoT devices. When unknown intrusion behaviors or abnormal communication strength changes occur in the edge network, they are prone to problems such as missed intrusion detection, false alarms, or delayed protection responses. Therefore, existing technologies are insufficient to meet the high-precision intrusion detection requirements of IoT devices in complex edge network scenarios. Summary of the Invention

[0005] This invention provides a computer network security protection method and system based on big data to solve the problem of insufficient identification of dynamic intrusion behavior in existing network security protection, resulting in low intrusion detection accuracy.

[0006] In a first aspect, the present invention provides a computer network security protection method based on big data, comprising:

[0007] Real-time capture of traffic data between IoT devices, removal of low-frequency irrelevant interactions, and a simplified traffic dataset are obtained;

[0008] For the simplified traffic dataset, analyze the communication frequency and connection density, and construct an initial device communication relationship diagram;

[0009] The initial device communication relationship graph is analyzed to calculate the node centrality metric and communication path length, and to determine the key communication clusters.

[0010] For the critical communication cluster, abnormal node markers are extracted. When the node centrality exceeds a preset abnormal node centrality threshold and the communication path length is lower than a preset length standard, it is determined to be an abnormal communication mode.

[0011] If the abnormal communication pattern is identified, the risk path is traced from the device communication relationship diagram, and the threat propagation range and historical abnormal data are compared to obtain the associated attack clue sequence.

[0012] Based on the attack clue sequence, calculate the trust score of the node and compare it with a preset trust score threshold. Nodes with a trust score lower than the preset trust score threshold are marked as high-risk nodes. Adjust the edge weight distribution and determine the core threat path.

[0013] Based on the core threat path, update the overall device communication relationship diagram to obtain the optimized final protection decision basis.

[0014] Secondly, the present invention provides a computer network security protection system based on big data, comprising:

[0015] The traffic simplification module is used to capture traffic data between IoT devices in real time, remove low-frequency irrelevant interactions, and obtain a simplified traffic dataset.

[0016] The relationship building module is used to analyze the communication frequency and connection density of the simplified traffic dataset and build an initial device communication relationship graph.

[0017] The cluster determination module is used to analyze the initial device communication relationship graph, calculate the node centrality metric and communication path length, and determine the key communication clusters;

[0018] The anomaly detection module is used to extract abnormal node markers from the critical communication cluster. When the node centrality exceeds a preset abnormal node centrality threshold and the communication path length is lower than a preset length standard, it is determined to be an abnormal communication mode.

[0019] The clue acquisition module is used to trace the risk path from the device communication relationship graph if the abnormal communication pattern is identified, compare the threat propagation range with historical abnormal data, and obtain the associated attack clue sequence.

[0020] The path determination module is used to calculate the trust score of the node based on the attack clue sequence and compare it with a preset trust score threshold, mark the node with a lower than the preset trust score threshold as a high-risk node, adjust the edge weight distribution, and determine the core threat path.

[0021] The decision generation module is used to update the overall device communication relationship diagram based on the core threat path to obtain the optimized final protection decision basis.

[0022] Compared with the prior art, the present invention has the following beneficial effects:

[0023] (1) This invention uses big data technology to perform hierarchical filtering and correlation analysis of IoT device traffic, constructs a device communication relationship diagram, breaks through the limitations of traditional static rule bases in identifying dynamic intrusion behavior, and achieves accurate capture of hidden communication relationships and potential intrusion clues between devices, providing data support for intrusion detection;

[0024] (2) This invention uses the division of key communication clusters and the marking of abnormal nodes, combined with historical data comparison to track threat paths, so that the protection scheme can adapt to the dynamically changing attack patterns in the edge network in real time, reducing the problems of missed and false alarms in intrusion detection.

[0025] (3) This invention forms a closed-loop mechanism of “traffic analysis-anomaly identification-threat location-protection optimization” by calculating node trust scores and locking the core threat path, combined with dynamic updates of the communication relationship graph. This ensures that protection decisions are highly matched with the network security needs of the edge network and improves the anti-intrusion capability and operational security of IoT devices. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the computer network security protection method based on big data provided in the first embodiment of the present invention;

[0027] Figure 2 This is a schematic diagram of the structure of a computer network security protection system based on big data provided in the second embodiment of the present invention. Detailed Implementation

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

[0029] Reference Figure 1 The first embodiment of the present invention provides a computer network security protection method based on big data, comprising the following steps:

[0030] S1 captures real-time traffic data between IoT devices, removes low-frequency irrelevant interactions, and obtains a simplified traffic dataset.

[0031] S2, For the simplified traffic dataset, analyze the communication frequency and connection density, and construct an initial device communication relationship diagram;

[0032] S3, Analyze the initial device communication relationship diagram, calculate the node centrality metric and communication path length, and determine the key communication clusters;

[0033] S4. For the key communication cluster, extract abnormal node markers. When the node centrality exceeds the preset abnormal node centrality threshold and the communication path length is lower than the preset length standard, it is determined to be an abnormal communication mode.

[0034] S5. If the abnormal communication pattern is identified, trace the risk path from the device communication relationship diagram, compare the threat propagation range with historical abnormal data, and obtain the associated attack clue sequence.

[0035] S6. Based on the attack clue sequence, calculate the trust score of the node and compare it with the preset trust score threshold. Mark the nodes that are lower than the preset trust score threshold as high-risk nodes, adjust the edge weight distribution, and determine the core threat path.

[0036] S7. Based on the core threat path, update the overall device communication relationship diagram to obtain the optimized final protection decision basis.

[0037] In step S1, traffic data between IoT devices is captured in real time, low-frequency irrelevant interactions are removed, and a simplified traffic dataset is obtained, including:

[0038] S11, capture raw traffic data between IoT devices, remove low-frequency irrelevant interaction records with interaction frequency below the preset communication frequency threshold, and obtain a preliminary simplified traffic set;

[0039] S12, the preliminary simplified traffic set is segmented by time, and data segments containing periodic high-frequency interaction characteristics are retained to form a traffic subset;

[0040] S13, compare the device interaction patterns in the traffic subset with the preset communication behavior characteristics, retain the key communication data that is successfully matched, and integrate them to obtain a simplified traffic dataset.

[0041] In step S1, the raw traffic data between IoT devices is captured, and low-frequency irrelevant interaction records with interaction frequencies lower than a preset communication frequency threshold are removed to obtain a preliminary simplified traffic set.

[0042] It should be noted that the capture of raw traffic data is achieved by deploying a traffic mirroring acquisition component at the core gateway or switch of the edge network to replicate all communication data packets transmitted between IoT devices in real time. The acquired data packets must include the device's unique identifier (such as MAC address, device number), the timestamp of the interaction (accurate to milliseconds), the data frame length, the type of communication protocol used (such as MQTT, CoAP), and the data packet payload summary information. For example, in a smart home scenario, the authentication data packets transmitted between the smart door lock (device number DL-001) and the home gateway (device number GW-001) via the MQTT protocol, and the status reporting data packets between the smart air conditioner (device number AC-001) and the control center (device number CC-001) must all be completely captured.

[0043] The preset communication frequency threshold is set to 5 interactions per minute. This threshold is based on statistics of the normal communication behavior of 10 typical IoT devices (smart door locks, air conditioners, speakers, cameras, sensors, etc.). It was found that the interaction frequency of devices for core functions (such as status monitoring and command response) is generally no less than 5 times per minute. Low-frequency interactions, such as the brightness synchronization of smart lights 1-2 times a day and the firmware version check of smart curtains once a week, are mostly non-safety-critical interactions. Removing such data can reduce the amount of data for subsequent analysis. Tests have shown that this threshold can reduce the amount of original data by about 60% while retaining more than 95% of the safety-related interaction records.

[0044] The removal of low-frequency interaction records refers to grouping devices into "device pairs" (such as DL-001 and GW-001, AC-001 and CC-001), counting the number of interactions for each group of devices within a unit of time (1 minute), and if the number of interactions for a certain group of devices is less than 5 times for three consecutive minute periods, then all interaction records of that group of devices within the corresponding period are marked as low-frequency irrelevant interactions and removed from the original data, ultimately resulting in a preliminary streamlined traffic set containing only high-frequency interaction records. For example, smart lamps (device number LT-001) and GW-001 interact only 2 times per minute, maintaining this frequency for 3 consecutive minutes, and their interaction records for the corresponding time period are removed; while AC-001 and CC-001 interact 8 times per minute, with no instances of interactions below the threshold for 3 consecutive minutes, and their interaction records are completely retained in the preliminary streamlined traffic set.

[0045] In step S12, the preliminary simplified traffic set is segmented by time, and data segments containing periodic high-frequency interaction characteristics are retained to form a traffic subset.

[0046] It should be noted that the time segmentation adopts a fixed time window of 10 minutes. The length of this window is set based on the analysis of the periodic interaction behavior of IoT devices. It was found that the regular interactions of most devices, such as the timed identity verification requests of smart door locks at 8 am and 6 pm, and the frame transmission of smart cameras every 5 minutes, can be fully presented within a 10-minute window. If the window is too short (such as 5 minutes), it is easy to split the interaction of the same period into different windows, resulting in the omission of periodic identification. If the window is too long (such as 15 minutes), it will contain too much non-periodic interaction data, increasing redundancy.

[0047] The identification of periodic high-frequency interaction characteristics refers to statistically analyzing device interaction records within each time window according to "device pair - interaction interval". If a "device pair" exhibits interactions at fixed time intervals (e.g., once every 2 minutes, once every 3 minutes) in three consecutive adjacent time windows, and the number of interactions at this fixed interval accounts for more than 70% of the total number of interactions within the window, then the "device pair" is determined to have periodic high-frequency interaction characteristics within the corresponding window. For example, if DL-001 and GW-001 interact once every 2 minutes in the three windows of 8:00-8:10, 8:10-8:20, and 8:20-8:30, and the number of interactions at this interval accounts for 85% of the total number of interactions in each window, then periodic high-frequency interaction characteristics are determined to exist.

[0048] The retention of corresponding data segments refers to retaining the complete time window data containing periodic high-frequency interaction characteristics, while window data that does not meet the periodic characteristics are completely removed, ultimately forming a traffic subset containing only periodic high-frequency interaction data. For example, the three 10-minute window data corresponding to DL-001 and GW-001 are completely retained, while window data of a certain "device pair" that only has high-frequency interaction within a single window but does not have periodicity is removed.

[0049] In step S13, the device interaction patterns in the traffic subset are compared with preset communication behavior characteristics, key communication data that are successfully matched are retained, and the simplified traffic dataset is obtained.

[0050] It should be noted that the preset communication behavior characteristics are based on an interaction template library pre-built according to typical security-related scenarios of IoT devices. This library includes four core modes: "Request-Response," "Timed Reporting," "Command Issuance," and "Anomaly Alarm." Each mode defines a clear interaction sequence, data format, and field characteristics: The "Request-Response" mode requires a clear request data packet (containing a "Request" identifier field) and a corresponding response data packet (containing a "Response" identifier field), with the time interval between them not exceeding 1 second; the "Timed Reporting" mode requires the data to contain a "StatusReport" field, and the interaction interval is fixed; the "Command Issuance" mode requires the data to contain a "Command" field, and the initiator must be a control device (such as CC-001, GW-001); the "Anomaly Alarm" mode requires the data to contain an "Alarm" field, and the data frame length must be greater than that of a regular interaction data packet, typically approximately 64-128 bytes, with alarms exceeding 256 bytes.

[0051] It is worth noting that the preset communication behavior feature template library is predefined based on IoT communication protocol specifications (such as MQTT, CoAP, HTTP) and industry best practices. The template definition includes analyzing the protocol message structure and extracting key fields (such as the "Request" and "Response" identifiers in MQTT); statistically analyzing the normal device interaction sequence and setting the maximum response interval (such as 1 second); and combining security policies to mark abnormal patterns (such as abnormally increased data packet length). The template library is stored in JSON format and supports dynamic updates. When a new device type or protocol version is added, a new template can be added through the administrator console.

[0052] The comparison interaction mode refers to extracting the interaction records of each "device pair" from the traffic subset, arranging them in "time order," and then matching them one by one against the pattern features in the template library: first, checking whether the data packet contains the identifier field of the corresponding pattern, then verifying whether the interaction sequence and data length meet the template requirements. If all features match, the pattern is considered to be successfully matched. For example, DL-001 sends a data packet (96 bytes long) containing the "Request-Auth" field to GW-001. 100 milliseconds later, GW-001 returns a data packet (80 bytes long) containing the "Response-Auth-Success" field, which matches the "request-response" pattern feature, and the match is considered successful.

[0053] The retention of successfully matched key communication data refers to marking successfully matched interaction records as "key communication data". Interaction records that do not match any pattern, such as data packets without clear identification fields or with disordered timing, are judged as non-key data and removed. For example, a data packet without any pattern identification field and with irregular interaction intervals is judged as non-key data and removed.

[0054] The streamlined traffic dataset obtained through integration refers to storing all "key communication data" in a structured format. Each data entry contains "initiating device identifier - receiving device identifier - interaction timestamp - interaction mode type - data packet length - core field summary", such as "DL-001-GW-001, 2023-10-01 08:00:00.123, request-response, 96 bytes, summary, Request-Auth;UserID:001". This dataset can be directly used for subsequent device communication relationship analysis, and the data volume is only 15%-20% of the original traffic data, significantly reducing the subsequent computational burden.

[0055] In step S2, the simplified traffic dataset is analyzed for communication frequency and connection density to construct an initial device communication relationship graph, including:

[0056] S21, extract device identifiers, number of interactions and duration from the simplified traffic dataset, and calculate the communication frequency and connection density between devices;

[0057] S22, Remove device association records whose connection density is lower than a preset connection density threshold to obtain filtered communication data;

[0058] S23. Based on the filtered communication data, an initial device communication relationship graph is constructed, with devices as nodes and the communication frequency as the weight of the edges between nodes.

[0059] In step S21, device identifiers, number of interactions, and duration are extracted from the simplified traffic dataset, and the communication frequency and connection density between devices are calculated.

[0060] It should be noted that the extraction of device identifiers, number of interactions, and duration refers to determining a unique "device pair" from the simplified traffic dataset by "initiating device identifier - receiving device identifier", counting the number of interactions of each "device pair" within a unit of time (1 hour) (i.e., the total number of interaction records of the "device pair" included in that hour), and calculating the duration of each interaction (the difference between the timestamp of the data packet sent by the initiating device and the timestamp of the acknowledgment data packet returned by the receiving device; if it is a one-way transmission, half of the time interval between the sending of the data packet and the sending of the next data packet is taken), and summing them to obtain the total interaction duration of the "device pair" within 1 hour.

[0061] The calculated communication frequency refers to the number of interactions between each "device pair" within one hour as the communication frequency of that "device pair", with the unit being "times / hour". This indicator reflects the frequency of interaction between devices. For example, if AC-001 and CC-001 have 20 interaction records within one hour, their communication frequency is 20 times / hour; if DL-001 and GW-001 have 15 interaction records within one hour, their communication frequency is 15 times / hour.

[0062] The connection density calculation refers to dividing the total interaction time of each "device pair" within 1 hour by the time length (1 hour, i.e., 3600 seconds) to obtain the percentage of interaction time per unit time, with the unit being "seconds / hour". This indicator reflects the tightness of communication between devices. For example, if the total interaction time between AC-001 and CC-001 within 1 hour is 300 seconds, its connection density is 300 seconds / hour; if the total interaction time between DL-001 and GW-001 within 1 hour is 240 seconds, its connection density is 240 seconds / hour.

[0063] In step S22, device association records with connection densities lower than a preset connection density threshold are removed to obtain filtered communication data.

[0064] It should be noted that the preset connection density threshold is set at 100 seconds / hour. This threshold is set based on the statistical analysis of the connection density of core "device pairs" in five typical IoT scenarios: smart home, industrial control, smart healthcare, smart transportation, and environmental monitoring. It was found that the connection density of core communication "device pairs" normally used for security protection analysis is generally not less than 100 seconds / hour. "Device pairs" with a connection density of less than 100 seconds / hour are mostly occasional or low-importance interactions, which have no substantial value for analyzing device communication relationships. Removing such data can further focus on core associations.

[0065] The removal of low connection density records refers to iterating through the connection density data of all "device pairs". If the connection density of a "device pair" is below 100 seconds / hour for two consecutive hours, all communication records of that "device pair" are removed from the streamlined traffic dataset, and only the communication records of "device pairs" with a connection density ≥ 100 seconds / hour are retained, forming the filtered communication data. For example, the connection density between the smart socket (device number PS-001) and GW-001 is 40 seconds / hour, and there has been no improvement for two consecutive hours, so its communication records are removed; while the connection density between the smart camera (device number CAM-001) and GW-001 is 250 seconds / hour, which meets the threshold requirement, so its communication records are retained.

[0066] In step S23, based on the filtered communication data, an initial device communication relationship graph is constructed, with devices as nodes and the communication frequency as the weight of the edges between nodes.

[0067] It should be noted that, with devices as nodes, each IoT device involved in the filtered communication data is treated as an independent node element. The node name uses a unique device identifier (such as DL-001, GW-001, AC-001). At the same time, for easy visual differentiation, different types of device nodes are identified by different colors (such as red for control devices GW-001 and CC-001, blue for terminal devices DL-001 and AC-001, and green for sensing devices).

[0068] Using communication frequency as the weight of an edge means that for each "device pair" in the filtered communication data, a connection edge is established between the two corresponding device nodes. The weight value of the edge is directly taken from the communication frequency (times / hour) of the "device pair". The higher the communication frequency, the greater the weight value of the edge, and the thicker the corresponding line in the visualization graph. For example, the communication frequency of AC-001 and CC-001 is 20 times / hour, the weight of the corresponding edge is 20, and the line thickness is 2mm; the communication frequency of DL-001 and GW-001 is 15 times / hour, the weight of the corresponding edge is 15, and the line thickness is 1.5mm.

[0069] The construction of the initial device communication relationship graph refers to using an undirected graph topology (because communication between IoT devices is mostly bidirectional) and mapping device nodes and weighted connection edges according to actual communication relationships using graph visualization tools (such as Neo4j and Gephi). This forms a topology graph that intuitively reflects the communication strength and association between devices. Control devices (such as GW-001) will naturally be located at the center of the graph due to their high-weighted connections with multiple terminal devices, while the terminal devices are distributed around them, making it easy to quickly identify the core communication architecture in the network.

[0070] In step S3, the analysis of the initial device communication relationship graph, the calculation of node centrality metric and communication path length, and the determination of key communication clusters include:

[0071] S31, Based on the initial device communication relationship diagram, calculate the centrality metric of each node and obtain the communication path length between nodes;

[0072] S32, remove nodes whose centrality metric is lower than the preset core node threshold, and retain high-frequency interaction nodes to form a candidate node set;

[0073] S33, extract the high-frequency interactive connection structure of the nodes in the candidate node set to form the core device subgraph;

[0074] S34, divide the key communication clusters according to the communication density in the core device sub-graph, and the communication density in the cluster must be higher than the preset cluster density threshold.

[0075] In step S31, based on the initial device communication relationship diagram, the centrality metric of each node is calculated, and the communication path length between nodes is statistically obtained.

[0076] It should be noted that the centrality metric for computing nodes uses the degree centrality algorithm. The algorithm is chosen because in edge IoT networks, the coreness of a device is mainly reflected in the number of devices it directly connects to, rather than complex indirect connection paths. For example, betweenness centrality focuses on the number of paths that are intermediated. Degree centrality more directly reflects the core position of a device in the network. The calculation method is that the centrality metric of a node is equal to the number of other nodes that have established direct connections with that node. For example, GW-001 directly connects to DL-001, AC-001, CAM-001, and the smart speaker (device number SP-001), so its centrality metric is 4; AC-001 only directly connects to GW-001 and CC-001, so its centrality metric is 2; and DL-001 only directly connects to GW-001, so its centrality metric is 1.

[0077] The statistical communication path length refers to calculating the number of intermediate nodes required for communication between any two nodes in the initial device communication relationship graph. The path length is calculated using a shortest path algorithm (such as Dijkstra's algorithm), which selects the path with the fewest intermediate nodes as the calculation basis. The path length value is equal to the number of intermediate nodes in the shortest path. For example, the shortest path between DL-001 and AC-001 is DL-001→GW-001→AC-001, which passes through 1 intermediate node (GW-001), and its communication path length is 1. The shortest path between DL-001 and CC-001 is DL-001→GW-001→AC-001→CC-001, which passes through 2 intermediate nodes (GW-001, AC-001), and its communication path length is 2. If the two nodes are directly connected (such as DL-001 and GW-001), then the number of intermediate nodes is 0, and the communication path length is 0.

[0078] In step S32, nodes whose centrality metric is lower than the preset core node threshold are removed, and high-frequency interaction nodes are retained to form a candidate node set.

[0079] It should be noted that the preset core node threshold is set to 2. This threshold is set based on the analysis of node centrality in multi-scenario IoT networks. It was found that the centrality metric values ​​of core communication nodes, such as gateways, control centers, and important terminal devices, are generally not lower than 2. Nodes with centrality metric values ​​lower than 2 are mostly edge sensing devices and low-importance terminal devices, which have little impact on the overall communication cluster. Removing such nodes can reduce the computational load of subsequent cluster analysis and avoid edge nodes interfering with the identification of the core cluster. Tests have shown that this threshold can remove about 30% of edge nodes without affecting the integrity of the core communication architecture.

[0080] The removal of low-centrality nodes refers to traversing all nodes in the initial device communication graph, removing nodes with a centrality metric value lower than 2 from the graph, and deleting all connecting edges associated with these nodes. Only nodes with a centrality metric value ≥ 2 and their corresponding connecting edges are retained. These retained nodes are the high-frequency interaction nodes, forming a candidate node set. For example, DL-001, with a centrality metric value of 1 (below the threshold of 2), is removed, and its connecting edge with GW-001 is also deleted. GW-001 (centrality 4), AC-001 (centrality 2), CC-001 (centrality 3), CAM-001 (centrality 2), and SP-001 (centrality 2) all have a centrality ≥ 2 and are retained in the candidate node set.

[0081] In step S33, the high-frequency interactive connection structure of the nodes in the candidate node set is extracted to form a core device subgraph.

[0082] It should be noted that the extraction of high-frequency interactive connection structures refers to filtering connections in the candidate node set whose weight (communication frequency) of the connecting edges between nodes is higher than 10 times / hour. The weight threshold is set based on the statistical distribution of the weights of the connecting edges in the candidate node set. It was found that the weights of core communication connections are generally higher than 10 times / hour, while connections with a weight lower than 10 times / hour are mostly secondary associations in the candidate node set (such as the occasional data sharing between CAM-001 and SP-001), which have no key impact on the core communication architecture. After being removed, the focus can be on core associations.

[0083] The formation of the core equipment subgraph refers to grouping candidate nodes together, and forming an independent subgraph structure with nodes and connecting edges whose weights are ≥10 times / hour. This subgraph only contains core nodes and core connecting edges. For example, the connecting edges between GW-001 and AC-001 (weight 20), GW-001 and CAM-001 (weight 18), GW-001 and SP-001 (weight 16), and AC-001 and CC-001 (weight 14) all have ≥10 times / hour. These nodes and connecting edges together constitute the core equipment subgraph, which intuitively presents the most critical communication links and node associations in the network.

[0084] In step S34, key communication clusters are divided according to the communication density within the core device sub-graph, and the communication density within each cluster must be higher than a preset cluster density threshold.

[0085] It should be noted that the communication density within the core equipment subgraph refers to the average connection density between each node in the core equipment subgraph and all other nodes in the subgraph. This indicator reflects the overall communication density of the nodes within the subgraph. For example, the connection densities of GW-001 with AC-001, CAM-001, and SP-001 are 300 seconds / hour, 280 seconds / hour, and 250 seconds / hour, respectively, and their average communication density is (300+280+250)÷3=277 seconds / hour; the connection densities of AC-001 with GW-001 and CC-001 are 300 seconds / hour and 260 seconds / hour, respectively, and their average communication density is (300+260)÷2=280 seconds / hour.

[0086] The preset cluster density threshold is set to 150 seconds / hour. This threshold is set based on the analysis of the average communication density of different types of core device subgraphs. It was found that the average communication density of control clusters (such as GW-001, CC-001 and associated terminals) is mostly above 200 seconds / hour, while the average communication density of data transmission clusters (such as CAM-001, AC-001) is mostly between 150 and 200 seconds / hour. 150 seconds / hour is the minimum density standard covering all types of core clusters. Node combinations below this value are loosely associated and cannot form an effective cluster.

[0087] The division of critical communication clusters refers to using a community detection algorithm (such as the Louvain algorithm) to group nodes in the core device subgraph with an average communication density ≥150 seconds / hour and an inter-node connection edge weight ≥10 times / hour into the same cluster. Nodes in each cluster must satisfy the condition that "there is a direct or indirect core connection (weight ≥10 times / hour) between any two nodes". For example, GW-001, AC-001, CC-001, CAM-001, and SP-001 all have an average communication density ≥150 seconds / hour and have core connections with each other, and are therefore divided into a critical communication cluster. If there is another group of nodes in the core device subgraph that meets the conditions, then it is divided into a second critical communication cluster.

[0088] In step S4, for the critical communication cluster, abnormal node markers are extracted. When the node centrality exceeds a preset abnormal node centrality threshold and the communication path length is lower than a preset length standard, it is determined to be an abnormal communication mode, including:

[0089] S41, Obtain historical interaction records of each node from the key communication cluster, and filter out potential abnormal nodes whose interaction behavior deviates from the average level of the cluster.

[0090] S42, obtain the centrality metric of the potential abnormal node; if the centrality metric of the potential abnormal node exceeds the preset abnormal node centrality threshold and the path length is lower than the preset length standard, mark the node as an abnormal node.

[0091] S43, Summarize the marking results of the abnormal nodes, and combine them with the interaction and association of the abnormal nodes in the critical communication cluster to determine an abnormal communication mode.

[0092] In step S41, historical interaction records of each node are obtained from the key communication cluster, and potential abnormal nodes whose interaction behavior deviates from the average level of the cluster are screened out.

[0093] It should be noted that obtaining historical interaction records refers to extracting communication data of each node in the critical communication cluster over the past 24 hours, including the number of interactions per hour, the length of the data packet for each interaction, the direction of interaction (such as A→B or B→A), and the integrity of data transmission. Data packet verification is used to determine whether there is any loss or tampering. Complete data is recorded as "normal" and abnormal data is recorded as "abnormal", ensuring that all core interaction characteristics of the nodes in the recent period are covered.

[0094] The average level of the computing cluster refers to calculating the average number of interactions and the average data packet length per hour over 24 hours for all nodes within the critical communication cluster. The average number of interactions is the arithmetic mean of the number of interactions per hour for all nodes, and the average data packet length is the arithmetic mean of the data packet length for each interaction between all nodes. For example, if the number of interactions per hour for 5 nodes in the cluster is 15, 20, 18, 16, and 17 over 24 hours, the average number of interactions is (15+20+18+16+17)÷5=17.2 times / hour; and the data packet lengths for each node are 96, 128, 80, 112, and 104 bytes, the average data packet length is (96+128+80+112+104)÷5=104 bytes.

[0095] The selection of nodes deviating from the cluster average level refers to the following criteria: if a node's interaction count for any three consecutive hours within a 24-hour period is higher than twice the cluster average or lower than 50% of the cluster average, or if the node's data packet length for ten consecutive interactions is higher than twice the average or lower than 50% of the average, or if the node experiences more than five data transmission integrity anomalies, then the node is considered a potential abnormal node. These deviation criteria are based on statistical analysis of the interaction fluctuation range of normal nodes. It was found that the interaction count and data packet length of normal nodes typically fluctuate between 50% and 200% of the average, and the number of integrity anomalies rarely exceeds three. Nodes exceeding these ranges are considered potentially abnormal. For example, if a node's interaction count for three consecutive hours is 40, 42, and 38 times / hour (average 17.2 times / hour, higher than twice the average), and its data packet length for ten consecutive interactions is consistently 256 bytes (average 104 bytes, higher than twice the average), it is considered a potential abnormal node.

[0096] In step S42, the centrality metric of the potential abnormal node is obtained. If the centrality metric of the potential abnormal node exceeds the preset abnormal node centrality threshold and the path length is lower than the preset length standard, the node is marked as an abnormal node.

[0097] It should be noted that the preset abnormal node centrality threshold is set to 3. The basis for this threshold setting is that in order to expand the range of threat propagation, abnormal nodes usually actively increase the number of connections with other nodes, making their centrality metric value significantly higher than that of normal nodes. Statistical analysis of past abnormal events shows that the centrality metric value of abnormal nodes generally exceeds 3. If it is lower than 3, the threat propagation capability is limited. This threshold can effectively distinguish between normal core nodes and abnormal nodes.

[0098] The preset length standard is set to 1. This standard is based on the fact that abnormal communication is mostly direct connection (path length 0) or only passes through 1 intermediate node (path length 1) to achieve rapid threat propagation. If the path length exceeds 1, such as passing through 2 or more intermediate nodes, the propagation efficiency will be greatly reduced, which does not meet the rapid spread characteristics of abnormal behavior. Therefore, a path length of less than 1 (i.e., path length is 0 or 1) is regarded as a typical characteristic of abnormal nodes.

[0099] The process of marking abnormal nodes involves first calculating the centrality metric of a potential abnormal node within the critical communication cluster, and then calculating the communication path length between the node and other nodes in the cluster. If the centrality metric exceeds 3 and the communication path length with at least 3 other nodes is less than 1, the node is marked as an abnormal node. For example, a potential abnormal node has a centrality metric of 4 (exceeding the threshold of 3), and its communication path length with GW-001, AC-001, and CAM-001 is 1 (below the standard of 1), thus it is marked as an abnormal node.

[0100] In step S43, the marking results of the abnormal nodes are summarized, and combined with the interaction association of the abnormal nodes in the critical communication cluster, they are determined to be abnormal communication patterns.

[0101] It should be noted that the summarized abnormal node marking results refer to the number of abnormal nodes, device type (such as terminal device, control device), and location (center or edge in the map) of all abnormal nodes in the critical communication cluster. For example, two abnormal nodes are marked in the cluster, both of which are terminal devices (CAM-002, SP-002), located at the edge of the map but directly connected to the center GW-001.

[0102] The analysis of the interaction association of abnormal nodes refers to checking whether there is a direct or indirect communication connection between abnormal nodes, and whether the interaction frequency between abnormal nodes and normal core nodes (such as GW-001, CC-001) has increased abnormally. For example, if the interaction frequency suddenly increases from 10 times / hour to 50 times / hour within 24 hours, if there is a direct connection between abnormal nodes and the interaction frequency with core nodes has increased abnormally, it indicates that there is an abnormal communication link.

[0103] The determination of an abnormal communication mode refers to the existence of two or more abnormal nodes in the critical communication cluster, and the abnormal nodes or the abnormal nodes and the core node form a high-frequency direct connection link (path length ≤ 1, weight ≥ 30 times / hour). For example, if CAM-002 and SP-002 have a direct connection (weight 35 times / hour, path length 0), and the interaction frequency between both of them and GW-001 suddenly increases from 10 times / hour to 50 times / hour (weight 50 times / hour, path length 0), it is determined to be an abnormal communication mode.

[0104] In step S5, if the abnormal communication pattern is identified, the risk path is traced from the device communication relationship graph, and the threat propagation range and historical abnormal data are compared to obtain the associated attack clue sequence, including:

[0105] S51, Starting from the abnormal node in the abnormal communication mode, traverse the device communication relationship diagram, trace all communication links of the abnormal node, and determine potential risk paths;

[0106] S52, count the number of nodes covered by each potential risk path, define the threat propagation range of the potential risk path, and eliminate paths whose threat propagation range is lower than a preset propagation range threshold;

[0107] S53, extract the communication features of the remaining potential risk paths and compare them with the attack path features in historical anomaly data;

[0108] S54, filter out paths with a matching degree higher than a preset matching degree threshold, extract the communication records of the paths and sort them by time to form an attack clue sequence.

[0109] In step S51, starting from the abnormal node in the abnormal communication mode, the device communication relationship diagram is traversed to trace all communication links of the abnormal node and determine potential risk paths.

[0110] It should be noted that the traversal of the communication relationship graph starting from the abnormal node refers to using a breadth-first traversal algorithm for each abnormal node, starting from the abnormal node, tracing back all its directly and indirectly connected nodes layer by layer, recording the connection order of each node, and forming a complete communication link. For example, if the direct connected node of abnormal node CAM-002 is GW-001, and the direct connected nodes of GW-001 are AC-001, CC-001, and SP-001, then the communication links starting from CAM-002 are CAM-002→GW-001, CAM-002→GW-001→AC-001, CAM-002→GW-001→CC-001, and CAM-002→GW-001→SP-001.

[0111] The determination of potential risk paths refers to marking all communication links containing abnormal nodes as potential risk paths. These paths may be carriers of threat propagation. Each potential risk path must clearly record the complete node sequence of "starting point (abnormal node) - intermediate node - ending point (normal node)" and the weight of the connecting edges between each node. For example, the four communication links starting from CAM-002 are all marked as potential risk paths. Each path records the node sequence and the corresponding edge weight (e.g., the weight of CAM-002→GW-001 is 50 times / hour, and the weight of GW-001→AC-001 is 20 times / hour).

[0112] In step S52, the number of nodes covered by each potential risk path is counted, the threat propagation range of the potential risk path is defined, and paths whose threat propagation range is lower than a preset propagation range threshold are eliminated.

[0113] It should be noted that the number of nodes covered by the statistical path refers to the total number of independent nodes (including the starting point, intermediate nodes, and ending point) in the path for each potential risk path. For example, the path CAM-002→GW-001 contains 2 nodes, the path CAM-002→GW-001→AC-001 contains 3 nodes, and the path CAM-002→GW-001→AC-001→CC-001 contains 4 nodes.

[0114] The preset propagation range threshold is set to 3 nodes. This threshold is based on the fact that threat propagation needs to cover a certain number of nodes to cause substantial security impact. Paths that only cover 2 nodes, such as abnormal node → single normal node, have a limited impact range and are unlikely to cause large-scale threats. Paths that cover 3 or more nodes can enable the spread of threats between core nodes and have a higher risk. Therefore, potential risk paths with fewer than 3 covered nodes are eliminated.

[0115] The removal of low-propagation-range paths refers to traversing all potentially risky paths, removing paths with fewer than 3 covered nodes from the list, and retaining only paths with 3 or more covered nodes. For example, the path CAM-002→GW-001 (2 nodes) is removed, while the paths CAM-002→GW-001→AC-001 (3 nodes), CAM-002→GW-001→CC-001 (3 nodes), and CAM-002→GW-001→SP-001 (3 nodes) are retained.

[0116] In step S53, the communication features of the remaining potential risk paths are extracted and compared with the attack path features in historical anomaly data.

[0117] It should be noted that the historical anomaly data refers to the attack path data of IoT network security incidents stored in the past two years, including 500+ typical attack cases, such as DDoS attacks, device hijacking, and data theft. Each case records the communication characteristics of the attack path, including the amplitude of communication frequency fluctuations, data packet length distribution, interaction time distribution, and protocol type anomaly rate.

[0118] The extraction of communication characteristics of potential risk paths refers to calculating the communication frequency fluctuation range of each retained potential risk path within 24 hours. For example, if the normal frequency of a certain path is 10 times / hour, and the frequency during the attack is 50 times / hour, the fluctuation range is 400%. It also involves statistically analyzing packet length distribution, such as 80% of the data packet length being concentrated between 256 and 512 bytes, recording interaction time distribution, such as 70% of the interactions being concentrated between 2:00 AM and 4:00 AM, and calculating the protocol type anomaly rate, such as 15% of the interactions using non-standard MQTT fields.

[0119] The feature comparison refers to comparing each communication feature of a potential risk path with the average value of the corresponding feature in historical anomaly data. For example, the frequency fluctuation amplitude of a potential risk path (400%) is compared with the average fluctuation amplitude of historical attack paths (380%), and the data packet length distribution is compared with the average distribution of historical attack data packets. The comparison result of each feature dimension is represented by a "matching score". A complete match scores 100 points, a complete mismatch scores 0 points, and a partial match scores according to the overlap ratio. Finally, the total matching degree of each path is the arithmetic mean of the matching degree scores of all feature dimensions. The matching degree score of each feature dimension (frequency fluctuation, data packet length distribution, etc.) is calculated using the weighted Euclidean distance method, with each dimension having a weight of 25% (due to balanced feature importance). The total matching degree is the arithmetic mean of the scores of each dimension, or the weighted Euclidean distance method can be used as needed. The weight values ​​have been tested to balance the false positive and false negative rates.

[0120] It should be noted that the historical anomaly data is constructed by collecting publicly available IoT security datasets (such as IoT-23 and CICIDS2017) and internal security event logs; the data is stored in a relational database, and each record contains attack path characteristics (such as communication frequency fluctuation amplitude, packet length distribution, interaction time distribution, and protocol type anomaly rate); the data is updated monthly, and new events are imported from the Security Information and Event Management (SIEM) system through automated scripts to ensure that the historical data covers the latest threat patterns.

[0121] In step S54, paths with a matching degree higher than a preset matching degree threshold are selected, and the communication records of the paths are extracted and sorted by time to form an attack clue sequence.

[0122] It should be noted that the preset matching threshold is set to 80%. This threshold is set based on the statistical data found that the feature matching degree between normal paths and attack paths is generally less than 50%, while the matching degree between real attack paths and historical attack features is generally higher than 80%. 80% is the critical value for distinguishing between normal paths and attack paths. Paths with a matching degree below 80% are likely to be normal fluctuations, while paths with a matching degree above 80% are highly suspected of being attacked.

[0123] The screening of high-match-rate paths refers to retaining potential risk paths with a total match rate ≥ 80%, which are considered as suspected attack paths. For example, a path with a frequency fluctuation match rate of 90 points, a data packet length match rate of 85 points, a time distribution match rate of 75 points, and a protocol anomaly match rate of 80 points has a total match rate of (90+85+75+80)÷4=82.5 points (≥ 80 points), and is retained as a suspected attack path.

[0124] The extraction and sorting of communication records by time refers to extracting the interaction records of all "device pairs" on the suspected attack path from the simplified traffic dataset. Each record contains "interaction timestamp - initiating device - receiving device - data packet length - protocol characteristics - integrity status". These records are then arranged in order of interaction timestamp from earliest to latest to form an ordered sequence of attack clues, such as "2023-10-01 02:00:00, CAM-002→GW-001, 256 bytes, non-standard MQTT field, complete; 2023-10-01 02:01:30, GW-001→AC-001, 384 bytes, standard MQTT field, complete; ...". This sequence can clearly present the propagation timeline and characteristics of the threat along the path.

[0125] In step S6, based on the attack clue sequence, the trust score of the node is calculated and compared with a preset trust score threshold. Nodes with a trust score lower than the preset trust score threshold are marked as high-risk nodes. The edge weight distribution is adjusted, and the core threat path is determined, including:

[0126] S61, extract the interaction frequency, data transmission integrity and historical security records of each node from the attack clue sequence, and calculate the trust score of each node by weighting.

[0127] S62, compare the trust score with a preset trust score threshold, and mark nodes that are lower than the preset trust score threshold as high-risk nodes;

[0128] S63, Based on the degree of association between the high-risk node and other nodes, adjust the weight of the corresponding edge in the device communication relationship graph to optimize the edge weight distribution;

[0129] S64, sort the paths in the adjusted device communication relationship diagram by weight, and select the path with the highest weight as the core threat path.

[0130] In step S61, the interaction frequency, data integrity, and historical security records of each node are extracted from the attack clue sequence, and the trust score of each node is calculated by weighting.

[0131] It should be noted that the extraction of interaction frequency refers to counting the total number of interactions of each node within 24 hours from the attack clue sequence, and then mapping the interaction frequency of all nodes to a standardized range of 0-100 points. The mapping method is to multiply the ratio of the node's interaction frequency to the highest interaction frequency among all nodes by 100. For example, if the highest interaction frequency is 100 times and a node's interaction frequency is 80 times, its standardized value is 80 points; if the highest interaction frequency is 100 times and a node's interaction frequency is 30 times, its standardized value is 30 points.

[0132] The extraction of data transmission integrity refers to classifying all interaction records of each node in the attack clue sequence as "complete" or "abnormal". Complete means that the data packet is verified correctly and there is no loss or tampering, while abnormal means that the verification is wrong, the data is lost or tampered with. Then, the integrity score of the node is calculated. The integrity score is the quotient of the number of complete interaction records divided by the total number of interaction records, multiplied by 100. For example, if a node has 90 complete interactions and 10 abnormal interactions out of 100 interactions, its integrity score is 90 points; if a node has 40 complete interactions and 40 abnormal interactions out of 80 interactions, its integrity score is 50 points.

[0133] The extraction of historical security records refers to querying the security violation records of each node over the past 6 months, such as whether there have been intrusions, sending malicious data packets, or accessing unauthorized networks. A score of 100 is awarded for no violations, 60 for one violation, and 0 for two or more violations. For example, a node with no violations in the past 6 months receives 100 points; a node with one violation receives 60 points; and a node with three violations receives 0 points. These historical security records are obtained from a local security information management system or cloud security platform via API. Query parameters include device identifier and time range (past 6 months). The returned results include the type of security violation (such as unauthorized access or data tampering) and the number of occurrences. If no integrated system is available, the records can be initialized as empty and supplemented manually later.

[0134] The weighted calculation of the trust score is based on the following weight allocation: 40% for the standardized value of interaction frequency, 30% for the data transmission integrity score, and 30% for the historical security record score. These weights are determined experimentally using an IoT device security risk assessment model. Through historical data regression analysis, it was found that interaction frequency has the highest threat sensitivity (approximately 40%), followed by data transmission integrity (30%), and historical record stability is relatively strong (30%). This ratio has been verified in multiple scenarios to optimize classification accuracy to over 90%. Specifically, the calculation method is as follows: first, multiply the standardized value of interaction frequency by 40; then, multiply the data transmission integrity score by 30; then, multiply the historical security record score by 30; add these three results to obtain the total score; and finally, divide the total score by 100 to obtain the trust score. For example, if a node has a standardized interaction frequency score of 80, an integrity score of 90, and a history record score of 60, the calculation process is as follows: 80×40=3200, 90×30=2700, 60×30=1800, total score=3200+2700+1800=7700, and trust score=7700÷100=77.

[0135] In step S62, the trust score is compared with a preset trust score threshold, and nodes that are lower than the preset trust score threshold are marked as high-risk nodes.

[0136] It should be noted that the preset trust score threshold is set to 60 points. This threshold is set based on dividing the node trust score into three risk levels: 80-100 points is "low risk", 60-79 points is "medium risk", and below 60 points is "high risk". 60 points is the critical value to distinguish between medium risk and high risk. Marking nodes below this value as high-risk nodes can accurately pinpoint the core risk source.

[0137] The process of marking high-risk nodes involves traversing the trust scores of all nodes, marking nodes with scores below 60 as "high-risk nodes," and recording the reasons for their risk, such as abnormally low interaction frequency, low integrity score, and numerous historical violations. For example, a node with a trust score of 55, a standardized interaction frequency of 40, an integrity score of 50, and a historical record score of 80 is below the threshold of 60 and is therefore marked as a high-risk node. The reasons for the risk are recorded as "low interaction frequency and poor data transmission integrity."

[0138] In step S63, the weights of the corresponding edges in the device communication graph are adjusted according to the degree of association between the high-risk node and other nodes, thereby optimizing the edge weight distribution.

[0139] It should be noted that the determination of the degree of association refers to classifying the degree of association into "strong association" and "weak association" based on the frequency of interaction and connection density between high-risk nodes and other nodes: if the interaction frequency between a high-risk node and a certain node is ≥20 times / hour and the connection density is ≥200 seconds / hour, it is determined to be "strong association"; if the interaction frequency is <10 times / hour and the connection density is <100 seconds / hour, it is determined to be "weak association"; and those in between are "medium association".

[0140] The adjusted edge weights refer to different adjustment strategies applied to connection edges with different degrees of correlation: "Strong correlation" edges between high-risk nodes and other nodes have their weight increased by 50% (to highlight the main path of threat propagation); "Medium correlation" edges between high-risk nodes and other nodes have their weight increased by 30%; "Weak correlation" edges between high-risk nodes and other nodes have their weights unchanged; and "Weak correlation" edges between non-high-risk nodes (weight < 5 times / hour) have their weights decreased by 30% (to reduce irrelevant interference). For example, the edge between high-risk nodes CAM-002 and GW-001 originally had a weight of 50 times / hour (strong correlation), and after adjustment, it becomes 50 × (1 + 50%) = 75 times / hour; the edge between high-risk nodes CAM-002 and SP-002 originally had a weight of 15 times / hour (medium correlation), and after adjustment, it becomes 15 × (1 + 30%) = 19.5 times / hour; the edge between normal nodes AC-001 and SP-001 originally had a weight of 4 times / hour (weak correlation), and after adjustment, it becomes 4 × (1 - 30%) = 2.8 times / hour.

[0141] The optimized edge weight distribution refers to adjusting the weight of threat-related paths in the device communication relationship graph to be significantly higher than that of normal paths. For example, after adjustment, the weight of high-risk node associated edges is generally above 20 times / hour, while the weight of normal weakly associated edges is mostly below 5 times / hour, which facilitates the rapid identification of core risk paths.

[0142] In step S64, the paths in the adjusted device communication relationship diagram are sorted by weight, and the path with the highest weight is selected as the core threat path.

[0143] It should be noted that the sum of the calculated path weights refers to adding the weights of all connecting edges on each path in the adjusted device communication graph to obtain the total weight of that path. For example, the edge weights of the path CAM-002→GW-001→AC-001 are 75 times / hour and 20 times / hour, respectively, and the total weight is 75+20=95 times / hour; the edge weights of the path CAM-002→GW-001→CC-001 are 75 times / hour and 18 times / hour, respectively, and the total weight is 75+18=93 times / hour; the edge weights of the path CAM-002→GW-001→SP-001 are 75 times / hour and 16 times / hour, respectively, and the total weight is 75+16=91 times / hour.

[0144] The weighted sorting refers to arranging all paths containing high-risk nodes from high to low according to their total weight. The higher the total weight of a path, the greater the likelihood of threat propagation and the more significant the impact.

[0145] The selection of the path with the highest weight as the core threat path means determining the path with the highest total weight in the ranking results as the core threat path. This path is the main channel for the spread of threats in the network and is also the key target of subsequent protection strategies. For example, in the example above, the path CAM-002→GW-001→AC-001 with a total weight of 95 times / hour was determined as the core threat path.

[0146] In step S7, based on the core threat path, the overall device communication relationship diagram is updated to obtain the optimized final protection decision basis, including:

[0147] S71, Based on the weight of the core threat path, adjust the weight of each edge in the overall device communication relationship diagram to strengthen the high-risk identification of the core threat path;

[0148] S72, reconstruct the topology of the device communication relationship diagram, delete isolated nodes and low-association connections, and obtain the updated device communication relationship diagram;

[0149] S73, input the real-time device interaction data into the updated device communication relationship diagram to verify the anomaly identification accuracy and response latency of the updated device communication relationship diagram;

[0150] S74, if the anomaly identification accuracy is higher than a preset validity threshold and the response delay is lower than a preset delay threshold, generate the final protection decision basis based on the updated device communication relationship diagram.

[0151] In step S71, the weights of each edge in the overall device communication relationship diagram are adjusted according to the weights of the core threat path to strengthen the high-risk identification of the core threat path.

[0152] It should be noted that the adjustment of the edge weights of the core threat path refers to increasing the weights of all connecting edges on the core threat path by an additional 40% on top of the weights adjusted in step S63. This adjustment ratio is based on testing findings that an additional 40% increase can make the weight of the core threat path at least 30% higher than that of other paths. This can be clearly distinguished in the visualization graph by the thickness of the lines. For example, the edge weight of the core threat path CAM-002→GW-001 after adjustment is 75 times / hour, and after an increase of 40%, it becomes 75×(1+40%)=105 times / hour; the edge weight of GW-001→AC-001 after adjustment is 20 times / hour, and after an increase of 40%, it becomes 20×(1+40%)=28 times / hour. The total weight becomes 105+28=133 times / hour.

[0153] The adjustment of edge weights for non-core paths refers to increasing the weights of edges associated with high-risk nodes on non-core paths by 10% based on the weights adjusted in step S63 (only slightly to avoid interfering with core paths); for edges on non-core paths between normal nodes, the weights remain unchanged from the result of the adjustment in step S63. For example, the edge weight between high-risk nodes CAM-002 and SP-002 is 19.5 times / hour after adjustment, and then increased by 10% to 21.45 times / hour; the edge weight between normal nodes AC-001 and SP-001 remains unchanged at 2.8 times / hour.

[0154] The enhanced high-risk identification refers to adjusting the weights so that the core threat path becomes the path with the highest weight and thickest line in the device communication relationship diagram. At the same time, the path and related nodes are highlighted in red in the diagram to visually highlight the core risks and facilitate rapid location by subsequent protection personnel.

[0155] In step S72, the topology of the device communication relationship diagram is reconstructed, isolated nodes and low-association connections are deleted, and an updated device communication relationship diagram is obtained.

[0156] It should be noted that the deletion of isolated nodes refers to deleting nodes in the updated device communication relationship graph that have no connection edges (i.e., no interaction records) within 24 hours. These nodes are mostly offline or abandoned devices and have no impact on the current security protection. For example, a certain smart sensor (device number SN-001) has no interaction within 24 hours and is judged as an isolated node and deleted.

[0157] The deletion of low-association connections refers to deleting connection edges with a weight of less than 3 times per hour. This weight threshold is set based on the statistically adjusted edge weight distribution. It was found that edges with a weight of less than 3 times per hour are mostly very weakly correlated and have no significance for threat analysis. Deleting them can make the graph structure more concise. For example, the edge weight between normal nodes SP-001 and SN-002 is 2.5 times per hour, which is judged as a low-association connection and deleted.

[0158] The updated device communication relationship graph refers to the graph that retains the core threat path, the strongly associated path of high-risk nodes, the core path of normal nodes (weight ≥ 10 times / hour) and the corresponding nodes, forming a simplified and key-focused topology graph. For example, the updated graph only includes GW-001, CC-001, AC-001, CAM-002 (high-risk), SP-002 (high-risk) and related high-weight connection edges. The graph data volume is reduced by about 50% compared to the initial graph, and the core risk paths are clearly visible.

[0159] In step S73, real-time device interaction data is input into the updated device communication relationship diagram to verify the anomaly identification accuracy and response latency of the updated device communication relationship diagram.

[0160] It should be noted that the real-time device interaction data collection refers to the collection of real-time interaction data of the nodes involved in the updated device communication relationship diagram for the past hour, with a data volume of no less than 1,000 entries, ensuring that it includes sufficient normal interactions and potential abnormal interactions.

[0161] The calculation of anomaly identification accuracy refers to inputting real-time interactive data into the updated device communication relationship graph, which automatically identifies abnormal interactions based on edge weights and node risk indicators. Then, the automatic identification results are compared with manually labeled real anomaly data. The anomaly identification accuracy is calculated as the quotient of the number of automatically identified correct anomalies divided by the number of manually labeled real anomalies multiplied by 100%. For example, if 50 real anomalies are manually labeled and the graph automatically identifies 45 correctly, the accuracy is 90%.

[0162] The calculated response latency refers to the time difference between the generation of real-time interactive data (the device sending data packets) and the identification of an anomaly by the graph and the output of alarm information. The response latency of 100 anomaly identifications is statistically analyzed, and the average value is taken as the final response latency. For example, the latency of 100 identifications is 80 milliseconds, 95 milliseconds, 100 milliseconds, etc., and the average value is 92 milliseconds.

[0163] In step S74, if the anomaly identification accuracy is higher than a preset validity threshold and the response delay is lower than a preset delay threshold, the final protection decision basis is generated based on the updated device communication relationship diagram.

[0164] It should be noted that the preset effectiveness threshold is set to 90%. This threshold is set based on the fact that the anomaly identification accuracy of the security protection system needs to reach more than 90% to effectively reduce false negatives and ensure that most threats can be detected in a timely manner. The preset delay threshold is set to 100 milliseconds. This threshold is set based on the real-time protection requirements of edge IoT networks. A response delay of more than 100 milliseconds may result in the threat spreading before the protection measures are triggered. A delay of less than 100 milliseconds can achieve a rapid response.

[0165] The basis for generating the final protection decision refers to formulating specific protection strategies based on the updated device communication relationship graph if the anomaly identification accuracy is ≥90% and the response latency is ≤100 milliseconds. These strategies include: blocking measures, such as prohibiting direct communication between high-risk nodes (e.g., CAM-002, SP-002) and core control nodes (e.g., GW-001, CC-001); monitoring measures, such as real-time traffic monitoring of the core threat path (CAM-002→GW-001→AC-001) and setting traffic thresholds (e.g., no more than 20 interactions per hour), triggering alarms if the threshold is exceeded; permission restrictions, such as reducing the operational permissions of high-risk nodes associated with normal nodes, e.g., prohibiting AC-001 from receiving control commands from CAM-002; and periodic updates, such as setting a dynamic update cycle for the graph to ensure the protection strategies adapt to real-time risk changes. These protection strategies collectively constitute the final protection decision basis and can be directly used for security deployment in edge IoT networks.

[0166] In summary, this invention discloses a computer network security protection method and system based on big data, which can realize full-process control of IoT network security, improve the accuracy of threat identification and protection response efficiency, and provide support for edge network security protection.

[0167] Reference Figure 2 The second embodiment of the present invention provides a computer network security protection system based on big data, comprising:

[0168] The traffic simplification module is used to capture traffic data between IoT devices in real time, remove low-frequency irrelevant interactions, and obtain a simplified traffic dataset.

[0169] The relationship building module is used to analyze the communication frequency and connection density of the simplified traffic dataset and build an initial device communication relationship graph.

[0170] The cluster determination module is used to analyze the initial device communication relationship graph, calculate the node centrality metric and communication path length, and determine the key communication clusters;

[0171] The anomaly detection module is used to extract abnormal node markers from the critical communication cluster. When the node centrality exceeds a preset abnormal node centrality threshold and the communication path length is lower than a preset length standard, it is determined to be an abnormal communication mode.

[0172] The clue acquisition module is used to trace the risk path from the device communication relationship graph if the abnormal communication pattern is identified, compare the threat propagation range with historical abnormal data, and obtain the associated attack clue sequence.

[0173] The path determination module is used to calculate the trust score of the node based on the attack clue sequence and compare it with a preset trust score threshold, mark the node with a lower than the preset trust score threshold as a high-risk node, adjust the edge weight distribution, and determine the core threat path.

[0174] The decision generation module is used to update the overall device communication relationship diagram based on the core threat path to obtain the optimized final protection decision basis.

[0175] This invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements all the steps of the big data-based computer network security protection method described above. This electronic device can employ an industrial-grade edge gateway or server, acquiring data through traffic acquisition components of an edge network, an IoT device identification management system, and a historical anomaly database. It supports traffic data processing frequencies above 1kHz, providing efficient computing power support for network security protection in complex IoT scenarios and ensuring real-time threat identification and protection decisions.

[0176] This invention also provides a computer-readable storage medium, which includes a stored computer program. When the computer program is executed, it controls the device containing the computer-readable storage medium to perform any of the aforementioned big data-based computer network security protection methods. This storage medium can be a high-reliability industrial-grade solid-state drive (SSD) or hard disk drive (HDD) with a storage capacity of at least 1TB. It is deployed on a local control node or security management server in an edge network, supporting localized storage and rapid retrieval of traffic data, communication relationship graph data, and protection decision schemes. This avoids data transmission delays affecting protection response efficiency and simultaneously meets the stability and security requirements of data storage in industrial scenarios.

[0177] It should be noted that the big data-based computer network security protection system provided in this embodiment of the invention is used to execute all the process steps of the big data-based computer network security protection method in the above embodiments. The two correspond one-to-one in terms of module function, working logic and technical effect, and have the same threat identification accuracy and protection adaptability. Therefore, the specific working details and beneficial effects of the system can be referred to the aforementioned method embodiments, and will not be repeated here.

[0178] For example, the computer program can be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the electronic device. For example, the computer program can be divided into traffic processing instruction segments, graph construction instruction segments, cluster analysis instruction segments, etc., corresponding to functions such as traffic simplification, graph construction, and cluster determination, respectively.

[0179] The electronic device may be an edge computing gateway, an industrial control server, a desktop computer, or other device with data processing capabilities. The electronic device may include, but is not limited to, a processor and a memory. Those skilled in the art will understand that the above components are merely examples of electronic devices and do not constitute a limitation on the electronic device. It may include more or fewer components than described above, or combine certain components, or use different components. For example, the electronic device may also include a data interface, a network module, an alarm module, etc. The data interface is used to connect the traffic acquisition component to the IoT device, the network module is used to realize data interaction between devices, and the alarm module is used to trigger audible, visual, or SMS alarms when abnormal communication patterns are detected.

[0180] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the electronic device, connecting various parts of the device through various interfaces and lines. It executes computer programs and / or modules stored in the memory, and retrieves data stored in the memory to realize the network security protection data processing and decision generation functions of the electronic device.

[0181] It should be noted that the system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the system embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0182] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A computer network security protection method based on big data, characterized in that, include: Real-time capture of traffic data between IoT devices, removal of low-frequency irrelevant interactions, and a simplified traffic dataset are obtained; For the simplified traffic dataset, analyze the communication frequency and connection density, and construct an initial device communication relationship diagram; The initial device communication relationship graph is analyzed to calculate the node centrality metric and communication path length, and to determine the key communication clusters. For the critical communication cluster, abnormal node markers are extracted. When the node centrality exceeds a preset abnormal node centrality threshold and the communication path length is lower than a preset length standard, it is determined to be an abnormal communication mode. If the abnormal communication pattern is identified, the risk path is traced from the device communication relationship diagram, and the threat propagation range and historical abnormal data are compared to obtain the associated attack clue sequence. Based on the attack clue sequence, calculate the trust score of the node and compare it with a preset trust score threshold. Nodes with a trust score lower than the preset trust score threshold are marked as high-risk nodes. Adjust the edge weight distribution and determine the core threat path. Based on the core threat path, update the overall device communication relationship diagram to obtain the optimized final protection decision basis; The step of analyzing the initial device communication graph, calculating node centrality metrics and communication path lengths, and determining key communication clusters includes: Based on the initial device communication relationship diagram, the centrality metric of each node is calculated, and the communication path length between nodes is statistically obtained. Remove nodes whose centrality metric is lower than a preset core node threshold, and retain high-frequency interaction nodes to form a candidate node set; Extract the high-frequency interactive connection structure of the nodes in the candidate node set to form a core device subgraph; Based on the communication density within the core device sub-graph, key communication clusters are divided, and the communication density within each cluster must be higher than a preset cluster density threshold. Specifically, for the critical communication cluster, abnormal node markers are extracted. When the node centrality exceeds a preset abnormal node centrality threshold and the communication path length is lower than a preset length standard, it is determined to be an abnormal communication mode, including: Historical interaction records of each node are obtained from the key communication cluster, and potential abnormal nodes whose interaction behavior deviates from the average level of the cluster are screened out. Obtain the centrality metric of the potential abnormal node. If the centrality metric of the potential abnormal node exceeds a preset abnormal node centrality threshold and the path length is lower than a preset length standard, mark the node as an abnormal node. The marking results of the abnormal nodes are summarized, and combined with the interaction and association of the abnormal nodes within the critical communication cluster, an abnormal communication pattern is determined.

2. The method according to claim 1, characterized in that, The real-time capture of traffic data between IoT devices, after removing low-frequency irrelevant interactions, yields a simplified traffic dataset, including: The raw traffic data between IoT devices is captured, and low-frequency irrelevant interaction records with interaction frequencies below a preset communication frequency threshold are removed to obtain a preliminary simplified traffic set. The preliminary simplified traffic set is segmented by time, and data segments containing periodic high-frequency interaction characteristics are retained to form a traffic subset; By comparing the device interaction patterns in the traffic subset with preset communication behavior characteristics, key communication data that successfully matches are retained, and the resulting data is integrated to obtain a simplified traffic dataset.

3. The method according to claim 1, characterized in that, The process of analyzing communication frequency and connection density in the simplified traffic dataset and constructing an initial device communication relationship graph includes: From the simplified traffic dataset, device identifiers, number of interactions, and duration are extracted to calculate the communication frequency and connection density between devices. Remove device-associated records whose connection density is lower than a preset connection density threshold to obtain filtered communication data; Based on the filtered communication data, an initial device communication relationship graph is constructed, with devices as nodes and the communication frequency as the weight of the edges between nodes.

4. The method according to claim 1, characterized in that, If the abnormal communication pattern is identified, the risk path is traced from the device communication relationship graph, and the threat propagation range is compared with historical abnormal data to obtain the associated attack clue sequence, including: Starting from the abnormal node in the abnormal communication mode, traverse the device communication relationship graph, trace all communication links of the abnormal node, and determine potential risk paths; The number of nodes covered by each potential risk path is counted, the threat propagation range of the potential risk path is defined, and paths whose threat propagation range is lower than a preset propagation range threshold are eliminated. Extract the communication characteristics of the remaining potential risk paths and compare them with the attack path characteristics in historical anomaly data; Paths with a matching degree higher than a preset matching degree threshold are selected, and the communication records of the paths are extracted and sorted by time to form an attack clue sequence.

5. The method according to claim 1, characterized in that, The step of calculating the trust score of a node based on the attack clue sequence and comparing it with a preset trust score threshold, marking nodes with a trust score below the preset trust score threshold as high-risk nodes, adjusting the edge weight distribution, and determining the core threat path includes: The interaction frequency, data integrity, and historical security records of each node are extracted from the attack clue sequence, and a weighted trust score is calculated for each node. The trust score is compared with a preset trust score threshold, and nodes that are lower than the preset trust score threshold are marked as high-risk nodes. Based on the degree of association between the high-risk node and other nodes, the weights of the corresponding edges in the device communication relationship graph are adjusted to optimize the edge weight distribution; The paths in the adjusted device communication relationship graph are sorted by weight, and the path with the highest weight is selected as the core threat path.

6. The method according to claim 1, characterized in that, The step of updating the overall device communication relationship diagram based on the core threat path to obtain the optimized final protection decision basis includes: Based on the weight of the core threat path, adjust the weight of each edge in the overall device communication relationship diagram to strengthen the high-risk identification of the core threat path; The topology of the device communication relationship graph is reconstructed, and isolated nodes and low-association connections are deleted to obtain the updated device communication relationship graph. Input real-time device interaction data into the updated device communication relationship diagram to verify the anomaly identification accuracy and response latency of the updated device communication relationship diagram; If the anomaly identification accuracy is higher than a preset validity threshold and the response delay is lower than a preset delay threshold, the final protection decision basis is generated based on the updated device communication relationship diagram.

7. A computer network security protection system based on big data, used to implement the method as described in any one of claims 1-6, characterized in that, include: The traffic simplification module is used to capture traffic data between IoT devices in real time, remove low-frequency irrelevant interactions, and obtain a simplified traffic dataset. The relationship building module is used to analyze the communication frequency and connection density of the simplified traffic dataset and build an initial device communication relationship graph. The cluster determination module is used to analyze the initial device communication relationship graph, calculate the node centrality metric and communication path length, and determine the key communication clusters; The anomaly detection module is used to extract abnormal node markers from the critical communication cluster. When the node centrality exceeds a preset abnormal node centrality threshold and the communication path length is lower than a preset length standard, it is determined to be an abnormal communication mode. The clue acquisition module is used to trace the risk path from the device communication relationship graph if the abnormal communication pattern is identified, compare the threat propagation range with historical abnormal data, and obtain the associated attack clue sequence. The path determination module is used to calculate the trust score of the node based on the attack clue sequence and compare it with a preset trust score threshold, mark the node with a lower than the preset trust score threshold as a high-risk node, adjust the edge weight distribution, and determine the core threat path. The decision generation module is used to update the overall device communication relationship diagram based on the core threat path to obtain the optimized final protection decision basis.

Images