Method and system for dynamic filtering and isolating based on policy issued control data

Abstract

The embodiment of the application relates to the technical field of data filtering, and provides a control data dynamic filtering and isolating method and system based on policy issuing, which constructs a process state vector by extracting key security invariants from original traffic in real time, accurately captures semantic conversion of a production stage by using a modal conversion graph, and then deeply fuses atom policy fragments searched dynamically with a global security baseline, generates a real-time active filtering rule set, can construct a dynamic barrier with physical dimension compliance checking capability, realizes a technical leap from traditional static matching to predictive blocking, can effectively identify logical fatal instructions under compliance formats, significantly improves defense accuracy of a control system on complex semantic threats, and ensures high unification of an industrial control network and physical production logic and essential safety of a production process.

Description

Technical Field

[0001] This invention relates to the field of data filtering technology, and in particular to a method and system for dynamic filtering and isolation of control data based on policy issuance. Background Technology

[0002] With the deepening of industrial digitalization and networking, industrial control systems have become a core support for critical infrastructure, and their security is directly related to physical production safety and social stability. In the industrial internet environment, control data is moving from closed to open, facing increasingly complex network threats. Therefore, building a security solution capable of dynamically filtering and precisely isolating real-time control data is of paramount importance for preventing unauthorized command tampering, intercepting malicious control behaviors, and ensuring the continuity of production processes.

[0003] Existing control data protection solutions primarily rely on deploying industrial firewalls or Deep Packet Inspection (DPI) technology. These solutions typically rely on pre-defined static rules, blacklists / whitelists, or protocol compliance checks to administratively intercept and verify the header format, function codes, and register value ranges of industrial protocols. However, these solutions suffer from a serious problem of "contextual semantic attacks on legitimate instructions" when dealing with deeper industrial security threats. Current DPI technology often only verifies the correctness of protocol format and syntax, but cannot effectively identify malicious attack instructions that are correctly formatted but logically fatal. Due to the lack of logical awareness of the physical process status on-site, existing protection devices struggle to determine the compatibility of control instructions with the current production mode. This lack of a process context semantic association means that existing solutions cannot identify and block destructive instructions that contradict the current physical operating logic, making it difficult to meet the needs of more granular and dynamic industrial control security protection. Summary of the Invention

[0004] The present invention aims to solve at least one of the problems existing in the prior art, and to provide a method and system for dynamic filtering and isolation of control data based on policy issuance.

[0005] One aspect of the present invention provides a method for dynamic filtering and isolation of control data based on policy issuance, comprising: Step S1: Based on the pre-configured state label definition table, perform multi-layer protocol decoding and state feature separation on the original control flow to obtain the process state vector and the data payload to be inspected; Step S2: Based on the preset mode transition diagram, perform state space matching and mode classification on the process state vector to obtain the operating mode identifier; Step S3: Based on the runtime mode identifier, retrieve the associated atomic policy fragments from the micro-policy repository, and perform priority fusion and conflict resolution on the atomic policy fragments and the global security baseline to obtain the active filtering rule set; Step S4: Based on the active filtering rule set, perform deep granular filtering and isolation on the data payload to be inspected to obtain cleaning control data and isolation trigger signals; Step S5: Perform physical port forwarding or logical isolation blocking on the cleaning control data based on the isolation trigger signal.

[0006] Another aspect of the present invention provides a dynamic filtering and isolation system for control data based on policy issuance, comprising: The protocol decoding and feature separation module is used to perform multi-layer protocol decoding and state feature separation on the original control flow based on a pre-configured state label definition table to obtain the process state vector and the data payload to be inspected. The state matching and mode determination module is used to perform state space matching and mode classification determination on the process state vector based on the preset mode transition diagram to obtain the operating mode identifier; The policy retrieval and rule generation module is used to retrieve associated atomic policy fragments from the micro-policy repository based on the runtime mode identifier, and to perform priority fusion and conflict resolution on the atomic policy fragments and the global security baseline to obtain the active filtering rule set. The data filtering and isolation execution module is used to perform deep granular filtering and isolation execution on the data payload to be inspected based on the active filtering rule set in order to obtain cleaning control data and isolation trigger signals. The control isolation and port processing module is used to perform physical port forwarding or logical isolation blocking of cleaning control data based on the isolation trigger signal.

[0007] Compared with existing technologies, the present invention provides a dynamic filtering and isolation method and system for control data based on policy issuance. It extracts key safety invariants from the raw traffic in real time to construct a process state vector, and uses modal transformation diagrams to accurately capture semantic transformations in the production stage. Then, it deeply integrates dynamically retrieved atomic policy fragments with the global safety baseline to generate an active filtering rule set that takes effect in real time. This enables the construction of a dynamic barrier with physical dimension compliance checking capabilities, achieving a technological leap from traditional static matching to predictive blocking. This effectively identifies logically fatal instructions under compliant formats, significantly improves the defense accuracy of the control system against complex semantic threats, and ensures a high degree of unity between the industrial control network and physical production logic, as well as the inherent safety of the production process. Attached Figure Description

[0008] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0009] Figure 1 This is a flowchart of a policy-based dynamic filtering and isolation method for control data according to an embodiment of the present invention; Figure 2 This is a data flow diagram of a policy-based dynamic filtering and isolation method for control data according to an embodiment of the present invention. Figure 3 This is a flowchart of step S3 in the policy-based dynamic filtering and isolation method for control data according to an embodiment of the present invention; Figure 4 This is a block diagram of a policy-based dynamic filtering and isolation system for control data according to an embodiment of the present invention. Detailed Implementation

