A power industrial control system vulnerability verification method, device, equipment and storage medium

Abstract

The application provides a power industrial control system vulnerability verification method, device and equipment and a storage medium. The method comprises the following steps: constructing a firmware-level simulation model in a virtualization environment, and running real firmware of a target device; acquiring an attack payload, injecting the attack payload into the simulation model and a corresponding physical device respectively, collecting behavior data of the two and comparing the behavior data, and determining a behavior deviation; when the deviation exists, locating a hardware abstraction component (i.e. a software module simulating the function of a physical chip or peripheral device) causing the deviation according to a deviation attribute, and performing repair. The method calibrates the model by comparing the behavior data, solves the problem of high false alarm rate caused by simulation distortion, and improves the fidelity and reliability of vulnerability verification.

Description

Technical Field

[0001] This application belongs to the field of system vulnerability detection, and in particular relates to a method, device, equipment and storage medium for verifying vulnerabilities in power industrial control systems. Background Technology

[0002] As power industry control systems become critical national information infrastructure, they face increasingly severe cybersecurity threats. To ensure the safe and stable operation of the power grid, verifying and testing cybersecurity vulnerabilities in power industry control systems has become crucial.

[0003] Existing technologies mainly include pure digital simulation, pure physical testing, and automated vulnerability discovery tools to discover and verify security vulnerabilities in power industrial control systems. Pure digital simulation solutions test by establishing virtual models of the industrial control system, featuring low cost and good scalability; pure physical testing solutions perform penetration testing directly on real industrial control hardware devices, which can realistically reflect the attack effects; while automated tools such as Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and fuzzing are used to discover potential vulnerabilities in batches.

[0004] However, significant shortcomings exist in practical implementation: First, purely digital simulation schemes fail to adequately depict the details of industrial control firmware, protocol timing, and physical characteristics, leading to model distortion and a high false positive rate in vulnerability verification results. Furthermore, they cannot reproduce the impact of real attacks on physical devices. Second, while purely physical testing schemes can reflect real-world effects, direct testing on real devices poses security risks such as device downtime and power grid disturbances. Moreover, the high cost and long deployment cycle of these devices cannot meet the needs of large-scale vulnerability verification. In addition, existing automated vulnerability discovery tools lack effective closed-loop mechanisms for vulnerability verification, making it impossible to quantitatively assess the complete impact chain of cyberattacks penetrating from cyberspace to the physical power grid. Simultaneously, existing simulation architectures lack unified standards for virtual-real interaction, resulting in data asynchrony and inconsistent behavior between virtual models and physical devices.

[0005] The above technical solutions suffer from high false positive rates in vulnerability verification results due to model distortion, and cannot quantify the physical impact of attacks. Summary of the Invention

[0006] The purpose of this application is to overcome the defects in the prior art and provide a method, apparatus, device and storage medium for verifying vulnerabilities in power industrial control systems.

[0007] This application provides a method for vulnerability verification in a power industrial control system, including: Construct a firmware-level simulation model, which runs the real firmware of physical industrial control equipment in a virtual environment; Obtain the attack payload targeting the firmware-level simulation model; In an isolated test environment, the attack payload is injected into the firmware-level simulation model and the corresponding physical industrial control equipment, respectively. Acquire the first behavioral data of the firmware-level simulation model under the attack payload, and the second behavioral data of the physical industrial control device under the attack payload; By comparing the first behavioral data with the second behavioral data, behavioral deviations can be determined. When the behavioral deviation exists, based on the attributes of the behavioral deviation, at least one hardware abstraction component in the firmware-level simulation model that causes the behavioral deviation is located, and the hardware abstraction component is a software module that simulates the functions of a physical chip or peripheral device. Repair the identified hardware abstraction components.

[0008] Optionally, acquiring the first behavioral data of the firmware-level simulation model under the attack payload, and the second behavioral data of the physical industrial control device under the attack payload, includes: Before injecting the attack payload, the same standardized test signal sequence is injected into the firmware-level simulation model and the physical industrial control equipment; Based on the state established by the standardized test signal sequence, the first behavioral data and the second behavioral data are obtained.

