A power system vulnerability mining verification linkage assessment method

Abstract

The present application relates to the technical field of power system network security, and more particularly to a power system vulnerability mining and verification linkage evaluation method. The method obtains power system asset data, communication topology data, vulnerability knowledge data and operating state data, and generates asset vulnerability correlation results. Based on network reachability relationship, operating state constraints and vulnerability environment dependency conditions, a verifiable vulnerability candidate set is screened. Combined with verification risk level, target asset operating state and verification window, a controlled verification task is generated. The verification is performed and a vulnerability verification result is generated. Combined with the power business influence relationship, a vulnerability evaluation result is generated, and the vulnerability state, verification task parameters and evaluation rules are updated. The present application forms a continuous processing link of vulnerability candidate screening, controlled verification and evaluation feedback.

Description

Technical Field

[0001] This invention relates to the field of power system network security technology, and in particular to a method for joint evaluation of power system vulnerability discovery and verification. Background Technology

[0002] In the field of power system cybersecurity, existing solutions for power system vulnerability detection and assessment typically rely on vulnerability intelligence platforms, vulnerability knowledge bases, vulnerability scanning tools, asset management platforms, and handling process systems. These solutions generally identify target devices through asset inventories, identify vulnerability instances through vulnerability knowledge data or vulnerability scanning results, and then combine vulnerability levels, asset importance, or handling status to form a risk record. Under normal circumstances, these solutions can complete vulnerability discovery, impact scope identification, and handling status recording. However, under the constraints of power system operation, limitations such as mismatches between vulnerability candidates and communication links, inconsistencies between verification tasks and the operational status of target assets, and insufficient alignment between vulnerability assessment results and actual business impact can arise.

[0003] Existing solutions often rely on fixed vulnerability database matching, periodic scanning tasks, manually set verification windows, or static risk levels for processing. When the status of power system assets, communication topology, access control rules, target asset operating status, or vulnerability knowledge data changes, there is a lack of stable connection between vulnerability candidate screening, verification task generation, and subsequent risk assessment. This can easily lead to situations where vulnerability-related items are identified but do not meet the verification conditions, or the verification results fail to be synchronously correlated with the impact on power business.

[0004] For the joint processing of asset vulnerability correlation results, verifiable vulnerability candidate sets, controlled verification tasks, and vulnerability assessment results, existing technologies still suffer from a common shortcoming: a disconnect between candidate selection, verification control, result linkage, and rule updates. Therefore, it is necessary to address the issue of how to generate controlled verification tasks and link vulnerability assessment results based on asset vulnerability correlation results and vulnerability verification results, within the constraints of power system operation, specifically in the scenario of power system vulnerability mining, verification, and assessment linkage. Summary of the Invention

[0005] This invention provides a method for linking vulnerability mining, verification, and evaluation in power systems, addressing the problem of how to generate controlled verification tasks and link vulnerability evaluation results based on asset vulnerability correlation results and vulnerability verification results under the constraints of power system operation.

[0006] To address the aforementioned technical problems, this invention provides a power system vulnerability discovery, verification, and assessment linkage method, comprising: S100: Obtain power system asset data, communication topology data, vulnerability knowledge data, and operation status data; normalize the asset identity and business object in the power system asset data; associate the normalized asset identity with the communication link and access control rules in the communication topology data; and perform vulnerability knowledge matching with the vulnerability knowledge data to generate asset vulnerability association results. S200. Based on the asset vulnerability association results, the vulnerability association items are filtered according to network reachability, runtime constraints and vulnerability environment dependencies to generate a set of verifiable vulnerability candidates. S300. Based on the verifiable vulnerability candidate set, generate a controlled verification task by configuring the verification strength and rollback conditions according to the verification risk level, the target asset's operating status, and the verification window. S400. Execute the controlled verification task, collect verification response data, system indicators and behavior logs, and generate vulnerability verification results based on the verification judgment conditions. S500. Based on the vulnerability verification results and the impact on power services, combined with the importance of equipment and the dependency of communication links, generate vulnerability assessment results, and update the vulnerability status, verification task parameters and assessment rules according to the review results or handling results.