[0010] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the various embodiments of the present invention will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details are presented in the embodiments of the present invention to facilitate a better understanding of the invention. However, the technical solutions claimed in the present invention can be implemented even without these technical details and various variations and modifications based on the following embodiments. The division of the following embodiments is for ease of description and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined with and referenced by each other without contradiction.

[0011] As indicated in the specification and claims of this invention, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0012] While this invention makes various references to certain modules in systems according to embodiments of the invention, any number of different modules can be used and run on user terminals and / or servers. The modules described are merely illustrative, and different aspects of the systems and methods may use different modules.

[0013] This invention uses flowcharts to illustrate the operations performed by the system according to embodiments of the invention. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously, as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0014] One embodiment of the present invention provides a method for dynamic filtering and isolation of control data based on policy issuance. Figure 1 This is a flowchart of a policy-based dynamic filtering and isolation method for control data according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the data flow in a policy-based dynamic filtering and isolation method for control data according to an embodiment of the present invention. (In conjunction with...) Figure 1 and Figure 2 According to an embodiment of the present invention, a dynamic filtering and isolation method for control data based on policy issuance includes: Step S1, performing multi-layer protocol decoding and state feature separation on the original control flow based on a pre-configured state label definition table to obtain a process state vector and a data payload to be inspected; Step S2, performing state space matching and mode classification judgment on the process state vector based on a preset mode transition diagram to obtain an operating mode identifier; Step S3, retrieving associated atomic policy fragments from the micro-policy repository based on the operating mode identifier, and performing priority fusion and conflict resolution on the atomic policy fragments and the global security baseline to obtain an active filtering rule set; Step S4, performing deep granular filtering and isolation execution on the data payload to be inspected based on the active filtering rule set to obtain cleaning control data and an isolation trigger signal; Step S5, performing physical port forwarding or logical isolation blocking on the cleaning control data based on the isolation trigger signal.

[0015] Specifically, in step S1, based on a pre-configured state label definition table, multi-layer protocol decoding and state feature separation are performed on the original control flow to obtain the process state vector and the data payload to be inspected. It should be understood that existing industrial deep message inspection technologies can only achieve administrative verification at the protocol format level, failing to perceive the actual logical state of the physical production process. This makes it difficult to identify legitimate command context semantic attacks that are format-compliant but logically fatal. Through step S1, state features reflecting the physical process operation can be proactively extracted from the mixed industrial flow and transformed into a mathematical vector representation, thus providing a data foundation for subsequent modal determination. Simultaneously, extracting control commands separately as the data payload to be inspected allows for finer-grained and more dynamic filtering and isolation of command execution while perceiving physical environmental constraints. This data separation driven by physical invariants effectively fills the gap in traditional protection technologies regarding process semantic logic perception.

[0016] Step S1, in its specific implementation, includes: First, performing link-layer decapsulation and transport-layer reassembly on the original control traffic stream to obtain a protocol frame sequence. The original control traffic stream contains the Media Access Control address, Internet Protocol address, port number, industry protocol function code, register address, and register value. It should be understood that the original control traffic stream captured by the network interface card exists in bitstream form, containing encapsulation information from the physical layer, link layer (e.g., Ethernet frames), network layer (e.g., IP packets), and transport layer (e.g., TCP / UDP segments), as well as the final application-layer industry protocol data. Therefore, in the technical solution of this invention, the original control traffic stream is first decapsulated at the link layer and reassembled at the transport layer. During this process, the physical layer preamble and start-of-frame delimiter are first stripped to complete the decapsulation of the Ethernet frame (MAC frame), extracting the source / destination MAC address and payload (IP packet). Next, the IP packet is parsed to obtain information such as the source / destination IP address and protocol type. Then, the transport layer (e.g., Modbus / TCP on TCP port 502) messages are reassembled, reassembling potentially fragmented TCP packets into complete application layer message streams according to their sequence numbers. Finally, the output protocol frame sequence is a set of data units, stripped of underlying network encapsulation, arranged in logical order according to the application layer messages, and directly usable for industrial protocol parsing.

[0017] Next, the protocol frame sequence undergoes deep parsing of key fields to locate and extract the industrial protocol function code, starting register address, data length, and payload value in each frame. These values ​​are then bound to their source information to obtain the extracted field set. In this process, firstly, for each frame in the protocol frame sequence, based on its protocol type, the key control fields in its application layer header are located and parsed. Taking the Modbus / TCP protocol as an example, the parser locates the industrial protocol function code field (e.g., 03 reads holding registers, 06 writes a single register, 16 writes multiple registers), parses the starting register address field, parses the register quantity or data length field, and finally extracts the payload value (for write commands, the payload value is the data value to be written to the register). Simultaneously, to maintain data traceability, each parsed value is bound to its source context information. This source information includes at least: the Media Access Control address, Internet Protocol address, port number, and the industrial protocol function code and register address parsed in this step. In one example, data that "writes the value 0x2710 to the register at address 40001" will be bound and tagged as coming from "MAC: XX:XX:XX:XX:XX:XX, IP:192.168.1.10:502 ->192.168.1.20:502, FuncCode: 06, Address: 40001". All parsed and bound data entries together constitute the extracted field set.