[0009] Optionally, comparing the first behavioral data with the second behavioral data to determine behavioral deviation includes: The timing sequence of instruction execution recorded in the first behavior data and the second behavior data is compared to determine the timing-type behavior deviation.

[0010] Optionally, comparing the first behavioral data with the second behavioral data to determine behavioral deviation includes: Compare the read / write state sequences of peripheral registers recorded in the first and second behavior data to determine the state-type behavior deviation.

[0011] Optionally, based on the attributes of the behavioral deviation, at least one hardware abstraction component in the firmware-level simulation model that causes the behavioral deviation is located, including: When the attribute of the behavior deviation is a timing-type behavior deviation, locate the CPU virtual core or timer virtual module in the firmware-level simulation model.

[0012] Optionally, based on the attributes of the behavioral deviation, at least one hardware abstraction component in the firmware-level simulation model that causes the behavioral deviation is located, including: When the attribute of the behavior deviation is a state-type behavior deviation, locate the virtual module of the peripheral interface controller corresponding to the peripheral register in the firmware-level simulation model.

[0013] Optionally, the located hardware abstraction component is repaired, including: When the hardware abstraction component is a central processing unit (CPU) virtual core, adjust the instruction simulation cycle parameters of the CPU virtual core; When the hardware abstraction component is a timer virtual module, the time base parameters of the timer virtual module are corrected.

[0014] This application also provides a vulnerability verification device for power industrial control systems, including: The model module constructs a firmware-level simulation model, which runs the real firmware of the physical industrial control equipment in a virtual environment. The payload module acquires attack payloads targeting the firmware-level simulation model. The testing module injects the attack payload into the firmware-level simulation model and the corresponding physical industrial control equipment in an isolated testing environment. The data module acquires the first behavioral data of the firmware-level simulation model under the attack payload, and the second behavioral data of the physical industrial control device under the attack payload; The comparison module compares the first behavioral data with the second behavioral data to determine the behavioral deviation; The determination module, when the behavior deviation exists, locates at least one hardware abstraction component in the firmware-level simulation model that causes the behavior deviation based on the attributes of the behavior deviation. The hardware abstraction component is a software module that simulates the functions of a physical chip or peripheral device. The optimization module repairs the identified hardware abstraction components.

[0015] Optionally, the data module acquires first behavioral data of the firmware-level simulation model under the attack payload, and second behavioral data of the physical industrial control device under the attack payload, including: Before injecting the attack payload, the same standardized test signal sequence is injected into the firmware-level simulation model and the physical industrial control equipment; Based on the state established by the standardized test signal sequence, the first behavioral data and the second behavioral data are obtained.

[0016] Optionally, the comparison module compares the first behavioral data with the second behavioral data to determine the behavioral deviation, including: The timing sequence of instruction execution recorded in the first behavior data and the second behavior data is compared to determine the timing-type behavior deviation.

[0017] Optionally, the comparison module compares the first behavioral data with the second behavioral data to determine the behavioral deviation, including: Compare the read / write state sequences of peripheral registers recorded in the first and second behavior data to determine the state-type behavior deviation.

[0018] Optionally, the determining module locates at least one hardware abstraction component in the firmware-level simulation model that causes the behavioral deviation based on the attributes of the behavioral deviation, including: When the attribute of the behavior deviation is a timing-type behavior deviation, locate the CPU virtual core or timer virtual module in the firmware-level simulation model.

[0019] Optionally, the determining module locates at least one hardware abstraction component in the firmware-level simulation model that causes the behavioral deviation based on the attributes of the behavioral deviation, including: When the attribute of the behavior deviation is a state-type behavior deviation, locate the virtual module of the peripheral interface controller corresponding to the peripheral register in the firmware-level simulation model.

[0020] Optionally, the optimization module repairs the located hardware abstraction component, including: When the hardware abstraction component is a central processing unit (CPU) virtual core, adjust the instruction simulation cycle parameters of the CPU virtual core; When the hardware abstraction component is a timer virtual module, the time base parameters of the timer virtual module are corrected.

[0021] This application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement any of the methods described above.

[0022] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform any of the methods described above.

