A method, system, medium, and product for tracing device abnormal behavior

Abstract

A device abnormal behavior tracing method, system, medium and product relate to the field of Internet of Things security. The method receives network data by monitoring the resident service process, dynamically updates the version identifier and generates the process shard node, so as to realize the logical isolation of the process state and establish the predecessor context association. At the same time, the cross-shard data dependency edge is generated based on the resource version mapping table. When the abnormal alarm is received, the priority reverse search is performed from the target process shard node by using the shard association and the cross-shard data dependency edge. The present application solves the problems of "state pollution" and "dependency explosion" caused by the existing full life cycle trace graph construction by cutting the long-running process into discrete logical units according to the business boundary, eliminates the interference of irrelevant historical business, and improves the accuracy of device abnormal behavior tracing.

Description

A method, system, medium, and product for tracing the source of abnormal equipment behavior. Technical Field

[0001] This application relates to the field of Internet of Things (IoT) security, and in particular to a method, system, medium, and product for tracing abnormal device behavior. Background Technology

[0002] With the acceleration of the Internet of Things and digital transformation, device security risks are becoming increasingly complex. Traditional methods for tracing abnormal behavior mainly rely on traffic data packets captured by firewalls or intrusion detection systems, using the five-tuple information to locate the source IP. However, this method only stays at the network communication level outside the device, leaving malicious operations performed by the device's internal execution logic through encrypted channels or using legitimate system tools (Living off the Land) in a "black box" state. Simple traffic analysis cannot reconstruct which process or file operation within the device triggered the anomaly, resulting in a lack of specific causal evidence in the tracing results, making it difficult to guide vulnerability remediation.

[0003] To address the issue of missing internal causal relationships caused by network layer analysis, the relevant technology employs a system-wide provenance graph approach. This method uses kernel probes to collect system call events in real time, constructing a directed graph with causal dependencies from scattered processes, files, and sockets. When an anomaly (such as an illegal external connection) is detected, the system traces back from the anomaly node, accurately reconstructing the parent process that initiated the connection and its associated file operations. This successfully links the abnormal behavior to the specific operation path within the system, achieving fine-grained causal tracing.

[0004] However, this source graph-based technology suffers from "state pollution" and "dependency explosion" problems when dealing with long-running service processes (such as web servers and databases). Because this technology typically abstracts the entire lifecycle of a process as a single node in a graph, the massive amounts of irrelevant historical requests processed by long-running processes converge on that node. When the process eventually produces abnormal output, graph-based reachability analysis may misjudge all historical inputs as potential causes, resulting in the source path containing a large number of legitimate operations unrelated to the attack, reducing the accuracy and timeliness of tracing abnormal device behavior. Summary of the Invention

[0005] This application provides a method, system, medium, and product for tracing the source of abnormal equipment behavior, which can improve the accuracy of tracing the source of abnormal equipment behavior.

[0006] Firstly, this application provides a method for tracing the source of abnormal device behavior, applied to a server of a device monitoring system, comprising: acquiring a set of system call events arranged in chronological order, wherein the system call event set includes at least a process identifier, an operation action type, and a resource identifier; identifying resident service processes in the system call event set based on the process identifier, and configuring a process state version identifier for the resident service processes; in response to detecting that a resident service process has received network data, updating the process state version identifier and generating a new process shard node, and establishing a predecessor context association between the new process shard node and the previous process shard node; mapping events in the system call event set to the corresponding process shard nodes based on the process state version identifier at the time of the event, and identifying that the current system call event is a read operation on resources written to historical shard nodes based on the operation action type and resource identifier, generating cross-shard data dependency edges; when receiving an abnormal behavior alarm message for a target device, locating the target process shard node corresponding to the abnormal alarm message based on the target process identifier in the abnormal alarm message; and performing a reverse search based on the cross-shard data dependency edge and the predecessor context association, starting from the target process shard node, to generate an abnormal behavior tracing result.

[0007] By adopting the above technical solution, the server first identifies resident service processes using process identifiers and configures process state version identifiers, establishing the foundation for fine-grained management of the continuous process lifecycle. Secondly, the server responds to network data reception events to drive state updates, dividing the long-running process stream into discrete process shard nodes according to business boundaries, and maintaining logical environment consistency between shards through predecessor context association. Next, the server maps system call event sets to specific shards based on version identifiers, identifies read operations on historical shard write resources, constructs cross-shard data dependency edges, and preserves data causality across time while isolating different business request states. Finally, the server performs a reverse search based on the target process shard node, directly locking and tracing back to the specific shard related to the anomaly, cutting off interference from historical normal business operations unrelated to the current attack. In summary, this solution solves the problem of redundant tracing paths caused by "state pollution" of resident service processes, improving the accuracy of tracing abnormal device behavior.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, in response to detecting that a resident service process has received network data, updating the process state version identifier and generating a new process shard node specifically includes: obtaining the timestamp of the current network data reception event and the historical timestamp of the last network data reception event of the resident service process; calculating the time difference between the occurrence timestamp and the historical timestamp; if the time difference is greater than a preset time threshold, updating the process state version identifier and generating a new process shard node; if the time difference is less than or equal to the preset time threshold, keeping the process state version identifier unchanged and mapping the current network data reception event to the current process shard node.

[0009] By adopting the above technical solution, the server first obtains the timestamps of the current and previous network data reception events and calculates the time difference between them, quantifying the business processing frequency of the resident service process from a time perspective. Secondly, the server introduces a preset time threshold as a judgment logic. When the time difference is greater than the preset time threshold, the server determines that a new business request has arrived and generates a new process shard node for isolation. When the time difference is less than or equal to the preset time threshold, the server treats it as a continuation of the same business context and maintains the current version identifier unchanged. Finally, through this dynamic sharding strategy based on time density, the server avoids a surge in the number of traceability graph nodes due to excessively fine sharding while ensuring the integrity of business logic. In summary, this solution achieves a balance between reducing server computing resource consumption and controlling the size of the traceability graph, improving the system's efficiency when processing high-throughput data.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, before the step of calculating the time difference between the occurrence timestamp and the historical timestamp, the method further includes: parsing the network 5-tuple information or socket handle in the current network data reception event to generate a communication session identifier for the current event.

[0011] By adopting the above technical solution, before performing time-based judgments, the server proactively parses the network 5-tuple or socket handle, transforming the underlying network communication parameters into a logically unique communication session identifier, thus obtaining a second key judgment dimension besides the time dimension. Secondly, the server generates this communication session identifier, providing data support for subsequent processing and enabling the system to distinguish between concurrent connections or interleaved requests from different sources. In summary, the server provides the necessary contextual basis for subsequent, more refined sharding decisions, ensuring that subsequent steps are not only based on time series but also on the independence of network sessions for logical partitioning, laying a data foundation for tracing the source of abnormal device behavior in complex network environments.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, if the time difference is less than or equal to a preset time threshold, the process state version identifier is kept unchanged, and the current network data reception event is mapped to the current process shard node. Specifically, this includes: determining whether the communication session identifier of the current network data reception event is consistent with the communication session identifier associated with the current process shard node; if the time difference is less than or equal to the preset time threshold and the communication session identifiers are consistent, then the step of keeping the process state version identifier unchanged is executed; if the time difference is less than or equal to the preset time threshold, but the communication session identifiers are inconsistent, then the step of updating the process state version identifier and generating a new process shard node is executed.

