A power system transverse isolation and secure data transmission method and system

Abstract

The application relates to the technical field of power system network and information security, and discloses a power system horizontal isolation and safe data transmission method and system, which comprises the following steps: determining a production control security domain and a management information security domain, and configuring cross-domain business flow information; when transmission between the production control security domain and the management information security domain is needed, collecting cross-domain business flow information to which business data belongs and encapsulating the cross-domain business flow information into a safe self-description data unit; on a horizontal isolation path, obtaining header information to generate a session token; when the safe self-description data unit is forwarded, obtaining feature data and comparing the feature data with an associated session token, and forwarding when the feature data and the session token both satisfy a limited condition; maintaining a sliding time window and statistically processing the forwarded safe self-description data unit to identify abnormal behavior. The application realizes semantic level access control and dynamic protection of cross-domain business between the production control security domain and the management information security domain.

Description

Technical Field

[0001] This invention relates to the field of power system network and information security technology, and more specifically, to a method and system for horizontal isolation and secure data transmission in a power system. Background Technology

[0002] Power monitoring systems widely adopt a security architecture of "security zoning, dedicated networks, horizontal isolation, and vertical authentication." The production control security domain handles real-time operations such as dispatch monitoring, protection, and automatic devices, while the management information security domain handles non-real-time operations such as operation management, production management, and analytical decision-making. Horizontal isolation and secure data transmission between these two domains must be achieved through dedicated security products for power monitoring systems to meet national standards for power monitoring system security. Against this backdrop, security protection and data transmission control on the power monitoring network side are gradually evolving from traditional firewalls and intrusion detection to fine-grained access control and network behavior analysis.

[0003] In existing power network security protection solutions, most efforts focus on the connectivity and status detection of security devices themselves for horizontal isolation between the production control security domain and the management information security domain. For example, patent CN112383410B proposes to diagnose connection anomalies of forward isolation devices by collecting connection status, port status, and heartbeat information of the first and second regions, thereby improving the detection efficiency when internal and external network connection failures occur. However, these solutions mainly monitor the status of isolation devices at the network or host level, without providing a unified security self-description encapsulation for cross-domain business data. They lack a fine-grained control mechanism that establishes a baseline model of cross-domain business flows based on business intent tags and access object scope, and generates session tokens. Furthermore, they do not introduce cross-domain business flow timing behavior statistics based on sliding time windows and session token tightening or deactivation strategies driven by abnormal behavior on the horizontal isolation path. This makes it difficult to detect unauthorized access and frequency abnormal control behaviors through legitimate channels in a timely manner, and the problems of decoupling cross-domain business semantics from access constraints and difficulty in dynamically converging the session scope still exist.

[0004] Therefore, it is necessary to design a method and system for horizontal isolation and secure data transmission in power systems to solve the problems existing in the current technology. Summary of the Invention

[0005] In view of this, the present invention proposes a method and system for horizontal isolation and secure data transmission in power systems, aiming to solve the problem that the existing technology lacks fine-grained dynamic control based on cross-domain business flow semantics and access object scope, making it difficult to detect unauthorized access and frequency abnormal control behaviors performed through legitimate channels in a timely manner.

[0006] In one aspect, the present invention proposes a method for lateral isolation and secure data transmission in a power system, comprising:

[0007] In the power system, a production control security domain and a management information security domain are determined, and cross-domain business flow information is configured based on cross-domain business requirements. The cross-domain business flow information includes a cross-domain business flow identifier, a business intent tag, and an access object scope.

[0008] On the business data generation side, when business data needs to be transmitted between the production control security domain and the management information security domain, the cross-domain business flow information to which the business data belongs is collected, and the business data is encapsulated into a secure self-describing data unit. The header information of the secure self-describing data unit carries at least the cross-domain business flow information and the type of business instruction, and the business load carries the business data corresponding to the header information.

[0009] On the horizontal isolation path between the production control security domain and the management information security domain, the header information of the first security self-describing data unit is obtained, a session token is generated according to the pre-established cross-domain business flow baseline model, and the session token is associated with the cross-domain business flow identifier.

[0010] When forwarding the secure self-describing data unit on the lateral isolation path, the feature data of the secure self-describing data unit is obtained, and the feature data is compared with the associated session token. If the feature data satisfies the limiting conditions of the session token, the secure self-describing data unit is forwarded; otherwise, the secure self-describing data unit is blocked.

[0011] A sliding time window is maintained on a per-domain business flow basis. Time-series behavior statistics are performed on the security self-description data units forwarded within each sliding time window. Abnormal behavior is identified according to the behavior anomaly judgment rules. When abnormal behavior is identified, the access object range and quantity conditions limited by the corresponding session token are tightened or disabled, and subsequent security self-description data units belonging to the cross-domain business flow are blocked.

[0012] Furthermore, when defining the production control security domain and management information security domain in the power system, and configuring cross-domain service flow information based on cross-domain service requirements, this includes:

[0013] Collect asset information of various business systems and equipment in the power system. The asset information includes the security domain to which it belongs, business functions, industrial communication protocol type used, and identification of the object being operated.

[0014] Based on the asset information identification, the data interaction needs to be transmitted between the production control security domain and the management information security domain. According to the business function, the data interaction is divided into at least one business type among measurement uploading, operation status uploading, control command issuance, parameter adjustment and file issuance. A unique cross-domain business flow identifier is generated for each type of data interaction, and the corresponding business intent tag is selected for the cross-domain business flow from the preset business intent tag set.

[0015] Based on the identifier of the operated object involved in the cross-domain business flow, the scope of access objects is determined as a set of measurement point identifiers or a set of device identifiers, so that the same cross-domain business flow is fixedly associated with a unique cross-domain business flow identifier, business intent tag and scope of access objects.

[0016] Furthermore, when encapsulating business data into secure self-describing data units on the business data generation side, this includes:

[0017] The industrial communication protocol message corresponding to the business data is parsed to obtain the sending business system identifier, receiving business system identifier, business function and operated object identifier. Based on the sending business system identifier, receiving business system identifier, business function and operated object identifier, the cross-domain business flow information matching the business data is determined from the pre-configured cross-domain business flow information to obtain the cross-domain business flow identifier, business intent tag and access object range.

[0018] The production control security domain identifier, management information security domain identifier, cross-domain business flow identifier, business intent label, access object scope, and business instruction type are written into the header information of the security self-describing data unit. The industrial communication protocol message is written into the business load part of the security self-describing data unit, so that the same business data is transmitted in the form of a security self-describing data unit carrying a unified business meaning and access constraints when transmitted between the production control security domain and the management information security domain.

[0019] Furthermore, when generating a session token on the lateral isolation path between the production control security domain and the management information security domain, the following steps are included:

[0020] Based on the pre-collected cross-domain service configuration and historical security self-description data units, a cross-domain service flow baseline model is established according to the cross-domain service flow. The cross-domain service flow baseline model at least provides the normal service instruction type, normal access object range, normal session duration, and the upper limit of the number of security self-description data units passed within the normal session and the upper limit of the number of security self-description data units passed per unit time for the corresponding cross-domain service flow.

[0021] When the first security self-describing data unit arrives, parameters matching the cross-domain business flow identifier of the security self-describing data unit are selected from the cross-domain business flow baseline model. These parameters are used as the allowed business instruction types, allowed access object range, session validity period, and quantity-based access conditions limited by the session token, and the session token is associated with the cross-domain business flow identifier.

[0022] Furthermore, the generation of session tokens also includes:

[0023] Based on the importance of the business intent label, the scope of access objects, and the sensitivity of the business instruction type given in the cross-domain business flow baseline model, cross-domain business flows are divided into at least a first risk level and a second risk level.

[0024] When the cross-domain service flow belongs to the first risk level, the access scope limited by the session token is restricted to a single set of test points or a single set of devices, and the number of secure self-describing data units allowed to pass within the session and the number of secure self-describing data units allowed to pass within a unit time are restricted to a first quantity threshold range, and the session validity time is restricted to a first duration range; when the cross-domain service flow belongs to the second risk level, the access scope limited by the session token is restricted to multiple sets of test points or multiple sets of devices, and the number of secure self-describing data units allowed to pass within the session and the number of secure self-describing data units allowed to pass within a unit time are restricted to a second quantity threshold range, and the session validity time is restricted to a second duration range, wherein the first quantity threshold range is smaller than the second quantity threshold range, and the first duration range is shorter than the second duration range.

[0025] Furthermore, when forwarding secure self-describing data units on the lateral isolation path, the following is included:

[0026] For each security self-description data unit to be forwarded, read the type of business instruction and the access object in the header information, obtain the arrival time of the security self-description data unit on the horizontal isolation path, and determine the number of security self-description data units that have passed in the session and the number of security self-description data units that have passed within a preset unit time based on the number of security self-description data units that have been marked as forwarded in the current session and the number of security self-description data units that have been marked as forwarded within a preset unit time.

[0027] The service instruction type, access object, arrival time, number of secure self-describing data units passed within the session, and number of secure self-describing data units passed per unit time are used as feature data. These are compared item by item with the allowed service instruction types, allowed access object range, session validity time, maximum number of items within the session, and maximum number of items per unit time as defined by the associated session token. Only when all items corresponding to the feature data are within the limits defined by the session token are the secure self-describing data units marked as forwarded; otherwise, they are marked as blocked.

[0028] Furthermore, when a secure self-describing data unit is marked as blocked, it also includes:

[0029] Based on the project records in the feature data that cause the session token restriction conditions to be not met, the blocking reason is recorded as cross-domain business unauthorized access when the condition is not met (business instruction type or access object); as session scope exceeding limit when the condition is not met (session validity time or number of security self-description data units that have passed within the session); and as frequency abnormal when the condition is not met (number of security self-description data units that have passed within a unit time). The blocking reason is then associated with the corresponding cross-domain business flow identifier and session token identifier.