[0007] Furthermore, the power system asset data includes asset identity, equipment type, equipment version, firmware version, open ports, communication protocols, and business roles; the communication topology data includes security partitions, communication links, access control rules, and service bearer relationships; the vulnerability knowledge data includes vulnerability number, affected objects, version range, triggering conditions, environmental dependencies, and patch information; and the operational status data includes online status, system load, system response time, communication status, and alarm data.

[0008] Furthermore, the generation of asset vulnerability association results includes: normalizing asset identities and business objects to generate asset-business mapping relationships; associating the asset-business mapping relationships with communication links and access control rules to generate communication link relationships; and matching the communication link relationships with vulnerability knowledge data in terms of version range, service features, and specification features to generate asset vulnerability association results containing asset identifiers, business object identifiers, communication link identifiers, and vulnerability knowledge entry identifiers.

[0009] Furthermore, the generation of a verifiable vulnerability candidate set includes: performing network reachability judgment on the communication path between the vulnerability verification source and the target asset based on security partitions and access control rules, and generating a reachability judgment result; performing operational status constraint judgment on the target asset based on operational status data, and generating an operational constraint judgment result; identifying vulnerability association items that simultaneously satisfy the reachability judgment result, the operational constraint judgment result, and the vulnerability environment dependency condition as verifiable vulnerability candidates, and generating a verifiable vulnerability candidate set.

[0010] Furthermore, the generation of the controlled verification task includes: configuring the verification intensity based on the target asset's operating status and verification risk level in the verifiable vulnerability candidate set; configuring the verification conditions based on the verification window and rollback conditions; and writing the verification object, verification method, verification conditions, verification intensity, verification window, and anomaly handling conditions into the controlled verification task.

[0011] Furthermore, the abnormal handling conditions include verification suspension conditions, verification degradation conditions, verification postponement conditions, and verification blocking conditions; when the system load of the target asset exceeds the system load threshold, the system response time exceeds the system response time threshold, the target asset is in an alarm state, or the target asset is not within the verification window, the controlled verification task is suspended, downgraded, postponed, or blocked, and an abnormal log record is generated.

[0012] Furthermore, generating the vulnerability verification result includes: collecting verification response data, system indicators, and behavior logs when executing the controlled verification task; matching the verification response data, system indicators, and behavior logs with the verification judgment conditions to generate a vulnerability verification result including verification status, verification evidence, verification confidence level, and anomaly markers.

[0013] Furthermore, generating vulnerability assessment results includes: determining the vulnerability status based on the vulnerability verification results; determining the scope of business impact based on the power business impact relationship; and generating vulnerability assessment results including risk level, scope of impact, and handling priority by combining equipment importance, communication link dependency, verification confidence level, and handling status.

[0014] Furthermore, the updating of vulnerability status, verification task parameters, and evaluation rules includes: updating the vulnerability status based on the review results or handling results; when the review result corresponds to a false alarm flag, downgrading the candidate rule of the corresponding vulnerability candidate generation rule; when the review result corresponds to a verification failure flag, updating the verification task parameters; and when the review result corresponds to a change in risk level, updating the evaluation rules and generating a rule update record.

[0015] Furthermore, the verification task parameters include verification strength, verification window, and fallback conditions; the evaluation rules include risk level generation rules corresponding to device importance, communication link dependency, verification confidence, and handling status; the verification task parameters are written into subsequent controlled verification tasks, and the evaluation rules are written into subsequent vulnerability evaluation results.

[0016] The key innovations of this invention include: (1) Unify the asset identity and business object in the power system asset data, and associate the unified asset identity with the communication link, access control rules and vulnerability knowledge data so that the asset vulnerability association result includes the correspondence between the asset side, the link side and the vulnerability knowledge side. On this basis, the vulnerability association items are screened according to the network reachability relationship, the operating status constraint and the vulnerability environment dependency condition to form a verifiable vulnerability candidate set.

[0017] (2) Configure controlled verification tasks around the verifiable vulnerability candidate set, and incorporate the verification risk level, target asset operating status, verification window, verification strength and rollback conditions into the same task generation process, so that the vulnerability verification task is subject to the common constraints of operating status and verification boundary before it is issued.

[0018] (3) Link the vulnerability verification results with the impact on power business, and generate vulnerability assessment results by combining the importance of equipment and the dependence of communication links; after the review results or handling results are returned, update the vulnerability status, verification task parameters and assessment rules so that the verification results and review results can participate in subsequent candidate screening, verification task generation and assessment processing.