[0013] By adopting the above technical solution, when the time difference is less than or equal to a preset time threshold, the server further determines the consistency of the communication session identifier. If the identifiers are consistent, the server confirms that the current event is an interaction of the same connection and maintains the current shard to ensure the integrity of the operation chain; if the identifiers are inconsistent, the server forcibly updates the process state version identifier and generates a new process shard node, enabling the server to distinguish between time-adjacent but logically independent requests in high-concurrency scenarios. In summary, this solution prevents state confusion between different network sessions within the same shard, ensures the purity of causal relationships in the tracing results, and reduces the risk of false associations caused by concurrent requests.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, the device monitoring system further includes a resource version mapping table. The resource version mapping table records the correspondence between resource identifiers and the version of the process shard node that last performed a write operation on the resource. Based on the process state version identifier at the time of the event, events in the system call event set are mapped to the corresponding process shard nodes. Based on the operation action type and resource identifier, it is identified that the current system call event is a read operation on resources written to historical shard nodes, generating cross-shard data dependency edges. Specifically, this includes: when the operation action type of the system call event is a write type, updating the resource identifier of the current event and the current process shard node in the resource version mapping table; when the operation action type of the system call event is a read type, querying the resource version mapping table based on the resource identifier of the current event; if a corresponding historical shard node is found, establishing a cross-shard data dependency edge from the historical shard node to the current process shard node.

[0015] By adopting the above technical solution, the server dynamically records the process shard node information corresponding to the last write to each resource using a resource version mapping table, thereby establishing a resource status index library spanning the time dimension. When a subsequent read operation occurs, the server no longer vaguely associates it with the process entity, but precisely locates the specific "historical shard node" that generated the data by querying the resource version mapping table. Ultimately, the server generates cross-shard data dependency edges based on this precise read-write matching relationship, building a clear data bridge between logically segmented process shards. In summary, this solution successfully reconstructs the data flow path between different business requests or time periods, enabling the source graph to accurately reconstruct complex attack chains where attackers use files or memory as springboards while maintaining node isolation, thus improving the accuracy of tracing the source of abnormal device behavior.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, before updating the resource identifier of the current event and the current process shard node to the resource version mapping table, the method further includes: obtaining the resource attribute type corresponding to the resource identifier in the current system call event, wherein the resource attribute type includes at least dynamic data type and static shared type; if the resource attribute type is dynamic data type, then the operation of updating the resource identifier of the current event and the current process shard node to the resource version mapping table is performed, allowing subsequent establishment of cross-shard data dependency edges for the resource; if the resource attribute type is static shared type, then the update operation of the resource version mapping table is performed, but cross-shard data dependency edges generated based on static shared resources are blocked.

[0017] By adopting the above technical solution, the server identifies resource attribute types, distinguishing between dynamic data types that carry business functions and static shared types that only provide the environment. If the current system call event is a dynamic data type, the server performs an update operation to preserve key traces; if the current system call event is a static shared type, the server does not perform an update operation on the resource version mapping table, thereby blocking cross-shard data dependency edges generated based on that resource. In summary, this solution prevents the phenomenon of "super nodes" connecting all nodes in the tracing graph caused by high-frequency access to public resources, reduces invalid dependency paths, purifies the tracing graph structure, and focuses the tracing results generated by the server on abnormal data flows with substantial causality.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, starting from the target process shard node, a reverse search is performed based on cross-shard data dependency edges and predecessor context associations to generate abnormal behavior tracing results. Specifically, this includes: taking the target process shard node as the current search node and initializing the tracing path; when performing a reverse search based on cross-shard data dependency edges, marking the searched historical shard nodes as first priority nodes; when performing a reverse search based on predecessor context associations, calculating the context decay coefficient based on the time interval between the current search node and the predecessor shard node; if the context decay coefficient meets a preset association threshold, marking the predecessor shard node as a second priority node and assigning it a second priority association weight; the first priority is higher than the second priority, and the weight of the first priority is higher than the weight of the second priority; adding the searched nodes to the tracing path in descending order of priority until the tracing search is completed and the abnormal behavior tracing results are obtained.

[0019] By adopting the above technical solution, the server first initializes the tracing path. Next, the server marks nodes based on cross-shard data dependency edges as first-priority nodes, locking in clear data causality. For nodes based on predecessor context association, the server calculates a context decay coefficient based on time intervals. Then, only when the context decay coefficient meets a preset correlation threshold is the server marked as a second-priority node. Finally, the server generates a clear and logically sound abnormal behavior tracing path through weight allocation and priority sorting. In summary, this solution constructs the tracing path according to priority order, automatically filtering out long-standing and weakly correlated background noise, improving the readability and efficiency of abnormal behavior tracing results.

[0020] Secondly, this application provides a server for a device monitoring system. The server includes one or more processors and a memory. The memory is coupled to one or more processors and is used to store computer program code, which includes computer instructions. One or more processors invoke the computer instructions to cause the server to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, this application provides a computer-readable storage medium including instructions that, when executed on a server, cause the server to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, this application provides a computer program product that, when run on a server, causes the server to perform the method described in the first aspect and any possible implementation thereof.

[0023] Understandably, the server of the equipment monitoring system provided in the second aspect, the computer program product provided in the third aspect, and the computer storage medium provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0025] 1. By adopting a technical solution that updates the process state version identifier based on network data reception events and generates new process shard nodes, and performs reverse search based on cross-shard data dependency edges and predecessor context associations, long-running resident service processes can be divided into discrete logical units according to business request boundaries, and only relevant data and context relationships are constructed. This effectively solves the problems of "state pollution" and "dependency explosion" caused by the construction of the full lifecycle graph in related technologies, and thus achieves the generation of highly accurate abnormal behavior tracing results that exclude interference from irrelevant historical business.

[0026] 2. By employing a technical solution that calculates the time difference between the occurrence timestamp and the historical timestamp, and only updates the process status version identifier when the difference exceeds a preset time threshold, the sharding strategy can be dynamically adjusted according to the density of business activities. This aggregates continuous network interactions within a short period of time to the same node, effectively solving the problem of a surge in the number of graph nodes or the fragmentation of business logic caused by sharding based solely on event counting or fixed time windows in related technologies. This achieves a balance between granular control of process sharding nodes and system resource consumption, thereby improving the efficiency of tracing graph construction.

[0027] 3. By employing a technical solution that uses a resource version mapping table to record the correspondence between resource identifiers and process shard nodes during write operations, and establishes cross-shard data dependency edges during reading, it can accurately pinpoint which specific historical shard node generated the currently used resource across the time dimension. This effectively solves the problem of broken causal chains or ambiguous data flow that easily occurs after process state segmentation in related technologies, thereby achieving a complete reconstruction of complex cross-stage attack paths that use files or memory as springboards. Attached Figure Description

