Power monitoring host reinforcement method for multi-source operating system

Abstract

The application discloses a power monitoring host reinforcement method for a multi-source operating system, and relates to the technical field of power monitoring host security protection.The method comprises the following steps: collecting the inter-process communication behavior and network communication behavior of each process on the power monitoring host, and constructing a process communication observation record set; constructing an intra-host process communication graph; identifying the protocol semantic features in the power protocol message, and forming an enhanced process communication graph; generating an intra-host process-level micro-isolation whitelist strategy; identifying the operating system type of the power monitoring host, converting the whitelist strategy into a filtering rule, and making the filtering rule take effect.The application solves the technical problems that the prior art cannot identify power protocol semantics, cannot distinguish between business traffic and attack traffic, and cannot make the strategy take effect on multiple types of operating systems, and achieves the technical effects of realizing process-level micro-isolation based on protocol semantics and cross-system strategy adaptation, and improving the security protection capability and reinforcement universality of the power monitoring host.

Description

Technical Field

[0001] This invention relates to the field of power monitoring host security protection technology, specifically to a method for hardening power monitoring hosts for multi-source operating systems. Background Technology

[0002] Power monitoring hosts, often running on heterogeneous operating systems such as Windows and Linux, are critical nodes in power industrial control systems. Currently, the industry predominantly employs traditional network-layer micro-segmentation solutions based on IP and ports for security protection. This approach only manages basic network connections and cannot parse the semantic features of power-specific protocols such as IEC 104 and 61850, making it difficult to accurately distinguish between normal business traffic and malicious lateral movement attacks, resulting in coarse-grained protection. Furthermore, existing protection strategies lack cross-platform adaptability, requiring separate writing and configuration of filtering rules for different operating systems, leading to cumbersome deployment processes and hindering unified management and batch application of policies. Traditional solutions fail to meet the fine-grained isolation requirements at the process level in power scenarios and suffer from poor multi-system compatibility and insufficient protection effectiveness, making it difficult to cope with increasingly complex industrial control network security threats. Therefore, there is an urgent need for host hardening solutions that adapt to multiple operating systems and incorporate power protocol semantics.

[0003] Existing technologies have technical problems such as being unable to recognize power protocol semantics, having difficulty distinguishing between business traffic and attack traffic, and the inability of policies to take effect uniformly across multiple operating systems. Summary of the Invention

[0004] This application provides a method for hardening power monitoring hosts for multi-source operating systems, which addresses the technical problems of existing technologies, such as the inability to recognize power protocol semantics, the difficulty in distinguishing between service traffic and attack traffic, and the inability of strategies to take effect uniformly across multiple operating systems.

[0005] In view of the above problems, this application provides a method for hardening power monitoring hosts for multi-source operating systems.

[0006] This application provides a method for hardening a power monitoring host for multi-source operating systems, the method comprising: The system collects inter-process communication and network communication behaviors of each process on the power monitoring host to construct a process communication observation record set. Based on the process communication observation record set, an intra-host process communication graph is constructed with processes as nodes and allowed communication relationships as edges. Deep analysis is performed on communication packets flowing through each monitoring port within the host to identify protocol semantic features in power protocol packets. These protocol semantic features are then associated with the attributes of the corresponding edges in the intra-host process communication graph to form an enhanced process communication graph. Based on the enhanced process communication graph, the range of communication peers and ports that each process is allowed to initiate and receive is derived using the principle of minimizing privileges, generating an intra-host process-level micro-isolation whitelist policy. The operating system type of the power monitoring host is identified. When identified as a first type of operating system, the intra-host process-level micro-isolation whitelist policy is converted into a first filtering rule corresponding to the first type of operating system and implemented. When identified as a second type of operating system, the intra-host process-level micro-isolation whitelist policy is converted into a second filtering rule corresponding to the second type of operating system and implemented.