[0030] Furthermore, when maintaining a sliding time window on a per-domain business flow basis, it includes:

[0031] Set a sliding time window length and sliding step size for each cross-domain service flow. Within each sliding time window, perform time-series behavior statistics on the forwarded security self-description data units. The time-series behavior statistics include the number of security self-description data units belonging to control command issuance and parameter adjustment, the number of devices or measurement point sets accessed within the sliding time window, the minimum time interval between adjacent control commands or parameter adjustments, and the number of security self-description data units marked as blocked within the sliding time window.

[0032] According to the pre-configured abnormal behavior judgment rules, at least one of the following situations is judged as abnormal behavior: the number of control commands issued exceeds the number threshold, the number of accessed devices or the number of measurement point sets exceeds the object number threshold, the minimum time interval is lower than the time interval threshold, and the number of blocks exceeds the blocking number threshold. The sliding time window of the abnormal behavior is associated with the corresponding cross-domain business flow identifier and session token identifier.

[0033] Furthermore, upon identifying the abnormal behavior, the following steps are taken:

[0034] When the abnormal behavior is that the number of accessed devices or the number of measurement point sets exceeds the object number threshold, the scope of access objects limited by the corresponding session token will be narrowed from multiple measurement point sets or multiple device sets to a single measurement point set or a single device set.

[0035] When the abnormal behavior is that the number of control commands issued exceeds the number threshold or the number of blocked commands exceeds the number threshold, the number of secure self-describing data units allowed to pass within the session and the number of secure self-describing data units allowed to pass per unit time, which are limited by the corresponding session token, will both be reduced to the lower limit threshold.

[0036] When abnormal behavior occurs within multiple consecutive sliding time windows, the corresponding session token is deactivated. During the deactivation period, subsequent security self-describing data units belonging to the cross-domain service flow are blocked, and the deactivation information, the cross-domain service flow identifier, and the session token identifier are recorded.

[0037] Compared with existing technologies, the advantages of this invention are as follows: Using the production control security domain and management information security domain as boundaries, cross-domain business flow information is pre-configured around cross-domain business needs, solidifying the cross-domain business flow identifier, business intent tag, and access object scope. At the business data generation side, by parsing industrial communication protocol messages, each piece of business data is encapsulated into a secure self-describing data unit carrying the aforementioned business semantics and business instruction types. This allows the lateral isolation path to no longer only see network packets but also perceive which type of business is operating which objects. When the first cross-domain business occurs, a session token corresponding one-to-one with the cross-domain business flow identifier is generated based on the cross-domain business flow baseline model. During forwarding, the business instruction type, access object, arrival time, and the number of transactions within the session and per unit time are recorded. The system compares the number of secure self-describing data units (SSDIs) and other characteristic data with session token constraints item by item to achieve semantic-level access control for individual SSDIs. It maintains a sliding time window for cross-domain business flows, performs time-series behavior statistics on forwarded SSDIs, and triggers behavior anomaly detection accordingly. Upon detecting anomalies, it automatically tightens or disables the access object range and quantity conditions limited by the corresponding session token and blocks subsequent data. This forms an adaptive and convergent dynamic protection loop within the legitimate channel to control unauthorized access and frequency anomalies. This solves the shortcomings of existing technologies where cross-domain business semantics are decoupled from access constraints and fine-grained anomalies are difficult to detect in a timely manner based solely on equipment status monitoring, thus improving business security and protection accuracy in power system horizontal isolation scenarios.

[0038] On the other hand, this application also provides a power system lateral isolation and secure data transmission system for applying the above-mentioned power system lateral isolation and secure data transmission method, including:

[0039] The production control security domain and the management information security domain are connected by a lateral isolation path.

[0040] The production control security domain is equipped with a business data processing device. When business data needs to be transmitted between the production control security domain and the management information security domain, the business data processing device collects the cross-domain business flow information to which the business data belongs and encapsulates the business data into a secure self-describing data unit. The header information of the secure self-describing data unit carries the cross-domain business flow information and the type of business instruction, and the business load carries the business data corresponding to the header information.

[0041] A session control device is set up on the horizontal isolation path. The session control device is used to obtain the header information of the first appearance of the secure self-describing data unit, generate a session token according to the pre-established cross-domain business flow baseline model, associate the session token with the cross-domain business flow identifier, and obtain the feature data of the secure self-describing data unit when forwarding the secure self-describing data unit. The feature data is compared with the limiting conditions of the associated session token. If the feature data meets the limiting conditions, the secure self-describing data unit is allowed to pass. If the feature data does not meet the limiting conditions, the secure self-describing data unit is blocked.

[0042] The behavior monitoring device is used to maintain a sliding time window on a cross-domain business flow basis, perform time-series behavior statistics on the forwarded security self-description data units within each sliding time window, identify abnormal behavior according to behavior anomaly judgment rules, tighten or disable the access object range and quantity conditions limited by the corresponding session token when abnormal behavior is identified, and block subsequent security self-description data units belonging to the cross-domain business flow.

[0043] It is understandable that the aforementioned method and system for horizontal isolation and secure data transmission in power systems have the same beneficial effects, and will not be elaborated further here. Attached Figure Description

[0044] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0045] Figure 1 A flowchart illustrating a method for lateral isolation and secure data transmission in a power system, provided as an embodiment of the present invention;

[0046] Figure 2 This is a structural block diagram of a power system lateral isolation and secure data transmission system provided in an embodiment of the present invention. Detailed Implementation

[0047] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the disclosure to those skilled in the art. It should be noted that, unless otherwise specified, embodiments and features in the embodiments of the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0048] In the traditional horizontal isolation architecture of existing power monitoring systems, the business semantics and access constraints of cross-domain business flows are decoupled. Specifically, the business intent label fails to establish a dynamic binding mechanism with the scope of access objects, causing the session scope to fail to adaptively converge based on real-time transmission behavior. Furthermore, security policies lack fine-grained control capabilities at the business flow level during cross-domain data transmission. This means that horizontal isolation devices can only perform static monitoring based on network or host layer states, failing to identify unauthorized access behaviors and abnormally frequent control behaviors implemented through legitimate channels. This results in structural defects in the security protection system at the business semantic level, consequently affecting the overall system security and data transmission reliability.

[0049] For example, in a power dispatching and monitoring scenario, relay protection devices in the production control security domain need to transmit equipment status data to the operation management system in the management information security domain. When business data is transmitted across domains, because a unified secure self-describing encapsulation is not implemented for the business flow, the business intent label (such as "protection device status update") and the scope of access objects (such as circuit breaker equipment in a specific substation) are not associated with the data unit header. The lateral isolation device can only filter based on port status or heartbeat information. In this scenario, attackers can use legitimate business channels to send disguised data packets and perform unauthorized operations by frequently accessing unauthorized device objects. Existing isolation mechanisms lack the ability to analyze time-series behavior based on business intent and cannot detect such abnormal behavior patterns, leading to the risk of unauthorized operation penetration into the system.

[0050] If the above issues are not addressed, the security control of cross-domain business flows will continue to rely on static policy configurations, failing to achieve dynamic coupling between access constraints and business semantics. Furthermore, the security protection system will struggle to cope with covert attacks, allowing malicious operations to continuously penetrate through legitimate data channels. This could lead to damage to business data integrity or functional abnormalities, severely weakening the security isolation effectiveness of the power monitoring network.

[0051] For this, please refer to Figure 1As shown, this application proposes a method for lateral isolation and secure data transmission in a power system, including:

[0052] S100: In the power system, determine the production control security domain and the management information security domain, and configure cross-domain business flow information based on cross-domain business requirements. The cross-domain business flow information includes cross-domain business flow identifier, business intent label and access object scope.

[0053] S200: On the business data generation side, when business data needs to be transmitted between the production control security domain and the management information security domain, the cross-domain business flow information to which the business data belongs is collected, and the business data is encapsulated into a secure self-describing data unit. The header information of the secure self-describing data unit carries at least the cross-domain business flow information and the type of business instruction, and the business load carries the business data corresponding to the header information.

[0054] S300: On the horizontal isolation path between the production control security domain and the management information security domain, obtain the header information of the first security self-describing data unit, generate a session token based on the pre-established cross-domain business flow baseline model, and associate the session token with the cross-domain business flow identifier;

[0055] S400: When forwarding a Secure Self-Description Data Unit (SSDI) on a lateral isolation path, obtain the characteristic data of the SSDI, compare the characteristic data with the associated session token, and forward the SSDI if the characteristic data meets the limiting conditions of the session token; otherwise, block the SSDI.

[0056] S500: Maintains a sliding time window for cross-domain business flows, performs time-series behavior statistics on the forwarded security self-description data units within each sliding time window, identifies abnormal behavior according to behavior anomaly judgment rules, and tightens or disables the access object scope and quantity conditions limited by the corresponding session token when abnormal behavior is identified, and blocks subsequent security self-description data units belonging to cross-domain business flows.