[0019] The following are its main beneficial effects: (1) To address the problem that existing vulnerability candidates are easily formed by matching vulnerability knowledge data or asset versions, the association between asset identity, business object, communication link, access control rules and vulnerability knowledge data, combined with network reachability, running status constraints and vulnerability environment dependency conditions, can reduce the number of vulnerability association items that do not meet the verification conditions from entering the subsequent verification process, so that the set of verifiable vulnerability candidates can match the communication conditions and running status of the target asset.

[0020] (2) In response to the problem of insufficient connection between existing verification tasks and the operating status of target assets, by introducing verification risk level, target asset operating status, verification window, verification intensity and rollback conditions in the process of generating controlled verification tasks, the verification object, verification conditions and abnormal handling boundaries can be defined before verification execution, thereby reducing task abnormalities caused by inconsistency between verification tasks and the current operating status of the power system.

[0021] (3) To address the problem of insufficient connection between existing vulnerability assessment results and actual business impact, by using vulnerability verification results, power business impact, equipment importance and communication link dependency to generate vulnerability assessment results, and updating vulnerability status, verification task parameters and assessment rules based on review results or handling results, subsequent vulnerability candidate screening, controlled verification task generation and vulnerability assessment processing can be connected based on verification feedback. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a power system vulnerability discovery, verification, and linkage evaluation method provided in an embodiment of this application. Detailed Implementation

[0023] Example 1: Refer to Figure 1 This is a flowchart illustrating a power system vulnerability discovery, verification, and linkage assessment method provided in an embodiment of the present invention. The process may include at least steps S100-S500: S100: Obtain power system asset data, communication topology data, vulnerability knowledge data, and operation status data; normalize the asset identity and business object in the power system asset data; associate the normalized asset identity with the communication link and access control rules in the communication topology data; and perform vulnerability knowledge matching with the vulnerability knowledge data to generate asset vulnerability association results. S200. Based on the asset vulnerability association results, the vulnerability association items are filtered according to network reachability, runtime constraints and vulnerability environment dependencies to generate a set of verifiable vulnerability candidates. S300. Based on the verifiable vulnerability candidate set, generate a controlled verification task by configuring the verification strength and rollback conditions according to the verification risk level, the target asset's operating status, and the verification window. S400. Execute the controlled verification task, collect verification response data, system indicators and behavior logs, and generate vulnerability verification results based on the verification judgment conditions. S500. Based on the vulnerability verification results and the impact on power services, combined with the importance of equipment and the dependency of communication links, generate vulnerability assessment results, and update the vulnerability status, verification task parameters and assessment rules according to the review results or handling results.

[0024] S100. Obtain power system asset data, communication topology data, vulnerability knowledge data, and operational status data. Normalize the asset identities and business objects in the power system asset data. Associate the normalized asset identities with the communication links and access control rules in the communication topology data, and perform vulnerability knowledge matching with the vulnerability knowledge data to generate asset vulnerability association results. In one implementation, this method is executed by a centralized vulnerability management system deployed in a power system network security detection environment. This centralized vulnerability management system communicates with an asset data table, a communication topology table, a vulnerability knowledge base, an operational status acquisition interface, and a historical verification record database. The asset data table can be derived from the asset ledger, device fingerprint identification results, or configuration management database of the power monitoring system; the communication topology table can be derived from security partition configuration, communication link configuration, access control rules, and service carrying relationships; the vulnerability knowledge base can receive vulnerability numbers, affected objects, version ranges, triggering conditions, environmental dependencies, and patch information; operational status data can be provided by device monitoring modules, log systems, or alarm systems. Before the above data enters this step, the centralized vulnerability management system first verifies the data source identifier and collection time. Data with abnormal time order or missing sources is not included in the current round of matching and is retained in the cache to be supplemented in the next collection cycle.

[0025] When performing asset identity unification, the centralized vulnerability management system reads asset identity, equipment type, equipment version, firmware version, open ports, communication protocols, and business roles from the power system asset data. If the same target asset has multiple names in different data sources, the system prioritizes merging them according to asset identity. If an asset identity is missing, the system compares it with equipment type, communication address, open ports, and communication protocols to form a unified asset identifier. When unifying business objects, the system maps dispatch master stations, substation communication gateways, business front-end servers, substation monitoring hosts, engineering workstations, remote terminals, intelligent electronic devices, and industrial control equipment to their corresponding business roles. If there is a conflict between asset identity and business role, such as the same communication address being marked as both a business front-end server and a regular network device, the asset is placed in a pending review state and will not be included in subsequent vulnerability candidate screening.