[0007] One or more technical solutions provided in this application have at least the following technical effects or advantages: This system collects inter-process communication (IPC) and network communication behaviors of various processes on a power monitoring host, constructing a set of IPC observation records. It then builds an intra-host IPC graph. Deep analysis is performed on communication packets flowing through each monitoring port within the host to identify protocol semantic features in the power protocol packets. These semantic features are then associated with the attributes of corresponding edges in the intra-host IPC graph, forming an enhanced IPC graph. An intra-host process-level micro-segmentation whitelist policy is generated. The system identifies the operating system type of the power monitoring host. When identified as a first-type operating system, the intra-host process-level micro-segmentation whitelist policy is converted into a first filtering rule corresponding to the first-type operating system and implemented. When identified as a second-type operating system, the policy is converted into a second filtering rule corresponding to the second-type operating system and implemented. This achieves the technical effect of realizing protocol-semantic-based process-level micro-segmentation and cross-system policy adaptation, improving the security protection capabilities and strengthening the versatility of the power monitoring host. Attached Figure Description

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

[0009] Figure 1A schematic flowchart of a power monitoring host hardening method for multi-source operating systems provided in this application embodiment; Figure 2 This is a flowchart illustrating the process of constructing an intra-host process communication graph in the power monitoring host hardening method for multi-source operating systems provided in this application embodiment. Detailed Implementation

[0010] This application provides a method for hardening power monitoring hosts for multiple operating systems, which addresses the technical problems of existing technologies, such as the inability to recognize power protocol semantics, the difficulty in distinguishing between service traffic and attack traffic, and the inability of strategies to take effect uniformly across multiple operating systems.

[0011] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0012] Examples, such as Figure 1 As shown, this application provides a method for hardening a power monitoring host for multi-source operating systems, the method comprising: Step S100: Collect the inter-process communication behavior and network communication behavior of each process on the power monitoring host, and construct a set of process communication observation records.

[0013] Specifically, the system continuously monitors all running processes of the power monitoring host, comprehensively collecting local interactive communication behaviors between processes and network communication behaviors initiated by processes. It synchronously records raw data such as process name, process ID, communication initiator, communication receiver, listening port, destination IP, destination port, transport layer protocol, communication start and end time, and number of communications. It cleans and organizes duplicate, incomplete, and invalid data, classifies and summarizes all valid communication behavior data according to a unified data format, and arranges them in a structured manner. Finally, it integrates them into a standardized and complete set of process communication observation records.

[0014] Step S200: Based on the process communication observation record set, construct an intra-host process communication graph with processes as nodes and allowed communication relationships as edges.

[0015] Specifically, based on the complete data within the process communication observation record set, each running process in the set is first used as an independent node in the graph, and the inter-process communication relationships and network communication relationships recorded in the records are used as connecting edges between nodes to build an initial process communication graph. Then, noise filtering is performed on the initial graph to remove temporary process nodes with a lifespan shorter than a preset lifespan threshold, and occasional connecting edges with fewer than a preset communication count threshold are also removed to obtain a standard process communication graph. Finally, the standard process communication graph is retrieved, and multiple process instance nodes with the same executable file path and identical command line parameters are merged into a single logical business process node, thus completing the construction of the host-internal process communication graph.

[0016] Step S300: Perform deep analysis on the communication packets flowing through each listening port within the host, identify the protocol semantic features in the power protocol packets, and associate the protocol semantic features with the attributes of the corresponding edges in the process communication graph within the host to form an enhanced process communication graph.

[0017] Specifically, the system captures and deeply analyzes the transmission communication messages of each listening port of the host. By identifying the start identifier in the header of the message data frame, different power protocol types are distinguished. When the start identifier of the first type of power protocol is detected, the protocol type identifier, message function type identifier, and associated device address in the message are extracted as the first protocol semantic features. When the start identifier of the second type of power protocol is detected, the protocol type identifier, service primitive type identifier or application identifier, and dataset member list in the message are extracted as the second protocol semantic features. Then, all the connection edges of the process communication graph within the host are traversed to determine the source process node, destination process node, and matching listening port number corresponding to each edge. The two types of protocol semantic features obtained from the parsing of the corresponding port are filled into the protocol semantic annotation field of the edge. After completing the attribute supplementation of all edges, an enhanced process communication graph with enhanced protocol semantics is finally formed.

[0018] Step S400: Based on the enhanced process communication graph, deduce the range of communication peers and ports that each process is allowed to initiate and receive, using the principle of minimizing privileges, and generate a host-level process-level micro-isolation whitelist strategy.