[0018] Furthermore, based on the status label definition table, register address matching and data splitting are performed on the extracted field set. Data belonging to the status definition addresses are categorized into the status indication dataset, while data belonging to control commands are encapsulated into the data payload to be inspected. Here, the status label definition table is a predefined configuration file or database that explicitly lists the register addresses (or variable identifiers) used to represent process states (such as "temperature sensor T101 address: 40001-40002", "motor M201 speed address: 40100"), and the addresses used to carry control commands (such as "heater H301 switch address: 00001", "valve V401 opening setting address: 40050"). In this process, each piece of data in the extracted field set is matched against the status label definition table according to its bound register address. If the address of a data item falls within the range of the status definition addresses, then the data (value and its binding information) is categorized into the status indication dataset. Conversely, if the address of a data item is a control instruction address (typically a function code involving a write operation, such as 06 or 16), then the data item is encapsulated as a data payload to be inspected. This data payload contains not only the value to be written but also its complete source binding information, for subsequent fine-grained matching by security rules.

[0019] Subsequently, based on the key state variables defined in the state label definition table, the corresponding components of the memory-mapped vector are incrementally refreshed using the latest values ​​in the state indicator dataset. State variables that do not appear in the current frame retain their previous values ​​to obtain the process state vector. It is worth mentioning that the state label definition table not only defines the addresses of state variables, but also defines the index position and dimension of each variable in a unified state vector. In this process, a fixed-length vector, namely the process state vector, is maintained in memory, with each component corresponding to a predefined key state variable (for example, V[0] corresponds to temperature T101, and V[1] corresponds to rotational speed M201). When a new state indicator dataset is received, the state indicator dataset is traversed, and the index of its corresponding component in the process state vector is found according to the address in the data item. Then, the value of the corresponding component is refreshed with the latest value. For variables that have not received updated data in the current processing cycle (i.e., variables whose addresses do not appear in the current state indicator dataset), the value of the corresponding component in the process state vector will remain unchanged, retaining the value of the previous moment. Specifically, firstly, a time-continuous process state vector is defined. When a new status indication dataset is received at a specific moment, each record in this dataset is traversed. For each record, based on its contained register address, the predefined mapping relationship between the address and the component index of the process state vector is queried to find the corresponding position in the process state vector. Once the corresponding position is found, the latest value in this record is immediately used to overwrite the original value of the process state vector at that corresponding position. At the same time, for all other variables defined in the status label definition table but not appearing in the received status indication dataset, their corresponding component values ​​in the process state vector are not updated; instead, the values ​​of these components are left as they were at the end of the previous processing moment. Through this incremental refresh mechanism that dynamically updates based on the latest data and retains historical values ​​for missing data, a process state vector that comprehensively and in real-time reflects the current status of all key status variables is finally obtained.

[0020] Specifically, in step S2, based on a preset modality transition diagram, state space matching and modality classification are performed on the process state vector to obtain the operating modality identifier. It should be understood that even if a control command is legal in terms of protocol syntax and numerical range, it may cause a fatal accident if it does not match the current stage of the physical process. By introducing modality transition diagrams and state space matching techniques, macroscopic operational semantics can be extracted from discrete process characteristics. This modality classification judgment ensures that the execution of safety policies is no longer based on blind interception of static rules, but on-demand issuance based on production logic. This allows for the accurate identification of compliant commands that are destructive at specific process stages, ensuring a high degree of coordination between control logic and the physical entity state.

[0021] Step S2, in its specific implementation, includes: First, based on the feature space defined by the mode transition graph, the process state vector is projected into the state space and matched with the modal nodes to obtain active modal nodes. Here, the preset mode transition graph is a directed graph model, where each node represents a possible operating mode of the system (e.g., "Mode_A: Startup", "Mode_B: Running"). Each node is associated with a feature space, which defines the numerical range or characteristic conditions of the process state vector belonging to that mode. In this process, the current process state vector is projected onto the feature space defined by each modal node in the mode transition graph for matching calculation. In a specific example of the present invention, the matching algorithm may be to calculate the Euclidean distance between the process state vector and the center point of the node's feature space, or to check whether each component of the process state vector falls within the threshold interval defined by the node. For example, for a two-dimensional state vector [temperature, pressure], the feature space for modal preheating can be defined as "temperature between 50 and 80 and pressure between 0.1 and 0.5", while the feature space for modal full-speed operation can be defined as "temperature between 80 and 120 and pressure between 0.5 and 1.0". The values ​​of the process state vector are compared with the feature space conditions of each node. Nodes that successfully match (i.e., whose vectors satisfy all conditions of the node's feature space) are determined to be active modal nodes. Specifically, this matching process can be formalized as finding the node with the highest matching degree. The matching degree can vary depending on the definition of the feature space, for example, based on interval compliance calculation. That is, for a given process state vector, for each node in the modal transition graph, each component of the process state vector is checked one by one to see if it falls within the numerical range of the corresponding component defined for that node. For each component, if its value is within the range, the compliance degree of that component is recorded as 1; otherwise, it is recorded as 0. Then, the compliance degrees of all components of the process state vector are summed (or averaged) to obtain the total compliance degree of that node. After traversing all nodes, select the node with the highest total conformity as the active modality node.

[0022] Next, a standardized operating mode identifier is extracted from the attributes of the active modal nodes. This standardized identifier is then compared with the previous modality recorded in the historical modality cache to verify its legality and obtain the final operating mode identifier. In this process, identifiers are first extracted from the graph nodes, and the legality of state transitions is checked. Specifically, each node in the modality transition graph has a predefined, standardized attribute field, namely the standardized operating mode identifier (e.g., the string "MODE_STARTUP" or the numeric code "0x01"). After identifying an active modal node, this attribute field is directly read as the initial standardized operating mode identifier. Secondly, to prevent the system from jumping between modes that do not conform to process logic due to instantaneous state fluctuations or malicious injection (e.g., jumping directly from "emergency stop" to "full speed operation," skipping the necessary "reset" and "startup" modes), a transition legality check is introduced. Specifically, a historical modality cache is maintained to record the operating mode identifier finally determined in the previous processing cycle. The modal transition graph is queried to check if a directed edge exists between historical modal nodes and the currently active modal node. This directed edge represents a predefined, valid process state transition path. If this edge exists, the verification passes, and the currently extracted standardized operating modality identifier is confirmed as the final valid identifier, i.e., the final operating modality identifier. If this edge does not exist, it means that an illegal or abnormal state transition has occurred. The identifier obtained after verification, i.e., the operating modality identifier, is the final reliable operating modality identifier used in subsequent steps.

