Industrial internet attack propagation simulation deduction method, system, medium and product

Abstract

The invention discloses an industrial internet attack propagation simulation deduction method and system, a medium and a product, and relates to the technical field of data processing. According to the method, industrial equipment data are collected and synchronized to a preset digital twinborn model, and a behavior model library and an equipment connection map of an instruction sequence are constructed. And injecting attack traffic into the digital twin model, and training an attack detector in combination with the behavior model library and the equipment connection atlas to judge an attack event. And an attack event is positioned to a starting node of the equipment connection map, a propagation path is determined through iterative deduction, and an attack propagation thermodynamic diagram is generated. High-risk target nodes in the thermodynamic diagram are analyzed, data distortion influence chains and physical out-of-control influence chains of the high-risk target nodes are traced, and finally an attack propagation simulation deduction report is generated. By implementing the technical scheme provided by the invention, the accuracy of industrial internet attack propagation simulation deduction can be improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a method, system, medium, and product for simulating and deducing the propagation of industrial internet attacks. Background Technology

[0002] With the development of the industrial era, Industrial Internet technology has been widely applied in manufacturing, energy, transportation, and other fields. By interconnecting industrial equipment, control systems, and management systems, the Industrial Internet has enabled the intelligentization and automation of production processes. However, as the degree of networking of industrial equipment increases, the cybersecurity threats faced by industrial systems are also becoming increasingly severe. Frequent cyberattacks on industrial control systems are causing escalating economic losses and seriously threatening the safe and stable operation of industrial production.

[0003] Currently, security protection for the Industrial Internet primarily employs traditional cybersecurity technologies such as abnormal traffic detection and vulnerability scanning. These technologies typically rely on known attack characteristics for detection and defense.

[0004] However, in practical applications, due to the complex dependencies between devices within industrial systems, when an attack occurs, relying solely on existing known attack characteristics for detection and defense often fails to accurately grasp the spread trend of the attack, neglecting the cascading effects on various parts of the system. This reduces the accuracy of industrial internet attack propagation simulation and leads to poor emergency response to security incidents. Summary of the Invention

[0005] This application provides a method, system, medium, and product for simulating and extrapolating the propagation of industrial internet attacks, which can improve the accuracy of industrial internet attack propagation simulation and extrapolation.

[0006] The first aspect of this application provides a simulation and deduction method for industrial internet attack propagation, including: Acquire equipment data of industrial equipment, and based on the mapping relationship between the acquired data and virtual entities in a preset digital twin model, synchronize the acquired data to the preset digital twin model. The equipment data includes physical parameters, operating status, and network traffic characteristics. Collect the instruction sequence of the preset digital twin model during operation, and construct a behavior model library corresponding to the instruction sequence; By using the interaction data between virtual entities in the preset digital twin model, dependent links, data transmission paths, and physical control links are identified, and a device connection map is constructed. Attack traffic is injected into the digital twin model to generate simulation data, and the attack detector is trained by combining the behavior model library and the device connectivity graph. Attack events are determined based on the detection results of the attack detector. The determined attack event is located at the starting node of the device connection graph. Multiple propagation paths are determined by iterative deduction of the starting node, and an attack propagation heatmap is generated based on each propagation path. Target nodes in the attack propagation heatmap with a probability of being compromised greater than a preset probability threshold are selected. The data distortion impact chain of the target node is traced upward along the dependency link, and the physical loss of control impact chain of the target node is traced downward along the physical control link. Based on the target node, the data distortion impact chain, and the physical loss of control impact chain, an attack propagation simulation report of the industrial equipment is generated.

[0007] By adopting the above technical solutions, and synchronizing equipment data such as physical parameters, operating status, and network traffic characteristics of industrial equipment to a preset digital twin model, and constructing an equipment connection graph based on the interaction data between virtual entities, the complex relationships such as dependency links, data transmission paths, and physical control links between equipment within the industrial system can be comprehensively reflected. Simultaneously, by injecting attack traffic into the digital twin model to generate simulation data, and training an attack detector using a behavioral model library corresponding to the instruction sequence and the equipment connection graph, attack events can be detected promptly, and the starting node of the attack can be accurately located. Furthermore, by iteratively extrapolating the starting node to determine multiple propagation paths and generating an attack propagation heatmap, the spread trend of the attack in the industrial system can be intuitively displayed. By screening target nodes with a high probability of being compromised, and combining the tracing analysis of their data distortion impact chain and physical loss of control impact chain, the cascading impact of the attack event on the industrial system can be comprehensively assessed, thereby effectively improving the accuracy of industrial internet attack propagation simulation extrapolation.

[0008] Optionally, the programmable logic controller (PLC), servo motor, and industrial control protocol state machine associated with the industrial equipment are determined; the register values ​​of the PLC and the speed and torque of the servo motor are collected as the physical parameters, and the working mode and process occupancy rate of the industrial control protocol state machine are collected as the running state; the message headers and industrial control protocol instructions of the industrial equipment are received as the network traffic characteristics; a virtual entity containing attribute fields is created for the industrial equipment in the preset digital twin model, and the correspondence between the physical parameters, the running state, the network traffic characteristics, and the attribute fields of the virtual entity is established as the mapping relationship; the equipment data is synchronized to the attribute fields of the virtual entity through the mapping relationship, and the preset digital twin model is driven to run.

[0009] Optionally, communication messages and instruction call records between virtual entities in the preset digital twin model are extracted from the interaction data; based on the communication messages and instruction call records, data read requests and control instructions sent by the host computer virtual entity to the lower-level controller virtual entity are identified, and the communication links corresponding to the data read requests and the control instructions are taken as the dependency links; the data flow direction between the virtual entities is collected as the data transmission path; by analyzing the timestamps of attribute changes of the virtual entities through time series analysis, the actuator-sensor pairing relationship is identified where the time when the actuator virtual entity issues its action command precedes the time when the sensor virtual entity changes its reading, and the link corresponding to the actuator-sensor pairing relationship is taken as the physical control link; the device connection graph is constructed based on the dependency links, the data transmission path, and the physical control link, where the graph nodes in the device connection graph correspond to industrial equipment, and the graph edges correspond to the connection relationships between virtual entities.

[0010] Optionally, the preset digital twin model is driven to simulate and generate benchmark data. At preset time points, industrial control protocol vulnerability attack traffic, command attack traffic, and lateral movement attack traffic are injected into the virtual entity of the preset digital twin model. The running data after the injection of attack traffic is collected as simulation data. The benchmark data and the simulation data are used to train an attack detector including multiple detection modules, obtaining the anomaly confidence score output by each detection module. The detection modules include a traffic feature detection module, a behavior deviation detection module, and a communication anomaly detection module. The historical recall and hit rates of each detection module are obtained, and the detection weights corresponding to each detection module are determined based on these historical recall and hit rates. The anomaly confidence scores of each detection module are weighted and calculated based on the detection weights to obtain a target confidence score. When the target confidence score exceeds a preset threshold, an attack event is determined to exist.

[0011] Optionally, the starting node is located in the device connection graph based on the source address of the attack event, and adjacent nodes connected to the starting node are extracted along the data transmission path; for each adjacent node, the communication frequency and data sensitivity of the connection edge markings of the adjacent node are extracted, the vulnerability information and business importance of the adjacent node are extracted, and the communication frequency, data sensitivity, vulnerability information and business importance are weighted and fused to determine the probability of being compromised; adjacent nodes with a probability of being compromised less than a baseline probability threshold are removed, and the remaining adjacent nodes are marked as compromised nodes, generating multiple propagation paths from the starting node to each compromised node; the attack propagation heatmap is generated based on the probability of being compromised of each adjacent node in each propagation path.

[0012] Optionally, the source IP address, source port, and source device identifier associated with the attack event are extracted as the source address; each graph node in the device connection graph is traversed, and the IP address, port information, and device identifier marked on each graph node are matched with the source address; the graph node with a matching degree greater than a preset matching degree threshold is determined as the starting node; when there are multiple graph nodes with a matching degree greater than the preset matching degree threshold, the time difference between the timestamp of the attack event and the most recent activity time corresponding to each graph node is calculated, and the graph node with the smallest time difference is selected as the starting node.

[0013] Optionally, based on the dependency links, recursively trace upstream devices from the target node to identify upstream device nodes that receive data from the target node, and connects the upstream device nodes to form the data distortion impact chain; based on the physical control link, recursively trace downstream devices from the target node to identify downstream device nodes controlled by the target node, and connects the downstream device nodes to form the physical out-of-control impact chain; simulate and verify the injection of abnormal data and erroneous instructions into the target node using the preset digital twin model, record the service interruption duration of each device in the data distortion impact chain and the parameter offset of each device in the physical out-of-control impact chain; perform structured processing on the data distortion impact chain, the physical out-of-control impact chain, the service interruption duration, and the parameter offset to generate an attack propagation simulation and deduction report in a preset format.

[0014] Secondly, embodiments of this application provide an industrial internet attack propagation simulation system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, which includes computer instructions, and the one or more processors call the computer instructions to cause the industrial internet attack propagation simulation system to perform the method described in the first aspect and any possible implementation thereof.

[0015] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an industrial internet attack propagation simulation and deduction system, cause the industrial internet attack propagation simulation and deduction system to perform the method described in the first aspect and any possible implementation thereof.