[0019] Specifically, based on the completed enhanced process communication graph, strictly following the principle of minimizing privilege, each connection edge in the graph is traversed sequentially. First, the semantic features of the protocol associated with the edge are used to determine whether the communication falls within the scope of compliance. Then, the source process node and the destination process node at both ends of the edge are verified to be in the same security zone and to conform to the preset upstream and downstream business relationship. Only the connection edges that simultaneously meet the requirements of compliant communication scope, same security zone, and upstream and downstream business relationship are retained, and the remaining connection edges that do not meet the requirements are removed. Subsequently, the remaining valid connection relationships are mapped one by one to policy entries containing source process identifier, source port, destination IP, destination port, and allowed protocol type. After summarizing all valid entries, a complete host-level process-level micro-segmentation whitelist policy is generated.

[0020] Step S500: Identify the operating system type of the power monitoring host. When it is identified as a first type of operating system, convert the process-level micro-segmentation whitelist policy within the host into a first filtering rule corresponding to the first type of operating system and apply it. When it is identified as a second type of operating system, convert the process-level micro-segmentation whitelist policy within the host into a second filtering rule corresponding to the second type of operating system and apply it.

[0021] Specifically, the system automatically identifies the operating system type of the power monitoring host. If it is determined to be a first-type operating system, each policy entry in the process-level micro-segmentation whitelist policy within the host is converted into a first filtering rule that adapts to the network filtering framework of that operating system. The first filtering rule is then sent to the system and takes effect in a forced interception mode. If it is determined to be a second-type operating system, each whitelist policy is converted into a second filtering rule that matches the network filtering framework of that operating system. After the rule is sent, it also runs in a forced interception mode, thereby achieving the adaptation and implementation of isolation and hardening policies under different operating systems.

[0022] In one possible implementation, such as Figure 2 As shown, step S200 further includes: Step S210: Using each process in the process communication observation record set as a node, and the inter-process communication relationships and network communication relationships recorded in the process communication observation record set as edges, construct an initial process communication graph.

[0023] Step S220: Noise filtering is performed on the initial process communication graph, temporary process nodes with a lifespan shorter than a preset lifespan are removed, and occasional connection edges with fewer than a preset number of communications are removed, to obtain a standard process communication graph.

[0024] Step S230: Merge multiple instance process nodes with the same executable file path and the same command line parameters in the standard process communication graph into a single logical business process node to obtain the host intra-process communication graph.

[0025] Specifically, the generated set of process communication observation records is retrieved, and each running process in the set is set as an independent node in the graph. The various communication relationships recorded in the set are used as connecting edges between nodes. Among them, inter-process communication relationships include shared memory access, signal transmission, and socket communication, while network communication relationships include TCP connections and UDP communication established between processes and external devices. Based on the above correspondence between nodes and edges, the initial process communication graph is fully constructed.

[0026] Noise filtering is performed on the initial process communication graph that has been built. The runtime of all process nodes in the graph is checked one by one. Temporary process nodes with a lifespan of less than the preset lifespan threshold are removed. At the same time, the number of communication interactions corresponding to each connection edge in the graph is counted one by one. Occasional connection edges with fewer than the preset communication number threshold are removed. After the above two rounds of screening and purification, a standard process communication graph with a normal structure and valid data is finally obtained.

[0027] Traverse all process nodes in the standard process communication graph, compare the executable file path and startup command line parameters of each node one by one, integrate multiple multi-instance process nodes with the same executable file path and the same command line parameters, merge them into a single logical business process node, and simultaneously retain all the original communication connection relationships and associated attributes of the node. After completing the merging operation of all nodes of the same type, the host intra-process communication graph is finally obtained.

[0028] In one possible implementation, step S200 further includes: The process identifier, listening port, destination IP, destination port, and transport layer protocol information of each node in the host intra-process communication graph are labeled to form a structured host intra-process communication graph.