[0023] Then, based on the final operating mode identifier and the current timestamp provided by the system clock, the operating mode identifier is XORed with a time factor normalized to a preset time window size, and a one-way hash calculation is performed to obtain the policy retrieval index. This step aims to add time dimension information to the operating mode identifier, generating a more unique and timely index for subsequent policy retrieval from the micro-policy repository. In this process, firstly, the current operating mode identifier and the current timestamp provided by the system clock are obtained. Then, a preset time window size is defined. Next, the current timestamp is divided by the preset time window size, and the result is rounded down to obtain an integer, which serves as the time factor. Then, the time factor and the operating mode identifier are XORed. Bitwise XOR is a binary bitwise operation that compares each bit of the two operands; if corresponding bits are the same, the result bit is 0; otherwise, it is 1. This operation mixes mode information with time window information. Finally, a one-way hash calculation (e.g., SHA-256 algorithm) is performed on the intermediate result obtained from the XOR operation. One-way hash functions can map input data of arbitrary length to a fixed-length, seemingly random output (hash value), and the process is irreversible. This final hash value is the policy retrieval index. This policy retrieval index can be used as a primary key or part of an index to quickly and accurately retrieve policy fragments associated with a specific modality within a specific time window in the micro-policy repository.

[0024] Specifically, in step S3, based on the operational modality identifier, associated atomic policy fragments are retrieved from the micro-policy repository, and priority fusion and conflict resolution are performed on the atomic policy fragments and the global security baseline to obtain the active filtering rule set. It should be understood that security requirements in industrial control environments are highly dynamic and phased, and traditional static filtering rules cannot adapt to drastic changes in the process flow. For example, configuration instructions allowed during system startup may be considered high-risk operations during steady-state production. Through this step, atomic policy fragments that best fit the current physical conditions can be extracted in real-time and on demand from the large-scale policy repository based on the operational modality identifier determined in step S2. Simultaneously, considering that policies from different sources may have logical overlaps or contradictory actions, by prioritizing and resolving conflicts between the modality-specific policies and the global security baseline representing the system's bottom-line security, it can be ensured that the final active filtering rule set is both targeted to the current modality and possesses global-level security and logical consistency. This dynamic fusion mechanism solves the computational burden caused by policy redundancy and eliminates the risk of false blocking caused by logical conflicts, achieving perfect synchronization between protection rules and process timing.

[0025] Figure 3 This is a flowchart of step S3 in the policy-based dynamic filtering and isolation method for control data according to an embodiment of the present invention. (In conjunction with...) Figure 3 Step S3 includes: S31, using the running modality identifier as the primary key, querying and deserializing all associated policy entries in the micro-policy repository to obtain a modality-specific policy fragment set; S32, reading the global security baseline from the system's protected memory area to generate a baseline rule set, and performing a set union operation between the modality-specific policy fragment set and the baseline rule set to obtain the original candidate rule pool; S33, performing priority-based conflict resolution and active set instantiation on the original candidate rule pool to obtain the active filtering rule set.

[0026] Specifically, in step S31, using the runtime modality identifier as the primary key, all associated policy entries are queried and deserialized in the micro-policy repository to obtain a set of modality-specific policy fragments. During this process, a micro-policy repository is maintained; this is a persistent storage system (such as a database or configuration file), where each policy entry (atomic policy fragment) is indexed and associated using one or more runtime modality identifiers as tags. In one example, a policy entry identified as "MODE_FILLING" is only retrieved when the system is in the filling modality. When this step receives a specific runtime modality identifier (such as "FILLING"), it uses this identifier as the primary key or query condition to initiate a query in the micro-policy repository. The query statement logic is: "Find all policy entries whose tags contain 'FILLING'". The query returns a set of serialized policy data (e.g., data blocks in JSON or binary format). These data blocks are then deserialized, loaded into memory, and restored to structured policy objects (e.g., objects containing fields such as matching conditions, actions, and priorities) that can be understood and processed by the program. All these loaded policy objects together constitute a modality-specific policy fragment set, which represents the security rules that match the currently running modality.

[0027] Specifically, in step S32, a baseline rule set is generated by reading the global security baseline from the system's protected memory area, and a set union operation is performed between the modality-specific policy fragment set and the baseline rule set to obtain the original candidate rule pool. In this process, firstly, at startup, a set of the highest-level, mandatory security rules (global security baseline) is loaded into a protected memory area to prevent accidental modification or attack. These rules define the security baseline that must be followed under all circumstances. Specifically, these rules are read directly from the protected memory area and organized into a structured set of rule objects, i.e., the baseline rule set. Then, a logical set union operation is performed, which creates an original candidate rule pool at the program logic level. This pool initially contains all rules from the modality-specific policy fragment set. Subsequently, all rules from the global security baseline rule set are also added one by one to the same original candidate rule pool. This operation does not perform deduplication or logical merging; it simply physically or logically gathers all rule references or copies into the same set. The final original candidate rule pool is a set containing all currently available rules.

