Heterogeneous security event aggregation attribution method based on alarm confidence

Abstract

The present application relates to the cross technical field of computer system security and graph computing, and provides a heterogeneous security event aggregation and attribution method based on alarm confidence. In order to solve the problem of how to realize accurate aggregation of security events belonging to the same attack activity and complete restoration of attack causal chain without relying on the semantics of heterogeneous alarms, the method continuously acquires system call event streams, constructs a security primitive causal graph with processes and operation objects as nodes and operation behaviors as directed edges, anchors heterogeneous security alarms as event probes to corresponding process nodes, aggregates according to the connected components of the nodes where the anchored probes are located within a preset time window, and performs root cause graph traversal on the causal subgraph corresponding to the aggregated security events to generate a complete attack causal chain, thereby realizing deterministic aggregation and accurate tracing based on system underlying causal behavior, and significantly improving the accuracy of security event aggregation and the completeness of attack tracing chain.

Description

Technical Field

[0001] This invention relates to the interdisciplinary field of computer system security and graph computing, particularly to operating system-level behavior auditing and causal graph analysis technology, specifically to a heterogeneous security event aggregation and attribution method based on alarm confidence. Background Technology

[0002] Heterogeneous security incident aggregation and attribution refers to the process of associating and integrating alarm information from different security detection devices with different formats and semantics to reconstruct the complete attack chain. It is a core foundational capability for modern security operations centers to achieve efficient threat response.

[0003] Taking a multi-stage attack scenario on an enterprise network as an example: Attackers first establish an initial foothold on terminal A through phishing emails, then exploit system vulnerabilities to escalate privileges and create a malicious process. Using this process as a springboard, they move laterally to server B, ultimately accessing database C to steal sensitive data. During this process, the endpoint detection system on terminal A generates an abnormal process alert, the network intrusion detection system detects lateral movement traffic, and the server's database auditing system captures abnormal query operations. Upon receiving these heterogeneous alerts, the security operations center needs to aggregate them into a single attack event and reconstruct the complete attack path from terminal A to database C. However, alerts generated by different security devices are independent in terms of data format, field definitions, and semantic descriptions, lacking a unified analytical benchmark.

[0004] Traditional technologies typically employ the following approaches: First, rule-based association analysis, where security experts write association rules based on prior knowledge to merge alarms that meet preset conditions (such as the same source IP address or similar time windows); Second, similarity aggregation methods based on statistics or machine learning, which convert alarm texts into vector representations and group them by calculating the cosine similarity between vectors or applying clustering algorithms; Third, semantic reasoning methods based on knowledge graphs, which construct knowledge graphs containing security domain ontology such as attack patterns and asset relationships, and use predefined relationships between entities to deduce alarm associations.

[0005] However, the aforementioned traditional techniques have a fundamental technical flaw: the accuracy of the aggregation results is limited by the quality and completeness of the information carried by the alarm itself, leading to false aggregation and missed aggregation, and making it impossible to accurately reconstruct the causal chain of the attack.

[0006] The core reason for this deficiency lies in the fact that all methods, whether rule-based, statistical, or knowledge graph-based, rely solely on "alarms" generated by security detection equipment as the sole source of information and analytical benchmark. Alarms are "secondary processed information" resulting from the interpretation, compression, and encapsulation of underlying system activities by various security sensors, inevitably leading to information loss, semantic ambiguity, and misjudgment. Typically, technological improvements focus on optimizing the processing of alarm information, such as designing more complex association rules, training larger-scale deep learning models, and constructing more comprehensive security domain ontologies. However, this approach of "processing alarms at the alarm level" essentially still involves association analysis based on distorted information, failing to fundamentally overcome the constraint of alarm information quality on aggregation accuracy.

[0007] Therefore, how to accurately aggregate security events belonging to the same attack activity and fully reconstruct the attack causal chain without relying on the semantics of heterogeneous alerts themselves has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0008] To address the aforementioned technical problems, this invention provides a heterogeneous security event aggregation and attribution method based on alarm confidence. It constructs a causal graph model with system-level call events as primitives as a unified analysis benchmark, projects heterogeneous alarms as probes onto this causal graph, and achieves aggregation by calculating the causal connectivity of the alarm probes on the graph. Source tracing is then completed based on root cause traversal of the aggregated subgraph. This fundamentally eliminates the constraint of alarm information distortion on aggregation accuracy, enabling deterministic aggregation and accurate source tracing based on system-level causal behavior without relying on the semantics of the alarms themselves. This significantly improves the accuracy of security event aggregation and the completeness of the attack source tracing chain.

[0009] To address the aforementioned technical problems, this invention provides the following technical solution: a heterogeneous security event aggregation and attribution method based on alarm confidence, comprising: continuously acquiring and processing system call event streams from a host; constructing a security primitive causal graph using the process executing the system call as a node, the object being operated on by the system call as a node, and the operation behavior generated between the processes through system calls as directed edges, to represent the operation dependencies between processes across the entire host; receiving N heterogeneous security alarms, extracting the process identifier and alarm timestamp used for locating in the security primitive causal graph from each heterogeneous security alarm, and then... A security alarm is constructed as an event probe and anchored to a corresponding process node with the same process identifier and alarm timestamp in the security primitive causal graph, where N is a natural number. The set of process nodes pointed to by all anchored event probes within a preset time window is obtained. Each connected component of the process node set is determined in the security primitive causal graph, and all heterogeneous security alarms corresponding to the event probes belonging to the same connected component are aggregated into a single security event. Root cause graph traversal is performed on the causal subgraph of the connected component corresponding to the security event to generate a complete attack causal chain from the attack source to the attack target.

[0010] As a preferred embodiment of the heterogeneous security event aggregation and attribution method based on alarm confidence described in this invention, extracting process identifiers and alarm timestamps for locating events in the security primitive causal graph from each heterogeneous security alarm includes: parsing the original data packet of the heterogeneous security alarm to determine whether it contains a process identifier field; if it does, directly extracting the process identifier from the original data packet; if it does not, extracting network session quintuple information from the heterogeneous security alarm, and based on the network session quintuple information and the alarm timestamp, backtracking and querying the process node associated with the corresponding network session in the security primitive causal graph, and determining the identifier of the queried process node as the process identifier corresponding to the heterogeneous security alarm.

[0011] Beneficial Effects: The solution implemented in this invention, by constructing a security primitive causal graph with system call events as primitives, firstly achieves the modeling of inter-process operation dependencies across the entire host as a unified and objective causal graph benchmark, providing a low-level behavioral reference for the aggregation and attribution of heterogeneous alarms that does not depend on the semantics of the alarms themselves; based on this, by anchoring heterogeneous security alarms as event probes to the corresponding process nodes in the security primitive causal graph, it further achieves the unified projection of alarms from different security devices with different formats and semantics onto the same causal coordinate system, eliminating information mapping barriers caused by differences in data format, field definitions, and semantic descriptions of heterogeneous alarms; on this basis, by calculating the connected components of the set of process nodes where the anchored event probes are located in the security primitive causal graph, alarms belonging to the same connected component are aggregated into a single security primitive causal graph. This event achieves deterministic aggregation based on objective causal behavior at the system's underlying level. Unlike traditional technologies that rely on approximate aggregation methods based on alarm text similarity or prior association rules, it fundamentally eliminates mis-aggregation and omissions caused by alarm information distortion and semantic ambiguity. Furthermore, this aggregation based on the causal connectivity at the system's underlying level essentially constructs a novel "alarm confidence" assessment method based on objective behavioral causality. It reconstructs the incomparable, isolated confidence that relies on the static scoring of the alarm itself in traditional technologies into a deterministic confidence based on the behavioral context and causal correlation strength of the alarm in the causal graph. Moreover, by performing root cause graph traversal on the causal subgraph corresponding to the aggregated security event, a complete attack causal chain from the attack source to the attack target is generated, achieving automated and conclusive reconstruction of the attack path.

[0012] Based on the interconnected effects described above, a four-stage closed-loop mechanism was constructed, consisting of "objective causal graph benchmark construction - heterogeneous alarm causal probe transformation - deterministic aggregation of connected components - root factor graph traversal and source tracing".

[0013] Therefore, unlike traditional technologies that "process alarms at the alarm level" and rely on the semantics of the alarms themselves and static confidence scores for correlation analysis, this invention projects heterogeneous alarms onto a security primitive causal graph and uses graph connectivity as the aggregation basis. This transforms the traditional model based on "approximate correlation of alarm semantics" into a model based on "deterministic aggregation of system behavior causality," and transforms the traditional model based on "isolated confidence scores of alarm self-ratings" into a model based on "deterministic confidence scores of causal behavioral context." Ultimately, this achieves accurate aggregation of security events belonging to the same attack activity and complete reconstruction of the attack causal chain without relying on the semantics of heterogeneous alarms themselves. This significantly improves the accuracy of security event aggregation, the completeness of the attack attribution chain, and the response efficiency of security operations. Attached Figure Description

[0014] Figure 1This is a flowchart illustrating the heterogeneous security event aggregation and attribution method based on alarm confidence provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of the first sub-process of the heterogeneous security event aggregation and attribution method based on alarm confidence provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the second sub-process of the heterogeneous security event aggregation and attribution method based on alarm confidence provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0015] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to specific examples. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0016] This invention provides a heterogeneous security event aggregation and attribution method based on alarm confidence. This method can be a security analysis engine hosted on a server or cloud platform, directly driving security operations applications across multiple dimensions, including but not limited to: First, in an enterprise security operations center, by aggregating multi-dimensional heterogeneous alarms into a unified security event and automatically generating a complete attack causal chain, it provides security analysts with a deterministic attack context, reducing average detection and response time from hours to minutes. Second, in an automated response orchestration system, by mapping the generated attack causal chain to response script parameters, it drives the security orchestration and automated response platform to perform precise blocking or isolation operations, achieving closed-loop automation from analysis to handling. Third, in threat tracing and forensic analysis scenarios, by restoring the complete attack causal chain, it provides operating system-level temporal evidence of attack behavior, providing technical support for security event review, accountability, and evidence fixation. Fourth, in security capability assessment and attack / defense drill scenarios, by post-event analysis of the aggregation and attribution results, it evaluates the coverage and vulnerabilities of the existing security detection system, providing data for security strategy optimization. This invention solves the technical challenges of deterministic aggregation of heterogeneous alarms and complete reconstruction of attack causal chains, providing reusable core data capabilities for cost reduction, efficiency improvement, and capability upgrade in enterprise security operations.