[0029] Specifically, the process involves traversing each process node in the intra-host process communication graph. Each process node represents a basic unit in the graph that symbolizes a single running process of the power monitoring host. The process identifier corresponding to each process node is extracted sequentially; this includes the process ID and process name that uniquely distinguish different processes. Simultaneously, the listening port bound to the process is collected—the port number on which the process provides communication services and continuously listens for data packets—as well as the destination IP and destination port to which the process initiates communication, i.e., the network address and corresponding service port of the communication interface device. The transport layer protocol used for communication is also identified, including mainstream network transport protocols such as TCP and UDP. All of the above attribute information is then labeled onto the corresponding process node according to a unified format. Based on standardized information labeling, data is organized, ultimately forming a structured intra-host process communication graph with complete information dimensions and a standardized organizational form.

[0030] In one possible implementation, step S300 further includes: Step S310: Perform deep parsing on the communication packets flowing through each listening port in the host, check the data frame header of each communication packet one by one, and when the data frame header is detected to contain the start identifier of the first type of power protocol, mark the corresponding communication packet as a packet that conforms to the first type of power protocol, and read the values ​​of the protocol type identifier field, the packet function type identifier field and the associated device address field from the packet in sequence as the first protocol semantic feature.

[0031] Step S320: When the start identifier of the second type of power protocol is detected in the data frame header, the corresponding communication message is marked as a message conforming to the second type of power protocol, and the values ​​of the protocol type identifier field, service primitive type identifier field or application identifier field and dataset member list field are read from the message in sequence as the second protocol semantic features.

[0032] Specifically, communication packets flowing through all listening ports of the power monitoring host are collected and deep parsed. The header content of each communication packet is examined one by one. Once the start identifier corresponding to the first type of power protocol is identified in the header of the data frame, the communication packet is immediately marked as a first type of power protocol packet. Then, the specific values ​​of the protocol type identifier field, the packet function type identifier field, and the associated device address field in the packet are extracted in the order of the packet format. The values ​​of the three sets of fields are integrated together to form the first protocol semantic feature corresponding to the packet.

[0033] Continue to inspect the headers of the data frames of the communication messages received by each listening port of the host. If the header of the data frame is found to carry the start identifier corresponding to the second type of power protocol, the communication message is marked as a second type of power protocol message. Then, according to the established format of the message, read the specific values ​​of the protocol type identifier field, service primitive type identifier field or application identifier field, and dataset member list field in the message respectively. Integrate and summarize all the extracted field values ​​as the second protocol semantic feature corresponding to the message.

[0034] In one possible implementation, step S300 further includes: Step S330: Traverse each edge in the host intra-process communication graph, determine the source process node and destination process node connected to the corresponding edge, and determine the listening port number corresponding to the edge.

[0035] Step S340: Write the protocol type identifier, message function type identifier, and associated device address from the first protocol semantic feature that matches the listening port number into the protocol semantic annotation field of that edge.

[0036] Step S350: Write the protocol type identifier, service primitive type identifier or application identifier and dataset member list from the second protocol semantic feature that matches the listening port number into the protocol semantic annotation field of the edge.

[0037] Step S360: Mark the host intra-process communication graph after the completion of writing the specification semantic annotation fields as an enhanced process communication graph.

[0038] Specifically, the process iterates through all the connection edges in the host's intra-process communication graph one by one. First, it locates the source process node and the destination process node that are connected at both ends of each edge. Then, it retrieves the communication attribute data that is pre-associated with the edge, queries and extracts the listening port number used for this communication behavior, and completes the confirmation of the node information and listening port number corresponding to each connection edge one by one.

[0039] Based on the listening port number corresponding to each connection edge, the first protocol semantic feature matching the port number is retrieved and filtered out. The protocol type identifier, message function type identifier, and associated device address are extracted from it. Then, all the extracted content is filled into the preset protocol semantic annotation field of the current connection edge to complete the semantic information binding of a single edge.

[0040] Based on the listening port number corresponding to the current connection edge, retrieve the matching second protocol semantic features, extract information such as protocol type identifier, service primitive type identifier or application identifier, and dataset member list, and append the extracted content to the existing protocol semantic annotation field of the edge to complete the association and entry of the second type of power protocol related semantic information of this edge.

[0041] After completing the input of the first and second types of power protocol information in the protocol semantic annotation fields of all connected edges in the host intra-process communication graph, a unified identification setting is set for the entire graph, and a unique mark is added to the graph to distinguish it. The graph with the supplemented protocol semantic attributes is officially defined and marked as an enhanced process communication graph.