[0057] In this embodiment, the business intent tag refers to a business semantic descriptor used to identify the purpose of a cross-domain business flow. In practical applications, it can be implemented using predefined business type codes, such as "device status monitoring" or "parameter adjustment request." Its main purpose is to bind the business semantics to the scope of the accessed object at the source, preventing the business intent from becoming disconnected from the operational boundary during cross-domain transmission. Specifically, the secure self-describing data unit refers to a data structure containing header information and business payload. It can be implemented using structured data formats such as JSON or XML. For example, the header carries the cross-domain business flow identifier and business instruction type, while the business payload carries the original business data content. Its main purpose is to ensure that data self-describing business meaning and constraints are maintained during transmission between the production control security domain and the management information security domain. The cross-domain business flow baseline model refers to a parameter range model established based on historical normal behavior. It can be implemented using statistical analysis methods or rule engine configuration. For example, it calculates the distribution threshold of normal business instruction types using historical data. Its main purpose is to provide a basis for generating session tokens. Furthermore, a session token refers to a verification credential associated with a cross-domain business flow identifier. It can be implemented using cryptographic tokens or digital signature technology, such as generating a token using the HMAC algorithm. Its primary purpose is to limit the types of business instructions, the scope of access objects, and the quantity conditions. On the lateral isolation path, feature data refers to data attributes used to verify whether a secure self-describing data unit meets the session token conditions. This can include the source address, timestamp, or data size of the data unit, such as recording the generation time and transmission delay of the data unit. Its primary purpose is to compare each item with the session token's limiting conditions. Therefore, this application tightly couples business semantics and access constraints from the source through a binding mechanism between business intent tags and the scope of access objects; ensures the integrity of business meaning in data transmission through secure self-describing data unit encapsulation; achieves fine-grained access control by generating session tokens based on the cross-domain business flow baseline model; performs real-time dynamic verification by comparing feature data with session tokens; and maintains a sliding time window for time-series behavior statistics on a cross-domain business flow basis, enabling the security policy to dynamically converge the scope and quantity conditions of access objects based on the results of abnormal behavior identification.

[0058] In the method of horizontal isolation and secure data transmission in power systems, the production control security domain and the management information security domain are clearly defined within the system first. Cross-domain business flow information is then configured based on cross-domain business requirements. This information includes cross-domain business flow identifiers, business intent tags, and the scope of access objects. This achieves tight coupling of business semantics and access constraints at the business source, avoiding the risk of unauthorized access caused by the separation of semantics and constraints in traditional solutions. When business data needs to be transmitted between the two domains, the cross-domain business flow information of the data generation side is collected, and the business data is encapsulated into secure self-describing data units. The header information carries cross-domain business flow information and business instruction types, while the business load carries the corresponding business data. This ensures that the data unit self-describes the business meaning and access constraints during transmission, preventing semantic loss or tampering during transmission. On the horizontal isolation path, the header information of the first secure self-describing data unit is obtained. A session token is generated based on a pre-established cross-domain business flow baseline model and associated with the cross-domain business flow identifier. This baseline model defines parameter ranges based on historical normal behavior, ensuring that the session token accurately matches the specific business flow characteristics. During forwarding, the feature data of the secure self-describing data unit is extracted and compared in real time with the associated session token constraint conditions. Forwarding is only performed when the feature data fully meets the session token constraint conditions; otherwise, it is blocked, thus achieving fine-grained access control. Furthermore, a sliding time window is maintained on a cross-domain business flow basis. The time-series behavior statistics of the forwarded secure self-describing data units within the window are performed, and abnormal behavior is identified according to the behavior anomaly judgment rules. Once an anomaly is identified, the scope and number of access objects restricted by the session token are dynamically tightened or disabled, and subsequent secure self-describing data units belonging to the same cross-domain business flow are blocked, so that the security policy adaptively converges with changes in business flow behavior.

[0059] In one specific embodiment, when the dispatch monitoring system transmits control commands to the operation management system, the cross-domain service flow information is configured with a cross-domain service flow identifier "CTRL_FLOW_1", a service intent label "control command issuance", and an access object scope of "circuit breaker set of substation 1". The service data is encapsulated into a secure self-describing data unit (SDG). The header information includes "CTRL_FLOW_1", "control command issuance", "circuit breaker set of substation 1", and "closing command", while the service load portion is an IEC 60870-5-104 protocol message. On the lateral isolation path, when this data unit first appears, a session token is generated, limiting the allowed service command type to "closing / opening", the access object scope to "circuit breaker set of substation 1", the session validity period to 10 minutes, and the maximum number of requests within a session to 20. Subsequent data unit characteristics, such as command type, access object, arrival time, number of requests passed within the session, and number of requests passed per unit time, are verified in real time. If a "opening command" is detected accessing "circuit breaker of substation 2", it is blocked. Meanwhile, the number of control commands and the number of accessed devices are counted within a sliding time window (e.g., a 5-minute window). If the number of control commands exceeds 15 or the number of accessed devices exceeds 5, the access scope of the session token is narrowed to a single circuit breaker.

[0060] Therefore, this method solves the problem of decoupling cross-domain business semantics and access constraints by binding the business intent label and the scope of access objects to the header of the security self-describing data unit, ensuring that business data always carries a unified business meaning and access constraints during transmission. At the same time, the time-series behavior statistics based on the sliding time window and the dynamic session token tightening mechanism enable the session scope to adaptively converge according to actual business behavior, timely identify and block unauthorized access and frequency abnormal control behavior through legitimate channels, and improve the security and policy adaptive capability of horizontal isolation in the power system.

[0061] Specifically, in some of the embodiments described above in this application, a constraint framework for configuring cross-domain business flow information to define cross-domain data transmission is proposed. However, in its implementation, if there is a lack of an automated identification and accurate configuration mechanism based on system asset information, it will lead to duplicate or conflicting cross-domain business flow identifiers, mismatch between business intent tags and actual business functions, and over-generalization or ambiguity of the scope of access objects. This will make it impossible for session token generation to accurately reflect business semantics, thereby causing misjudgment and omission of unauthorized access or abnormal behavior on the horizontal isolation path, making it difficult to achieve fine-grained business-level security control.

[0062] In this regard, this application further proposes a method for horizontal isolation and secure data transmission in power systems, including:

[0063] Collect asset information of various business systems and equipment in the power system. The asset information includes the security domain to which it belongs, business functions, the type of industrial communication protocol used, and the identifier of the object being operated.

[0064] Based on the data interaction required for asset information identification between the production control security domain and the management information security domain, the data interaction is divided into at least one business type according to business function, such as measurement uploading, operation status uploading, control command issuance, parameter adjustment and file issuance. A unique cross-domain business flow identifier is generated for each type of data interaction, and the corresponding business intent tag is selected for the cross-domain business flow from the preset business intent tag set.

[0065] Based on the identifier of the operated object involved in the cross-domain business flow, the scope of access objects is determined as a set of measurement point identifiers or a set of device identifiers, so that the same cross-domain business flow is fixedly associated with a unique cross-domain business flow identifier, business intent label and scope of access objects.

[0066] The acquisition of asset information from various business systems and equipment within the power system refers to obtaining attribute datasets of system operating entities. This can be automated using an asset management system or configuration management database, aiming to construct an asset profile based on the actual system status and avoid information loss or bias caused by manual configuration. Data interaction between the production control security domain and the management information security domain, based on asset information identification, can be understood as filtering cross-domain data flows through a rule engine or business flow analysis module. Its purpose is to accurately locate business scenarios requiring isolation and control. Classifying data interactions into business types such as measurement transmission and operational status transmission based on business functions involves logical classification based on business semantics, for example, using decision tree algorithms or predefined classification rules. The aim is to clarify the boundaries of business types and enhance the interpretability of functional semantics. A unique cross-domain business flow identifier is generated for each type of data interaction. This refers to creating a unique business flow identifier, which can be implemented using a UUID generation algorithm or a timestamp-based sequence number mechanism. The purpose is to prevent identifier conflicts and ensure the uniqueness of the business flow. Selecting the corresponding business intent tag from a preset set of business intent tags can be understood as matching business functions from an enumerated tag library, for example, through a tag mapping table or semantic matching algorithm. The purpose is to ensure that the tag and business function strictly correspond. Determining the scope of the access object as a set of measurement point identifiers or a set of device identifiers means constructing a precise access boundary based on the identifier of the operated object. This can be implemented using an object identifier list or a set management module. The purpose is to avoid generalization of the access scope. Making the same cross-domain business flow permanently associated with a unique cross-domain business flow identifier, business intent tag, and access object scope specifically involves establishing an immutable metadata binding relationship, for example, through database transactions or hash verification mechanisms.

[0067] Specifically, the proposed solution automatically constructs a system entity attribute database by collecting asset information. Based on this database, it identifies cross-domain data interactions and categorizes them according to business function semantics. A unique identifier is generated for each type of interaction, and a preset tag is matched. Simultaneously, the scope of access objects is precisely limited based on the identifier of the operated object. Finally, the identifier, tag, and scope are solidified into an indivisible metadata unit. In this process, asset information collection provides the data foundation for business flow identification; business function division ensures clear type boundaries; unique identifier generation avoids conflicts; tag selection strengthens semantic consistency; access scope determination achieves object-level constraints; and a fixed association mechanism ensures metadata integrity. Each step is interconnected: the accuracy of asset information directly affects the reliability of data interaction identification; the accuracy of business function division determines the matching degree of identifiers and tags; the clarity of object identifiers supports the accuracy of access scope; and fixed association integrates scattered elements into a unified business flow definition. This design shifts cross-domain business flow configuration from manual experience-driven to automated semantic-driven, ensuring that business constraint definitions are strictly aligned with the actual system state.

[0068] As a preferred embodiment, the solution of this application is implemented as follows: In the 220kV smart substation scenario, the business data processing device collects the RTU equipment asset information of the SCADA system through the asset management system, including the security domain being the production control security domain, the business function being telemetry data acquisition, the industrial communication protocol being IEC 60870-5-104, and the operated object being identified as the transformer oil temperature measuring point ID; based on the asset information, the measurement upload service that needs to be transmitted across domains is identified, and it is classified into measurement upload type according to the business function, generating a unique cross-domain business flow identifier such as FLOW_MEAS_001, and selecting the business intent label MeasurementUpload from the preset label set; according to the transformer oil temperature measuring point ID involved in the business flow, the scope of access is determined as the measuring point set identifier of a specific transformer, so that the cross-domain business flow identifier, the business intent label, and the scope of access are fixedly associated through the metadata management module.