[0017] The following detailed description of some embodiments of the present invention is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0018] Example 1: A heterogeneous security event aggregation and attribution method based on alarm confidence.

[0019] In this embodiment, please refer to Figure 1 , Figure 1 This is a flowchart illustrating the heterogeneous security event aggregation and attribution method based on alarm confidence provided in an embodiment of the present invention. Figure 1 As shown, in this embodiment, the method can be applied to a security analysis engine, including the following steps S11-S14: S11: Continuously acquire and process the system call event stream from the host, using the process executing the system call as a node, the object operated by the system call as a node, and the operation behavior generated between the processes through the system call as directed edges, to construct a security primitive causal graph to represent the operation dependency relationship between processes across the entire host.

[0020] System call event stream: refers to a continuous sequence of events captured and output by the audit subsystem at the host operating system kernel level, recording the system call behavior initiated by processes. System calls are interfaces for user-mode programs to request kernel services, including process creation (such as fork, execve), file operations (such as open, write, read), and network connections (such as connect, sendto). Each event in the system call event stream carries the calling process identifier, the called object identifier, the operation type, and a precise timestamp of the event occurrence. Its collection can be implemented based on common operating system audit frameworks such as the Linux Audit subsystem, Windows ETW (EventTracing for Windows), or eBPF (extended Berkeley Packet Filter). In this invention, the system call event stream constitutes the data source of the security primitive causal graph, and its underlying nature and immutability provide an objective and reliable basis for causal analysis.

[0021] Security primitive cause-effect graph: This refers to a directed graph model built using operating system-level system call events as primitives to represent the operational dependencies between processes across the entire host through system calls. "Security primitives" refer to the lowest-level, indivisible system call operations captured by the operating system kernel auditing system, constituting all security events and attack behaviors. The security primitive cause-effect graph uses the process executing the system call as the process node, the object being operated on by the system call (such as a file, network endpoint, pipe, etc.) as the object node, and the operational behaviors generated between processes through system calls as directed edges, with the edge direction pointing from the calling process to the called object or target process. The security primitive cause-effect graph transforms the scattered and isolated system logs of traditional technologies into a global, structured, and computable behavioral dependency model, providing a unified and objective benchmark coordinate system for the aggregation and attribution of heterogeneous alerts.

[0022] The specific implementation of this step is as follows: First, the security analysis engine's data acquisition module continuously receives and parses system call event streams through lightweight audit probes deployed on various hosts. These audit probes, acting as user-space adapters for the kernel audit interface, are responsible for converting raw binary audit logs into structured event streams and transmitting them to the security analysis engine in real time via a secure channel. Each system call event in the system call event stream is encapsulated as a tuple containing the calling process's PID, the path or identifier of the called object (such as a file path or IP:Port), the operation type, and an event timestamp, with the timestamp accuracy reaching the millisecond level.

[0023] Secondly, the graph construction module of the security analysis engine processes each system call event in a streaming manner. For each system call event, the unique identifier of the calling process (which may be composed of the host ID, process PID, and process creation timestamp) is used as the source node identifier, and the unique identifier of the called object is used as the target node identifier. If the corresponding node does not yet exist in the security primitive causal graph, the node is created; node attributes may include the process executable file path, command-line arguments, user ID, etc. According to the operation type, a directed edge is established between the source node and the target node, and the operation type and event timestamp are recorded as attributes of the edge. The specific node creation and edge establishment process will be described in detail in the subsequent embodiment 2.

[0024] Then, the graph construction module continuously updates and persists the constructed security primitive causal graph to a graph database (such as JanusGraph or Amazon Neptune based on time-series graphs), and supports efficient time-window subgraph queries and traversals. As a unified graph model across the entire host, the security primitive causal graph explicitly reveals the control flow and data flow dependencies between processes caused by system calls, forming a traceable causal network.

[0025] It should be noted that the methods for collecting system call events mentioned above are not limited to those based on Linux Audit or ETW. In one example, eBPF technology can be used to directly capture system call events in the kernel. This reduces user-space data transmission overhead through efficient kernel-level filtering and aggregation, making it suitable for high-frequency system call scenarios. In another example, system call events of processes within a container can be obtained by monitoring the gRPC API interface during container runtime, making it suitable for cloud-native environments. Any technical means capable of acquiring the host system call event stream in real time falls within the scope of protection of this invention.

[0026] For example, taking a phishing attack on a company's office network as an example, the attacker tricked users into executing a malicious macro via email, creating a malicious process called malware.exe (PID 3301). This process then called execve to create a child process called cmd.exe (PID 3302), which connected to an external C2 server 203.0.113.10:443 via connect. An audit probe deployed on the host continuously outputs an event stream, such as event E1: malware.exe (PID 3301) - execve -> cmd.exe (PID 3302), time=T1; event E2: cmd.exe (PID 3302) - connect -> 203.0.113.10:443, time=T2. After parsing these events, the security analysis engine's graph construction module creates process nodes N1 (malware.exe) and N2 (cmd.exe), object node O1 (203.0.113.10:443), and establishes directed edges E1 (N1 -> N2, operation type: process creation, time T1) and E2 (N2 -> O1, operation type: network connection, time T2), and so on. This constructs a causal graph segment reflecting the security primitives' dependencies on malicious process operations.

[0027] In step S11, by continuously acquiring and processing the system call event stream, a globally unified security primitive causal graph is constructed, using processes and operation objects as nodes and the operation behaviors generated by system calls as directed edges. This transforms the scattered and static log records in traditional technologies into a dynamic and traceable system behavior causal model, providing a low-level objective reference system for heterogeneous alarm aggregation and attribution that does not rely on alarm semantics. This solves the problem of strong subjectivity and poor accuracy in alarm correlation caused by the lack of a global causal perspective.

[0028] S12: Receive N heterogeneous security alarms, extract the process identifier and alarm timestamp used for positioning in the security primitive causal graph from each heterogeneous security alarm, and anchor the heterogeneous security alarm as an event probe to the corresponding process node with the same process identifier and alarm timestamp in the security primitive causal graph, where N is a natural number.

[0029] Heterogeneous security alerts refer to security alerts generated by different types of security detection devices deployed in the network (such as Intrusion Detection Systems (IDS), Endpoint Detection and Response Systems (EDR), Web Application Firewalls (WAF), database auditing systems, etc.), with independent data formats, field definitions, and semantic descriptions. Each heterogeneous security alert typically includes, but is not limited to, fields such as alert type, source / destination IP address, port, process identifier (optional), alert timestamp, and detailed alert description. The name and semantics of the process identifier field can vary depending on the device; for example, EDR alerts typically include the process PID and name, while network IDS alerts typically only include the network session 5-tuple without process information.

[0030] Alarm timestamp: This refers to the specific time recorded in each security alarm, indicating the occurrence of the alarm event. Alarm timestamps are typically provided by the clock of the security device that generated the alarm, but their accuracy and synchronization may deviate from the event timestamps in the system call event stream. To ensure anchoring accuracy, in practice, the clocks of each host can be synchronized, for example, by using NTP or PTP protocols to keep the clocks of each node globally consistent with the security analysis engine.

[0031] Event probe: In this invention, an event probe is a logical entity that maps heterogeneous security alarms onto a security primitive causal graph. An event probe can carry the ID and type of the original alarm and, through the extracted process identifier and alarm timestamp, can be anchored to the corresponding time and process node in the security primitive causal graph. Its function is to mark the process node as associated with the current alarm event, rather than relying on the semantic content of the alarm itself. The semantics of the alarm are stripped away in this process, retaining only its spatiotemporal location information on the security primitive causal graph.

[0032] The specific implementation of this step is as follows: First, the alarm access module of the security analysis engine receives raw alarm streams from multiple heterogeneous security devices, i.e., multiple heterogeneous security alarms, which can be N heterogeneous security alarms, where N is a natural number. The security alarms are then parsed to extract information such as the alarm timestamp, source / destination IP, port, and host ID for each security alarm.

[0033] Secondly, the alarm anchoring module performs a process identifier extraction process for each security alarm. It parses the original data packet of the security alarm to determine if it directly contains a process identifier field (such as process PID, process name, or process path). If it does, the process identifier is directly extracted and combined with the host ID to generate a unique source node identifier pointed to by the security alarm; if it does not contain the process identifier, a backtracking query process based on the network session 5-tuple is performed to determine the associated process node. The specific hierarchical extraction and backtracking query mechanism will be detailed in the subsequent embodiment 4.

[0034] Then, the alarm anchoring module, based on the extracted process ID and alarm timestamp, queries the security primitive cause-effect graph for process nodes with the same process ID whose lifecycle covers the alarm timestamp. During the query, the graph database's indexing function can be used to quickly locate nodes using the process ID and alarm timestamp as conditions. If the location is successful, the security alarm is used as an event probe and anchored to that process node. This means that the security alarm ID and operation type are added to the graph database as a dynamic attribute of the node or associated with it through a temporary virtual edge, without changing the original cause-effect graph structure. If the location fails (e.g., the alarm timestamp is earlier than the process creation time or later than the process exit time), the security alarm is recorded as an unanchored alarm, awaiting further processing (such as manual auditing or retrying with an extended time window).

