Network security intelligent checking method and system for power monitoring system

Abstract

The application provides a power monitoring system network security intelligent verification method and system, relates to the power grid safety control technical field, and the method comprises the following steps: extracting inherent attribute features of an upgrade package file and multi-dimensional operation features of a corresponding device for the upgraded package after access, and establishing a correlation representation of device states and upgrade package attributes; combining component dependency knowledge graph and a safety risk case library, determining an upgrade risk level based on the correlation representation of device states and upgrade package attributes, and determining an adaptive verification strategy according to the risk level; verifying the upgraded package after access and the corresponding device to be upgraded according to the adaptive verification strategy, if the verification fails, performing hierarchical interception and triggering an alarm; if the verification is passed, issuing an encrypted deployment instruction, and monitoring the application restart state in real time, through the construction of a whole-process safety control closed loop, effectively balancing the upgrade safety of the power monitoring system and the operation and maintenance efficiency.

Description

Technical Field

[0001] This application relates to the field of power grid security management and control technology, and more specifically, to a network security intelligent verification method and system for power grid monitoring systems. Background Technology

[0002] With the continuous advancement of digital transformation of power industrial control systems, the version iteration and function upgrade operations of power monitoring systems are becoming increasingly frequent. Security verification during the upgrade process has become a key component of network security protection, directly affecting the stability of power grid operation and business continuity.

[0003] The current power monitoring system upgrade verification has formed a basic protection system, which can generally realize the verification of the source of upgrade packages and the verification of file integrity. Some solutions have added component version matching checks, and batch upgrade scenarios are also equipped with corresponding verification processes and abnormal alarm mechanisms.

[0004] However, in practical applications, existing technologies still have many limitations, making it difficult to simultaneously meet the dual requirements of high-reliability protection and efficient operation and maintenance. Firstly, the verification mode is relatively fixed, failing to adapt to the differentiated protection requirements of different upgrade scenarios, easily leading to resource redundancy or insufficient protection. Secondly, the risk assessment dimensions are relatively singular, insufficiently considering the adaptability to the upgrade operating environment, and the accuracy of risk judgment needs improvement. Thirdly, the verification scheduling and anomaly handling methods in batch upgrade scenarios are relatively crude, easily exacerbating system resource consumption and interfering with the normal operation of core businesses. Fourthly, the protection scope is mostly concentrated in the pre-upgrade verification stage, with insufficient coverage of security control over upgrade execution and subsequent operational stages, failing to form a complete end-to-end protection closed loop.

[0005] In summary, existing power monitoring system upgrade and verification technologies still have shortcomings in terms of scenario adaptability, risk assessment accuracy, batch control efficiency, and end-to-end protection capabilities, and urgently need further optimization to meet the ever-increasing security protection and operation and maintenance management needs of the power industry. Summary of the Invention

[0006] To address the aforementioned technical issues, this invention provides a network security intelligent verification method and system for power monitoring systems. It constructs a mechanism for precise assessment and hierarchical control of upgrade risks, quantifies upgrade risk levels by combining component dependencies and historical operation and maintenance data, and dynamically adapts differentiated verification strategies and strengths based on risk levels. For batch upgrade scenarios, it optimizes verification scheduling rules based on real-time equipment load, and includes a hierarchical interception and alarm handling mechanism. Simultaneously, it covers the entire process of upgrade deployment command transmission and application operation status monitoring, forming a closed-loop security protection system throughout the upgrade lifecycle. This effectively improves the operation and maintenance efficiency of batch upgrades while ensuring the security and reliability of power monitoring system upgrades, achieving a balanced improvement in security protection and operation and maintenance efficiency.

[0007] This application provides a network security intelligent verification method for a power monitoring system, the method comprising: Perform compliance screening of upgrade packages and identify the basic attributes of the equipment to be upgraded through the power equipment profile database to complete the access determination of upgrade tasks; After the upgrade package is applied, the inherent attribute features of the upgrade package file and the multi-dimensional operating features of the device are extracted from the corresponding device, and the association between the device status and the upgrade package attributes is established. By combining the component dependency knowledge graph and the security risk case library, the upgrade risk level is determined based on the correlation between device status and upgrade package attributes, and the appropriate verification strategy is determined according to the risk level. The upgrade package and the corresponding device to be upgraded are verified according to the adapted verification strategy. If the verification fails, a tiered interception is performed and an alarm is triggered. If all verifications pass, an encrypted deployment command is issued and the application restart status is monitored in real time. The encrypted deployment instructions are generated using domestically developed commercial cryptographic algorithms.

[0008] This application achieves pre-entry approval by combining upgrade package compliance screening with device profile attribute recognition, filtering out non-compliant upgrade tasks at the source and solidifying the foundation for pre-protection of upgrade security. By extracting multi-dimensional features of upgrade packages and devices and constructing a correlation representation between the two, it establishes a data link between upgrade package attributes and device operating status, providing comprehensive data support for upgrade risk assessment and effectively improving the accuracy of hidden risk identification. Through the collaborative application of component dependency knowledge graphs and security risk case libraries, it achieves scientific determination of upgrade risk levels and dynamically adapts differentiated verification strategies based on risk levels. This avoids resource redundancy and low operation and maintenance efficiency caused by full verification in low-risk scenarios, while ensuring verification depth and protection reliability in high-risk scenarios, achieving a balance between security protection and operation and maintenance efficiency. Through the supporting design of hierarchical interception alarms, encrypted deployment command transmission, and application restart status monitoring, security control covers the entire process from upgrade verification and deployment execution to operation monitoring, forming a complete upgrade security control closed loop, comprehensively improving the security, compliance, and batch operation and maintenance control efficiency of power monitoring system upgrade operations.

[0009] In one embodiment, establishing the association between device status and upgrade package attributes includes: Security identification features and resource constraint features are extracted from the upgrade package side, and security partition attribute features and operating condition features are extracted from the corresponding equipment to form four heterogeneous feature sets. One-hot encoding is performed on the discrete features of the four types of heterogeneous feature sets, and the continuous features are standardized to generate a standardized feature dataset. The global identity code of the power equipment and the unique version signature of the upgrade package are extracted from the standardized feature dataset as the core association key. Based on the dual-core associated primary key extracted above, a bidirectional mapping index is built between the standardized features of the equipment and the standardized features of the upgrade package; Based on the bidirectional mapping index, three sets of security constraint relationships are marked: security partitions and access permissions, device components and upgrade package components, and operating load and resource consumption. Risk weights are assigned to each set of constraints. Using the bidirectional mapping index as the row and column association benchmark, the security constraint relationships of each group with risk weights are mapped to matrix elements, and a structured security constraint association matrix between the device and the upgrade package is generated.