[0026] Communication link association is performed after asset identity normalization. The centralized vulnerability management system reads security partitions, communication links, access control rules, and service bearer relationships from the communication topology data, and maps the normalized asset identities to the communication links. In cases where multiple communication paths exist between the master station and the plant station, the system checks the communication direction, communication port, and communication protocol according to the access control rules, retaining communication link relationships that satisfy the access control rules. If a link record for a certain asset is missing in the communication topology data, but the communication status and log information of that asset exist in the operational status data, the system does not directly recognize the link as valid. Instead, it generates a communication link pending confirmation marker, which serves as a constraint for network reachability determination in S200.

[0027] Vulnerability knowledge matching is performed after the communication link relationship is established. The system matches the device version, firmware version, open ports, and communication protocols in the asset data with the affected objects, version ranges, triggering conditions, and environmental dependencies in the vulnerability knowledge data. Version range matching verifies whether the software version or firmware version of the target asset falls within the version range given in the vulnerability knowledge data; service feature matching verifies whether the open ports and service features of the target asset correspond to the vulnerability triggering conditions; protocol feature matching verifies whether the communication protocol is consistent with the environmental dependencies in the vulnerability knowledge data. For cases where the version number format is inconsistent, the system first performs version format parsing; version numbers that cannot be parsed are not discarded directly, but the original version field is retained, and the vulnerability-related item is marked as a version pending review.

[0028] This step ultimately generates the asset vulnerability association result. This result is not simply a vulnerability list, but a data object containing asset identifiers, business object identifiers, communication link identifiers, vulnerability knowledge entry identifiers, matching methods, and matching statuses. Asset identifiers and vulnerability knowledge entry identifiers are used by S200 to identify vulnerability association items; communication link identifiers and access control rules are used by S200 to determine network reachability; and business object identifiers are used by S500 to associate power service impact relationships. If a vulnerability knowledge entry only matches an asset version but lacks communication link relationships or operational status data, that vulnerability association item remains in the asset vulnerability association result, but is processed in subsequent steps as if the verification conditions are insufficient.

[0029] S200. Based on the asset vulnerability association results, the vulnerability association items are filtered according to network reachability, runtime constraints, and vulnerability environment dependencies to generate a verifiable vulnerability candidate set: S200 receives the asset vulnerability association results generated by S100, which are then executed by the vulnerability candidate generation module. This module does not directly use all vulnerability associations as verification targets. Instead, it first reads the asset identifier, communication link identifier, access control rules, vulnerability knowledge entry identifier, and matching status from each vulnerability association, and then filters them based on the current runtime status data. Through this process, the system further narrows down the "potentially affected" vulnerability associations into vulnerability candidates that meet the verification criteria.

[0030] Network reachability checks precede runtime constraint checks. The vulnerability candidate generation module searches for the communication path between the vulnerability verification source and the target asset based on the communication link identifier in the asset vulnerability association results. The vulnerability verification source can be a verification node configured in the centralized vulnerability management system or a vulnerability collection device deployed in the corresponding security partition. The module verifies the communication direction, port, communication protocol, and access permissions between the verification source and the target asset according to the security partition and access control rules. If the access control rules do not allow the verification source to access the target asset, or if the communication link identifier is in an unconfirmed state, the vulnerability association item is not included in the verifiable vulnerability candidate set and is marked as unreachable.

[0031] The runtime constraint judgment is performed after the reachability judgment. The vulnerability candidate generation module reads the online status, system load, system response time, communication status, and alarm data of the target asset. If the target asset is offline, or the communication status shows a link interruption, the vulnerability association item is marked as verification delayed. If the target asset is online, but the system load exceeds the system load threshold, or the system response time exceeds the system response time threshold, the vulnerability association item will not be included in the current round of verification task generation. For target assets in an alarm state, the system further verifies the alarm type; if the alarm type is related to communication failure, process abnormality, or abnormal resource usage, the vulnerability association item corresponding to the target asset is placed in the runtime constraint unmet state.