[0035] It should be noted that the positioning conditions for alarm anchoring mentioned above are not limited to precise timestamp matching. In one example, a certain time tolerance range (e.g., ±1 second) can be allowed because there may be transmission delays or clock deviations in alarm reporting time. Setting a time tolerance range improves the anchoring success rate and avoids missed anchoring due to minor time errors. In another example, when the same security alarm can be anchored to multiple candidate process nodes, uniqueness can be determined by combining other auxiliary information in the security alarm (e.g., the matching degree between alarm category and process type). Any method that can establish a reliable mapping relationship between security alarms and process nodes in the causal graph of security primitives falls within the protection scope of this invention.

[0036] For example, continuing the previous example, suppose the security analysis engine receives two heterogeneous security alerts: Security alert A comes from EDR, and its content may be "A malicious process malware.exe (PID3301) was detected performing suspicious operations," which may include the host ID and process PID3301, and the alert timestamp T1'; Security alert B comes from Network IDS, and its content may be "An internal network host was detected accessing a known malicious IP 203.0.113.10," which may include the host ID, the session 5-tuple (source IP, source port, destination IP 203.0.113.10, destination port 443, protocol TCP), and the alert timestamp T2'. For security alert A, the alert anchoring module directly extracts the process identifier PID3301 from its original message, combines it with the host ID, locates the node N1 (malware.exe) in the security primitive cause-effect graph, and anchors security alert A as event probe A to N1. For security alert B, since it does not contain a process identifier, the alert anchoring module extracts the network session quintuple and backtracks through the security primitive cause-effect graph to find the process node associated with the corresponding network session. Specifically, it finds the object node O1 through the destination IP and port, and then reverses to find the process node N2 (cmd.exe) connected to O1. Security alert B is then anchored to N2 as event probe B. Through this anchoring, two security alerts from different sources and with different formats are uniformly projected into the same security primitive cause-effect graph.

[0037] In step S12, process identifiers and alarm timestamps are extracted from heterogeneous security alarms, and security alarms are used as event probes to anchor to the security primitive causal graph. This transforms the scattered and semantically inconsistent security alarm information in traditional technologies into probe markers under a unified causal coordinate system. This eliminates the information mapping barriers caused by differences in data format and semantics between heterogeneous security alarms, and lays the data foundation for subsequent deterministic aggregation based on causal connectivity.

[0038] S13: Obtain the set of process nodes pointed to by all anchored event probes within a preset time window, determine each connected component of the process node set in the security primitive causal graph, and aggregate the heterogeneous security alarms corresponding to all event probes belonging to the same connected component into a single security event.

[0039] Connected components: a concept derived from graph theory, referring to the largest set of nodes in an undirected graph (or a directed graph transformed into an undirected one) that are connected by edges. In this invention, connected components are used to define a set of process nodes directly or indirectly related by causal edges in a security primitive causal graph. Since the anchored event probes point to several process nodes, if these nodes belong to the same connected component in the graph, it indicates that there is an objective causal dependency between them at the system's underlying level. Therefore, it can be highly confident that the corresponding security alerts belong to the same attack activity.

[0040] The specific implementation of this step is as follows: First, the aggregation module of the security analysis engine sets a sliding time window. The duration of the preset time window can be configured according to the actual needs of security operations, with a typical range of 1 minute to 30 minutes, for example, 5 minutes. Within this time window, the aggregation module obtains the set of process nodes pointed to by all anchored event probes.

[0041] Secondly, the aggregation module performs connected component analysis on the causal graph of security primitives in the graph database. Since the causal flow of an attack may occur in multiple sequences, and security alerts may only capture partial fragments, the directionality of edges can be ignored when calculating connected components, treating the original graph as an undirected graph. Specifically, parallel breadth-first search (BFS) or depth-first search (DFS) algorithms can be used to traverse the graph starting from each node in the process node set, marking visited nodes belonging to the process node set as the same connected component, repeating this process until all nodes are marked. Each connected component constitutes an aggregation candidate.

[0042] Then, the aggregation module aggregates all heterogeneous security alarms corresponding to event probes belonging to the same connected component into a single security event. During aggregation, a security event object is generated, recording its associated original alarm list, the process nodes and edges it contains, and the corresponding connected component causal subgraph. This connected component causal subgraph serves as the input for subsequent root cause traversal.

[0043] It should be noted that the implementation of the above-described connected component calculation is not limited to standard BFS / DFS. In one example, a label-based connected component algorithm can be used, suitable for distributed computing on very large-scale graphs, which divides connected components by iteratively propagating the minimum node ID between nodes. In another example, weighted edges can be introduced, assigning different weights to edges based on the credibility of system call operation types, and only considering connected components formed by edges with weights greater than a threshold to filter out noisy edges. Any graph computing algorithm that can divide nodes into sets of causal relationships based on the graph structure falls within the protection scope of this invention.

[0044] For example, continuing the previous example, assume that within a preset time window (e.g., 5 minutes), anchored event probes A and B point to process nodes N1 and N2, respectively. In the security primitive causal graph, N1 and N2 are connected by a directed edge E1 (process creation), and they are both connected to object node O1 (network connection edge E2). Therefore, N1 and N2 belong to the same connected component after ignoring the direction. The aggregation module aggregates security alarms A and B into a single security event SE-001, whose connected component causal subgraph contains nodes N1, N2, and O1, as well as edges E1 and E2.

[0045] Step S13 involves acquiring the set of process nodes with anchored event probes within a preset time window and performing deterministic aggregation based on the connected components of the graph. This transforms the subjective association based on alarm semantic similarity in traditional techniques into deterministic aggregation based on the objective causal behavior at the system's underlying level, fundamentally eliminating erroneous and missed aggregations caused by alarm information distortion and semantic ambiguity. This aggregation based on the causal connectivity of the system essentially reconstructs the connotation of "alarm confidence"—from an incomparable, isolated confidence that relies on the static scoring of the alarm itself to a deterministic confidence based on the behavioral context and causal correlation strength of the alarm in the causal graph of security primitives.

[0046] S14: Perform root cause graph traversal on the causal subgraph of the connected component corresponding to the security event to generate a complete attack causal chain from the attack source to the attack target.

[0047] The specific implementation of this step is as follows: First, the security analysis engine's tracing module obtains the causal subgraph of the security events generated by S13 and their corresponding connected components. The purpose of root cause graph traversal is to find the initial intrusion point (root cause node) of the attack and reconstruct the complete attack path sequence.

[0048] Secondly, the tracing module executes a root cause analysis algorithm on the causal subgraph of the connected components. The root cause analysis algorithm first identifies process nodes with an in-degree of zero in the causal subgraph and determines the process node with the earliest event timestamp as the root cause node. An in-degree of zero indicates that no other process node points to it within the causal subgraph, making it likely the starting point of the attack. If no process node with an in-degree of zero exists (e.g., all nodes in the attack chain have a parent node, but the parent node is outside the causal subgraph), the algorithm backtracks to the global security primitive causal graph to identify externally related nodes that are connected to nodes in the causal subgraph by directed edges but do not belong to the causal subgraph, and identifies nodes with suspicious operational behavior as root cause nodes. Specific root cause graph traversal strategies, external node backtracking, and suspicious operational behavior determination methods will be detailed in subsequent embodiments 7 and 8.

[0049] Then, starting from the identified root cause node, a depth-first traversal (DFS) is performed on the causal subgraph to generate a path sequence containing all anchored alarm nodes and key target nodes (such as the attacked database server or the tampered critical file) in the order of event timestamps. This path sequence is the complete attack causal chain from the attack source to the attack target. Each node on the attack causal chain and its edge attributes (such as operation type and timestamp) fully describe the temporal dependency of the attack behavior.

[0050] It should be noted that the path generation algorithm for root cause traversal described above is not limited to depth-first traversal. In one example, when multiple possible paths exist, the path with the simplest and most interpretable observation alarm can be selected as the optimal attack chain based on the minimum description length (MDL) principle, avoiding the introduction of redundant branches. In another example, an attack chain integrity score can be introduced to prioritize the output of the path covering the most tactical phases. Any graph traversal or path selection algorithm capable of extracting attack causal paths from causal subgraphs falls within the protection scope of this invention.

[0051] For example, following the previous example, regarding the causal subgraph of security event SE-001, the source tracing module examines process nodes N1 (malware.exe) and N2 (cmd.exe). N1 has an in-degree of zero (its parent process may be outside the causal subgraph), and its timestamp T1 is the earliest; therefore, N1 is determined to be the root cause node. Then, a DFS traversal is performed starting from N1 to generate the attack causal chain: N1 (malware.exe, process creation, T1) → N2 (cmd.exe, network connection, T2) → O1 (malicious IP, time T2). This attack causal chain fully describes the attack process from the creation of the malicious process to connecting to the C2 server.

[0052] In step S14, by performing root cause graph traversal on the causal subgraph corresponding to the aggregated security event, the fragmented tracing based on human experience in traditional technology is transformed into automated, deterministic tracing based on security primitive causal graph traversal. This achieves a complete reconstruction of the attack path and provides conclusive technical evidence for security response.

[0053] In this embodiment, through sequential processing in steps S11-S14, a heterogeneous security event aggregation and attribution method based on alarm confidence is fully realized by constructing a security primitive causal graph, heterogeneous alarm probe anchoring, deterministic aggregation of connected components, and root cause graph traversal tracing. Its core lies in transforming heterogeneous alarms into probes on the system's underlying causal graph, using graph connectivity as the objective basis for aggregation, and graph traversal as the technical means of tracing the source. This transforms security alarm aggregation and attribution from "similar comparison of alarm semantics" to "causal calculation of system behavior," reconstructing the connotation of alarm confidence and providing enterprises with efficient, accurate, and interpretable analytical capabilities for security operations.