[0010] This step extracts and standardizes multi-dimensional heterogeneous features of devices and upgrade packages, establishing a bidirectional mapping index using the device's global identity code and the upgrade package's unique version signature. It then generates a security constraint association matrix by combining three types of security constraints in the power scenario with their corresponding risk weights. On one hand, this unifies the format of multi-source heterogeneous data, establishing a data link between device operating conditions and upgrade package attributes, enabling accurate bidirectional matching and retrieval of devices and upgrade packages in batch upgrade scenarios. On the other hand, it quantifies the power industry's zoning, component, and load security rules into a computable matrix carrier, improving the accuracy of identifying hidden upgrade risks, making risk level determination objective and traceable, and providing reliable data support for dynamic hierarchical verification strategies.

[0011] In one embodiment, the step of combining the component dependency knowledge graph and the security risk case library to determine the upgrade risk level based on the association between device status and upgrade package attributes includes: The security constraint association matrix between the device and the upgrade package is retrieved, and the pre-built component dependency knowledge graph and power industrial control security risk case library are called simultaneously to complete the interface connection of multi-source data. Based on the component dependency knowledge graph, the component constraint items in the security constraint association matrix of the device and the upgrade package are traversed to analyze the full-link dependency relationship between the existing components of the device and the newly added components of the upgrade package, and the component adaptation risks of version conflict and dependency missing are identified. At the same time, based on the power industrial control security risk case library, historical operation and maintenance data that meet the three conditions of the security partition being consistent with the current upgrade task, the device model being matched, and the upgrade package version being corresponding are retrieved, and the corresponding risk factors and the probability of occurrence of historical risks are extracted respectively. The comprehensive risk score for this upgrade task is calculated by weighting the risk weights of each group in the security constraint association matrix between the device and the upgrade package as the base coefficients, superimposing the component adaptation risks of version conflict and dependency missing categories, and superimposing the corresponding risk factors and the probability of occurrence of historical risks. The upgrade risk level is then obtained accordingly.

[0012] In one embodiment, determining an appropriate verification strategy based on the risk level includes: The system receives the upgrade risk level output and retrieves the graded verification strategy template library to match the basic verification strategy corresponding to the current upgrade risk level, including: For low-risk levels, the basic verification mode is enabled, while application identity verification and file integrity verification are retained; For medium-risk levels, standard verification mode is enabled, including application identity verification, file integrity verification, and component compatibility verification. For high-risk levels, an enhanced verification mode is enabled, which, in addition to enabling application identity verification, file integrity verification, and component compatibility verification, reduces the judgment thresholds for each verification.

[0013] In one embodiment, enabling the basic verification mode for low-risk levels while retaining application identity verification and file integrity verification specifically means: In batch upgrade scenarios, batch verification of application identity legitimacy is performed on all devices to be upgraded in the current upgrade batch: this includes matching the global identity code of each device one by one based on the pre-stored whitelist of authorized devices in the power monitoring system, verifying the device's upgrade authorization qualification, and blocking unauthorized devices that do not have upgrade permissions; Perform file integrity verification on the upgrade package corresponding to the device that has passed identity verification: This includes performing full hash verification of the upgrade package and official digital signature verification based on domestic commercial cryptographic algorithms to confirm that the upgrade package has not been tampered with and that its source is legal and compliant.

[0014] In one embodiment, enabling the standard verification mode for medium-risk levels, and activating application identity verification, file integrity verification, and component compatibility verification, specifically involves: For all devices in the current upgrade batch, the application identity is verified and the file integrity is checked. Then, the upgrade packages that pass the file integrity check are checked for component compatibility with the corresponding devices. This includes calling the component dependency knowledge graph, comparing the existing component versions on the device with the built-in component versions in the upgrade package, parsing the end-to-end dependency matching relationship between the two, identifying upgrade tasks with version conflicts and missing dependencies, and blocking upgrade packages that do not meet the component adaptation requirements.

[0015] In one embodiment, the determination threshold for each validation step of the narrowing process includes: For application identity verification, only global identity codes within the core authorized device library are allowed to be matched, while upgrade qualifications for temporary authorized devices and cross-regional authorized devices are excluded. For file integrity verification, full file segment-by-segment hash verification and multi-level digital signature cross-verification are performed, and the legitimacy verification of the upgrade package distribution channel is added. For component compatibility verification, it is required that the existing components on the device and the built-in components in the upgrade package are fully matched in version. Upgrade tasks with minor version compatibility issues or missing dependencies are prohibited from passing.

[0016] In one embodiment, if the verification fails, tiered interception is performed and an alarm is triggered, specifically including: For low-risk verification failures, a single-task interception is performed to block the upgrade task execution process of the corresponding device. At the same time, a regular alert is triggered to the operation and maintenance management platform, and the abnormal information is recorded and archived. For items that fail verification at the medium-risk level, the associated devices in the same batch will be blocked, thus interrupting the upgrade process of the current device and the associated devices of the same type in the same batch. At the same time, an important warning alarm will be triggered to the operation and maintenance management platform and pushed to the corresponding operation and maintenance manager. For high-risk items that fail verification, the entire batch upgrade task will be blocked, the execution process of all current upgrade batches will be suspended, and an emergency security alarm will be triggered to the operation and maintenance management platform, which will be simultaneously pushed to the security management person in charge and the system operation and maintenance supervisor.

[0017] In one embodiment, if all verifications pass, an encryption deployment command is issued, and the application restart status is monitored in real time, including: After confirming that all verification items pass the verification, an upgrade deployment instruction based on domestic commercial cryptographic algorithms is issued to the corresponding device to be upgraded. The instruction includes the upgrade execution sequence and running parameter configuration; the encrypted deployment instruction is generated based on domestic commercial cryptographic algorithms.

[0018] Throughout the entire lifecycle of application restart and deployment, the system collects process startup status data on the device in real time, synchronously collects core service operation status data, and collects system resource usage data. If a restart failure, core service operation abnormality, or system resource usage exceeding a preset threshold is detected, the system immediately triggers the corresponding level of operation and maintenance alarm and synchronously pushes the abnormality details data to the operation and maintenance management platform of the power monitoring system.

