A blockchain-enhanced power network security simulation method

Abstract

The application relates to the field of power network security, in particular to a blockchain-enhanced power network security simulation method.The method comprises the following steps: acquiring power network topology data and an attack event library, performing topology mapping and entry screening, generating an attack injection list and performing target topology adaptation; collecting and checking simulation response data, performing baseline comparison and error calculation based on the response data, generating a vulnerability evidence graph, performing risk assessment and vulnerability priority sorting, and generating an evidence report; writing the vulnerability evidence report back to the blockchain event library, generating security improvement suggestions and verification tasks, starting the re-verification task and generating the next round of simulation plan.The application improves the accuracy and reliability of the power network security simulation through the automatic management based on the blockchain technology and the smart contract, realizes the accurate injection and traceability of the attack events, optimizes the vulnerability detection and repair process, and improves the network security protection capability.

Description

Technical Field

[0001] This invention relates to the field of power network security, and in particular to a blockchain-enhanced power network security simulation method. Background Technology

[0002] In the field of power network security, existing solutions typically rely on traditional simulation platforms to conduct network security testing by constructing power network topology models and combining them with attack event databases. However, existing methods suffer from insufficient transparency and security in data storage; data in the attack event database is easily tampered with or lost, resulting in poor traceability of attack events. Furthermore, traditional simulation methods often fail to accurately adapt to the actual power network topology, making it difficult to simulate real-world attack scenarios, especially in complex network environments where attack injection is often inaccurate or ineffective. Existing methods largely depend on manually configuring the mapping between attack events and target devices, which has significant limitations in dynamic adjustment and real-time adaptability, leading to a lack of accuracy and reliability in simulation results. In this context, the temporal sequence and triggering conditions of attack vectors are also difficult to control effectively, lacking automated management mechanisms. For the joint processing of power network topology data and attack event databases, existing technologies generally face shortcomings such as inaccurate execution of the injection process, incomplete verification of response data, and unscientific vulnerability prioritization. This makes it difficult to establish a continuous and reliable simulation and evaluation process from attack injection to vulnerability remediation in a real power network environment, resulting in simulation results that cannot effectively guide actual security protection measures. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention provides a blockchain-enhanced power network security simulation method, comprising:

[0004] The system acquires power network topology data and an attack event database. Based on preset attack events and their characteristics in the blockchain-based attack event database, it performs topology mapping and entry filtering. It then uses smart contracts to verify attack targets and adapt to the topology, generating a contract injection list. The power network topology data includes buses, substations, lines, protection devices, and communication links. The attack event database contains attack types, attack targets, and triggering conditions.

[0005] Based on the attack injection list and session ID, time window locking and injection sequence arrangement are performed to generate attack execution data packets, perform real-time injection and receipt collection, record simulation response logs, and perform self-consistency verification to check timestamp alignment and response behavior deviations, thus obtaining a preliminary response dataset.

[0006] The response deviation and key device indicators are extracted from the initial response dataset, and baseline comparison and error calculation are performed based on on-chain historical data benchmarks to generate a vulnerability evidence graph. Then, dynamic risk assessment and vulnerability priority ranking based on historical data and response differences are performed to generate the final vulnerability security report.

[0007] Based on the final vulnerability security report, the blockchain event database is written back through smart contracts to update vulnerability records and risk assessment scores, and policy linkage processing is executed to generate security improvement suggestions and build a verification task write-back.

[0008] Furthermore, the attack injection manifest and session IDs include:

[0009] The attack injection list includes attack vector ID, attack vector type, target device, trigger timing policy, adaptation information based on power network topology, and injection policy structure constructed for each attack event; the session ID includes attack injection list version, time window locking parameters, injection sequence arrangement, and simulation environment snapshot.

[0010] Furthermore, response deviation and key equipment indicators include:

[0011] Response deviations include deviations in the triggering state of equipment safety mechanisms, deviations in the functional state of equipment, and deviations in response timing; key equipment indicators include time-dimensional indicators, electrical characteristic indicators, line load fluctuations, and system stability indicators.

[0012] Furthermore, the process of acquiring power network topology data and an attack event database, and performing topology mapping and entry filtering based on preset attack events and their characteristics in the blockchain-based attack event database, also includes:

[0013] Obtain power network topology data;

[0014] The information is matched with entries in the attack event database to filter out attack vectors that match the current network environment;

[0015] The selected entries and topology mappings will be input as the contract injection manifest.

[0016] Furthermore, the process of verifying attack targets and adapting topology through smart contracts also includes:

[0017] Extract the attack vector ID and corresponding timing triggering strategy from the attack event database;

[0018] By checking the matching between the target device and the attack vector, it is determined whether the attack can be executed on the specified bus, line or protection device, ensuring that the attack vector can accurately penetrate the target device;

[0019] If the target device or network component is not suitable for receiving a certain attack event, it will be automatically replaced and updated in the contract injection list.

[0020] Furthermore, the process of generating attack execution packets based on the attack injection list and session ID, including time window locking and injection sequence arrangement, also includes:

[0021] After the attack injection entries are generated, the entries are sorted and categorized, and the final injection list is generated through the contract system.

[0022] Based on the complexity and execution difficulty of the attack vector, an appropriate injection strategy structure is constructed for each attack event. The strategy structure specifies how to initiate the attack, how to execute the attack step by step in the simulation environment, and how to dynamically adjust the injection strength and execution order during the attack process.

[0023] Furthermore, the process of extracting response deviations and key device indicators from the initial response dataset, and performing baseline comparison and error calculation based on on-chain historical data benchmarks to generate a vulnerability evidence graph also includes:

[0024] The response deviation is extracted based on preset standards or historical records, whereby the standards include the expected response of the device when facing a specific attack.

[0025] Key metrics were extracted, including equipment response time, voltage variation range, and load fluctuation.

[0026] The extracted response deviation is compared with historical data benchmarks, and the benchmark data is stored on the chain as a known normal operating mode.

[0027] A vulnerability evidence graph is generated based on an error calculation method. The vulnerability evidence graph includes each attack event and its impact on the device.

[0028] Furthermore, the process of performing dynamic risk assessment and vulnerability prioritization based on historical data and response discrepancies also includes:

[0029] Retrieve historical response data from the blockchain, including the device's behavior when it encountered similar attacks in the past;

[0030] Assess the potential impact of attacks on devices and the severity of different attacks based on historical data;

[0031] Based on the differences in response, and combined with a preset risk assessment algorithm, the priority of each vulnerability is calculated. Vulnerabilities with higher priority are marked as more urgent and serious security risks.

[0032] Furthermore, the process of generating the final vulnerability security report also includes:

[0033] Verify and analyze the vulnerability evidence diagrams in detail to confirm whether each vulnerability evidence has sufficient supporting evidence;

[0034] Based on the type of vulnerability, the severity of the attack, and historical data, conduct in-depth analysis to determine which vulnerabilities have a larger attack surface or potential cascading effects, and mark them as high-priority vulnerabilities.

[0035] Generate a complete vulnerability security report, which includes the analysis results of all vulnerabilities, confirmed evidence, and remediation recommendations.

[0036] Furthermore, based on the final vulnerability security report, the process of writing back the blockchain event database via smart contracts, updating vulnerability records and risk assessment scores, and executing coordinated policy actions to generate security improvement recommendations also includes:

[0037] By writing back the blockchain event database through smart contracts, vulnerability records and risk assessment scores are updated.

[0038] The execution strategy is linked to generate security improvement suggestions and build a verification task write-back.

[0039] The key innovations of this invention include:

[0040] (1) This invention manages the attack event database using blockchain technology, enabling the recording and tracking of attack events throughout their entire lifecycle. Unlike traditional static storage methods, this invention stores each piece of data from an attack event (including attack sequence, triggering conditions, etc.) on the blockchain in an immutable manner, ensuring the transparency and security of the event data. Simultaneously, by combining the topology information of the power network, attack events can be accurately mapped to target devices and paths, achieving dynamic adaptation of attack events.

[0041] (2) This invention automatically generates attack injection strategies through smart contracts and controls the timing and triggering conditions of attack events. The smart contract not only drives the injection of attack events, but also records the execution process and results of each attack in real time, providing detailed on-chain evidence for subsequent auditing and analysis.

[0042] (3) This invention employs self-consistency verification technology to comprehensively verify the simulation response data, ensuring time alignment, event consistency, and logical consistency, and identifying potential vulnerabilities. In addition, by combining historical data with the differences in real-time responses, the system can perform dynamic risk assessment and vulnerability priority ranking, thereby accurately identifying and addressing the most critical security vulnerabilities.

[0043] The following are its main beneficial effects:

[0044] (1) By using blockchain-based attack event database management and topology adaptation, the traceability and immutability of attack events can be ensured, the accuracy and real-time performance of attack event injection can be improved, and the problems of data tampering and information loss in traditional storage methods can be avoided. This method provides higher transparency and reliability for the security simulation of power networks, and enhances the adaptability of attack events and the ability to simulate attacks in network environments.

[0045] (2) Smart contract-driven attack vector injection and automated control greatly reduce interference from human operation and improve the accuracy and consistency of attack injection. This method can achieve complete automation and recording of the attack injection process, providing more credible evidence for simulation results and ensuring the reproducibility and auditability of each attack. In this way, the flexibility and security of the power network simulation process are significantly improved.

[0046] (3) Through self-consistency verification and dynamic risk assessment, this invention can effectively discover and correct minor differences and vulnerabilities that are difficult to identify by traditional methods, thereby improving the accuracy of vulnerability detection and repair. At the same time, the dynamic risk assessment mechanism combines historical data with real-time response differences, making the vulnerability priority ranking more scientific, ensuring that the most critical vulnerabilities can be dealt with first, thereby improving the overall security and emergency response capability of the system. Attached Figure Description

[0047] Figure 1 This is a flowchart illustrating a blockchain-enhanced power network security simulation method provided in an embodiment of this application. Detailed Implementation

[0048] Example 1: Refer to Figure 1 This is a flowchart illustrating a blockchain-enhanced power network security simulation method provided in an embodiment of the present invention. The process may include at least steps S100-S400:

[0049] S100: Obtain power network topology data and attack event database; perform topology mapping and entry filtering based on preset attack events and their characteristics in the blockchain attack event database; verify attack targets and adapt topology through smart contracts; and generate a contract injection list.

[0050] S200: Based on the attack injection list and session ID, time window locking and injection sequence arrangement are performed to generate attack execution data packets, real-time injection and receipt collection are performed, simulation response logs are recorded, and self-consistency verification is performed to check timestamp alignment and response behavior deviations, thus obtaining a preliminary response dataset.

[0051] S300: Extract response deviation and key device indicators from the initial response dataset, perform baseline comparison and error calculation based on on-chain historical data benchmark, generate vulnerability evidence graph, and then perform dynamic risk assessment and vulnerability priority ranking based on historical data and response differences to generate the final vulnerability security report.

