A System Call Analysis Method Based on Multi-Dimensional Association

Abstract

This invention relates to a system call analysis method based on multi-dimensional correlation, belonging to the field of data processing technology. It solves the problems of high performance overhead and difficulty in balancing accuracy and real-time performance in existing call analysis methods. The method includes: filtering and capturing system call events generated by a target application according to filtering rules, and dynamically adjusting the filtering rules by real-time monitoring of system load; correlating the captured system call events along process, time, and resource dimensions to obtain multiple system call sequences; precisely matching each system call sequence with atomic behavior rules to obtain the behavior type of successfully matched system call sequences; performing feature matching of unmatched system call sequences with historical behavior data to obtain the corresponding behavior type; and outputting structured behavior data based on each system call sequence and its behavior type. This achieves accurate and real-time analysis of discrete system call events.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a system call analysis method based on multi-dimensional correlation. Background Technology

[0002] With the deepening development of cloud computing, big data, and enterprise informatization, application system behavior monitoring and compliance auditing have become key technical means to ensure stable business operations, data security, and compliance with regulatory requirements. System calls, as the core interface for interaction between applications and the operating system kernel, record all underlying behaviors of applications, including file operations, network communication, and process management. They are the core data source for reconstructing the full picture of application behavior and conducting in-depth security analysis. By capturing and correlating system call events throughout the application lifecycle, a clear application behavior chain can be constructed, providing crucial support for anomaly detection, threat tracing, and compliance review.

[0003] In existing technologies, the analysis of system calls generally adopts a "full capture + post-event batch correlation" approach. That is, all types of system call events generated by all processes are captured indiscriminately at the kernel level, and then offline or batch correlation analysis is performed on the massive number of collected discrete events in user space based on preset rules.

[0004] Existing methods suffer from three major flaws in practical applications. First, they incur excessive system performance overhead. The full capture mode continuously consumes significant CPU and memory resources, while the subsequent batch association process requires complex matching calculations on massive amounts of events. This combination places a heavy burden on production systems, making it difficult to meet the performance requirements of production environments. Second, the accuracy and timeliness of association results are severely lacking. Existing methods often rely on a single dimension (such as process ID or timestamp) to aggregate events. When faced with complex concurrency, multi-process collaboration, or cross-resource interaction scenarios, this easily leads to fragmented and broken behavioral chains, resulting in numerous misclassifications. Furthermore, the post-event analysis mode has inherent time lags, failing to support dynamic application scenarios such as real-time compliance auditing and immediate security interception. Third, existing association algorithms lack specific aggregation rules designed for the event characteristics of system calls, making it difficult to transform discrete low-level system calls into meaningful high-level application behaviors, and thus failing to provide high-quality structured data for subsequent visualization and compliance auditing. Summary of the Invention

[0005] Based on the above analysis, the embodiments of the present invention aim to provide a system call analysis method based on multi-dimensional association, in order to solve the problems of high system performance loss and difficulty in balancing the accuracy and real-time performance of behavior association caused by the existing full capture and single-dimensional association.

[0006] This invention provides a system call analysis method based on multi-dimensional correlation, comprising the following steps: Based on preset filtering rules, system call events generated by the target application are filtered and captured, and the filtering rules are dynamically adjusted by real-time detection of system load status. For captured system call events, process-dimensional association is performed based on process identifier, time-dimensional association is performed based on time window, and resource-dimensional association is performed based on the resources operated by the system call events, and multiple system call sequences are integrated. Each system call sequence is precisely matched with preset atomic behavior rules to obtain the behavior type of the successfully matched system call sequence; the unmatched system call sequences are feature-matched with historical behavior data to obtain the corresponding behavior type; and structured behavior data is output based on each system call sequence and its behavior type.

[0007] Further improvements to the above method involve dynamically adjusting filtering rules based on real-time system load status, including: The system acquires the system CPU utilization in real time. When the system CPU utilization exceeds the preset load threshold, low-priority system call events in the filtering rules are dynamically removed. When the system CPU utilization is lower than the preset load threshold, the capture of the removed low-priority system call events is gradually restored according to the preset recovery rate.

[0008] Further improvements to the above method include process-dimensional association based on process identifiers, including: Obtain process information of captured system call events, and mount the captured process information to the process tree based on the process identifier and parent process identifier in the process information.

[0009] Based on the further improvement of the above method, the process tree takes the root process of the target application as the vertex, and monitors the survival status of processes in the process tree by listening to process exit events and polling mechanism, marking processes that have exited or are in a zombie state as invalid and removing them from the process tree.

[0010] Further improvements to the above method include time-dimensional correlation based on time windows, including: For system call events that are associated at the process level, based on a preset time window, system call events with call timestamps within the same time window are divided into the same continuous behavior segment; at the same time, based on a preset cross-window tolerance threshold, system call events that meet the conditions of having the same resource identifier and a call timestamp interval within the cross-window tolerance threshold are divided into the same continuous behavior segment.