[0054] Example 2: Specific implementation of the construction of a cause-effect graph of security primitives.

[0055] In this embodiment, constructing a security primitive causal graph includes: Each system call event in the system call event stream is parsed into an event tuple containing the calling process identifier, the called object identifier, the operation type, and the event timestamp; Using the calling process identifier as the source node identifier and the called object identifier as the target node identifier, create or update the nodes in the security primitive cause-effect graph; Based on the operation type, a directed edge is established between the source node and the target node, and the operation type and the event timestamp are recorded as attributes of the directed edge to construct a graph model. The operation type includes process creation, file operation, and network connection.

[0056] Event timestamp: This refers to the precise time of an event occurrence, carried within the system call event itself and recorded by the kernel auditing system. The event timestamp is a temporal attribute of edges in a security primitive causal graph, used to determine the order and causal relationships between operations. Its precision depends on the kernel clock and auditing architecture, typically ranging from nanoseconds to milliseconds. Event timestamps and alarm timestamps (the occurrence time recorded in security alarms) are two time concepts from different sources. The former is the authoritative time of the underlying system operation, while the latter is the observation time of the upper-layer security device. Both work together to ensure time alignment during the alarm anchoring process.

[0057] The specific implementation of this embodiment is as follows: First, the security analysis engine's event parsing module parses each system call event in the system call event stream into a structured event tuple. This event tuple may contain, but is not limited to, the following fields: calling process identifier (uniquely identifying the calling process, such as consisting of host ID, process PID, and process creation timestamp), called object identifier (such as file path, network IP:Port, or process identifier), operation type (such as FORK, EXECVE, OPEN, WRITE, CONNECT, etc.), and event timestamp. The event timestamp can be extracted from the kernel event header by the audit probe, directly reflecting the real-time time of the operation.

[0058] Secondly, the graph construction module creates or updates graph nodes based on event tuples. The calling process identifier is used as the source node ID, and the called object identifier is used as the target node ID. In the security primitive causal graph, nodes are stored as vertices with unique identifiers. If a node with the same identifier already exists in the security primitive causal graph, its attributes (such as last active time) are updated; otherwise, a new node is created, and its attributes are recorded. Node attributes include, but are not limited to: node type (e.g., process / object), corresponding process path or object path, initial appearance time, last active time, etc.

[0059] Then, the graph construction module establishes a directed edge between the source node and the target node based on the operation type. The direction of the directed edge points from the calling process to the called object, indicating that "the calling process affects or depends on the called object through this operation." After the directed edge is established, the operation type and event timestamp are stored as attributes of the edge, giving the edge temporal and semantic information. The establishment of directed edges supports the graph model in describing dynamic operation dependencies between processes.

[0060] It should be noted that the recording method for the aforementioned edge attributes is not limited to direct key-value pair storage. In one example, the operation type can be encoded as a predefined enumeration value, and a compressed timestamp format (such as a Unix millisecond timestamp) can be used to reduce storage overhead, suitable for large-scale event stream scenarios. In another example, a weight attribute can be attached to each edge, and an initial weight can be assigned based on the credibility and importance of the operation type for subsequent weighted graph analysis. Any method that can record and structurally express the influence relationship between processes of system call operations falls within the protection scope of this invention.

[0061] For example, continuing from the previous example, for event E1: malware.exe (PID3301) - execve -> cmd.exe (PID3302), time=T1, the event parsing module generates an event tuple (source ID=HostA_3301_T0, destination ID=HostA_3302_T1, operation type=EXECVE, timestamp=T1). The graph building module creates nodes N1 (identified by HostA_3301_T0) and N2 (identified by HostA_3302_T1), and establishes a directed edge from N1 to N2 with the attributes {operation type: process creation, event timestamp: T1}.

[0062] In this embodiment, by defining the structure of event tuples, node creation and update strategies, and edge attribute recording methods, the system call event flow is structurally mapped into a computable graph model. Thus, based on the security primitive causal graph framework constructed in Embodiment 1 above, this embodiment further solves the problem of how to efficiently and accurately transform unstructured audit logs into graph data structures, providing a high-quality data foundation for subsequent graph analysis.

[0063] Example 3: Specific implementation of causal path merging based on process tree.

[0064] In this embodiment, after establishing a directed edge between the source node and the target node, the method further includes: When M directed edges of the same operation type from different source nodes targeting the same called object are detected, it is determined whether the calling processes corresponding to the M directed edges belong to the same process tree, where M≥2 and are integers; If they belong to the same process tree, add a convergence identifier to the M directed edges that points to the common ancestor process node of the calling process corresponding to each of the M directed edges, so that the security primitive causal graph supports causal path merging based on the process tree.

[0065] Process Tree: In an operating system, processes create child processes through the `fork` or `execve` system calls, forming a directed tree structure rooted at the initial process, where the parent process is the creator of the child processes. Processes within the same process tree have kinship relationships, typically derived from the same initial parent process or the same set of parent and child processes. In attack scenarios, malicious programs often create multiple child processes or sibling processes to collaboratively perform malicious operations; these processes exhibit consistent behavior. The process tree information in this invention can be derived from the `fork` and `execve` events in the system call event stream, or by directly querying the operating system's process snapshot.

[0066] Common ancestor process node: This refers to the nearest common ancestor node of the multiple calling processes in a process tree. Since these calling processes belong to the same process tree, there must be a node that is their common parent node or a higher-level ancestor. The convergence identifier points to this common ancestor process node, indicating that these concurrent identical operations were initiated by the same process family and can be merged.

[0067] The specific implementation of this embodiment is as follows: First, during the construction of the security primitive causal graph, the graph optimization module continuously monitors newly established directed edges. When multiple directed edges (M≥2) pointing to the same called object (such as the same file path, the same IP:Port, etc.), originating from different source nodes and having the same operation type are detected, a process tree convergence check is triggered. This phenomenon of multiple directed edges pointing to the same called object may indicate that multiple related processes are coordinating to attack the same target, such as multiple child processes simultaneously connecting to the C2 server.

[0068] Secondly, the graph optimization module traces back the source nodes (i.e., the calling processes) of these directed edges. By querying the process creation events in the system call event stream or directly utilizing the constructed process tree relationships, it determines whether these source nodes belong to the same process tree. The determination process can be as follows: extract the parent process chain of each source node and check whether they share the same ancestor process (usually tracing back to the most recent identical fork event). If so, they are determined to belong to the same process tree; otherwise, they do not.

[0069] If they belong to the same process tree, the graph optimization module calculates the nearest common ancestor node of these source nodes, i.e., the common ancestor process node. Then, a convergence identifier pointing to the common ancestor process node is added to these M directed edges. The convergence identifier can be a virtual edge or an edge attribute, used to mark that these edges originate from the same process group. During subsequent traversal and analysis, they can be merged into a single logical operation, thereby simplifying the causal graph structure of the security primitive and avoiding redundancy.

[0070] It should be noted that the triggering condition for the above process tree aggregation is not limited to M≥2. In one example, a minimum concurrency threshold (e.g., M≥3) can be set to avoid frequent aggregation calculations caused by normal concurrent operations, thus reducing performance overhead. In another example, the threshold can be dynamically adjusted according to the operation type, setting a lower threshold for high-risk operations (e.g., network connections) and a higher threshold for low-risk operations (e.g., reading system configuration files). Any graph optimization mechanism capable of identifying and merging concurrent operations from the same source falls within the scope of protection of this invention.

[0071] For example, continuing the previous example, suppose the malware `malware.exe` creates three child processes, `child1`, `child2`, and `child3`, all of which initiate a `connect` connection to the same C2 server, 203.0.113.10:443. The graph will show three directed edges, each pointing from `child1`, `child2`, and `child3` to the same target node. The graph optimization module detects these three directed edges with the same operation type and the same target, determining that all three child processes belong to a process tree rooted at `malware.exe`, and their common ancestor process node is the `malware.exe` node. Therefore, a convergence marker pointing to the `malware.exe` node is added to these three edges. In subsequent connected component calculations, these three edges can be grouped into "network connection behavior initiated by the `malware.exe` process tree," thus simplifying the graph structure and highlighting the attack source.

[0072] In this embodiment, by detecting and aggregating concurrent identical operations on the same object within the same process tree, redundant sibling process behaviors are merged into the aggregation behavior of the ancestor node. Thus, based on the graph model constructed in Embodiment 2 above, the problem of the expansion of the security primitive causal graph and path redundancy caused by a large number of concurrent child process operations is further solved, significantly improving the efficiency of graph analysis and the readability of attack behaviors.

[0073] Example 4: Specific implementation of alarm process identifier extraction based on 5-tuple backtracking.

[0074] In this embodiment, please refer to Figure 2 , Figure 2This is a schematic diagram of the first sub-process of the heterogeneous security event aggregation and attribution method based on alarm confidence provided in an embodiment of the present invention. Figure 2 As shown, in this embodiment, the process identifier and alarm timestamp used for locating in the security primitive causal graph are extracted from each of the heterogeneous security alarms, including: S21: Parse the original data packet of the heterogeneous security alarm and determine whether it contains a process identifier field; S22: If included, extract the process identifier directly from the original data packet; S23: If not included, extract network session quintuple information from the heterogeneous security alarm, and based on the network session quintuple information and alarm timestamp, backtrack and query the process node associated with the corresponding network session in the security primitive causal graph, and determine the identifier of the queried process node as the process identifier corresponding to the heterogeneous security alarm.

[0075] Network session quintuple information refers to the five identifying fields of a network communication session based on the TCP / IP protocol, typically including the source IP address, source port, destination IP address, destination port, and transport layer protocol (such as TCP or UDP). The network session quintuple is common information in alarms from network-side security devices (such as IDS and firewalls) and is used to uniquely identify a network connection. In this invention, when a security alarm lacks a process identifier, the network session quintuple information is used to reverse-engineer the process node that initiated the connection in the security primitive cause-effect graph.