[0069] Through the above scheme, this application avoids the problem of duplicate or conflicting cross-domain business flow identifiers, ensures that the business intent label strictly matches the actual business function, prevents the scope of access objects from being overly generalized or ambiguous, and enables the generation of session tokens to accurately reflect business semantics. This provides a reliable business constraint framework for fine-grained access control on the horizontal isolation path, and reduces the risk of misjudgment and omission of unauthorized access and abnormal behavior.

[0070] In some of the embodiments described above in this application, it is proposed to encapsulate business data into secure self-describing data units on the business data generation side to achieve secure cross-domain transmission. However, in this process, since business data may be based on various industrial communication protocols, the structural differences of protocol messages make it impossible to accurately collect the cross-domain business flow information to which the business data belongs, resulting in errors in the header information of the secure self-describing data unit, causing the business semantics to decouple from access constraints, and affecting the effectiveness of fine-grained control.

[0071] In this regard, this application further proposes that when encapsulating business data into secure self-describing data units on the business data generation side, the following should be included:

[0072] The industrial communication protocol messages corresponding to the business data are parsed to obtain the sending business system identifier, receiving business system identifier, business function and operated object identifier. Based on the sending business system identifier, receiving business system identifier, business function and operated object identifier, the cross-domain business flow information matching the business data is determined from the pre-configured cross-domain business flow information to obtain the cross-domain business flow identifier, business intent tag and access object scope.

[0073] The header information of the security self-describing data unit includes the production control security domain identifier, management information security domain identifier, cross-domain business flow identifier, business intent label, access object scope, and business instruction type. The business payload of the security self-describing data unit includes the industrial communication protocol message, so that the same business data is transmitted in the form of a security self-describing data unit carrying a unified business meaning and access constraints when transmitted between the production control security domain and the management information security domain.

[0074] Specifically, industrial communication protocol message parsing refers to the structured extraction of industrial communication protocol messages upon which business data is based. This can be achieved using a protocol parsing engine that supports IEC 60870-5-104 and Modbus. The parsing of messages from various industrial protocols, such as TCP, aims to accurately extract key business identifiers from the original messages, avoiding information collection errors caused by protocol differences. Cross-domain business flow information matching can be understood as associating cross-domain business flows based on the identifiers obtained through parsing. This can be achieved using key-value queries or rule-based matching algorithms, such as quickly retrieving a pre-configured cross-domain business flow information database using a hash table. The purpose is to ensure that business data is accurately bound to the correct cross-domain business flow information, preventing mismatches between business intent tags and access object scopes. Writing secure self-describing data unit header information specifically refers to integrating business semantics and access constraints into the data unit header. This can be achieved using fixed field encapsulation or extensible tag mechanisms, aiming to give the data unit self-describing characteristics and provide a unified basis for verification on horizontal isolation paths. Writing the business payload portion into industrial communication protocol messages can be understood as preserving the complete content of the original business data. This can be achieved using transparent transmission or encrypted encapsulation methods, aiming to ensure the integrity of business functions while minimizing intrusion into existing business systems.

[0075] Specifically, the solution in this application first parses the industrial communication protocol message to obtain the sending business system identifier, receiving business system identifier, business function, and operated object identifier. These identifiers serve as key inputs to accurately match the corresponding cross-domain business flow identifier, business intent tag, and access object range from pre-configured cross-domain business flow information. Subsequently, the matching result, along with information such as security domain identifier and business instruction type, is written into the header of the secure self-describing data unit. At the same time, the original industrial communication protocol message is encapsulated as the business payload, thereby forming a data unit carrying a unified business meaning and access constraints. This process ensures that regardless of the industrial protocol from which the business data originates, it is converted into a standardized secure self-describing data unit, so that the business semantics and access constraints remain tightly coupled throughout the transmission process, providing a reliable foundation for session token verification and behavior monitoring on the lateral isolation path.

[0076] As a specific implementation method, the solution of this application is implemented as follows: When business data is generated based on the IEC60870-5-104 protocol, the business data processing device first calls the protocol parsing engine to parse the message, extracting the sending business system identifier as SCADA system, the receiving business system identifier as DMS system, the business function as control command issuance, and the operated object identifier as circuit breaker set; then, based on these identifiers, it queries the pre-configured cross-domain business flow information database, matching the cross-domain business flow identifier as CTL_FLOW_001, the business intent label as "emergency control", and the access object scope as "substation A circuit breaker group"; next, it writes the production control security domain identifier "PC_ZONE", the management information security domain identifier "MI_ZONE", the cross-domain business flow identifier CTL_FLOW_001, the business intent label "emergency control", the access object scope "substation A circuit breaker group", and the business command type "opening command" into the security self-describing data unit header, and directly encapsulates the original IEC in the business load part. Message 60870-5-104; Ultimately, this secure self-describing data unit always carries consistent business meaning and access constraints during cross-domain transmission, ensuring that session control devices on the lateral isolation path can perform effective verification based on header information.

[0077] Through the above solution, this application solves the problem of cross-domain business flow information collection errors caused by differences in industrial communication protocols, and enables the header information of the secure self-describing data unit to accurately reflect business semantics and access constraints, avoiding the phenomenon of business intent being decoupled from access control. This ensures that the fine-grained control mechanism based on session tokens can be reliably executed, and improves the security and consistency of cross-domain data transmission in horizontal isolation of power systems.

[0078] In some of the embodiments described above in this application, a session token based on a cross-domain business flow baseline model is proposed to achieve fine-grained access control. However, in its implementation, the parameter settings of the baseline model lack specific basis and fine-grained definition, which makes the session token unable to accurately reflect the normal behavioral characteristics of different business flows. This may cause legitimate data transmission to be mistakenly blocked or abnormal behavior to be missed, affecting the security and reliability of cross-domain data transmission.

[0079] In this regard, this application further proposes steps for generating session tokens on a lateral isolation path between the production control security domain and the management information security domain, including:

[0080] Based on the pre-collected cross-domain service configuration and historical security self-description data units, establish a cross-domain service flow baseline model according to the cross-domain service flow. The cross-domain service flow baseline model shall at least provide the normal service instruction type, normal access object range, normal session duration, and the upper limit of the number of security self-description data units passed in the normal session and the upper limit of the number of security self-description data units passed per unit time for the corresponding cross-domain service flow.

[0081] When the first security self-describing data unit arrives, parameters matching the cross-domain business flow identifier of the security self-describing data unit are selected from the cross-domain business flow baseline model. These parameters are used as the allowed business instruction types, allowed access object range, session validity period, and quantity-based access conditions limited by the session token, and the session token is associated with the cross-domain business flow identifier.

[0082] In practical applications, the cross-domain business flow baseline model refers to a model established based on cross-domain business flows. It can be implemented using statistical analysis methods based on historical business data. Its purpose is to provide parameters for session tokens that conform to actual business behavior. Normal business instruction types refer to the types of business operations allowed to be executed in a specific cross-domain business flow. These can be predefined instruction sets, and their purpose is to limit the scope of legal operations to prevent unauthorized access. Normal access object scope refers to the set of devices or measurement points allowed to be accessed in a specific cross-domain business flow. These can be a list of identifiers, and their purpose is to control data access boundaries to ensure the principle of least privilege. Normal session duration refers to the effective duration of a single session, which can be determined based on historical session data analysis. Its purpose is to prevent security risks caused by excessively long sessions. The upper limit of the number of secure self-describing data units passing through a normal session refers to the maximum number of data units allowed to be transmitted in a single session. This can be set based on business requirements, and its purpose is to limit data transmission volume to prevent data leakage. The upper limit of the number of secure self-describing data units passing through per unit time refers to the maximum number of data units allowed to be transmitted within a specific time window. This can be determined based on traffic analysis, and its purpose is to prevent abnormal behavior caused by excessive frequency.

[0083] Specifically, the solution in this application establishes a cross-domain business flow baseline model based on pre-collected cross-domain business configurations and historical security self-description data units. This model defines the normal behavior parameters of each business flow. When the first security self-description data unit arrives, the system selects matching parameters from the baseline model based on its cross-domain business flow identifier, generates a session token, and associates it with the business flow identifier. During data transmission, the system compares the data unit characteristics with the session token constraints item by item, forwarding the data unit only when all characteristic data meet the session token constraints, thereby achieving fine-grained access control based on business flow characteristics. This mechanism ensures that the session token parameters are directly derived from actual business operation data, avoiding deviations caused by subjective parameter settings. Simultaneously, by covering the core elements of business operations with multi-dimensional indicators, the token constraints are highly consistent with actual business operations, strengthening the targeted nature of access control.

[0084] As a specific implementation method, the solution of this application is implemented as follows: For the measurement upload service flow, the system establishes a baseline model based on historical data, determines that the normal service instruction type is telemetry data upload type, the normal access object range is the predefined measurement point set identifier, the normal session duration is set to a short time limit, the upper limit of the number of data units within the session is set to a moderate threshold, and the upper limit of the number per unit time is set to a low threshold. When the first secure self-describing data unit arrives, the system generates a session token, limiting the allowed service instruction type to telemetry data upload type, the allowed access object range to the measurement point set identifier, the session validity time to a short time limit, the upper limit of the number within the session to a moderate threshold, and the upper limit of the number per unit time to a low threshold.