[0011] Further improvements to the above method include resource-level association based on the resources operated on by system call events, including: Extract the resource identifier operated by each system call event within each consecutive behavior segment, and associate system call events with the same resource identifier into a system call sequence according to the order of the call timestamp.

[0012] Based on the further improvement of the above method, before performing exact matching and feature matching, the duplicate system call events that are repeatedly triggered in each system call sequence are deduplicated, and only the corresponding first event is retained and marked with the number of times it is repeatedly triggered.

[0013] Based on further improvements to the above method, the unmatched system call sequences are matched with historical behavior data to obtain the corresponding behavior types, including: Extract features from the sequence of unmatched system calls and construct a multidimensional feature vector; Based on multidimensional feature vectors, the K-nearest neighbor algorithm is used to find the K most similar behavior data in historical behavior data; the behavior type that appears most frequently among the K most similar behavior data and exceeds a preset proportion threshold is taken as the corresponding behavior type.

[0014] Based on the above method, further improvements are made to extract features from the unmatched system call sequences and construct a multi-dimensional feature vector, including: The time-series fingerprinting method is used to extract sequence features from the system call sequence; The system call events in the system call sequence are standardized, and the resulting resource identifiers are hashed and normalized to obtain resource characteristics. The call timestamp intervals between system call events in the system call sequence are discretized, and all discretized values ​​are statistically calculated and normalized to obtain the time interval characteristics. The sequence features, resource features, and time interval features are weighted by their respective preset weights and then combined to obtain a multidimensional feature vector.

[0015] Based on further improvements to the above method, a time-series fingerprinting method is used to obtain sequence features from the system call sequence, including: The system call sequence is split into binary time units of adjacent calls in chronological order. A hash calculation is performed on each binary time unit. All hash values ​​are statistically calculated and normalized to obtain the sequence characteristics.

[0016] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects: 1. A dual filtering mechanism of static preset filtering rules and dynamic adaptive adjustment of filtering rules is adopted to achieve dynamic selective capture of system call events. Non-core events are automatically filtered under high load and capture is resumed under low load. This effectively avoids excessive consumption of CPU and memory resources caused by full capture, keeps system performance loss within a controllable range, and facilitates stable adaptation to the long-term deployment needs of the production environment.

[0017] 2. By coordinating and associating processes, time, and resources, discrete system call events are integrated into a system call sequence that is aggregated by resources and ordered by time. This solves the problems of behavior fragmentation and misjudgment caused by traditional single-dimensional association, and significantly improves the integrity and accuracy of application behavior links.

[0018] 3. By combining precise matching of preset atomic behavior rules with feature matching of K-nearest neighbor algorithm, a dual-path behavior recognition mechanism is established, which not only ensures the rapid and accurate recognition of common known behaviors, but also enables adaptive classification of system call sequences not covered by preset rules. This improves the coverage and robustness of behavior type recognition and enables accurate and real-time analysis of discrete system call events.

[0019] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0020] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Figure 1 This is a flowchart of a system call analysis method based on multi-dimensional association in an embodiment of the present invention. Detailed Implementation

[0021] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0022] A specific embodiment of the present invention discloses a system call analysis method based on multi-dimensional correlation, such as... Figure 1 As shown, it includes steps S1-S3.

[0023] S1. Based on preset filtering rules, the system call events generated by the target application are filtered and captured, and the filtering rules are dynamically adjusted by real-time detection of system load status.

[0024] This step employs a dual filtering mechanism of static preset filtering rules and dynamic adaptive adjustment of filtering rules to dynamically and selectively capture system call events, thereby accurately obtaining system call events related to the monitoring target while keeping system performance loss within an acceptable range.

[0025] It should be noted that the preset filtering rules include a process filtering list and a system call type filtering list. The process filtering list is used to limit the target scope of capture, supports whitelist configuration, and only allows the capture of system call events generated by the target application process and its derived child processes.

[0026] For example, the process whitelist is set to include the target process corresponding to the process name "app_server" and its dynamically spawned child processes at runtime; during operation, the system dynamically matches the corresponding process PID by traversing the process information under the / proc file system (such as reading / proc / [PID] / comm or / proc / [PID] / cmdline) based on the configured process name, and includes its subsequent child processes in the capture range.

[0027] It should be noted that the system call type filter list in the filtering rules is used to limit the types of system calls to be monitored and the system call events they contain, according to the monitoring scenario requirements and functional classification.

[0028] For example, system call types include: file operation, process management, memory management, network communication, device and driver control, clock and timer, signal processing, security and permission, and debugging and performance analysis. File operation system call events include: open, close, read, write, rename, unlink, mkdir, and rmdir. Process management system call events include: fork, vfork, clone, execve, exit, exit_group, and wait. Network communication system call events include: socket, bind, listen, accept, connect, send, recv, and shutdown. When only file operation and network communication behaviors are considered, only file operation and network communication types can be selected, excluding process management and other system call types from the capture scope, thus reducing the number of invalid events at the source.