[0032] The vulnerability environment dependency condition is used to exclude vulnerability associations that are reachable but lack the triggering conditions. The vulnerability candidate generation module reads the triggering conditions and environment dependency conditions from the vulnerability knowledge entries and compares them with the open ports, communication protocols, device versions, and operating status of the target asset. For vulnerabilities requiring specific service status, specific open ports, or specific communication protocol support, the vulnerability association is only identified as a verifiable vulnerability candidate if the corresponding service characteristics, port status, and protocol characteristics all match. If the environment dependency conditions in the vulnerability knowledge entry conflict with the operating status of the target asset, such as the corresponding service of the target asset not being started, the system generates an environment dependency non-compliance flag.

[0033] The verifiable vulnerability candidate set formed in this step includes verifiable vulnerability candidates, target assets, vulnerability knowledge entry identifiers, network reachability judgment results, operational constraint judgment results, and environment dependency condition matching results. Once this set enters the S300, the controlled verification task generation module no longer performs complete asset matching repeatedly; instead, it directly reads the target assets, vulnerability knowledge entry identifiers, and verifiable conditions. For vulnerability-related items that did not enter the set due to inaccessibility, unmet operational constraints, or unmet environment dependencies, the system retains their reason markers; these reason markers can participate in the next round of screening when communication topology data, access control rules, or operational status data change.

[0034] S300. Based on the verifiable vulnerability candidate set, generate a controlled verification task by configuring the verification strength and fallback conditions according to the verification risk level, target asset operating status, and verification window: S300 is executed by the controlled verification task generation module. This module receives the set of verifiable vulnerability candidates generated by S200 and configures the verification task according to the target asset's operating status, vulnerability knowledge entries, and verification window. Unlike directly executing scanning or reproduction scripts, this step configures the verification strength and rollback conditions for each verifiable vulnerability candidate before verification, ensuring that the verification actions are adapted to the current operating status of the power system.

[0035] The risk level is determined by both vulnerability knowledge data and the target asset's status. The controlled verification task generation module reads the vulnerability knowledge entry identifiers from the verifiable vulnerability candidates, extracting the vulnerability level, triggering conditions, and environmental dependencies; it then reads the system load, system response time, communication status, and alarm data from the target asset's operational status. If vulnerability verification requires active interaction requests, service response comparisons, or configuration status checks, the system configures it as low-intensity verification; if the verification action may cause service restarts, abnormal message responses, or link fluctuations, the system configures it as high-risk verification and requires entry into the verification window and verification of fallback conditions. High-risk verification does not generate execution tasks when the target asset is in an alarm state, has abnormal load, or abnormal response; it only generates a record of tasks to be verified.

[0036] The verification window is configured based on the maintenance window, low-load periods, and access control rules. The controlled verification task generation module reads the load changes and communication status of the target asset from the runtime status data and determines the execution time in conjunction with the manually configured verification window. If the current time is not within the verification window, the system generates a verification delay record and does not issue a task to the verification execution module. For verification paths between security partitions that require specific access control rules, the module writes the allowed communication directions, ports, and communication protocols into the verification conditions during the task generation phase to avoid temporary changes to the verification scope during the verification execution phase.

[0037] When configuring verification strength, the system writes the verification object, verification method, verification conditions, verification strength, verification window, and exception handling conditions into the controlled verification task. The verification object corresponds to the target asset and vulnerability knowledge entries; the verification method can be service feature verification, version response verification, configuration status verification, or isolated environment verification; the verification conditions correspond to port, communication protocol, running status, and environment dependency conditions; the verification strength is used to limit the frequency of verification requests, the number of verifications, or the depth of interaction; exception handling conditions include verification pause conditions, verification degradation conditions, verification postponement conditions, and verification blocking conditions. All of the above together define the verification boundaries that the verification execution module can perform.

[0038] In one implementation, when the target asset system load exceeds the system load threshold, the system response time exceeds the system response time threshold, the system is in an alarm state, or the system is not within the verification window, the controlled verification task generation module does not delete the corresponding candidate. Instead, it generates a verification delay, verification degradation, or verification blocking status. A verification delay status indicates that the candidate is waiting for the next verification window; a verification degradation status indicates that the original verification method is switched to low-intensity verification; and a verification blocking status indicates that access control rules or security partitions do not allow verification to be performed. Anomaly handling records are saved along with the controlled verification task, and the S400 will re-verify these conditions before subsequent execution.