[0085] Through the above technical solutions, the baseline model parameters are established based on actual business operation data, enabling the session token to accurately adapt to the characteristics of specific business flows. This avoids the risk of misjudgment caused by parameter deviations, reduces the situation where legitimate data transmission is mistakenly blocked or abnormal behavior is missed, and improves the security and reliability of cross-domain data transmission.

[0086] Specifically, in some of the embodiments described above in this application, a session token is generated based on a cross-domain service flow baseline model to achieve fine-grained access control. However, in its implementation, all service flows adopt a unified token parameter setting, which makes it impossible to implement stricter access constraints for high-risk service flows or to provide more relaxed transmission conditions for low-risk service flows. This results in security risks such as unauthorized access and abnormal frequency behavior for high-risk service flows, while low-risk service flows may be affected by excessive restrictions, thus affecting normal transmission efficiency.

[0087] In this regard, this application further proposes that when generating a session token, it also includes:

[0088] Based on the importance of the business intent labels, the scope of access objects, and the sensitivity of the types of business instructions given in the cross-domain business flow baseline model, cross-domain business flows are divided into at least the first risk level and the second risk level.

[0089] When a cross-domain business flow is classified as Level 1 risk, the scope of access objects limited by the session token is restricted to a single set of test points or a single set of devices. The number of secure self-describing data units allowed to pass within the session and the number of secure self-describing data units allowed to pass within a unit of time are limited to a first quantity threshold range, and the session validity time is limited to a first duration range. When a cross-domain business flow is classified as Level 2 risk, the scope of access objects limited by the session token is restricted to multiple sets of test points or multiple sets of devices. The number of secure self-describing data units allowed to pass within the session and the number of secure self-describing data units allowed to pass within a unit of time are limited to a second quantity threshold range, and the session validity time is limited to a second duration range. The first quantity threshold range is smaller than the second quantity threshold range, and the first duration range is shorter than the second duration range.

[0090] Specifically, risk level classification refers to the technical means of classifying cross-domain business flows based on business security attributes. It can be implemented using preset rule sets or dynamic risk assessment models. The risk level is determined by quantifying the sensitivity of business intent tags, the criticality of the access object scope, and the risk coefficient of business instruction types. Its purpose is to establish differentiated security control strategies to adapt to the actual risk levels of different business flows. Among them, the first risk level refers to the business flow category judged as high-risk, which can be understood as the business flow involving critical control operations or sensitive data, such as the control instruction issuance business. Its purpose is to impose strict constraints on high-risk businesses to compress potential attack windows. The second risk level refers to the business flow category judged as low-risk, which can be understood as the business flow involving status monitoring or non-critical data, such as measurement upload business. Its purpose is to improve the continuity of data transmission while ensuring basic security.

[0091] Specifically, the solution in this application introduces a dynamic risk level adaptation mechanism when generating session tokens. First, based on the business intent label, the importance of the access object scope, and the sensitivity of the business instruction type in the cross-domain business flow baseline model, the business flow is divided into different risk levels. Then, differentiated token parameters are configured for different risk levels: For business flows at the first risk level, the scope of access objects is strictly limited to a single set of measurement points or a single set of devices, with a smaller range of quantity thresholds and a shorter session duration, thus constraining the spread of unauthorized access and compressing the attack window. For business flows at the second risk level, the scope of access objects is allowed to expand to multiple sets of measurement points or multiple sets of devices, while a larger range of quantity thresholds and a longer session duration are set, improving transmission efficiency while ensuring basic security. This risk level-based parameter differentiation allows security control policies to dynamically match the business risk level, strengthening the defense-in-depth capability of high-risk business flows while avoiding transmission interruptions in low-risk business flows due to excessive restrictions, thereby achieving an optimized balance between security control granularity and business efficiency.

[0092] As a specific implementation method, the solution of this application is implemented as follows: When the business intent label of the cross-domain business flow indicates "emergency control" and involves circuit breaker operation, the system classifies it as the first risk level, sets the access object scope limited by the session token to a single set of circuit breaker devices, and configures the quantity threshold range and session duration range within a strictly constrained range; while when the business intent label of the cross-domain business flow indicates "routine monitoring" and involves the transmission of substation measurement point data, the system classifies it as the second risk level, allows the access object scope to cover multiple measurement point sets within the substation, and configures the quantity threshold range and session duration range within a relatively relaxed range, thereby improving the data transmission continuity of non-critical services while ensuring security isolation.

[0093] Through the above technical solution, this application can implement differentiated session token parameter configuration for cross-domain business flows with different risk levels, which solves the security risks of high-risk business flows and the transmission efficiency problems of low-risk business flows. It not only prevents unauthorized access and abnormal frequency behavior, but also avoids transmission interruption of normal business due to improper parameter settings, thereby improving the security data transmission efficiency in the horizontal isolation environment of the power system.

[0094] Specifically, in some of the embodiments described above in this application, a mechanism is proposed to obtain feature data and compare it with session tokens when forwarding secure self-describing data units on a lateral isolation path. However, in its implementation, the specific constituent elements and comparison logic of the feature data lack clear specifications, which makes it impossible for the system to accurately verify whether the type of business instruction is within the allowed range, whether the accessed object is within the accessed object range, whether the session is within the valid time, and whether the data transmission frequency exceeds the threshold. This may result in unauthorized access and abnormal frequency behavior not being blocked in time, causing security risks of lateral isolation paths being abused for illegal data transmission.

[0095] In this regard, this application further proposes that when forwarding secure self-describing data units on lateral isolation paths, the following should be included:

[0096] For each security self-description data unit to be forwarded, read the business instruction type and access object in the header information, obtain the arrival time of the security self-description data unit on the horizontal isolation path, and determine the number of security self-description data units that have passed in the session and the number of security self-description data units that have passed within a preset unit time based on the number of security self-description data units that have been marked as forwarded in the current session and the number of security self-description data units that have been marked as forwarded within a preset unit time.

[0097] The service instruction type, access object, arrival time, number of secure self-describing data units passed within the session, and number of secure self-describing data units passed per unit time are used as feature data. These are compared item by item with the allowed service instruction types, allowed access object range, session validity period, maximum number of items within the session, and maximum number of items per unit time as limited by the associated session token. Only when all the corresponding items of the feature data are within the limits of the session token are the secure self-describing data units marked as forwarded; otherwise, they are marked as blocked.

[0098] Among them, the business instruction type refers to the field in the header information of the secure self-describing data unit that identifies the type of business operation. It can be implemented using predefined enumeration values ​​(such as measurement upload, operation status upload, control instruction issuance, parameter adjustment, and file issuance). The purpose is to clarify the semantic attributes of the business operation and provide a unified basis for verifying the legality of the instruction. The access object refers to the target device or measurement point range specified in the header information of the secure self-describing data unit. It can be a set of measurement point set identifiers or a set of device set identifiers. The purpose is to limit the physical boundary of data access and prevent unauthorized operations. The arrival time refers to the receiving timestamp of the secure self-describing data unit on the horizontal isolation path. It can be implemented using the time value obtained by the system's high-precision clock synchronization. The purpose is to dynamically verify the timeliness of the session. The number of secure self-describing data units that have passed in the session refers to the cumulative number of data units that have been forwarded in the current session. It can be implemented by real-time accumulation and statistics through a counter. The purpose is to monitor the total amount of data transmission within the session lifecycle. The number of secure self-describing data units that have passed per unit time refers to the number of data units that have been forwarded within a preset time window. It can be implemented by dynamically calculating through a sliding time window algorithm. The purpose is to detect whether the data transmission frequency conforms to the normal fluctuation range of the business.

[0099] Specifically, the solution in this application first extracts the type of business instruction and the access object directly from the header information of the security self-describing data unit, ensuring that the verification is based on a unified business semantics without the need for external parsing; at the same time, it obtains the precise arrival time as a dynamic time benchmark; then, it counts the number of forwarded requests in real time based on the current session state and a preset time window, forming a dynamic quantitative indicator; subsequently, it performs independent condition checks on the above-mentioned multi-dimensional feature data and session token constraints, ensuring that security dimensions such as business semantics, access objects, time points, cumulative quantity, and transmission rate are strictly verified; finally, it only allows forwarding when all feature data fully meets the session token constraints, otherwise it immediately blocks it, thus constructing a zero-tolerance verification mechanism that satisfies all conditions, avoiding single-dimensional verification vulnerabilities.

[0100] As a preferred embodiment, the specific implementation of the solution in this application is as follows: In a power system horizontal isolation environment, when a security self-describing data unit arrives at the horizontal isolation path, the session control device parses its header information to obtain the service instruction type as "control instruction issuance" and the access object as "measuring point set A"; records the arrival time as a system timestamp; counts the number of security self-describing data units forwarded in the current session as 5, and the number forwarded in the past minute as 3; compares these feature data with the limiting conditions of the associated session token (allowed service instruction types include "control instruction issuance", allowed access object range is "measuring point set A", session validity time is 5 minutes after the current time, the maximum number in the session is 10, and the maximum number per unit time is 5); since all feature data are within the limited range, the security self-describing data unit is marked as forwarded.

[0101] Through the above scheme, this application achieves fine-grained dynamic control over cross-domain business flows, solves the problem of inaccurate security verification caused by fuzzy feature data definitions, ensures that unauthorized access and abnormal frequency behaviors are blocked in a timely manner, and thus strengthens the security of the lateral isolation path.