[0023] The beneficial effects of this application are: This application provides a method for verifying vulnerabilities in a power industrial control system, comprising: constructing a firmware-level simulation model, wherein the firmware-level simulation model runs the real firmware of a physical industrial control device in a virtualized environment; obtaining an attack payload targeting the firmware-level simulation model; injecting the attack payload into the firmware-level simulation model and the corresponding physical industrial control device in an isolated test environment; obtaining first behavioral data of the firmware-level simulation model under the attack payload and second behavioral data of the physical industrial control device under the attack payload; comparing the first behavioral data with the second behavioral data to determine a behavioral deviation; when the behavioral deviation exists, locating at least one hardware abstraction component in the firmware-level simulation model that causes the behavioral deviation based on the attributes of the behavioral deviation, wherein the hardware abstraction component is a software module that simulates the functions of a physical chip or peripheral device; and patching the located hardware abstraction component. This application constructs a firmware-level simulation model and runs real firmware to obtain and compare the behavioral data of the model and the physical device under attack payloads. It locates and repairs the hardware abstraction components that cause behavioral deviations, and realizes the accurate calibration of the virtual model on the behavior of physical entities. This solves the problem of high false alarm rate of verification results caused by model distortion and improves the fidelity and credibility of vulnerability verification. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the vulnerability verification process for the power industrial control system in this application; Figure 2 This is a schematic diagram of the power industrial control system vulnerability verification device in this application. Detailed Implementation

[0025] Exemplary embodiments of the present disclosure will now be provided in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it is to be understood that various forms of implementation of the present disclosure are intended and should not be limited to the embodiments set forth herein. Rather, the embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0026] This application provides a vulnerability verification method for power industrial control systems, which is applied in the field of power industrial control network security.

[0027] The present application describes a method for verifying vulnerabilities in power industrial control systems, which addresses the technical shortcomings of existing technologies, such as low simulation fidelity, high testing risk, lack of virtual-real closed-loop verification, and inability to quantify the impact of attacks.

[0028] Please refer to Figure 1 As shown, the method for verifying vulnerabilities in a power industrial control system according to this application includes: S101. Construct a firmware-level simulation model, wherein the firmware-level simulation model runs the real firmware of the physical industrial control equipment in a virtualized environment.

[0029] A firmware-level simulation model refers to a software copy of the firmware of a real device running based on virtualization technology.

[0030] In its implementation, the firmware-level simulation model is an industrial control equipment simulation model that runs real PLC / RTU firmware based on QEMU virtualization technology. Building this model is fundamental for high-fidelity simulation, as it needs to be able to replicate the underlying behavior of real industrial control equipment.

[0031] Specifically, a five-layer hybrid twin simulation architecture needs to be built, which includes an application presentation layer, a student interaction layer, a simulation model layer, a physical entity layer, and a security layer to support the entire verification process.

[0032] In the application presentation layer, based on Web visualization and Unity's refined modeling technology, it supports drag-and-drop scene construction for all aspects of power generation, transmission, transformation, distribution, and consumption, and provides a three-layer dynamic display of business view, physical simulation view, and power flow view.

[0033] In the Lisheng interaction layer, as the core hub for virtual and physical collaboration, a unified API is used to realize the full lifecycle management of virtual resources, physical devices, and simulation models, and supports data acquisition and command issuance for industrial control protocols such as SSH, MODBUS, IEC104, and OPCUA.

[0034] An encrypted and isolated network is built based on SD-LAN, VXLAN, and IPsecVPN to achieve physical isolation between the test environment and the production network, thereby ensuring secure remote testing and forming an isolated test environment.

[0035] At the simulation model layer, in addition to building a firmware virtual simulation model of physical industrial control equipment based on QEMU, a power system simulation model and a communication network simulation model are also integrated to cover full-stack simulation. The power system simulation model is based on PandaPower and PSCAD to build mathematical models of generators, lines, and loads, used to accurately simulate electromagnetic transients and electromechanical transient physical processes. The communication network simulation model is based on the SGAM architecture and NetworkX to build a full-link communication network, used to simulate industrial control protocols such as IEC61850 and IEC104.

[0036] At the physical entity layer, a test closed loop consisting of real industrial control hardware is deployed, including a physical wind turbine PLC, a micro wind power physical model, relay protection devices, industrial switches, and ADC / DAC signal interface devices. The interface devices enable bidirectional conversion between the electrical signals of the simulation model and the state variables of the physical devices.