[0042] In one possible implementation, step S400 further includes: Step S410: Traverse each edge in the enhanced process communication graph. If the protocol semantic feature associated with any edge is determined to be within the allowed communication range, and the source process node and the destination process node belong to the preset upstream and downstream business relationship within the same security zone, then retain the edge as a whitelist entry.

[0043] Step S420: For edges that are not determined to be within the allowed communication range, or edges where the source process node and the destination process node do not belong to the same security zone identifier, they are removed from the enhanced process communication graph.

[0044] Step S430: Map the reserved edges to host-level process-level micro-segmentation whitelist policy entries containing source process identifier, source port, destination IP, destination port, and allowed protocol type, and generate the host-level process-level micro-segmentation whitelist policy.

[0045] Specifically, all connection edges within the enhanced process communication graph are iterated one by one. For each connection edge, the protocol type identifier and message function type identifier stored in its protocol semantic annotation field are read first. These two types of identifier information are then matched and compared item by item with the list of allowed protocol types pre-configured and stored by the system. Only when the protocol type identifier and message function type identifier can be found in the list of allowed protocol types can it be determined that the protocol semantic features associated with the edge are within the compliant allowed communication range. On this basis, the source process node and destination process node at both ends of the edge are further verified to confirm that the two process nodes belong to the same security zone and that their operation logic and data interaction logic conform to the pre-defined upstream and downstream business correspondence within the security zone. Connection edges that meet both the conditions of protocol communication compliance, process affiliation, and business relationship compliance are all retained and compiled as valid entries in the process-level micro-segmentation whitelist.

[0046] Continue traversing the remaining connection edges in the enhanced process communication graph. First, determine whether the semantic feature of the protocol corresponding to a single edge does not belong to the allowed communication range, or check whether the security zone identifier carried by the source process node and the destination process node connected by the edge is inconsistent. As long as either judgment condition is met, perform the deletion operation and remove the illegal connection edge from the enhanced process communication graph.

[0047] Extract all valid connection edges that have been filtered and retained in the enhanced process communication graph. Read the source process identifier, source port, destination IP, destination port and compliant allowed protocol type from the node and attribute data associated with each edge. Combine the above information one by one according to the preset data format to form independent policy entries. After summarizing all entries, integrate them to generate a complete host-level process-level micro-segmentation whitelist policy.

[0048] This embodiment uses a 110kV substation power monitoring host as the application scenario. Link filtering is performed according to the principle of least privilege. The final mapped process-level micro-segmentation whitelist strategy and details of the illegal link determination are shown in Table 1. Table 1 Comparison of Process Communication Link Filtering and Whitelisting Strategies

[0049] In one possible implementation, step S500 further includes: Step S510: When identified as a first type of operating system, each policy entry in the host-internal process-level micro-segmentation whitelist policy is converted into a first filtering rule that matches the network filtering framework of the first type of operating system.

[0050] Step S520: Send the first filtering rule to the first type of operating system of the power monitoring host and enable it in forced interception mode.

[0051] Specifically, after identifying the operating system type of the power monitoring host, if the host operating system is determined to be of type 1, which is specifically an operating system based on the Windows kernel architecture and with built-in support for the Windows Filtering Platform (WFP) network filtering interface, covering mainstream systems such as Windows 7, Windows 10, and various versions of Windows Server, then type 2 is a system type distinct from type 1, specifically an operating system based on the Linux kernel architecture or POSIX-compliant. This type of operating system has built-in support for Netfilter / iptables or nftables packet filtering frameworks and carries mandatory access control interfaces such as SELinux (Linux Security Module), including various Linux distributions. Because the underlying kernel architecture, native network filtering framework, and security control interfaces of the two types of operating systems are completely different, targeted adaptation and conversion isolation strategies are required. Based on this, for the identified type 1 operating system, all policy entries in the pre-generated host-level process-level micro-isolation whitelist policy are iterated one by one, and the core permission configuration parameters such as source process identifier, source port, destination IP, destination port, and allowed protocol type contained in each entry are completely extracted, strictly adhering to the Windows Filtering Platform (WFP) implemented on the type 1 operating system. The Platform (WFP) network filtering framework specifies the rule syntax format, field matching rules, permission verification logic, and rule priority. It converts each standardized process-level whitelist policy entry into a first filtering rule that can be recognized, parsed, and executed independently by the Windows system kernel. This completes the conversion process for all policy entries, achieving precise adaptation between the process-level micro-segmentation whitelist policy and the native network filtering mechanism of the first type of operating system.