[0052] S400, based on the final vulnerability security report, writes back to the blockchain event database through smart contracts, updates vulnerability records and risk assessment scores, and executes policy linkage processing to generate security improvement suggestions, and constructs a verification task write-back.

[0053] Step S100 includes at least steps S110-S130:

[0054] S110. Obtain power network topology data and attack event database, perform topology mapping and entry filtering processing, and obtain contract injection list and target topology adaptation;

[0055] Specifically, power network topology data is acquired as input, including configuration and status information of components such as buses, substations, lines, protection devices, and communication links. This information is matched against entries in an attack event database to filter out attack vectors that match the current network environment. The attack event database contains a series of preset attack events and their characteristics (such as attack type, attack target, triggering conditions, etc.). During the filtering process, the system verifies the compatibility between the target device's topology and the attack vector to ensure that the injected attack event can accurately locate the target device or communication link. All filtered entries and topology mappings are input as a contract injection list into the subsequent attack injection process. Furthermore, during the topology mapping stage, the association between all devices and attack entries is recorded and used to generate a target topology adaptation scheme. The output of this process is the generated contract injection list, which includes information on the compatibility of all selected attack vectors with the target topology, and is used as input for subsequent steps. The output field is named "Contract Injection List," and the next input position is the attack vector extraction and target verification in S120.

[0056] S120. Extract the attack vector ID and timing triggering strategy from the attack event database, perform attack target verification and topology adaptation, and generate attack injection entries.

[0057] Furthermore, attack vector IDs and corresponding timing triggering policies are extracted from the attack event database. Each attack vector ID corresponds to a specific attack method, such as network traffic hijacking, DDoS attacks, virtual machine escape, etc., and defines the timing conditions for attack triggering, such as the specific network state or communication mode at the time of attack initiation. The system will adapt and verify the topology based on this information to ensure that the attack vector can be effectively triggered in the current topology. Specifically, by checking the matching between the target device and the attack vector, such as determining whether the attack can be executed on a specified bus, line, or protection device, the system ensures that the attack vector can accurately penetrate the target device. If the target device or network component is not suitable for receiving a certain attack event, the system will automatically replace it and update it in the contract injection list. After the attack target is verified, the system will generate a final attack injection entry, which contains the attack vector ID, triggering policy, target device, and its topology adaptation information. This entry will be used for subsequent attack injection execution. The output field is named "Attack Injection Entry," and the next input position is the injection list generation and policy construction in S130.

[0058] S130. Generate an injection list from the attack event database and construct an attack injection list;

[0059] Specifically, after the attack injection entries are generated, they will be organized and categorized, and a final injection list will be generated through the contract system. This list contains all verified attack events and their corresponding triggering sequences, target devices, attack vector types, and other information. Furthermore, an appropriate injection strategy structure needs to be constructed for each attack event based on the complexity and execution difficulty of the attack vector. These strategy structures specify how to initiate the attack, how to execute the attack step-by-step in the simulation environment, and how to dynamically adjust the injection strength and execution order during the attack. To improve the reliability of the simulation process, all generated attack injection lists will be automatically managed through smart contracts, ensuring that the execution of each attack event conforms to preset timing conditions and security requirements. Finally, all constructed attack injection lists will be sent back to the simulation system along with the contract injection list, ready for the next stage of attack injection and simulation execution. The output field is named "Attack Injection List," and the next input position is the generation of the attack injection data packet in S210.

[0060] In summary, the technical effects of this step are as follows: Through steps S110 to S130, this invention generates a precise attack injection list and strategy structure by combining power network topology data with entries in the attack event database. This ensures a high degree of matching and adaptability between attack events and target devices, provides an automated attack injection process based on smart contract management, and offers clear data input and operational guidance for subsequent simulation execution.

[0061] In one embodiment, configuration and status information of buses, substations, lines, protection devices, and communication links are obtained from power network topology data, and preset attack events and their characteristics (such as attack type, attack target, triggering conditions, etc.) are obtained from an attack event database as input. The system performs topology mapping and entry filtering. Formula ① is used to calculate the matching score between each attack event and the topology. Let The number of attack events, derived from the number of entries in the attack event database. The number of devices, derived from power network topology data. For each attack event. ( ), whose target type set is Events originating from the attack event database The characteristics of the attack target. For each device ( ), its type is Devices derived from power network topology data Type configuration. Attack event. Matching score Defined as:

[0062]

[0063] in, It is an indicator function; its value is 1 when the condition is true, and 0 otherwise. The number of devices; The value range is [0,1], representing an attack event. The degree of adaptation to the topology; : Index of attack events; : The device index; : The type of device j; : The set of target types for attack event i.

[0064] Data source mapping: The attack target type is extracted from the attack event database and denoted as... The device type is extracted from the power network topology data and recorded as follows: Together, they form the formula ① Formula ① It is used as an intermediate indicator in formula ②.

[0065] Formula ② applies soft maximum mapping to calculate the selection probability of each attack event. Used to filter entries:

[0066]

[0067] in, The probability of attack event i being selected; For temperature parameters; Exponential function; : Summation index.

[0068] Data source mapping: Formula ① As input, it is obtained through soft maximum mapping. The system is based on Choose events with higher probability (such as...) in The threshold is used to record topology mapping information and generate a contract injection list. The output field is named Contract Injection List, which includes the selected attack vector and target topology adaptation information, extracted by the attack vector of S120 and the target verification input.