[0076] The specific implementation of this embodiment is as follows: First, the alarm anchoring module parses the raw data packets of heterogeneous security alarms, using regular expression matching or field mapping techniques to traverse the security alarm field list. It then determines whether a process identifier field, such as pid, process_id, process_name, or image_path, is included. If it exists, the field value is extracted and combined with the host identifier from the security alarm to generate a process identifier.

[0077] If the process identifier field is not included, the backtracking query process based on the network session 5-tuple is initiated. The alarm anchoring module extracts the network session 5-tuple information (source IP, source port, destination IP, destination port, protocol) from the alarm message. Based on the alarm timestamp, the security primitive cause-effect graph is queried in the graph database to locate the object node (e.g., IP:Port node) corresponding to the destination IP and destination port. This object node should have one or more incoming edges of type "network connection," and the source node of the edge is the process node that initiated the network connection. By filtering the edge's time attribute and matching it with the alarm timestamp (considering a certain time tolerance), the most likely process node is determined. If multiple candidates exist, the best-matching process node can be selected based on heuristic rules such as the proximity of edge timestamps and process activity. The unique identifier of the queried process node is determined as the process identifier corresponding to the security alarm.

[0078] It should be noted that the matching strategy for the above-mentioned backtracking query is not limited to exact timestamp matching. In one example, a probabilistic matching method based on Bayesian inference can be used, combining the alarm context and process behavior probability model to calculate the posterior probability of candidate process nodes, and selecting the process node with the highest posterior probability as the anchoring result. In another example, a process-network connection mapping cache can be maintained, updating the correspondence between processes and network session quintuples in real time. When a security alarm arrives, it can be quickly retrieved directly from the cache, improving anchoring efficiency. Any technical means that can map network-side security alarms to the initiating process falls within the protection scope of this invention.

[0079] For example, following the previous example, for security alarm B, its message does not contain a process identifier field. The alarm anchoring module extracts its network session 5-tuple: source IP=192.168.1.100, source port=45678, destination IP=203.0.113.10, destination port=443, protocol=TCP, alarm timestamp T2'. In the graph database, the object node O1 (203.0.113.10:443) is retrieved. This node has an incoming edge from process node N2 (cmd.exe), with the edge attributes {operation type: network connection, event timestamp: T2}. Since T2 and T2' are consistent within a reasonable time tolerance, the process identifier HostA_3302_T1 of the source node N2 is determined as the process identifier of security alarm B. Thus, security alarm B is successfully anchored to N2.

[0080] This embodiment solves the problem that a large number of network security alarms cannot be directly associated with host processes by using a hierarchical extraction strategy and a network session five-tuple backtracking query mechanism. Thus, based on the alarm anchoring achieved in Embodiment 1 above, it further realizes process tracing of default process identifier alarms, opens up the mapping channel between network security alarms and host behavior graphs, and significantly improves the coverage and accuracy of heterogeneous alarm anchoring.

[0081] Example 5: Specific implementation of dynamic evaluation of event-level confidence.

[0082] In this embodiment, after aggregating all heterogeneous security alarms corresponding to the event probes belonging to the same connected component into a single security event, the method further includes: Extract the causal subgraph of the connected components corresponding to the security event; Calculate the causal density index, malicious behavior concentration index, and attack chain integrity index of the causal subgraph; The causal density index, the malicious behavior concentration index, and the attack chain integrity index are input into a preset confidence assessment model to obtain the event-level confidence score of the security event.

[0083] Causality density index: This refers to the ratio of the number of process nodes marked by anchored event probes to the total number of process nodes in the causal subgraph corresponding to a security event. The causal density index reflects the coverage density of alarm signals in the security primitive causal graph of the aggregated event. A higher causal density index indicates that a higher proportion of the causal region involved in the aggregated event is covered by security alarms, suggesting that the security event is aggregated based on sufficient evidence and should have a higher confidence level. Its calculation formula is: D = N_alert / N_total, where N_alert is the number of process nodes in the causal subgraph anchored by alarm probes, and N_total is the total number of process nodes in the causal subgraph.

[0084] Malicious Behavior Concentration Index: This refers to the proportion of system call edges in a causal subgraph involving malicious operations (such as connecting to known malicious IPs, writing to sensitive file paths, creating scheduled tasks, etc.) to the total number of edges in the causal subgraph. Malicious operations can be defined based on a pre-defined malicious behavior rule base, which contains a series of malicious operation patterns, such as target IPs matching threat intelligence blacklists, writing to sensitive system directories, and operations involving service creation or registry modification. A higher malicious behavior concentration indicates that malicious operations dominate the security incident, the higher the threat level, and the higher the corresponding confidence level. The calculation formula can be: C = M_edge / E_total, where M_edge is the number of edges judged as malicious, and E_total is the total number of edges in the causal subgraph.

[0085] Attack chain completeness metric: This refers to the degree of pattern matching between the system behavior sequence in the causal subgraph and the standard attack chain (such as the tactical phases defined in the MITRE ATT&CK framework). It is calculated by aligning the operation sequence in the causal subgraph with a pre-defined attack chain template (e.g., initial access → execution → persistence → lateral movement). A higher attack chain completeness indicates that the reconstructed attack behavior of the security event closely matches a known attack chain pattern, and the credibility of its attribution is higher. The calculation formula is: K = M_stage / S_total, where M_stage is the number of matched tactical phases, and S_total is the total number of phases in the template.

[0086] The pre-defined confidence assessment model refers to a mathematical model that is pre-built and deployed to calculate the event-level confidence score by comprehensively considering the above three indicators. Its input consists of the three normalized or standardized indicator values, and its output is a confidence score between 0 and 1. This confidence assessment model can be based on linear regression, logistic regression, or a simple weighted sum and normalized using the Sigmoid function. The specific model structure and weights will be discussed in the subsequent Example 6.

[0087] Event-level confidence score: This refers to a comprehensive quantitative indicator calculated by the aforementioned confidence assessment model, used to measure the authenticity and threat severity of aggregated security events. The event-level confidence score no longer relies on the confidence level assigned by the original alarm device, but is dynamically calculated from the objective structural indicators of the security primitive cause-effect graph. Therefore, it can serve as an objective basis for prioritizing security responses.

[0088] The specific implementation of this embodiment is as follows: First, after aggregating and generating security events, the confidence assessment module of the security analysis engine extracts the causal subgraph (i.e., the connected component subgraph) corresponding to the security event. The causal subgraph contains a set of nodes, a set of edges, and their attributes.

[0089] Secondly, the confidence assessment module calculates three indicators: traversing all process nodes in the subgraph, counting the number of nodes anchored by the alert probe, and calculating the causal density indicator D; traversing all directed edges, matching the operation type and target object of each edge with the malicious behavior rule base, and calculating the malicious behavior concentration indicator C; and aligning the operation sequence (sorted by time) in the causal subgraph with a preset attack chain template, and calculating the attack chain integrity indicator K. The specific attack chain template matching algorithm can be implemented using sequence alignment or the longest common subsequence (LCS) algorithm. The sequence alignment or LCS algorithm can refer to existing related technologies and will not be elaborated here.

[0090] Then, the three indicators are input into a preset confidence assessment model, which outputs an event-level confidence score S according to a predefined calculation logic (such as weighted sum). The closer the value of S is to 1, the higher the credibility of the security event as a real attack.

[0091] It should be noted that the calculation methods for the above indicators are not limited to simple ratios. In one example, the causal density indicator can incorporate node weights, calculating the density based on the criticality of nodes in the attack chain, thus increasing the contribution of critical node alerts to the density. In another example, the attack chain integrity indicator can consider the sequence of stages, requiring not only the occurrence of stages but also that their order conforms to the logical progression of a typical attack chain. Any indicator definition and calculation method that can quantify the credibility of an event based on the structural and behavioral characteristics of the causal subgraph falls within the scope of protection of this invention.

[0092] For example, continuing from the previous example, for the causal subgraph of security event SE-001, the total number of process nodes N_total = 2 (N1 and N2), and the number of process nodes anchored by the alert probe N_alert = 2 (N1 anchors alert A, N2 anchors alert B), therefore the causal density index D = 1.0. There are 2 directed edges in the causal subgraph, among which edge E2 connected to the malicious IP is determined to be a malicious edge, with a malicious behavior concentration C = 0.5. The behavioral sequence (process creation → network connection) in the causal subgraph matches the "execution" and "command and control" stages in the attack chain template. The total number of stages in the template is 5, and the attack chain completeness K = 0.4. After inputting the three indices into the model, the event-level confidence score S is obtained, such as 0.78.

[0093] In this embodiment, by extracting causal subgraphs and calculating multidimensional behavioral indicators, and then comprehensively quantifying them through a confidence assessment model, the isolated and static confidence level that relies on alarm device self-scoring in traditional technologies is reconstructed into a deterministic confidence level that is dynamically calculated based on multidimensional objective indicators of the causal graph. Thus, based on the deterministic aggregation achieved in Embodiment 1 above, an objective and quantitative assessment of the credibility of the aggregation results is further realized, significantly improving the accuracy and interpretability of security event priority ranking.

[0094] Example 6: Specific implementation of the confidence assessment model.

[0095] In this embodiment, the preset confidence assessment model calculates the event-level confidence score using the following formula: ; Wherein, S is the event-level confidence score, σ is the sigmoid function, D is the causal density index, C is the malicious behavior concentration index, K is the attack chain integrity index, and w1, w2 and w3 are weight coefficients obtained by training with historical security event data.