[0019] Based on the same inventive concept, this application also proposes a network security intelligent verification system for power monitoring systems, the system comprising: The upgrade task access module is used to perform compliance screening of upgrade packages and identify the basic attributes of the equipment to be upgraded through the power equipment profile database to complete the access determination of upgrade tasks. The feature extraction and association construction module is used to extract the inherent attribute features of the upgrade package file and the multi-dimensional operating features of the device from the upgraded package and the corresponding device after the upgrade package is applied, and to establish the association representation between the device status and the upgrade package attributes. The risk assessment and strategy adaptation module is used to combine the component dependency knowledge graph and the security risk case library to determine the upgrade risk level based on the correlation between device status and upgrade package attributes, and determine the appropriate verification strategy according to the risk level. The verification execution and deployment control module is used to perform verification on the upgrade package and the corresponding device to be upgraded after the application is approved according to the adapted verification strategy. If the verification fails, it will perform hierarchical interception and trigger an alarm. If all verifications pass, it will issue an encrypted deployment command and monitor the application restart status in real time.

[0020] The beneficial effects of the embodiments in this application compared with the prior art are: First, it achieves differentiated and dynamic adaptation of verification strategies, effectively balancing security protection strength and operational efficiency. Addressing the issues of fixed and rigid verification models in existing technologies, which are prone to resource redundancy or insufficient protection, this application dynamically matches verification strategies of corresponding strength based on the upgrade risk level assessment results. In low-risk scenarios, it simplifies verification dimensions, reduces system computing power and bandwidth resource consumption, and improves the efficiency of batch upgrade operations; in high-risk scenarios, it strengthens verification depth and judgment standards, ensuring the reliability of upgrade protection and avoiding the drawbacks of a one-size-fits-all approach with fixed verification models.

[0021] Second, this application enhances the comprehensiveness and accuracy of risk assessment and strengthens the ability to identify hidden risks. Addressing the shortcomings of existing technology risk assessments, such as their limited dimensions and insufficient consideration of environmental adaptability, this application extracts inherent attributes from upgrade package files and multi-dimensional operational characteristics of equipment, constructing a correlation representation between the two to establish a data link between upgrade package attributes and equipment operating status. Simultaneously, it combines full-chain dependency analysis of components with historical operation and maintenance case data to support risk level determination, effectively identifying hidden risks related to component compatibility, improving the scientific rigor and accuracy of risk assessment, and providing a reliable decision-making basis for the dynamic adjustment of verification strategies.

[0022] Third, this application optimizes the flexibility of verification scheduling and the rationality of anomaly handling in batch upgrade scenarios. Addressing the issues of inefficient batch verification scheduling and simplistic anomaly handling mechanisms in existing technologies, this application dynamically adjusts verification concurrency rules based on the real-time operating load of the devices to be upgraded. This avoids exacerbating system resource consumption and interfering with the normal operation of core power monitoring services during high-load periods. Simultaneously, it incorporates a tiered interception and alarm response mechanism, matching differentiated interception ranges and alarm notification levels according to risk levels. This minimizes the impact on the overall upgrade progress while ensuring effective security protection, thereby improving the management efficiency and system stability of batch upgrades.

[0023] Fourth, this application constructs a closed-loop security management system covering the entire upgrade cycle, expanding the scope of security protection. Addressing the issue that existing technologies focus primarily on pre-upgrade verification and lack sufficient full-process control coverage, this application extends security management to cover the entire process from pre-upgrade access determination, tiered security verification, encrypted deployment command transmission to application restart and operational status monitoring. This ensures the security of deployment command transmission, preventing the risk of command tampering or misuse, and also allows for timely detection of service anomalies after the upgrade, forming a complete end-to-end security protection chain and comprehensively improving the overall security and controllability of power monitoring system upgrade operations. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a schematic flowchart of a network security intelligent verification method for a power monitoring system, provided as an embodiment of the present invention.

[0026] Figure 2 This is a schematic diagram of a network security intelligent verification system for a power monitoring system, provided as an embodiment of the present invention. Detailed Implementation

[0027] It should be understood that, when used in this application specification and the appended claims, the term includes indicating the presence of the described feature, integral, step, operation, element and / or component, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0028] It should also be understood that the terms used in this application specification and the appended claims refer to any combination of one or more of the associated listed items and all possible combinations, and include such combinations.

[0029] Example 1: like Figure 1 As shown, this application provides a network security intelligent verification method for a power monitoring system, the method comprising: S1: Perform compliance screening of upgrade packages and identify the basic attributes of the equipment to be upgraded through the power equipment profiling database to complete the access determination of the upgrade task; S2: Extract the inherent attribute features of the upgrade package file and the multi-dimensional operating features of the device from the upgrade package and the corresponding device after alignment, and establish a correlation representation between the device status and the upgrade package attributes; S3: Combining component dependency knowledge graph and security risk case library, determine the upgrade risk level based on the association between device status and upgrade package attributes, and determine the appropriate verification strategy based on the risk level; S4: Verify the upgrade package and the corresponding device to be upgraded after the application is approved according to the appropriate verification strategy. If the verification fails, hierarchical interception is performed and an alarm is triggered. If all verifications pass, an encrypted deployment command is issued and the application restart status is monitored in real time.

[0030] In one embodiment, the specific implementation process of S1 is as follows: S101: Perform compliance screening of upgrade packages; Receive upgrade task requests initiated by the operations and maintenance team, obtain the upgrade package file to be verified, and perform three screening and verification steps in sequence: ① File Basic Format Verification: Read the header identifier bytes of the upgrade package to verify whether the file format conforms to the power monitoring system dedicated upgrade package specification. At the same time, check whether the file size deviates from the published nominal size within a preset threshold (e.g., ±0.1%). If the file format does not conform, the size deviation exceeds the limit, or there is file truncation or damage, the screening will be directly determined as failing. The power monitoring system dedicated upgrade package specification includes file format specifications, such as a special suffix .ecup, a fixed 4-byte identifier 0xEC0xSC0x0100 in the file header, a nominal file size of 100MB, and version or vendor specifications, but is not limited to these.

[0031] ② Basic Release Qualification Verification: Extract the manufacturer release number and version number fields carried by the upgrade package, verify whether the version number naming conforms to the three-stage version specification of the power monitoring system (major version number, minor version number, revision number), and at the same time check whether the releasing manufacturer is in the list of approved manufacturers of the power monitoring system, and whether the upgrade package version is an officially announced valid release version, and exclude upgrade packages released through irregular channels or informally from entering the subsequent stages. ③ Fast Blacklist Filtering: The entire binary data of the .ecup power upgrade package is read, and the SHA256 algorithm is used to generate a fixed-length 256-bit hash digest as the unique fingerprint of the upgrade package. This hash digest is then quickly compared with a pre-stored blacklist of known malicious upgrade packages, violating versions, and recalled versions. Upgrade packages that match the blacklist are immediately deemed to have failed the screening and their records are retained. Each record in the blacklist stores: the upgrade package's SHA256 hash, the risk type (malicious / vulnerability violation / vendor recall), the corresponding version number, and a risk description. By calculating the hash of the current upgrade package and performing batch fast matching with the hashes in the blacklist, if a match is found (meaning the package is on the blacklist), the entire verification process is immediately terminated, and the screening is deemed a failure.