[0037] The security layer provides unified security services throughout the entire architecture, integrating identity authentication, operation auditing, vulnerability databases, and attack knowledge bases.

[0038] The five-layer hybrid twin simulation architecture ensures that the subsequent testing process is physically isolated from the real production network, eliminating the risk of equipment damage or power grid disturbance. Its purpose is to solve the technical bottlenecks of pure physical testing schemes, such as high equipment cost, long deployment cycle, and security risks, as well as pure digital simulation schemes, such as high false alarm rate of vulnerability verification results due to model distortion.

[0039] The process of building a firmware-level simulation model combines Ghidra reverse engineering to achieve binary-level behavioral simulation, which can semi-automatically complete firmware extraction, taint analysis and vulnerability location, thereby solving the problem of missed detections in traditional testing.

[0040] S102. Obtain the attack payload against the firmware-level simulation model.

[0041] An attack payload is a specific sequence of data or instructions that can trigger potential security vulnerabilities in industrial control equipment and cause it to produce abnormal or predetermined behaviors.

[0042] Obtaining the attack payload is a crucial step in vulnerability discovery.

[0043] Specifically, fuzz testing or reverse engineering using tools like Ghidra can be performed on pre-built virtual PLC models or other firmware-level simulation models to discover potential vulnerabilities such as remote command execution in an automated or semi-automated manner.

[0044] Fuzzing is a method of discovering vulnerabilities by inputting a large amount of random or mutated unexpected data into a target program to trigger its crash or anomaly.

[0045] Once a suspected vulnerability is discovered in the virtual model, a specific attack payload needs to be constructed to target that vulnerability, such as a malicious instruction sequence that could cause the target PLC to shut down. This step is completed in a virtual environment, allowing for safe and repeated vulnerability discovery and attack simulation without concern for damage to real physical equipment. This solves the problem of automated vulnerability discovery tools such as SAST / DAST and fuzzing lacking a closed-loop verification mechanism for vulnerability validity in power scenarios.

[0046] Impact analysis is performed on discovered vulnerabilities in a virtual environment, assessing the impact on the system should the attack payload be successfully triggered. Physical injection is only performed if the analysis determines that the attack payload or model will not cause damage or irreparable harm to physical devices; otherwise, the attack payload or model is patched in the virtual environment until its impact is manageable.

[0047] S103. In an isolated test environment, the attack payload is injected into the firmware-level simulation model and the corresponding physical industrial control equipment, respectively.

[0048] An isolated test environment refers to a test network that is completely separated from the real production network through technical means, such as an encrypted isolated network built using SD-LAN, VXLAN, or IPsec VPN.

[0049] Injection refers to the process of sending attack payload data to the target device. It is a core step connecting virtual and physical verification, aiming to perform reverse verification to confirm the validity of the vulnerability with zero risk. In specific implementation, through the secure access device of the industrial test scenario in the Li Sheng interaction layer, the attack payload constructed in the previous step is sent simultaneously or sequentially to the virtual PLC, which serves as the firmware-level simulation model, and its corresponding physical fan PLC, via a pre-configured secure channel. The injection process is completely isolated from the production network, ensuring the security of the test and eliminating the security risks of equipment downtime and power grid disturbances that exist when conducting penetration testing directly on real devices.

[0050] Injecting attack payloads into virtual models is to predict the attack's effect, while injecting them into physical devices is to verify whether the effect actually occurs, thus completing a closed-loop verification from virtual to physical.

[0051] Perform forward model calibration.

[0052] Forward model calibration is used to ensure that the virtual model replicates the behavior of the real device one-to-one. It is an important preliminary step to improve the verification fidelity and eliminate model distortion. It belongs to the forward verification closed-loop stage in the virtual-real two-way mutual verification.

[0053] Calibration includes static parameter calibration and dynamic response comparison.

[0054] Static parameter calibration refers to importing all static information of the physical device, such as hardware configuration, firmware version, network parameters, and register parameters, into the virtual model to complete the alignment of basic information.