[0052] All the generated first filtering rules are batch-deployed to the first type of Windows operating system of the power monitoring host. The rules are registered and loaded by relying on the built-in Windows Filtering Platform (WFP) filtering framework. At the same time, the system network filtering policy is configured to force interception mode, and all process communication behaviors that do not match the whitelist filtering rules are rejected by default. Only process network communication and power protocol interaction traffic that fully match the first filtering rules are allowed. This makes the converted first filtering rules fully and forcibly effective, realizing process-level micro-isolation security management of the power monitoring host in the Windows system environment.

[0053] In one possible implementation, step S500 further includes: Step S530: When identified as a second type of operating system, each policy entry in the host-internal process-level micro-segmentation whitelist policy is converted into a second filtering rule that matches the network filtering framework of the second type of operating system.

[0054] Step S540: Send the second filtering rule to the second type of operating system of the power monitoring host and enable it in forced interception mode.

[0055] Specifically, the operating system type of the power monitoring host is identified and determined. If the identification result is a second type of operating system based on the Linux kernel architecture, compatible with the POSIX standard, equipped with Netfilter / iptables or nftables packet filtering framework, and supporting mandatory access control interfaces of Linux Security Modules such as SELinux, then all policy entries of the generated host-level process-level micro-segmentation whitelist policy are traversed one by one. The core parameters corresponding to each entry, such as source process identifier, source port, destination IP, destination port, and allowed protocol type, are completely extracted. Strictly following the syntax specifications, field matching logic, protocol identification rules, and process permission constraint mechanism of the native network filtering framework of the second type of operating system, each process-level whitelist policy entry is accurately converted into a second filtering rule that can be parsed, loaded, and executed by the Linux kernel. This completes the standardized adaptation and conversion of all policy entries, adapting to the network traffic control and process communication isolation mechanism under the Linux system environment.

[0056] All converted second filtering rules are batch-deployed to the second type of operating system of the power monitoring host. The rules are loaded and registered by relying on the built-in Netfilter / iptables or nftables packet filtering framework and SELinux mandatory access control interface. At the same time, the system network management mode is set to mandatory interception mode, which blocks all process communication traffic that does not match the second filtering rules by default, and only allows communication behavior that conforms to the whitelist policy, so that the second filtering rules are fully effective and realize host process-level security isolation and management under Linux-like systems.

[0057] In one possible implementation, step S500 further includes: Step S550: Before issuing the host-level process-level micro-segmentation whitelist policy, first run the host-level process-level micro-segmentation whitelist policy in audit mode on the power monitoring host or a reference host of the same model, record the blocked connection attempts, and generate a blocking log.

[0058] Step S560: Traverse the blocking log, read the protocol semantic features in each blocked connection record, compare them with the preset list of allowed protocol types, and if at least one blocked connection record has protocol semantic features in the list of allowed protocol types, it is determined that there is a case of false blocking of power service communication within the allowed communication range, an alarm is issued and the host in-process micro-isolation whitelist policy is rolled back and adjusted.

[0059] Specifically, before officially issuing the in-host process-level micro-segmentation whitelist policy, the policy is deployed to the power monitoring host or a reference host of the same model and switched to audit mode. In this mode, only illegal connections are identified, and no actual blocking operations are performed. The system captures all process connection behaviors that trigger the blocking conditions in real time, extracts complete information such as the corresponding source process identifier, port, destination IP, destination port, protocol semantics, and access time for each connection, organizes them in a unified manner according to the preset log format, writes them to the log file one by one, and finally summarizes them to form a complete blocking log.