[0032] S102: Identify the basic attributes of the equipment to be upgraded through the power equipment profile database; The global identity code of the device to be upgraded is extracted from the upgrade task request. The pre-built power equipment profile library is called, and the full set of basic attribute data of the corresponding device is retrieved by matching the global identity code as the primary key. The power equipment profile library is pre-built based on the power monitoring system's network-wide equipment ledger and stores the basic attribute information of all devices, including the device type (dispatch workstation, measurement and control device, relay protection device, communication gateway, etc.), the security zone to which it belongs (production control zone / management information zone), the current running software version, the device authorization level, the operation and maintenance responsibility entity, the service life, historical upgrade records, and abnormal record fields.

[0033] S103: Access determination for completing the upgrade task; Based on the upgrade package screening results and the basic attributes of the equipment, a comprehensive access determination is performed: If the upgrade package screening passes all tests, and the device simultaneously meets all of the following admission criteria, the upgrade task is deemed to have passed the admission process and will proceed to the subsequent feature extraction stage: ① The security zone to which the equipment belongs is consistent with the security zone applicable to the upgrade package, which meets the security protection zone control requirements of the power monitoring system; ② The current software version of the device belongs to the upgradeable version range supported by the upgrade package. Downgrading or upgrading across major versions is prohibited. ③ The equipment has the authorization qualifications for the corresponding upgrade operation and does not fall under the category of equipment that is prohibited from being upgraded, such as those subject to operation and maintenance freeze or power supply protection.

[0034] If the upgrade package screening fails any item, or if any of the device's access conditions are not met, the upgrade task is deemed unacceptable, the upgrade task is rejected directly, the reason for rejection is recorded, and the information is simultaneously pushed to the operation and maintenance management platform for filing.

[0035] In one embodiment, establishing the association between device status and upgrade package attributes in S2 includes: S201: Extract security identification features and resource constraint features from the upgrade package side, and extract security partition attribute features and operating condition features from the corresponding equipment to form four heterogeneous feature sets; In this embodiment, differentiated features are extracted from both the upgrade package and the device to be upgraded, forming four types of heterogeneous feature sets, specifically including: Upgrade package dimension: Extract security identification features and resource constraint features; among them, security identification features include upgrade package digital signature, vendor number, version signature, and security access mark; resource constraint features include indicators such as upgrade package decompression storage usage, process runtime memory overhead, and peak CPU usage; Device dimension: Extract security partition attribute features and operating condition features; among which, security partition attribute features include the device's partition affiliation, access permission level, and cross-region interaction restriction identifier; operating condition features include the device's real-time CPU load, memory usage, online business concurrency, and long-term steady-state parameters.

[0036] S202: Perform one-hot encoding on the discrete features of the four types of heterogeneous feature sets, standardize the continuous features to generate a standardized feature dataset, and extract the global identity code of the power equipment and the unique version signature of the upgrade package from the standardized feature dataset as the core association key. In this embodiment, a unified numerical conversion is performed on the four types of heterogeneous feature sets collected to distinguish data types: For discrete classification features such as security partition type, manufacturer number, component model, and authorization level, a one-hot encoding method is used to convert them into binary numerical vectors, eliminating the problem that text labels cannot participate in the calculation; For continuous numerical characteristics such as device CPU load, memory usage, upgrade package storage overhead, and peak operating resource consumption, Z-Score standardization is used to unify the units and eliminate calculation bias caused by differences in the numerical ranges of different indicators. After all features are encoded and standardized, they are integrated to generate a standardized feature dataset in a unified format; Within the standardized feature dataset, two globally unique identifiers are selected as binding primary keys: the global identity code of the power equipment and the unique version signature of the upgrade package. Both types of primary keys have the characteristic of being globally unique and serve as the unique anchor points for associating equipment with upgrade package data.

[0037] S203: Based on the extracted dual-core association primary key, construct a bidirectional mapping index between the standardized features of the device and the standardized features of the upgrade package; the bidirectional mapping index includes: Forward Index: Using the device's global identity code as the index key, quickly query all standardized features of the upgrade packages bound to the device.

[0038] Reverse index: Using the unique version signature of the upgrade package as the index key, batch match all the operating characteristics of all devices that are compatible with the upgrade package and are to be upgraded.

[0039] S204: Based on the bidirectional mapping index, mark three sets of security constraint relationships: security partitions and access permissions, device components and upgrade package components, and operating load and resource consumption, and assign risk weights to each set of constraints, specifically including: Security partitioning and access permission constraints (preferred weight 0.4): Control security risks of partitions such as upgrades across production control zones and management information zones, and unauthorized access; Device component and upgrade package component constraints (preferred weight 0.4): Control the software and hardware compatibility risks such as version conflicts between existing components and newly added components in the upgrade package, and missing underlying dependencies; Operating load and resource consumption constraints (preferred weight 0.2): Controlling the upgrade process to avoid consuming business resources and the risk of business interruption caused by upgrading under high equipment load; Each set of constraints, its corresponding weights, and the device-upgrade package pairing relationship are bound and stored in the index entry.

[0040] S205: Using the bidirectional mapping index as the row and column association basis, the security constraint relationships of each group with risk weights are mapped to matrix elements to generate a structured security constraint association matrix between the device and the upgrade package.

[0041] In this embodiment, a security constraint association matrix is ​​constructed using a bidirectional mapping index as the row and column basis, specifically including: Each row in the matrix corresponds to a power device to be upgraded within the index, identified by a global device identification code. The matrix columns correspond to the various version upgrade packages that match the device, identified by the unique version signature of each upgrade package; The three types of security constraints with risk weights attached to each pairing relationship are numerically mapped and filled into the elements inside the matrix; After all pairing constraints are filled, a structured security constraint association matrix of devices and upgrade packages that can be directly used for algorithm calculation is obtained, which serves as a standardized input data source for the subsequent risk level assessment module.