[0028] Specifically, step S33 involves priority-based conflict resolution and active set instantiation of the original candidate rule pool to obtain an active filtering rule set. This step specifically includes: first, performing conflict detection on the original candidate rule pool to identify rule pairs that target the same object but have contradictory actions. Specifically, the original candidate rule pool is traversed to identify rule pairs that target the same object but have contradictory actions. Here, the same object is usually determined by matching conditions in the rules (such as protocol, source / destination IP, register address range, function code). For example, rule A specifies "allow write operations to register addresses [40000, 40010]", while rule B specifies "block write operations to register addresses [40005, 40015]". These two rules create a contradiction between "allow" and "block" actions for "write operations" within the address range [40005, 40010], constituting a conflicting rule pair. Furthermore, based on a preset priority weight matrix, conflict resolution is performed according to the principle that the global security baseline takes precedence over modality-specific policies and blocking actions take precedence over allowing actions, removing covered or invalid rules to obtain the active filtering rule set. Specifically, when a baseline rule conflicts with a modality policy rule, the baseline rule wins regardless of their specific actions. The part of the modality policy rule that conflicts with the baseline is marked as "covered" or "invalid". When two rules belonging to the same priority level (e.g., both baselines or policies of the same modality) conflict, the rule that performs the "blocking" action wins, and the rule that performs the "allowing" action is covered. In practice, this can be achieved through a priority value comparison. Specifically, each rule is assigned a comprehensive priority value, which consists of two parts: the first part is the weight of the rule's source, usually the weight of the global security baseline is much higher than the weight of the modality-specific policy; the second part is the weight of the rule action, usually the weight of the "blocking" action is higher than the weight of the "allowing" action. These two weights are added together to obtain the final priority score for each rule. When two rules conflict, their priority scores are compared. The rule with the higher score is considered valid, while the rule with the lower score is deemed invalid or overridden in the context of the conflict. If the priority scores of the two rules are exactly equal, a default rule is applied, such as "blocking action priority," and the rule specifying the blocking action wins. After all conflicts are resolved, all rules marked as "invalid" or "overridden" are removed from the original candidate rule pool. The remaining valid rules constitute the final output active filtering rule set. This rule set is logically self-consistent; for any given packet matching condition, at most one rule will give a definite action (block or allow), providing a clear and unambiguous decision basis for the next step of data filtering.

[0029] Specifically, in step S4, based on the active filtering rule set, deep granular filtering and isolation execution are performed on the data payload to be inspected to obtain cleansing control data and isolation trigger signals. That is, by performing deep granular filtering and isolation execution on the data payload to be inspected, abstract security policies are transformed into specific control action interceptions, thereby achieving the final closed loop from deep packet parsing on the network side to compliance checks on the physical side. Specifically, this step not only identifies the syntactic correctness of instructions but also assesses the potential risk level of instructions in the current production mode by calculating security scores. This deep granular auditing mechanism can accurately eliminate malicious or non-compliant instructions that may lead to production accidents—the so-called cleansing process. Simultaneously, by generating clear isolation trigger signals, immediate instructions are provided for physical-level connection disconnection or logical-level interception, ensuring that the industrial control network can achieve predictive blocking when facing complex semantic threats, thereby completely solving the problem of attacks on correctly formatted but logically fatal instructions and ensuring the absolute security of physical production logic.

[0030] Step S4, in its specific implementation, includes: First, performing field decomposition and numerical normalization on the data payload to be inspected, converting the target register address, written value, and operation instruction type into a standardized format and assembling them into a payload feature vector. The data payload to be inspected is a structured object containing all the context information of the original instruction (such as source IP, target IP, protocol, function code, register address, written value, etc.). In this process, firstly, the payload is decomposed into fields, that is, according to the format of the industry protocol, the key fields used for security matching are precisely separated, mainly including "target register address", "written value", and "operation instruction type" (usually represented by function code, such as "write single register" or "write multiple registers"). Next, numerical normalization is performed to eliminate the diversity of data representation and ensure the accuracy of matching. For example, the register address may be represented in decimal or hexadecimal, so it is uniformly converted into an internal standard format; the written value may be a signed integer, unsigned integer, or floating-point number, so it is converted into a standardized numerical representation; and the operation instruction type is mapped to a predefined enumerated value. After normalization, these processed key fields are assembled into a structured data object to obtain the payload feature vector. This vector can be formally represented as a structure containing key features such as normalized address, normalized value, and normalization operation type, which is used for deep rule matching.

