Gray scale self-adaptive security policy generation method based on business logic
By adopting a business logic-based grayscale adaptive security policy generation method, the problems of static rigidity and business disconnect in traditional power systems are solved, realizing dynamic and secure policy management and improving the operational efficiency and stability of the power grid.
Patent Information
- Application Number
- CN202511158775.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-19
- Publication Date
- 2025-11-18
AI Technical Summary
Traditional power system security strategies are static and rigid, unable to adapt to dynamic business needs, lacking business context awareness, and the security strategy change process is inefficient and error-prone, resulting in a prominent contradiction between operational efficiency and security.
A business logic-based gray-scale adaptive security policy generation method is adopted. By parsing business logic instructions to generate a formal model, dynamic risk assessment is performed, and security policies are automatically generated and deployed in stages. Combined with continuous monitoring and automatic rollback mechanisms, a closed-loop management process is formed.
It achieves deep integration of security policies and business logic, improves the security and efficiency of policy changes, reduces the risk of configuration errors, and ensures stable operation and operational efficiency of the power grid.
Smart Images

Figure CN120979733A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The application belongs to the technical field of key infrastructure network security, and particularly relates to a gray-scale adaptive security policy generation method based on business logic. BACKGROUND
[0002] The network security system of the traditional power system has been established on the concept of physical isolation and static defense for a long time. The core strategy aims to resist external threats by building a solid boundary. In this mode, the security policy of the OT network tends to be fixed after deployment, and the policy is specifically the access control rules of the industrial firewall, the security configuration of the network device, etc. Any change in the policy needs to go through a long manual approval process and be completed manually by the operation and maintenance personnel within the scheduled downtime maintenance window. This way is effective in the past relatively closed and stable power grid environment.
[0003] However, with the promotion of the construction of "new power system" and "new industrialization", the power grid is undergoing a profound digital transformation. The communication protocol represented by the IEC61850 standard is widely used in substations, promoting the Ethernet interconnection of a large number of intelligent electronic devices (IED). At the same time, the integration of new technologies such as Internet of Things, artificial intelligence and 5G makes the business model of the power grid increasingly dynamic, intelligent and collaborative. This transformation, while improving operational efficiency, also poses serious security challenges: Fundamental conflict between static security policy and dynamic business demand: The traditional static and manually configured security policy update mechanism has a response speed of weeks or months, which is completely unable to match the dynamic business demand in minutes or hours. A temporary cross-regional dispatching instruction or an emergency remote device maintenance task may require temporary opening of specific network access permissions. Under the existing system, either the dynamic demand is rejected for security, or the security process is bypassed for operation, bringing huge security risks. This contradiction between operational agility and security rigidity has become one of the core bottlenecks restricting the development of digital power grids.
[0004] Security measures lack business context awareness: The existing security protection technology mainly bases its decision on network-level data and general threat intelligence, including IP addresses, ports and traffic characteristics, and specific security information and event management systems or basic security automation tools. These tools cannot understand the "business intent" behind network traffic. They cannot distinguish between a control instruction that belongs to a regular device round-trip or a high-risk power grid splitting operation. Therefore, their response measures are likely to be "one-size-fits-all", which can easily harm normal business and even trigger a chain of failures, posing a direct threat to the safe and stable operation of the power grid. The security posture is completely decoupled from the real business logic of the power grid.
[0005] High risk in policy deployment process and "black box" state: The change of security policy itself is a high-risk operation. A small configuration error, specifically, a key port is mistakenly blocked on the firewall, can cause the protection of a certain area to fail or the monitoring to be interrupted. The traditional manual deployment method completely depends on the experience and meticulousness of the person, which is not only inefficient, but also prone to errors. More importantly, the deployment process is a "black box" operation of "all or nothing", and once the policy takes effect, its impact immediately spreads to the whole network. The system lacks the mechanism of monitoring, verification and safe rollback during the deployment process, and once a problem occurs, the recovery process will be chaotic and high-pressure.
[0006] In the software engineering practice of the IT field, in order to reduce the risk of new version online, a mature "gray release" or "canary release" mechanism has been developed. This mechanism gradually introduces new versions into the production environment, realizes small-scale verification, continuous monitoring and rapid rollback, and effectively controls the change risk. However, this advanced and security deployment-centered concept has not been applied in the field of power grid OT security policy management.
[0007] In summary, the existing technology has a series of deep-seated problems such as static and rigid security policy, lack of business context awareness, and high change risk when dealing with the digital and dynamic business needs of the power grid. Therefore, there is an urgent need for an innovative method that can deeply integrate security policy with business logic and realize the safe and controllable process of policy change. SUMMARY
[0008] The main purpose of the present application is to overcome the above-mentioned defects of the prior art, and to provide a brand-new security policy generation and management method.
[0009] Specifically, the present application aims to solve the following technical problems: (1) The static and rigid characteristics of security policy in power grid OT network make it unable to adapt to dynamic and agile business needs.
[0010] (2) The security protection measures are disconnected from the actual business logic of the power grid, and lack understanding of the operation intent, resulting in insufficient effectiveness and security of the policy.
[0011] (3) The manual change process of security policy is inefficient and prone to errors, and the "all or nothing" deployment method brings great risk to the stable operation of the power grid.
[0012] To achieve the above object, the application provides a gray-scale adaptive security policy generation method based on business logic. The core idea of the method is to regard each adjustment of the security policy as support for a specific business logic, and to build an automated and closed-loop management process from risk assessment to security deployment around the business logic.
[0013] The method specifically comprises the following steps: The system automatically acquires and analyzes high-level business logic instruction sets, which are specifically "dispatching instructions" from a dispatching system or "device maintenance plans" from an operation and maintenance system. By using a predefined domain ontology and formalization method, these unstructured or semi-structured instructions are converted into a machine-readable and analyzable formalized business logic model, which is specifically a directed acyclic graph (DAG). The model accurately describes all operation tasks involved in the business, the sequence and dependency relationship between the tasks, and the specific OT network assets involved, including IEDs, servers and switches.
[0014] The system conducts a dynamic and context-related security risk assessment for the formalized business logic model. It associates the assets involved in the model with information such as their criticality and known vulnerabilities, and superimposes a threat model corresponding to the operation tasks, which is specifically an attack tree model, thereby calculating a quantitative risk value. The risk value is not a static asset risk, but a dynamic risk closely related to the specific business operation.
[0015] The system automatically generates a customized and multi-stage security policy deployment plan based on the formalized business logic model and the quantitative risk value, which the application refers to as a "gray-scale deployment strategy set". This is a structured workflow that breaks down the originally one-time policy change into multiple progressive stages such as simulation verification, passive monitoring, small-scale execution, full-scale promotion, etc. The higher the risk of the business operation, the more rigorous the corresponding policy set stage and the more complete the verification steps.
[0016] A security orchestration, automation and response (SOAR) engine is responsible for executing the above generated policy set. The engine, through linkage with security devices and monitoring systems in the OT network, safely and progressively applies new security policies according to the steps defined in the policy set, with the security devices specifically being firewalls and the monitoring systems specifically being SIEM. During the entire deployment process, the system continuously monitors key performance indicators (KPIs) and security risk indicators (KRIs), and predefines an automatic rollback trigger. Once any abnormality that may affect the stable operation of the power grid is monitored, the system will immediately suspend the deployment and automatically restore all configurations to the security state before deployment, forming a complete security closed loop.
[0017] The application further provides a system for implementing the method, which comprises a service logic formalization module, a dynamic risk assessment module, a self-adaptive strategy generation module and a gray deployment arrangement module, and each module cooperates to complete the method.
[0018] Compared with the prior art, the application has the following beneficial effects: 1. The generation source of the security policy is changed from a static network topology to dynamic service logic.
[0019] 2. The application creatively introduces the gray release idea in the IT field into the OT security management of the power grid.
[0020] 3. The entire process, from analyzing the service instruction to finally deploying the strategy, is highly automated, which liberates the security operation personnel from tedious, repetitive and error-prone manual configuration work, and enables them to focus on higher-level security analysis and threat hunting work.
[0021] 4. The application ensures that the security is enhanced without sacrificing the operation efficiency and stability of the power grid, guarantees the reliability of power supply, and avoids major power outage accidents and economic losses caused by policy change errors. BRIEF DESCRIPTION OF DRAWINGS
[0022] Figure 1 FIG. 1 is a system architecture diagram of a gray self-adaptive security policy generation system based on service logic according to an embodiment of the application.
[0023] Figure 2 FIG. 2 is a general flowchart of a gray self-adaptive security policy generation method based on service logic according to an embodiment of the application.
[0024] Figure 3 FIG. 3 is a formal directed acyclic graph model diagram of a power grid dispatching service logic in an embodiment of the application.
[0025] Figure 4 FIG. 4 is a phased structure diagram of a generated gray deployment strategy set in an embodiment of the application. DETAILED DESCRIPTION
[0026] For the purposes of making the objectives, technical solutions, and advantages of the present application clearer, further detailed descriptions of the present application will be given below in conjunction with the drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely intended to explain the present application, and are not intended to limit the present application.
[0027] Referring to Figure 1 The embodiment of the present application provides a service logic-based gray adaptive security policy generation system 100.
[0028] The system is usually deployed on a server of a power enterprise management information area, and the management information area is a safety II area or a safety III area divided according to a security protection regulation, and interacts with related equipment of a production control area through a secure interface. The system 100 mainly comprises the following core modules: A business logic formalization module (BLFM) 110: this module is the starting point of the whole process. It is responsible for interfacing with an upper-layer service system, and obtaining a set of to-be-executed business logic instructions, and the service system is specifically a power grid dispatching production management system (D-PMS), an equipment asset management system (EAM), or a maintenance work order system. The BLFM 110 internally embeds an analysis engine based on power field knowledge, which can convert semi-structured or unstructured business instructions into a formalized model readable by a machine, and the instructions are specifically dispatching orders in an XML format or work orders in a JSON format.
[0029] A dynamic risk assessment module (DRAM) 120: this module is responsible for quantitatively assessing the security risks of the formalized business logic. It internally maintains or connects an OT asset information library 121, a threat model library 122, and a vulnerability information library 123. The core function of the DRAM 120 is not to perform static and global risk assessment, but to dynamically calculate the incremental risk brought by a specific business operation in the context of the operation.
[0030] An adaptive policy generation module (APGM) 130: this module is the core of policy generation. It receives the formalized business logic model from the BLFM 110 and the quantitative risk value from the DRAM 120, and generates two key outputs by comprehensively considering the two inputs: one is a specific security policy configuration that can be deployed on a network device, and the configuration is specifically a firewall rule set; and the other is a gray deployment strategy set 140 for guiding the whole deployment process.
[0031] Gray-scale Deployment Orchestration Module (GDOM) 150: This module is the execution hub of the entire scheme, its functions are usually implemented by a security orchestration, automation and response (SOAR) platform. GDOM 150 parses and executes the policy set 140 generated by APGM 130. It communicates with and issues configuration instructions to network security devices 161 in the OT network 160 through standard interfaces, such as NETCONF or RESTful API, and the network security devices 161 are industrial firewalls or security gateways. At the same time, it also collects real-time feedback data from network monitoring systems 162 and performance monitoring tools for closed-loop monitoring and decision-making during deployment, and the network monitoring systems 162 are SIEM or NIDS.
[0032] Referring to Figure 2 The method flow provided by the embodiment of the application includes the following detailed steps: Step 201: Acquire and formalize business logic, the flow starts from the business logic formalization module (BLFM) 110 of the system 100 acquiring a set of business logic instructions to be executed. In the power grid environment, this is usually a dispatch instruction, an operation order or a device maintenance plan. These instructions define a series of operations that need to be performed in the OT network, and a specific operation is “switching the No. 2 main transformer of A substation from operation to maintenance”.
[0033] After acquiring the instructions, the BLFM 110 parses and formalizes them. This process is not simply text matching, but is based on a pre-constructed ontology in the field of power systems. The ontology follows industry standards such as the Common Information Model and IEC61850, and defines various entities in the power grid, their relationships and possible operations, the entities being transformers, circuit breakers and IEDs, the relationships being connections and protections, and the operations being closing, opening and reading settings. Through the ontology, the system can deeply understand the semantics of the instructions.
[0034] The final output of formalization is a directed acyclic graph (DAG), as shown in Figure 3 As a powerful data structure, DAG can clearly represent the dependency relationships in a complex workflow. In the present application, the DAG is constructed as follows: Nodes: Figure 3 The nodes in are divided into two categories. One category is task nodes, representing a specific operation step, identified by a prefix of T. The other category is asset nodes, representing physical or logical assets that perform tasks or are affected by tasks, identified by a prefix of A.
[0035] Edges: Directed edges connecting nodes represent the dependency between them. An edge from task node T1 to task node T2 means that task T2 must start after task T1 is completed, which is a temporal dependency. An edge from task node T2 to asset node A4 means that the operation of task T2 is on asset A4, which is a logical dependency.
[0036] By constructing such a DAG, the system converts a piece of human-readable business instruction into a structured, machine-analyzable computing object. This DAG model 300 not only contains the flow of operations, but also explicitly indicates the exact asset scope affected by each step, laying a solid foundation for subsequent contextual risk assessment.
[0037] Step 202: Perform contextual risk assessment. After obtaining the formalized business logic DAG 300, the dynamic risk assessment module (DRAM) 120 immediately initiates a contextual risk assessment for this specific business.
[0038] First, the DRAM 120 traverses all asset nodes in the DAG 300. For each asset node, it queries the OT asset information library 121 to obtain detailed information about the asset, including its criticality level in the power grid, device model, firmware version, and known CVE vulnerability information.
[0039] Next, the DRAM 120 dynamically loads one or more threat models, preferably attack tree models, for the entire business scenario represented by the DAG 300. If the DAG contains a task of "remote login to IED for setting value modification", the DRAM 120 will load an attack tree for IED remote access. The root node of this attack tree is "successfully tampering with IED setting value", and the leaf nodes are various specific attack means to achieve this goal, such as "using default password" or "using known firmware vulnerabilities".
[0040] Finally, the system combines asset information and threat models to perform quantitative risk calculation. The risk value (R) can be derived from a comprehensive formula: Where: traverses all affected assets in the DAG; is the criticality weight of asset i; is the potential impact on asset i after a successful attack, which is economic loss or power outage range; is the threat to asset i in the current business context . Probability of occurrence. This probability is dynamic and is influenced by the specifics of the current operation. An operation such as “opening a remote debugging port” will significantly increase the probability of an attack exploiting the associated vulnerability.
[0041] In this way, the risk value computed by the DRAM 120 is highly dynamic and context-dependent. It does not assess “how dangerous is this IED”, but rather “how dangerous is this sequence of operations performed in order to accomplish this dispatch task”.
[0042] Step 203: The set of grey deployment policies, together with the assessed risk value R, are passed to the Adaptive Policy Generation Module (APGM) 130, along with the business logic DAG 300. The core task of the APGM 130 is to generate a set of SOAR-executable grey deployment policies 140.
[0043] The complexity and rigor of this policy set is directly proportional to the risk value R. For low-risk operations, the policy set can be relatively simple; for high-risk operations, the policy set will contain more, and more stringent, verification stages. See Figure 4 , a typical policy set 400 for a high-risk operation can contain the following stages: Stage 401: Pre-deployment simulation verification, this stage is first performed on a digital twin model or simulation test platform of the OT network. The specific security policies generated by the APGM 130 are applied to this virtual environment, a specific policy being the one that allows the dispatch master IP to access the TCP 102 port of the target IED. Then, the system simulates the normal communication traffic defined in the business logic DAG 300, checking whether the new policy would erroneously block any legitimate communication. Only if the simulation verification passes, the flow proceeds to the next stage.
[0044] Stage 402: Passive monitoring, the policy is actually issued to the target security device 161 in the OT network 160, but it is working in “logging only” or “shadow” mode, the security device being specifically a firewall. In this mode, the policy rules only produce logs for matching traffic, without actually blocking or passing it. The GDOM 150 collects these logs and compares them to the expected traffic pattern in the DAG 300, to find any potential impact outside of expectations. This stage usually lasts for a pre-set time window, a specific time window being 15 minutes.
[0045] Stage 403: Limited-scope enforcement, after confirming that the shadow mode is correct, the policy is switched to “enforcement” mode, but its application scope is limited. This “limited scope” is intelligently chosen, the APGM 130 analyzes the business logic DAG 300, prioritizing assets with minimal impact as “canaries”. If there are primary and backup protection IEDs, the policy is first enforced on the links corresponding to the backup IED.
[0046] Stage 404: Automated Verification. After each critical stage, especially after stage 403, the policy set will contain an automated verification task. GDOM 150 can proactively initiate a simulated, legitimate business request to verify the end-to-end connectivity and correctness of the communication link and business function.
[0047] Stage 405: Full Promotion and Effectiveness. Only after all the previous stages are successfully completed and the automated verification is correct, the policy will be applied to all assets involved in the business logic DAG 300, officially and fully effective.
[0048] Stage 406: Continuous Monitoring and Rollback. This is a constant task throughout all stages. The policy set defines the key indicators that need to be monitored and the corresponding security thresholds. A specific KPI is "dispatch instruction delay", and a specific KRI is "abnormal increase in firewall blocking times". Once any indicator exceeds the threshold, the policy set will automatically trigger the rollback procedure to restore all device configurations to the state before deployment.
[0049] Step 204: Orchestrated Execution and Closed-loop Management, Finally, the gray-scale deployment orchestration module (GDOM) 150, i.e. the SOAR engine, is responsible for the landing execution of the entire process. It acts as a general commander, accurately executing each step in the policy set 140.
[0050] GDOM 150 interacts with heterogeneous devices in the OT network through various connectors integrated. It calls the API of the firewall to issue and modify rules, calls the interface of SIEM to query and analyze logs, and calls performance monitoring tools to obtain KPI data.
[0051] The entire execution process is fully automated and auditable. Every operation, every decision, and every state change is recorded in detail. This not only greatly improves efficiency, but also provides a complete chain of evidence for post-tracing and compliance review.
[0052] Most importantly, through continuous monitoring and pre-set automated rollback mechanisms, GDOM 150 forms a strong security closed loop. It transforms traditional, high-risk "open-loop" manual operations into a controllable, fault-tolerant "closed-loop" automated process. This adaptive, self-correcting capability ensures that while pursuing the agility of security policies, the core of the power grid - safe and stable operation - is given the highest priority.
[0053] In summary, the application constructs a new and intelligent power grid OT security policy management paradigm through four closely linked steps of service logic formalization, context risk assessment, gray-scale policy set generation and orchestrated execution. It not only solves many challenges faced by the prior art, but also provides an advanced, reliable and highly industrial value security protection scheme for the future highly dynamic and complex "new power system".
Claims
1. A method for generating grayscale adaptive security policies based on business logic, characterized in that, The method includes: Acquire the set of business logic instructions to be executed in the power system operation technology (OT) network; Based on the business logic instruction set, a formal business logic model is generated. The formal business logic model provides a structured representation of the operational tasks, dependencies between tasks, and affected OT network assets contained in the business logic instruction set. A contextual risk assessment is performed on the aforementioned situational business logic model to quantify the security risk value corresponding to the execution of the business logic instruction set; Based on the formal business logic model and the quantified security risk value, a gray-scale deployment strategy set is generated. The gray-scale deployment strategy set defines a multi-stage, monitored sequence for deploying the corresponding security strategy. The security orchestration engine executes the canary deployment policy set to apply the security policy to the OT network.
2. The method for generating a grayscale adaptive security policy based on business logic according to claim 1, characterized in that, The formal business logic model is specifically a directed acyclic graph (DAG), where the nodes of the DAG represent the operation tasks and the OT network assets, and the edges represent the temporal or logical dependencies between the operation tasks.
3. The method for generating a grayscale adaptive security policy based on business logic according to claim 2, characterized in that, The set of instructions for obtaining business logic includes: Receive dispatch instructions or equipment maintenance plans in semi-structured data format from the power grid dispatch production management system or operation and maintenance work order system; Furthermore, the semi-structured data is parsed using a predefined domain ontology based on the general information model of power systems and the IEC61850 standard to extract the operational tasks, dependencies, and OT network assets.
4. The method for generating a grayscale adaptive security policy based on business logic according to claim 1, characterized in that, The contextual risk assessment of the formal business logic model includes: The OT network asset nodes in the formal business logic model are associated with the asset information database, which contains the criticality level and known vulnerability information of the assets. For the operational tasks represented by the formal business logic model, the corresponding attack tree threat model is dynamically loaded. The security risk value is calculated by combining the criticality level and vulnerability information of the asset with the attack success probability of the attack tree threat model, wherein the security risk value is associated with a specific operational context during the execution of the business logic instruction set.
5. The method for generating a grayscale adaptive security policy based on business logic according to claim 1, characterized in that, The gray-scale deployment strategy set includes multiple stages executed sequentially, and the number and specific configuration of the stages are adaptively adjusted according to the security risk value; The aforementioned multiple stages specifically include: Pre-deployment simulation verification phase: The security policy to be deployed is applied to the digital twin model or simulation environment of the OT network to verify its ability to allow data flows corresponding to the business logic instruction set; Passive monitoring phase: Deploy the security policy to the target network device in logging-only mode and continuously monitor its logs to identify legitimate business traffic that may be blocked in enforcement mode; Limited-scope enforcement phase: Based on the non-critical or redundant OT network assets identified by the formal business logic model, the security policy is switched to enforcement mode and applied only to the non-critical or redundant OT network assets.
6. The method for generating a grayscale adaptive security policy based on business logic according to claim 5, characterized in that, The gray-scale deployment strategy set further includes: After each stage is executed, a series of verification operations are automatically performed to confirm that the core functions required by the business logic instruction set are not affected; It also defines an automated rollback trigger based on OT network key performance indicators (KPIs) and key risk indicators (KRIs). When the indicators deviate from the preset threshold during policy deployment, the deployment is automatically stopped and a rollback operation is performed to restore the network device configuration to the state before deployment.
7. The method for generating a grayscale adaptive security policy based on business logic according to claim 1, characterized in that, The security orchestration engine is specifically a Security Orchestration, Automation and Response (SOAR) platform. The SOAR platform is responsible for parsing and executing the grayscale deployment policy set and interacting with network security devices and monitoring systems in the OT network.
8. The method for generating a grayscale adaptive security policy based on business logic according to claim 1, characterized in that, The security policy is a set of configuration rules that conform to the IEC62443 industrial control system network security standard. The configuration rules are applied to network security devices, which may specifically be firewalls, intrusion detection systems, or network switches.
9. A gray-scale adaptive security policy generation system based on business logic, characterized in that, The system includes: The business logic formalization module is configured to acquire a set of business logic instructions to be executed in the power system operation technology (OT) network, and generate a formal business logic model based on the instruction set. The model provides a structured representation of the operational tasks, dependencies, and affected OT network assets. The dynamic risk assessment module is configured to perform contextual risk assessment on the formal business logic model to quantify the security risk value corresponding to the execution of the business logic instruction set; The adaptive policy generation module is configured to generate a gray-scale deployment policy set based on the formal business logic model and the quantified security risk value. The policy set defines a multi-stage, monitored sequence for deploying the corresponding security policy. The canary deployment orchestration module is configured to execute the canary deployment policy set through the security orchestration engine to apply the security policy to the OT network.
10. The system according to claim 9, characterized in that, The grayscale deployment orchestration module is further configured as follows: During each stage of executing the grayscale deployment strategy set, key performance indicators (KPIs) and key risk indicators (KRIs) from the OT network are continuously monitored. When any metric is detected to exceed the preset security threshold, the rollback mechanism is automatically triggered to restore the deployed security policy to its pre-deployment state and generate an alarm.