[0039] The controlled verification task output in this step serves as direct input to the S400. The verification execution module reads the verification object, verification method, verification conditions, verification strength, verification window, and anomaly handling conditions from the controlled verification task, and decides whether to execute, postpone, downgrade, or block it based on the task status. For cases where multiple controlled verification tasks exist for the same target asset, the controlled verification task generation module sorts them according to equipment importance, verification risk level, and verification window. Within the same time window, only tasks matching the current operating status are issued; unissued tasks are kept in the task queue awaiting subsequent rounds.

[0040] S400. Execute the controlled verification task, collect verification response data, system indicators, and behavior logs, and generate vulnerability verification results based on the verification judgment conditions: S400 is executed in conjunction with the verification execution module and the verification evidence collection unit. Upon receiving a controlled verification task, the verification execution module first reads the verification window, verification strength, and anomaly handling conditions from the task, and then reads the target asset's operational status data. If the operational status before execution differs from the status when the S300 generated the task—for example, if the system load suddenly increases or the target asset enters an alarm state—the verification execution module performs verification suspension, verification degradation, verification postponement, or verification blocking according to the anomaly handling conditions in the controlled verification task, and writes the processing result to the anomaly log.

[0041] The verification actions are performed according to the verification methods in the controlled verification task. For service feature verification, the verification execution module initiates a low-intensity request to the target asset that matches the open port and communication protocol, and collects the return code, service identifier, or protocol response fragment. For version response verification, the module reads the version information returned by the target asset and compares it with the vulnerability version range in the controlled verification task. For configuration status verification, the module reads the configuration status or service status in the target asset corresponding to the vulnerability triggering conditions. For isolated environment verification, the module maps the version characteristics, configuration characteristics, and vulnerability knowledge entries of the target asset to the controlled environment for verification execution. The verification response data returned by the controlled environment is recorded separately from the system indicators of the real target asset.

[0042] The verification evidence collection unit simultaneously collects verification response data, system metrics, and behavior logs during the verification process. Verification response data reflects the target asset's direct response to the verification action; system metrics reflect the target asset's system load, system response time, and communication status during verification; and behavior logs reflect service accesses, protocol interactions, or abnormal returns triggered by the verification action. If a receipt timeout, abnormal response format, or missing log occurs during the collection process, the verification evidence collection unit does not directly determine whether a vulnerability exists or not. Instead, it generates an anomaly marker and submits the anomaly marker to the verification judgment conditions for matching.

[0043] The verification criteria are derived from controlled verification tasks and vulnerability knowledge data. The verification execution module matches the verification response data, system metrics, and behavior logs with the verification criteria. If the response data matches the vulnerability triggering conditions and a corresponding access or service response record exists in the behavior log, the system generates a verification status of "verified successfully" for the vulnerability verification result. If the response data does not match, but the system metrics and behavior logs show no abnormalities, the system generates a verification status of "verified unsuccessfully" for the vulnerability verification result. If the response times out, logs are missing, or changes in the target asset's status affect the verification process, the system generates a verification status of "verified abnormal" and writes an abnormal flag.

[0044] Vulnerability verification results include verification status, verification evidence, verification confidence level, and anomaly markers. Verification status indicates whether verification passed, failed, or anomaly occurred. Verification evidence stores response data, system metrics, and behavior log fragments directly related to the judgment criteria. Verification confidence level is formed based on the completeness of the verification response data, the stability of system metrics, and the degree of matching with the behavior logs. If verification degradation is performed during the verification process, the system retains a degradation marker in the verification evidence, and S500 will process the verification confidence level according to this marker when generating vulnerability assessment results.

[0045] The vulnerability verification results output in this step are fed into the S500 system. The S500 reads the verification status, verification evidence, verification confidence level, and anomaly markers, and processes them in conjunction with their impact on the power business. For verification anomalies, the S500 does not directly generate a high-risk assessment; instead, it combines the anomaly markers, the importance of the target asset, and the handling status to generate a pending review status. For verification successful results, the S500 continues to read the business objects and communication link dependencies, calculating the corresponding impact scope and handling priority.