[0069] Following the aforementioned contract injection list, the system retrieves selected attack events and extracts attack vector IDs and corresponding timing triggering strategies from the attack event database. Attack target verification and topology adaptation are then performed. Formula ③ is used to calculate the adaptation score between each attack event and the specific device. For each selected event... and each device (in ),make For the event The trigger condition value comes from events in the attack event database. Triggering conditions, For equipment The status values ​​are derived from the devices in the power network topology data. Status information. Fit score. Defined as the probability of a condition being met, using a logical function:

[0070]

[0071] in, : The fit score of attack event i on device j; For steep parameters; : The status value of device j; The trigger condition value for event i; Exponential function; and : i is the attack event index, j is the device index.

[0072] Data source mapping: The triggering conditions are extracted from the attack event database and recorded as... The device status is extracted from the power network topology data and recorded as... This forms formula ③. Formula ③ Used in formula ④.

[0073] Formula ④ selects the target device for each attack event by calculating the selection weight. Using soft maximum mapping:

[0074]

[0075] in, The selection weight of device j as the target of event i; For parameters; : Summation index.

[0076] Data source mapping: Formula ③ As input, it is obtained through soft maximum mapping. System Selection Largest equipment As an event The target device is used to generate an attack injection entry. The output field is named "Attack Injection Entry," which includes the attack vector ID, triggering policy, target device, and its topology adaptation information. It is used as input for the injection manifest generation and policy construction of S130.

[0077] Following the aforementioned attack injection entries, the system organizes and categorizes these entries, and generates a final injection list through the contract system. Formula ⑤ is used to construct the injection strength for each attack event. Let... For attack events The complexity score is derived from preset values ​​in the attack type mapping of the attack event database. Injection strength. Defined as:

[0078]

[0079] in, Complexity score of attack event i; : Injection strength of attack event i.

[0080] Data source mapping: Complexity scores are extracted from the attack event database and denoted as... This forms formula ⑤. Formula ⑤ Used in formula ⑥.

[0081] Formula 6 is used to determine the execution order of attack events by calculating priority scores. Let... For target equipment The criticality score is derived from the equipment criticality indicators in the power network topology data. Priority score:

[0082]

[0083] in, Priority score of attack event i; : Injection intensity from formula ⑤; The criticality score of device j is derived from the criticality indicators of the device based on the power network topology data.

[0084] Data source mapping: Formula ⑤ The criticality of equipment for power network topology data is denoted as This forms formula ⑥. The system is based on The system arranges events in sequence, constructs the injection strategy structure, and generates an attack injection list. The output field, named "Attack Injection List," includes information such as all verified attack events, their trigger sequence, target devices, and attack vector types. This list is generated from the attack injection data packets of the S210.

[0085] This section summarizes the technical effects: Through steps S110 to S130, the present invention achieves accurate mapping and adaptation between attack events and power network topology, and generates a traceable attack injection list based on blockchain and smart contracts, ensuring the reliability and automation of the simulation process.

[0086] Step S200 includes at least steps S210-S230:

[0087] S210. Obtain the attack injection list and session ID, lock the time window and arrange the injection sequence, and generate the attack execution data packet;

[0088] First, the attack injection list and corresponding session ID generated in step S130 are obtained as input. The attack injection list specifically includes all verified attack event entries generated in step S130 and their corresponding key information. Structurally, this list integrates the contract injection list output in step S110 and the attack injection entries generated in step S120. Its content specifically includes: attack vector ID, attack vector type (e.g., network traffic hijacking, DDoS attack, virtual machine escape, etc.), target device (e.g., specific bus, line, or protection device), trigger timing strategy, adaptation information based on power network topology, and information for each attack event. The constructed injection strategy structure (which specifies the attack initiation method, the step-by-step execution logic in the simulation environment, and the dynamic adjustment rules for injection strength and execution order) is used, and all list items are automatically managed through smart contracts to ensure that they meet the preset timing and security requirements. The session ID is an identifier used to uniquely identify the current simulation session. The associated data includes, but is not limited to, the attack injection list version corresponding to this simulation, time window locking parameters, injection sequence arrangement, and simulation environment snapshot. This ID ensures that all data and events from attack injection to receipt collection and even subsequent consistency verification can be accurately tracked and traced back.

[0089] Specifically, the attack injection list contains all attack events to be injected, their corresponding timing triggering strategies, and topology adaptation information. The session ID is used to identify the current simulation session, ensuring accurate tracking and backtracking of data and events during each simulation. Further, the system performs a time window locking operation based on the attack events in the attack injection list and simulation time window limitations. By setting a specific time window, the system ensures that attack events are triggered within a specified time range without time conflicts or errors. Next, the system arranges the order of attack injection according to the injection timing. Specifically, the purpose of the injection sequence arrangement is to ensure that attack events proceed in a reasonable sequence, thereby simulating a more realistic attack scenario. Finally, after time window locking and injection sequence arrangement, the system generates an attack execution data packet. This data packet contains the execution order of all injected events, the target device, the triggering timing, and the corresponding network parameters. The output field is named "Attack Execution Data Packet," which will be used for injection execution and real-time monitoring in subsequent step S220.

[0090] S220. Extract the attack target and injection timing from the attack execution data packet, perform real-time injection and receipt collection, and obtain the simulation response log.