[0102] In some of the embodiments described above in this application, the reason for blocking is recorded when the security self-describing data unit is blocked in order to support the classification and response of abnormal behavior. However, in its implementation, the blocking event lacks fine-grained classification and contextual association of specific reasons, which makes it impossible for the system to distinguish between different types of abnormal behavior such as unauthorized access, session overrun, or abnormal frequency. This makes it difficult to accurately implement the behavior monitoring and session token dynamic adjustment strategy based on sliding time window, and affects the security control capability of the lateral isolation path for cross-domain business flows.

[0103] When a secure self-describing data unit is marked as blocked, the following steps are also taken: Record the blocking reason based on the item in the feature data that causes the session token restriction conditions to not be met. When the condition is not met, the blocking reason is recorded as cross-domain business unauthorized access. When the condition is not met, the blocking reason is recorded as session scope exceeded. When the condition is not met, the blocking reason is recorded as frequency abnormality. The blocking reason is associated with the corresponding cross-domain business flow identifier and session token identifier.

[0104] Among them, the items in the feature data that cause the session token limitation conditions to be unmet refer to specific data items that conflict with the preset parameters of the session token during the forwarding of the security self-describing data unit. These can be identified by one or more of the following: business instruction type, access object, arrival time, number of data units passed within the session, and number of data units passed per unit time. The purpose is to accurately locate the root cause of the blocking, avoiding simply executing blocking operations without traceable evidence. Cross-domain unauthorized access, session scope exceeding limits, and abnormal frequency refer to three standardized blocking reason categories based on the type of condition not met. These can be implemented by using a condition judgment logic module to classify and map feature data. The purpose is to establish a unified abnormal behavior classification system, enabling the system to distinguish between different types of security events such as permission violations, session abuse, and high-frequency requests. Associating the blocking reason with the corresponding cross-domain business flow identifier and session token identifier refers to the technical means of binding the blocking event to a specific business flow and session context. This can be achieved by using database indexes or log recording mechanisms to establish a mapping relationship between the blocking reason, cross-domain business flow identifier, and session token identifier. The purpose is to provide structured data support for time-series behavior statistics, ensuring that the blocking event has complete business context information.

[0105] Specifically, the solution in this application triggers a blocking cause analysis process when a security self-describing data unit is marked as blocked. First, it extracts specific items from the feature data that cause the session token constraint conditions to be unmet. Then, based on preset classification rules, it maps the blocking cause to three standardized categories: unauthorized access to cross-domain services, exceeding session scope limits, or abnormal frequency. Finally, it establishes a persistent association between the classification results and the cross-domain service flow identifier and the session token identifier. This process forms a closed-loop working mechanism with the session control device on the lateral isolation path: when the comparison result between the feature data and the session token constraint conditions is not met, the blocking operation synchronously triggers the cause classification logic, transforming the blocking event from a simple data discard into a structured security event. Simultaneously, the associated blocking cause data is collected in real time by the behavior monitoring device for time-series behavior statistics and anomaly determination within a sliding time window, thereby driving the dynamic adjustment strategy of the session token. It is precisely because of the refined classification of blocking reasons and the close binding with the business flow context that the system can implement differentiated response measures based on the type of abnormal behavior. For example, it can associate cross-domain business unauthorized access with the tightening operation of the access object scope, and associate frequency anomalies with the dynamic adjustment of quantity thresholds, thus solving the problem of analysis blind spots caused by isolated blocking events without context.

[0106] As a specific implementation method, the solution of this application is implemented as follows: When the session control device detects that the service instruction type of a certain secure self-describing data unit exceeds the range of allowed service instruction types limited by the session token on the lateral isolation path, the system automatically classifies the blocking event as cross-domain service unauthorized access and establishes an association record between this blocking reason and the cross-domain service flow identifier to which the secure self-describing data unit belongs and the current session token identifier; during the behavior monitoring process, the behavior monitoring device, based on the sliding time window statistics, finds that three consecutive cross-domain service unauthorized access events occur under the cross-domain service flow identifier, and then triggers a dynamic shrinking mechanism for the access object scope, shrinking the access object scope limited by the session token from multiple measurement point sets to a single measurement point set, thereby blocking subsequent possible unauthorized access behaviors. In this process, the classification result of the blocking reason directly guides the adjustment strategy of the session token, making the security control measures accurately match the abnormal behavior type.

[0107] Through the above technical solutions, this application realizes the fine-grained classification and business context association of blocking events, enabling the system to accurately distinguish different types of abnormal behaviors such as unauthorized access to cross-domain business, exceeding session scope limits, and abnormal frequency. This provides a structured data foundation for behavior monitoring based on sliding time windows, thereby supporting the precise implementation of dynamic adjustment strategies for session tokens and improving the security control capabilities of lateral isolation paths over cross-domain business flows.

[0108] Specifically, in some of the embodiments described above in this application, a sliding time window is proposed to be maintained on a cross-domain business flow basis to identify abnormal behavior. However, in its implementation, the timing behavior statistics of the sliding time window lack specific statistical dimensions and judgment criteria, and cannot accurately capture potential risks such as excessively high frequency of control commands, abnormal expansion of the scope of access objects, or concentrated occurrence of blocking events, resulting in a lag in the identification of abnormal behavior and the inability to dynamically adjust security policies in a timely manner.

[0109] In this regard, this application further proposes that, when maintaining a sliding time window on a per-domain business flow basis according to the above-mentioned power system horizontal isolation and secure data transmission method, the following includes:

[0110] Set the sliding time window length and sliding step size for each cross-domain business flow. Within each sliding time window, perform time-series behavior statistics on the forwarded security self-description data units. The time-series behavior statistics include the number of security self-description data units belonging to control command issuance and parameter adjustment, the number of devices or measurement point sets accessed within the sliding time window, the minimum time interval between adjacent control commands or parameter adjustments, and the number of security self-description data units marked as blocked within the sliding time window.

[0111] According to the pre-configured abnormal behavior judgment rules, at least one of the following situations is judged as abnormal behavior: the number of control commands issued exceeds the number threshold, the number of accessed devices or the number of measurement point sets exceeds the object number threshold, the minimum time interval is lower than the time interval threshold, and the number of blocks exceeds the blocking number threshold. The sliding time window of the abnormal behavior is associated with the corresponding cross-domain business flow identifier and session token identifier.

[0112] The sliding time window length refers to the time span used for behavior statistics. It can be configured as a fixed duration or dynamically adjusted according to the characteristics of the business flow. This can be achieved through system configuration parameters. Its purpose is to adapt to the real-time requirements of different cross-domain business flows and avoid the dilution of abnormal behavior due to an excessively large window or the misjudgment caused by an excessively small window. The sliding step size refers to the time interval for window movement. It can be set using equal or non-equal intervals. This can be achieved through a clock synchronization mechanism. Its purpose is to balance statistical accuracy and system overhead, ensuring the continuity and timeliness of behavior monitoring. The number of secure self-describing data units belonging to control command issuance and parameter adjustment refers to the counting index of highly sensitive business commands. This can be achieved through the command type parsing module. Its purpose is to focus on... For critical business operations, accurately identify command injection attacks; the number of devices or measurement point sets accessed within the sliding time window refers to a quantitative indicator of the scope of the operation object, which can be achieved through object identifier set operations. Its purpose is to detect abnormal expansion of the access scope and prevent unauthorized scanning behavior; the minimum time interval between adjacent control commands or parameter adjustments refers to the extreme value of the time difference between consecutive commands, which can be achieved through timestamp comparison logic. Its purpose is to capture high-frequency command flooding attacks and identify abnormal operation frequency; the number of security self-describing data units marked as blocked within the sliding time window refers to the cumulative count of security policy conflict events. It can be achieved through the blocking log aggregation module. Its purpose is to quantify the risk of avoidance attempts and reflect the effectiveness of policy execution.

[0113] Specifically, the solution in this application configures the sliding time window length and sliding step size independently for each cross-domain business flow, enabling the statistical window to dynamically match the characteristics of the business flow. Within the window, multi-dimensional temporal behavior statistics are performed on the forwarded security self-describing data units, incorporating the number of control commands, the scope of accessed objects, the command time interval, and blocking events into a unified analysis framework. Based on pre-configured behavior anomaly judgment rules, the statistical results are compared with dynamic thresholds, and any indicator exceeding the threshold range is judged as abnormal behavior. At the same time, the anomaly window is associated with the cross-domain business flow identifier and the session token identifier to ensure that the anomaly location is accurate to the specific business flow and session context. This design realizes multi-dimensional monitoring of business intent, access scope, time frequency, and policy conflicts, enabling the system to distinguish between normal business fluctuations and real threats from historical baselines, avoiding the identification lag problem caused by single-dimensional statistics.

[0114] As a specific implementation method, the solution of this application is implemented as follows: For remote control business flows in power dispatching scenarios, the system configures a sliding time window length and sliding step size for the cross-domain business flow. During the operation of a certain sliding time window, the system counts in real time the number of control instruction issuance data units in the forwarded security self-describing data units, and records the number of accessed substation devices, the minimum time interval between adjacent control instructions, and the number of blocked data units. When the system detects that the number of control instructions is higher than the normal level, the number of accessed devices exceeds the preset range, the minimum time interval of instructions is abnormally shortened, and blocking events occur frequently, it triggers anomaly judgment according to the behavior anomaly judgment rules, and binds the anomaly window with the corresponding cross-domain business flow identifier and session token identifier.

[0115] Through the above solution, this application can accurately capture potential risks such as excessively high frequency of control commands, abnormal expansion of the scope of access objects, or concentrated occurrence of blocking events, and achieve timely identification and location of abnormal behavior, enabling dynamic convergence and adjustment of security policies, thus solving the problem of security policies failing to respond in a timely manner due to the lag in abnormal behavior identification.