[0046] S500. Based on the vulnerability verification results and the impact on power services, combined with the importance of equipment and the dependency on communication links, a vulnerability assessment result is generated, and the vulnerability status, verification task parameters, and assessment rules are updated according to the review results or handling results: S500 is executed by the linkage assessment module and the feedback update module. After receiving the vulnerability verification results output by S400, the linkage assessment module first verifies the verification status, verification evidence, verification confidence level, and anomaly markers, and then reads the corresponding asset identifier, business object identifier, and communication link identifier from the asset vulnerability association results. The power business impact relationship reflects the correspondence between the target asset and the business object, the business bearer relationship, and the communication link dependency relationship. This step uses this relationship to put the individual vulnerability verification result back into the power system business link for evaluation.

[0047] When generating vulnerability assessment results, the collaborative assessment module first determines the vulnerability status based on the vulnerability verification results. Vulnerabilities that pass verification proceed to the risk level generation process; vulnerabilities that fail verification enter a low-risk or observational state; and vulnerabilities with abnormal verification enter a pending review state. Subsequently, the module determines the scope of business impact based on the power business impact relationships. The scope of business impact may include affected business objects, associated communication links, and affected target assets. If the target asset is located on a critical communication link, or if the corresponding business object has multiple downstream dependencies, the communication link dependencies will participate in the risk level generation. If the target asset passes verification, but its business object is not in the current business carrying relationship, the system marks the vulnerability assessment result as having a limited scope of impact.

[0048] Risk level and handling priority are generated based on equipment importance, communication link dependencies, verification confidence level, and handling status. Equipment importance can be determined by business roles, security partitions, and business bearer relationships; communication link dependencies reflect the connection location of the target asset between the main station, the plant, or security partitions; verification confidence level comes from the vulnerability verification results of S400; and handling status comes from the vulnerability status table or historical verification record database. The linkage assessment module performs rule matching on the above objects to generate vulnerability assessment results including risk level, impact scope, and handling priority. If the verification confidence level is low and the verification evidence contains anomaly markers, the system does not directly increase the risk level but instead generates a review task and retains the current handling status.

[0049] Upon receiving the verification or handling results, the feedback update module updates the vulnerability status, verification task parameters, and evaluation rules. When the verification result corresponds to a false positive flag, the module downgrades the candidate rule generation for the corresponding vulnerability and reduces the priority of similar matching items entering the verifiable vulnerability candidate set during subsequent S200 filtering. When the verification result corresponds to a verification failure flag, the module updates the verification task parameters, including verification strength, verification window, and fallback conditions. When the verification result corresponds to a change in risk level, the module updates the evaluation rules and generates a rule update record. The rule update record retains the rule identifiers and trigger sources before and after the update, for use in the next round of vulnerability evaluation result generation.

[0050] The handling results are used to synchronize vulnerability status. If the handling result indicates that the vulnerability has been patched, the feedback update module updates the vulnerability status to "Pending Review" and triggers subsequent controlled verification tasks. If the review passes, the vulnerability status is updated to "Closed." If the review fails, the vulnerability status remains open, and the verification task parameters are updated. In cases where handling results are missing or the handling status conflicts with the verification status, the system generates a review status without updating the evaluation rules. This approach avoids deviations in subsequent candidate selection and risk assessment from the actual status due to errors in a single handling receipt.

[0051] The updated verification task parameters generated in this step are written into subsequent controlled verification tasks, and the updated evaluation rules are written into subsequent vulnerability evaluation results. In the next round of the process, S200 can read the candidate rule weighting results when generating a set of verifiable vulnerability candidates; S300 can read the updated verification strength, verification window, and fallback conditions when generating controlled verification tasks; and S500 can read the updated risk level generation rules when generating vulnerability evaluation results. Therefore, vulnerability verification results, review results, and handling results are not only recorded at the end of the process but also continuously participate in subsequent vulnerability candidate selection, task generation, and evaluation processing.

Claims