[0028] Figure 1 is a flowchart illustrating a method for tracing the source of abnormal device behavior in an embodiment of this application;

[0029] Figure 2 is another flowchart illustrating a method for tracing abnormal device behavior in an embodiment of this application;

[0030] Figure 3 is a schematic diagram of the physical device structure of a server of the equipment monitoring system in an embodiment of this application. Detailed Implementation

[0031] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0032] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0033] To facilitate understanding, the application scenarios of the embodiments of this application are described below.

[0034] In related technologies, process behavior monitoring and backtracking can be achieved by constructing a system source graph based on the entire lifecycle. The following scenario describes a method for tracing abnormal device behavior using this technology: In a long-running web server (i.e., a resident service process), all behavior of the process since its startup is attributed to the same graph node. After the server has been running for several months, it accumulates a massive amount of normal business access records and file read / write operations. If an attacker exploits a vulnerability to compromise the process, security personnel attempting to trace the abnormal behavior will find that the process node is connected to tens of thousands of historical edges. Because it's impossible to distinguish which operations belong to the current attack request and which belong to normal business operations from the past few months, the source graph contains a large amount of irrelevant "noise." This phenomenon is called "dependency explosion" and "state pollution," making it extremely difficult to locate the attack entry point.

[0035] The solution in this application, by dividing continuously running resident processes into discrete process shard nodes according to business interaction boundaries, achieves logical isolation of business context, preserving not only the key data flow across time dimensions. The following describes a scenario using a device abnormal behavior tracing method from this application: When the aforementioned web server receives a new network request, the solution identifies the network data reception event and immediately generates a new "shard node" (e.g., version V100) for the process. Subsequently, all system calls triggered by this request are associated only with the V100 node. If an attack occurs during this request, the system only needs to reverse-search the V100 node and its specific historical shards precisely associated through the "resource version mapping table" (e.g., reading the configuration file written by version V50) during tracing, completely shielding other normal business shards from V1 to V99 that are unrelated to this attack, thus generating a clear and precise attack chain.

[0036] As can be seen, by adopting the process state sharding and cross-shard dependency construction technology in the embodiments of this application, while achieving accurate attack path restoration, it can also effectively solve the problems of "state pollution" and "dependency explosion" in the tracing graph caused by the long-term operation of resident service processes, thereby achieving efficient and low-noise tracing of abnormal device behavior.

[0037] To facilitate understanding, the method provided in this embodiment will be described in detail below, taking into account the above scenario. Please refer to Figure 1, which is a flowchart illustrating a method for tracing the source of abnormal device behavior in an embodiment of this application.

[0038] S101. Obtain a system call event set arranged in chronological order. The system call event set shall include at least the process identifier, operation action type and resource identifier.

[0039] The system call event set arranged in chronological order represents a collection of system call records collected by the server from the operating system kernel level of the target device, ordered chronologically according to the event timestamps. Each system call event records a complete operation of the interaction between the process and the operating system kernel. The process identifier is a digital tag used to uniquely identify a running process in the operating system, usually including process ID (PID) and thread ID (TID), which can accurately locate the specific process that performed the operation in the system call event. The operation action type indicates the specific operation category performed by the system call event, such as file read / write operations, network communication operations (send / recv / accept / connect), process management operations (fork / exec / exit), etc., which are used to describe the process's access to system resources. The resource identifier is used to represent the specific system resource object involved in the system call event, including file path, file descriptor, network socket information, memory address, etc., which can accurately locate the target resource of the process operation.

[0040] Specifically, after deploying the monitoring agent on the target device, the server needs to continuously acquire the system call event stream generated during device operation to provide a complete data foundation for subsequent abnormal behavior tracing and analysis. The server deploys data acquisition probes at the operating system kernel layer of the target device to capture system call events generated by all processes in real time. These discrete events are then strictly ordered according to their timestamps to form a continuous event stream. Each system call event extracts key identification information during acquisition, including the process identifier executing the call, the specific operation type, and the resource identifiers involved, ensuring that subsequent analysis can accurately reconstruct the process's behavioral trajectory. The server stores the collected system call event set in a time-series database, maintaining the temporal order of events and providing an accurate time reference for constructing causal relationship graphs and abnormal source tracing.

[0041] S102. Identify the resident service processes in the system call event set based on the process identifier, and configure the process status version identifier for the resident service processes.

[0042] Among them, resident service processes refer to system processes that run continuously on the target device for a long time and are usually used to provide specific service functions, such as web server processes (nginx, apache), database service processes (mysql, postgresql), SSH service processes (sshd), etc. These processes are characterized by long running time, frequent request processing, and lifecycles spanning multiple user sessions. The process state version identifier is used to represent the logical state number of the resident service process at different time stages. By assigning an incrementing version number to the same physical process, its state when handling different requests or tasks is distinguished, such as version V0, V1, V2, etc. Each version corresponds to the time period during which the process handles specific business logic.

[0043] Specifically, after obtaining the system call event set, the server needs to identify long-running resident service processes that are prone to "dependency explosion" from among numerous processes, and establish a versioned state management mechanism for them. The server analyzes the process identification information in the system call event set, combining it with characteristics such as process runtime, network listening status, and system call frequency, to identify target processes that match the characteristics of resident service processes. Once a resident service process is identified, the server immediately initializes a process state version identifier for that process, typically starting from version V0. This version identifier will serve as the basis for subsequent process sharding and state tracking.

[0044] S103. In response to detecting that the resident service process has received network data, update the process status version identifier and generate a new process shard node, and establish a predecessor context association between the new process shard node and the process shard node before the update.

[0045] Among them, network data represents data packets or network connection requests received by resident service processes through network interfaces, usually manifested through system calls such as accept, recv, and recvfrom. This network data often represents the start of new client requests or business processing. Process shard nodes refer to logical nodes in the source graph used to represent the same physical process in a specific time period or specific business processing stage. By logically dividing long-running processes according to business boundaries, each shard node corresponds to an independent context for the process to handle specific requests or tasks. Predecessor context association is used to represent the state inheritance relationship between a newly generated process shard node and its previous version. This association maintains the continuity of context information such as process memory state, environment variables, and open file descriptors.

[0046] Specifically, the server monitors the network activity of identified resident service processes in real time. When a resident service process is detected performing a network data reception operation, it immediately triggers the process state version update and the creation of a new shard node. By analyzing the system call event stream, the server identifies network reception system calls executed by the resident service process, such as `accept` (accepting new connections), `recv` (receiving data), and `recvfrom` (receiving data packets). These calls typically indicate that the service process has begun processing new client requests or receiving new business data. Once such a network reception event is detected, the server immediately increments the current process state version identifier of the resident service process (e.g., from V0 to V1) and simultaneously creates a corresponding new process shard node in the tracing graph. This node will carry all subsequent system call events related to this network request. To maintain the continuity of the process state, the server establishes a predecessor context association edge between the old and new process shard nodes. This association edge marks the inheritance relationship of the process's internal state, ensuring that the evolution of the process state can be correctly understood during tracing analysis.