[0031] Next, the payload feature vector is logically compared with each rule in the active filtering rule set. For matched rules, a single-item matching score is calculated based on address range overlap and opcode consistency. A weighted cumulative calculation is then performed based on the weight coefficients and rejection factors of each rule. When an absolute blocking rule is matched, the rejection factor is set to zero, forcing the total score to zero, thus obtaining a security score and a list of matching rule actions. In this process, firstly, each rule in the active filtering rule set is traversed. Each rule defines its matching conditions, which are also based on the target register address (which may be a range), operation instruction type, source / destination IP, and even the range of written values. The payload feature vector is compared with the matching conditions of each rule one by one. If the feature vector satisfies all the matching conditions of a rule, then that rule is matched. Secondly, for each matched rule, its single-item matching score is calculated to quantify the degree of matching between the current payload and that rule. This score is typically based on address range overlap and opcode consistency. The principle behind address range overlap is as follows: It determines the proportion of the payload's target address falling within the address range defined by the rule. If the payload's target address falls entirely within the defined address range, the overlap is at its highest value (e.g., 1). If the payload's target address partially falls within the defined address range, a value between 0 and 1 is calculated based on the ratio of the overlapping portion to the payload address (or the rule's address range). The principle behind opcode consistency is a Boolean judgment: if the payload's operation instruction type is completely consistent with the operation type defined by the rule, the consistency is 1; otherwise, it is 0. The single-item matching score is a weighted sum of these two dimensions, where the weight coefficient represents the relative importance of address matching and opcode matching in the score. Finally, by combining the results of all matching rules, a final security score is obtained. This process is based on cumulative weighted calculations. Each matching rule, in addition to its matching score, has a preset weight coefficient (representing the rule's importance) and a key veto factor (usually defaulting to 1). The initial value of the security score, i.e., the matching score, is 0. For each matching rule, its contribution is the product of the rule's weight coefficient, the single-item matching score, and the veto factor. The contributions of all matching rules are summed. When an absolute blocking rule is matched, its rejection factor is set to zero, making its contribution to the total score zero. The entire security score calculation logic triggers a special process: the final total score is forcibly set to 0 or a very low negative value to indicate absolute insecurity. Specifically, the system first checks if any "absolute blocking" rules exist among the matched rules. If so, the final security score is directly determined to be 0, regardless of the calculation results of other non-absolute blocking rules. If no absolute blocking rules exist, the final security score is equal to the sum of the products of the weight coefficients of all matched rules and their individual matching scores.At the same time, it will record a list of matching rule actions for all hit rules (such as "allow", "block", "log" etc.).

[0032] Next, the security score is compared with a preset security pass threshold. If the security score is not lower than the security pass threshold and there is no explicit isolation action in the matching rule action list, the data payload to be inspected is marked as cleaning control data and an invalid level isolation trigger signal is generated. If the security score is lower than the security pass threshold or there is an explicit isolation action, the cleaning control data is set to a no-operation instruction and an active level isolation trigger signal is generated. During this process, a preset security pass threshold is used, which is a configurable parameter used to define the quantization boundary between security and insecurity. Then, the following decision logic is executed: Condition A: The security score is greater than or equal to the security pass threshold, and there is no rule in the matching rule action list whose action is "explicit isolation" or "blocking". Specifically, if condition A is met, the decision is security. The original data payload to be inspected is marked as cleaning control data. This means that the data payload to be inspected is considered clean and safe, and can be allowed to pass. At the same time, an invalid level isolation trigger signal (e.g., logic '0' or low level) is generated, indicating that subsequent steps do not require isolation blocking and this data should be forwarded. Condition B: The safety score is less than the safety pass threshold, or at least one "explicit isolation" or "blocking" action exists in the matching rule action list. Specifically, if Condition B is met (i.e., as long as the score is below the threshold or a rule explicitly requires blocking), the system is deemed unsafe. The cleansing control data is set to a no-op instruction (e.g., modifying a write instruction to a no-op code or safe value with no practical effect), or simply left empty. Simultaneously, a valid isolation trigger signal (e.g., logic '1' or high) is generated, indicating that subsequent steps must perform an isolation blocking operation. This decision process ensures that the ruling depends not only on the quantified risk score but also on the explicitly specified action intent in the rules, making safety controls more precise and reliable.

[0033] Specifically, in step S5, physical port forwarding or logical isolation blocking is performed on the cleaning control data based on the isolation trigger signal. It should be understood that the security judgment result calculated through the preceding steps must be applied to the underlying communication link in real time and accurately to truly achieve the interception of illegal commands or the release of legitimate commands. In industrial control environments, security protection requires not only the ability to identify risks but also the ability to block them. In the technical solution of this invention, by reading the isolation trigger signal, logical isolation blocking can be implemented for risky commands. This not only prevents malicious commands from being sent to field devices by discarding cached data but also actively cuts off abnormal logical connections by sending reset packets, preventing the continued spread of attacks. Simultaneously, for cleaning control data determined to be safe, this step ensures that it is efficiently forwarded through the physical port after re-encapsulation, guaranteeing the continuity and real-time nature of the physical production process. This execution mechanism based on hardware signal feedback ensures strong consistency between the control logic and the communication link status, building the final physical barrier for the industrial control system.