[0016] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on an industrial internet attack propagation simulation and deduction system, cause the industrial internet attack propagation simulation and deduction system to execute the method described in the first aspect and any possible implementation thereof.

[0017] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: By adopting the above technical solutions, and synchronizing equipment data such as physical parameters, operating status, and network traffic characteristics of industrial equipment to a preset digital twin model, and constructing an equipment connection graph based on the interaction data between virtual entities, the complex relationships such as dependency links, data transmission paths, and physical control links between equipment within the industrial system can be comprehensively reflected. Simultaneously, by injecting attack traffic into the digital twin model to generate simulation data, and training an attack detector using a behavioral model library corresponding to the instruction sequence and the equipment connection graph, attack events can be detected promptly, and the starting node of the attack can be accurately located. Furthermore, by iteratively extrapolating the starting node to determine multiple propagation paths and generating an attack propagation heatmap, the spread trend of the attack in the industrial system can be intuitively displayed. By screening target nodes with a high probability of being compromised, and combining the tracing analysis of their data distortion impact chain and physical loss of control impact chain, the cascading impact of the attack event on the industrial system can be comprehensively assessed, thereby effectively improving the accuracy of industrial internet attack propagation simulation extrapolation. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating an industrial internet attack propagation simulation method disclosed in an embodiment of this application; Figure 2 This is another flowchart illustrating an industrial internet attack propagation simulation method disclosed in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a system provided in an embodiment of this application.

[0019] Explanation of reference numerals in the attached drawings: 301, Central Processing Unit; 302, Read-Only Memory; 303, Random Access Memory; 304, Bus; 305, Input / Output Interface; 306, Input Section; 307, Output Section; 308, Storage Section; 309, Communication Section; 310, Driver; 311, Removable Media. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0021] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0022] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0023] This application provides a simulation and deduction method for industrial internet attack propagation, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an industrial internet attack propagation simulation method provided in an embodiment of this application. The method is applied to a system, which refers to a hardware and software integrated platform capable of executing an industrial internet attack propagation simulation program. The system can execute an industrial internet attack propagation simulation program, and the method includes steps 101 to 106, as follows: Step 101: Acquire equipment data of industrial equipment, and based on the mapping relationship between the collected data and the virtual entities in the preset digital twin model, synchronize the collected data to the preset digital twin model. The equipment data includes physical parameters, operating status and network traffic characteristics.

[0024] Industrial equipment refers to machinery and equipment used in industrial production processes, such as robots, conveyor belts, and processing equipment on production lines. Equipment data is categorized into three types: physical parameters, which refer to the physical quantities of the equipment during operation, including measurable data such as temperature, pressure, and rotational speed; operating status, which refers to the current working condition of the equipment, including on / off status, fault status, and task execution progress; and network traffic characteristics, which refer to the data characteristics generated by the equipment during network communication, including packet size, transmission frequency, and protocol type. A digital twin model is a virtual mapping of a physical entity. The virtual device, constructed through software, possesses the same attributes and behavioral characteristics as the physical device. A virtual entity is a software object representing a physical device in the digital twin model, possessing corresponding data structures and functional modules. The mapping relationship defines the correspondence rules between physical device data and virtual entity attributes.

[0025] Specifically, real-time data from industrial equipment is first collected via a sensor network. Sensors include temperature sensors, pressure sensors, and speed sensors. The collection frequency is set according to actual needs, with temperature data collected once per second and equipment status updated once per minute. The collected data is transmitted to a data processing server via the industrial network. The server categorizes the data according to a pre-established mapping rule table, which clearly defines the correspondence between each data item of the physical equipment and the attributes of the virtual entity. For example, temperature sensor data maps to the temperature value attribute of the virtual entity, equipment on / off status maps to the operating status attribute, and network communication data packet size maps to the data packet size attribute. The data processing server executes a data synchronization program, writing the categorized data into the corresponding attribute fields of the virtual entities, completing the data synchronization. The synchronization process uses real-time database technology, ensuring that changes in physical equipment data are reflected in the digital twin model within 100 milliseconds. After data synchronization is complete, the virtual entity state in the digital twin model is consistent with the physical equipment, achieving data mapping from the physical world to the virtual space.

[0026] In one possible implementation, equipment data of industrial equipment is acquired, and based on the mapping relationship between the acquired data and virtual entities in a preset digital twin model, the acquired data is synchronized to the preset digital twin model. Specifically, this includes steps 1011-1013, as follows: Step 1011: Determine the programmable logic controller, servo motor, and industrial control protocol state machine associated with the industrial equipment; collect the register values ​​of the programmable logic controller and the speed and torque of the servo motor as physical parameters, and collect the working mode and process occupancy rate of the industrial control protocol state machine as the running status.

[0027] A programmable logic controller (PLC) is a digital electronic device in an industrial automation control system that stores data and control instructions through internal registers. Register values ​​include the values ​​in the data registers and flag bits in the status registers. A servo motor is an actuator that automatically adjusts its speed and position based on input signals; its speed and torque are key operating parameters. An industrial control protocol state machine is a program module in an industrial control network that handles communication protocols. It has multiple operating modes (such as idle, communication, and data processing modes), and the process utilization rate indicates the proportion of system resources used by the state machine program.

[0028] Specifically, by scanning the industrial network, a communication address table for the devices is obtained. Based on the device type identifier in the address table, the IP address and port number of the programmable logic controller (PLC) are filtered out. The device number and communication parameters of the servo motor are read through the fieldbus interface. Network communication data packets are analyzed to extract the industrial control protocol type and the corresponding state machine identifier. For the identified PLC, its internal registers are read using the Modbus protocol, including the values ​​of data registers D0-D100 and the flag bits of status registers M0-M50. For the servo motor, real-time speed data is collected through a feedback encoder, and the current torque value is collected through a torque sensor, with the collection frequency set to 10 milliseconds / time. For the industrial control protocol state machine, its operation log is read to obtain the current working mode identifier, and the state machine process number is obtained through the operating system interface. The ratio of the CPU time occupied by this process to the total CPU time is calculated as the process utilization rate. All collected data is marked with a unified timestamp to form structured data records for subsequent digital twin model synchronization.

[0029] Step 1012: Receive the message header and industrial control protocol instructions from the industrial equipment as network traffic characteristics; create a virtual entity containing attribute fields for the industrial equipment in the preset digital twin model, and establish a mapping relationship between physical parameters, operating status and network traffic characteristics and the attribute fields of the virtual entity.

[0030] The message header is the control information portion of a network communication data packet, containing fields such as source address, destination address, and protocol type. Industrial control protocol commands are standardized commands used for device communication in industrial control systems, such as operation commands for reading data and writing control variables. Network traffic characteristics describe the data characteristics of communication between devices, including communication frequency, data volume, and protocol type. Attribute fields are variables used to store data in virtual entities, with each field corresponding to a type of data. Mapping relationships define the correspondence rules between physical device data items and virtual entity attribute fields, ensuring the accuracy of data synchronization.

[0031] Specifically, a data capture module is first deployed at the network interface to collect communication data from industrial equipment in real time. For each data packet, its header information is extracted, including: source MAC address (6 bytes), destination MAC address (6 bytes), source IP address (4 bytes), destination IP address (4 bytes), protocol type identifier (2 bytes), and port number (2 bytes). The payload portion of the data packet is parsed to extract industrial control protocol instructions, recording fields such as instruction type code (e.g., 01 in Modbus protocol indicates reading the coil, 03 indicates reading the holding register), function code, data address, and data length. Virtual entity objects are created in the digital twin model, with attribute fields including: basic information fields (equipment identifier, equipment type, installation location), physical parameter fields (temperature value, pressure value, speed value, torque value, etc.), operating status fields (working mode identifier, process utilization rate, equipment status code), and communication characteristic fields (packet header information, protocol instruction sequence, communication statistics). A mapping table is established to map the temperature sensor data of the physical equipment to the temperature value field of the virtual entity, the equipment status code to the working mode field, and the communication packets to the communication characteristic fields. The mapping table is stored in key-value pair format, where the key is the physical data item identifier and the value is the virtual entity attribute field name, which facilitates the data synchronization program to quickly find the corresponding relationship.

[0032] Step 1013: Synchronize device data to the attribute fields of the virtual entity through mapping relationships, and drive the preset digital twin model to run.

[0033] The attribute fields of a virtual entity are a set of variables used in a digital twin model to store data about the corresponding device.

[0034] Specifically, the implementation process is divided into two stages: data synchronization and model execution. Data Synchronization Stage: First, the data synchronization program is started, which updates data every 10 milliseconds. Within each cycle, the program reads the latest data from the device's data buffer, including measurements from physical sensors, flags in the device status register, and messages collected from the network communication interface. The program queries the mapping table to obtain the virtual entity attribute field name corresponding to each data item, such as mapping temperature sensor data to the `temperature` field, device status codes to the `workMode` field, and communication messages to the `commData` field. The program calls the virtual entity's attribute update method to write the data to the corresponding attribute fields. For items requiring data type conversion, the corresponding conversion functions are executed, such as converting analog quantities to digital quantities and byte streams to structured data. Model Execution Stage: The digital twin model's execution engine is started, driving the model execution according to a preset time step (e.g., 100 milliseconds). Within each time step, the virtual entity calculates the next state based on the current attribute value, executing preset physical rules (e.g., heat conduction models, mechanical motion equations) and control logic (e.g., PID control algorithms, state machine transition rules). During model operation, the system continuously receives attribute values ​​updated by the data synchronization program to maintain synchronization between the virtual entity's state and the physical device. Simultaneously, it records the state changes of the virtual entity, creating an operational log for subsequent analysis and verification.