[0029] Furthermore, system call events included in the system call types are preset with priorities. Priority is determined based on the degree to which system calls support core application behaviors and their impact on system performance, categorizing them into high and low priorities. High-priority system calls directly support core application business behaviors such as file operations and network communication, and are crucial for reconstructing the application's behavior chain. The performance overhead from capturing and analyzing these calls is controllable; examples include file operation calls like `unlink`, `write`, and `read`, and network communication calls like `connect`, `bind`, and `send`. Low-priority system calls are not directly related to core application business behaviors and are mainly used for system debugging or low-level auxiliary interactions. Whether or not they are captured does not affect the reconstruction of the core behavior chain, and capturing a large number of them can easily cause additional CPU and memory overhead. Examples include debugging and performance analysis calls like `ptrace` and `sysinfo`, as well as some non-core low-level auxiliary calls. The priority classification allows users to customize adjustments according to actual business needs, upgrading specific low-priority calls to high priority or downgrading non-core high-priority calls to adapt to personalized monitoring requirements.

[0030] Furthermore, by monitoring the system load status in real time, the filtering rules are dynamically adjusted, including: The system acquires CPU utilization in real time, for example, by sampling and reading the / proc / stat file every 100ms and calculating the CPU utilization. When the system CPU utilization exceeds the preset load threshold (default 8%, configurable), low-priority system call events in the filtering rules are dynamically removed, i.e., the capture of these system call events is stopped.

[0031] Specifically, the triggering frequency of each low-priority system call event is counted by sliding time window (e.g., 1-second window with a step size of 500ms), and the low-priority system call event with the highest triggering frequency is removed one by one until the system CPU utilization rate falls below the load threshold.

[0032] When the system CPU utilization rate is lower than the preset load threshold, the capture of the removed low-priority system call events is gradually restored according to the preset recovery rate (e.g., 50 system call events / second) to enrich the integrity of the call behavior as much as possible when the system is idle.

[0033] It should be noted that by dynamically and adaptively adjusting the filtering rules, the system prioritizes application performance when the system load is high and enhances the richness of the analyzed data when the load is low. This effectively solves the problems of excessive performance loss and inability to adapt to long-term deployment in production environments in traditional full capture solutions.

[0034] Employing eBPF (Extended Berkeley Packet Filter) probe technology, event capture is triggered by attaching custom probe programs targeting system call entry and exit points. The capture triggering strategy employs a two-layer mechanism of "kernel-level basic capture and application-level dynamic filtering" to ensure that only truly necessary events are collected. This includes: the kernel layer capturing only system call events from the selected system call type filter list based on the target process in the process filter list; and the application layer further enabling or disabling the capture of low-priority events in real time based on system load. Simultaneously, the capture program skips clearly meaningless system call events with empty parameters or return values ​​explicitly indicating that the call was not executed (e.g., a return value of -ENOENT indicates that the file does not exist), further reducing the overhead of collecting and processing invalid data.

[0035] Furthermore, the captured system call events are encapsulated in a structured manner and transformed into structured event objects with unified fields and standardized resource identifiers.

[0036] Specifically, for each captured system call event, the core information extracted includes: process information, call information, resource information, time information, and return information.

[0037] The process information includes: process identifier (PID), parent process identifier (PPID), process name, operating user identifier, and process start timestamp; call information includes: system call function name and system call number; resource information is divided into two categories according to the system call type: resource information for file operation events includes: file path and file inode number; resource information for network communication events includes: network socket and 5-tuple information (source IP, source port, destination IP, destination port, protocol); time information includes: call timestamp (accurate to microseconds) and call duration; return information includes: return code and return result description.

[0038] Using the attribute names in the core information as keys and the attribute values ​​as values, a unified key-value pair format is encapsulated to generate a structured system call event object. The event ID is then combined with the process identifier in the process information, the call timestamp in the time information, and the system call number in the call information to form a globally unique event ID.

[0039] Taking a file open operation triggered by the target application app_server (PID=8245) as an example, the extracted information is as follows: process information (PID=8245, PPID=1, process name=app_server, operating user=app_user), call information (function name=open, call number=2), resource information (file path= / data / sensitive.txt, inode=4729381), time information (call timestamp=16999999999999μs, duration=10μs), and return information (return code=0, result description=success). The combined event ID is 8245_1699999999999_2.

[0040] Furthermore, the resource information for both types of events is standardized to ensure consistency in subsequent resource dimension associations.