[0060] The system sequentially iterates through all connection records in the blocking log, accurately extracting stored protocol type identifiers, message function type identifiers, and other protocol semantic features from each record. The extracted content is then matched against a pre-entered and stored list of allowed protocol types. If any record's protocol semantic features match an item in the list of allowed protocol types, the system is deemed to have encountered an anomaly of compliant power business communication being mistakenly blocked. Immediately, audible and visual alarms, pop-ups, or background log alerts are activated. Simultaneously, a policy rollback operation is performed, canceling any pending whitelist policies. Furthermore, the policy entries are reviewed, modified, and optimized based on the specific information regarding the mistaken blocking.

[0061] In one possible implementation, step S560 further includes: If, after traversing the blocking logs, no protocol semantic features of any blocked connection record are found in the list of allowed protocol types, it is determined that no business communication within the allowed communication scope has been blocked, and the host-level process-level micro-segmentation whitelist policy is switched to forced interception mode and officially takes effect.

[0062] Specifically, the complete blocking log is traversed one by one, extracting the protocol semantic features corresponding to each blocked connection record, and continuously comparing them with the system's pre-set list of allowed protocol types. When all records have been verified and none match any of the list entries, it is determined that there is no situation where compliant power business communication has been mistakenly blocked. Subsequently, the audit mode is turned off, the in-host process-level micro-segmentation whitelist policy is switched to forced blocking mode, all filtering rules are loaded and enabled, and the policy is officially implemented to carry out normalized process-level isolation and control of host communication.

[0063] It should be noted that the order of the embodiments described above is for descriptive purposes only and does not represent the superiority or inferiority of the embodiments. Specific embodiments of this specification have been described above. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0064] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0065] This specification and accompanying drawings are merely illustrative examples of this application and are intended to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from its scope. Therefore, if such modifications and variations fall within the scope of this application and its equivalents, this application intends to include such modifications and variations.

Claims

1. A method for hardening a power monitoring host for multi-source operating systems, characterized in that, The method includes: Collect inter-process communication and network communication behaviors of each process on the power monitoring host, and construct a set of process communication observation records; Based on the aforementioned set of process communication observation records, an intra-host process communication graph is constructed with processes as nodes and allowed communication relationships as edges. Deeply analyze the communication packets flowing through each monitoring port within the host, identify the protocol semantic features in the power protocol packets, and associate the protocol semantic features with the attributes of the corresponding edges in the process communication graph within the host to form an enhanced process communication graph. Based on the enhanced process communication graph, the range of communication peers and ports that each process is allowed to initiate and receive is derived according to the principle of minimizing privileges, and a host-level process-level micro-isolation whitelist strategy is generated. The operating system type of the power monitoring host is identified. When it is identified as a first type of operating system, the process-level micro-segmentation whitelist policy within the host is converted into a first filtering rule corresponding to the first type of operating system and takes effect. When it is identified as a second type of operating system, the process-level micro-segmentation whitelist policy within the host is converted into a second filtering rule corresponding to the second type of operating system and takes effect.

2. The method for hardening a power monitoring host for multi-source operating systems as described in claim 1, characterized in that, Constructing the intra-host process communication graph, including: Using each process in the process communication observation record set as a node, and the inter-process communication relationships and network communication relationships recorded in the process communication observation record set as edges, an initial process communication graph is constructed. The initial process communication graph is subjected to noise filtering, temporary process nodes with a lifespan shorter than a preset lifespan are removed, and occasional connection edges with fewer than a preset number of communications are removed to obtain a standard process communication graph. Multiple instance process nodes with the same executable file path and the same command-line parameters in the standard process communication graph are merged into a single logical business process node to obtain the host intra-process communication graph.

3. The method for hardening a power monitoring host for multi-source operating systems as described in claim 2, characterized in that, After constructing the intra-host process communication graph, it also includes: The process identifier, listening port, destination IP, destination port, and transport layer protocol information of each node in the host intra-process communication graph are labeled to form a structured host intra-process communication graph.

4. The method for hardening a power monitoring host for multi-source operating systems as described in claim 1, characterized in that, Deep analysis of communication packets flowing through each listening port within the host is performed, including: The communication packets flowing through each listening port in the host are subjected to deep analysis. The data frame header of each communication packet is checked one by one. When the start identifier of the first type of power protocol is detected in the data frame header, the corresponding communication packet is marked as a packet that conforms to the first type of power protocol. The values ​​of the protocol type identifier field, the packet function type identifier field and the associated device address field are read from the packet in sequence as the semantic features of the first protocol. When the start identifier of the second type of power protocol is detected in the header of the data frame, the corresponding communication message is marked as a message that conforms to the second type of power protocol, and the values ​​of the protocol type identifier field, service primitive type identifier field or application identifier field and dataset member list field are read from the message in sequence as the semantic features of the second protocol.