[0096] The specific implementation of this embodiment is as follows: The weight coefficients w1, w2, and w3 are obtained through training on historical security event data. Specifically, confirmed and labeled historical security event samples (including real attack events and false positives) are collected. The values ​​of the causal density index, malicious behavior concentration index, and attack chain integrity index corresponding to each historical security event sample are extracted. Using the sample's authenticity label (e.g., 1 for true, 0 for false) as the target value, a logistic regression model is constructed. Using the three indicators as features, gradient descent or maximum likelihood estimation can be used to train the model parameters, thereby obtaining the optimal weight coefficients. After training, the weight coefficients are embedded into a pre-defined confidence assessment model. During inference, for newly aggregated security events, their indicator vectors are calculated, and the event-level confidence score S is output through weighted summation and mapping using the Sigmoid function. The Sigmoid function σ(x) = 1 / (1 + e^(-x)) maps the linear combination to the (0, 1) interval, consistent with a probabilistic interpretation.

[0097] Parameter determination method: The initial values ​​of the weight coefficients w1, w2, and w3 can be set to 0.33, 0.33, and 0.34, respectively, and then adjusted through training iterations. Typically, after training, the weight coefficients can be w1=0.25, w2=0.45, and w3=0.30, reflecting that the concentration of malicious behavior has the greatest impact on the confidence level. The input to the Sigmoid function is a linear combination of values; a typical output range above 0.5 indicates a high-confidence attack event.

[0098] In this embodiment, by defining a confidence assessment formula based on linear weighting and Sigmoid normalization, and using historical data to train the weight coefficients, adaptive optimization of the assessment model is achieved. Thus, based on the multidimensional indicators constructed in the above embodiment 5, the problem of how to integrate multidimensional indicators into a unified confidence quantification is further solved, making the confidence assessment more accurate and dynamically evolving.

[0099] Example 7: Specific implementation of root cause graph traversal and attack chain generation.

[0100] In this embodiment, root cause graph traversal is performed on the causal subgraph of the connected component corresponding to the security event to generate a complete attack causal chain from the attack source to the attack target, including: In the causal subgraph, process nodes with an in-degree of zero are identified, and the process node with the earliest event timestamp is determined as the root cause node. If there is no process node with an in-degree of zero, backtrack to the security primitive causal graph, determine the external associated node that has a directed edge connection with the node in the causal subgraph and does not belong to the causal subgraph, and determine the first node with suspicious operation behavior among the external associated nodes as the root cause node. Starting from the root cause node, a depth-first traversal is performed on the causal subgraph to generate a path sequence containing all anchored alarm nodes and key target nodes, which serves as the complete attack causal chain.