[0041] It should be noted that the standardized handling of file paths in file operation events includes: For system call events such as open, openat, creat, and unlink that directly carry path parameters, if the file path is a relative path, it is combined with the process's current working directory (obtained by reading / proc / [PID] / cwd) to form an absolute path, and redundant path symbols (such as ". / " and ".. / ") are cleaned up. For system call events such as write, read, and close that operate on file descriptors (fd), since the kernel layer can only capture the process identifier (PID) and the file descriptor (fd), the application layer processes them by resolving the absolute path from the symbolic link / proc / [PID] / fd / [FD]. For standard input (fd=0), standard output (fd=1), and standard error (fd=2), if they are not redirected, they are uniformly marked as / dev / stdin, / dev / stdout, and / dev / stderr; if they are redirected, the resolved real absolute path is used. If the target process has exited during resolution, causing the file descriptor (fd) to be unable to be resolved through the / proc mapping, it is uniformly marked as [resolve_fail:PID-FD], and the inode number is preserved (if it exists). For resources without a physical path, such as anonymous file descriptors, pipes, and network sockets, they are labeled as anon:[inode], pipe:[inode], and socket:[inode], respectively, according to their type.

[0042] It should be noted that the standardized processing of network 5-tuple information in network communication events includes: For system call events based on file descriptors (fd), such as socket, connect, bind, and accept, the kernel layer only captures the process identifier (PID) and the file descriptor (fd). When processing at the application layer, the kernel layer obtains the socket's inode number (in the format socket:[inode]) by reading the symbolic link / proc / [PID] / fd / [FD]. Then, using this inode number as an index, the kernel searches for the complete 5-tuple information in the virtual files / proc / net / tcp, / proc / net / tcp6, / proc / net / udp, and / proc / net / udp6.

[0043] The resource information after the above standardization process serves as the resource identifier: the resource identifier for file operation events is the standardized file path and inode number; the resource identifier for network communication events is the standardized network 5-tuple information; and the resource identifier for anonymous resources without a physical path is the type tag plus the inode number.

[0044] S2. For the captured system call events, perform process-dimensional association based on process identifier, time-dimensional association based on time window, and resource-dimensional association based on the resources operated by the system call events, and integrate them to obtain multiple system call sequences.

[0045] This step involves real-time correlation of captured system call events across three dimensions: process, time, and resources. This correlation integrates discrete low-level system call events into a structured system call sequence. The correlation across these three dimensions is not executed sequentially, but rather operates in an incremental, real-time collaborative manner: each time a new system call event is captured, its attributes are determined in real time, and the correlation yields the system call sequence.

[0046] It should be noted that the purpose of process-level association is to bring system call events belonging to the same application but generated by different processes or threads into a unified context, avoiding behavior fragmentation caused by process forking. Process-level association based on process identifiers includes: obtaining process information of captured system call events, and mounting the captured process information to the process tree based on the process identifier and parent process identifier in the process information.

[0047] The process tree is apexed by the root process of the target application, which is the target application process specified in the process filter list in the monitoring configuration, such as app_server (PID=8245).

[0048] During mounting, if the current process's PPID points to an existing process in the process tree, the current process is mounted as a child node of that process. If the PPID is not yet in the process tree, the process is traced up the parent process chain until it connects to an existing process tree node or the root process. For example, when an event with PID=8245 is captured, 8245 is the root process. When an event with PID=5678 and PPID=8245 is subsequently captured, the root process is found through PPID=8245, and the process with PID=5678 is mounted under the root process with PID=8245. Thus, system call events of the root process and all its child and grandchild processes are integrated into the same behavioral context.

[0049] It should be noted that during the target application's operation, the liveness status of processes in the process tree is monitored by listening for process exit events and using a polling mechanism. Processes that have exited or are in a zombie state are marked as invalid and removed from the process tree to avoid confusion with newly reused processes using the same PID. This removal operation does not change the attribution of events generated by the process before its invalidation in the behavioral chain; it only affects the mounting of subsequent new events.

[0050] Specifically, the process exit event is monitored by listening for exit and exit_group system call events through a custom eBPF probe; the polling mechanism detects process exits in real time by periodically (e.g., every 3 seconds) checking the process directory information in the / proc virtual file system.

[0051] After defining the context scope at the process dimension, the time dimension association is used to segment events on the timeline, grouping events that are highly clustered in the same application context and in time into continuous behavior segments, while separating events that are significantly distant in time into different behavior segments.

[0052] Specifically, time-dimensional correlation based on time windows includes: For system call events that are associated at the process level, based on a preset time window, system call events with call timestamps within the same time window are divided into the same continuous behavior segment. At the same time, based on a preset cross-window tolerance threshold, system call events that meet the conditions of having the same resource identifier and call timestamp interval within the cross-window tolerance threshold are divided into the same continuous behavior segment.

[0053] It should be noted that the length of the time window is configured based on the application's behavior characteristics; for example, it is set to 100ms. The time window uses a non-overlapping sliding mode, with the window step size consistent with the window size, ensuring that each event clearly belongs to a unique behavior segment. The cross-window tolerance threshold is used to avoid association breaks caused by accidental cutting of window boundaries; the default value is 50% of the time window size, and it is configurable. When two system call events operate on the same resource identifier (i.e., operate on the same resource), and the interval between their call timestamps is within the cross-window tolerance threshold, they will be forced into the same continuous behavior segment, even if they would normally be classified into two adjacent behavior segments according to the time window. For example, if a process performs an open operation at the end of a time window, and then performs a write operation on the same file at the beginning of the next time window 40ms later, although the call timestamps of the two events belong to different time windows, they are classified into the same continuous behavior segment because they operate on the same resource and the 40ms interval is within the 50ms cross-window tolerance threshold. Conversely, if two operations on the same resource are separated by several seconds or even longer, far exceeding the cross-window tolerance threshold, they are classified as different consecutive behavior segments and regarded as two independent behavior executions.