[0055] Dynamic response comparison refers to inputting the same standard signal or standardized test signal sequence, such as Modbus standard commands, into physical and virtual devices in an isolated environment, and then comparing the timing and numerical consistency of the control commands and communication messages generated by the two.

[0056] The above process establishes a baseline response state for virtual and physical devices under the same input, providing an accurate reference baseline for subsequent behavior comparison under attack payloads.

[0057] Protocol consistency testing is also required, which involves verifying the completeness and accuracy of the virtual device protocol stack simulation based on the network interaction messages of the physical devices. If deviations are found during the calibration process, the system will automatically trigger a model optimization process to continuously correct the model, ensuring consistency between the model behavior and the physical entities, and achieving a simulation fidelity of over 99%. This addresses the issue of high false positive rates in vulnerability verification results due to model distortion.

[0058] S104. Obtain the first behavior data of the firmware-level simulation model under the attack load, and the second behavior data of the physical industrial control device under the attack load.

[0059] The first and second rows of data record the operating status, output response, and abnormal behavior of the virtual model and physical device after being affected by the attack payload, respectively.

[0060] Behavioral data is the direct basis for determining whether a vulnerability has been successfully triggered and what impact the attack has. Specifically, after the attack payload is applied to the target, data needs to be observed and collected in real time.

[0061] For firmware-level simulation models, their internal process states, register values, and output network packets can be collected as the first line of data.

[0062] For physical industrial control equipment, the actual behavior of the equipment, such as process crashes, logic anomalies, or shutdowns, is collected through sensors, logging systems, or monitoring software as secondary behavioral data.

[0063] Data is recorded in real time and transmitted to the processing center for subsequent analysis and comparison. The network attack path, device operating status, and vulnerability triggering process are visualized in real time through the application presentation layer. Behavioral data acquisition is based on a baseline state established using previously defined standardized test signal sequences, ensuring consistent starting conditions for data collection and improving the reliability of the comparison.

[0064] S105. Compare the first behavioral data with the second behavioral data to determine the behavioral deviation.

[0065] Behavioral deviation refers to the inconsistency in the behavior of virtual models and physical entities under the same attack load in a specific dimension.

[0066] Identifying the biases is crucial for determining whether a model needs optimization and whether the vulnerability verification results are valid. The comparison process requires meticulous analysis from multiple dimensions.

[0067] One dimension of comparison is the comparison of instruction execution timing sequences. Instruction execution timing sequences record the temporal order and intervals at which the device processes instructions. By comparing the instruction execution timing sequences recorded in the first line of data with those recorded in the second line of data, it can be determined whether there are differences in their time response characteristics; this difference is called timing-related behavioral bias.

[0068] For example, a virtual model may respond to an interruption faster or slower than a physical device.

[0069] Another dimension of comparison involves comparing the read / write state sequences of peripheral registers. These sequences reflect the data changes during the interaction between the device and external hardware. By comparing the read / write state sequences of peripheral registers recorded in the first and second rows of data, it can be determined whether there are differences in their data interaction states; this difference is called state-based behavioral deviation.

[0070] For example, an attack payload might cause a flag bit in a register to be set on the physical device but not in the virtual model.

[0071] Through systematic comparison, specific behavioral points where the virtual model and the physical entity are inconsistent can be accurately identified. This comparison and calibration process constitutes a closed-loop verification of results. If the results are consistent, the vulnerability is confirmed to be real and valid; if they are inconsistent, optimization of the virtual model is triggered, forming a continuous iterative closed loop. This quickly eliminates false positives in automated testing and improves the efficiency of vulnerability verification.

[0072] S106. When the behavior deviation exists, based on the attributes of the behavior deviation, locate at least one hardware abstraction component in the firmware-level simulation model that causes the behavior deviation, wherein the hardware abstraction component is a software module that simulates the functions of a physical chip or peripheral device.

[0073] Hardware abstraction components are the foundational software modules that make up a virtualized simulation model; each module simulates a specific physical hardware function. Identifying problem components is a prerequisite for targeted model optimization.

[0074] Based on the attributes of the behavioral deviations identified in the previous step, the types of potentially erroneous hardware abstraction components in the model can be inferred and precisely located. When timing-related behavioral deviations are identified, these deviations are typically related to inconsistencies in processor scheduling, clocking, or timing-related functions. Therefore, it is necessary to locate the CPU virtual core or timer virtual module in the firmware-level simulation model.