[0035] Step 102: Collect the instruction sequence of the preset digital twin model during operation and build a behavior model library corresponding to the instruction sequence.

[0036] An instruction sequence is an ordered set of operational commands executed by virtual entities in a digital twin model, including control commands (start, stop, adjust, etc.), data operation commands (read, write, calculate, etc.), and communication commands (send, receive, etc.). The behavioral model library is a database of typical operating modes of a storage device. Each behavioral model contains the execution order, timing relationships, and constraints of the instruction sequence. The timing characteristics of the instruction sequence include time attributes such as instruction interval time, execution duration, and triggering conditions. Behavioral characteristics include static attributes such as instruction type distribution, operation objects, and parameter ranges.

[0037] Specifically, firstly, an instruction capture module is embedded in the runtime engine of the digital twin model. This module records detailed information about each instruction executed by the virtual entity. For each instruction, the following data items are recorded: instruction timestamp (accurate to milliseconds), instruction type identifier (e.g., READ for read instruction, WRITE for write instruction), instruction source address, target address, operation parameters, and return value. The continuously captured instructions are sorted by timestamp to form an instruction sequence. The instruction sequence is then segmented, using significant state change points (e.g., device startup, mode switching) as boundaries to divide the complete sequence into multiple subsequences. The characteristics of each subsequence are analyzed, extracting the frequency distribution of instruction types, statistical values ​​of time intervals between instructions, parameter value ranges, and the relationships between operation objects. Based on the extracted features, a data structure for the behavioral model is constructed, including: sequence identifier, start condition, end condition, instruction list, timing constraints, and parameter constraints. The constructed behavioral models are stored in a behavioral model library, and an index structure is established to support retrieval by device type, operation type, time characteristics, and other conditions. Each behavioral model is labeled with its applicable scenarios and confidence level, with the confidence level calculated based on the number of times the behavioral pattern recurs in historical data. The behavior model library supports incremental updates. As the digital twin model continues to run, new instruction sequence patterns are discovered and added to the model library.

[0038] Step 103: Identify dependent links, data transmission paths, and physical control links through the interaction data between virtual entities in the preset digital twin model, and construct a device connection map.

[0039] Interactive data refers to the information exchanged between virtual entities, including communication content such as control commands, status feedback, and data transmission. Dependency links represent the functional dependencies between devices, such as the control dependency of a host computer on a slave computer. Data transmission paths describe the direction of data flow and transmission channels between devices. Physical control links reflect the interaction between actuators and controlled objects, embodying the causal relationships within the physical system. A device connection graph is a network structure describing the relationships between devices, where nodes represent devices and edges represent the connections between them.

[0040] Specifically, the process begins by collecting interaction data from virtual entities in the digital twin model. The record format includes: source entity identifier, target entity identifier, interaction time, data content, and interaction type. For each interaction record, its communication protocol type and data format are analyzed. The process of identifying dependent links involves analyzing the flow of control commands in the interaction data. When entity A sends a control command to entity B and B executes the command, a dependent link from A to B is established. Command frequency is statistically analyzed; when the command sending frequency exceeds 10 times per second, the dependent link is marked as a strong dependency. The process of identifying data transmission paths involves tracing the transmission process of data packets between entities and recording the forwarding sequence of data packets. Transmission frequency and data volume are statistically analyzed, and the bandwidth utilization of the path is calculated. Paths with bandwidth utilization exceeding 50% are marked as primary transmission paths. The process of identifying physical control links involves analyzing the temporal relationship between actuator actions and sensor data changes. When the action of actuator A causes a change in the reading of sensor B within 100 milliseconds, a physical control link from A to B is established. The correlation coefficient between the action amplitude and the sensor change is calculated; a correlation coefficient greater than 0.8 confirms the physical control relationship. The process of constructing a device connectivity graph involves: creating a graph data structure with node attributes including device type, function description, and location information; edge attributes including connection type (dependency / transmission / control), connection strength, and transmission latency; and using an adjacency matrix to store the graph structure, which supports fast querying of connectivity relationships between devices.

[0041] In one possible implementation, by using the interaction data between virtual entities in a pre-set digital twin model, dependent links, data transmission paths, and physical control links are identified, and a device connection map is constructed. Specifically, this includes steps 1031-1033, as follows: Step 1031: Extract communication messages and instruction call records between virtual entities in the preset digital twin model from the interaction data; based on the communication messages and instruction call records, identify the data read requests and control commands sent by the host computer virtual entity to the lower controller virtual entity, and use the communication links corresponding to the data read requests and the communication links corresponding to the control commands as dependency links.

[0042] Communication messages are data packets transmitted between devices, containing a header (address, timestamp, etc.) and a body (the actual data content). Instruction call logs are logs of device instruction execution, recording the sender, receiver, execution time, and result. Upper-level virtual entities correspond to management-level devices in industrial control systems, such as industrial PCs and dispatch stations. Lower-level virtual entities correspond to execution-level devices, such as PLCs and RTUs. Data read requests are instructions from the upper-level computer to retrieve data from the lower-level computer. Control instructions are control commands issued by the upper-level computer to the lower-level computer. Dependency links represent the control dependencies between the upper-level computer and the lower-level computer.

[0043] Specifically, the implementation process is divided into two stages: data extraction and dependency identification. Data extraction stage: Interaction data between virtual entities is obtained from the communication interface of the digital twin model, and the message format of each data packet is parsed. Message parsing extracts the following fields: message header (source address, destination address, timestamp, message length), message type identifier (e.g., 0x01 indicates a read request, 0x05 indicates a write command), and message content (data address, data length, specific value). Simultaneously, instruction call records are extracted from the virtual entity's runtime log. The record format includes: call time, instruction type, sender identifier, receiver identifier, execution status, and return result. Dependency identification stage: First, based on the virtual entity's type identifier, entities are classified into host and slave groups. Message flow is analyzed; when communication from the host group to the slave group is detected, the message type is parsed. For data read messages (type identifiers such as 0x01, 0x03, etc.), record the communication link as a data dependency; for control command messages (type identifiers such as 0x05, 0x0F, etc.), record the communication link as a control dependency. Count the message frequency for each communication link; links with a message frequency exceeding 5 times per second are marked as high-frequency dependencies. Verify the validity of the dependency relationship based on the command call record. When the lower-level machine executes the corresponding command and returns a success status, the dependency link is confirmed to be valid. Store the identified dependency links in a dependency table. Each record includes: source node identifier, target node identifier, dependency type (data / control), dependency strength (message frequency), and establishment time.

[0044] Step 1032: Collect the data flow direction between virtual entities as the data transmission path; by analyzing the timestamps of the attribute changes of virtual entities through time series analysis, identify the actuator-sensor pairing relationship where the time when the actuator virtual entity issues the action command precedes the time when the sensor virtual entity changes the reading, and take the link corresponding to the actuator-sensor pairing relationship as the physical control link.

[0045] Data flow refers to the direction and route of data transmission between virtual entities, including the data source, transmission nodes, and destination nodes. Data transmission path is a specific channel description of the data flow. Actuator virtual entities correspond to actual actuators, such as motors, valves, and other devices capable of performing actions. Sensor virtual entities correspond to actual sensing devices used to measure physical quantities. A timestamp is a time stamp recording the moment data is generated or changed, accurate to the millisecond level. The actuator-sensor pairing relationship indicates the impact of actuator actions on sensor readings. The physical control link reflects the actuator's control effect on the physical system.

[0046] Specifically, the process of data packet transmission between virtual entities is recorded. For each data packet, the following information is recorded: data packet identifier, source entity identifier, current entity identifier, target entity identifier, entry time, exit time, and data size. Based on the transmission order of data packets between entities, a data flow graph is constructed, where nodes represent virtual entities and edges represent data transmission directions. The data volume and transmission frequency for each transmission path are statistically analyzed, with data volume in bytes and transmission frequency in times per second. Then, a time-series database is established to record the action commands of actuator virtual entities and the changes in sensor virtual entity readings. The actuator action record format includes: actuator identifier, action type, action parameters, and execution timestamp. The sensor reading record format includes: sensor identifier, measured value, and measurement timestamp. The time-series data is analyzed, with a time window of 1 second. Within each time window, the change in sensor readings after the actuator action is detected. When the action timestamp T1 of actuator A is detected to be earlier than the reading change timestamp T2 of sensor B, and the time difference T2-T1 is less than 500 milliseconds, an actuator-sensor pairing relationship is recorded. For each pairing, a correlation index is calculated: 10 time windows are set, and the correlation coefficient between the actuator's action amplitude and the change in sensor readings is statistically analyzed. Pairings with a correlation coefficient greater than 0.7 are confirmed as valid physical control links. The identified physical control links are stored in the link database, and the records include: actuator identifier, sensor identifier, response time, correlation coefficient, and control type.

[0047] Step 1033: Construct a device connection graph based on dependency links, data transmission paths, and physical control links. Graph nodes in the device connection graph correspond to industrial equipment, and graph edges correspond to the connection relationships between virtual entities.