[0054] By combining time windows with cross-window tolerance thresholds, the time dimension association in this step effectively avoids excessively linking unrelated behavioral fragments together while ensuring the continuity of behavioral sequence.

[0055] Furthermore, through process-dimensional and time-dimensional association, system call events are confined to a defined process context and segmented into continuous "behavioral fragments" based on time. The role of resource-dimensional association is to aggregate scattered events into an ordered sequence of system calls at the resource granularity according to the resource identifier operated by the system call event within each continuous behavioral fragment.

[0056] Specifically, resource-dimensional association is performed based on the resources operated by system call events, including: extracting the resource identifiers operated by each system call event within each continuous behavior segment, and associating system call events with the same resource identifiers into a system call sequence according to the order of the call timestamps.

[0057] For example, within the same continuous action segment, if there are three events—open, read, and close—that operate on the file / data / sensitive.txt (inode=4729381), and they occur out of time, they are arranged in chronological order as a system call sequence [open, read, close]. This continuous action segment also includes the connection event (connect) and data transmission event (sendto) for network socket fd=5 corresponding to 203.0.113.10:80, which are also arranged in chronological order as a sequence [connect, sendto]. Through this aggregation behavior, the originally discrete low-level calls are combined into a system call sequence with operational semantics.

[0058] During real-time processing, discrete system call events are transformed into multiple system call sequences with clear attribution, temporal order, and resource aggregation through the progressive association of process, time, and resources. These system call sequences do not wait indefinitely for new system call events to join; instead, they trigger subsequent behavior matching upon meeting any closure condition.

[0059] It should be noted that the closure conditions include: capturing the corresponding resource's shutdown system call event (such as close, shutdown), the arrival of the time window boundary, and detecting that the same process initiates a new operation cycle on the same resource.

[0060] S3. Perform precise matching of each system call sequence with the preset atomic behavior rules to obtain the behavior type of the successfully matched system call sequence; perform feature matching of the unmatched system call sequences with historical behavior data to obtain the corresponding behavior type; output structured behavior data based on each system call sequence and its behavior type.

[0061] It should be noted that before performing precise matching and feature matching in step S3, the duplicate system call events triggered repeatedly in each system call sequence are deduplicated, and only the corresponding first event is retained and marked with the number of repeated triggers, so as to reduce the redundancy of subsequent matching calculations.

[0062] For example, the original system call sequence is [open, write, write, write, close], and the deduplicated system call sequence is [open, write(N=3), close]. Deduplication preserves the complete semantics of the behavior while compressing the sequence length, thus improving the hit rate of subsequent exact matching and the computational efficiency of feature matching.

[0063] It should be noted that each deduplicated system call sequence is first precisely matched against preset atomic behavior rules. These preset atomic behavior rules cover multiple operation categories, each including various behavior types and their corresponding system call sequence patterns. The operation categories include: file operations, process management, memory management, network communication, device and driver control, clock and timer operations, signal processing, security and permissions, and debugging and performance analysis.

[0064] For example, the system call sequence pattern corresponding to the "file write" behavior in the file operation class is: [open, write, close], the system call sequence pattern corresponding to the "file read" behavior is: [open, read, close], and the system call sequence pattern corresponding to the "initiate network connection and send data" behavior in the network communication class is: [socket, connect, sendto].

[0065] During exact matching, the parameters and resource information are removed from the deduplicated system call sequence to obtain the system call name sequence to be matched. This sequence is then compared with the system call sequence pattern in the atomic behavior rules. If they are completely identical, the exact match is successful.

[0066] For example, by removing the parameters from the deduplicated system call sequence [open, write(N=3), close], the system call name sequence [open, write, close] is obtained. If it is completely consistent with the system call sequence pattern corresponding to the "file write" behavior in the preset atomic behavior rules, then the behavior type of the system call sequence is directly determined to be "file write".

[0067] Preferably, to achieve fast matching with O(1) time complexity, all preset atomic behavior rules are loaded into memory and stored as a hash table structure when the target application starts. The key of the hash table is the system call sequence pattern, and the value is the behavior type. Chaining is used to resolve hash collisions. Through precise matching, most common and known system call patterns can be quickly identified without additional computational overhead, ensuring the overall real-time performance of the system.

[0068] Furthermore, for system call sequences that do not match any atomic behavior rules, an adaptive feature matching algorithm based on historical behavior data is used to determine their corresponding behavior type.

[0069] First, features of the unmatched system call sequences are extracted to construct a multi-dimensional feature vector.