[0075] The CPU virtual core is the core module that simulates the execution of instructions and calculations by a physical CPU; its simulation cycle parameters directly affect the instruction execution speed. The timer virtual module is a module that simulates the function of a physical timer or counter; its time base parameters determine the timing accuracy.

[0076] When a state-related behavioral deviation is identified, this deviation is typically related to the interface control logic of a specific external device. Therefore, it is necessary to locate the peripheral interface controller virtual module in the firmware-level simulation model that corresponds to the peripheral register. The peripheral interface controller virtual module is a software module that simulates specific hardware interfaces such as GPIO, UART, and ADC, and is responsible for handling read and write operations on that peripheral. The location process can be accomplished by analyzing the program execution flow and hardware access logs at the time the deviation occurs.

[0077] S107. Repair the located hardware abstraction component.

[0078] Patching refers to modifying or adjusting the internal parameters or logic of a hardware abstraction module to eliminate behavioral differences between it and the real physical hardware, thereby optimizing the fidelity of the entire firmware-level simulation model.

[0079] Patching is a key operation for continuous iterative optimization of the model to approximate the real device.

[0080] The specific repair procedures vary depending on the type of hardware abstraction component identified. When the hardware abstraction component is identified as a CPU virtual core, the instruction emulation cycle parameters of the CPU virtual core need to be adjusted.

[0081] The instruction simulation cycle parameter defines the time period that the virtual CPU takes to execute one instruction. Adjusting this parameter can correct the execution speed of the virtual CPU relative to the physical CPU, thereby eliminating timing-related deviations.

[0082] When the hardware abstraction component is positioned as a timer virtual module, the time base parameter of the timer virtual module needs to be corrected. The time base parameter is the basic time unit for timer timing; correcting this parameter ensures that the timing frequency and accuracy of the virtual timer are consistent with the physical timer.

[0083] This targeted patching allows the behavior of the firmware-level simulation model to closely match the behavior of physical industrial control equipment when it is attacked, thereby ensuring that the conclusions of vulnerability discovery and impact analysis based on the model are true and reliable.

[0084] After completing vulnerability verification and model optimization, an impact quantification assessment can be conducted.

[0085] Impact quantification assessment refers to using simulation models to quantitatively analyze the potential physical and economic consequences of a verified vulnerability once exploited, thereby quantifying the impact chain of a cyberattack penetrating from cyberspace to the physical power grid. Specifically, the simulation model collects data on the physical processes affected by the attack in real time. For example, in the case of wind turbine PLC shutdown, the power system simulation model accurately simulates the electromagnetic and electromechanical transient physical processes, quantifies and calculates key physical quantities such as power flow, voltage, and frequency, and then collects data on wind power output reduction and grid voltage fluctuations. This quantitatively assesses the economic losses and grid operation risks caused by the vulnerability triggering, and generates a detailed verification report that visually presents the cross-space transmission chain of the attack from bits to electrical energy, providing data support for optimizing protection strategies.

[0086] Perform closed-loop archiving of vulnerabilities.

[0087] Vulnerability closed-loop archiving refers to the standardized organization and storage of the complete verification process, results, and impact assessment data. Specifically, vulnerability verification results, attack impact data, and other information are synchronized to the industrial control distributed crowdsourcing testing platform or local vulnerability and attack knowledge bases to complete the complete closed loop from vulnerability discovery, verification, to archiving. This provides data support for subsequent security protection and strategy optimization and adapts to large-scale security testing scenarios.

[0088] Please refer to Figure 2 As shown, this application also provides a vulnerability verification device for a power industrial control system, comprising: Model module 201 constructs a firmware-level simulation model, which runs the real firmware of physical industrial control equipment in a virtualized environment; The payload module 202 acquires the attack payload against the firmware-level simulation model; Test module 203 injects the attack payload into the firmware-level simulation model and the corresponding physical industrial control equipment in an isolated test environment; Data module 204 acquires the first behavior data of the firmware-level simulation model under the attack load, and the second behavior data of the physical industrial control device under the attack load; The comparison module 205 compares the first behavioral data with the second behavioral data to determine the behavioral deviation; The determination module 206, when the behavior deviation exists, locates at least one hardware abstraction component in the firmware-level simulation model that causes the behavior deviation based on the attributes of the behavior deviation. The hardware abstraction component is a software module that simulates the functions of a physical chip or peripheral device. The optimization module 207 repairs the identified hardware abstraction components.