[0091] Further, the system extracts attack target and injection timing information from the attack execution data packet generated in step S210. Specifically, the attack target refers to the device or network component within the system selected as the attack target, while the injection timing refers to the specific time sequence of the attack events. During this process, the system ensures that each attack target can receive injection according to the prescribed timing, ensuring the timing of the attack events and target compatibility. Subsequently, the system injects attack events in real time. Attack injection is executed through an injection module in the simulation environment, which can simulate various attack vectors, such as DDoS attacks and network traffic hijacking. During real-time injection, the system dynamically injects attack traffic or control signals according to the preset attack target and injection timing to detect the device's response. Simultaneously, the system also needs to collect feedback, recording the reactions of each device in the simulation environment, such as whether the device rejects the attack or malfunctions. All simulation response data will be recorded as a simulation response log. This log records in detail each step of the attack event and its impact on the system, providing important evidence for subsequent security assessment and vulnerability analysis. The output field is named "Simulation Response Log," which will undergo consistency verification and analysis in step S230.

[0092] S230. Perform self-consistency verification on the simulation response log and generate a preliminary response dataset;

[0093] After obtaining the simulation response logs, the system performs a self-consistency check on the logs. The purpose of the self-consistency check is to ensure that all collected response data is consistent in time and space and conforms to the expected attack pattern. First, the system checks whether all timestamps are accurately aligned, ensuring that each event in the log is consistent with the timing of its corresponding attack event. Second, the system compares the response of each device with its predetermined behavior pattern to detect any abnormal deviations. For example, if a device should trigger protective measures or alarms when attacked, and the expected response does not occur, the event will be marked as abnormal. In this way, the system can discover potential device failures or security vulnerabilities. Finally, based on the consistency check results, the system generates a preliminary response dataset. This dataset contains all the checked response log data and provides a foundation for subsequent baseline comparison and vulnerability analysis. The output field is named Preliminary Response Dataset, which will be used in step S310 for further response analysis and vulnerability evidence generation.

[0094] In summary, the technical effects of this step are as follows: Through steps S210 to S230, this invention ensures the successful execution of the attack event and the actual response of the device by precisely timing the attack injection and verifying the target. During the simulation, the validity of the response log is confirmed through self-consistency verification, providing reliable basic data for subsequent vulnerability analysis and security assessment, and ensuring the accuracy and credibility of the simulation results.

[0095] Step S300 includes at least steps S310-S330:

[0096] S310. Extract response deviation and key device indicators from the preliminary response dataset, perform baseline comparison and error calculation, and obtain vulnerability evidence map;

[0097] First, the preliminary response dataset obtained in step S230 is used as input. The response deviation refers to the difference calculated by comparing the actual response in the preliminary response dataset with a preset standard or historical record. Specifically, it includes deviations in the device's security mechanism trigger state (i.e., whether protective measures or alarms were triggered as expected), deviations in the device's functional state (e.g., whether a fault, shutdown, or functional abnormality occurred), and deviations in response timing (e.g., the difference between the actual response delay and the preset delay). The key device indicators refer to core parameters collected from specific devices in the power network during the simulation process that reflect their operating status and health. Specific indicators include time-dimensional indicators such as device response time, electrical characteristic indicators such as bus voltage variation range and line load fluctuations, and system stability indicators such as frequency deviation. These deviations and indicators together form the basis for baseline comparison and error calculation, used to accurately generate vulnerability evidence maps.

[0098] Specifically, the dataset contains records of the responses of various devices in the simulation environment to attack events. The system extracts response deviations based on preset standards or historical records. These standards include the expected responses of devices when facing specific attacks, such as whether the device triggers predetermined security mechanisms, whether a malfunction occurs, and the response delay. The calculation of response deviations is mainly quantified by comparing the differences between the actual responses and preset standards. After deviation extraction, the system further extracts key device indicators, including but not limited to device response time, voltage variation range, and load fluctuation. The system compares the extracted response deviations with historical data benchmarks, which are typically stored on-chain as known normal operating modes. This process ensures that all response behaviors do not have significant differences or anomalies compared to previous normal behaviors. After the comparison is completed, the system generates a vulnerability evidence graph based on the error calculation method. The vulnerability evidence graph contains each attack event and its impact on the devices, indicating which devices and functions were attacked, the extent of the impact, and the interaction relationships between the devices. The output field is named "Vulnerability Evidence Graph," which will be further used for risk assessment and vulnerability prioritization in step S320.

[0099] S320. Based on the vulnerability evidence diagram, conduct a risk assessment and prioritize the vulnerabilities, and generate an evidence report;

[0100] Further, the system will use the vulnerability evidence graph generated in step S310 as input to begin risk assessment. Risk assessment is calculated based on the difference between historical data and current response data. Specifically, the system first retrieves historical response data from the blockchain, which includes the device's performance when it encountered similar attacks in the past. Historical data provides a standard for assessing the anomaly and severity of the current response. Based on this historical data, the system can assess the potential impact of the attack on the device and the degree of harm caused by different attacks. For example, some attacks may only have a temporary impact on the device, while others may cause long-term functional damage. Then, based on the response differences and a preset risk assessment algorithm, the system calculates the priority of each vulnerability; higher-priority vulnerabilities are considered more urgent and serious security risks. Risk assessment is not only based on the response data of a single device but also considers the interaction effects between multiple devices, especially the cascading effects that an attack event may trigger. After the assessment is completed, the system will generate an evidence report, which includes a detailed description of the vulnerability, a ranking of vulnerability priorities, and recommended remediation measures for each vulnerability. The output field is named "Evidence Report," which will be used for vulnerability confirmation and detailed analysis in subsequent step S330.

[0101] S330. Based on the evidence report and vulnerability evidence diagram, confirm and analyze in detail to generate the final vulnerability security report;