[0101] Externally related nodes: These are nodes in the global security primitive causal graph that are connected to a node in the current causal subgraph via directed edges, but are not themselves part of that subgraph. These nodes are typically upstream nodes in the attack chain (such as the attacker's initial entry point process) and are not included in the current causal subgraph because they were not alerted or had their time window pruned. Externally related nodes may hold the root cause of the attack.

[0102] Suspicious operational behavior: refers to a node's operational behavior sequence that highly matches known attack patterns, or exhibits obvious malicious characteristics (such as executing suspicious scripts, injecting code, accessing abnormal networks, etc.). The specific determination method will be implemented in Example 8 by matching operational behavior sequences with attack chain templates.

[0103] The specific implementation of this embodiment is as follows: First, the source tracing module traverses all process nodes on the causal subgraph corresponding to the security event, calculating the in-degree of each node (considering only edges within the causal subgraph). A process node with an in-degree of zero indicates that no other process points to it within the causal subgraph, making it a candidate for the front end of the attack chain. If multiple nodes with an in-degree of zero exist, the node with the earliest event timestamp in its edge attributes is selected as the root cause node.

[0104] If the in-degree of all process nodes in the subgraph is greater than zero (i.e., there is a circular dependency or all nodes have a predecessor, which is rare in process behavior graphs but may be due to incomplete alarm coverage), then a global backtracking is performed. The backtracking process: Starting from each boundary node of the causal subgraph, a reverse search is performed along the incoming edges in the global security primitive causal graph to collect all externally related nodes that are connected to nodes in the causal subgraph by directed edges but are not in the causal subgraph. For these externally related nodes, the suspicious operation behavior judgment logic (Example 8) is applied to find the first node (in chronological order or nearest neighbor) with suspicious behavior as the root cause node.

[0105] Then, starting from the identified root cause node, a depth-first search (DFS) traversal is performed on the causal subgraph, moving along the edges and collecting all nodes and directed edges along the traversal path to generate a path sequence. During the traversal, it is ensured that all anchored alert nodes and attack target nodes (such as sensitive files that have been written to or database nodes that have been accessed) are included. The path sequence can be arranged in ascending order by event timestamps to form an attack causal chain.

[0106] For example, continuing from the previous example, the causal subgraph of security event SE-001 contains nodes N1 and N2. Checking the in-degree: N1 has an in-degree of 0 (no other node points to it), and N2 has an in-degree of 1 (an edge from N1). Therefore, N1 is determined to be the root cause node. Performing a Depth-First Search (DFS) starting from N1 generates the following path: N1 (malware.exe) - [Process Creation] -> N2 (cmd.exe) - [Network Connection] -> O1. The attack chain reconstruction is complete.

[0107] In this embodiment, a two-layer root cause localization strategy is constructed by prioritizing the search for root cause nodes with an in-degree of zero within the causal subgraph and backtracking the global security primitive causal graph to find external suspicious nodes when they are missing. This further solves the problem of root cause indeterminacy due to incomplete alarm coverage or missing preceding attack phases, based on the above embodiment 1, and significantly improves the integrity of the attack tracing chain.

[0108] Example 8: Specific implementation of suspicious node determination based on behavior pattern matching.

[0109] In this embodiment, please refer to Figure 3 , Figure 3 This is a schematic diagram of the second sub-process of the heterogeneous security event aggregation and attribution method based on alarm confidence provided in an embodiment of the present invention. For example... Figure 3 As shown, in this embodiment, the first node among the external associated nodes with suspicious operational behavior is identified as the root cause node, including: S31: For each external associated node, extract its corresponding operation behavior sequence in the security primitive causal graph. The operation behavior sequence is composed of the operation types in the directed edge attributes of the external associated node and its descendant nodes in chronological order. S32: Match the operation behavior sequence with a preset attack chain behavior pattern library, wherein the preset attack chain behavior pattern library contains multiple attack behavior templates composed of standard operation type sequences. S33: If there is at least one of the attack behavior templates, such that the matching degree between the operation behavior sequence and the attack behavior template exceeds a preset matching threshold, the corresponding external associated node is marked as a node with suspicious operation behavior; S34: After processing all the external associated nodes, if there is at least one node marked as having suspicious operation behavior, the external associated node with the earliest event timestamp is determined as the root cause node. S35. If no node is marked as having suspicious operation behavior, generate an anomaly alarm to prompt manual analysis of the external associated node, and push the anomaly alarm to the security operation terminal.

[0110] A pre-built library of attack chain behavior patterns refers to a pre-built standard operation sequence template library that stores various known attack behavior patterns. It contains multiple attack behavior templates, each an ordered list of operation types representing a typical system call sequence when an attacker performs a specific attack action. For example, a "remote code execution" template can be represented as: [EXECVE, OPEN, WRITE, CONNECT], indicating that the attacker completes the intrusion by executing scripts, writing files, connecting to the network, etc. The attack behavior templates can be sourced from security community knowledge bases (such as the underlying behavioral abstractions of ATT&CK technologies), historical attack event analysis results, and expert experience.

[0111] Matching degree: A metric used to quantify the similarity between a sequence of operational behaviors and an attack behavior template. It can be the ratio of the longest common subsequence (LCS) length to the template length, or a normalized score calculated using a sequence dynamic programming alignment algorithm (such as Needleman-Wunsch). The matching degree ranges from 0 to 1, with values ​​closer to 1 indicating a higher degree of matching.

[0112] The specific implementation of this embodiment is as follows: First, for each externally associated node, the tracing module extracts the causal subgraph rooted at that node from the security primitive causal graph, collects the directed edges of that node and all its descendant nodes, and sorts the operation types in ascending order by the event timestamps of the edges to form an operation behavior sequence.

[0113] Secondly, the sequence of operational behaviors is matched against each attack behavior template in the attack chain behavior pattern library. A sequence matching algorithm based on dynamic programming can be used, allowing insertion and deletion operations, and the normalized longest common subsequence ratio or alignment score between the operational behavior sequence and the attack behavior template can be calculated as the matching degree.

[0114] Then, if the matching degree exceeds the preset matching threshold (e.g., 0.6, the threshold can be adjusted according to the sensitivity requirements, and the value range can be 0.5-0.9), the behavior of the external associated node is determined to be suspicious, and the node is marked as a suspicious node.

[0115] Finally, after processing all external related nodes, if there is at least one node marked as suspicious, the one with the earliest event timestamp is selected as the root cause node.

[0116] If no node is marked as suspicious, an anomaly alarm is generated to prompt manual analysis and attention to external related nodes, and the anomaly alarm is pushed to the security operations terminal. At the same time, the event-level confidence score of the security event can be multiplied by a preset decay coefficient (e.g., 0.8) to indicate the uncertainty of its root cause determination.

[0117] For example, suppose an external associated node N0 corresponds to a process with an unanchored alarm, whose operation sequence is [EXECVE, OPEN, CONNECT]. The LCS length of the "remote execution" template [EXECVE, OPEN, WRITE, CONNECT] is 3, the template length is 4, the matching degree is 0.75, which exceeds the threshold of 0.6, so it is marked as suspicious, and N0 is the root cause node.

[0118] In this embodiment, by extracting the sequence of operational behaviors and matching it with the attack chain behavior pattern library, the "suspicious" characterization that relies on manual judgment by experts in traditional technologies is transformed into a calculable, objective judgment based on behavior pattern matching. Thus, based on the above embodiment 7, it further solves the problem of how to automatically and standardize the identification of external suspicious nodes as the root cause of attacks, and significantly improves the accuracy and automation of root cause determination.

[0119] Example 9: Specific implementation of anchoring enhancement based on malicious identifier feedback.

[0120] In this embodiment, after generating a complete attack causal chain from the attack source to the attack target, the method further includes: Extract all process node identifiers along the attack path from the complete attack causal chain to form a confirmed set of malicious process identifiers; The malicious process identifier set is fed back to a preset alarm anchoring optimizer, so that the alarm anchoring optimizer will prioritize anchoring newly received heterogeneous security alarms to process nodes belonging to the malicious process identifier set during subsequent anchoring processes.

[0121] The preset alarm anchoring optimizer is a decision-making unit added to the alarm anchoring module. When selecting from multiple candidate anchoring nodes, it assigns higher priority to nodes already identified as malicious processes. When a new security alarm can be anchored to different process nodes through multiple paths, the anchoring optimizer references the set of malicious process identifiers and prioritizes process nodes belonging to that set, thereby accelerating the association of subsequent attack alarms.

[0122] The specific implementation of this embodiment is as follows: First, after generating the attack causal chain, the tracing module extracts the unique identifiers of all process nodes on the attack causal chain to form a malicious process identifier set. The malicious process identifier set can be stored in a memory cache or database, and a time limit window can be set (such as valid for 24 hours after the attack).

[0123] Secondly, when the alarm anchoring module receives a new security alarm and executes the anchoring logic (step S12), if multiple candidate nodes are matched based on the process identifier and alarm timestamp, the alarm anchoring optimizer is invoked. The anchoring optimizer queries the set of malicious process identifiers. If a candidate node belongs to the set of malicious process identifiers, it is preferentially selected as the anchoring target, thereby quickly associating the new security alarm with known attack activities. When there is only one candidate node, a flag indicating whether the candidate node is a malicious node can also be added to accelerate subsequent response.

[0124] For example, after confirming the SE-001 attack causal chain, the malicious process identifier set includes N1 and N2. When a new alert C is subsequently received (from the host firewall, detecting that process N2 is attempting to access an internal database), the anchoring module matches candidate node N2 with another normal process N3. Based on the malicious process identifier set, the anchoring optimizer prioritizes anchoring the new alert C to N2, immediately identifying it as an extension of the same attack event.

[0125] In this embodiment, by feeding back the confirmed attack chain information to the alarm anchoring stage, a closed-loop mechanism of "source tracing results feeding back to real-time analysis" is constructed. Thus, based on the alarm anchoring achieved in Embodiment 1 above, it further realizes the proactive guidance and acceleration of subsequent alarm anchoring, significantly improving the continuity and response speed of security event tracking.

[0126] Example 10: Specific implementation of the closed-loop adaptive optimization method.

[0127] In this embodiment, after generating a complete attack causal chain from the attack source to the attack target, the method further includes: The complete attack causal chain is analyzed, and all malicious process node identifiers and corresponding malicious operation behavior sequences on the attack path are extracted. The malicious operation behavior sequences are composed of the operation types in the directed edge attributes of the attack path in chronological order. Based on the malicious operation behavior sequence, a target response script is matched in a preset automated response script library and the execution of the target response script is triggered to block or isolate the process corresponding to the malicious process node identifier. After triggering the execution of the target response script, continuously monitor the process activities related to the malicious process node identifier in the security primitive cause-effect graph. If a new process or derived operation originating from the malicious process node identifier is detected within a preset observation period, it is determined to be an attack remnant or variant, and a new security event is automatically generated. The new process or derived operation is taken as the root cause node, and the root cause graph traversal is re-executed to update the complete attack cause-effect chain.

[0128] Malicious Operation Behavior Sequence: This refers to the sequence of operation types extracted chronologically from the directed edge attributes of a confirmed attack causal chain. It is similar to the operation behavior sequence definition in Example 8, but the source is a confirmed malicious attack chain, not the node to be evaluated. The malicious operation behavior sequence describes the specific behavioral patterns actually performed by the attacker and is a key feature for matching response scripts.

[0129] The pre-defined automated response script library refers to a set of predefined executable automated response process templates, containing multiple response scripts. Each response script targets a specific attack behavior pattern and specifies concrete blocking or isolation operations, such as terminating processes, isolating hosts, blocking IPs, and disabling accounts. Script matching is based on the signature or pattern of malicious operation behavior sequences; for example, when the [EXECVE, CONNECT] sequence is identified, the "Block C2 Communication" script is matched.

[0130] The specific implementation of this embodiment is as follows: First, the security analysis engine's response module parses the generated complete attack causal chain, extracts all malicious process node identifiers and the sequence of directed edge operation types along the attack path, and constitutes a sequence of malicious operation behaviors.

[0131] Secondly, the malicious action sequence is matched against the trigger conditions of response scripts in the automated response script library. The matching method can be rule-based pattern matching: each response script predefines a trigger action signature (also composed of an action type sequence), calculates the similarity between the signature and the malicious action sequence, and selects the response script with the highest similarity as the target response script. This triggers the execution of the response script, sending process termination commands to the endpoint protection system and IP blocking commands to the firewall via the Security Orchestration Automation and Response (SOAR) platform's API.

[0132] Then, the response module initiates an observation period (e.g., 30 minutes). During this observation period, it continuously monitors new activities related to the dealt-off malicious process nodes in the security primitive causal graph. Specific monitoring methods include, but are not limited to: setting up a listener in the graph database; when a new process with the original malicious process node as its parent node (such as a new fork event) is detected, or a new operation is derived from the original malicious process identifier (such as a new connection to the same malicious IP), it is determined to be an attack remnant or variant. At this time, a new security event is automatically generated, using the newly created process as the root cause node, re-triggering the root cause graph traversal process of Example 7, generating an updated attack causal chain, and forming a closed loop.

[0133] For example, after detecting the attack causal chain, the malicious operation sequence is [EXECVE, CONNECT], which matches the response script "isolate the host and block C2". After executing the above response script, process N2 is terminated. In subsequent observations, if process N1 is found to have created a new child process N4 (a variant of malware.exe), a new event is automatically generated, and the root cause is traced back to N4.

[0134] In this embodiment, by driving automated response with attack causal chain analysis results and continuously monitoring the response effect to discover attack remnants and automatically re-analyze, a closed-loop adaptive security mechanism of "analysis → response → verification → re-analysis" is constructed. Thus, based on the aggregation attribution achieved in embodiments 1-9 above, it further realizes the leap from passive analysis to active defense, significantly improving the automation level of security operations and resilience against advanced threats.

[0135] The heterogeneous security event aggregation and attribution method based on alarm confidence described in the above embodiments can be recombined as needed to obtain a combined implementation scheme, but all are within the protection scope claimed by this invention.

[0136] Experimental verification To verify the technical effects of the embodiments of the present invention, the following verification experiment can be designed to demonstrate the correlation between the technical solution and the technical effects of the present invention: [List of technical effects to be verified] Final result: Achieve highly accurate security event aggregation and complete attack causal chain reconstruction without relying on the semantics of the alerts themselves.

[0137] Direct effect A (corresponding to security primitive cause-effect graph and alarm anchoring): realizes unified security primitive cause-effect graph projection of heterogeneous alarms, and eliminates information mapping obstacles.

[0138] Direct effect B (corresponding to connected component aggregation and confidence reconstruction): realizes deterministic aggregation based on causal behavior and reconstructs the connotation of alarm confidence.

[0139] Direct effect C (corresponding to root cause graph traversal): Enables automated and complete reconstruction of the attack causal chain.

[0140] 1) Experiment overview and grouping.

[0141] To verify the aggregation and attribution effect of the method of the present invention, a dataset of simulated attacks on a corporate network can be used as the experimental scenario. Three experimental schemes can be set up: Control group A uses a SIEM association method based on alarm similarity clustering (such as DBSCAN clustering based on cosine similarity); Control group B can use an alarm association method based on knowledge graph reasoning (constructing an asset-vulnerability relationship graph); the experimental group uses the heterogeneous security event aggregation and attribution method based on alarm confidence described in embodiments 1-10 of the present invention. The dataset can contain approximately 500 heterogeneous alarms (such as those from IDS, EDR, and WAF) and corresponding system audit logs, simulating 15 multi-stage attack scenarios. The experiment can be run on a server equipped with an Intel Xeon processor and 128GB of memory, using JanusGraph as the graph database.

[0142] 2) Data on the correlation between key processes and effects.

[0143] [Direct Effect A Verification] To verify the effectiveness of causal projection and anchoring in eliminating information mapping barriers, the proportion of network-side security alarms (excluding process identifiers) successfully associated with host processes in the three schemes was statistically analyzed. Control groups A and B, due to their reliance on security alarm content matching or predefined relationships, had security alarm process association success rates of approximately 32% and 41%, respectively. The experimental group, through quintuple backtracking queries and causal graph anchoring, achieved a success rate of approximately 96%. These results confirm that the mechanism of converting alarms into event probes and anchoring them to the security primitive causal graph directly contributes to opening up mapping channels between heterogeneous data sources and eliminating information mapping barriers.

[0144] [Direct Effect B Verification] To verify the effect of connected component aggregation and confidence reconstruction on aggregation accuracy, the aggregation accuracy (number of correctly aggregated alarms / total number of alarms) and false aggregation rate of the three schemes were statistically analyzed. Control group A had an accuracy of approximately 78% and a false aggregation rate of approximately 22%; control group B had an accuracy of approximately 82% and a false aggregation rate of approximately 18%. The experimental group had an accuracy of approximately 97% and a false aggregation rate of approximately 3%. These results indicate that using causal graph connected components instead of semantic similarity for aggregation can significantly improve aggregation accuracy and reduce false aggregation. Furthermore, the security events output by the experimental group are accompanied by event-level confidence scores based on causal graph metrics, providing quantifiable credibility data.