[0047] Optionally, in some embodiments, for resident service processes employing multi-threading or I / O multiplexing models (such as the Reactor pattern), the server's generation of new process shard nodes may also include fine-grained binding logic based on thread identifiers (TIDs). Specifically, when the server detects that the main thread or listening thread of the resident service process has received a network connection request and distributed it to worker threads, the system not only updates the process-level state version but also captures thread switching or thread-specific system calls. In this case, the generated "process shard node" is actually a tuple of "process version - thread ID".

[0048] For example, when a network data reception event is detected, the system records the thread ID (TID_A) currently executing the operation. If subsequent file read or write operations occur under the same TID_A, these operations are mapped to the current shard node bound to TID_A. If a worker thread TID_B is detected starting to process a task, an independent shard child node is generated for TID_B, inheriting the current version of the main process's environment context.

[0049] In high-concurrency scenarios, it can accurately distinguish between different network requests processed in parallel, avoiding the misattribution of abnormal behavior caused by malicious requests processed by thread A to normal business data processed by thread B, thereby further reducing the false alarm rate of the tracing results.

[0050] S104. Based on the process state version identifier at the time of the event, the events in the system call event set are mapped to the corresponding process shard nodes, and the current system call event is identified as a read operation of the resource written to the historical shard node according to the operation action type and resource identifier, and cross-shard data dependency edges are generated.

[0051] Among them, historical shard nodes represent process shard nodes that are earlier than the current event in time sequence. These nodes carry various operations and resource modifications performed by the resident service process in previous versions. Read operations refer to the operation behavior of the process to obtain data content from the file system, shared memory or other storage media through system calls such as read, pread, mmap, etc. Cross-shard data dependency edges are used to represent the directed dependency relationship formed between different process shard nodes due to data read and write relationships. This edge connects the resource writing node (data producer) and the reading node (data consumer), reflecting the data flow and causal relationship.

[0052] Specifically, after creating process shard nodes, the server needs to correctly allocate continuously generated system call events to the corresponding process shard nodes and identify data dependencies across different shard versions to construct a complete causal graph structure. The server first queries the current process state version identifier of the process at the time of each system call event based on the timestamp and process identifier. Then, it maps and associates the event with the corresponding version of the process shard node to ensure accurate event attribution. During event mapping, the server focuses on read-type operations. By analyzing resource identifiers in the event (such as file paths, inode numbers, shared memory identifiers, etc.), it queries the global resource write history table maintained by the server. This table records the most recent write operation for each resource and its corresponding process shard node information. When the server finds that the current system call event is a read operation on a resource, and the last write operation of that resource came from a different historical shard node, it immediately creates a directed edge in the causal graph from the historical write shard node to the current read shard node. The edge type is marked as data dependency, thus establishing a causal chain across shards.

[0053] S105. When receiving an alarm message about abnormal behavior of a target device, locate the target process shard node corresponding to the abnormal alarm message based on the target process identifier in the abnormal alarm message.

[0054] Among them, the abnormal behavior alarm information refers to the alarm message sent to the server by the external security detection system or the internal anomaly monitoring module. This message contains detailed information about the detected suspicious or malicious behavior. The target process identifier is the unique identifier of the specific process that caused the abnormal behavior, as specified in the abnormal behavior alarm information. It usually includes information such as process ID, process name, and timestamp of the anomaly, and is used to accurately locate the starting point of the abnormal behavior in the source tracing diagram. The target process fragment node is used to represent the specific process fragment node corresponding to the abnormal behavior alarm information in the source tracing diagram. This node carries the state of the process and related operation records when the abnormal behavior occurred.

[0055] Specifically, when abnormal behavior occurs, the server needs to quickly respond to alarm information and accurately locate the corresponding node in the source graph, providing a precise starting point for subsequent reverse tracing analysis. When the server receives abnormal behavior alarm information from intrusion detection systems, firewalls, endpoint detection and response systems, or other security monitoring components, it immediately parses the key information in the alarm message, including the type of abnormal behavior, the time of occurrence, the process information involved, and a detailed description of the abnormal operation. Based on the target process identifier provided in the alarm information and the precise timestamp of the abnormal behavior, the server performs a precise matching operation in the process shard node set of the source graph. Since the same physical process may correspond to multiple different versions of process shard nodes, the server needs to determine the specific state version of the process at the time of the abnormal behavior to locate the accurate target process shard node carrying the abnormal operation. By querying the process state version management table and comparing the abnormal timestamp with the creation time and lifecycle range of each process shard node, the server finally locks down the target process shard node corresponding to the abnormal behavior alarm information.

[0056] S106. Starting from the target process shard node, perform a reverse search based on cross-shard data dependency edges and predecessor context associations to generate abnormal behavior tracing results.

[0057] In this context, reverse search refers to the analysis process in which the server starts from the target process shard node corresponding to the abnormal behavior and traverses the directed edges in the source graph in reverse. By tracing the source of data flow and control flow, the root cause of the abnormal behavior can be identified. The abnormal behavior source tracing result represents the analysis report generated by the server through the reverse search algorithm. This report contains the complete causal path leading to the abnormal behavior, the processes and resources involved, the key operation sequences, and possible attack vectors, providing security analysts with detailed event reconstruction information.

[0058] Specifically, after locating the target process shard node, the server needs to perform in-depth reverse tracing analysis to reconstruct the complete attack chain of the abnormal behavior, revealing the root cause and propagation path of the abnormal behavior. The server initializes the reverse search algorithm, using the target process shard node as the starting point, setting a search queue and configuring search depth limits and time window constraints to avoid excessive search scope expansion. During the reverse search, the server prioritizes traversing cross-shard data dependency edges. These edges represent clear data causal relationships and can reveal the key data sources upon which the abnormal behavior depends, such as malicious files, configuration tampering, and privilege abuse. The server also considers predecessor context-related edges, but sets a lower tracing priority and condition constraints for these edges to avoid including too many historically irrelevant operations in the tracing results. During the traversal, the server records information about each visited node, the type and weight of the edges, and the path relationships between nodes, constructing a causal dependency subgraph of the abnormal behavior. The server also analyzes key operation patterns in the path, identifies common attack techniques such as file injection, privilege escalation, and lateral movement, and marks these patterns in the tracing results. Finally, the server generates anomaly tracing results containing the complete attack chain. These results are presented in the form of visual graphs and structured reports, showing in detail the complete propagation path from the initial intrusion point to the point where the anomalous behavior was triggered. This includes all process shard nodes involved, key file and network operations, time-series information, and recommended protection and remediation measures.

[0059] In this embodiment, by adopting the technical solution of updating the process state version identifier in response to network data reception events and generating new process shard nodes, and performing reverse search based on cross-shard data dependency edges and predecessor context associations, long-running resident service processes can be divided into discrete logical units according to business interaction boundaries, and data causal and contextual relationships across time can be accurately constructed. This effectively solves the problems of "state pollution" and "dependency explosion" caused by the construction of the full lifecycle graph in related technologies, and thus achieves the generation of highly accurate abnormal behavior tracing results that exclude interference from irrelevant historical business.