[0102] Specifically, after generating the evidence report in step S320, the system further confirms and analyzes the vulnerability evidence graph in detail. The confirmation process primarily involves using an expert system or rule-based logic to check the completeness and consistency of the data in the vulnerability evidence graph. The system verifies that each piece of vulnerability evidence has sufficient supporting evidence, such as a detailed description of the attack pattern, specific information about the affected devices, and potential expansion risks. This process also includes verifying the evidence to ensure that all data sources are traceable and accurate. During the analysis, the system conducts in-depth analysis based on the vulnerability type, attack severity, and historical data to determine which vulnerabilities have a larger attack surface or potential cascading effects, and marks them as high-priority vulnerabilities. The analysis also considers the criticality of devices and the overall security of the network, ensuring that vulnerabilities in all critical devices are addressed first. Finally, the system generates a complete vulnerability security report, which includes the analysis results of all vulnerabilities, confirmed evidence, and remediation recommendations. This report not only helps administrators understand the impact of vulnerabilities but also provides guidance for subsequent security protection measures. The output field is named "Final Vulnerability Security Report," which will serve as input for the vulnerability closure write-back operation in S400.

[0103] In summary, the technical effects of this step are as follows: Through steps S310 to S330, this invention can accurately identify security vulnerabilities in power networks and ensure that critical vulnerabilities are addressed promptly through risk assessment and prioritization. The generation of vulnerability evidence diagrams and security reports provides a clear basis for subsequent security remediation and protection strategies, enhancing the security protection and response capabilities of power networks.