[0070] It should be noted that the multidimensional feature vector is constructed through the following steps: ① Use the time fingerprinting method to extract sequence features from the system call sequence.

[0071] Specifically, the system call sequence is divided into binary time units of adjacent calls in chronological order. For example, the set of binary time units for the system call sequence [open, read, close] is {<open, read> ,<read, close> Specifically, for a system call sequence of length 1, the system call name is used directly as the unit to be calculated.

[0072] For each binary time unit, a CRC32 hash is performed to generate a 32-bit unsigned integer hash value. Statistical calculations, such as arithmetic mean, are then performed on all the obtained hash values ​​to obtain the original feature value. After Min-Max normalization, the original feature value is mapped to the [0,1] interval to obtain the final sequence feature. .

[0073] ② The resources operated by system call events in the system call sequence are standardized, and the resulting resource identifiers are hashed and normalized to obtain resource characteristics.

[0074] Specifically, the resource identifier is subjected to CRC32 hash calculation to generate a 32-bit unsigned integer hash value, which is then mapped to the [0,1] interval through Min-Max normalization to obtain the resource characteristics. .

[0075] ③ Discretize the timestamp intervals between system call events in the system call sequence, perform statistical calculations on all the discretized values, and then normalize them to obtain the time interval characteristics. .

[0076] Specifically, based on the timestamps of each system call event, the timestamp interval between system call events is calculated and discretized into fixed intervals. For example, the intervals [0, 10ms), [10ms, 50ms), [50ms, 100ms), [100ms, 500ms), and [500ms, +∞) are mapped to discrete values ​​of 1, 2, 3, 4, and 5 respectively. Then, the average value is calculated for all discrete values, and the average value is normalized to the [0, 1] interval using Min-Max normalization to obtain the time interval feature. For sequences that have undergone deduplication, the timestamp interval is calculated based on the retained events; for system call sequences of length 1, the time interval feature is directly set to 0. This processing method unifies the time interval feature of sequences of different lengths into a single scalar, ensuring that the dimension of the feature vector is fixed and comparable.

[0077] ④ After weighting the sequence features, resource features, and time interval features with their respective preset weights, they are combined to obtain a multidimensional feature vector.

[0078] The feature values ​​of the three dimensions are assigned preset weights and then combined in a weighted manner to construct a three-dimensional feature vector. The weight allocation follows the priority principle of "sequence features > resource features > time interval features," for example, the weight value is: sequence feature weight. Resource feature weights Time interval feature weights The weighted eigenvectors The format is: , Where T represents the transpose operation.

[0079] Then, based on the multidimensional feature vector, the K nearest neighbor algorithm is used to find the K most similar behavior data in the historical behavior data; the behavior type that appears most frequently in the most similar behavior data and exceeds the preset proportion threshold is taken as the corresponding behavior type.

[0080] It should be noted that the historical behavior data is a sequence of system calls whose behavior types have been determined in each association analysis. It is stored in the historical sample library, and each piece of historical behavior data has been constructed into a three-dimensional feature vector in the same way as described above.

[0081] Finding similar behavioral data in historical behavioral data involves calculating the similarity between the feature vectors of system call sequences that did not match precisely and the feature vectors of each historical behavioral data. The Manhattan distance (the sum of the absolute values ​​of the differences between the components of each dimension) is used as the similarity measure, and the smaller the distance, the more similar the behaviors are.

[0082] Furthermore, select the top-K most similar behavioral data (K is 5 by default, but can be configured to odd numbers such as 3, 7, 9), and calculate the occurrence ratio of each behavioral type in these K most similar behavioral data. The behavioral type with the highest occurrence ratio that exceeds a preset ratio threshold (e.g., 60% by default, configurable) is determined as the behavioral type corresponding to the unmatched sequence.

[0083] For example, for a system call sequence [read, unlink] that failed to match, if four out of the five similar behavior data found are of the behavior type "read and delete file" (accounting for 80%, exceeding the 60% threshold), then it is identified as the behavior type of the sequence. If the proportion of all behavior types is lower than the proportion threshold, then the feature matching also failed, and the sequence is marked as an unidentified behavior and recorded in the log.

[0084] It should be noted that the historical sample database has a capacity limit (e.g., a maximum capacity of 50MB and a maximum number of samples of 10,000). It adopts an incremental update and LRU expiration constraint management strategy: when the sample database reaches the capacity limit, samples that have expired and have the lowest access frequency are prioritized for elimination to ensure the controllability of storage resources and the efficiency and stability of K-nearest neighbor calculation.

[0085] Compared to existing technologies, this step employs a hierarchical behavior aggregation mechanism that combines precise matching based on predefined rules with feature matching using the K-nearest neighbor algorithm. This effectively addresses the problems of insufficient coverage due to relying solely on rule matching or poor interpretability due to relying solely on machine learning in traditional methods. The method in this step ensures rapid identification of common, known behaviors while effectively classifying boundary variations of predefined rules through feature matching. As historical behavior samples accumulate during system operation, the matching accuracy of the K-nearest neighbor algorithm will gradually improve.

[0086] Once the behavior type of the system call sequence is determined through exact matching or feature matching, structured behavior data is generated and output by combining the information of the continuous behavior segment and the context information associated with the process dimension.

[0087] Behavioral data includes attributes such as behavior type, associated process tree information, resource identifier operated on, start and end time of behavior, behavior status (success or failure, determined by the return code of events in the sequence), and a list of associated system call event IDs.

[0088] For example, the structured data of the "file read" behavior atom is: behavior type = file read, operating user = app_user (UID = 1001), associated process = app_server (PID = 8245), operated resource = / data / sensitive.txt, execution time = 16999999999999μs to 1700000000090μs, status = success, associated event ID = [8245_1699999999999_2,8245_1699999999999_5,8245_1699999999999_8].

[0089] It should be noted that the method in this embodiment further includes: dynamically optimizing the time window size and cross-window tolerance threshold in the time dimension association in step S2 based on the matching result of step S3.

[0090] Specifically, the exact match hit rate, the percentage of unidentified behaviors, and the system CPU utilization are periodically (default 5 seconds, configurable) calculated for each period. The exact match hit rate represents the proportion of sequences that successfully match the atomic behavior rules in the cache to the total number of sequences, reflecting the reuse effect of the caching mechanism. The percentage of unidentified behaviors represents the proportion of sequences that fail to match either the exact match or the feature match to the total number of sequences, reflecting the adaptability of the current event association granularity.

[0091] When the proportion of unidentified behaviors exceeds the preset first threshold (default 10%) or the exact match hit rate is lower than the preset second threshold (default 70%), it indicates that the current event association granularity may not be suitable for the application behavior characteristics, making it difficult to match the sequence pattern with the preset rules. The time window is automatically narrowed and the cross-window tolerance threshold is reduced to produce more accurate behavior fragments and improve the matching accuracy.

[0092] Specifically, the time window is gradually reduced in preset steps (e.g., 10% of the current window size), while the cross-window tolerance threshold is reduced proportionally. For example, if the current time window is 100ms and the cross-window tolerance threshold is 50ms, and the proportion of unidentified behaviors continues to exceed the limit, the time window is reduced to 90ms and the cross-window tolerance threshold is lowered to 45ms; if the situation still does not improve, it is further reduced to 81ms and the cross-window tolerance threshold to 40.5ms, and so on, until the indicator returns to within the threshold. To ensure system stability, a lower limit for the time window is set (e.g., 20ms) to avoid excessive fragmentation of behavior segments due to excessive reduction.

[0093] When the system CPU utilization exceeds the preset load threshold (default 8%), it indicates that the system performance burden is heavy. At this time, if low-priority events have been removed after executing the dynamic adjustment filtering rules in step S1, but the CPU utilization still exceeds the limit, parameter adjustment is triggered: automatically expanding the time window and increasing the cross-window tolerance threshold to reduce the associated computational overhead and prioritize application performance.

[0094] Specifically, the time window is gradually expanded in preset steps, while the cross-window tolerance threshold is increased simultaneously. For example, if the current time window is 100ms and the cross-window tolerance threshold is 50ms, and the CPU utilization exceeds the limit, the time window is expanded to 110ms and the cross-window tolerance threshold is increased to 55ms; if it still exceeds the limit, it is further expanded to 121ms and the cross-window tolerance threshold is increased to 60.5ms, until the CPU utilization falls back below the threshold. To ensure the reasonableness of the correlation, an upper limit for the time window is set (e.g., 500ms) to prevent the window from being too large, causing obviously unrelated behaviors to be incorrectly aggregated.

[0095] The dynamic optimization mechanism of the aforementioned correlation parameters facilitates continuous adaptation based on actual load and recognition results during operation, achieving a balance between accuracy and performance.

[0096] During implementation, the structured behavioral data output further supports behavioral visualization and compliance auditing of upper-layer applications.

[0097] For example, compliance auditing includes: sensitive file compliance auditing, network access compliance auditing, and process permission compliance auditing. Sensitive file compliance auditing monitors file operation data within behavioral data; when an unauthorized user is detected performing operations on a sensitive file, a real-time alarm is triggered. Network access compliance auditing monitors network communication data within behavioral data, performing compliance matching on data with the behavior type "network connection" and "network data transmission / reception"; if outbound network connections to untrusted addresses are detected, a violation alarm is immediately triggered or real-time blocking is implemented. Process permission compliance auditing monitors whether process management data within structured behavioral data conforms to filtering rules; if an unfamiliar process attempts to access protected resources, it is determined as unauthorized behavior and recorded.

[0098] Compared with existing technologies, this embodiment provides a system call analysis method based on multi-dimensional association. It employs a dual filtering mechanism of static preset filtering rules and dynamic adaptive adjustment of filtering rules to achieve dynamic selective capture of system call events. It automatically filters non-core events under high load and resumes capture under low load, effectively avoiding excessive CPU and memory resource consumption caused by full capture, keeping system performance loss within a controllable range, and facilitating stable adaptation to long-term deployment requirements in production environments. Through collaborative association of process, time, and resource dimensions, discrete system call events are integrated into a resource-aggregated, time-ordered system call sequence, solving the problems of behavior fragmentation and association misjudgment caused by traditional single-dimensional association, significantly improving the integrity and accuracy of application behavior chains. Through a dual-path behavior recognition mechanism combining precise matching of preset atomic behavior rules and feature matching of the K-nearest neighbor algorithm, it ensures rapid and accurate identification of common known behaviors while adaptively classifying system call sequences not covered by preset rules, improving the coverage and robustness of behavior type recognition, and achieving accurate and real-time analysis of discrete system call events.

[0099] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0100] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A system call analysis method based on multi-dimensional correlation, characterized in that, Includes the following steps: Based on preset filtering rules, system call events generated by the target application are filtered and captured, and the filtering rules are dynamically adjusted by real-time detection of system load status. For captured system call events, process-dimensional association is performed based on process identifier, time-dimensional association is performed based on time window, and resource-dimensional association is performed based on the resources operated by the system call events, and multiple system call sequences are integrated. Each system call sequence is precisely matched with preset atomic behavior rules to obtain the behavior type of the successfully matched system call sequence; The sequence of unmatched system calls is matched with historical behavior data to obtain the corresponding behavior type. Based on each system call sequence and its behavior type, output structured behavior data.