[0042] In one embodiment, step S3 combines a component dependency knowledge graph with a security risk case library to determine the upgrade risk level based on the association between device status and upgrade package attributes. The specific implementation process is as follows: S301: Retrieve the security constraint association matrix between the device and the upgrade package, synchronously call the pre-built component dependency knowledge graph and the power industrial control security risk case library, and complete the interface connection of multi-source data; In this embodiment, two sets of pre-built knowledge base data are synchronously pulled through a standardized internal interface: (1) Component dependency knowledge graph: The graph is pre-loaded with the upstream and downstream dependencies, compatible version ranges, and incompatible version lists of the drivers, service programs, middleware, and protocol components of the entire series of power monitoring equipment; the graph nodes are hardware and software components, and the edges are dependency, compatibility, and conflict associations; (2) Power industrial control security risk case library: The library stores past batch upgrade historical events of substations and dispatch master stations. Each case is bound to the security partition, equipment model, upgrade package version, fault type, impact of the fault, risk factor value, and historical fault statistics probability; three types of data are completed: security constraint association matrix, component dependency knowledge graph, and risk case library field alignment and data format unification, and a real-time data interaction channel is established.

[0043] S302: Based on the component dependency knowledge graph, traverse the component constraint items in the security constraint association matrix of the device and the upgrade package, analyze the full-link dependency relationship between the existing components of the device and the newly added components in the upgrade package, and identify component adaptation risks such as version conflict and dependency missing; simultaneously, based on the power industrial control security risk case library, retrieve historical operation and maintenance data that simultaneously meet the three conditions of the security partition being consistent with the current upgrade task, the device model being matched, and the upgrade package version being corresponding, and extract the corresponding risk factors and the probability of historical risk occurrence respectively; In this embodiment, the identification of component adaptation risks such as version conflict and dependency missing categories specifically includes: traversing all component constraint items corresponding to device and upgrade package pairings within the device and upgrade package security constraint association matrix, extracting the list of existing components for the device and the list of newly added components built into the upgrade package; recursively parsing the upstream and downstream dependencies of the entire component chain along the knowledge graph node edges, and verifying the component version matching relationship layer by layer; identifying two types of high-frequency hidden risks in industrial control: Version conflict risk: Incompatibility between the existing component versions on the device and the new component versions in the upgrade package may lead to API call anomalies and service crashes. Dependency missing risk: The underlying supporting components required by the new components in the upgrade package are not deployed locally on the device, and the functions cannot start normally after the upgrade; Furthermore, based on the conflicting or missing component level and the importance of the business, a standardized component risk coefficient is assigned to each identified component risk.

[0044] The search and filtering criteria are based on three key conditions for the current upgrade task: ① the security partition of the device is consistent with the case partition; ② the device hardware model is completely matched; ③ the upgrade package version number corresponds to the case upgrade package version. All historical upgrade and maintenance cases that meet all three matching conditions are selected, and irrelevant cases with mismatched scenarios are removed. Two types of core quantitative parameters are extracted from the matched cases: standardized risk factors and the historical probability of failure in this type of upgrade scenario. If there are multiple matching cases, the average risk factors and failure probabilities of multiple cases are taken as the benchmark value for this calculation.

[0045] S303: The comprehensive risk score of this upgrade task is calculated by weighting the risk weights of each group in the security constraint association matrix between the device and the upgrade package as the basic coefficients, superimposing the component adaptation risks of version conflict and dependency missing categories, and superimposing the corresponding risk factors and the probability of occurrence of historical risks, and the corresponding upgrade risk level is obtained.

[0046] In this embodiment, the pre-configured risk weights of three types of constraints—security partition, component, and load—are extracted from the security constraint correlation matrix as the basic weighting coefficients; then, the weighting calculation is completed. First layer: Multiply the component adaptation risk coefficient corresponding to component version conflict and missing dependency by the component constraint weight to obtain the component dimension risk score; The second layer: Multiply the risk factors of historical cases by the probability of historical failures, and add them to the total score calculation system; The third layer: integrates the basic risk scores corresponding to the security partition and resource load constraint weights, and summarizes them to obtain the unique comprehensive risk score for this upgrade task; The preset fixed score range is mapped to a risk level as follows: Overall score of 0-30: Low risk; Overall score of 31-70: Medium risk; Overall score of 71-100: High risk; Finally, the overall risk score and corresponding upgrade risk level of this upgrade task are output as the input basis for the next step of dynamically matching differentiated verification strategies.

[0047] In one embodiment, determining the appropriate verification strategy based on the risk level in step S3 includes: The system receives the upgrade risk level output and retrieves the graded verification strategy template library to match the basic verification strategy corresponding to the current upgrade risk level, including: For low-risk levels, the basic verification mode is enabled, while application identity verification and file integrity verification are retained; For medium-risk levels, standard verification mode is enabled, including application identity verification, file integrity verification, and component compatibility verification. For high-risk levels, an enhanced verification mode is enabled, which, in addition to enabling application identity verification, file integrity verification, and component compatibility verification, reduces the judgment thresholds for each verification.

[0048] In one embodiment, for low-risk levels, the system automatically retrieves the hierarchical verification strategy template library, enables the basic verification mode, and only performs two types of verification items: application identity legitimacy verification and file integrity verification. The specific execution process is as follows: In batch upgrade scenarios, a batch verification of application identity legitimacy is performed on all devices to be upgraded within the current upgrade batch. This includes verifying the global identity code, authorization validity period, and allowed upgrade version range of all devices authorized to perform upgrade operations based on a pre-stored whitelist of authorized devices in the power monitoring system. The global identity code of each device is matched one by one to verify the device's upgrade authorization qualification, and unauthorized devices without upgrade permissions are blocked. If the global identity code of a device is not included in the authorized whitelist, the device is determined to lack legitimate upgrade permissions, and the upgrade sub-task of that device is blocked separately. The device number, the reason for the block, and the data are recorded and stored in the audit log. Only devices that are successfully matched to the whitelist and have valid upgrade authorization proceed to the next stage of verification.

[0049] Perform file integrity verification on the upgrade packages corresponding to devices that have passed identity verification. This includes full hash verification of the upgrade package and official digital signature verification based on domestically developed commercial cryptographic algorithms to confirm that the upgrade package has not been tampered with and that its source is legitimate and compliant. Specifically, a unified dual verification of integrity and source legitimacy is performed based on domestically developed commercial cryptographic algorithms, using the SM3 hash algorithm and SM2 digital signature algorithm for verification. (1) Full hash verification of the upgrade package: Read all file data of the upgrade package, calculate the complete file hash digest using the SM3 domestic hash algorithm, and compare it with the standard hash value released by the manufacturer; if the two are inconsistent, it is determined that the upgrade package has been tampered with or the file is corrupted. (2) Official digital signature verification: Read the manufacturer's SM2 signature certificate built into the upgrade package, use the manufacturer's public key to verify the signature, and verify whether the signature is an official and valid signature; if the signature is invalid or forged, the source of the upgrade package is determined to be non-compliant.