[0060] Based on the above embodiments, the method provided in this embodiment will be further described in more detail below. Please refer to Figure 2, which is another flowchart illustrating a method for tracing abnormal device behavior in this application embodiment.

[0061] S201. Obtain a system call event set arranged in chronological order. The system call event set shall include at least the process identifier, operation action type and resource identifier.

[0062] S202. Based on the process identifier, identify the resident service process in the system call event set, and configure the process status version identifier for the resident service process.

[0063] Steps S201 and S202 are similar to steps S101 and S102 in the embodiment described in FIG1, and will not be repeated here.

[0064] Optionally, in some embodiments, before monitoring begins in step S203, the server also performs an initialization environment mapping operation. The server creates a virtual "System Baseline Node" and initializes the resource identifiers (such as the combination of inode and file path) of all files existing in the file system at the time of monitoring in the resource version mapping table, pointing their origins to this system baseline Node. Therefore, when the resident service process subsequently reads these existing files, the server can identify that they depend on the baseline environment, rather than on a specific dynamic business shard. This allows for reverse tracing, enabling the server to trace not only dynamic attacks but also environment configuration issues.

[0065] S203. In response to detecting that the resident service process has received network data, obtain the timestamp of the current network data reception event and the historical timestamp of the last network data reception event of the resident service process.

[0066] The occurrence timestamp represents the precise time record when the server detected the current network data receiving operation performed by the resident service process; the historical timestamp refers to the time record of the last time the same resident service process performed a network data receiving operation, which serves as a time reference point; the preset time threshold represents the critical time interval used by the server to determine whether to create a new process shard node. This threshold is used to distinguish between continuous network activities and independent business requests, and is usually set to a time length in seconds or minutes. The specific value can be adjusted according to business characteristics. For example, it can be set to 30 seconds for high-frequency web services and 5 minutes for low-frequency database services to balance sharding granularity and system performance.

[0067] Specifically, when the server detects that a resident service process is receiving network data, it needs to analyze the time dimension to determine whether to trigger an update of the process state version and the creation of a new shard node. When the server's network monitoring module identifies that the resident service process has executed network receiving system calls such as accept, recv, and recvfrom, it immediately extracts the precise timestamp of the current network data receiving event. This timestamp is obtained from the time field of the system call event to ensure the accuracy of the time record. Subsequently, the server queries the historical network activity record table of the resident service process to obtain the historical timestamp of the process's last network data receiving operation. If the process is being monitored for the first time or has not had a network receiving event before, the historical timestamp is set to the process startup time or monitoring start time.

[0068] Optionally, in some embodiments, when the server detects that a resident service process generates other external request data reception behavior, it can also execute the scheme of this embodiment. In addition to network packets based on the TCP / IP protocol suite, in this embodiment, the external request data also includes, but is not limited to: local communication data received through Unix domain sockets, inter-process instructions transmitted through named pipes, and business processing requests triggered by shared memory semaphores. The server configures a system call monitoring list to regard the above-mentioned entry calls that mark the business boundary as events that trigger fragmentation determination.

[0069] S204. Parse the network 5-tuple information or socket handle in the current network data reception event, generate the communication session identifier of the current event; calculate the time difference between the occurrence timestamp and the historical timestamp.

[0070] The network quintuple information represents five key parameters used to uniquely identify a network connection or session in network communication, including the source IP address, source port number, destination IP address, destination port number, and transport protocol type (such as TCP or UDP). This information can accurately distinguish different network communication sessions. The socket handle is a unique identifier assigned by the operating system to a network connection, usually a file descriptor or handle value, used to reference a specific network connection object in system calls. The communication session identifier is a unique tag generated by the network quintuple information or socket handle to identify a specific network communication session. This identifier can distinguish different client requests handled by the same process or different types of network connections. The time difference is the length of the time interval obtained by the server by calculating the difference between the occurrence timestamp and the historical timestamp. This value is expressed in time units (such as seconds or milliseconds) to represent the time distance between two network reception events.

[0071] Specifically, after obtaining the timestamps of current and historical network data reception events, the server needs to parse the session characteristic information of network communication to more accurately determine the correlation and independence of network events. The server first parses the network protocol information carried in the current network data reception event, extracting the network 5-tuple information from the system call parameters, including the IP addresses, port numbers, and transport protocol types of both communicating parties, or obtaining the socket handle value used in the system call. Based on the extracted network information, the server generates a communication session identifier for the current event. This identifier can be a hash value of the network 5-tuple information, a string representation of the socket handle, or a unique identifier calculated by combining multiple network parameters. Simultaneously, the server also performs a time difference calculation operation, subtracting the historical timestamp of the last network data reception event from the timestamp of the current network data reception event to obtain the time difference representing the time interval between the two network activities.

[0072] S205. If the time difference is greater than the preset time threshold, update the process status version identifier and generate a new process shard node.

[0073] Among them, updating the process state version identifier means that the server increments the current version number of the resident service process, such as updating from V0 to V1, from V1 to V2, etc. Each version update marks the transformation of the process's logical state. The new process shard node represents the graph node object created by the server in the source graph to carry all system call events and operation records of the process in the new version state. This node has an independent identifier, version information, and time range attribute.

[0074] Specifically, after calculating the time difference, the server needs to compare this difference with a preset time threshold to determine whether to perform process sharding to achieve fine-grained state management of resident service processes. When the server detects that the time difference is greater than the preset time threshold, it determines that the current network data reception event represents the start of a relatively independent business process, which needs to be logically isolated from previous network activities. The server immediately initiates the process state version identifier update process. First, it locks the state management object of the resident service process to prevent version conflicts caused by concurrent updates. Then, it performs an atomic increment operation on the current version identifier of the process to ensure the continuity and uniqueness of the version number. After completing the version update, the server creates a corresponding new process shard node in the source graph data structure. This node inherits the basic attribute information of the process (such as process ID, process name, etc.) and sets a new version identifier, creation timestamp, and network event information that triggered the shard. The server also updates the historical timestamp record of the process, setting the occurrence timestamp of the current event as the new historical baseline to prepare for the calculation of the time difference of the next network event.

[0075] S206. If the time difference is less than or equal to a preset time threshold, the process state version identifier remains unchanged, and the current network data reception event is mapped to the current process shard node, specifically including:

[0076] Determine whether the communication session identifier of the current network data reception event is consistent with the communication session identifier associated with the current process shard node;

[0077] If the time difference is less than or equal to the preset time threshold and the communication session identifier is consistent, then the step of keeping the process state version identifier unchanged will be executed.

[0078] If the time difference is less than or equal to the preset time threshold, but the communication session identifiers are inconsistent, then the steps of updating the process status version identifier and generating a new process shard node are executed.

[0079] The current process shard node represents the existing shard node in the server tracing graph that corresponds to the current version status of the resident service process. This node already carries the historical system call events and operation records under this version.