[0048] Specifically, first, a graph data structure is created, using an adjacency matrix to store the graph's topological relationships. A node table is created, with each node recording the following attributes: node identifier, device type (e.g., PLC, sensor, actuator), device function description, physical location coordinates, and operating status flag. An edge table is created, with each edge recording the following attributes: edge identifier, starting node, ending node, connection type (dependency / transmission / control), and connection weight. Dependency link data is imported, converting dependencies into graph edges. Edge weights are set based on dependency strength (message frequency): 0.2 for 1 message per second, 0.5 for 5 messages per second, and 1.0 for 10 messages per second. Data transmission paths are imported, converting data flow into directed edges in the graph. Edge weights are set based on the amount of data transmitted: 0.3 for 1 MB / s, 0.6 for 5 MB / s, and 1.0 for 10 MB / s. Import the physical control links, converting actuator-sensor pairings into graph edges. Edge weights are set based on correlation coefficients: 0.7 = 0.7, 0.8 = 0.8, and 0.9 = 0.9. Duplicate connections are merged, retaining only the highest weight value. An index structure for the graph is built, supporting fast queries by device type, connection type, and weight range. Topological features of the graph are calculated, including node degree distribution, connectivity, and clustering coefficients, to evaluate network structure characteristics. A hierarchical view of the graph is established, grouping devices by control level (management layer, control layer, execution layer) to visually demonstrate the hierarchical relationships between devices.

[0049] Step 104: Inject attack traffic into the digital twin model to generate simulation data, and train the attack detector by combining the behavior model library and device connectivity graph. Determine the attack event based on the detection results of the attack detector.

[0050] Attack traffic refers to data packets simulating network attack behavior, including types such as industrial control protocol vulnerability attacks, instruction tampering attacks, and lateral movement attacks. Simulation data is system operation data generated by a digital twin model after injecting attack traffic. The behavior model library stores instruction sequence patterns during normal device operation. The device connectivity graph describes the topological relationships and interaction patterns between devices. The attack detector is a multi-module anomaly detection system used to identify potential attack behaviors. An attack event refers to a specific instance of a detected attack behavior.

[0051] Specifically, the attack traffic injection module is first constructed to generate three types of attack traffic: industrial control protocol vulnerability attack traffic, instruction tampering attack traffic (tampering with control instruction parameters and inserting abnormal instructions), and lateral movement attack traffic (forging device identity and establishing illegal connections). Attack injection points are set in the digital twin model, and attack traffic is injected according to a predefined time series. System operation data before and after the injection attack is collected, with the recording format including: timestamp, device status, communication data, and physical parameters. A multi-module attack detector is constructed, containing three detection modules: a traffic feature detection module (analyzing the protocol characteristics and traffic statistical characteristics of communication packets), a behavior deviation detection module (comparing the current instruction sequence with normal patterns in the behavior model library), and a communication anomaly detection module (monitoring abnormal connections and data flows in the device connection graph). The specific process for training the detection modules is as follows: normal operation data is collected as a baseline dataset, and data after the injection attack is collected as an anomaly dataset. For each detection module, a normal behavior baseline is established using the baseline dataset, and an anomaly detection model is trained using the anomaly dataset. Traffic feature detection uses a statistical threshold method to calculate the mean and standard deviation of packet features, setting 3 times the standard deviation as the anomaly threshold. Behavioral deviation detection employs a sequence matching algorithm to calculate the similarity between the current instruction sequence and the normal pattern; similarities below 0.8 are marked as abnormal. Communication anomaly detection is based on graph structure analysis, detecting newly added abnormal connections and abnormal traffic paths. Each detection module outputs anomaly confidence (a value between 0 and 1), and module weights are determined based on historical detection accuracy. The weighted confidence scores of the three modules are summed to obtain the final anomaly score; a score exceeding 0.8 is considered an attack event. Detailed information about the attack event is recorded: occurrence time, attack type, affected devices, and anomaly characteristics.

[0052] In one possible implementation, attack traffic is injected into the digital twin model to generate simulation data, and an attack detector is trained by combining a behavioral model library and a device connectivity graph. The attack event is determined based on the detection results of the attack detector, specifically including steps 1041-1043, as follows: Step 1041: Drive the preset digital twin model to simulate and generate benchmark data, and inject industrial control protocol vulnerability attack traffic, command attack traffic and lateral movement attack traffic into the virtual entity of the preset digital twin model at preset time nodes, and collect the running data after injecting attack traffic as simulation data.

[0053] Baseline data consists of system operation data generated by a digital twin model under normal operating conditions, reflecting the system's standard behavioral characteristics. Industrial control protocol vulnerability attack traffic refers to attack packets targeting security vulnerabilities in industrial control protocols (such as Modbus and S7). Command attack traffic consists of attack packets that tamper with or forge control commands. Lateral movement attack traffic consists of attack packets used by attackers to penetrate the network laterally. Simulation data is the system's operational data after the injection of attack traffic, reflecting the abnormal state of the system under the influence of the attack.

[0054] Specifically, the digital twin model is first run for 24 hours to collect baseline data under normal operating conditions. The baseline data includes: device operating parameters (CPU utilization, memory usage, number of processes), communication data (number of messages, traffic volume, protocol type), and physical quantity data (temperature, pressure, rotational speed). The data sampling frequency is set to 100ms / time to form the baseline dataset. An attack traffic generator was constructed to generate three types of attack traffic: Industrial Control System (ICS) protocol vulnerability attack traffic was generated by modifying Modbus protocol function codes (changing the read function code 0x03 to the illegal value 0xFF), constructing malformed packets (setting incorrect data length fields), and inserting replay packets (copying and repeatedly sending historical packets); command attack traffic was generated by tampering with control command parameters (changing the temperature setpoint from 25°C to 85°C), inserting abnormal commands (inserting stop commands into normal command sequences), and forging control commands (generating fake start commands); lateral movement attack traffic was generated by forging device identities (copying the MAC address and IP address of legitimate devices), establishing illegal connections (establishing communication connections with unauthorized devices), and forwarding sensitive data (forwarding data to abnormal target addresses). Ten attack injection time points were set in the digital twin model, with a time interval of 30 minutes. At each injection time point, different types of attack traffic were injected into the selected virtual entity, with each type of attack lasting 5 minutes. System operation data during the injection attacks was collected as simulation data, with the collected content being the same as the baseline data, and the sampling frequency maintained at 100ms / time. The baseline data and simulation data are saved as time series databases, with each record containing a timestamp and the corresponding data item.

[0055] Step 1042: Train an attack detector that includes multiple detection modules using benchmark data and simulation data, and obtain the anomaly confidence scores of each detection module. The detection modules include a traffic feature detection module, a behavior deviation detection module, and a communication anomaly detection module.

[0056] The detection module is a functional unit within the attack detector, with each module responsible for detecting anomalies in a specific dimension. The traffic feature detection module analyzes the statistical and protocol characteristics of communication data. The behavior deviation detection module compares the current behavior with normal behavior patterns. The communication anomaly detection module monitors abnormal changes in communication patterns between devices. The anomaly confidence score is a quantified value of the degree of anomaly output by the detection module, ranging from 0 to 1; a higher value indicates a higher probability of an anomaly.

[0057] Specifically, the baseline and simulation data are first preprocessed, including data cleaning (removing noise and outliers), feature extraction (calculating statistical features), and data labeling (marking normal and abnormal samples). The training process for the traffic feature detection module involves extracting feature vectors from the communication data, including message rate (messages per second), byte rate (bytes per second), protocol type distribution (the proportion of each protocol), and message length distribution (mean and variance of message size). A statistical model of normal traffic is established using the baseline data, and the mean μ and standard deviation σ of each feature are calculated. An anomaly detection threshold is set to μ ± 3σ; when a feature value exceeds this range, the degree of anomaly is calculated. The anomaly confidence score is calculated as: confidence score = |feature value - μ| / σ, and the result is normalized to the 0-1 range. The training process for the behavior deviation detection module involves extracting normal instruction sequence patterns from the baseline data and constructing sequence features including instruction type sequences, instruction interval time sequences, and instruction parameter sequences. A sequence matching algorithm is used to calculate the similarity between the current instruction sequence and the normal pattern. The similarity calculation uses the edit distance algorithm to calculate the minimum number of operations required to transform between the two sequences. The anomaly confidence score is calculated as follows: Confidence = 1 - Similarity, with the similarity normalized to the 0-1 range. The training process for the communication anomaly detection module involves constructing a normal communication pattern based on the device connection graph, including a communication relationship matrix (connection relationships between devices) and a traffic matrix (data traffic between devices). Newly added abnormal connections (inconsistent with historical connection relationships) and abnormal traffic (exceeding the normal traffic range) are detected. The anomaly confidence score is calculated using a weighted sum: Confidence = 0.6 × Connection Anomaly Score + 0.4 × Traffic Anomaly Score. Finally, the three detection modules are jointly tested, using labeled simulation data to verify the detection effect and calculate the detection accuracy and recall of each module. Based on the test results, detection parameters are optimized, such as adjusting statistical thresholds, updating sequence matching algorithm parameters, and modifying the weights for anomaly calculation.

[0058] Step 1043: Obtain the historical recall and hit rates of each detection module, and determine the detection weight corresponding to each detection module based on the historical recall and hit rates of each detection module; calculate the anomaly confidence of each detection module based on the detection weight to obtain the target confidence; when the target confidence exceeds the preset threshold, it is determined that there is an attack event.