[0050] Only when the full hash comparison is consistent and the SM2 digital signature verification is passed can the upgrade package be determined to be complete, tamper-proof, and of legitimate origin, and proceed to the subsequent deployment process; if any verification fails, the upgrade task for that device will be intercepted and a regular prompt alarm will be triggered.

[0051] In low-risk scenarios, only the basic verification mode is retained, greatly simplifying the verification process, reducing complex comparison calculations for component compatibility, and lowering the system's computing power and bandwidth resource consumption during batch upgrades; relying on the device's global identity code whitelist for batch verification, unauthorized and illegal devices are quickly filtered out; based on the national cryptographic algorithm, full hash and digital signature dual verification are completed, achieving tamper-proof and source-trusted verification of upgrade packages at low cost, effectively improving the overall verification efficiency of low-risk batch upgrade tasks while ensuring basic security.

[0052] In one embodiment, enabling the standard verification mode for medium-risk levels, and activating application identity verification, file integrity verification, and component compatibility verification, specifically involves: Based on the application identity legitimacy verification and file integrity verification of all devices to be upgraded in the current upgrade batch, the component compatibility verification is then performed on the upgrade packages that pass the file integrity verification and the corresponding devices. This includes calling the component dependency knowledge graph, comparing the existing component versions on the device with the built-in component versions in the upgrade package, parsing the full-link dependency matching relationship between the two, identifying upgrade tasks with version conflicts and missing dependencies, and blocking upgrade packages that do not meet the component adaptation requirements.

[0053] In this embodiment, the specific process of the execution component compatibility verification is as follows: The system invokes a pre-built component dependency knowledge graph to extract the current device's existing hardware and software component list, all components built into the upgrade package, and their corresponding version numbers. Based on the graph, it recursively parses the upstream and downstream dependencies of the components. (1) Compare the compatibility range of the existing component versions of the equipment with the newly added components in the upgrade package item by item, and identify the incompatible conflict items; (2) Traverse the dependency chain of the upgrade package components, verify whether all dependent supporting components are deployed locally on the device, and identify the risk of missing dependencies; If any compatibility issues such as version conflicts or missing dependencies are found during verification, the upgrade package is determined to be incompatible with the device, the corresponding upgrade task is intercepted, and the component exception details are retained. Only when all component dependencies are matched without any exceptions can the verification of this batch of devices be considered complete and proceed to the encrypted deployment and distribution stage.

[0054] In medium-risk scenarios, component compatibility checks are added on top of basic identity and file integrity checks. By relying on the component dependency knowledge graph, hidden risks in underlying software and hardware adaptation are explored, making up for the shortcomings of basic checks that can only identify surface tampering and illegal devices.

[0055] In one embodiment, for high-risk levels, an enhanced verification mode is enabled, and the threshold values ​​for limiting each verification step include: For application identity verification, only global identity codes within the core authorized device library are allowed to be matched. For devices holding temporary or cross-regional authorizations, their upgrade operation permissions are directly removed, and identity verification will not be passed even if they are in the ordinary whitelist. For devices that do not match the core library, single-device upgrade tasks are directly intercepted, and high-risk identity anomaly logs are simultaneously marked.

[0056] For file integrity verification, the logic of full single hash verification in low and medium risk scenarios is abandoned, and segmented verification is adopted: the upgrade package is split into segments of fixed fragment length, and the fragment hash of each segment is calculated using the SM3 domestic commercial cryptographic algorithm. The hash value of each segment is compared with the official fragment hash value. Multi-level digital signature cross-verification is superimposed, and the vendor's first-level release signature and the power grid security management platform's second-level verification signature are verified at the same time. The signature is considered valid only if both levels of signature verification are passed. An additional verification of the legality of the upgrade package release channel is added to verify whether the upgrade package transmission link and storage source are the power grid's officially designated trusted release server. If it comes from non-compliant channels such as the external network or temporary relay servers, the verification is directly judged to fail.

[0057] For component compatibility verification, the component dependency knowledge graph is invoked to perform a complete version comparison of the device's existing components and the components built into the upgrade package. The judgment criteria are tightened to a complete version match: compatibility solutions that only have the same major version but differ in minor versions are not allowed to pass the verification; all upstream and downstream dependency links are completely traversed, and if any layer of dependency components is missing or the version does not match, the component compatibility verification is directly judged to have failed; there is no lenient rule of allowing minor version compatibility, thus avoiding upgrade failures and security risks caused by component adaptation from the bottom layer.

[0058] If any of the identity, file, or component verifications fails to meet the tightened and stringent thresholds, the upgrade verification is deemed a failure. In accordance with the high-risk handling rules, the entire batch upgrade is blocked, triggering an emergency security alert that is pushed to the security management manager and system operations manager. The segmented hash records, multi-level signature verification logs, component version matching details, and release channel verification records are fully retained for security audit and tracing purposes.

[0059] To address high-risk upgrade scenarios, the verification and judgment thresholds have been tightened across the board, narrowing the scope of authorized devices, improving the accuracy of file tampering identification, and eliminating the fault tolerance space for component version compatibility. The security access threshold has been significantly raised from three layers: device access, file trust, and software and hardware adaptation. Through segmented hashing, multi-level cross-signing, and verification of release channels, multiple protections can be implemented to accurately identify malicious upgrade packages that are difficult to detect by conventional verification, such as fragmented tampering, forged secondary signatures, and illegal channels.

[0060] In one embodiment, the system performs identity, file, and component verification according to the verification strategy corresponding to the risk level. If any verification item fails to meet the corresponding level judgment standard, the verification is deemed to have failed. If the verification fails, tiered interception is executed and an alarm is triggered, specifically including: Scenario 1: Handling of low-risk level verification failure: For low-risk verification failures, a single-task interception is executed, blocking the upgrade task execution process of the corresponding device. At the same time, a regular alert is triggered to the operation and maintenance management platform, recording and archiving the abnormal information, including device characteristics, upgrade package SM3 hash value, verification comparison record, and reason for interception. Other compliant devices in the same batch are not affected and can continue to complete the remaining verification and deployment process normally. The alert content includes the device's global identity code, upgrade package version, verification failure item, and failure timestamp. The alert is only displayed on the platform interface and is not pushed to personnel via SMS or in-system messages.