[0034] Step S5, in its specific implementation, includes: reading the status of the isolation trigger signal; if the isolation trigger signal is valid, sending a reset packet to the sending end and discarding buffered data to disconnect the logical connection; if the isolation trigger signal is invalid, re-encapsulating the cleaning control data into an Ethernet frame and writing it into the transmit buffer of the physical network interface to complete media transmission. Specifically, when the isolation trigger signal is invalid, physical port forwarding is performed. In this process, firstly, the status of the isolation trigger signal is read. If an invalid level is detected (e.g., logic '0', low level, or a Boolean value representing "no" false), it is determined that the current cleaning control data is safe and should be forwarded normally. Subsequently, the forwarding operation is performed. The core of the forwarding operation is to re-encapsulate the cleaning control data in memory into a standard format that can be transmitted over the network. This encapsulation process is the reverse of the preceding decoding steps: based on the context information of the original data packet (such as source / destination MAC address, IP address, port number) and the industrial protocol content (function code, register address, value, etc.) in the cleaned control data, it is reassembled into a complete and valid Ethernet frame according to the corresponding industrial protocol (such as Modbus / TCP) format and the underlying network protocol (TCP / IP, Ethernet) format. Finally, this Ethernet frame is written to the transmit buffer of the target physical network interface (such as the network card connected to the programmable logic controller PLC). Once written to the transmit buffer, the hardware of the network interface controller (NIC) automatically completes media access control and sends the data frame out through the physical line (such as a network cable), thereby completing the forwarding to the physical port of the controlled device. Conversely, when the isolation trigger signal is at a valid level, logical isolation blocking is performed. In this process, firstly, the status of the isolation trigger signal is read. If the signal is detected to be at a valid level (such as logic '1', high level, or a Boolean value of true representing "yes"), it is determined that there is a security threat to the current connection or data flow, and isolation blocking must be performed. Subsequently, a series of logical isolation operations are performed. In practice, the first step is to send a reset packet to the data sender. This is a proactive network layer interference measure. For example, if the current connection is based on the TCP protocol, a TCP RST (reset) packet from the receiver (or acting as a man-in-the-middle) can be forged and sent to the attack source. This RST packet will forcibly terminate the TCP connection that the attack source believes exists, disrupting its attack rhythm. Secondly, cached data is discarded. All currently processed packets deemed malicious, as well as any subsequent cached data potentially related to this session, are discarded to ensure that this harmful data is not further processed or leaked. Finally, the logical connection is severed. That is, in its internal session state table, this connection (identified by the five-tuple: protocol, source IP, source port, destination IP, destination port) is marked as "isolated" or its session state is directly deleted.All subsequent data packets belonging to this logical connection will be discarded at an earlier stage without requiring complex deep parsing. This improves blocking efficiency and achieves continuous isolation. This series of operations together constitutes logical isolation blocking, the goal of which is not only to block individual malicious data packets, but also to interrupt malicious communication sessions.

[0035] In summary, the policy-based dynamic filtering and isolation method for control data according to embodiments of the present invention is explained. It extracts key safety invariants from the raw traffic in real time to construct a process state vector, and uses modal transition diagrams to accurately capture semantic transitions in the production stage. Then, it deeply integrates dynamically retrieved atomic policy fragments with the global safety baseline to generate an active filtering rule set that takes effect in real time. This method can construct a dynamic barrier with physical dimension compliance checking capabilities, achieving a technological leap from traditional static matching to predictive blocking. As a result, it can effectively identify logically fatal instructions under compliant formats, significantly improve the defense accuracy of the control system against complex semantic threats, and ensure the high degree of unity between the industrial control network and the physical production logic, as well as the inherent safety of the production process.

[0036] An embodiment of the present invention also provides a dynamic filtering and isolation system for control data based on policy issuance.

[0037] Figure 4 This is a block diagram of a policy-based control data dynamic filtering and isolation system according to an embodiment of the present invention. Figure 4 As shown, the control data dynamic filtering and isolation system 300 based on policy issuance according to an embodiment of the present invention includes: a protocol decoding and feature separation module 310, used to perform multi-layer protocol decoding and state feature separation on the original control flow based on a pre-configured state label definition table to obtain a process state vector and a data payload to be inspected; a state matching and mode determination module 320, used to perform state space matching and mode classification determination on the process state vector based on a preset mode transition diagram to obtain an operating mode identifier; a policy retrieval and rule generation module 330, used to retrieve associated atomic policy fragments from the micro-policy repository based on the operating mode identifier, and perform priority fusion and conflict resolution on the atomic policy fragments and the global security baseline to obtain an active filtering rule set; a data filtering and isolation execution module 340, used to perform deep granular filtering and isolation execution on the data payload to be inspected based on the active filtering rule set to obtain cleaning control data and an isolation trigger signal; and a control isolation and port processing module 350, used to perform physical port forwarding or logical isolation blocking on the cleaning control data based on the isolation trigger signal.

[0038] The specific implementation method of the policy-based dynamic filtering and isolation system for control data provided in this embodiment of the invention can be found in the description of the policy-based dynamic filtering and isolation method for control data provided in this embodiment of the invention, and will not be repeated here.

[0039] The policy-based dynamic filtering and isolation system 300 for control data according to embodiments of the present invention can be implemented in various wireless terminals, such as servers with a policy-based dynamic filtering and isolation algorithm for control data. In one possible implementation, the policy-based dynamic filtering and isolation system 300 for control data according to embodiments of the present invention can be integrated into the wireless terminal as a software module and / or a hardware module. For example, the policy-based dynamic filtering and isolation system 300 for control data can be a software module in the operating system of the wireless terminal, or it can be an application developed for the wireless terminal; of course, the policy-based dynamic filtering and isolation system 300 for control data can also be one of many hardware modules of the wireless terminal.

[0040] Alternatively, in another example, the policy-based control data dynamic filtering and isolation system 300 and the wireless terminal can also be separate devices, and the policy-based control data dynamic filtering and isolation system 300 can be connected to the wireless terminal via wired and / or wireless networks, and transmit interactive information in accordance with the agreed data format.

[0041] Those skilled in the art will understand that the above embodiments are specific implementations of the present invention, and in practical applications, various changes can be made in form and detail without departing from the spirit and scope of the present invention.

Claims

1. A method for dynamic filtering and isolation of control data based on policy issuance, characterized in that, include: Step S1: Based on the pre-configured state label definition table, perform multi-layer protocol decoding and state feature separation on the original control flow to obtain the process state vector and the data payload to be inspected; Step S2: Based on the preset mode transition diagram, perform state space matching and mode classification on the process state vector to obtain the operating mode identifier; Step S3: Based on the runtime mode identifier, retrieve the associated atomic policy fragments from the micro-policy repository, and perform priority fusion and conflict resolution on the atomic policy fragments and the global security baseline to obtain the active filtering rule set; Step S4: Based on the active filtering rule set, perform deep granular filtering and isolation on the data payload to be inspected to obtain cleaning control data and isolation trigger signals; Step S5: Perform physical port forwarding or logical isolation blocking on the cleaning control data based on the isolation trigger signal.