[0116] In practical applications, some of the embodiments described above in this application propose a mechanism for cross-domain business flow timing behavior statistics and abnormal behavior identification based on sliding time windows. However, in its implementation, the system can only determine abnormal behavior but lacks dynamic response capabilities. This results in the inability to adjust security policies in a timely manner after detecting anomalies, which may lead to unauthorized access or frequency abnormal behavior continuing to occur. Security risks cannot be effectively mitigated, and the scope and number of access objects are difficult to tighten precisely according to the type of anomaly. It may even be impossible to completely block business flows when there are continuous anomalies, thus leaving security risks in cross-domain data transmission.

[0117] In this regard, this application further proposes that when abnormal behavior is detected, it includes:

[0118] When the abnormal behavior is that the number of accessed devices or the number of measurement point sets exceeds the object number threshold, the scope of access objects limited by the corresponding session token will be narrowed from multiple measurement point sets or multiple device sets to a single measurement point set or a single device set.

[0119] When the abnormal behavior is that the number of control commands issued exceeds the number threshold or the number of blocked commands exceeds the number threshold, the number of security self-description data units allowed to pass within the session and the number of security self-description data units allowed to pass per unit time, which are limited by the corresponding session token, will be reduced to the lower limit threshold.

[0120] When abnormal behavior occurs within multiple consecutive sliding time windows, the corresponding session token is deactivated. During the deactivation period, subsequent security self-describing data units belonging to cross-domain business flows are blocked, and the deactivation information, cross-domain business flow identifier, and session token identifier are recorded.

[0121] In practical applications, the object quantity threshold refers to a preset threshold used to determine whether the scope of accessed objects is abnormal. This can be implemented using a threshold dynamically calculated based on historical behavior data or a fixed threshold, with the aim of promptly identifying unauthorized access behavior. Narrowing the scope of accessed objects to a single set of measurement points or a single set of devices means restricting the scope of allowed access to a single entity. This can be understood as being achieved by updating the access control list of the session token, with the aim of immediately reducing the attack surface when anomalies first appear, while maintaining basic business continuity. The quantity threshold and blocking quantity threshold are thresholds used to determine the frequency of control commands and blocking events, respectively. These can be determined using a moving average algorithm or a peak detection mechanism, with the aim of preventing… The cumulative effect of high-frequency malicious operations; reducing the quantity condition to the lower limit threshold means limiting the number of secure self-describing data units to the minimum security level, which can be achieved by dynamically adjusting the upper limit value of the counter in the session token, with the aim of balancing security protection and business efficiency through a step-by-step tightening strategy; multiple consecutive sliding time windows refer to the set of windows in which abnormal behavior occurs continuously in a time series, which can be detected based on time series analysis models, with the aim of distinguishing between occasional events and persistent anomalies; deactivating the session token and recording the deactivation information means invalidating the session token and storing relevant audit data, which can be achieved by using token status marking and logging mechanisms, with the aim of completely blocking high-risk business flows and supporting post-event traceability analysis.

[0122] Specifically, the solution in this application achieves closed-loop optimization of the security control mechanism by triggering differentiated dynamic response strategies based on the type and persistence of abnormal behavior. Upon detecting abnormal behavior, the system first initiates a corresponding response based on the specific manifestation of the abnormality: if the abnormality manifests as the number of accessed devices or measurement points exceeding the object quantity threshold, the scope of accessed objects is immediately narrowed to a single entity to limit the spread of potential unauthorized access; if the abnormality manifests as the number of control commands issued or blocked exceeding the corresponding threshold, the requirement for the number of secure self-describing data units within the session and per unit time is reduced to the lower limit threshold to prevent the cumulative effect of frequency anomalies; if the abnormality recurs within multiple consecutive sliding time windows, the session token is disabled and subsequent data units are blocked, while the disabling information is recorded. This fine-grained response mechanism based on the abnormality context enables the security strategy to shift from passive detection to proactive defense. Through precise mapping between abnormality types and response measures, it ensures rapid risk mitigation when an abnormality occurs, preventing the security mechanism from failing.

[0123] As a specific implementation method, the solution of this application is implemented as follows: When it is detected that the number of devices accessed by a cross-domain service flow within a sliding time window exceeds the object number threshold, the scope of access objects limited by the session token corresponding to the service flow is reduced from multiple device sets to a single device set; if the number of control commands issued subsequently exceeds the number threshold, the number of secure self-describing data units allowed to pass within the session and the number of secure self-describing data units allowed to pass per unit time limited by the session token will be further reduced to the lower limit threshold; if the abnormal behavior occurs repeatedly within multiple consecutive sliding time windows, the session token will be deactivated, and during the deactivation period, subsequent secure self-describing data units belonging to the cross-domain service flow will be blocked, and the deactivation information will be associated with the cross-domain service flow identifier and the session token identifier.

[0124] Through the above solution, this application can precisely tighten the scope and number of access objects according to the type of abnormal behavior, completely block business flow when the abnormality continues, solve the problem of policy adjustment lag after abnormality detection, and improve the dynamic response capability and risk convergence efficiency of security policies in cross-domain data transmission.

[0125] In summary, this application uses the production control security domain and management information security domain as boundaries, pre-configures cross-domain business flow information around cross-domain business needs, and solidifies the cross-domain business flow identifier, business intent label, and access object scope. At the business data generation side, by parsing industrial communication protocol messages, each piece of business data is encapsulated into a secure self-describing data unit carrying the aforementioned business semantics and business instruction type. This allows the lateral isolation path to no longer only see network packets but also perceive which type of business is operating on which objects. When a cross-domain business occurs for the first time, a session token corresponding one-to-one with the cross-domain business flow identifier is generated based on the cross-domain business flow baseline model. During forwarding, the business instruction type, access object, arrival time, and the number of secure self-describing data passed within the session and per unit time are recorded. By comparing characteristic data such as the number of units with session token constraints item by item, semantic-level access control is achieved for individual secure self-describing data units. A sliding time window is maintained for cross-domain business flows, and the time-series behavior statistics of forwarded secure self-describing data units are performed. Based on this, behavior anomaly judgment is triggered. When anomalies are detected, the access object range and quantity conditions limited by the corresponding session token are automatically tightened or disabled, and subsequent data is blocked. Thus, an adaptive and convergent dynamic protection closed loop is formed within the legitimate channel to control unauthorized access and frequency anomalies. This solves the defects of existing technologies, such as the decoupling of cross-domain business semantics and access constraints, and the difficulty in timely detection of fine-grained anomalies by relying solely on equipment status monitoring. It improves the business security and protection accuracy in the horizontal isolation scenario of the power system.

[0126] Based on another preferred embodiment described above, see [link to preferred embodiment]. Figure 2As shown, this embodiment provides a power system lateral isolation and secure data transmission system for applying the above-described power system lateral isolation and secure data transmission method, including:

[0127] The production control security domain and the management information security domain are connected through lateral isolation paths.

[0128] A business data processing device is set up in the production control security domain. When business data needs to be transmitted between the production control security domain and the management information security domain, the business data processing device collects the cross-domain business flow information to which the business data belongs and encapsulates the business data into a secure self-describing data unit. The header information of the secure self-describing data unit carries the cross-domain business flow information and the type of business instruction, and the business load carries the business data corresponding to the header information.

[0129] A session control device is set up on the horizontal isolation path. The session control device is used to obtain the header information of the first appearance of the secure self-describing data unit, generate a session token according to the pre-established cross-domain business flow baseline model, associate the session token with the cross-domain business flow identifier, and obtain the feature data of the secure self-describing data unit when forwarding the secure self-describing data unit. The feature data is compared with the limiting conditions of the associated session token. If the feature data meets the limiting conditions, the secure self-describing data unit is allowed to pass. If the feature data does not meet the limiting conditions, the secure self-describing data unit is blocked.

[0130] The behavior monitoring device is used to maintain a sliding time window on a cross-domain business flow basis, perform time-series behavior statistics on the forwarded security self-description data units within each sliding time window, identify abnormal behaviors according to behavior anomaly judgment rules, tighten or disable the access object range and quantity conditions limited by the corresponding session token when abnormal behaviors are identified, and block subsequent security self-description data units belonging to cross-domain business flows.

[0131] It is understandable that by combining the semantic encapsulation mechanism of the secure self-describing data unit with the dynamic control mechanism of the session token in a collaborative manner, and introducing cross-domain business flow temporal behavior statistics based on a sliding time window, the source binding of business intent tags and access object scope and the adaptive dynamic convergence of the session scope are achieved, thus realizing the timely detection of unauthorized access and abnormal frequency behavior. Specifically, the business data processing device encodes the business intent tag and access object scope uniformly into the header of the secure self-describing data unit during the data encapsulation stage, making business semantics and access constraints tightly coupled; the session control device generates session tokens based on the cross-domain business flow baseline model, and accurately identifies and blocks unauthorized access behavior by comparing feature data with token limitation conditions in real time; the behavior monitoring device dynamically adjusts the access scope and quantity conditions of the session token according to the temporal behavior statistics within the sliding time window, ensuring that the security policy adaptively converges with changes in business behavior. In summary, through the closed-loop mechanism of semantic encapsulation, tokenization control, and dynamic policy adjustment, the problems of decoupling cross-domain business semantics and access constraints and the difficulty in dynamically converging the session scope are solved.

[0132] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

Claims