[0104] In one embodiment, the preliminary response dataset obtained in step S230 is used as input. This dataset contains records of the responses of various devices in the simulation environment to attack events. The system extracts response deviations based on preset standards or historical records. These deviations include deviations in device security mechanism trigger states, device functional states, and response timing. Simultaneously, the system extracts key device indicators, including device response time, voltage variation range, and load fluctuations. Formula ⑦ is used to calculate the response deviation value for each device, employing the L2 norm to measure the difference between the actual response and the preset standard. Let... The number of devices is derived from the total number of devices in the initial response dataset. For each device... ( Its actual response vector is Sourced from preliminary response data centralized device Response logs; :Number of devices;Preset standard response vector is This is derived from preset standards or historical records. Response deviation. Defined as:

[0105]

[0106] in: Indicates equipment The degree of response deviation, with a value range of [0, +∞); Device index; : The actual response vector of device j; : The preset standard response vector of device j.

[0107] Data source mapping: The actual response is extracted from the preliminary response dataset and denoted as... The expected response is extracted from the preset standard and recorded as... Together, they form the formula in ⑦. Formula ⑦ It is used as an intermediate indicator in formula ⑧.

[0108] Formula ⑧ is used to integrate response deviation and key equipment indicators to generate a comprehensive anomaly score for each device. Key equipment indicators include response time. Voltage changes Load fluctuations All data are derived from the preliminary response dataset. (Comprehensive anomaly score) Calculated by weighted sum:

[0109]

[0110] in Preset weights; Indicates equipment The degree of abnormality, with a value range of [0, +∞); :Response time metric for device j; The voltage variation range index of device j; : Load fluctuation index of device j.

[0111] Data source mapping: Formula ⑦ Response time extracted from the initial response dataset Voltage changes Load fluctuations Together they form the formula in ⑧ The system will The vulnerability is compared with historical on-chain data, which is derived from normal operating patterns stored on-chain. Error calculations generate a vulnerability evidence graph, which includes the interactions between devices. The output field, named "Vulnerability Evidence Graph," includes the anomaly score and impact relationship of each device, inputted by S320's risk assessment and vulnerability priority ranking.

[0112] Following the aforementioned vulnerability evidence diagram, the system extracts the anomaly scores and impact relationships for each device, and retrieves historical response data from the blockchain, including the device's performance when encountering similar attacks in the past. Formula 9 is used to calculate the risk score for each vulnerability, based on the difference between historical data and current response data. Let... For equipment The current abnormal score is derived from the vulnerability evidence graph; For equipment The historical average anomaly score is derived from on-chain historical data benchmarks. Risk Score Calculated using the focus loss function to highlight outliers:

[0113]

[0114]

[0115] in, For focusing parameters; Indicates equipment The risk level is defined as [0, +∞). The probability value of device j; Focusing parameters; The current anomaly score of device j; : The historical average anomaly score of device j; Absolute value function; : Sum index.

[0116] Data source mapping: Extract the current anomaly score from the vulnerability evidence graph and record it as... Historical anomaly scores are extracted from on-chain historical data benchmarks and recorded as follows: Together, they form the formula in formula ⑨. Formula 9 It is used as an intermediate indicator in formula 10.

[0117] Formula 10 is used to prioritize vulnerabilities, calculating the priority weight of each vulnerability using soft maximum mapping. Priority Weight Defined as:

[0118]

[0119] in, For temperature parameters; Indicates vulnerability The priority level, with a value range of (0,1).

[0120] Data source mapping: Formula 9 As input, it is obtained through soft maximum mapping. The system is based on The system prioritizes vulnerabilities and considers inter-device interactions to generate an evidence report. The output field, named "Evidence Report," includes a detailed description of the vulnerabilities, their priority ranking, and recommended remediation measures. This report is based on the confirmed and detailed analysis of vulnerabilities in the S330.

[0121] Following the aforementioned evidence report and vulnerability evidence diagram, the system performs verification and detailed analysis through expert systems or rule-based logic. Formula 11 is used to check the data integrity of the vulnerability evidence diagram, employing logical consistency scoring. Let... The adjacency matrix of the vulnerability evidence graph is derived from the vulnerability evidence graph. This is the evidence vector, derived from the vulnerability description in the evidence report. Consistency score. Defined as:

[0122]

[0123] in: This indicates the degree of consistency of the evidence, and its value ranges from [0, +∞). The adjacency matrix of the vulnerability evidence graph; :Evidence vector; L1 norm.

[0124] Data source mapping: The adjacency matrix is ​​extracted from the vulnerability evidence graph and denoted as... The evidence vector is extracted from the evidence report and denoted as... Together, they form the formula in formula 11. Formula 11 It is used as an intermediate indicator in formula ⑫.

[0125] Formula 12 is used to generate the remediation recommendation parameters in the final vulnerability security report. Let The threshold value is a preset value derived from expert system rules. (Strength of repair suggestion) Defined as:

[0126]

[0127] in: Indicates vulnerability The urgency of repair, with a value range of [0,1); : Preset threshold.

[0128] Data source mapping: Formula 10 And formula 11 As input, it is obtained through threshold determination. The system is based on High-priority vulnerabilities are flagged, and a final vulnerability security report is generated. The output field, named "Final Vulnerability Security Report," includes analysis results, confirmation evidence, and remediation recommendations for all vulnerabilities, and is input via the vulnerability closed-loop write-back operation of S400. In summary, through steps S310 to S330, this invention achieves quantitative analysis of response deviations, dynamic risk assessment based on historical data, and automated confirmation of vulnerability evidence, ensuring the accuracy and traceability of the security report.

[0129] The technical benefits of S300: It enables accurate identification and prioritization of vulnerabilities through mathematical tools, thereby improving the simulation efficiency and reliability of power network security.

[0130] Step S400 includes at least steps S410-S430:

[0131] S410. Based on the final vulnerability security report, write back to the blockchain event database and update vulnerability records and scores;

[0132] Specifically, the final vulnerability security report generated in step S330 is used as input. This report contains detailed vulnerability analysis results, vulnerability priority, and related risk assessment data. Based on this information, the system will write back and update the existing vulnerability records in the event database. The write-back process first uses blockchain technology to save the vulnerability evidence report and its associated risk assessment results to the event database. This data will be added to the blockchain as new event entries and scored based on key indicators such as vulnerability severity and attack type. The scoring mechanism is calculated using a specific algorithm based on a comprehensive consideration of the vulnerability's potential threat level, impact scope, and feasibility. These scores will be used for priority ranking, helping subsequent security protection measures focus on the most important vulnerabilities. Furthermore, the written-back data includes not only the vulnerability description but also the current remediation status, response strategy, and historical remediation progress. All write-back operations are managed through smart contracts to ensure the immutability of each data update and that each write-back complies with preset compliance requirements. The output field is named "Update Vulnerability Record," which will serve as input for generating improvement suggestions in subsequent step S420.

[0133] S420: Based on updated vulnerability records and scores, perform policy linkage processing to generate security improvement suggestions;

[0134] Further, the system obtains updated vulnerability records and scoring information from step S410 as input data. Based on the vulnerability priority and assessment results, the system automatically generates security improvement suggestions for each vulnerability. First, the system sorts each vulnerability according to the risk assessment results and generates improvement suggestions according to priority. These suggestions typically involve vulnerability remediation measures, risk mitigation methods, or adjustments to protection strategies, such as strengthening the security settings of certain devices, updating firewall rules, or improving detection capabilities. For higher-priority vulnerabilities, the system proposes more detailed and urgent remediation solutions and performs corresponding policy linkage processing. Policy linkage processing includes sending these improvement suggestions to the relevant security policy management modules to strengthen network protection capabilities through automated policy updates and execution. For example, the system can use an automated rule engine to transform improvement suggestions into specific protection measures based on vulnerability type and priority, such as isolating target devices, adjusting access control policies, or modifying network configurations. All generated security improvement suggestions are recorded and used as input for the verification task write-back in subsequent step S430. The output field is named "Security Improvement Suggestion," which will continue to be used in subsequent step S430 to generate verification tasks and simulation plans.

[0135] S430. Based on the security improvement recommendations, write back to the event database and generate a verification task write-back.

[0136] Taking the security improvement suggestions generated in step S420 as input, the system will further write these suggestions and related verification tasks back to the event database. The write-back process will include assigning corresponding verification tasks to each improvement suggestion. The purpose of these tasks is to verify the effectiveness of the proposed improvements and ensure that the system can successfully implement the required security protection in a real-world environment. Verification tasks will be categorized according to the type and importance of the improvement suggestions, and the system will process each task according to its priority and urgency. The execution of verification tasks will include automated verification, using a simulation platform to simulate different attack scenarios to check whether vulnerabilities have been effectively patched and whether protective measures can be correctly implemented in practice. All verification tasks will be recorded on the blockchain to ensure that the execution results are immutable and traceable. In addition, the system will generate a simulation plan for the next round based on the execution status of the verification tasks. This plan will further optimize the simulation environment and adjust the simulation strategy based on the feedback and patching effects of the previous round of verification tasks to test whether the new security protection measures can effectively prevent potential attacks. The output field is named "Verification Task Write-back," which will serve as the input for updating the attack event database in subsequent step S100.

[0137] In summary, the technical effects of this step are as follows: Through steps S410 to S430, this invention forms an automated security remediation and protection closed loop by writing back vulnerability evidence and generating security improvement suggestions. The execution status of each remediation and verification task is recorded in the blockchain, ensuring the immutability and traceability of the data, while also providing clear guidance for the next round of simulation and verification. This process significantly enhances the security protection capabilities of the power network, ensuring continuous and dynamic security assessment and response.

Claims

1. A blockchain-enhanced power network security simulation method, characterized in that, include: S100: Obtain power network topology data and attack event database; based on the preset attack events and their characteristics in the blockchain attack event database, perform topology mapping and entry filtering to obtain the contract injection list. Based on the aforementioned contract injection list, attack target verification and topology adaptation are performed through smart contracts to generate an attack injection list; the power network topology data includes buses, substations, lines, protection devices, and communication links; the attack event database contains attack types, attack targets, and triggering conditions. S200. Based on the attack injection list and session ID, time window locking and injection sequence arrangement are performed, attack execution data packets are generated, real-time injection and receipt collection are performed, simulation response logs are recorded, and self-consistency verification is performed to obtain a preliminary response dataset. S300. Extract response deviation and key device indicators from the preliminary response dataset, perform baseline comparison and error calculation based on on-chain historical data benchmark, generate vulnerability evidence graph, and then perform dynamic risk assessment and vulnerability priority ranking based on historical response data and response differences to generate final vulnerability security report. S400, based on the final vulnerability security report, writes back to the blockchain event database through smart contracts, updates vulnerability records and risk assessment scores, and executes policy linkage processing to generate security improvement suggestions, and constructs a verification task write-back.

2. The method according to claim 1, characterized in that, The attack injection list and session IDs include: The attack injection list includes attack vector ID, attack vector type, target device, trigger timing policy, adaptation information based on power network topology, and injection policy structure constructed for each attack event; the session ID includes attack injection list version, time window locking parameters, injection sequence arrangement, and simulation environment snapshot.

3. The method according to claim 1, characterized in that, Response deviation and key equipment indicators include: Response deviations include deviations in the triggering state of equipment safety mechanisms, deviations in the functional state of equipment, and deviations in response timing; key equipment indicators include time-dimensional indicators, electrical characteristic indicators, line load fluctuations, and system stability indicators.

4. The method according to claim 1, characterized in that, The process of acquiring power network topology data and an attack event database, and performing topology mapping and entry filtering based on preset attack events and their characteristics in the blockchain-based attack event database, also includes: Obtain power network topology data; The information in the power network topology data is matched with entries in the attack event database to filter out attack vectors that match the current network environment. The selected entries and topology mappings will be input as the contract injection manifest.

5. The method according to claim 1, characterized in that, The process of using smart contracts to verify attack targets and adapt topologies also includes: Extract the attack vector ID and corresponding timing triggering strategy from the attack event database; By checking the matching between the target device and the attack vector, it is determined whether the attack can be executed on the specified bus, line or protection device, ensuring that the attack vector can accurately penetrate the target device; If the target device or network component is not suitable for receiving a certain attack event, it will be automatically replaced and updated in the contract injection list.

6. The method according to claim 1, characterized in that, Based on the attack injection list and session ID, the process of performing time window locking and injection sequence arrangement to generate attack execution data packets also includes: After the attack injection entries are generated, the entries are sorted and categorized, and the final injection list is generated through the contract system. Based on the complexity and execution difficulty of the attack vector, an appropriate injection strategy structure is constructed for each attack event. The strategy structure specifies how to initiate the attack, how to execute the attack step by step in the simulation environment, and how to dynamically adjust the injection strength and execution order during the attack process.

7. The method according to claim 1, characterized in that, The process of extracting response deviations and key device indicators from the preliminary response dataset, and generating a vulnerability evidence graph based on baseline comparison and error calculation using on-chain historical data benchmarks, also includes: The response deviation is extracted based on preset standards or historical records, whereby the standards include the expected response of the device when facing a specific attack. Key metrics were extracted, including equipment response time, voltage variation range, and load fluctuation. The extracted response deviation is compared with historical data benchmarks, and the benchmark data is stored on the chain as a known normal operating mode. A vulnerability evidence graph is generated based on an error calculation method. The vulnerability evidence graph includes each attack event and its impact on the device.

8. The method according to claim 1, characterized in that, The process of performing dynamic risk assessment and vulnerability prioritization based on historical response data and response discrepancies also includes: Retrieve historical response data from the blockchain, which includes the device’s behavior when it encountered similar attacks in the past; Assess the potential impact of attacks on devices and the severity of different attacks based on historical response data; Based on the differences in response, and combined with a preset risk assessment algorithm, the priority of each vulnerability is calculated. Vulnerabilities with higher priority are marked as more urgent and serious security risks.

9. The method according to claim 1, characterized in that, The process of generating the final vulnerability security report also includes: Verify and analyze the vulnerability evidence diagrams in detail to confirm whether each vulnerability evidence has sufficient supporting evidence; Based on the type of vulnerability, the severity of the attack, and historical data, conduct in-depth analysis to determine which vulnerabilities have a larger attack surface or potential cascading effects, and mark them as high-priority vulnerabilities. Generate a complete vulnerability security report, which includes the analysis results of all vulnerabilities, confirmed evidence, and remediation recommendations.

10. The method according to claim 1, characterized in that, Based on the final vulnerability security report, the process of writing back the blockchain event database via smart contracts, updating vulnerability records and risk assessment scores, and executing coordinated policy actions to generate security improvement recommendations also includes: By writing back the blockchain event database through smart contracts, vulnerability records and risk assessment scores are updated. The execution strategy is linked to generate security improvement suggestions and build a verification task write-back.

Images