[0059] Historical recall rate refers to the ratio of the number of attack events correctly identified by the detection module to the total number of actual attack events, reflecting the completeness of the detection. Hit rate refers to the ratio of the number of attack events correctly identified by the detection module to the total number of detected events, reflecting the accuracy of the detection. Detection weight is the importance coefficient of each detection module in the final decision. Anomaly confidence is the anomaly score output by each detection module. Target confidence is the comprehensive score obtained by weighting multiple detection modules. Preset threshold is the scoring standard for judging attack events.

[0060] Specifically, the historical performance metrics of each detection module are first analyzed. For the traffic feature detection module: historical detection logs are analyzed to count the number of correct detections (TP), the number of missed detections (FN), and the number of false positives (FP), and the recall rate R1 = TP / (TP+FN) and the hit rate P1 = TP / (TP+FP) are calculated. For the behavior deviation detection module: the recall rate R2 and the hit rate P2 are calculated in the same way. For the communication anomaly detection module: the recall rate R3 and the hit rate P3 are calculated. Detection weights are calculated based on performance metrics using the comprehensive scoring formula: Wi = (Ri+Pi) / (∑(Rj+Pj)), where i represents the module number, and j iterates through all modules. The specific calculation process is: W1 = (R1+P1) / ((R1+P1)+(R2+P2)+(R3+P3)), and W2 and W3 are calculated similarly. The calculation process for target confidence is as follows: Read the current abnormal confidence scores C1, C2, and C3 output by each detection module, and perform a weighted calculation: Target Confidence = W1 × C1 + W2 × C2 + W3 × C3. Set a preset threshold of 0.8 for attack detection; when the target confidence score exceeds this threshold, it is considered an attack event. After an attack event is detected, record the following information: event occurrence time, abnormal confidence score of each module, target confidence score value, and abnormal characteristics that triggered the detection. Establish a detection result feedback mechanism, adding detection results to the historical log for periodically updating module performance metrics and weight coefficients. The weight update cycle is set to 7 days, and each update recalculates the performance metrics and weight coefficients for the most recent 30 days.

[0061] Step 105: Locate the identified attack event to the starting node of the device connection graph, perform iterative deduction on the starting node to determine multiple propagation paths, and generate an attack propagation heatmap based on each propagation path.

[0062] The starting node is the earliest device node where the attack occurs; it's the entry point for the attack in the device connectivity graph. The propagation path is the route the attack takes from the starting node to other nodes, consisting of a series of interconnected device nodes. Iterative simulation predicts the attack's propagation process in the network through multiple rounds of calculation. The attack propagation heatmap is a visual representation using color intensity to indicate the probability of each node being attacked; darker red indicates a higher probability of being attacked.

[0063] Specifically, the attack source characteristics, including source IP address, source MAC address, and source device identifier, are first extracted from the attack event detection records. All nodes in the device connection graph are traversed, and the node address information is matched with the attack source characteristics. The similarity calculation formula is: Similarity = (Number of matched fields) / (Total number of fields). The node with the highest similarity is selected as the starting node, and its identifier and network location information are recorded. Iterative propagation calculations are performed starting from the starting node. Each iteration executes the following steps: Extract all neighboring nodes of the current node, which are determined by edge connections in the device connection graph. The propagation probability is calculated for each neighboring node. Factors contributing to the probability include: connection strength (edge ​​weight, value 0-1), node vulnerability (based on historical attack records, value 0-1), and protection level (node ​​security protection level, value 0-1). The propagation probability calculation formula is: P = 0.4 × Connection Strength + 0.4 × Node Vulnerability + 0.2 × (1 - Protection Level). A propagation probability threshold of 0.5 is set. When the propagation probability exceeds the threshold, the adjacent node is added to the propagation path and becomes the new starting node in the next iteration. The iteration process continues until the propagation probability of the end nodes of all paths is below the threshold, or the maximum iteration depth (set to 5 layers) is reached. Node information for all propagation paths is collected, including node identifier, propagation probability, and path level. A heatmap data structure is constructed, including: node coordinates (position on the visualization plane), heat values ​​(normalized values ​​of propagation probability), and color mapping (mapping of probability values ​​to shades of red). An attack propagation heatmap is generated, using a red gradient to represent propagation probability: dark red for probability values ​​above 0.9, red for 0.7-0.9, and light red for 0.5-0.7. The connection relationships of the propagation paths are marked on the heatmap, with arrows indicating the direction of attack spread.

[0064] Step 106: Filter target nodes in the attack propagation heatmap whose probability of being compromised is greater than a preset probability threshold; trace the data distortion impact chain of the target node upward along the dependency links, trace the physical loss of control impact chain of the target node downward along the physical control links, and generate an attack propagation simulation report for industrial equipment based on the target nodes, the data distortion impact chain, and the physical loss of control impact chain.

[0065] The probability of being compromised is a numerical value representing the likelihood that a device node will be attacked and successfully controlled, ranging from 0 to 1. Target nodes are key devices whose probability of being compromised exceeds a preset threshold. The data distortion impact chain is the path by which the target node transmits erroneous data to upper-layer devices, reflecting the true spread of information loss. The physical loss of control impact chain is the path by which the target node transmits abnormal control commands to lower-layer devices, reflecting the spread of physical system loss of control. The attack propagation simulation report is a systematic analysis document of the scope and extent of the attack's impact.

[0066] Specifically, first, a preset probability threshold of 0.7 is set, and the probability of all nodes being compromised is extracted from the attack propagation heatmap. The node list is traversed, and nodes with a probability greater than 0.7 are selected as the target node set. An impact chain analysis is performed on each target node, divided into two directions: upward and downward. The process of tracing the data distortion impact chain upwards: based on dependency links, tracing upwards from the target node. Upper-level nodes that have data dependencies on the target node are extracted; the decisions and controls of these nodes depend on the data provided by the target node. The propagation attenuation of data distortion is calculated; the attenuation coefficient is related to the transmission level, decreasing by 0.2 for each upward layer. The data items and distortion degree of each affected node are recorded. Data items include: sensor readings, status information, and control parameters. Distortion degree = original compromise probability × (1 - attenuation coefficient). The process of tracing the physical loss of control impact chain downwards: based on the physical control link, tracing downwards from the target node. Lower-level execution devices controlled by the target node are extracted; the physical actions of these devices depend on the control commands of the target node. The diffusion coefficient of the runaway impact is calculated, which is related to the physical coupling degree. The diffusion coefficient is 0.9 for links with high coupling degree, 0.6 for medium coupling degree, and 0.3 for low coupling degree. The physical parameters and deviation degree of each affected node are recorded. Physical parameters include temperature, pressure, rotational speed, and location. The deviation degree = original probability of being compromised × diffusion coefficient. The process of generating an attack propagation simulation report is as follows: The report consists of three parts: attack overview, impact analysis, and risk assessment. The attack overview includes: attack discovery time, attack type, attack source characteristics, and propagation path. The impact analysis includes: data distortion impact chain (data items and distortion degree of each node), physical runaway impact chain (physical parameters and deviation degree of each node), and impact range statistics (total number of affected nodes and maximum impact depth). The risk assessment includes: critical node identification (the node with the highest distortion / deviation degree), potential hazard analysis (potential system failures), and protection recommendations (equipment and links requiring enhanced protection).

[0067] In one possible implementation, the data distortion impact chain of the target node is traced upwards along the dependency link, and the physical loss of control impact chain of the target node is traced downwards along the physical control link. Based on the target node, the data distortion impact chain, and the physical loss of control impact chain, an attack propagation simulation report for the industrial equipment is generated, specifically including steps 1061-1064, as follows: Step 1061: Based on dependency links, recursively trace upstream devices from the target node to identify the upstream device nodes that receive data from the target node, and connect the upstream device nodes in series to form a data distortion impact chain.