[0145] [Direct Effect C Verification] To verify the effect of root cause graph traversal on the completeness of attack chain reconstruction, the proportion of the three schemes that correctly reconstructed the complete attack chain (covering all steps from the initial intrusion to the final target) was statistically analyzed. Control groups A and B only had approximately 35% and 48% of attack scenarios completely reconstructed, respectively. The experimental group achieved a complete reconstruction rate of approximately 92%. These results indicate that the root cause traversal mechanism based on causal subgraph in-degree analysis and external backtracking can significantly improve the completeness of attack attribution.

[0146] [Overall Effectiveness Verification] The invention comprehensively evaluates its improvement in security operation efficiency. The mean time to response (MTTR) from the first appearance of a security alert to the output of a complete attack chain was recorded. Control group A had an average MTTR of approximately 55 minutes, and control group B approximately 42 minutes. The experimental group, through automated aggregation attribution and closed-loop response mechanisms, reduced the average MTTR to approximately 8 minutes. Furthermore, the aggregation results of the experimental group provided a deterministic causal chain, with a direct acceptance rate of approximately 90% by security analysts, significantly higher than the approximately 60% in the control group.

[0147] 3) Experimental conclusions.

[0148] The experimental data above demonstrates that the embodiments of the present invention, through a closed-loop mechanism of constructing a security primitive causal graph, alarm probe anchoring, connected component aggregation, and root cause graph traversal, can: A) achieve precise anchoring of heterogeneous security alarms, eliminating information silos; B) replace subjective semantic association with deterministic causal aggregation, achieving an aggregation accuracy of approximately 97%; and C) restore the attack chain to approximately 92% completeness, effectively supporting source tracing and evidence collection. Thus, the embodiments of the present invention demonstrate a significant effect in solving the technical challenge of "achieving precise aggregation and complete attribution without relying on the semantics of the alarm itself," elevating security event confidence from subjective static assessment to objective dynamic calculation, and significantly enhancing the efficiency and accuracy of security operations.

[0149] In one embodiment, a computer device is provided, which may be a server or a cloud platform, and its internal structure diagram may be as follows. Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements the functions or steps of a heterogeneous security event aggregation and attribution method based on alarm confidence.

[0150] Those skilled in the art will understand that the methods provided in the embodiments of the present invention can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. The methods can also be implemented as a computer program product stored in one or more computer-readable storage media, including but not limited to: disks, optical disks, read-only memory (ROM), random access memory (RAM), flash memory, etc. When the computer program product is executed by one or more data processing devices (such as computers), the devices perform the steps as described in any of the foregoing method embodiments.

[0151] The software tools, components, or models not belonging to our company that appear in the embodiments of this invention are merely illustrative examples and do not represent actual use.

[0152] The data collection in this embodiment of the invention complies with the requirements of relevant laws and regulations, such as the Data Security Law of the People's Republic of China, the Personal Information Protection Law of the People's Republic of China, GDPR (General Data Protection Regulation of the European Union), or information security standards of other countries and regions.

[0153] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A heterogeneous security event aggregation and attribution method based on alarm confidence, characterized in that, include: Continuously acquire and process the system call event stream from the host, and construct a security primitive causal graph with the process executing the system call as the node, the object operated by the system call as the node, and the operation behavior generated between the processes through the system call as the directed edge to represent the operation dependency relationship between processes across the entire host. Receive N heterogeneous security alarms, extract the process identifier and alarm timestamp for locating in the security primitive causal graph from each heterogeneous security alarm, and use the heterogeneous security alarm as an event probe to anchor to the corresponding process node with the same process identifier and alarm timestamp in the security primitive causal graph, where N is a natural number; Obtain the set of process nodes pointed to by all anchored event probes within a preset time window, determine each connected component of the process node set in the security primitive cause-effect graph, and aggregate the heterogeneous security alarms corresponding to all event probes belonging to the same connected component into a security event. Root cause graph traversal is performed on the causal subgraph of the connected component corresponding to the security event to generate a complete attack causal chain from the attack source to the attack target.

2. The heterogeneous security event aggregation and attribution method based on alarm confidence as described in claim 1, characterized in that, Constructing a cause-effect graph of security primitives includes: Each system call event in the system call event stream is parsed into an event tuple containing the calling process identifier, the called object identifier, the operation type, and the event timestamp; Using the calling process identifier as the source node identifier and the called object identifier as the target node identifier, create or update the nodes in the security primitive cause-effect graph; Based on the operation type, a directed edge is established between the source node and the target node, and the operation type and the event timestamp are recorded as attributes of the directed edge to construct a graph model. The operation type includes process creation, file operation, and network connection.

3. The heterogeneous security event aggregation and attribution method based on alarm confidence as described in claim 2, characterized in that, After establishing a directed edge between the source node and the target node, the process further includes: When M directed edges of the same operation type from different source nodes targeting the same called object are detected, it is determined whether the calling processes corresponding to the M directed edges belong to the same process tree, where M≥2 and are integers; If they belong to the same process tree, add a convergence identifier to the M directed edges that points to the common ancestor process node of the calling process corresponding to each of the M directed edges, so that the security primitive causal graph supports causal path merging based on the process tree.

4. The heterogeneous security event aggregation and attribution method based on alarm confidence as described in claim 1, characterized in that, Extract the process identifier and alarm timestamp used for locating in the security primitive cause-effect graph from each of the heterogeneous security alarms, including: Parse the original data packet of the heterogeneous security alarm to determine whether it contains a process identifier field; If included, the process identifier is extracted directly from the original data packet; If not included, extract the network session quintuple information from the heterogeneous security alarm, and based on the network session quintuple information and the alarm timestamp, backtrack and query the process node associated with the corresponding network session in the security primitive causal graph, and determine the identifier of the queried process node as the process identifier corresponding to the heterogeneous security alarm.

5. The heterogeneous security event aggregation and attribution method based on alarm confidence as described in claim 1, characterized in that, After aggregating heterogeneous security alarms corresponding to all event probes belonging to the same connected component into a single security event, the process further includes: Extract the causal subgraph of the connected components corresponding to the security event; Calculate the causal density index, malicious behavior concentration index, and attack chain integrity index of the causal subgraph; The causal density index, the malicious behavior concentration index, and the attack chain integrity index are input into a preset confidence assessment model to obtain the event-level confidence score of the security event.

6. The heterogeneous security event aggregation and attribution method based on alarm confidence as described in claim 5, characterized in that, The preset confidence assessment model calculates the event-level confidence score using the following formula: ； Wherein, S is the event-level confidence score, σ is the sigmoid function, D is the causal density index, C is the malicious behavior concentration index, K is the attack chain integrity index, and w1, w2 and w3 are weight coefficients obtained by training with historical security event data.

7. The heterogeneous security event aggregation and attribution method based on alarm confidence as described in claim 1, characterized in that, Perform root cause graph traversal on the causal subgraph of the connected component corresponding to the security event to generate a complete attack causal chain from the attack source to the attack target, including: In the causal subgraph, process nodes with an in-degree of zero are identified, and the process node with the earliest event timestamp is determined as the root cause node. If there is no process node with an in-degree of zero, backtrack to the security primitive causal graph, determine the external associated node that has a directed edge connection with the node in the causal subgraph and does not belong to the causal subgraph, and determine the first node with suspicious operation behavior among the external associated nodes as the root cause node. Starting from the root cause node, a depth-first traversal is performed on the causal subgraph to generate a path sequence containing all anchored alarm nodes and key target nodes, which serves as the complete attack causal chain.

8. The heterogeneous security event aggregation and attribution method based on alarm confidence as described in claim 7, characterized in that, The first node among the external associated nodes with suspicious operational behavior is identified as the root cause node, including: For each externally associated node, extract its corresponding operation behavior sequence in the security primitive causal graph. The operation behavior sequence is composed of the operation types in the directed edge attributes of the externally associated node and its descendant nodes in chronological order. The sequence of operational behaviors is matched with a preset attack chain behavior pattern library, which contains multiple attack behavior templates composed of standard operation type sequences. If at least one of the attack behavior templates exists, such that the matching degree between the operation behavior sequence and the attack behavior template exceeds a preset matching threshold, the corresponding external associated node is marked as a node with suspicious operation behavior. After processing all the external associated nodes, if there is at least one node marked as having suspicious operational behavior, the external associated node with the earliest event timestamp is determined as the root cause node.

9. The heterogeneous security event aggregation and attribution method based on alarm confidence as described in claim 1, characterized in that, After generating a complete causal chain of attack from the source of the attack to the target, it also includes: Extract all process node identifiers along the attack path from the complete attack causal chain to form a confirmed set of malicious process identifiers; The malicious process identifier set is fed back to a preset alarm anchoring optimizer, so that the alarm anchoring optimizer will prioritize anchoring newly received heterogeneous security alarms to process nodes belonging to the malicious process identifier set during subsequent anchoring processes.

10. The heterogeneous security event aggregation and attribution method based on alarm confidence as described in any one of claims 1-9, characterized in that, After generating a complete causal chain of attack from the source of the attack to the target, it also includes: The complete attack causal chain is analyzed, and all malicious process node identifiers and corresponding malicious operation behavior sequences on the attack path are extracted. The malicious operation behavior sequences are composed of the operation types in the directed edge attributes of the attack path in chronological order. Based on the malicious operation behavior sequence, a target response script is matched in a preset automated response script library and the execution of the target response script is triggered to block or isolate the process corresponding to the malicious process node identifier. After triggering the execution of the target response script, continuously monitor the process activities related to the malicious process node identifier in the security primitive cause-effect graph. If a new process or derived operation originating from the malicious process node identifier is detected within a preset observation period, it is determined to be an attack remnant or variant, and a new security event is automatically generated. The new process or derived operation is taken as the root cause node, and the root cause graph traversal is re-executed to update the complete attack cause-effect chain.

Images