2. The system call analysis method based on multi-dimensional association according to claim 1, characterized in that, The step of dynamically adjusting the filtering rules by real-time detection of system load status includes: The system CPU utilization is acquired in real time. When the system CPU utilization exceeds a preset load threshold, low-priority system call events in the filtering rules are dynamically removed. When the system CPU utilization is lower than the preset load threshold, the capture of the removed low-priority system call events is gradually restored according to a preset recovery rate.

3. The system call analysis method based on multi-dimensional correlation according to claim 1, characterized in that, The process-dimensional association based on process identifiers includes: Obtain process information of captured system call events, and mount the captured process information to the process tree based on the process identifier and parent process identifier in the process information.

4. The system call analysis method based on multi-dimensional association according to claim 3, characterized in that, The process tree is centered on the root process of the target application. It monitors the survival status of processes in the process tree by listening to process exit events and using a polling mechanism. Processes that have exited or are in a zombie state are marked as invalid and removed from the process tree.

5. The system call analysis method based on multi-dimensional correlation according to claim 1 or 3, characterized in that, The time-dimensional correlation based on time windows includes: For system call events that are associated at the process level, based on a preset time window, system call events with call timestamps within the same time window are divided into the same continuous behavior segment; at the same time, based on a preset cross-window tolerance threshold, system call events that meet the conditions of having the same resource identifier and call timestamp interval within the cross-window tolerance threshold are divided into the same continuous behavior segment.