[0068] Specifically, the device identifier and network address information of the target node are first obtained, and dependency records related to that node are extracted from the dependency link database of the device connection graph. The dependency record contains fields: source device identifier, target device identifier, dependency type (data reading, status query, parameter acquisition), data item description, and update frequency. A recursive method is used for upstream tracing. The input parameter of the recursive function is the current node identifier. The execution process is as follows: query the dependency link database to obtain a list of all devices that use the current node as their data source; for each device node, record the following information: device type, network address, received data item, data purpose, and dependency level (based on data update frequency, 0.9 for high dependency (more than 1 time / second), 0.6 for medium dependency (more than 1 time / minute), and 0.3 for low dependency (less than 1 time / minute); the identified device node is used as the new current node, and the tracing function is recursively called; the recursion terminates when the highest-level device (such as an enterprise management system) is reached, or the tracing depth exceeds a preset number of layers (set to 5 layers). After completing the recursive tracing, all identified upstream device nodes are sorted from low to high control level to construct an ordered sequence of data distortion impact chains. Each node in the sequence contains attributes: node level (integer from 1 to 5), device information (type, address, function), dependent data (data item list), and dependency degree (value from 0.3 to 0.9). Relationships between nodes are established, and the upstream and downstream node identifiers corresponding to each node are recorded to form a complete data transmission link. A distortion attenuation coefficient is calculated for each level of the data distortion impact chain. The attenuation calculation formula is: current level distortion degree = previous level distortion degree × dependency degree × (1 - level × 0.1), where levels are counted starting from 1.

[0069] Step 1062: Based on the physical control link, recursively trace down to the downstream devices starting from the target node, identify the downstream device nodes controlled by the target node, and connect the downstream device nodes in series to form a physical loss of control impact chain.

[0070] Specifically, the control relationship records of the target node are first extracted from the physical control link database of the device connection graph. The control relationship records include fields: control source identifier, controlled device identifier, control type (switch control, parameter adjustment, action control), control cycle, and response time. A recursive tracing function is established, with the current node identifier as the input parameter. The execution process is as follows: query the physical control link database to obtain a list of all devices controlled by the current node; record information for each controlled device: device type, physical location, execution function, control parameter range, and control tightness (based on the control cycle: less than 100 milliseconds indicates strong control with a value of 0.9, less than 1 second indicates medium control with a value of 0.6, and greater than 1 second indicates weak control with a value of 0.3); the identified controlled device is used as the new current node, and the tracing function is recursively called; the recursion terminates when the lowest-level execution device is reached, or the tracing depth exceeds a preset number of layers (set to 4 layers). Assess the impact of physical runaway at each downstream node: Analyze control parameter deviations and calculate the parameter deviation rate = (abnormal parameter value - normal parameter value) / parameter range × 100%; assess response time delay and calculate the delay ratio = (abnormal response time - normal response time) / control cycle × 100%; determine the degree of control failure: failure degree = 0.5 × parameter deviation rate + 0.3 × delay ratio + 0.2 × control tightness. Sort all downstream device nodes according to control level from high to low, constructing a physical runaway impact chain. Each node includes attributes: node level (integer from 1 to 4), device information (type, location, function), control parameters (parameter list and range), control tightness (value from 0.3 to 0.9), and failure degree (value from 0 to 1). Establish control associations between nodes, record the hierarchical control relationships of each node, forming a complete control transmission chain. The runaway diffusion coefficient is calculated for each level of the physical runaway impact chain. The diffusion calculation formula is: current level of runaway degree = previous level of runaway degree × control tightness × (1 - level × 0.15), where the level is counted starting from 1.

[0071] Step 1063: Simulate and verify the injection of abnormal data and erroneous instructions into the target node using a preset digital twin model, and record the duration of service interruption and parameter offset of each device in the chain caused by data distortion and physical loss of control.

[0072] Specifically, the first step is to construct an injection scheme for abnormal data and erroneous commands. Abnormal data injection includes: numerical anomalies (changing temperature sensor data from 25°C to 125°C, pressure data from 2MPa to 10MPa), status anomalies (changing operating status from "running" to "fault," valve opening from 50% to 0%), and timing anomalies (changing data update cycle from 100ms to 10s, status feedback delay from 50ms to 2s). Erroneous command injection includes: control commands (sending start commands to running equipment, sending close commands to closed valves), parameter commands (changing speed setpoint from 1500rpm to 3000rpm, temperature setpoint from 80°C to 150°C), and operational commands (skipping equipment preheating and starting directly, violating interlocking logic and forcing operation). Simulation verification is performed in the digital twin model: the simulation duration is set to 4 hours, and the sampling period is 100ms. Verification process for the data distortion impact chain: Record the abnormal behavior of each device according to the hierarchical order of the impact chain: business process status (normal / paused / terminated), data processing status (normal / abnormal / interrupted), and function operation status (normal / degraded / stopped). Calculate the duration of each status and the business interruption duration = Σ(abnormal state duration). Verification process for the physical loss of control impact chain: Record the parameter changes of each device according to the hierarchical order of the impact chain: instantaneous parameter values ​​(recorded in physical quantity units), parameter change rate (change per unit time), and parameter stability (fluctuation range). Calculate the parameter offset = (abnormal parameter value - normal parameter value), and record the maximum offset, average offset, and offset duration. Establish a simulation data recording table containing fields: device identifier, timestamp, business status, interruption duration, parameter value, offset, and anomaly type. Perform statistical analysis on the simulation data: calculate the cumulative interruption duration, maximum parameter offset, average parameter offset, and impact recovery time for each device. Generate a statistical report on the impact of device anomalies, including abnormal indicator data and time-series change curves for each device.

[0073] Step 1064: Perform structured processing on the data distortion impact chain, physical loss of control impact chain, service interruption duration, and parameter offset to generate an attack propagation simulation report in a preset format.

[0074] Specifically, the data is first processed through structuring. For handling data distortion impact chains: a hierarchical data structure is created, containing three levels: Level 1: basic information of the impact chain (link identifier, starting node, ending node, impact depth); Level 2: node hierarchy information (hierarchy number, hierarchy type, number of nodes, distortion degree); Level 3: detailed node information (device identifier, device type, dependent data, distortion impact). For handling physical out-of-control impact chains: a similar three-level structure is used: Level 1: basic information of the impact chain (link identifier, starting node, ending node, impact depth); Level 2: node hierarchy information (hierarchy number, hierarchy type, number of nodes, out-of-control degree); Level 3: detailed node information (device identifier, device type, control parameters, out-of-control impact). For handling service interruption data: statistics are grouped by device, with records including: cumulative interruption duration, longest single interruption, average interruption duration, and number of interruptions. For handling parameter offset data: statistics are grouped by parameter type, with records including: maximum offset, average offset, offset duration, and offset change rate. The report generates an attack propagation simulation analysis report, structured as follows: Chapter 1: Attack Overview (Attack Type, Attack Time, Attack Characteristics, Propagation Scope); Chapter 2: Impact Chain Analysis (Complete description of the impact chain due to data distortion, complete description of the impact chain due to physical loss of control, impact chain topology diagram); Chapter 3: Impact Assessment (Detailed statistics of business interruption, detailed statistics of parameter offset, analysis of key nodes); Chapter 4: Propagation Path (Attack diffusion process, order of affected nodes, propagation speed analysis); Chapter 5: Risk Level (Impact severity classification, risk area division, protection recommendations). Data visualizations in the report include: impact chain topology diagram (network structure diagram of nodes and connections), heat map (color intensity map of impact severity), time-series variation diagram (parameter change curves over time), and statistical histogram (bar chart of data distribution). Data update mechanism: The report supports regular updates, updating real-time data hourly and generating a complete report daily. The report format uses a standardized electronic document format, supporting data export and sharing.

[0075] In the above embodiments, a basic attack detection framework was implemented through feature matching and rule verification. To further improve the accuracy of attack propagation path prediction and reduce the impact of network topology on propagation determination, this application also provides an industrial network attack propagation analysis method. This method analyzes the communication characteristics, dependency characteristics, and service characteristics between devices, studies the hierarchical structure of attack diffusion, and performs adaptive propagation probability calculation, enabling the system to more accurately handle the attack propagation path prediction needs in complex industrial network environments. The following section combines... Figure 2 Another industrial internet attack propagation simulation method is described in the embodiments of this application: Please see Figure 2This is a flowchart illustrating an industrial internet attack propagation simulation method in an embodiment of this application.

[0076] Step 201: Locate the starting node in the device connection graph based on the source address of the attack event, and extract the adjacent nodes connected to the starting node along the data transmission path.

[0077] Specifically, the first step is to extract the source address information from the attack event logs. The source address resolution process involves: converting the IP address from string format to a 32-bit integer (e.g., "192.168.1.1" to 3232235777); normalizing the MAC address to a 6-byte format (e.g., "00:1A:2B:3C:4D:5E"); extracting the port number and converting it to a 16-bit integer (e.g., "8080" to 32896); and standardizing the device identifier format (e.g., "PLC-001"). Then, node matching is performed in the device connection graph: traversing all nodes in the graph and calculating the address matching score for each node. The matching score calculation includes four parts: IP address matching (complete match score 1.0, same network segment score 0.8); MAC address matching (complete match score 1.0, first 4 bytes matching score 0.6); port number matching (complete match score 1.0, same service type score 0.7); and device identifier matching (complete match score 1.0, same type prefix score 0.5). Calculate the total matching score: Total score = 0.4 × IP matching score + 0.3 × MAC matching score + 0.2 × port matching score + 0.1 × identifier matching score. Select the node with the highest total matching score exceeding 0.8 as the starting node. After determining the starting node, extract adjacent nodes through the data transmission path: Query the edge table of the device connection graph to obtain all edges directly connected to the starting node; extract the target nodes corresponding to these edges as the set of adjacent nodes; record the connection attributes for each adjacent node: connection type (direct connection / routing forwarding), transmission protocol (TCP / UDP / ICP), bandwidth limit (Mbps), and transmission delay (ms). Establish an adjacent node table containing fields: node identifier, device type, network address, connection attribute, and most recent communication timestamp. Classify adjacent nodes: by connection type (directly connected nodes have higher priority), by transmission frequency (high-frequency communication nodes have higher priority), and by device importance (critical devices have higher priority).

[0078] In one possible implementation, the starting node is located in the device connection graph based on the source address of the attack event, specifically including steps 2011-2013, as follows: Step 2011: Extract the source IP address, source port, and source device identifier associated with the attack event as the source address.

[0079] Specifically, the first step is to extract address information from the attack event logs. Source IP address extraction: Check the IP address format validity. IPv4 addresses must conform to dotted decimal format (e.g., "192.168.1.1"), and IPv6 addresses must conform to colon hexadecimal format (e.g., "2001:0db8:85a3:0000:0000:8a2e:0370:7334"). After extraction, standardize the format: add leading zeros to IPv4 addresses and compress repeated zero segments for IPv6 addresses. Verify the reachability of the IP address, excluding reserved addresses (e.g., 127.0.0.1) and private addresses (e.g., 192.168.0.0 / 16). Source port extraction: Convert the port number from a string to a 16-bit integer (range 0-65535). Check the port number validity, excluding system reserved ports (0-1023). Record the service type corresponding to the port, such as 80 for HTTP, 443 for HTTPS, and 502 for Modbus. Source Device Identifier Extraction: Parses the device identifier format, supporting multiple identification methods (alphanumeric combination, MAC address, serial number); standardizes the identifier format, unifies uppercase and lowercase letters, and removes special characters; verifies the existence of the identifier in the device asset database. Data Association Processing: Creates an association table containing fields: event identifier (UUID format), source IP address (string), source port (integer), device identifier (string), extraction timestamp (accurate to milliseconds); checks the time consistency of address information to ensure it is within the same attack session; verifies the logical relationship of address information to ensure that the IP address corresponds to the device identifier. Source Address Structuring: Encapsulates the extracted address information into a standard data structure, containing the main fields: ipAddress (IP address string), portNumber (port number integer), deviceId (device identifier string), extractTime (extraction timestamp), validStatus (validity status); adds auxiliary fields: addressType (address type: IPv4 / IPv6), portService (port service type), deviceType (device type). Data quality control: Check data integrity; all required fields must not be empty; check data consistency; multiple address information for the same device must match; record data credibility based on the reliability assessment of the information source.

[0080] Step 2012: Traverse each node in the device connection graph, and match the IP address, port information and device identifier marked on each node with the source address; determine the node with a matching degree greater than the preset matching degree threshold as the starting node.

[0081] Specifically, a graph node traversal mechanism is first established. The traversal method employs depth-first search, creating a node access marker table to record visited nodes. For each graph node, address information is extracted: an IP address list (primary and backup IP addresses), a port list (port number and service type), and device identification information (primary identifier and alias). Address matching calculations are performed, with the matching score calculated across three dimensions: IP address matching rules: perfect match score 1.0; same network segment (first 24 bits identical) score 0.8; same subnet (first 16 bits identical) score 0.6; different network segments score 0.0. Port matching rules: perfect port number match score 1.0; same service type score 0.8; port number within a preset range score 0.5; no port match score 0.0. Device identifier matching rules: perfect primary identifier match score 1.0; alias match score 0.8; same device type score 0.5; no match score 0.0. The formula for calculating the total match score is: Match Score = 0.4 × IP Address Match Score + 0.3 × Port Match Score + 0.3 × Identifier Match Score. Create a match result table containing the following fields: Node Identifier, IP Match Score, Port Match Score, Identifier Match Score, Total Match Score, and Match Timestamp. Set a preset match score threshold of 0.8 to filter nodes whose match scores exceed the threshold. Matching Example: Node data: IP address = "192.168.1.100", port = 502, identifier = "PLC-001"; Source address data: IP address = "192.168.1.100", port = 502, identifier = "PLC_001"; Calculation results: IP match score = 1.0 (exact match), port match score = 1.0 (exact match), identifier match score = 0.8 (alias match); Total match score = 0.4 × 1.0 + 0.3 × 1.0 + 0.3 × 0.8 = 0.94. For nodes with a match score exceeding 0.8, perform the following verification steps: verify the node's activity status (online / offline); check the node's security status (normal / abnormal); confirm the node's network connectivity (reachable / unreachable). The node with the highest verified match score is designated as the starting node, and the determination criteria are recorded: match score value, match details, and determination timestamp. A starting node attribute table is created, containing fields such as: node identifier, network address, device information, match details, determination time, and determination criteria.

[0082] Step 2013: When there are multiple graph nodes with a matching degree greater than the preset matching degree threshold, calculate the time difference between the timestamp of the attack event and the most recent activity time of each graph node, and select the graph node with the smallest time difference as the starting node.

[0083] Specifically, first, a candidate node list is established, containing all graph nodes with a matching degree greater than 0.8. Attack event time information is extracted: attack event timestamps are converted to Unix timestamp format; timestamps are standardized to UTC time to eliminate time zone influence; the validity of timestamps is verified, excluding future and premature times. Candidate node activity times are extracted: activity logs for each node are collected, including: network communication records (data packet sending and receiving times), status change records (power on / off, configuration modification times), and alarm records (anomaly detection times); all time records are converted to Unix timestamp format; sorted in reverse chronological order, and the most recent activity time is selected. Time difference calculation process: a time difference calculation table is created, containing fields: node identifier, attack timestamp, activity timestamp, and time difference value (seconds); for each candidate node, the time difference is calculated as |attack timestamp - activity timestamp|; the time difference is converted to seconds; and the calculation results are recorded. Example of time difference comparison: Attack timestamp = 1640995200 (2022-01-01 00:00:00 UTC); Node A's most recent activity time = 1640995100 (2021-12-31 23:58:20 UTC), time difference = 100 seconds; Node B's most recent activity time = 1640995150 (2021-12-31 23:59:10 UTC), time difference = 50 seconds; Node C's most recent activity time = 1640995180 (2021-12-31 23:59:40 UTC), time difference = 20 seconds. Selection process: Sort candidate nodes in ascending order of time difference; Verify the validity of the node with the smallest time difference: Check if the time difference is within a reasonable range (less than 3600 seconds); Verify the connection status of the node during the attack period; Confirm that the node's data transmission records match the attack characteristics. Determine the starting node: Select the node with the smallest time difference and that has passed verification as the starting node; record the selection criteria: node identifier, matching degree, time difference, and verification result; establish a starting node attribute table containing complete node information and selection process data.

[0084] Step 202: For each adjacent node, extract the communication frequency and data sensitivity of the connecting edges of the adjacent node, extract the vulnerability information and business importance of the adjacent node, and perform weighted fusion of communication frequency, data sensitivity, vulnerability information and business importance to determine the probability of being compromised.

[0085] Specifically, the process begins by extracting connection attribute data for each adjacent node. Communication frequency extraction involves counting the number of communications per unit time and establishing frequency levels: high frequency (≥100 times / second, value 0.9), medium frequency (10-100 times / second, value 0.6), and low frequency (<10 times / second, value 0.3). Data sensitivity extraction involves analyzing the data type of transmission and determining its sensitivity level: control commands (high sensitivity, value 0.9), status data (medium sensitivity, value 0.6), and log information (low sensitivity, value 0.3). Vulnerability information extraction involves querying the device vulnerability database and extracting vulnerability records: critical vulnerabilities (unpatched, value 0.9; patched, value 0.3), moderate vulnerabilities (unpatched, value 0.6; patched, value 0.2), and minor vulnerabilities (unpatched, value 0.3; patched, value 0.1). Business Importance Extraction Process: Equipment Role Assessment: Core Control Equipment (0.9), Process Control Equipment (0.6), Auxiliary Equipment (0.3). The extracted four indicators are weighted and fused to calculate the probability of being compromised. Calculation Formula: Probability of Compromise = W1 × Communication Frequency + W2 × Data Sensitivity + W3 × Vulnerability Level + W4 × Business Importance, where the weighting coefficients are W1 = 0.2 (communication frequency weight), W2 = 0.3 (data sensitivity weight), W3 = 0.3 (vulnerability level weight), and W4 = 0.2 (business importance weight). Example of probability calculation for each adjacent node: A PLC node has the following metrics: Communication Frequency = 0.6 (medium frequency), Data Sensitivity = 0.9 (high sensitivity), Vulnerability Level = 0.6 (medium unpatched), Business Importance = 0.9 (core device). Therefore, its probability of being compromised is 0.2 × 0.6 + 0.3 × 0.9 + 0.3 × 0.6 + 0.2 × 0.9 = 0.75. Record the calculation results in the node attribute table, including the fields: node identifier, four metric values, weight coefficient, and probability of compromise. Sort the probability of compromise for all adjacent nodes and establish a risk level classification: high risk (probability ≥ 0.8), medium risk (0.5 ≤ probability < 0.8), and low risk (probability < 0.5).

[0086] Step 203: Remove the leading nodes whose probability of being compromised is less than the baseline probability threshold, and mark the remaining leading nodes as compromised nodes, generating multiple propagation paths from the starting node to each compromised node; generate an attack propagation heatmap based on the probability of each leading node being compromised in each propagation path.

[0087] Specifically, first, a baseline probability threshold of 0.6 is set, and the compromise probability of all adjacent nodes is traversed. Node filtering process: Create a node list containing fields: node identifier, compromise probability, device type, and network location; traverse the node list, removing nodes with a compromise probability less than 0.6; mark the remaining nodes as "compromised" and record the compromise timestamp. Propagation path generation process: Use a breadth-first search algorithm, traversing from the starting node. Path generation steps: Create an empty path set; add the starting node to the queue; when the queue is not empty, remove the head node; obtain all compromised adjacent nodes of the current node; for each adjacent node, construct a new path from the starting node through the current path to that node; add the new path to the path set. Path recording format: path identifier, node sequence, path length, cumulative probability (average of the compromise probabilities of all nodes on the path). Heatmap generation process: Create a 2D plane coordinate system; calculate node layout, use a force-directed algorithm to determine node positions, and set parameters: repulsion coefficient (distance between adjacent nodes) = 100, attraction coefficient (length of connecting edge) = 50, iteration count = 1000. Node drawing rules: Node size is proportional to device importance; node color is based on the probability of being compromised, with probabilities above 0.9 displayed as dark red (RGB: 255, 0, 0), probabilities between 0.7 and 0.9 displayed as red (RGB: 255, 99, 71), and probabilities between 0.6 and 0.7 displayed as light red (RGB: 255, 160, 122). Connecting edge drawing rules: Edge thickness is proportional to communication frequency; edge color gradually changes from the starting node color to the target node color. Heatmap data structure: Node layer (containing node position and color information), edge layer (containing connection relationships and style information), heatmap layer (containing color gradients of probability distribution). Legend: Add color bars to show the correspondence between probability and color; add attribute descriptions for nodes and edges. Supports interactive operations: clicking on nodes displays detailed information; hovering over paths highlights the view; and a scale bar adjusts the view.

[0088] The following describes an industrial internet attack propagation simulation and deduction system from the perspective of hardware processing, according to an embodiment of this invention. Please refer to [link / reference]. Figure 3 This is a schematic diagram of the structure of an industrial internet attack propagation simulation and deduction system in an embodiment of this application.

[0089] It should be noted that, Figure 3 The structure of the industrial internet attack propagation simulation system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0090] like Figure 3As shown, an industrial internet attack propagation simulation system includes a central processing unit (CPU) 301, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 302 or programs loaded from storage section 308 into random access memory (RAM) 303, such as executing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0091] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0092] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0093] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0094] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0095] Specifically, the industrial internet attack propagation simulation and deduction system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the industrial internet attack propagation simulation and deduction method provided in the above embodiment.