[0080] Specifically, after determining that the time difference is less than or equal to a preset time threshold, the server cannot decide to maintain the existing sharding state solely based on the time dimension. It also needs to further verify the correlation of network events by comparing network session characteristics to ensure the accuracy of the sharding decision. When the server detects that the time difference meets the continuity condition, it immediately initiates the communication session identifier comparison process. First, it retrieves the list of communication session identifiers associated with the current process shard node from the attribute information of the node. This list records the original network event that triggered the creation of the current shard node and the session information of all subsequent network events mapped to the node. The server compares the communication session identifier generated by the current network data reception event with the session identifiers associated with the node one by one to check if there is a completely matching session record. If the server finds that the communication session identifier of the current event is completely consistent with a certain associated session identifier of an existing shard node, it determines that the current network event belongs to the continuation of a known network session. At this time, the server keeps the process state version identifier unchanged, directly maps and associates the current network data reception event and its related attribute information to the current process shard node, and updates the node's last activity timestamp and event counter. However, if the server finds that the communication session identifier of the current event does not match any of the associated session identifiers of the existing shard nodes, even if the time interval is short, it indicates that this is a new request from a different client or a different connection. At this time, the server will perform an update operation on the process state version identifier and generate a new process shard node to ensure that the business processing logic of different network sessions can be correctly isolated and traced, and avoid errors in tracing analysis caused by session confusion.

[0081] S207. Establish a predecessor context association between the new process shard node and the previous process shard node.

[0082] This step is similar to step S103 in the embodiment shown in Figure 1, and will not be repeated here.

[0083] S208. When the operation action type of the system call event is write type, obtain the resource attribute type corresponding to the resource identifier in the current system call event. The resource attribute type includes at least dynamic data type and static shared type.

[0084] Among them, write type indicates the operation type of system call event belonging to the data writing or resource modification operation category, including file writing operations such as write, pwrite, and fwrite, as well as resource creation and attribute modification operations such as create, mkdir, and chmod; resource attribute type refers to the classification and identification of system resources according to their data characteristics and sharing mode, used to distinguish the processing strategies of different types of resources in the source tracing analysis; dynamic data type indicates the resource category whose content changes with the system operation process, such as log files, temporary files, and user data files, etc. The write operation of this type of resource has a clear data flow direction and causal relationship value; static sharing type refers to shared resources in the system that are frequently accessed by multiple processes and whose content is relatively stable, such as system library files (such as libc.so), configuration files (such as / etc / passwd), shared memory areas, etc. Because this type of resource is used by a large number of processes, establishing cross-shard dependency edges will lead to too many noisy connections in the source tracing graph.

[0085] Specifically, during the mapping of system call events, the server needs to perform special resource attribute analysis on write-type operations to determine whether the write operation should be recorded in the resource version mapping table. When the server identifies that the current event belongs to the write or resource modification type by parsing the operation action type field of the system call event, it immediately initiates the resource attribute type judgment process. The server first extracts resource identification information from the system call event, and then queries a pre-built resource classification knowledge base. This knowledge base contains attribute characteristic rules for various resources in the system, such as file path patterns, file extensions, inode attributes, access permissions, and other characteristic information. Based on the path characteristics, file type, access pattern, and other information of the resource identifier, the server classifies resources into dynamic data types or static shared types. For dynamic data type resources, such as temporary files in the / tmp directory, document files in the user's home directory, and application-generated log files, the server determines that write operations on these resources have important traceability value because changes in their content often directly reflect the execution process of the process's business logic. For static shared type resources, the server recognizes that although these resources may be written to, due to their shared nature, establishing too many dependencies will dilute the truly important attack paths, thus requiring different processing strategies.

[0086] S209. If the resource attribute type is a dynamic data type, the resource identifier of the current event and the current process shard node are updated to the resource version mapping table, allowing the subsequent establishment of cross-shard data dependency edges for the resource. The resource version mapping table is used to record the correspondence between the resource identifier and the version of the process shard node that last performed a write operation on the resource.

[0087] The resource version mapping table represents a data structure maintained by the server to record the mapping relationship between system resources and the process shard node that last wrote to the resource. The table uses the resource identifier as the key and the version information of the process shard node as the data value, supporting quick querying of the most recent write source of any resource. Cross-shard data dependency edges represent directed edges connecting different process shard nodes in the source graph. These edges indicate the causal relationship of data flowing from one shard node (data producer) to another shard node (data consumer).

[0088] Specifically, after confirming that the resource involved in the current system call event is a dynamic data type, the server needs to update the relevant information of the write operation in the resource version mapping table. When the server determines that the resource attribute type is a dynamic data type, it immediately executes the update operation of the resource version mapping table. First, it obtains the resource identifier of the current system call event, which may be the full path of the file, the inode number, or other unique resource locator. The server then obtains the identifier information of the process shard node currently processing the event, including key attributes such as process ID, shard version number, and node creation time. When performing the table update operation, the server adopts an atomic write mechanism, using the resource identifier as the primary key of the mapping table and storing or updating the complete information of the current process shard node as the mapping value. If the resource has a previous write record, the old record is overwritten with the current process shard node information, ensuring that the mapping table always retains the latest write source for each resource.

[0089] S210. If the resource attribute type is static shared type, then the update operation of the resource version mapping table is performed, but the cross-shard data dependency edge generated based on the static shared resource is blocked, thereby avoiding the appearance of "super nodes" and dependency explosion in the traceability graph due to high frequency reading of public library files.

[0090] Specifically, after the server identifies, through preceding steps, that the resource involved in the current system call event is of a static shared type, it needs to adopt a composite processing strategy of "logging and auditing but logically isolating" to ensure the ability to detect tampering with core system files while maintaining the simplicity of the traceability graph. When the server confirms that the resource attribute is of static shared type and the operation is write, it immediately performs an update operation on the resource version mapping table, binding the current process shard node (i.e., the modifier) ​​with the resource identifier and overwriting the old mapping record. This update operation is crucial, as it ensures that the system can retain the key forensic clue of "the process that last modified the shared resource," preventing malicious attackers from using methods such as system library replacement or configuration tampering (e.g., modifying / etc / ld.so.preload) to launch covert attacks and evade tracking.

[0091] However, during the aforementioned update, the server synchronously places a dependency blocking flag in the corresponding record of the resource version mapping table. The effect of this flag in subsequent processes is that when thousands of other processes read this static shared resource and query the mapping table, the server detects the blocking flag and forcibly terminates the creation process of cross-shard data dependency edges. Through this mechanism, the server effectively severs the graph connections from modifiers to a massive number of readers, preventing the formation of supernodes with huge connection counts in the source graph due to the universal loading of system library files. This preserves the ability to audit potential tampering at the physical storage level and successfully avoids the dependency explosion problem at the logical topology level.