[0089] Furthermore, the data module 204 acquires the first behavioral data of the firmware-level simulation model under the attack payload, and the second behavioral data of the physical industrial control device under the attack payload, including: Before injecting the attack payload, the same standardized test signal sequence is injected into the firmware-level simulation model and the physical industrial control equipment; Based on the state established by the standardized test signal sequence, the first behavioral data and the second behavioral data are obtained.

[0090] Furthermore, the comparison module 205 compares the first behavioral data with the second behavioral data to determine the behavioral deviation, including: The timing sequence of instruction execution recorded in the first behavior data and the second behavior data is compared to determine the timing-type behavior deviation.

[0091] Furthermore, the comparison module 205 compares the first behavioral data with the second behavioral data to determine the behavioral deviation, including: Compare the read / write state sequences of peripheral registers recorded in the first and second behavior data to determine the state-type behavior deviation.

[0092] Furthermore, the determining module 206 locates at least one hardware abstraction component in the firmware-level simulation model that causes the behavioral deviation based on the attributes of the behavioral deviation, including: When the attribute of the behavior deviation is a timing-type behavior deviation, locate the CPU virtual core or timer virtual module in the firmware-level simulation model.

[0093] Furthermore, the determining module 206 locates at least one hardware abstraction component in the firmware-level simulation model that causes the behavioral deviation based on the attributes of the behavioral deviation, including: When the attribute of the behavior deviation is a state-type behavior deviation, locate the virtual module of the peripheral interface controller corresponding to the peripheral register in the firmware-level simulation model.

[0094] Furthermore, the optimization module 207 repairs the located hardware abstraction component, including: When the hardware abstraction component is a central processing unit (CPU) virtual core, adjust the instruction simulation cycle parameters of the CPU virtual core; When the hardware abstraction component is a timer virtual module, the time base parameters of the timer virtual module are corrected.

[0095] This application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0096] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the above-described method.

[0097] The above embodiments are provided to enable those skilled in the art to understand and apply this application. Those skilled in the art will readily make various modifications to the above embodiments and apply the general principles described herein to other embodiments without inventive effort. Therefore, this application is not limited to the above embodiments, and any improvements and modifications made to this application based on the disclosure thereof should be within the scope of protection of this application.

Claims

1. A method for verifying vulnerabilities in a power industrial control system, characterized in that, include: Construct a firmware-level simulation model, which runs the real firmware of physical industrial control equipment in a virtual environment; Obtain the attack payload targeting the firmware-level simulation model; In an isolated test environment, the attack payload is injected into the firmware-level simulation model and the corresponding physical industrial control equipment, respectively. Acquire the first behavioral data of the firmware-level simulation model under the attack payload, and the second behavioral data of the physical industrial control device under the attack payload; By comparing the first behavioral data with the second behavioral data, behavioral deviations can be determined. When the behavioral deviation exists, based on the attributes of the behavioral deviation, at least one hardware abstraction component in the firmware-level simulation model that causes the behavioral deviation is located, and the hardware abstraction component is a software module that simulates the functions of a physical chip or peripheral device. Repair the identified hardware abstraction components.

2. The method according to claim 1, characterized in that, Acquiring the first behavioral data of the firmware-level simulation model under the attack payload, and the second behavioral data of the physical industrial control device under the attack payload, including: Before injecting the attack payload, the same standardized test signal sequence is injected into the firmware-level simulation model and the physical industrial control equipment; Based on the state established by the standardized test signal sequence, the first behavioral data and the second behavioral data are obtained.

3. The method according to claim 1, characterized in that, By comparing the first behavioral data with the second behavioral data, behavioral deviations are determined, including: The timing sequence of instruction execution recorded in the first behavior data and the second behavior data is compared to determine the timing-type behavior deviation.