[0061] Scenario 2: Handling of medium-risk level verification failure: For items failing verification at the medium-risk level, the system will block related devices in the same batch. In addition to blocking the devices that failed verification, the system will also block the upgrade process of the current device and related devices of the same type in the same batch, and suspend all upgrade processes for such devices. At the same time, an important warning alarm will be triggered to the operation and maintenance management platform. The alarm information will include detailed information on component conflicts / file anomalies / identity authorization anomalies and will be pushed to the corresponding operation and maintenance manager. Among these, devices of different models and different partitions within the same batch that are not related can be verified normally.

[0062] Scenario 3: Handling of high-risk level verification failure: For high-risk items that fail verification, all pending upgrade batches are immediately suspended, and all upgrade tasks are blocked. The execution of all current upgrade batches is halted, and no further verification or deployment actions are performed to prevent high-risk events from spreading to all power monitoring equipment across the network. Simultaneously, an emergency security alarm is triggered on the operation and maintenance management platform and pushed to the security management manager and system operation and maintenance supervisor. The alarm is marked with a high security risk level and includes a complete risk score, abnormal component dependencies, and upgrade package channel verification records.

[0063] In one embodiment, if all verifications pass, an encryption deployment command is issued, and the application restart status is monitored in real time, including: After confirming that all verification items pass the verification, an upgrade deployment command based on domestic commercial cryptographic algorithms is issued to the corresponding equipment to be upgraded. The command includes the upgrade execution sequence and operating parameter configuration. The complete plaintext command is encrypted and transmitted using the domestic commercial SM4 symmetric encryption algorithm, and an SM2 digital signature is attached to the command message header to prevent the command from being tampered with or hijacked during transmission. The encrypted deployment command is then sent point-to-point to each power equipment to be upgraded. The equipment decrypts and verifies the signature locally using a pre-stored national cryptographic key. The upgrade operation can only be started after the command is verified to be legal and valid.

[0064] Throughout the entire application restart and deployment lifecycle, real-time data on process startup status is collected from the device, along with synchronous data on the running status of core services and system resource usage. Specifically: (1) Process startup status data: Collect the creation, running and exit status of the upgrade program decompression process, system main program and business application process, and record the process startup time and process crash identifier; (2) Core service operation status data: heartbeat messages, online status, and packet loss rate of core power business services such as monitoring and dispatch communication, protection data interaction, and remote operation and maintenance; (3) System resource usage data: Real-time collection of device CPU usage, memory usage, disk read / write speed, and network bandwidth usage indicators. The system's built-in resource usage judgment thresholds (CPU 80%, memory 85%) are used as the criteria for anomaly judgment.

[0065] The system compares the collected data with the preset normal operation standards in real time. If a restart failure, abnormal operation of core services, or abnormal situation where system resource usage exceeds the preset threshold is detected, the corresponding level of operation and maintenance alarm is immediately triggered, and the abnormality details are pushed to the operation and maintenance management platform of the power monitoring system.

[0066] The alarm information includes the device's global identity code, upgrade package version, encrypted deployment instruction number, time of anomaly occurrence, real-time collected resource indicators, and process crash logs. All anomaly details are simultaneously uploaded to the power monitoring system operation and maintenance management platform for persistent archiving, and operation and maintenance personnel can view and export the anomaly audit records online.

[0067] If no anomalies are detected during the entire monitoring period, core services operate stably, and resource indicators remain within the threshold for an extended period, the platform automatically marks the upgrade task as complete, archives a full set of verification logs, encrypted command issuance records, and real-time operational monitoring data, forming a complete upgrade security control closed loop.

[0068] Example 2 like Figure 2 As shown, this application also proposes a network security intelligent verification system for power monitoring systems, the system comprising: The upgrade task access module is used to perform compliance screening of upgrade packages and identify the basic attributes of the equipment to be upgraded through the power equipment profile database to complete the access determination of upgrade tasks. The feature extraction and association construction module is used to extract the inherent attribute features of the upgrade package file and the multi-dimensional operating features of the device from the upgraded package and the corresponding device after the upgrade package is applied, and to establish the association representation between the device status and the upgrade package attributes. The risk assessment and strategy adaptation module is used to combine the component dependency knowledge graph and the security risk case library to determine the upgrade risk level based on the correlation between device status and upgrade package attributes, and determine the appropriate verification strategy according to the risk level. The verification execution and deployment control module is used to perform verification on the upgrade package and the corresponding device to be upgraded after the application is approved according to the adapted verification strategy. If the verification fails, it will perform hierarchical interception and trigger an alarm. If all verifications pass, it will issue an encrypted deployment command and monitor the application restart status in real time.

[0069] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A network security intelligent verification method for a power monitoring system, characterized in that, The method includes: Perform compliance screening of upgrade packages and identify the basic attributes of the equipment to be upgraded through the power equipment profile database to complete the access determination of upgrade tasks; After the upgrade package is applied, the inherent attribute features of the upgrade package file and the multi-dimensional operating features of the device are extracted from the corresponding device, and the association between the device status and the upgrade package attributes is established. By combining the component dependency knowledge graph and the security risk case library, the upgrade risk level is determined based on the correlation between device status and upgrade package attributes, and the appropriate verification strategy is determined according to the risk level. The upgrade package and the corresponding device to be upgraded are verified according to the adapted verification strategy. If the verification fails, a tiered interception is performed and an alarm is triggered. If all verifications pass, an encrypted deployment command is issued and the application restart status is monitored in real time. The encrypted deployment instructions are generated using domestically developed commercial cryptographic algorithms. The establishment of the association between device status and upgrade package attributes includes: Security identification features and resource constraint features are extracted from the upgrade package side, and security partition attribute features and operating condition features are extracted from the corresponding equipment to form four heterogeneous feature sets. One-hot encoding is performed on the discrete features of the four types of heterogeneous feature sets, and the continuous features are standardized to generate a standardized feature dataset. The global identity code of the power equipment and the unique version signature of the upgrade package are extracted from the standardized feature dataset as the core association key. Based on the dual-core associated primary key extracted above, a bidirectional mapping index is built between the standardized features of the equipment and the standardized features of the upgrade package; Based on the bidirectional mapping index, three sets of security constraint relationships are marked: security partitions and access permissions, device components and upgrade package components, and operating load and resource consumption. Risk weights are assigned to each set of constraints. Using the bidirectional mapping index as the row and column association benchmark, the security constraint relationships of each group with risk weights are mapped to matrix elements, and a structured security constraint association matrix between the device and the upgrade package is generated.