5. The method for hardening a power monitoring host for multi-source operating systems as described in claim 4, characterized in that, Associating the semantic features of the specification with the attributes of the corresponding edges in the intra-host process communication graph includes: Traverse each edge in the host intra-process communication graph, determine the source process node and destination process node connected to the corresponding edge, and determine the listening port number corresponding to the edge; Write the protocol type identifier, message function type identifier, and associated device address from the first protocol semantic feature that matches the listening port number into the protocol semantic annotation field of this edge; Write the protocol type identifier, service primitive type identifier or application identifier and dataset member list from the second protocol semantic feature that matches the listening port number into the protocol semantic annotation field of this edge; The host intra-process communication graph after the completion of writing the specification semantic annotation fields is marked as an enhanced process communication graph.

6. The method for hardening a power monitoring host for multi-source operating systems as described in claim 1, characterized in that, Based on the principle of minimizing privileges, the range of communication peers and ports that each process is allowed to initiate and receive communication from includes: Traverse each edge in the enhanced process communication graph. If the semantic feature of any edge is determined to be within the allowed communication range, and the source process node and the destination process node belong to the same security zone and are in a preset upstream and downstream business relationship, then retain that edge as a whitelist entry. Edges that are not determined to be within the allowed communication range, or edges where the source process node and the destination process node do not belong to the same security zone identifier, are removed from the enhanced process communication graph. Each reserved edge is mapped to an in-host process-level micro-segmentation whitelist policy entry containing the source process identifier, source port, destination IP, destination port, and allowed protocol type, thereby generating the in-host process-level micro-segmentation whitelist policy.

7. The method for hardening a power monitoring host for multi-source operating systems as described in claim 1, characterized in that, When identified as a first-type operating system, the host-level process-level micro-segmentation whitelist policy is converted into a first filtering rule corresponding to the first-type operating system and takes effect, including: When identified as a first type of operating system, each policy entry in the host-in-process-level micro-segmentation whitelist policy is converted into a first filtering rule that matches the network filtering framework of the first type of operating system. The first filtering rule is sent to the first type of operating system of the power monitoring host and takes effect in forced interception mode.

8. The method for hardening a power monitoring host for multi-source operating systems as described in claim 1, characterized in that, When identified as a second type of operating system, the host-level process-level micro-segmentation whitelist policy is converted into a second filtering rule corresponding to the second type of operating system and takes effect, including: When identified as a second type of operating system, each policy entry in the host-in-process-level micro-segmentation whitelist policy is converted into a second filtering rule that matches the network filtering framework of the second type of operating system. The second filtering rule is sent to the second type of operating system of the power monitoring host and takes effect in forced interception mode.

9. The method for hardening a power monitoring host for multi-source operating systems as described in claim 1, characterized in that, The method also includes a strategy verification step: Before issuing the host-in-host process-level micro-segmentation whitelist policy, the host-in-host process-level micro-segmentation whitelist policy is first run in audit mode on the power monitoring host or a reference host of the same model to record the blocked connection attempts and generate a blocking log. Traverse the blocking logs, read the protocol semantic features in each blocked connection record, and compare them with the preset list of allowed protocol types. If at least one blocked connection record has protocol semantic features in the list of allowed protocol types, it is determined that there is a case of false blocking of power business communication within the allowed communication range, an alarm is issued, and the host-level process-level micro-segmentation whitelist policy is rolled back and adjusted.

10. The method for hardening a power monitoring host for multi-source operating systems as described in claim 9, characterized in that, If, after traversing the blocking logs, no protocol semantic features of any blocked connection record are found in the list of allowed protocol types, it is determined that no business communication within the allowed communication scope has been blocked, and the host-level process-level micro-segmentation whitelist policy is switched to forced interception mode and officially takes effect.

Images