4. The method according to claim 1, characterized in that, By comparing the first behavioral data with the second behavioral data, behavioral deviations are determined, including: Compare the read / write state sequences of peripheral registers recorded in the first and second behavior data to determine the state-type behavior deviation.

5. The method according to claim 1, characterized in that, Based on the attributes of the behavioral deviation, locate at least one hardware abstraction component in the firmware-level simulation model that causes the behavioral deviation, including: When the attribute of the behavior deviation is a timing-type behavior deviation, locate the CPU virtual core or timer virtual module in the firmware-level simulation model.

6. The method according to claim 1, characterized in that, Based on the attributes of the behavioral deviation, locate at least one hardware abstraction component in the firmware-level simulation model that causes the behavioral deviation, including: When the attribute of the behavior deviation is a state-type behavior deviation, locate the virtual module of the peripheral interface controller corresponding to the peripheral register in the firmware-level simulation model.

7. The method according to claim 1, characterized in that, Repairing the identified hardware abstraction components includes: When the hardware abstraction component is a central processing unit (CPU) virtual core, adjust the instruction simulation cycle parameters of the CPU virtual core; When the hardware abstraction component is a timer virtual module, the time base parameters of the timer virtual module are corrected.

8. A vulnerability verification device for a power industrial control system, characterized in that, include: The model module constructs a firmware-level simulation model, which runs the real firmware of the physical industrial control equipment in a virtual environment. The payload module acquires attack payloads targeting the firmware-level simulation model. The testing module injects the attack payload into the firmware-level simulation model and the corresponding physical industrial control equipment in an isolated testing environment. The data module acquires the first behavioral data of the firmware-level simulation model under the attack payload, and the second behavioral data of the physical industrial control device under the attack payload; The comparison module compares the first behavioral data with the second behavioral data to determine the behavioral deviation; The determination module, when the behavior deviation exists, locates at least one hardware abstraction component in the firmware-level simulation model that causes the behavior deviation based on the attributes of the behavior deviation. The hardware abstraction component is a software module that simulates the functions of a physical chip or peripheral device. The optimization module repairs the identified hardware abstraction components.

9. The apparatus according to claim 8, characterized in that, The data module acquires the first behavioral data of the firmware-level simulation model under the attack payload, and the second behavioral data of the physical industrial control device under the attack payload, including: Before injecting the attack payload, the same standardized test signal sequence is injected into the firmware-level simulation model and the physical industrial control equipment; Based on the state established by the standardized test signal sequence, the first behavioral data and the second behavioral data are obtained.

10. The apparatus according to claim 8, characterized in that, The comparison module compares the first behavioral data with the second behavioral data to determine the behavioral deviation, including: The timing sequence of instruction execution recorded in the first behavior data and the second behavior data is compared to determine the timing-type behavior deviation.

11. The apparatus according to claim 8, characterized in that, The comparison module compares the first behavioral data with the second behavioral data to determine the behavioral deviation, including: Compare the read / write state sequences of peripheral registers recorded in the first and second behavior data to determine the state-type behavior deviation.

12. The apparatus according to claim 8, characterized in that, The determining module locates at least one hardware abstraction component in the firmware-level simulation model that causes the behavioral deviation based on the attributes of the behavioral deviation, including: When the attribute of the behavior deviation is a timing-type behavior deviation, locate the CPU virtual core or timer virtual module in the firmware-level simulation model.

13. The apparatus according to claim 8, characterized in that, The determining module locates at least one hardware abstraction component in the firmware-level simulation model that causes the behavioral deviation based on the attributes of the behavioral deviation, including: When the attribute of the behavior deviation is a state-type behavior deviation, locate the virtual module of the peripheral interface controller corresponding to the peripheral register in the firmware-level simulation model.

14. The apparatus according to claim 8, characterized in that, The optimization module repairs the located hardware abstraction components, including: When the hardware abstraction component is a central processing unit (CPU) virtual core, adjust the instruction simulation cycle parameters of the CPU virtual core; When the hardware abstraction component is a timer virtual module, the time base parameters of the timer virtual module are corrected.

15. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement any one of the methods described in claims 1 to 7.

16. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed in a computer, causes the computer to perform any one of the methods described in claims 1 to 7.

Images