2. The dynamic filtering and isolation method for control data based on policy issuance according to claim 1, characterized in that, The raw control flow contains the Media Access Control address, Internet Protocol address, port number, Industry Protocol function code, register address, and register value.

3. The dynamic filtering and isolation method for control data based on policy issuance according to claim 2, characterized in that, Step S1 includes: The original control traffic stream is decapsulated at the link layer and reassembled at the transport layer to obtain a protocol frame sequence. The protocol frame sequence is subjected to in-depth analysis of key fields. The industrial protocol function code, start register address, data length and payload value in each frame are located and extracted. The values ​​are then bound to their source information to obtain the set of extracted fields. Based on the status label definition table, register address matching and data splitting are performed on the extracted field set. Data belonging to the status definition address is classified into status indication dataset, and data belonging to control instructions is encapsulated into data payload to be inspected. Based on the key state variables defined in the state label definition table, the corresponding components of the memory mapping vector are incrementally refreshed using the latest values ​​in the state indicator dataset. State variables that do not appear in the current frame are kept unchanged from the previous moment to obtain the process state vector.

4. The dynamic filtering and isolation method for control data based on policy issuance according to claim 1, characterized in that, Step S2 includes: Based on the feature space defined by the mode transition graph, the process state vector is projected into the state space and matched with the mode nodes to obtain the active mode nodes; Extract standardized runtime mode identifiers from the attributes of active modal nodes, and perform a conversion validity check between the standardized runtime mode identifiers and the previous time mode recorded in the historical modality cache to obtain the final runtime mode identifier.

5. The dynamic filtering and isolation method for control data based on policy issuance according to claim 4, characterized in that, Step S2 also includes: Based on the final operating mode identifier and the current timestamp provided by the system clock, the operating mode identifier is XORed with a time factor normalized to a preset time window size, and a one-way hash calculation is performed to obtain the strategy retrieval index.

6. The dynamic filtering and isolation method for control data based on policy issuance according to claim 1, characterized in that, Step S3 includes: Using the runtime modality identifier as the primary key, query and deserialize all associated policy entries in the micro-policy repository to obtain a set of modality-specific policy fragments; The system reads the global security baseline from the protected memory area to generate a baseline rule set, and performs a set union operation on the modality-specific policy fragment set and the baseline rule set to obtain the original candidate rule pool. Priority-based conflict resolution and active set instantiation are performed on the original candidate rule pool to obtain the active filtering rule set.

7. The dynamic filtering and isolation method for control data based on policy issuance according to claim 6, characterized in that, The original candidate rule pool is subjected to priority-based conflict resolution and active set instantiation to obtain the active filtering rule set, including: Conflict detection is performed on the original candidate rule pool to identify rule pairs that target the same object but have contradictory actions; Based on a preset priority weight matrix, conflict resolution is performed according to the principle that the global security baseline takes precedence over modality-specific policies and blocking actions take precedence over releasing actions, removing covered or invalid rules to obtain an active filtering rule set.

8. The method for dynamic filtering and isolation of control data based on policy issuance according to claim 1, characterized in that, Step S4 includes: The data payload to be inspected is decomposed into fields and normalized in numerical form. The target register address, written value and operation instruction type are uniformly converted into a standardized format and assembled into a payload feature vector. The payload feature vector is logically compared with each rule in the active filtering rule set. For the matched rules, the individual matching score is calculated according to the address range overlap and opcode consistency. The weighted cumulative calculation is performed based on the weight coefficient and rejection factor of each rule. When an absolute blocking rule is matched, the rejection factor is set to zero to force the total score to zero, so as to obtain the security score and the list of matching rule actions. The safety score is compared with the preset safety pass threshold. If the safety score is not lower than the safety pass threshold and there is no explicit isolation action in the matching rule action list, the data payload to be tested is marked as cleaning control data and an invalid level isolation trigger signal is generated. If the safety score is lower than the safety pass threshold or there is an explicit isolation action, the cleaning control data is set to a no-operation command and an effective level isolation trigger signal is generated.

9. The dynamic filtering and isolation method for control data based on policy issuance according to claim 1, characterized in that, Step S5 includes: Read the status of the isolation trigger signal; if the isolation trigger signal is valid, send a reset packet to the sender and discard the buffered data to cut off the logical connection; if the isolation trigger signal is invalid, re-encapsulate the cleaning control data into an Ethernet frame and write it into the transmit buffer of the physical network interface to complete the media transmission.

10. A dynamic filtering and isolation system for control data based on policy issuance, characterized in that, include: The protocol decoding and feature separation module is used to perform multi-layer protocol decoding and state feature separation on the original control flow based on a pre-configured state label definition table to obtain the process state vector and the data payload to be inspected. The state matching and mode determination module is used to perform state space matching and mode classification determination on the process state vector based on the preset mode transition diagram to obtain the operating mode identifier; The policy retrieval and rule generation module is used to retrieve associated atomic policy fragments from the micro-policy repository based on the runtime mode identifier, and to perform priority fusion and conflict resolution on the atomic policy fragments and the global security baseline to obtain the active filtering rule set. The data filtering and isolation execution module is used to perform deep granular filtering and isolation execution on the data payload to be inspected based on the active filtering rule set in order to obtain cleaning control data and isolation trigger signals. The control isolation and port processing module is used to perform physical port forwarding or logical isolation blocking of cleaning control data based on the isolation trigger signal.

Images