6. The system call analysis method based on multi-dimensional association according to claim 5, characterized in that, The resource-dimensional association based on the resources operated on by system call events includes: Extract the resource identifier operated by each system call event within each consecutive behavior segment, and associate system call events with the same resource identifier into a system call sequence according to the order of the call timestamp.

7. The system call analysis method based on multi-dimensional correlation according to claim 1, characterized in that, Before performing precise matching and feature matching, the duplicate system call events that are repeatedly triggered in each system call sequence are deduplicated, and only the corresponding first event is retained and marked with the number of times it is repeatedly triggered.

8. The system call analysis method based on multi-dimensional correlation according to claim 7, characterized in that, The step of performing feature matching between the unmatched system call sequence and historical behavior data to obtain the corresponding behavior type includes: Extract features from the unmatched system call sequence and construct a multidimensional feature vector; Based on the multidimensional feature vector, the K nearest neighbor algorithm is used to find the K most similar behavior data in the historical behavior data; the behavior type that appears most frequently and exceeds a preset proportion threshold among the K most similar behavior data is taken as the corresponding behavior type.

9. The system call analysis method based on multi-dimensional correlation according to claim 8, characterized in that, The step of extracting features from the unmatched system call sequence and constructing a multi-dimensional feature vector includes: The time-series fingerprinting method is used to extract sequence features from the system call sequence; The system call events in the system call sequence are standardized, and the resulting resource identifiers are hashed and normalized to obtain resource characteristics. The call timestamp intervals between system call events in the system call sequence are discretized, and all discretized values ​​are statistically calculated and normalized to obtain the time interval characteristics. The sequence features, resource features, and time interval features are weighted by their respective preset weights and then combined to obtain a multidimensional feature vector.

10. The system call analysis method based on multi-dimensional association according to claim 9, characterized in that, The method of extracting sequence features from the system call sequence using a time-series fingerprinting technique includes: The system call sequence is split into binary time units of adjacent calls in chronological order. A hash calculation is performed on each binary time unit. All hash values ​​are statistically calculated and normalized to obtain the sequence characteristics.

Images