[0092] Optionally, in some embodiments, to prevent critical file tampering attacks from being missed due to blocking the dependency edges of static shared resources, the server is also configured with an "abnormal write escape" verification mechanism for static shared types. Specifically, when performing an update operation on the resource version mapping table, the server will further verify the identity or permissions of the process currently performing the write operation. If the process performing the write operation is a system installation program (such as apt, yum) or an update program with a trusted signature, the above blocking strategy is maintained to filter out normal system environment change noise; if the process performing the write operation is the resident service process itself (i.e., the current process shard node), or an untrusted third-party process, the static shared resource is determined to have entered a "suspected tampering state".

[0093] Correspondingly, for resources marked as "suspected of being tampered with," when a read operation is subsequently detected, the server will forcibly remove the dependency blocking restrictions for static shared types and generate cross-shard data dependency edges from the write shard node to the read shard node according to the processing logic for dynamic data types. Through this mechanism, this application can significantly reduce the size of the tracing graph through static resource filtering while accurately preserving the causal path of high-risk operations such as attackers tampering with system library files (e.g., .so files) and configuration files (e.g., / etc / passwd) using resident process vulnerabilities, thus avoiding security misses caused by over-optimization.

[0094] S211. When the operation action type of the system call event is read, query the resource version mapping table according to the resource identifier of the current event;

[0095] Specifically, when processing system call events, the server needs to perform a cross-shard data dependency identification process for read-type operations. This involves querying the resource version mapping table to determine if the current read operation has a definite data source. Once the server confirms that the current event is a read-type operation, it immediately initiates the cross-shard dependency detection mechanism. The server first extracts the identifier information of the resource being read from the current system call event. This identifier may be a file path, file descriptor, inode number, or other marker that uniquely identifies the resource. Then, using this resource identifier as the query key, the server performs an exact match query in the resource version mapping table to search for a corresponding write history for that resource.

[0096] S212. If the corresponding historical shard node is found, establish a cross-shard data dependency edge from the historical shard node to the current process shard node.

[0097] Specifically, after successfully retrieving the write history of a resource, the server needs to establish explicit cross-shard data dependencies in the source graph to accurately reflect the causal connections between shard nodes of different processes. Once the server obtains complete information about historical shard nodes from the resource version mapping table, it first verifies the validity of both the historical and current process shard nodes, ensuring that both nodes exist in the source graph's data structure and have the correct node attribute information. Before creating a dependency edge, the server also checks if the same dependency already exists to avoid redundant graph structure creation. After confirming no duplicates, the server creates a new directed edge in the source graph, with the source node set to the retrieved historical shard node and the target node set to the process shard node currently processing the read event. The server assigns a unique edge identifier to the newly created dependency edge and sets its type attribute to "cross-shard data dependency," while recording detailed attributes such as the specific resource information that triggered the dependency, the timestamp of the read / write operation, and the size of the data transfer.

[0098] Specifically, if the corresponding historical shard node is not found in the resource version mapping table based on the resource identifier of the current event, the server can take the following processing strategy: First, perform path normalization parsing on the resource identifier to obtain its physical inode (Inode) to exclude query failures caused by file aliases; if no record is found based on the physical inode, then compare the file system modification timestamp of the resource with the startup timestamp of the monitoring system.

[0099] For resources whose modification timestamps are earlier than the monitoring start time, they are associated with a preset system baseline node and marked as initial environment dependencies. For resources whose modification timestamps are later than the monitoring start time but have no write records, the server marks them as "resources of unknown origin" and immediately triggers file integrity checks and potential monitoring escape alarms for these resources. This hierarchical processing mechanism effectively solves the problem of broken traceability graphs caused by existing files or monitoring blind spots.

[0100] S213. When receiving an alarm message about abnormal behavior of a target device, locate the target process shard node corresponding to the abnormal alarm message based on the target process identifier in the abnormal alarm message.

[0101] This step is similar to step S105 in the embodiment shown in Figure 1, and will not be repeated here.

[0102] S214. Starting from the target process shard node, perform a reverse search based on cross-shard data dependency edges and predecessor context associations to generate abnormal behavior tracing results.

[0103] This step specifically includes:

[0104] Initialize the source tracing path by using the target process shard node as the current search node;

[0105] When performing a reverse search based on cross-shard data dependency edges, the searched historical shard nodes are marked as first priority nodes;

[0106] When performing a reverse search based on the predecessor context association, the context decay coefficient is calculated based on the time interval between the current search node and the predecessor shard node.

[0107] If the context decay coefficient meets the preset correlation threshold, the predecessor shard node is marked as a second priority node and assigned a second priority correlation weight; the first priority is higher than the second priority, and the weight of the first priority is higher than the weight of the second priority.

[0108] The searched nodes are added to the tracing path in descending order of priority until the tracing search is completed and the abnormal behavior tracing results are obtained.

[0109] In this context, reverse search refers to the server's analysis process of traversing backwards along the directed edges of the source graph, starting from the target process shard node corresponding to the abnormal behavior, to reconstruct the complete causal chain of the abnormal behavior by tracing the source of data flow and control flow; first priority nodes refer to historical shard nodes discovered through cross-shard data dependency edge search, these nodes represent clear data causal relationships and have the highest source tracing value; the context decay coefficient represents the association strength decay value calculated by the server based on the time interval between the current search node and the predecessor shard node, this coefficient reflects the impact of time distance on the credibility of causal relationships, and is usually calculated using an exponential decay function, with the decay coefficient decreasing as the time interval increases; the preset association threshold represents the service The threshold is used to determine whether the predecessor context association has tracing value. This threshold filters out historical nodes with low association to avoid excessive diffusion of the tracing path. It is usually set to a value between 0.3 and 0.7, which can be adjusted according to the system's business characteristics and analysis accuracy requirements. The second priority node refers to the predecessor fragment node found through predecessor context association search and whose context decay coefficient meets the threshold requirement. These nodes represent possible indirect causal relationships. The association weight is used to represent the quantitative value of the importance of different priority nodes in the tracing path. The weight of the first priority is usually set to 0.8-1.0, and the weight of the second priority is set to 0.3-0.6. The weight value affects the sorting and presentation of the final tracing results.

[0110] Specifically, after locating the target process shard node corresponding to the abnormal behavior, the server needs to execute a systematic reverse search algorithm to reconstruct the complete attack chain of the abnormal behavior. The server first sets the target process shard node corresponding to the abnormal alarm information as the current search node, and initializes the source path data structure. This structure includes components such as a node queue, edge set, and priority mapping table to store all relevant information discovered during the search process. The server starts the main loop of the reverse search. In each iteration, it first checks all incoming edges of the current search node. These incoming edges include two types: cross-shard data dependency edges and predecessor context association edges. When the server finds a cross-shard data dependency edge for the current search node, it immediately traces along these edges to the corresponding historical shard node, marks the searched historical shard node as the first priority node, and assigns it the highest association weight value. For predecessor context association edges, the server first calculates the time interval between the current search node and the predecessor shard node, and then applies a context decay function (such as the exponential decay function e). -λt The context decay coefficient is calculated by λ, where t is the time interval and λ is the decay parameter. The server compares the calculated decay coefficient with a preset correlation threshold. Only the predecessor shard node that meets the threshold requirement is marked as a second-priority node and added to the search queue.