1. A method for joint evaluation of vulnerability discovery and verification in power systems, characterized in that, include: S100: Obtain power system asset data, communication topology data, vulnerability knowledge data, and operation status data; normalize the asset identity and business object in the power system asset data; associate the normalized asset identity with the communication link and access control rules in the communication topology data; and perform vulnerability knowledge matching with the vulnerability knowledge data to generate asset vulnerability association results. S200. Based on the asset vulnerability association results, the vulnerability association items are filtered according to network reachability, runtime constraints and vulnerability environment dependencies to generate a set of verifiable vulnerability candidates. S300. Based on the verifiable vulnerability candidate set, generate a controlled verification task by configuring the verification strength and rollback conditions according to the verification risk level, the target asset's operating status, and the verification window. S400. Execute the controlled verification task, collect verification response data, system indicators and behavior logs, and generate vulnerability verification results based on the verification judgment conditions. S500. Based on the vulnerability verification results and the impact on power services, combined with the importance of equipment and the dependency of communication links, generate vulnerability assessment results, and update the vulnerability status, verification task parameters and assessment rules according to the review results or handling results.

2. The method according to claim 1, characterized in that, The power system asset data includes asset identity, equipment type, equipment version, firmware version, open ports, communication protocols, and business roles; the communication topology data includes security partitions, communication links, access control rules, and business bearer relationships; the vulnerability knowledge data includes vulnerability number, affected objects, version range, triggering conditions, environmental dependencies, and patch information; and the operational status data includes online status, system load, system response time, communication status, and alarm data.

3. The method according to claim 1, characterized in that, The process of generating asset vulnerability association results includes: normalizing asset identities and business objects to generate asset-business mapping relationships; associating the asset-business mapping relationships with communication links and access control rules to generate communication link relationships; and matching the communication link relationships with vulnerability knowledge data in terms of version range, service features, and specification features to generate asset vulnerability association results containing asset identifiers, business object identifiers, communication link identifiers, and vulnerability knowledge entry identifiers.

4. The method according to claim 1, characterized in that, The process of generating a verifiable vulnerability candidate set includes: determining the network reachability of the communication path between the vulnerability verification source and the target asset based on security partitions and access control rules, and generating a reachability determination result; determining the operational status constraint of the target asset based on operational status data, and generating an operational constraint determination result; identifying vulnerability association items that simultaneously satisfy the reachability determination result, the operational constraint determination result, and the vulnerability environment dependency condition as verifiable vulnerability candidates, and generating a verifiable vulnerability candidate set.

5. The method according to claim 1, characterized in that, The process of generating a controlled verification task includes: configuring the verification intensity based on the target asset's operating status and verification risk level in the verifiable vulnerability candidate set; configuring the verification conditions based on the verification window and rollback conditions; and writing the verification object, verification method, verification conditions, verification intensity, verification window, and anomaly handling conditions into the controlled verification task.

6. The method according to claim 5, characterized in that, The abnormal handling conditions include verification suspension conditions, verification degradation conditions, verification postponement conditions, and verification blocking conditions. When the system load of the target asset exceeds the system load threshold, the system response time exceeds the system response time threshold, the target asset is in an alarm state, or the target asset is not within the verification window, the controlled verification task is suspended, downgraded, postponed, or blocked, and an abnormal log record is generated.

7. The method according to claim 1, characterized in that, The process of generating vulnerability verification results includes: collecting verification response data, system metrics, and behavior logs when executing the controlled verification task; matching the verification response data, system metrics, and behavior logs with the verification judgment conditions to generate vulnerability verification results including verification status, verification evidence, verification confidence level, and anomaly markers.

8. The method according to claim 1, characterized in that, The generation of vulnerability assessment results includes: determining the vulnerability status based on the vulnerability verification results; determining the scope of business impact based on the power business impact relationship; and generating vulnerability assessment results including risk level, scope of impact, and handling priority by combining equipment importance, communication link dependency, verification confidence level, and handling status.

9. The method according to claim 1, characterized in that, The updating of vulnerability status, verification task parameters, and evaluation rules includes: updating vulnerability status based on review results or handling results; downgrading the candidate rule weight of the corresponding vulnerability candidate generation rule when the review result corresponds to a false alarm flag; updating verification task parameters when the review result corresponds to a verification failure flag; and updating evaluation rules and generating rule update records when the review result corresponds to a change in risk level.

10. The method according to claim 9, characterized in that, The verification task parameters include verification strength, verification window, and rollback conditions; the evaluation rules include risk level generation rules corresponding to device importance, communication link dependency, verification confidence, and handling status; the verification task parameters are written into subsequent controlled verification tasks, and the evaluation rules are written into subsequent vulnerability evaluation results.

Images