1. A method for lateral isolation and secure data transmission in a power system, characterized in that, include: In the power system, a production control security domain and a management information security domain are determined, and cross-domain business flow information is configured based on cross-domain business requirements. The cross-domain business flow information includes a cross-domain business flow identifier, a business intent tag, and an access object scope. On the business data generation side, when business data needs to be transmitted between the production control security domain and the management information security domain, the cross-domain business flow information to which the business data belongs is collected, and the business data is encapsulated into a secure self-describing data unit. The header information of the secure self-describing data unit carries at least the cross-domain business flow information and the type of business instruction, and the business load carries the business data corresponding to the header information. On the horizontal isolation path between the production control security domain and the management information security domain, the header information of the first security self-describing data unit is obtained, a session token is generated according to the pre-established cross-domain business flow baseline model, and the session token is associated with the cross-domain business flow identifier. When forwarding the secure self-describing data unit on the lateral isolation path, the feature data of the secure self-describing data unit is obtained, and the feature data is compared with the associated session token. If the feature data satisfies the limiting conditions of the session token, the secure self-describing data unit is forwarded; otherwise, the secure self-describing data unit is blocked. A sliding time window is maintained for each cross-domain business flow. Time-series behavior statistics are performed on the security self-description data units that have been forwarded within each sliding time window. Abnormal behavior is identified according to the behavior anomaly judgment rules. When abnormal behavior is identified, the access object range and quantity conditions limited by the corresponding session token are tightened or disabled, and subsequent security self-description data units belonging to the cross-domain business flow are blocked. When generating a session token on the lateral isolation path between the production control security domain and the management information security domain, the following steps are included: Based on the pre-collected cross-domain service configuration and historical security self-description data units, a cross-domain service flow baseline model is established according to the cross-domain service flow. The cross-domain service flow baseline model at least provides the normal service instruction type, normal access object range, normal session duration, and the upper limit of the number of security self-description data units passed within the normal session and the upper limit of the number of security self-description data units passed per unit time for the corresponding cross-domain service flow. When the first security self-describing data unit arrives, based on the cross-domain business flow identifier of the security self-describing data unit, parameters matching it are selected from the cross-domain business flow baseline model. These parameters are used as the allowed business instruction types, allowed access object range, session validity time, and quantity-based access conditions limited by the session token, and the session token is associated with the cross-domain business flow identifier. When generating a session token, the following is also included: Based on the importance of the business intent label, the scope of access objects, and the sensitivity of the business instruction type given in the cross-domain business flow baseline model, cross-domain business flows are divided into at least a first risk level and a second risk level. When the cross-domain service flow belongs to the first risk level, the access scope limited by the session token is restricted to a single set of test points or a single set of devices, and the number of secure self-describing data units allowed to pass within the session and the number of secure self-describing data units allowed to pass within a unit time are restricted to a first quantity threshold range, and the session validity time is restricted to a first duration range; when the cross-domain service flow belongs to the second risk level, the access scope limited by the session token is restricted to multiple sets of test points or multiple sets of devices, and the number of secure self-describing data units allowed to pass within the session and the number of secure self-describing data units allowed to pass within a unit time are restricted to a second quantity threshold range, and the session validity time is restricted to a second duration range, wherein the first quantity threshold range is smaller than the second quantity threshold range, and the first duration range is shorter than the second duration range.

2. The power system lateral isolation and secure data transmission method according to claim 1, characterized in that, When defining the production control security domain and management information security domain in a power system, and configuring cross-domain service flow information based on cross-domain service requirements, the following are included: Collect asset information of various business systems and equipment in the power system. The asset information includes the security domain to which it belongs, business functions, industrial communication protocol type used, and identification of the operated object. Based on the asset information identification, the data interaction needs to be transmitted between the production control security domain and the management information security domain. According to the business function, the data interaction is divided into at least one business type among measurement uploading, operation status uploading, control command issuance, parameter adjustment and file issuance. A unique cross-domain business flow identifier is generated for each type of data interaction, and the corresponding business intent tag is selected for the cross-domain business flow from the preset business intent tag set. Based on the identifier of the operated object involved in the cross-domain business flow, the scope of access objects is determined as a set of measurement point identifiers or a set of device identifiers, so that the same cross-domain business flow is fixedly associated with a unique cross-domain business flow identifier, business intent tag and scope of access objects.

3. The power system lateral isolation and secure data transmission method according to claim 1, characterized in that, When encapsulating business data into secure self-describing data units on the business data generation side, this includes: The industrial communication protocol message corresponding to the business data is parsed to obtain the sending business system identifier, receiving business system identifier, business function and operated object identifier. Based on the sending business system identifier, receiving business system identifier, business function and operated object identifier, the cross-domain business flow information matching the business data is determined from the pre-configured cross-domain business flow information to obtain the cross-domain business flow identifier, business intent tag and access object range. The production control security domain identifier, management information security domain identifier, cross-domain business flow identifier, business intent label, access object scope, and business instruction type are written into the header information of the security self-describing data unit. The industrial communication protocol message is written into the business load part of the security self-describing data unit, so that the same business data is transmitted in the form of a security self-describing data unit carrying a unified business meaning and access constraints when transmitted between the production control security domain and the management information security domain.

4. The power system lateral isolation and secure data transmission method according to claim 1, characterized in that, When forwarding secure self-describing data units on the lateral isolation path, the following is included: For each security self-description data unit to be forwarded, read the type of business instruction and the access object in the header information, obtain the arrival time of the security self-description data unit on the horizontal isolation path, and determine the number of security self-description data units that have passed in the session and the number of security self-description data units that have passed within a preset unit time based on the number of security self-description data units that have been marked as forwarded in the current session and the number of security self-description data units that have been marked as forwarded within a preset unit time. The service instruction type, access object, arrival time, number of secure self-describing data units passed within the session, and number of secure self-describing data units passed per unit time are used as feature data. These are compared item by item with the allowed service instruction types, allowed access object range, session validity time, maximum number of items within the session, and maximum number of items per unit time as defined by the associated session token. Only when all items corresponding to the feature data are within the limits defined by the session token are the secure self-describing data units marked as forwarded; otherwise, they are marked as blocked.

5. The power system lateral isolation and secure data transmission method according to claim 4, characterized in that, When a secure self-describing data unit is marked as blocked, it also includes: Based on the project records in the feature data that cause the session token restriction conditions to be not met, the blocking reason is recorded as cross-domain business unauthorized access when the condition is not met (business instruction type or access object); as session scope exceeding limit when the condition is not met (session validity time or number of security self-description data units that have passed within the session); and as frequency abnormal when the condition is not met (number of security self-description data units that have passed within a unit time). The blocking reason is then associated with the corresponding cross-domain business flow identifier and session token identifier.

6. The power system lateral isolation and secure data transmission method according to claim 1, characterized in that, When maintaining a sliding time window on a per-domain business flow basis, it includes: Set a sliding time window length and sliding step size for each cross-domain service flow. Within each sliding time window, perform time-series behavior statistics on the forwarded security self-description data units. The time-series behavior statistics include the number of security self-description data units belonging to control command issuance and parameter adjustment, the number of devices or measurement point sets accessed within the sliding time window, the minimum time interval between adjacent control commands or parameter adjustments, and the number of security self-description data units marked as blocked within the sliding time window. According to the pre-configured abnormal behavior judgment rules, at least one of the following situations is judged as abnormal behavior: the number of control commands issued exceeds the number threshold, the number of accessed devices or the number of measurement point sets exceeds the object number threshold, the minimum time interval is lower than the time interval threshold, and the number of blocks exceeds the blocking number threshold. The sliding time window of the abnormal behavior is associated with the corresponding cross-domain business flow identifier and session token identifier.

7. The power system lateral isolation and secure data transmission method according to claim 6, characterized in that, When the abnormal behavior is detected, it includes: When the abnormal behavior is that the number of accessed devices or the number of measurement point sets exceeds the object number threshold, the scope of access objects limited by the corresponding session token will be narrowed from multiple measurement point sets or multiple device sets to a single measurement point set or a single device set. When the abnormal behavior is that the number of control commands issued exceeds the number threshold or the number of blocked commands exceeds the number threshold, the number of secure self-describing data units allowed to pass within the session and the number of secure self-describing data units allowed to pass per unit time, as defined by the corresponding session token, will both be reduced to the lower limit threshold. When abnormal behavior occurs within multiple consecutive sliding time windows, the corresponding session token is deactivated. During the deactivation period, subsequent security self-describing data units belonging to the cross-domain service flow are blocked, and the deactivation information, the cross-domain service flow identifier, and the session token identifier are recorded.

8. A power system lateral isolation and secure data transmission system, used to apply the power system lateral isolation and secure data transmission method as described in any one of claims 1-7, characterized in that, include: The production control security domain and the management information security domain are connected by a lateral isolation path. The production control security domain is equipped with a business data processing device. When business data needs to be transmitted between the production control security domain and the management information security domain, the business data processing device collects the cross-domain business flow information to which the business data belongs and encapsulates the business data into a secure self-describing data unit. The header information of the secure self-describing data unit carries the cross-domain business flow information and the type of business instruction, and the business load carries the business data corresponding to the header information. A session control device is installed on the horizontal isolation path. This device acquires the header information of the first security self-describing data unit (SSDI), generates a session token based on a pre-established cross-domain business flow baseline model, associates the session token with the cross-domain business flow identifier, and acquires the feature data of the SSDI when forwarding it. The feature data is compared with the associated session token's limiting conditions. If the feature data meets all the limiting conditions, the SSDI is allowed; otherwise, it is blocked. A behavior monitoring device maintains a sliding time window on a cross-domain business flow basis. It performs time-series behavior statistics on the SSDI forwarded within each sliding time window, identifies abnormal behavior according to behavior anomaly judgment rules, and tightens or disables the access object range and quantity conditions limited by the corresponding session token when abnormal behavior is detected, and blocks subsequent SSDI belonging to the cross-domain business flow.

Images