[0111] During the construction of the tracing path, the server strictly processes the searched nodes in descending order of priority, prioritizing the reverse search of the first-priority nodes before processing the second-priority nodes. The server also sets search depth limits and loop detection mechanisms to prevent the search process from getting stuck in an infinite loop or excessively expanding its scope. When the search queue is empty or a preset search termination condition is met, the server ends the reverse search process and integrates all collected node, edge relationship, priority information, and weight data into a complete anomaly behavior tracing result. This result is presented in the form of a directed graph and a time-series analysis report, detailing the complete causal propagation path from the initial attack entry point to the trigger point of the anomaly behavior.

[0112] In this embodiment, by employing a dual determination mechanism based on occurrence timestamps and communication session identifiers to dynamically generate process sharding nodes, distinguishing resource attribute types to block the dependency construction of static shared type resources, and introducing a context decay coefficient for hierarchical reverse search, the technical solution can accurately identify business boundaries under high concurrency and automatically filter invalid associations caused by public resources. This effectively solves the problem of surge in tracing graph nodes and false alarms caused by rigid sharding strategies or interference from shared resources in related technologies, thereby achieving abnormal behavior tracing results that balance system resource consumption and causal accuracy.

[0113] The server of the device monitoring system in the embodiments of this application is described below from the perspective of hardware processing. Please refer to Figure 3, which is a schematic diagram of the physical device structure of the server of the device monitoring system in the embodiments of this application.

[0114] It should be noted that the server structure shown in Figure 3 is merely an example and should not impose any limitations on the functionality and scope of use of this embodiment of the invention. The server in this embodiment can be deployed in the data center of a cloud computing platform, edge computing node, or device monitoring system for efficient processing and tracing of data from various IoT devices.

[0115] As shown in Figure 3, the server includes a CPU 301, which can perform various appropriate actions and processes based on a program stored in the read-only memory ROM 302 or a program loaded from the storage section 308 into the random access memory RAM 303, such as performing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An I / O interface 305 is also connected to the bus 304.

[0116] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0117] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by CPU 301, it performs the various functions defined in the present invention.

[0118] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0119] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0120] Specifically, the server in this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements a method for tracing the source of abnormal device behavior provided in the above embodiment.

[0121] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the server described in the above embodiments; or it may exist independently and not assembled into the server. The storage medium carries one or more computer programs that, when executed by a processor of the server, cause the server to implement a method for tracing abnormal device behavior provided in the above embodiments.

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

[0123] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0124] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for tracing the source of abnormal equipment behavior, applied to the server of an equipment monitoring system, characterized in that, The device monitoring system also includes a resource version mapping table, which records the version correspondence between resource identifiers and the process shard node that last performed a write operation on the resource. The method includes: acquiring a system call event set arranged in chronological order, the system call event set including at least a process identifier, an operation action type, and a resource identifier; identifying resident service processes in the system call event set based on the process identifier, and configuring a process state version identifier for the resident service process; in response to detecting that the resident service process has received network data, updating the process state version identifier and generating a new process shard node, and establishing a predecessor context association between the new process shard node and the previous process shard node; mapping events in the system call event set to corresponding process shard nodes based on the process state version identifier at the time of the event, and identifying that the current system call event is a read operation on resources written to historical shard nodes based on the operation action type and resource identifier, generating cross-shard data dependency edges; when receiving an abnormal behavior alarm message for a target device, locating the target process shard node corresponding to the abnormal alarm message based on the target process identifier in the abnormal alarm message; and so on. Starting from the target process shard node, a reverse search is performed based on the cross-shard data dependency edge and the predecessor context association to generate abnormal behavior tracing results. The generation of the cross-shard data dependency edge specifically includes: when the operation action type of the system call event is a write type, obtaining the resource attribute type corresponding to the resource identifier in the current system call event, where the resource attribute type includes at least dynamic data type and static shared type; if the resource attribute type is the dynamic data type, then updating the resource identifier of the current event and the current process shard node to the resource version mapping table, and allowing subsequent updates. Continue to establish cross-shard data dependency edges for the resource; if the resource attribute type is the static shared type, then perform an update operation on the resource version mapping table, but block the cross-shard data dependency edges generated based on the static shared resource; update the resource identifier of the current event and the current process shard node to the resource version mapping table; when the operation action type of the system call event is a read type, query the resource version mapping table according to the resource identifier of the current event; if the corresponding historical shard node is found, establish a cross-shard data dependency edge from the historical shard node to the current process shard node.

2. The method according to claim 1, characterized in that, In response to detecting that the resident service process has received network data, the process status version identifier is updated and a new process shard node is generated. Specifically, this includes: obtaining the timestamp of the current network data reception event and the historical timestamp of the last network data reception event of the resident service process; calculating the time difference between the occurrence timestamp and the historical timestamp; if the time difference is greater than a preset time threshold, the process status version identifier is updated and a new process shard node is generated; if the time difference is less than or equal to the preset time threshold, the process status version identifier is kept unchanged, and the current network data reception event is mapped to the current process shard node.

3. The method according to claim 2, characterized in that, Before calculating the time difference between the occurrence timestamp and the historical timestamp, the method further includes: parsing the network 5-tuple information or socket handle in the current network data reception event to generate a communication session identifier for the current event.

4. The method according to claim 3, characterized in that, If the time difference is less than or equal to the preset time threshold, the process state version identifier is kept unchanged, and the current network data reception event is mapped to the current process shard node. Specifically, this includes: determining whether the communication session identifier of the current network data reception event is consistent with the communication session identifier associated with the current process shard node; if the time difference is less than or equal to the preset time threshold and the communication session identifiers are consistent, the step of keeping the process state version identifier unchanged is executed; if the time difference is less than or equal to the preset time threshold, but the communication session identifiers are inconsistent, the step of updating the process state version identifier and generating a new process shard node is executed.

5. The method according to claim 1, characterized in that, Starting from the target process shard node, a reverse search is performed based on the cross-shard data dependency edges and the predecessor context association to generate an abnormal behavior tracing result. Specifically, this includes: using the target process shard node as the current search node and initializing the tracing path; when performing a reverse search based on the cross-shard data dependency edges, marking the searched historical shard nodes as first priority nodes; when performing a reverse search based on the predecessor context association, calculating the context decay coefficient based on the time interval between the current search node and the predecessor shard node; if the context decay coefficient meets a preset association threshold, marking the predecessor shard node as a second priority node and assigning it a second priority association weight; the first priority is higher than the second priority, and the weight of the first priority is higher than the weight of the second priority; adding the searched nodes to the tracing path in descending order of priority until the tracing search is completed, and obtaining the abnormal behavior tracing result.

6. A server for an equipment monitoring system, characterized in that, The server includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the server to perform the method as described in any one of claims 1-5.

7. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on the server, it causes the server to perform the method as described in any one of claims 1-5.

8. A computer program product, characterized in that, When the computer program product is run on the server, the server performs the method as described in any one of claims 1-5.

Images