2. The intelligent network security verification method for a power monitoring system according to claim 1, characterized in that, The method of combining component dependency knowledge graphs and security risk case libraries to determine upgrade risk levels based on the correlation between device status and upgrade package attributes includes: The security constraint association matrix between the device and the upgrade package is retrieved, and the pre-built component dependency knowledge graph and power industrial control security risk case library are called simultaneously to complete the interface connection of multi-source data. Based on the component dependency knowledge graph, the component constraint items in the security constraint association matrix of the device and the upgrade package are traversed to analyze the full-link dependency relationship between the existing components of the device and the newly added components of the upgrade package, and the component adaptation risks of version conflict and dependency missing are identified. At the same time, based on the power industrial control security risk case library, historical operation and maintenance data that meet the three conditions of the security partition being consistent with the current upgrade task, the device model being matched, and the upgrade package version being corresponding are retrieved, and the corresponding risk factors and the probability of occurrence of historical risks are extracted respectively. The comprehensive risk score for this upgrade task is calculated by weighting the risk weights of each group in the security constraint association matrix between the device and the upgrade package as the base coefficients, superimposing the component adaptation risks of version conflict and dependency missing categories, and superimposing the corresponding risk factors and the probability of occurrence of historical risks. The upgrade risk level is then obtained accordingly.

3. The intelligent network security verification method for a power monitoring system according to claim 2, characterized in that, Determine the appropriate verification strategy based on the risk level, including: The system receives the upgrade risk level output and retrieves the graded verification strategy template library to match the basic verification strategy corresponding to the current upgrade risk level, including: For low-risk levels, the basic verification mode is enabled, while retaining application identity verification and file integrity verification. For medium-risk levels, standard verification mode is enabled, including application identity verification, file integrity verification, and component compatibility verification. For high-risk levels, an enhanced verification mode is enabled, which, in addition to enabling application identity verification, file integrity verification, and component compatibility verification, reduces the judgment thresholds for each verification.

4. The intelligent network security verification method for a power monitoring system according to claim 3, characterized in that, The provision that basic verification mode is enabled for low-risk levels, while retaining application identity verification and file integrity verification, specifically includes: In batch upgrade scenarios, batch verification of application identity legitimacy is performed on all devices to be upgraded in the current upgrade batch: this includes matching the global identity code of each device one by one based on the pre-stored whitelist of authorized devices in the power monitoring system, verifying the device's upgrade authorization qualification, and blocking unauthorized devices that do not have upgrade permissions; Perform file integrity verification on the upgrade package corresponding to the device that has passed identity verification: This includes performing full hash verification of the upgrade package and official digital signature verification based on domestic commercial cryptographic algorithms to confirm that the upgrade package has not been tampered with and that its source is legal and compliant.

5. The intelligent network security verification method for a power monitoring system according to claim 3, characterized in that, The above-mentioned standard verification mode is enabled for medium-risk levels, including application identity verification, file integrity verification, and component compatibility verification. For all devices in the current upgrade batch, the application identity is verified and the file integrity is checked. Then, the upgrade packages that pass the file integrity check are checked for component compatibility with the corresponding devices. This includes calling the component dependency knowledge graph, comparing the existing component versions on the device with the built-in component versions in the upgrade package, parsing the full-link dependency matching relationship between the two, identifying upgrade tasks with version conflicts and missing dependencies, and blocking upgrade packages that do not meet the component adaptation requirements.

6. The intelligent network security verification method for a power monitoring system according to claim 3, characterized in that, The threshold values ​​for each validation step in the narrowing process include: For application identity verification, only global identity codes within the core authorized device library are allowed to be matched, while upgrade qualifications for temporary authorized devices and cross-regional authorized devices are excluded. For file integrity verification, full file segment-by-segment hash verification and multi-level digital signature cross-verification are performed, and the legitimacy verification of the upgrade package distribution channel is added. For component compatibility verification, it is required that the existing components on the device and the built-in components in the upgrade package are fully matched in version. Upgrade tasks with minor version compatibility issues or missing dependencies are prohibited from passing.

7. The intelligent network security verification method for a power monitoring system according to claim 3, characterized in that, If the verification fails, tiered interception will be executed and an alarm will be triggered, specifically including: For low-risk verification failures, a single-task interception is performed to block the upgrade task execution process of the corresponding device. At the same time, a regular alert is triggered to the operation and maintenance management platform, and the abnormal information is recorded and archived. For items that fail verification at the medium-risk level, the associated devices in the same batch will be blocked, thus interrupting the upgrade process of the current device and the associated devices of the same type in the same batch. At the same time, an important warning alarm will be triggered to the operation and maintenance management platform and pushed to the corresponding operation and maintenance manager. For high-risk items that fail verification, the entire batch upgrade task will be blocked, the execution process of all current upgrade batches will be suspended, and an emergency security alarm will be triggered to the operation and maintenance management platform, which will be simultaneously pushed to the security management person in charge and the system operation and maintenance supervisor.

8. The intelligent network security verification method for a power monitoring system according to claim 3, characterized in that, If all verifications pass, an encrypted deployment command will be issued, and the application restart status will be monitored in real time, including: After confirming that all verification items have passed the verification, an upgrade deployment instruction based on domestic commercial cryptographic algorithms is sent to the corresponding device to be upgraded. The instruction includes the upgrade execution sequence and the configuration of running parameters. Throughout the entire lifecycle of application restart and deployment, the system collects process startup status data from the device in real time, synchronously collects core service operation status data, and collects system resource usage data. If a restart failure, core service operation anomaly, or system resource usage exceeding a preset threshold is detected, the system immediately triggers the corresponding level of operation and maintenance alarm and synchronously pushes the anomaly details to the operation and maintenance management platform of the power monitoring system.

9. A verification system for a network security intelligent verification method for a power monitoring system according to any one of claims 1-8, characterized in that, The verification system includes: The upgrade task access module is used to perform compliance screening of upgrade packages and identify the basic attributes of the equipment to be upgraded through the power equipment profile database to complete the access determination of upgrade tasks. The feature extraction and association construction module is used to extract the inherent attribute features of the upgrade package file and the multi-dimensional operating features of the device from the upgraded package and the corresponding device after the upgrade package is applied, and to establish the association representation between the device status and the upgrade package attributes. The risk assessment and strategy adaptation module is used to combine the component dependency knowledge graph and the security risk case library to determine the upgrade risk level based on the correlation between device status and upgrade package attributes, and determine the appropriate verification strategy according to the risk level. The verification execution and deployment control module is used to perform verification on the upgrade package and the corresponding device to be upgraded after the application is approved according to the adapted verification strategy. If the verification fails, it will perform hierarchical interception and trigger an alarm. If all verifications pass, it will issue an encrypted deployment command and monitor the application restart status in real time.

Images