[0096] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the industrial internet attack propagation simulation and deduction system described in the above embodiments; or it may exist independently and not assembled into the industrial internet attack propagation simulation and deduction system. The storage medium carries one or more computer programs, which, when executed by a processor of the industrial internet attack propagation simulation and deduction system, enable the industrial internet attack propagation simulation and deduction system to implement the industrial internet attack propagation simulation and deduction method based on IoT data encryption transmission provided in the above embodiments.

Claims

1. A simulation and deduction method for industrial internet attack propagation, characterized in that, The method includes: Acquire equipment data of industrial equipment, and based on the mapping relationship between the acquired data and virtual entities in a preset digital twin model, synchronize the acquired data to the preset digital twin model. The equipment data includes physical parameters, operating status, and network traffic characteristics. Collect the instruction sequence of the preset digital twin model during operation, and construct a behavior model library corresponding to the instruction sequence; By using the interaction data between virtual entities in the preset digital twin model, dependent links, data transmission paths, and physical control links are identified, and a device connection map is constructed. Attack traffic is injected into the digital twin model to generate simulation data, and the attack detector is trained by combining the behavior model library and the device connectivity graph. Attack events are determined based on the detection results of the attack detector. The determined attack event is located at the starting node of the device connection graph. Multiple propagation paths are determined by iterative deduction of the starting node, and an attack propagation heatmap is generated based on each propagation path. Target nodes in the attack propagation heatmap with a probability of being compromised greater than a preset probability threshold are selected. The data distortion impact chain of the target node is traced upward along the dependency link, and the physical loss of control impact chain of the target node is traced downward along the physical control link. Based on the target node, the data distortion impact chain, and the physical loss of control impact chain, an attack propagation simulation report of the industrial equipment is generated.

2. The method according to claim 1, characterized in that, The step of acquiring equipment data from industrial equipment and synchronizing the acquired data to the preset digital twin model based on the mapping relationship between the acquired data and virtual entities in the preset digital twin model includes: Identify the programmable logic controller, servo motor, and industrial control protocol state machine associated with the industrial equipment; The register values ​​of the programmable logic controller and the speed and torque of the servo motor are collected as the physical parameters, and the working mode and process occupancy rate of the industrial control protocol state machine are collected as the running state. The message headers and industrial control protocol instructions received from the industrial equipment are used as the network traffic characteristics. In the preset digital twin model, a virtual entity containing attribute fields is created for the industrial equipment, and the correspondence between the physical parameters, the operating status, and the network traffic characteristics and the attribute fields of the virtual entity is established as the mapping relationship; The device data is synchronized to the attribute fields of the virtual entity through the mapping relationship, and the preset digital twin model is driven to run.

3. The method according to claim 1, characterized in that, The process of identifying dependent links, data transmission paths, and physical control links, and constructing a device connectivity map, includes: Extract communication messages and instruction call records between virtual entities in the preset digital twin model from the interaction data; Based on the communication message and the instruction call record, identify the data read request and control instruction sent by the host computer virtual entity to the lower controller virtual entity, and use the communication link corresponding to the data read request and the communication link corresponding to the control instruction as the dependent link; The data flow direction between the virtual entities is collected as the data transmission path; By analyzing the timestamps of attribute changes in virtual entities through time-series analysis, the actuator-sensor pairing relationship is identified where the time when the action command of the actuator virtual entity is issued precedes the time when the reading of the sensor virtual entity changes. The link corresponding to the actuator-sensor pairing relationship is then taken as the physical control link. The device connection graph is constructed based on the dependency links, the data transmission paths, and the physical control links. The graph nodes in the device connection graph correspond to industrial equipment, and the graph edges correspond to the connection relationships between virtual entities.

4. The method according to claim 1, characterized in that, The process of injecting attack traffic into the digital twin model to generate simulation data, training an attack detector using the behavior model library and the device connectivity graph, and determining attack events based on the detection results of the attack detector includes: The preset digital twin model is driven to simulate and generate benchmark data. At preset time nodes, industrial control protocol vulnerability attack traffic, command attack traffic and lateral movement attack traffic are injected into the virtual entity of the preset digital twin model. The running data after the injection of attack traffic is collected as simulation data. An attack detector comprising multiple detection modules is trained using the benchmark data and the simulation data to obtain the anomaly confidence scores output by each detection module. The detection modules include a traffic feature detection module, a behavior deviation detection module, and a communication anomaly detection module. Obtain the historical recall and hit rates of each detection module, and determine the detection weight corresponding to each detection module based on the historical recall and hit rates of each detection module; The abnormal confidence of each detection module is calculated by weighting the detection weights to obtain the target confidence. When the target confidence exceeds a preset threshold, an attack event is determined to exist.

5. The method according to claim 1, characterized in that, The step of locating the determined attack event to the starting node of the device connection graph, iteratively deducing multiple propagation paths from the starting node, and generating an attack propagation heatmap based on each propagation path includes: Based on the source address of the attack event, locate the starting node in the device connection graph, and extract the adjacent nodes connected to the starting node along the data transmission path; For each adjacent node, the communication frequency and data sensitivity of the connecting edges of the adjacent node are extracted, the vulnerability information and business importance of the adjacent node are extracted, and the communication frequency, data sensitivity, vulnerability information and business importance are weighted and fused to determine the probability of being compromised. Remove the leading nodes whose probability of being compromised is less than the baseline probability threshold, and mark the remaining leading nodes as compromised nodes, generating multiple propagation paths from the starting node to each compromised node; The attack propagation heatmap is generated based on the probability of each connecting node in each propagation path being compromised.

6. The method according to claim 5, characterized in that, Locating the starting node in the device connectivity graph based on the source address of the attack event includes: Extract the source IP address, source port, and source device identifier associated with the attack event as the source address; Traverse each node in the device connection graph and match the IP address, port information, and device identifier marked on each node with the source address; The graph nodes with a matching degree greater than a preset matching degree threshold are determined as the starting nodes; When there are multiple graph nodes with a matching degree greater than a preset matching degree threshold, the time difference between the timestamp of the attack event and the most recent activity time of each graph node is calculated, and the graph node with the smallest time difference is selected as the starting node.

7. The method according to claim 1, characterized in that, The process involves tracing the data distortion impact chain upwards along the dependency link to the target node, tracing the physical loss of control impact chain downwards along the physical control link to the target node, and generating an attack propagation simulation report for the industrial equipment based on the target node, the data distortion impact chain, and the physical loss of control impact chain. This report includes: Based on the dependency link, starting from the target node, the upstream device nodes that receive the data from the target node are recursively traced upwards to identify the upstream device nodes that receive the data from the target node, and the upstream device nodes are connected in series to form the data distortion impact chain. Based on the physical control link, starting from the target node, the downstream device is recursively traced down to the next layer device to identify the downstream device node controlled by the target node, and the downstream device nodes are connected in series to form the physical loss of control impact chain; The target node is injected with abnormal data and erroneous instructions through the preset digital twin model to perform simulation verification, and the service interruption duration of each device in the data distortion impact chain and the parameter offset of each device in the physical loss of control impact chain are recorded. The data distortion impact chain, the physical loss of control impact chain, the service interruption duration, and the parameter offset are structured to generate an attack propagation simulation report in a preset format.

8. An industrial internet attack propagation simulation and deduction system, characterized in that, The industrial internet attack propagation simulation system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the industrial internet attack propagation simulation system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is run on the Industrial Internet Attack Propagation Simulation and Deduction System, the Industrial Internet Attack Propagation Simulation and Deduction System performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the Industrial Internet Attack Propagation Simulation and Deduction System, the Industrial Internet Attack Propagation Simulation and Deduction System performs the method as described in any one of claims 1-7.

Images