A security event incremental attack chain association method and system

Abstract

The application provides a security event incremental attack chain correlation method and system based on double anchor chain state and asset adaptive dynamic window, which models the attack chain correlation as an active chain state machine, and realizes online incremental correlation from a security event stream to a trusted attack chain through unified event standardization and strong and weak entity layering, double anchor chain state maintenance, asset adaptive dynamic window generation, multi-window time constraint, entity shared relationship calculation, cross-stage context bridging judgment, and the cooperation of differentiated parallel chain rules. The double anchor mechanism separates the chain tail update from the anchor update permission, so that the semantic center does not deviate from the noise; the asset adaptive window considers the anti-noise and slow attack restoration ability; through the cross-stage bridging, the interpretable attack chain continuation is identified when the strong entity sharing is lacking, avoiding false parallel chain while retaining the real cross-stage attack chain.

Description

Technical Field

[0001] This invention relates to the field of network security technology, specifically to a method and system for associating incremental attack chains of security events based on dual-anchor chain states and asset adaptive dynamic windows. Background Technology

[0002] With the rapid development of cloud computing, the Industrial Internet, and enterprise digitalization, Security Information and Event Management (SIEM), Endpoint Detection and Response (EDR), Host Intrusion Detection System (HIDS), Network Detection (NDR), and log auditing platforms continuously generate massive amounts of security incidents. A single security incident typically reflects only a localized anomaly, while real attacks often span multiple stages, including initial access, command execution, credential access, lateral movement, persistence, and data leakage, and are dispersed across different hosts, accounts, processes, time windows, and log sources. Due to log delays, out-of-order arrivals, missing fields, duplicate rule triggers, and significant background telemetry noise, incrementally reconstructing the attack chain from a continuous stream of security incidents has become a core technical challenge in security operations.

[0003] Existing attack chain association methods mostly rely on a single fixed time window and a small number of static entity fields for event aggregation, which has the following shortcomings:

[0004] (1) Existing methods mostly rely on a single time window or a unified association threshold for event aggregation. They usually only determine whether events are close in time, have the same host, IP, or user, and lack hierarchical state constraints on the first event, the last event, the most recent valid anchor point, and the most recent high-signal event. When background telemetry events or low-signal events arrive continuously, the last event is constantly refreshed, and subsequent events are still close to the latest last event and continue to be merged into the same chain, causing the attack chain to be lengthened by weak evidence and forming a long chain drift. In scenarios with out-of-order logs, alarm delays, and a lot of background telemetry, relying solely on the most recent event for judgment can also easily lead to incorrect associations.

[0005] (2) Existing methods typically use the same or similar chaining rules for background telemetry events, low-signal events, and high-signal events, and often employ fixed time thresholds, without fully considering the differences in background noise, business criticality, and historical alarm density among different assets. Uniform chaining rules and time thresholds can easily lead to background events being mistakenly included in the attack chain, low-signal events being dragged into the chain state, and resulting in excessive merging of high-noise assets, while slow penetration on low-noise critical assets is prematurely separated.

[0006] (3) Existing methods lack sufficient differentiation in entity sharing relationships, failing to distinguish the association strength of entities such as file hashes, malicious intelligence markers, session identifiers, commands, processes, file paths, rule numbers, asset types, and log sources. Existing attack phase-based analysis methods often treat phase order as a static display or rigid filtering condition. For events with only weak context sharing, direct chaining can easily lead to erroneous chaining, while complete discarding may result in the loss of valuable auxiliary evidence. In advanced persistent threat attacks, scenarios with "entity replacement and phase continuity" can easily split the same attack process into multiple isolated alerts by relying solely on the same host, same IP, same user, or strong entity sharing, while relying solely on loose aggregation based on the same business, same network segment, or same phase can easily lead to unrelated events being mistakenly merged into the same attack chain. Therefore, existing methods lack a mechanism for interpretable bridging and phase rollback control that combines attack phase evolution, asset context, access path, weak entity context, and threat intelligence clues.

[0007] (4) Existing methods lack the ability to reset chains for new high-signal events and also lack structured processing of cached events, critical events, and verification reasons. New attack starting points may be mistakenly merged into the old chain simply because they are close in time or on the same host, resulting in excessively long chain spans, chaotic stage paths, and distorted risk assessments. For events that cannot be chained temporarily but have stage information, valid strong entities, or a certain signal strength, immediate filtering may cause missed associations, while unconditional retention will increase noise. In addition, existing offline attack graph or full history backtracking methods require scanning a large number of historical logs or rebuilding the graph structure after a new event arrives, resulting in high latency in single-event association processing, which is not conducive to real-time security operations.

[0008] In summary, existing technologies have not yet provided a method to achieve online incremental association of attack chains in a continuous security event stream through hierarchical maintenance of activity chain states, adaptive dynamic windows for asset contexts, differentiated sharing of strong and weak entities, and cross-stage context bridging. Summary of the Invention

[0009] To overcome the shortcomings of existing technologies, this invention provides a method and system for associating security event incremental attack chains based on dual-anchor chain states and asset adaptive dynamic windows.

[0010] The technical solution adopted by this invention to solve its technical problem is:

[0011] According to one aspect of this application, a method for associating incremental attack chains of security events based on dual-anchor chain states and asset adaptive dynamic windows is provided, comprising:

[0012] Transform multi-source heterogeneous original security events into a unified event object, and extract strong entity sets and weak entity sets;

[0013] Based on the historical behavior statistics and asset attributes of the assets to which the candidate events belong, an adaptive dynamic window is generated; for each candidate attack chain, a chain state consisting of the chain head event, chain tail event, most recent anchor event, and most recent high signal event is maintained, where the most recent anchor event and the most recent high signal event constitute a double anchor.

[0014] Perform multi-window time constraint judgment on candidate events and candidate attack chains based on the dynamic window and the chain state;

[0015] For candidate events and candidate attack chains that pass the time constraint, calculate the entity sharing relationship based on the strong entity set, weak entity set, and entity set maintained by the candidate attack chain.

[0016] The event type is determined based on the signal strength of the candidate event. Differentiated chain condition judgments are performed on the candidate events of different event types based on the entity sharing relationship and the cross-stage context bridging relationship. The cross-stage context bridging relationship represents the continuity relationship between the candidate event and the candidate attack chain when there is no direct strong entity sharing, based on at least one interpretable dimension among attack stage evolution, asset context, access path, threat intelligence clues or weak entity context.

[0017] For candidate events that meet the chain conditions, they are merged into the corresponding candidate attack chain and the chain state is updated. The update permission of the dual anchor points is determined by the event type and signal strength of the candidate events.

[0018] In one optional implementation, the step of converting multi-source heterogeneous original security events into a unified event object includes: performing field parsing, field name mapping, rule base or asset ledger completion and normalization processing on the original security events to generate a unified event object; performing validity verification, normalization and deduplication on the fields used for association; writing highly distinguishable information such as IP, process, command, file, domain name, session identifier and malicious intelligence marker into a strong entity set to represent association evidence that can directly confirm the continuation of the event; and writing information such as username, hostname, asset type, rule number, log source and attack stage into a weak entity set to supplement the asset, rule and stage context.

[0019] In one optional implementation, generating the adaptive dynamic window includes: generating a window adjustment coefficient based on the asset criticality of the asset to which the candidate event belongs, historical attack hit markers, normalized background noise flow rate, historical false alarm ratio, and normalized historical alarm density, wherein the window adjustment coefficient is expressed as:

[0020]

[0021] in, This indicates that the calculation results will be restricted to... to Within the range, , , , and These represent, in order: asset criticality, historical attack hit markers, normalized background noise flow rate, historical false alarm rate, and normalized historical alarm density. , , , and To adjust the weights;

[0022] The preset basic window set is scaled using the window adjustment coefficient to generate a dynamic ordinary time window, a dynamic anchor point time window, a dynamic chain maximum span window, and a dynamic signal break window.

[0023] In one optional implementation, the multi-window time constraint determination includes: for candidate events For each candidate attack chain, calculate the normal time difference between the candidate event and the chain tail event, the anchor time difference with the most recent anchor event, and the total chain span after merging the event; when linking across assets, use the stricter value in the dynamic window of the relevant asset; the time constraint is passed if the following conditions are met simultaneously:

[0024]

[0025] in, , and These are the ordinary time window, anchor point time window, and chain maximum span window used in this judgment, respectively; the dynamic signal break window does not replace the above three constraints, but is used for subsequent new chain seed reset, low signal proximity judgment, and high signal continuity control.

[0026] In one optional implementation, the computing entity sharing relationship includes:

[0027] Based on the entity set maintained cumulatively from candidate events and candidate attack chains, strong entity sharing scores are calculated. Shared score with weak entities And a comprehensive entity-shared score is generated by reducing the number of weak entities:

[0028]

[0029] in, This is a weak entity reduction factor used to limit the impact of weak context on association results; entity relationships are reduced based on shared set and shared score. Mark as strong sharing, weak sharing, or no sharing;

[0030] When direct strong entity sharing between candidate events and candidate attack chains is insufficient to support chaining alone, the cross-stage context bridging relationship is judged according to the following four thresholds. :

[0031] First, the candidate events have passed the time constraints and are not background telemetry events;

[0032] Second, the signal strength of the candidate event reaches the bridging signal threshold, or the candidate event has a clear attack phase;

[0033] Third, the attack phase of the candidate event can be reasonably connected to the current phase of the candidate chain—belonging to the same phase supplement, reasonable advancement or preset allowed backtracking combination, or belonging to the preset weak allowed backtracking combination and having strong entity continuation evidence—and the signal interval between the candidate event and the most recent high signal event of the candidate chain does not exceed the dynamic signal break window.

[0034] Fourth, the candidate event and the candidate chain have an interpretable bridging relationship in at least one dimension of asset context, access path, threat intelligence, or weak entity context: the asset to which the candidate event belongs and the existing assets of the candidate chain belong to the same business, the same asset group, the same network segment, or the same security domain; or the source asset, target asset, source IP, or target IP of the candidate event have an upstream or downstream access path relationship with the existing assets or existing IP of the candidate chain; or the candidate event and the candidate chain share attack tools, malicious intelligence tags, vulnerability numbers, external domain names, or attack technology clues; or the weak entity sharing score of the candidate event reaches the weak entity bridging threshold, or at least two of the following relationships—same asset, same rule, and same stage—are met simultaneously.

[0035] When all four thresholds are passed Set as If any threshold is not met, set to ;

[0036] The establishment of the candidate relationship indicates that it is still required to enter the subsequent stage of control and differentiated chain judgment; background telemetry events must not be incorporated into the attack chain solely based on bridging relationships.

[0037] In an optional implementation, the method further includes:

[0038] When a candidate event is a high-value event but not a background telemetry event or a low-signal event, and the signal interval between the candidate event and the most recent high-signal event in the candidate attack chain exceeds the dynamic signal break window, and the candidate event and the candidate attack chain lack a strong entity continuation relationship, and the candidate event and the candidate attack chain do not have a cross-stage context bridging relationship, the candidate event is marked as a new chain seed reset relative to the candidate attack chain; wherein, the high-value event is established when the candidate event is not a background telemetry event, not a low-signal event, and the signal strength is not lower than the high-signal threshold; the strong entity continuation relationship is established when the sharing relationship between the candidate event and the candidate attack chain is a strong sharing relationship, or the strong entity sharing set is not empty, or the strong entity sharing score is not lower than the strong entity continuation threshold;

[0039] When a candidate event meets the high-value event condition or the attack chain seed event condition, and there is no candidate attack chain among all candidate attack chains that pass the time constraint that simultaneously meets the following conditions, a new candidate attack chain is initialized with the candidate event: the candidate event has not been marked as a new chain seed reset relative to the candidate attack chain; and there is a non-shared entity relationship between the candidate event and the candidate attack chain, or there is a cross-stage context bridge relationship.

[0040] For candidate relationships that have not triggered a new chain seed reset, a phase rollback pruning judgment is performed: obtain the phase index corresponding to the attack phase of the candidate event and the phase index corresponding to the most recent valid phase of the candidate chain, and calculate the phase difference; when the candidate event has a clear attack phase, the candidate chain already has a valid phase path, the candidate event and the candidate chain lack a strong entity continuation relationship and there is no cross-phase context bridge relationship, and any of the following situations occur, the candidate event is rejected from being merged into the candidate attack chain - the phase difference is less than a negative value of the preset phase pruning threshold, or the phase transfer score calculated based on the phase difference and the phase rollback rule is 0, or the phase path risk score obtained by comprehensively considering the phase rollback magnitude, the phase transfer score and the entity sharing score is not lower than the preset phase path risk pruning threshold;

[0041] Specifically, when a candidate event and a candidate chain have the strong entity continuation relationship or the cross-stage context bridging relationship, pruning will not be directly triggered due to stage rollback.

[0042] In one optional implementation, the differentiated parallel chain condition determination includes:

[0043] For background telemetry events, the following conditions are adopted: strong entity continuity relationship, same asset relationship, tightened chain tail and anchor point time constraints, and comprehensive chain connection score not lower than the background telemetry chain connection threshold.

[0044] For low-signal events, chaining can be performed through a strong entity continuation path—which requires satisfying the following conditions: strong entity continuation relationship, entity sharing score not lower than the low-signal entity sharing threshold, phase consistency score not lower than the low-signal phase threshold, and comprehensive chaining score not lower than the low-signal chaining threshold; or, chaining can be performed through a supplementary path with weak sharing that is close to high-signal evidence—which requires simultaneously satisfying the following conditions: weak sharing relationship, not belonging to a strong entity continuation relationship, same asset relationship, same phase relationship, signal interval not exceeding the dynamic signal break window, tightened chain tail time constraint, and comprehensive chaining score not lower than the low-signal weak sharing chaining threshold.

[0045] For ordinary high-signal events, chaining can be performed via a strong entity-dominated path—which requires satisfying the following conditions: strong entity continuation relationship, phase consistency score not lower than the high-signal strong entity phase threshold, and comprehensive chaining score not lower than the high-signal strong entity chaining threshold; or, chaining can be performed via a constrained weak-sharing path—which requires simultaneously satisfying the following conditions: weak-sharing relationship, not belonging to a strong entity continuation relationship, entity sharing score not lower than the high-signal weak-sharing entity score threshold, phase consistency score not lower than the high-signal weak-sharing phase threshold, signal strength not lower than the high-signal threshold, same asset relationship, and comprehensive chaining score not lower than the high-signal weak-sharing chaining threshold; or, chaining can be performed via a cross-phase context bridging path—which requires simultaneously satisfying the following conditions: cross-phase context bridging relationship, no phase rollback pruning triggered, signal interval not exceeding the dynamic signal break window, phase consistency score not lower than the high-signal bridging phase threshold, and comprehensive chaining score not lower than the high-signal bridging chaining threshold.

[0046] When a candidate event can be incorporated into multiple candidate attack chains, the comprehensive chain-merging score is expressed as:

[0047]

[0048] The four terms in the formula are, in order, the overall entity sharing score, the stage path consistency score, the event signal strength, and the auxiliary consistency score. to The weights are non-negative and their sum is 1; the candidate chain with the highest comprehensive chain-linking score and that reaches the chain selection threshold is selected as the chain-linking target; if the difference between the highest score and the second highest score is less than the discrimination threshold, the strong entity sharing score, comprehensive entity sharing score, time distance and stage consistency score are compared in turn for secondary discrimination. If it is still uncertain, it is transferred to pending review.

[0049] In one optional implementation, the update chain state includes: after the events are merged, deduplication is performed by identifier and sorted by event time, and the chain head event, chain tail event, asset set, entity set, stage path and dual anchor points are updated; the dual anchor points are not updated for background telemetry events and ordinary low signal events.

[0050] For candidate events that do not meet the chain-connection conditions and seed conditions but still have security value, write them into a short-term cache queue and re-execute the chain-connection judgment after the chain state of the candidate attack chain is updated.

[0051] For cached events that have expired but have not yet been merged into any candidate attack chain and still have a clear attack phase, a valid strong entity, or have reached the strength of a signal to be reviewed, a review record is generated. For candidate events or candidate relationships where multiple candidate chains have similar scores and lack strong entity continuation, where stage rollback pruning events still reach the strength of a signal to be reviewed, where the number of missing key fields reaches a threshold and the malicious marking score is high, or where weak sharing has not met the chain merging conditions but at least one of the same asset, the same rule, or the same stage is met, a review record is generated. The review record includes at least an event identifier, associated candidate chain, review reason code, and review prompt.

[0052] According to another aspect of this application, the present invention provides a security event incremental attack chain association system based on dual-anchor chain states and asset adaptive dynamic windows, comprising:

[0053] The event standardization module is used to convert multi-source heterogeneous original security events into unified event objects and extract strong entity sets and weak entity sets;

[0054] The dynamic window generation module is used to generate adaptive dynamic windows based on the historical behavior statistics and asset attributes of the assets to which the candidate events belong.

[0055] The chain state maintenance module is used to maintain the chain state for each candidate attack chain, consisting of the chain head event, chain tail event, most recent anchor event, and most recent high signal event, where the most recent anchor event and the most recent high signal event constitute a double anchor.

[0056] The multi-window time constraint module is used to perform multi-window time constraint judgment on candidate events and candidate attack chains based on the dynamic window and the chain state.

[0057] The entity sharing relationship calculation module is used to calculate the entity sharing relationship based on the strong entity set, weak entity set, and entity set maintained by the candidate events and candidate attack chains that have passed the time constraint.

[0058] The differentiated chain judgment module is used to determine the event type based on the signal strength of the candidate event, and to perform differentiated chain judgment on the candidate events of different event types based on the entity sharing relationship and the cross-stage context bridging relationship. The cross-stage context bridging relationship represents the continuity relationship between the candidate event and the candidate attack chain when there is no direct strong entity sharing, based on at least one interpretable dimension among attack stage evolution, asset context, access path, threat intelligence clues or weak entity context.

[0059] The chain state update module is used to merge candidate events that meet the chain merging conditions into the corresponding candidate attack chain and update the chain state, wherein the update permission of the dual anchor points is determined by the event type and signal strength of the candidate events.

[0060] The positive effects of this invention:

[0061] This invention improves the attack chain construction results in terms of real-time performance, stability, noise resistance, and interpretability through the synergistic effects of chain state hierarchical constraints, asset context adaptation, entity relationship differentiation quantification, stage semantic joint judgment, and review closed-loop mechanism. The specific description is as follows:

[0062] 1. Improve the stability of incremental correlations and the adaptability to heterogeneous assets.

[0063] This invention simultaneously maintains the chain head event, chain tail event, most recent anchor point event, and most recent high-signal event, and combines ordinary time difference, anchor point time difference, total chain span, and signal interval constraints to limit attack chain extension, separating chain tail updates from dual anchor point updates. This avoids long chain drift caused by continuous refresh of the chain state from background telemetry and low-signal events. The asset adaptive dynamic window adjusts the association range based on asset criticality, background noise flow rate, historical alarm density, false alarm ratio, and attack hit rate. It tightens the chain merging conditions for high-noise assets and appropriately widens the window for low-noise critical assets, thus balancing noise resistance with low-frequency, slow attack recovery and improving adaptability to out-of-order logs and delayed alarms. In typical simulation test scenarios, compared to the fixed single-window aggregation method, the long chain drift and false chain merging failure rate can be reduced by approximately 35% to 55%, and the association accuracy in out-of-order logs and delayed alarm scenarios can be improved by approximately 30% to 50%. For low-frequency, slow penetration or APT scenarios, the attack chain complete recovery rate and critical threat recall rate can be improved by approximately 25% to 40%.

[0064] 2. Improve the accuracy, completeness, and boundary clarity of attack chain associations.

[0065] This invention quantifies strong and weak entities separately and sets different admission conditions and dual-anchor update permissions for background telemetry events, low-signal events, and ordinary high-signal events, reducing the risk of background events and weakly shared events mistakenly entering the attack chain. When direct strong entity sharing is lacking, it combines attack phase evolution, asset business relationships, access paths, threat intelligence, and weak entity context to determine interpretable cross-phase continuity relationships, thereby preserving cross-asset and cross-phase attack processes where entities change but attack semantics remain continuous. At the same time, it prunes events with obvious phase regressions and lacking reliable continuity evidence, and triggers new chain seed resets for high-value events that are disconnected from the old chain signal and lack continuity relationships, preventing different attack processes from being incorrectly spliced ​​together or new attack starting points from being absorbed by the old chain. In typical simulation test scenarios, the proportion of background telemetry false links can be reduced by about 40% to 60%, the association error caused by low signal events dragging the chain state can be reduced by about 30% to 45%, the number of weak sharing false links can be reduced by about 25% to 50%, the association integrity of cross-stage attack chains can be improved by about 20% to 45%, the stage path disorder rate can be reduced by about 35% to 55%, and the signal-to-noise ratio of the output attack chain can be improved by more than 30%.

[0066] 3. Improve online processing efficiency and result interpretability

[0067] This invention maintains only a limited number of active candidate chains and can filter comparison chains using time, asset, and entity indexes. It eliminates the need for a full backtracking of historical logs or reconstruction of the complete attack graph every time a new event arrives, thus reducing historical data scanning overhead and real-time processing latency. For events that cannot be automatically merged but still have security value, a short-term caching mechanism, re-triggering after chain state changes, and a review mechanism are employed to record associated candidate chains, review reason codes, evidence summaries, and review prompts. This reduces missed associations caused by directly discarding critical evidence and provides security operations personnel with structured and interpretable manual review data. In typical simulation testing scenarios, the amount of invalid manual checks can be reduced by approximately 20% to 40%, and the probability of critical events being supplemented by subsequent chains can be increased.

[0068] Overall, this invention, through the joint constraints of time, chain state, asset context, entity relationships, stage semantics, and verification mechanisms, makes the output attack chain more stable, accurate, complete, and with clear boundaries, better meeting the needs of real-time analysis and security operations for continuous security event streams. The quantitative data above represent the expected performance range of this invention compared to traditional fixed single-time-window aggregation methods under typical simulation test scenarios. Specific performance can be verified and adjusted based on log size, rule quality, asset type distribution, attack sample composition, threshold configuration, and deployment environment. Attached Figure Description

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

[0070] Figure 1 This is a schematic diagram comparing the differences between traditional single-window processing and the dual-anchor-point dynamic window processing of this invention.

[0071] Figure 2 This is a schematic diagram of the overall process of the incremental attack chain association method for security events of the present invention. Detailed Implementation

[0072] The prior art and the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. 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.

[0073] Furthermore, to better illustrate this application, numerous specific details are provided in the following detailed embodiments. Those skilled in the art should understand that this application can be implemented without certain specific details. In some instances, methods, means, components, and circuits well-known to those skilled in the art have not been described in detail in order to highlight the main points of this application.

[0074] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0075] like Figure 1 As shown, traditional single-window processing typically aggregates candidate events based on their temporal proximity or entity similarity with the most recent events. This can easily lead to long chain drift due to continuous refresh of the chain tail by background telemetry or low-signal events, and may also merge new attack events lacking reliable continuity into the old chain. This invention, based on event standardization and signal strength identification, introduces an asset-adaptive dynamic window and maintains chain head events, chain tail events, most recent anchor events, and most recent high-signal events for candidate attack chains. The processing direction of events is determined by joint constraints of time, entity, stage, and event type.

[0076] Reference Figure 2This invention application provides an embodiment of a method for associating incremental attack chains of security events based on dual-anchor chain states and asset adaptive dynamic windows. This method can be deployed on security monitoring platforms, log auditing platforms, SIEM, XDR, EDR, NDR, or other data sources capable of generating security alerts and behavior logs. This invention is not limited to specific security platform types or specific log formats.

[0077] This embodiment generally includes the following steps: data acquisition, unified event standardization, event semantic recognition, event signal strength calculation, asset context statistics, dynamic window generation, activity chain state maintenance, multi-window time constraints, shared entity relationship calculation, cross-stage context bridging, new chain seed reset judgment, stage rollback pruning, differentiated event chain merging judgment, candidate chain selection, chain state update, short-term caching, queue to be reviewed, attack chain output, and result display.

[0078] During event correlation, unified event objects are categorized into strong and weak entities. An adaptive dynamic window adjusts the correlation range based on asset criticality, background noise, historical alarm density, false alarm rate, and attack hit rate. The chain head controls the total chain span, while the chain tail represents local continuity. The most recent anchor point and the most recent high-signal event form dual anchor points to prevent low-value events from continuously altering the semantic center of the attack chain. Candidate events are constrained by multiple windows and then further evaluated based on entity sharing, stage evolution, asset or business relationships, access paths, threat intelligence, and the context of weak entities to determine if an interpretable chain continuation exists.

[0079] For high-value events that experience a signal break with the old chain and lack evidence of continuation, the system triggers a new chain seed reset; for events with significant stage regression and lacking strong entity continuation and contextual bridging, pruning is performed. Subsequently, differentiated chain merging is performed according to the different evidence requirements of background telemetry, low-signal, and ordinary high-signal events, and candidate chain selection, caching, or pending review are conducted for ambiguous multi-chain events. After the event is merged, the event sequence, asset and entity sets, stage paths, and dual anchors are updated.

[0080] This method performs online incremental processing of continuous security event streams, maintaining only a limited number of active candidate chains and filtering chains for comparison by time, asset, or entity indexes, without requiring a full backtracking of historical logs or reconstruction of the complete attack graph. By closure of expired active chains, short-term caching, and re-triggering after chain state changes, it reduces the overhead of historical data scanning and real-time processing latency, while retaining events that temporarily lack corroborating evidence but still have security value.

[0081] according to Figure 2Steps S1 to S10 shown in this embodiment are divided into four stages: S1 to S3 complete event preparation; S4 to S6 complete candidate chain initialization and time, entity, and bridging relationship judgment; S7 to S9 complete new chain reset, stage pruning, differentiated chain merging, and event destination decision; S10 completes chain state and dual anchor point update, cache re-triggering, generation of pending verification, and attack chain output. Related parameters are configurable.

[0082] It should be noted that the thresholds, weights, base windows, window adjustment ranges, and empirical values ​​used in subsequent steps are all preferred implementation parameters and can be configured or incrementally adjusted based on network topology, asset type, log volume, rule quality, historical false positives, attack verification results, and security operation strategies. Specific parameter changes do not affect the implementation of core mechanisms such as unified event objects, dual-anchor chain states, asset adaptive dynamic windows, multi-window time constraints, entity relationships, phase control, and differentiated chaining.

[0083] S1. Multi-source security incident collection and incident standardization

[0084] Multi-source heterogeneous original security events are converted into unified event objects, and strong entity sets and weak entity sets are extracted.

[0085] Specifically, raw security events are read from security monitoring platforms, log auditing platforms, or other security data sources. Based on differences in field names, formats, and completeness among different log sources, field parsing, field mapping, necessary rule base or asset ledger completion, and normalization are performed to generate a unified event object. .

[0086] The The object carries the event identifiers, time, assets, network, identity, behavior, rules, entities, and computational judgment information required for subsequent attack chain associations, and can be represented as:

[0087]

[0088] in, , For event identifier and time fields; , , For asset fields; , , , and For network and identity fields; , , , , , For behavior fields; , , , , , This is the field for rules and log sources.

[0089] Perform case unification, path or command normalization, format validation, and deduplication on the above fields, and extract as needed for subsequent processing. , , and This eliminates the differences in representation of the same entity from multiple source logs. Used to hold extended security fields, where This indicates the extended host identifier; other extended fields are extracted according to the following strong and weak entity sets.

[0090] The fields used for association are validated, normalized, and deduplicated. High-discrimination information such as IP, process, command, file, domain, session identifier, and malicious intelligence markers are written into the strong entity set to represent association evidence that can directly confirm the continuation of the event. Information such as username, hostname, asset type, rule number, log source, and attack stage are written into the weak entity set to supplement the asset, rule, and stage context. Thus, in subsequent steps S5-S10, when judging the association between candidate events and candidate attack chains, the existence of direct entity continuation can be determined based on the above strong entity set, and auxiliary context information can be obtained based on the weak entity set. The two together constitute the evidence input for entity sharing relationship calculation (step S6) and differentiated chain judgment (step S9).

[0091] Specifically, it generates based on the original fields, normalized results, and extended security fields. The Including strong entity sets and weak entity set ,Right now:

[0092]

[0093] in, For a strong entity set, ( ) represents a set of weak entities; the former is used for reliable associations, and the latter is used for auxiliary context. The corresponding fields are as follows:

[0094]

[0095]

[0096] Write ( ) and ( The field values ​​must be removed from null and invalid placeholder values, formatted, normalized, and deduplicated. , , and These represent the attack phase, signal strength, low signal marker, and background telemetry marker, respectively. They can be initialized in this step and calculated in step S2. If a field is missing, it is set to a null value or a default value, and the subsequent score or anchor point update qualification is reduced.

[0097] S2. Event Signal Strength and Event Type Identification (Determining the event type based on the signal strength of candidate events)

[0098] Based on the unified event object generated in step S1 This step sequentially completes attack phase identification, signal strength calculation, and event type determination. Specifically, it first determines the attack semantic location of the event, then evaluates the reliability of its evidence, and finally classifies it into background telemetry, low-signal, or ordinary high-signal events. Output , , , , and This serves as the input for subsequent stage path, differentiated chaining, new chain seed, and dual anchor point update judgment.

[0099] (1) Attack Phase Identification. If the rule base, detection engine, or security product has provided attack phase labels, attack technique labels, or ATT&CK technique numbers, these should be used to determine the attack phase. Only when explicit labels are missing, based on candidate events. With each candidate attack phase Match scores are calculated across eight dimensions: rule description, rule grouping, event action, process, command, file, network, and threat intelligence.

[0100]

[0101] and These correspond to rule descriptions and rule groups, respectively. Corresponding event actions; and These correspond to process and command characteristics, respectively. Corresponding file characteristics; Corresponding network characteristics such as IP address, domain name, or URL; This corresponds to characteristics of malicious intelligence, vulnerabilities, or attack tools. Each function takes a value between 0 and 1, with higher values ​​indicating stronger support for the candidate stage. to For the preset weights, satisfy .

[0102] Calculate scores for all candidate stages and select the stage with the highest score. .when and season Otherwise, This is to avoid forcibly assigning an attack phase when there is insufficient evidence or when scores are close across multiple phases.

[0103] express The index in the preset attack phase sequence is used for subsequent phase path updates and phase rollback judgments; This indicates the reliability of the stage identification results. Explicit labels, multi-field inferences, and weak stage clues correspond to high, medium, and low values, respectively. for hour, Take 0.

[0104] (2) Calculation of event signal strength. Event signal strength This score is used to measure the reliability of candidate events as evidence of the main attack chain. Rule level, stage credibility, attack semantics, entity integrity, and malicious characteristics improve the score, while missing key fields decrease it.

[0105] Among them, entity integrity score The sufficiency of physical evidence in an event that can be used for subsequent correlation is determined in one implementation by the following formula:

[0106]

[0107] and These represent the number of valid strong entities and the number of valid weak entities after verification, normalization, and deduplication in step S1, respectively. Strong entity pairs The contribution of strong entities is higher than that of weak entities, in order to reflect the difference in the reliability of the association between the two types of entities.

[0108] Comprehensive rule level normalized score Stage confidence score Rule description validity score Entity integrity score Malicious marking scores and field missing penalty Calculate the event signal strength:

[0109]

[0110] Depend on Compared to the highest level of the access rule system Normalization yields the result; It is used to reflect the clarity of attack semantics in rule descriptions, thereby distinguishing between general descriptions and descriptions that can directly explain attack behavior; Used to reflect the credibility of direct malicious evidence such as malicious intelligence, vulnerability numbers, or attack tools; Based on the number of missing key fields Confirmed, among which Used to measure the incompleteness of event fields. This indicates that the results will be limited to the range of 0 to 100. The weights and scoring ranges can be configured according to the log source, rule quality, and historical validation results.

[0111] (3) Event type determination. Event type is determined by... This serves as the primary basis for judgment, and is further corrected based on whether the log source belongs to the preset background telemetry type. Because... , , , , and This has already been reflected in In this step, instead of repeatedly combining intermediate variables to set multiple sets of subdivision conditions, the unique event type is determined according to the order of "background telemetry priority, low signal priority, and the rest as ordinary high signal events".

[0112] Background telemetry events are those generated by general telemetry or routine business operations and are insufficient to serve as evidence of the main attack chain. Firstly, based on... , Alternatively, rule labels can be used to determine whether a candidate event belongs to a preset background telemetry source; if it belongs to that source, and Then Set to true. A high-signal threshold is used to classify event types. Events of this type are subsequently subject to strict chaining conditions and the dual anchor points are not updated.

[0113] Low-signal events have a certain security context, but existing evidence is insufficient to serve as primary evidence independently. If the condition is false, Then Set to true. This type of event can be used as supporting evidence in the association, but it usually does not update the dual anchor points.

[0114] when In such cases, candidate events are treated as ordinary high-signal events. This type indicates that the event has the basic strength to serve as candidate evidence for the main line of the attack chain, but it does not necessarily mean that it will become a seed for a new chain or an update double anchor point; further judgment is still needed based on entity continuation, phase consistency, and corresponding update thresholds.

[0115] Through the above methods, event type determination directly follows The calculation results are used to retain the correction effect of the log source on background telemetry events, so that the aforementioned scoring criteria are consistent with the subsequent classification results.

[0116] S3, Asset Context Statistics and Adaptive Dynamic Window Generation

[0117] An adaptive dynamic window is generated based on the historical behavior statistics and asset attributes of the candidate event's asset. Specifically, firstly, the asset to which the candidate event belongs is determined. Historical behavior statistics and asset attributes of the asset are obtained from the asset ledger, CMDB, historical event database, false alarm annotation database, or historical handling results. The historical behavior statistics include at least the number of historical events, the number of historical alarms, the number of historical false alarms, and historical attack hit markers, and background noise flow rate, historical alarm density, and historical false alarm ratio are calculated accordingly. The asset attributes include at least asset criticality (obtained by asset importance normalization) and asset type. Then, the above historical behavior statistics and asset attributes are combined into a window adjustment coefficient. , The larger the value, the more of a correlation observation range is required for the asset. A smaller value indicates a higher risk of event noise or false alarms for the asset, necessitating a tighter window; The preset basic ordinary time window, basic anchor point time window, basic chain maximum span window, and basic signal break window are scaled to generate a dynamic ordinary time window corresponding to the asset. Dynamic anchor point time window Maximum span window of dynamic link and dynamic signal break window The four types of dynamic windows described above will each assume different responsibilities in subsequent steps: This is used to constrain the local temporal continuity between candidate events and the tail event (step S5). This is used to constrain the deviation of candidate events from the nearest anchor event (step S5). This is used to limit the total span of the attack chain from the head of the chain to the current candidate event (step S5). Used to determine whether a signal break has occurred between a candidate event and the most recent high-signal event (step S7 new chain seed reset and step S9 differentiated chain merging).

[0118] The following is a more detailed description of this step.

[0119] This step addresses the issue that a fixed time window can easily lead to the over-merging of high-noise assets and the premature dismantling of slow-attack targets on low-noise critical assets when different assets differ in background noise, business criticality, and historical alarm density. Based on candidate events... Determine its assets To form asset context Calculate the window adjustment factor Based on this, four types of dynamic windows are generated.

[0120] Window adjustment factor The larger the value, the more of a correlation observation period is required for the asset; A smaller value indicates a higher risk of event noise or false alarms for the asset, requiring a tighter window. This allows the time constraint to adapt to the asset context without altering the subsequent chain-connection rule structure.

[0121] (1) Asset identification and context statistics. Prioritize asset identification based on candidate events. As an asset index; if this field is missing, it can be used. In , Or other fields that can uniquely identify the asset. The asset context does not need to be written entirely to the Uniform Event Object; it can be obtained by querying or statistically analyzing the asset ledger, CMDB, business configuration, historical event database, false alarm annotation database, or historical disposal results based on the above indexes.

[0122] In one implementation, It should include at least the asset identifier, asset type, asset criticality, business category, number of historical events, number of historical alarms, number of historical false alarms, historical attack hit markers, and statistics and window adjustment coefficients calculated from the above information, which can be expressed as:

[0123]

[0124]

[0125] For the reason The asset criticality obtained by normalization ranges from 0 to 1; This indicates whether the asset has been confirmed to have been hit by an attack within a preset historical period. Let the historical statistical period be... The background noise flow rate, historical alarm density, and historical false alarm ratio are respectively:

[0126]

[0127]

[0128]

[0129] and These respectively reflect the event flow rate and alarm density per unit time. This reflects the proportion of historical alerts that were confirmed or marked as false alarms. For ease of comparison across different assets, [the percentage will be...]. and Normalized to the preset reference value and Reference values ​​can be determined based on the global historical distribution or the historical distribution of similar assets.

[0130] (2) Calculation of window adjustment factor. The window adjustment factor comprehensively reflects asset importance, past attack risk, and current noise level. In one implementation, it is calculated according to the following formula:

[0131]

[0132] and Control the impact of asset criticality and historical attack hits on the window's relaxation effect; , and The effects of controlling the background noise flow rate, historical false alarm ratio, and historical alarm density on window tightening are respectively controlled. Limit the calculation results to to To prevent the window from being infinitely enlarged or compressed, the weights can be configured based on log size, rule quality, and security operation strategies.

[0133] When the number of historical events for an asset is insufficient to support stable statistics, a cold start approach is adopted. Less than the minimum sample threshold , can make This allows the asset to temporarily use the base window; alternatively, initial adjustment coefficients can be generated based on the asset's criticality and type.

[0134]

[0135] This is an asset type adjustment item used to differentiate between assets such as critical servers, general terminals, and high-frequency network equipment when historical data is insufficient. For assets that are not registered or cannot be matched with the asset ledger, a temporary asset context is generated and a neutral window is used; when the number of historical events reaches [a certain threshold], [the asset type adjustment item is applied]. Alternatively, after the asset ledger information is completed, the statistics will be recalculated based on the aforementioned figures. .

[0136] (3) Dynamic window generation. Let the basic ordinary time window, the basic anchor point time window, the basic chain maximum span, and the basic signal breakage window be respectively... , , and Then assets The corresponding dynamic window is:

[0137]

[0138]

[0139]

[0140]

[0141] Used to constrain the local temporal continuity between candidate events and the tail event; Used to constrain the deviation of candidate events from the nearest anchor event; Used to limit the total span of the attack chain from the first event to the current candidate event; Used to determine whether a signal break has occurred between a candidate event and the most recent high-signal event. The four types of windows have different functions, but together they control the continuation, splitting, and generation of new attack chains.

[0142] Basic window , The independent upper and lower limits of various dynamic windows can be configured to prevent windows from becoming too large or too small due to extreme asset statistics. After this step, a set of dynamic windows is generated for the candidate events:

[0143]

[0144] This set is used in subsequent steps for multi-window time constraints, new chain seed reset, stage rollback auxiliary judgment, and chain state update, respectively. High-noise, high-false-positive assets correspond to smaller... And stricter time constraints; low-noise key assets correspond to larger... This is to preserve the ability to correlate with low-frequency, slow attacks.

[0145] S4. Attack Chain Seed Event Identification and Chain State Initialization

[0146] This step follows the event type and signal strength output in step S2, and the event generated in step S3. This involves completing the seed qualification marking for candidate events and the initial initialization of the new chain state. Two types of concepts need to be distinguished: This indicates whether the event itself possesses the basic qualifications to serve as the starting point of a new chain; the new chain seed reset is a relationship judgment formed by comparing a candidate event with an existing candidate chain, and the two do not use the same set of conditions.

[0147] (1) Seed event eligibility assessment. Step S2 has already comprehensively reflected factors such as rule level, stage credibility, attack semantics, entity integrity, malicious characteristics, and field missingness in the... Therefore, these intermediate variables will not be expanded again in this step, as they are already included in the event types. A candidate event is marked as a seed event when the following conditions are met simultaneously:

[0148]

[0149]

[0150] in, It acts directly on The seed event signal strength threshold can typically be configured to be no lower than the high signal threshold in step S2. This condition means that only events that have been determined by S2 to be candidate evidence for the main line and whose signal strength meets the requirements for chain establishment are eligible for seed status. It only indicates that it "can be used as a starting point for a new chain" and does not immediately exclude existing candidate chains in this step.

[0151] when If an event meets the time, entity, and phase association conditions of an existing candidate chain, it will be preferentially merged into the existing chain; only when there is no existing chain that can receive the event will a new chain be initialized based on this qualification. This avoids repeatedly splitting high-signal events in the same attack process into multiple chains.

[0152] (2) Connection with New Chain Seed Reset. New chain seed reset is used to prevent new independent attack rounds from being absorbed by the old chain. Its judgment is based on the relationship between candidate events and specific candidate chains. Subsequent steps will be based on the relationship between candidate events and the most recent high-signal events. Dynamic signal break window Strong entity continuity relationship and The following judgment is made: when the signal interval exceeds the window, there is a lack of strong entity continuation, and there is no cross-stage context bridge, the corresponding relationship is marked as... If the event should be reset relative to all comparable candidate chains, then generate Then proceed to the new chain initialization. The above relationship determination will be elaborated in the subsequent new chain seed reset step. This step only clarifies the difference between it and the general seed qualification, and through... The dynamic window prepares the chain state for this judgment.

[0153] (3) Chain state initialization. When a candidate event cannot be merged into a suitable old chain, or when a new chain needs to be created due to the reset of the new chain seed, a unique chain state is generated. And initialize the following candidate attack chain states:

[0154]

[0155] in, , , and These are the chain head event, chain tail event, most recent anchor point event, and most recent high signal event, with the latter two constituting a double anchor point; Preservation of relevant assets; , and Save the cumulative strong entities, weak entities, and all entities; , and Save the stage path, event sequence, and currently used dynamic window respectively.

[0156] When initializing a new candidate attack chain, the dynamic normal time window, dynamic anchor time window, dynamic chain maximum span window, and dynamic signal break window corresponding to the asset to which the seed event belongs are respectively used as the initial chain-level dynamic windows of the candidate attack chain. , , and ,Right now:

[0157]

[0158] in, This indicates the asset to which the seed event belongs. The chain-level dynamic window is redefined in step S10 based on the set of assets involved in the candidate attack chain after subsequent events are incorporated into the candidate attack chain.

[0159]

[0160]

[0161]

[0162]

[0163] like Not for Then write this stage to Otherwise, initialize the stage path to empty or record it. This will be updated after subsequent events with clearly defined attack phases are included.

[0164] (4) Subsequent effects of chain states. Chain head events are used to control the total chain span, chain tail events are used to determine local temporal continuity, recent anchor events are used to maintain the semantic center of the attack chain's main line, and recent high-signal events are used to calculate the signal interval between high-value evidence and support the reset of the new chain seed. Seed events serve as the above four types of event states simultaneously during new chain initialization; after subsequent events are incorporated, the chain tail can be updated with the events, while whether the dual anchors are updated depends on the event type, signal strength, and association conditions.

[0165] Add the candidate attack chain after initialization When subsequent events arrive, candidate chains are selected from this set, and based on... , The system implements multi-window time constraints, entity sharing, stage judgment, and differentiated chaining for entity sets and stage paths.

[0166] (5) The destination of events that have not yet been established on a chain. If a candidate event has not obtained seed qualification and there is currently no candidate chain that can receive the event, but still has a clear attack phase, a valid strong entity, or a signal strength that meets the cache requirements, then it is written to the chain. The judgment will be retried after the chain state is updated; background telemetry or low-signal events with weak attack semantics and entity evidence can be downweighted and filtered or only retained for statistical purposes; events with many missing fields, uncertain stages, or critical weak correlations with multiple candidate chains will enter the pending review process. The specific rules for cache re-triggering, expiration handling, and pending review records will be explained in the subsequent closed-loop processing steps.

[0167] This step outputs and after initialization and for the follow-up , And provide the required state for cache re-trigger judgment.

[0168] S5, Multi-window time constraints for candidate event parallel chaining

[0169] Perform multi-window time constraint judgment on candidate events and candidate attack chains based on the dynamic window and the chain state.

[0170] Specifically, this step, based on the dynamic window of step S3 and the chain state of step S4, processes candidate events. and Candidate chains in China Perform initial time screening. By simultaneously checking the local continuity of the chain tail, the distance to the nearest anchor point, and the total span of the chain after event merging, candidate relationships that are obviously discontinuous, deviate from the semantic center of the chain, or would abnormally lengthen the attack chain are excluded before step S6, and the output is... .

[0171] (1) Calculate the three types of time relationships. Let the time of the candidate event be... The head, tail, and nearest anchor of the candidate chain are: , and When events arrive in chronological order, the normal time difference... for:

[0172]

[0173] For delayed or out-of-order arrival events, Search for the most recently occurring events within the chain to avoid excluding events simply because they arrived later:

[0174]

[0175] Anchor Time Difference Represents the temporal distance between the candidate event and the semantic center of the chain; total chain span. This represents the duration from the earliest to the latest event in the chain after a candidate event is merged:

[0176]

[0177]

[0178] If there is already an out-of-order insertion event in the chain according to The earliest and latest times in the actual time are recalculated. , and Constrain local continuity, semantic center stability, and overall chain duration, respectively.

[0179] (2) Determine the actual usage window. The dynamic window generated in step S3 is used for the same asset scenario; for cross-asset scenarios, in order to avoid wide windows for high-noise assets, the candidate relationship is relaxed, and the candidate event belongs to the asset. The dynamic window is selected from the more stringent value between the dynamic window and the corresponding chain-level dynamic window currently maintained by the candidate attack chain. The chain-level dynamic window is determined during new chain initialization in step S4 and is re-determined in step S10 after subsequent events are incorporated into the candidate attack chain.

[0180]

[0181]

[0182]

[0183] in, , and These are used to determine the ordinary time difference, anchor point time difference, and total chain span, respectively. It is not used in the initial screening of this step, but is used for subsequent new chain reset and high signal evidence interval judgment.

[0184] (3) Implement multi-window time constraints. A candidate event and candidate chain pass the initial time screening if they simultaneously meet the following three conditions:

[0185]

[0186]

[0187]

[0188] When all three conditions are met If any one of them is not satisfied, Normal time difference, anchor time difference, and excessive total chain span indicate a lack of local continuity, deviation from the semantic center of the chain, or an abnormally extended chain duration, respectively.

[0189] Candidate chains that fail will not proceed to step S6; successful candidate chains will be retained until entity sharing, phase, and differentiated chain merging are determined. If multiple candidate chains pass simultaneously, all will be retained; if all active chains fail, the candidate event will be handled according to the seed qualification rules of step S4 and the subsequent rules for resetting, caching, or reviewing new chains.

[0190] S6, Shared Entity Relationship Calculation

[0191] For candidate events and candidate attack chains that pass the time constraint, the entity sharing relationship is calculated based on the strong entity set, weak entity set, and entity set maintained by the candidate attack chain.

[0192] Specifically, for step S5, the following conditions must be met. candidate events With candidate chain This step employs two layers of evidence to determine whether the two events might belong to the same attack process: first, a direct sharing relationship is established based on entity intersection; if direct strong entities are insufficient, a cross-stage bridging relationship is then established based on stage evolution, signal continuity, and interpretable context. Both types of results serve as inputs for subsequent new chain reset, stage pruning, and differentiated chain merging.

[0193] (1) Direct entity sharing relationship. Strong entity set of candidate events. and weak entity set Generated in step S1, candidate chains are cumulatively maintained. and . This indicates that a valid set of entities is obtained according to the verification, normalization, and deduplication rules in step S1; and These represent the strong and weak entities actually shared by both parties:

[0194]

[0195]

[0196] and Entity type Strong and weak entity weights. Strong entity weights reflect highly discriminative evidence such as file hashes, attack tools, malicious intelligence, vulnerability numbers, and session identifiers; weak entity weights measure auxiliary context such as usernames, hostnames, rules, asset types, and log sources. To prevent extremely small positive numbers with a denominator of zero, the corresponding shared score is:

[0197]

[0198]

[0199] Indicates the degree of strong entity coverage. Indicates the degree of proximity in the auxiliary context; This is the reduction factor for weak entities, used to ensure that weak entities can only supplement, not replace, evidence of strong entities. The overall shared score is:

[0200]

[0201] This is used to classify direct entity evidence between candidate events and candidate chains into three categories: strong sharing, weak sharing, and no sharing. To achieve strong entity sharing threshold, This is the threshold for weak entity sharing. The determination process first checks the strong sharing condition; if the strong sharing condition is not met, then the weak sharing condition is checked; if neither condition is met, it is classified as no sharing.

[0202] The criteria for determining strong sharing are:

[0203]

[0204]

[0205] Only if the strong sharing condition is not met should the weak sharing condition be checked:

[0206]

[0207]

[0208] If none of the above conditions are met:

[0209]

[0210] This indicates that there is already relatively reliable direct evidence of entity continuation, which can increase the priority of the candidate chain in subsequent steps; This indicates that only auxiliary context is shared, and further judgment needs to be made by combining event type, time, signal strength, and stage relationship; This indicates insufficient direct physical evidence, but it does not necessarily mean the attack chain is broken. For or The system continues to perform auxiliary consistency and cross-stage context bridging judgments to identify cases where entities change but attack semantics remain continuous.

[0211] (2) Auxiliary consistency relationship. This indicates that the asset to which the candidate event belongs is already in the candidate chain asset set; This indicates that both parties share a valid rule identifier, in which By effective and constitute; This indicates that the candidate event has a clearly defined attack phase, and that phase has already appeared in the candidate chain. The three components only provide the auxiliary context required for bridging;

[0212]

[0213]

[0214]

[0215] (3) Cross-phase context bridging. The advancement of the attack phase may be accompanied by changes in hosts, accounts, processes, IPs, or external infrastructure. Therefore, when direct sharing relationships are insufficient, it is also necessary to determine This variable indicates that although the candidate events lack sufficiently strong entity sharing, they still have an interpretable attack chain continuity in terms of time, stage, signal, and context.

[0216] A stage continuity marker used to compare candidate events. With candidate chain When the most recent effective phase is supplemented by the same phase, or when the phase proceeds in a reasonable order according to a preset sequence, or when a combination that allows for rollback is selected. When the combination is weakly permissible for regression, it is only considered when there is strong evidence of entity continuation. If valid stage information is missing or stage transitions are unacceptable, then... This marker only indicates that the stage paths can be continuous; it is not equivalent to the conclusion of chain concatenation.

[0217] High signal continuity marker; This represents the time interval between a candidate event and the most recent high-signal event in the candidate chain; The actual signal break window determined according to the strict cross-asset principle in step S5:

[0218]

[0219] Indicates the same business, asset group, network segment, or security domain; This indicates that the source / target asset or IP has an upstream / downstream relationship with the on-chain access path; This indicates the sharing of attack tools, malicious intelligence, vulnerability numbers, external domains, or clues to attack techniques. This indicates that the sharing of weak entities has reached the bridging threshold, or that at least two of the following relationships—same asset, same rule, and same stage—are met simultaneously.

[0220] This is the bridging signal threshold. Bridging conditions are determined layer by layer in the following order.

[0221] First, the time and event type thresholds. Candidate events should meet the following requirements. Furthermore, it is not a background telemetry event; only non-background events that are still within the valid correlation time range will continue to be evaluated.

[0222] Second, the threshold for evidence regarding candidate events. Should reach Or the candidate event has a clear This is to exclude ordinary logs that lack security semantics.

[0223] Third, the continuity threshold. and This means that the attack phases are reasonably connected, and there is no signal break between the candidate event and the most recent high-signal evidence.

[0224] Fourth, contextual threshold. , , or At least one of the following conditions must be met. When all four thresholds are passed, then... If any necessary threshold is not met, the value is false.

[0225] In summary, this step first obtains the results through shared sets and differentiated weights. This forms direct substantive evidence; when direct strong substantive evidence is insufficient, further judgments are made sequentially. , In addition to assets, access paths, threat intelligence, and weak entity context, we obtain Therefore, the direct sharing relation answers the question "Does the same entity exist?", while the bridging relation answers the question "Does the attack continue to be explainable after the entity changes?" Together, they form a complete judgment chain from strict evidence to supplementary evidence.

[0226] After this step is completed, it becomes a candidate event. With each candidate chain that passes the initial screening under time constraints Output entity shared computation results:

[0227]

[0228] in, In such cases, the chain-merging priority of the candidate chain is increased in subsequent steps; In such cases, a rigorous judgment needs to be made by combining the event type, time window, signal strength, and stage relationship. Typically, chains are not directly merged, but high-signal candidate events can proceed to step S7 for new chain seed reset judgment. If If the candidate relationship is not immediately rejected due to insufficient direct entities, the process continues to steps S8 and S9. Background telemetry events must not be included in the attack chain solely based on bridging relationships.

[0229] S7, New Chain Seed Reset Judgment

[0230] This step focuses on the candidate events that passed the multi-window time constraint in step S5. With candidate chain The process involves determining whether the event should still enter the old chain, or whether it should be actively separated from the old chain and used as a seed candidate for a new attack round. This determination differs from step S4. The former is a judgment on the relationship between an event and a specific candidate chain, while the latter is a judgment on whether the event itself is qualified to build a chain.

[0231] (1) High-value events and signal intervals. This indicates whether the candidate event possesses the basic strength to serve as evidence of the main line of the attack chain. Step S2 has comprehensively reflected rule level, stage credibility, attack semantics, entity integrity, and malicious characteristics in... Therefore, these intermediate variables will not be expanded again in this step, as they are already included in the event types. The following conditions will be met: Set to true:

[0232]

[0233]

[0234] in, The high signal threshold used in step S2. This condition prevents background telemetry events and low signal events from triggering a new chain reset on their own.

[0235] Indicates the most recent high-signal event in the candidate chain. Indicates the time interval between the candidate event and the current event:

[0236]

[0237] The dynamic signal break window actually used in this candidate relationship is generated in step S3 and determined according to the strict cross-asset principle in step S5. Step S6 has been generated accordingly. :when No more than If the condition is met, return true; otherwise, return false. If there are no candidate chains yet... It can be used or For reference only; if the reference event still cannot be obtained, a reset will not be forcibly triggered in this step.

[0238] (2) Strong entity continuation and single chain reset. This indicates whether there is still a direct, strong entity continuation between the candidate event and the candidate chain sufficient to support the same attack process; The strong entity continuation threshold. It will be set if any of the following conditions are met. Set to true:

[0239]

[0240]

[0241]

[0242] This flag indicates whether a candidate event should be actively split relative to a certain candidate chain. It is set to true only when the event is sufficiently important, high-signal evidence has broken, strong entities no longer continue, and there is no cross-stage context bridging.

[0243]

[0244]

[0245]

[0246] The above four conditions should be answered in sequence: Is the event sufficiently significant? Has the high-value evidence from the old chain been broken? Is there still a direct entity continuing the chain? After the entity replacement, is there still an explainable continuation? If all four conditions are met, then... As the priority chained object; if any condition is not met... Set to false, and proceed to steps S8 and S9. Even if Larger, as long as It also does not cut off the attack chain separately due to time intervals, thus taking into account both slow attacks and entity replacement attacks.

[0247] (3) Overall new chain creation requirements. It is a judgment based on a single candidate chain; This indicates whether a candidate event should be prioritized as a seed for a new chain within the entire range of active candidate chains. First, confirm that the candidate event satisfies the conditions of step S4. or satisfying this step Next, check if there still exists an old chain that can reasonably receive the event. An acceptable old chain must satisfy all three of the following conditions:

[0248]

[0249]

[0250]

[0251] The above three items respectively indicate that: the candidate relationship is still within the valid time frame, the chain has not been actively reset or excluded, and the two still have a directly shared foundation or a cross-stage bridging foundation. If in If there is no candidate chain that simultaneously satisfies all three conditions, then... Set to true; if at least one acceptable old chain still exists, set to false and continue executing the stage path consistency and differentiated chain merging judgment. This logic covers both the case where "all chains that pass the time constraint trigger a reset" and the case where "candidate chains lack entity sharing and bridging infrastructure".

[0252] (4) Step Output and Responsibility Boundaries. This step outputs... , , , , and . Used to exclude or reduce the priority of the corresponding old chain in subsequent candidate chain screening; Used in steps S9 and S10 to determine whether to create a new chain. This step does not directly modify... And not immediately created The final merging, caching, verification, or new chain initialization are still completed by subsequent steps.

[0253] Through the above processing, this step sets an active split boundary in the direction of old chain continuation: to prevent new high-signal attacks from being absorbed by the old chain simply because of proximity in time, same asset, same rules, or same stage; at the same time, strong entity continuation and cross-stage context bridging are used as exceptions to prevent real slow attacks or entity replacement attacks from being split prematurely.

[0254] S8. Stage Path Consistency Judgment and Stage Rollback Pruning

[0255] This step only applies to steps S5 that satisfy the condition. And it was not triggered in step S7. candidate events With candidate chain Execution phase check. Determine whether the output of step S2 is valid. and Candidate chain maintenance The output of step S6 and and the determination in step S7 It is used to identify reasonable stage evolution and backtracking with evidence support, and to remove anomalous reverse jumps that lack entity continuation and context bridging.

[0256] (1) Establish a phase comparison benchmark. Indicates from the candidate chain Remove from The valid stage path obtained after the null and invalid placeholder stages. This indicates the last valid stage. If the valid stage path is empty, or the candidate event stage is... Then, no hard pruning will be performed, and each will be... Recorded as or and order , When both sides have valid phases, calculate the phase difference:

[0257]

[0258] This indicates supplementation or forward evolution within the same stage. This indicates a phase rollback; phase rollback also needs to be combined with rollback rules, entity continuation, and context bridging judgments.

[0259] (2) Calculate the stage transfer fraction. Let... and These are the sets of combinations with allowed backoff phases and the sets of combinations with weakly allowed backoff phases, respectively. The threshold for determining a strong rollback. Normalized values ​​from 0 to 1 are used: 1 for same-stage, forward evolution, and allowable rollback; 0.6 for weakly allowable rollback or rollback with small magnitude and not explicitly prohibited; and 0.6 for rollback exceeding [a certain threshold]. For values ​​that do not belong to the allowed or weakly allowed set, the backoff value is 0, and the calculation rule is as follows:

[0260]

[0261] Only evaluate the changes in the stage itself. This indicates the existence of a strong entity continuation. This indicates that the time, phase, and asset or threat context can still be interpreted as the same attack process; if any of these conditions are met, hard pruning is performed not only because the phase difference is negative.

[0262] (3) Quantify the risk of phase rollback and perform pruning. The phase rollback depth and rollback severity are as follows:

[0263]

[0264] make This indicates the existence of a strong entity continuation; otherwise, it is set to 0. Indicates will Limited to 0 to 1. The stage path risk is:

[0265]

[0266] The deeper the rollback, the lower the transfer score and the weaker the entity sharing. The larger the value, the greater the risk reduction when there is strong entity continuation. Let... The risk pruning threshold for stage paths is set, and pruning is performed only when a candidate event has a clearly defined stage, the candidate chain already has a valid stage path, there is a lack of strong entity continuation and no cross-stage context bridge, and there is a severe rollback, prohibited transfer, or excessively high risk.

[0267]

[0268] Other situations This flag only excludes the relationship between the candidate event and the current candidate chain; it does not globally negate the candidate event.

[0269] (4) Generate stage relationships and stage consistency scores. Based on stage differences, transition scores, strong entity continuation, and pruning results, These can be sequentially labeled as ForwardOrSame, AllowedBackward, SoftBackward, BackwardWithStrongContinue, HardBackwardWithStrongContinue, WeakBackward, NoPriorStage or UnknownStage, and PrunedBackward; corresponding to... The preferred values ​​are 1.0, 0.9, 0.8, 0.7, 0.6, 0.4, 0.5, and 0. These scores can be adjusted based on the attack phase model and historical samples, but the same configuration should remain consistent in steps S8 and S9.

[0270] This step forms Record the stage difference, transition score, backoff severity, stage path risk, stage relationship, stage consistency score, and pruning flag. Pruning only excludes the current candidate chain; other candidate chains still proceed to step S9. If all candidate chains are pruned, then combine... and Decide whether to create a new application, cache it, or wait for review.

[0271] This step does not modify the candidate chain. The unpruned result is passed to step S9, and the effective stage path is updated by step S10 only after step S9 determines the chain.

[0272] S9. Differentiated Event Chain Concurrency Rules and Candidate Chain Selection

[0273] The event type is determined based on the signal strength of the candidate event, and differentiated parallel chain condition judgments are performed on the candidate events of different event types based on the entity sharing relationship and cross-stage context bridging relationship.

[0274] Specifically, this step follows the time constraint results of step S5, the entity sharing and cross-stage context bridging results of step S6, the new chain seed reset results of step S7, and the stage consistency and pruning results of step S8 to determine candidate events. Whether to merge into an existing candidate chain, which target chain to select, or to switch to the new, pending review, cache, and filtering branches. This step only forms the admission, chain selection, and processing decisions; the specific status update is performed by step S10.

[0275] (1) Candidate chain set and unified evidence score. Only active candidate chains that pass the time constraint, do not trigger new chain seed reset, and are not pruned in the stage are included in the differentiated chain concatenation judgment:

[0276]

[0277] like If the value is empty, skip the existing chain admission and selection processes. For candidate chains in the set, It is used to quantify three auxiliary relationships: same asset, same rule, and same stage, but does not constitute a sufficient condition for chain consolidation on its own.

[0278]

[0279] in, , and These are indicator variables representing relationships based on the same asset, the same rule, and the same stage, respectively. They are set to 1 if the corresponding relationship is true, and 0 otherwise.

[0280] The parallel chain score is calculated by integrating entity sharing, stage path consistency, event signal strength, and auxiliary consistency.

[0281]

[0282] in, to The weights are non-negative and their sum is 1; The definition in step S7 is used.

[0283] (2) Differentiated chaining is performed based on event type. All three types of events must belong to the aforementioned candidate chain set. Background telemetry events are subject to the strictest conditions and are only chained as auxiliary evidence when the following conditions are met simultaneously: strong entity continuation, same asset, tightened chain tail and anchor time constraints, and score threshold.

[0284]

[0285]

[0286] Low-signal events require existing attack evidence and can be addressed through a strong entity continuation path, or through a restricted weak-sharing path involving the same asset, the same phase, and close to the most recent high-signal event. This can be established through the following two paths. The first is a strong entity continuation path:

[0287]

[0288]

[0289] The second path is a supplementary path with weak sharing and close to high-signal evidence:

[0290]

[0291]

[0292]

[0293] Ordinary high-signal events can be chained together through three paths: strong entity dominance, constrained weak sharing, or cross-stage context bridging. When and hour, The following three types of evidentiary paths can be used to establish the case. The first type is the strong entity-dominated path:

[0294]

[0295] The second type is constrained weakly shared paths:

[0296]

[0297]

[0298]

[0299] The third type is the cross-stage context bridging path:

[0300]

[0301]

[0302] The above , For time tightening coefficient, each The corresponding path threshold can be configured based on rule quality, attack samples, and erroneous chain risks. When any corresponding path is valid, the candidate event is uniformly determined to pass through the differentiated admission process of that candidate chain.

[0303] (3) Set of chainable chains and selection of target chain. The candidate chains that pass the differentiated admission criteria are denoted as:

[0304]

[0305] When the set is not empty, first select the candidate chain with the highest comprehensive chaining score:

[0306]

[0307] The highest score should reach the automatic chain selection threshold. When multiple candidate chains exist, the difference between the highest and second-highest scores should also reach the discrimination threshold. If the score difference is insufficient, then compare the strong entity sharing score, the comprehensive entity sharing score, and the smaller score in that order. and higher If the chain still cannot be distinguished, it will not be automatically merged and will proceed to a pending review and judgment.

[0308] (4) Review Trigger and Final Processing Decision. The review trigger function includes four types of conditions: multiple candidate chains have similar scores and lack clear strong entity continuation; the stage pruning event still reaches the review signal threshold; the number of missing key fields reaches the threshold and the malicious labeling score is high; weak sharing does not meet the chain merging condition but at least one of the following is true: same asset, same rule, or same stage. These are denoted as follows: to :

[0309]

[0310] First, This indicates that two or more candidate chains have similar scores and lack a clearly distinguishable strong entity continuation; secondly, Indicates that the candidate relationship is triggered But the event Still reaches the threshold for signals to be reviewed ;third, Indicates the number of missing key fields in step S2. Reaching the threshold for reviewing missing fields And maliciously marked scores Reaching the malicious labeling threshold ;fourth, Indicates the candidate relationship as And it did not meet the chain connection conditions, but at least one of the following conditions must be met: same asset, same rules, or same stage relationship.

[0311] The final processing decision is generated according to the priority of "merging into an existing chain - creating a new chain - pending review - caching - filtering": if the target chain has been determined, merge into an existing chain; otherwise, create a new chain if the necessary conditions for a new chain are met, or if there are no candidate chains to merge into and the candidate event has seed qualifications or high-value evidence; then review trigger, caching qualifications and filtering conditions are judged in sequence.

[0312] Output of this step:

[0313]

[0314] Step S10 performs existing chain update, new chain initialization, cache writing, record generation and filtering based on the above output results, thereby maintaining clear boundaries between judgment and state update between S5 and S10.

[0315] S10, Chain State Update, Cache Retrieval and Attack Chain Output

[0316] For candidate events that meet the chain conditions, they are merged into the corresponding candidate attack chain and the chain state is updated. The update permission of the dual anchor points is determined by the event type and signal strength of the candidate events.

[0317] Specifically, this step is based on the output of step S9. The processing result is executed, and the parallel chain admission and candidate chain selection are not repeated. Based on... Candidate events The process involves entering branches such as merging into an existing chain, creating a new chain, short-term caching, pending review, or filtering. After the chain state changes, the process then executes cache re-triggering, closing the active chain, and outputting the attack chain, thus forming a complete closed loop.

[0318] (1) Incorporate existing chains and update basic state. When At that time, the candidate events are incorporated into the events determined in step S9. Let the states of the chain before and after merging be respectively... and First, duplicate event identifiers are removed and sorted by event time to accommodate delayed or out-of-order arrivals.

[0319]

[0320] Indicates by Remove duplicates. This indicates that events are sorted by their occurrence time. The earliest and latest events after the update are designated as the head and tail of the chain, respectively.

[0321]

[0322]

[0323] Then update the cumulative status of assets and entities:

[0324]

[0325]

[0326]

[0327]

[0328] in, The validity verification and normalization deduplication rules of steps S1 and S6 are followed. The stage path only records the confirmed and chained valid attack stages: when for Or step S8 for the selected chain When true, Keep it unchanged; otherwise, if there is no valid stage in the candidate chain or the candidate event stage is different from the most recently valid stage, Append to the path. Consecutive occurrences of the same phase are not appended repeatedly, but the event is still retained. middle.

[0329] (2) Double anchor update. The most recent anchor event is used to maintain the semantic center of the main attack chain. The anchor point signal strength threshold. This is the path consistency threshold for the anchor point phase; both are used for the first time in this step to control anchor point updates. Let the candidate event satisfy the following condition: True:

[0330]

[0331]

[0332]

[0333] like ,and No earlier than now Then execute:

[0334]

[0335] Otherwise, keep the original Out-of-order anchor candidates are still written into the event sequence and entity set, but do not replace existing anchors that arrive later.

[0336] Recent high-signal events indicate recent high-value evidence of attacks within the chain. Update the threshold for high signals; A preset malicious labeling threshold is used to determine whether the malicious labeling score of a candidate event meets the high signal update requirement. Let... True:

[0337]

[0338] when , , ,and No earlier than now At that time, execute:

[0339]

[0340] Otherwise, keep the original Therefore, even if background telemetry and ordinary low-signal events are received, the dual anchor points cannot be easily moved.

[0341] According to the updated Redefine the chain-level dynamic window. Preferably, this is done separately for each asset involved. , , and Take the stricter value to form to This avoids high-noise assets from expanding the subsequent association window of the entire chain. The updated chain state is:

[0342]

[0343] (3) New chain, cache, branches to be reviewed and filtered. When At that time, according to step S4 Initialization rule generation The candidate event is simultaneously used as the chain head, chain tail, most recent anchor point, and most recent high-signal event, and then added to... The new chain triggered by step S7 can be retained. Source tag.

[0344] when When this condition is met, it indicates that the candidate event cannot be reliably incorporated into an existing attack chain, nor is it sufficient to create a new chain, but it still possesses security value that may be supplemented by subsequent evidence. Therefore, the system does not directly filter this event but instead writes it into... This creates a cache record:

[0345]

[0346] The cache record is used to simultaneously store the event itself, the cache lifecycle, and the previous candidate judgment. , and Each event is identified separately as a cached event, a unified event object, and its associated asset. and These represent the time for entering the cache and the time for ending the retention period, respectively. Explain why automatic processing is not being performed this time, for example, the existing chain admission conditions have not yet been met, the conditions for creating a new chain are not yet met, or there is still uncertainty between candidate chains; Save a summary of the most relevant candidate chain, its entity sharing, chain merging scores, stage relationships, and failure conditions. In subsequent re-triggering, the system uses this summary to determine whether new evidence or substantial changes in candidate relationships have occurred, rather than re-evaluating from a context-free state.

[0347] The cache retention period is defined for the first time in this step; the cache expiration time is:

[0348]

[0349] Cache events enter Afterwards, it enters a "awaiting supplementary evidence" state and will not update the chain tail, double anchors, entity sets, or stage paths. Each time an existing chain is updated or a new chain is created, the system only caches events that may form new relationships with the updated chain. Perform a re-trigger check. If any of the following changes occur, the cached event is re-sent to steps S5 through S9: its position relative to the tail of the update chain or its most recent anchor point remains within the corresponding range. or Within the time frame; the set of entities intersects with the set of chain entities; or the attack phase already exists. and Not lower than the preset cache re-trigger signal threshold .in, This indicates the minimum signal strength required for a cached event to re-enter the association determination process. These conditions are only used to determine whether to re-determine the issue and do not directly indicate whether chaining is allowed.

[0350] The processing result after the re-trigger determines how the cached event is transferred out: if step S9 decides to merge into an existing chain or create a new chain, then from Remove, and then perform the existing chain update or new chain initialization in this step respectively; if converted to Then move it from the cache queue. If it is still And the new candidate relationship with If there is no substantial change, it will continue to be retained until the next valid state change or cache expiration, and will not be repeatedly calculated; if it is determined to be If the data is not found in the cache queue, it will be removed, and only the necessary statistics will be retained.

[0351] when When this occurs, it indicates that the automated process has confirmed that the event has some security value, but the existing evidence is insufficient to reliably determine which candidate chain to merge into, whether to create a new chain, or whether to exclude it. Therefore, this step does not update any attack chain state, but instead reads the state from step S9. and those already established to Generate a record to be reviewed and write it. .in, This indicates that multiple candidate chains have similar scores. This indicates that the phase rollback has been pruned, but the event signal remains high. This indicates that many fields are missing, but the evidence is strong and malicious. This indicates that a weak shared or auxiliary context exists, but the conditions for automatic chaining have not yet been met.

[0352] At a minimum, the event identifier and event object, the disputed candidate chain, the review reason code, the evidence summary, and the review prompt should be recorded. The review reason code indicates "why it cannot be processed automatically"; the evidence summary centrally stores the sharing relationships, chain scores, phase relationships, phase path consistency scores, and signal strength directly related to the reason; the review prompt converts issues requiring manual confirmation into actionable issues, such as confirming whether two candidate chains belong to the same attack round, whether a phase rollback is reasonable supplementary evidence, or whether missing fields affect the malicious judgment. When multiple triggering conditions are met simultaneously, multiple reason codes and corresponding prompts can be recorded.

[0353] After manual review, return to the corresponding processing branch based on the conclusion: if it is confirmed that the event belongs to an existing chain, proceed as follows. The branch updates the chain; if it is confirmed that the event belongs to an independent attack round, then... The branch initializes a new chain; if it is believed that further evidence is still needed, it can re-enter. And reset the cache expiration time; if it is identified as an irrelevant event or noise, do not update the attack chain and process it according to the filtering branch. Therefore, It is not the endpoint of processing, but the entry point for human decision-making when the system automatically determines that the task cannot be reliably completed.

[0354] For cached events When it arrives If it is still not merged into any candidate chain, the system performs a final value judgment. If it still has a clear attack phase, at least one valid strong entity, or Reaching step S9, as defined Then let If true, generate a record to be reviewed indicating that the cache has expired but still has security value, and write it to... Otherwise from Remove it from the attack chain, retain only the necessary information for asset noise, alarm density, false alarm ratio, or rule quality statistics.

[0355] when At this time, the attack chain is not updated; this event may only be used for asset noise, alarm density, false alarm ratio, or rule quality statistics required in step S3. Filtered events that are confirmed as false alarms only through manual review, handling results, or other trusted annotations are included in the historical false alarm count and historical false alarm ratio.

[0356] (4) Activity chain closure and attack chain output. For Chains without new evidence in the medium to long term will be closed. Chain idle time and high-signal idle time are respectively:

[0357]

[0358]

[0359] The chain idle closure threshold is defined for the first time in this step and can be combined with... and Confirmed. When the chain idle time exceeds Or the high signal idle time exceeds and There are no repeatable events in the chain, or the total span of the chain exceeds [a certain value]. At that time, the chain will be removed from move in .

[0360] Chain confidence scores range from 0 to 100, used to measure whether a closed candidate chain has sufficiently complete and reliable evidence of an attack. This value is not directly given, but is calculated jointly by signal strength, entity coverage, stage coverage, anchor density, and noise penalty. The following intermediate scores are obtained first:

[0361]

[0362]

[0363]

[0364]

[0365]

[0366]

[0367] and These represent the average and maximum values ​​of the event signal strength within the chain, respectively, and are used to reflect the overall level of evidence and the strongest single event evidence; The coverage of entity evidence is evaluated based on the cumulative number of strong and weak entities, with strong entities contributing more than weak entities. according to Number of different effective attack phases Evaluate the completeness of the attack process in each phase; Based on the number of events that meet the anchor point candidate criteria Number of events in the chain The proportion of the main evidence density is evaluated. Based on the number of background telemetry events and low signal event count The chain confidence level is reduced.

[0368]

[0369] in, This indicates that the calculation results are limited to 0 to 100; the coefficients are used to control the contribution of different pieces of evidence to the chain confidence and can be adjusted based on historical attack chain samples and manual verification results. Output a confidence threshold for the attack chain. This is the signal threshold that allows a single high-risk event to trigger the output. After completing the above calculations, the following attack chain output judgment is then performed:

[0370]

[0371]

[0372]

[0373] in, The number of events within the chain. This represents the signal strength of the highest event within the chain. It is generated when the following conditions are met:

[0374]

[0375] in, Record high-value, anchor, or high-signal events. Explanation of issues such as record phase rollback, multi-chain ambiguity, cache re-triggering, or missing fields. Chains that do not reach the automatic output threshold but still have a certain chain confidence level are included. Low-value chains lacking high signals and strong entities can be downgraded for retention or filtered.

[0376] Final output of this step:

[0377]

[0378] This result centrally records existing chain updates, new chain creation, changes in cache and review queues, changes in the closed chain set, and attack chain outputs. Thus, the candidate events form a complete closed loop, from standardization, time and entity relationship judgment, stage control, and differentiated chain merging, to chain state updates, cache re-triggering, manual review, and attack chain outputs.

[0379] An embodiment of this application provides a security event incremental attack chain association system based on a dual-anchor chain state and asset adaptive dynamic window, comprising:

[0380] The event standardization module is used to convert multi-source heterogeneous original security events into unified event objects and extract strong entity sets and weak entity sets; the dynamic window generation module is used to generate adaptive dynamic windows based on the historical behavior statistics and asset attributes of the assets to which the candidate events belong; the chain state maintenance module is used to maintain the chain state consisting of the chain head event, chain tail event, most recent anchor event, and most recent high signal event, where the most recent anchor event and the most recent high signal event constitute a double anchor.

[0381] The system also includes a multi-window time constraint module, an entity sharing relationship calculation module, a differentiated chain judgment module, and a chain state update module. The multi-window time constraint module is used to determine the temporal relationship between candidate events and candidate attack chains by combining dynamic windows and chain states; the entity sharing relationship calculation module is used to calculate strong entity sharing, weak entity sharing, and comprehensive sharing relationships; the differentiated chain judgment module is used to complete chain admission and candidate chain selection by combining event type, cross-stage context bridging, new chain seed reset, and stage rollback pruning results; the chain state update module is used to perform event merging, new chain creation, dual anchor point update, short-term caching, re-triggering, pending verification, and attack chain output.

[0382] The processing logic of each module corresponds to steps S1 to S10, and the specific fields, calculation methods, and judgment conditions have been explained in the corresponding steps and will not be repeated here. Each module can be deployed on the same security monitoring platform, or it can be implemented collaboratively by multiple communicating processing nodes.

[0383] According to one embodiment of this application, an electronic device for incremental attack chain association is also provided, including a processor, a memory, and a network interface; the memory stores a computer program, and when the processor executes the computer program, it implements the aforementioned security event incremental attack chain association method. Depending on actual deployment needs, the electronic device may also include a display device, an input device, or other functional components, and its specific structure does not constitute a limitation on the embodiments of this invention.

[0384] In an exemplary embodiment, a computer-readable storage medium and a computer program product are also provided, wherein the instructions stored or contained therein, when executed by a processor of an electronic device, cause the electronic device to implement the aforementioned security event incremental attack chain association method. All or part of the process of the method can be implemented by software, hardware, or a combination of both, and is not limited by specific device form, storage medium type, or deployment architecture.

[0385] The above embodiments are used to illustrate the method and core ideas of the present invention, and are not intended to limit the scope of protection of the present invention. Modifications, equivalent substitutions, or adaptive changes made by those skilled in the art within the scope of the present invention should all be included within the scope of protection of the present invention.

Claims

1. A method for associating incremental attack chains of security events based on dual-anchor chain states and asset adaptive dynamic windows, characterized in that, include: Transform multi-source heterogeneous original security events into a unified event object, and extract strong entity sets and weak entity sets; Based on the historical behavior statistics and asset attributes of the assets to which the candidate events belong, an adaptive dynamic window is generated; for each candidate attack chain, a chain state consisting of the chain head event, chain tail event, most recent anchor event, and most recent high signal event is maintained, where the most recent anchor event and the most recent high signal event constitute a double anchor. Perform multi-window time constraint judgment on candidate events and candidate attack chains based on the dynamic window and the chain state; For candidate events and candidate attack chains that pass the time constraint, calculate the entity sharing relationship based on the strong entity set, weak entity set, and entity set maintained by the candidate attack chain. The event type is determined based on the signal strength of the candidate event. Differentiated chain condition judgments are performed on the candidate events of different event types based on the entity sharing relationship and the cross-stage context bridging relationship. The cross-stage context bridging relationship represents the continuity relationship between the candidate event and the candidate attack chain when there is no direct strong entity sharing, based on at least one interpretable dimension among attack stage evolution, asset context, access path, threat intelligence clues or weak entity context. For candidate events that meet the chain conditions, they are merged into the corresponding candidate attack chain and the chain state is updated. The update permission of the dual anchor points is determined by the event type and signal strength of the candidate events.

2. The method for associating incremental attack chains of security events based on dual-anchor chain states and asset adaptive dynamic windows according to claim 1, characterized in that, The process of converting multi-source heterogeneous original security events into a unified event object includes: performing field parsing, field name mapping, rule base or asset ledger completion and normalization on the original security events to generate a unified event object; performing validity verification, normalization and deduplication on the fields used for association; writing highly distinguishable information such as IP, process, command, file, domain name, session identifier and malicious intelligence marker into a strong entity set to represent association evidence that can directly confirm the continuation of the event; and writing information such as username, hostname, asset type, rule number, log source and attack stage into a weak entity set to supplement the asset, rule and stage context.

3. The method for associating incremental attack chains of security events based on dual-anchor chain states and asset adaptive dynamic windows according to claim 1, characterized in that, The process of generating an adaptive dynamic window includes: generating a window adjustment coefficient based on the asset criticality of the asset to which the candidate event belongs, historical attack hit markers, normalized background noise flow rate, historical false alarm ratio, and normalized historical alarm density. The window adjustment coefficient is expressed as follows: , in, This indicates that the calculation results will be restricted to... to Within the range, , , , and These represent, in order: asset criticality, historical attack hit markers, normalized background noise flow rate, historical false alarm rate, and normalized historical alarm density. , , , and To adjust the weights; The preset basic window set is scaled using the window adjustment coefficient to generate a dynamic ordinary time window, a dynamic anchor point time window, a dynamic chain maximum span window, and a dynamic signal break window.

4. The method for associating incremental attack chains of security events based on dual-anchor chain states and asset adaptive dynamic windows according to claim 1, characterized in that, The multi-window time constraint judgment includes: judging candidate events. For each candidate attack chain, calculate the normal time difference between the candidate event and the chain tail event, the anchor time difference with the most recent anchor event, and the total chain span after merging the event; when linking across assets, use the stricter value in the dynamic window of the relevant asset; the time constraint is passed if the following conditions are met simultaneously: ， in, , and These are the ordinary time window, anchor point time window, and chain maximum span window used in this judgment, respectively; the dynamic signal break window does not replace the above three constraints, but is used for subsequent new chain seed reset, low signal proximity judgment, and high signal continuity control.

5. The method for associating incremental attack chains of security events based on dual-anchor chain states and asset adaptive dynamic windows according to claim 1, characterized in that, The shared relationships between computing entities include: Based on the entity set maintained cumulatively from candidate events and candidate attack chains, strong entity sharing scores are calculated. Shared score with weak entities And a comprehensive entity-shared score is generated by reducing the number of weak entities: , in, This is a weak entity reduction factor used to limit the impact of weak context on association results; entity relationships are reduced based on shared set and shared score. Mark as strong sharing, weak sharing, or no sharing; When direct strong entity sharing between candidate events and candidate attack chains is insufficient to support chaining alone, the cross-stage context bridging relationship is judged according to the following four thresholds. : First, the candidate events have passed the time constraints and are not background telemetry events; Second, the signal strength of the candidate event reaches the bridging signal threshold, or the candidate event has a clear attack phase; Third, the attack phase of the candidate event can be reasonably connected to the current phase of the candidate chain—belonging to the same phase supplement, reasonable advancement or preset allowed backtracking combination, or belonging to the preset weak allowed backtracking combination and having strong entity continuation evidence—and the signal interval between the candidate event and the most recent high signal event of the candidate chain does not exceed the dynamic signal break window. Fourth, the candidate event and the candidate chain have an interpretable bridging relationship in at least one dimension of asset context, access path, threat intelligence, or weak entity context: the asset to which the candidate event belongs and the existing assets of the candidate chain belong to the same business, the same asset group, the same network segment, or the same security domain; or the source asset, target asset, source IP, or target IP of the candidate event have an upstream or downstream access path relationship with the existing assets or existing IP of the candidate chain; or the candidate event and the candidate chain share attack tools, malicious intelligence tags, vulnerability numbers, external domain names, or attack technology clues; or the weak entity sharing score of the candidate event reaches the weak entity bridging threshold, or at least two of the following relationships—same asset, same rule, and same stage—are met simultaneously. When all four thresholds are passed Set as If any threshold is not met, set to ; The establishment of the candidate relationship indicates that it is still required to enter the subsequent stage of control and differentiated chain judgment; background telemetry events must not be incorporated into the attack chain solely based on bridging relationships.

6. The method for associating incremental attack chains of security events based on dual-anchor chain states and asset adaptive dynamic windows according to claim 1, characterized in that, The method further includes: When a candidate event is a high-value event but not a background telemetry event or a low-signal event, and the signal interval between the candidate event and the most recent high-signal event in the candidate attack chain exceeds the dynamic signal break window, and the candidate event and the candidate attack chain lack a strong entity continuation relationship, and the candidate event and the candidate attack chain do not have a cross-stage context bridging relationship, the candidate event is marked as a new chain seed reset relative to the candidate attack chain; wherein, the high-value event is established when the candidate event is not a background telemetry event, not a low-signal event, and the signal strength is not lower than the high-signal threshold; the strong entity continuation relationship is established when the sharing relationship between the candidate event and the candidate attack chain is a strong sharing relationship, or the strong entity sharing set is not empty, or the strong entity sharing score is not lower than the strong entity continuation threshold; When a candidate event meets the high-value event condition or the attack chain seed event condition, and there is no candidate attack chain among all candidate attack chains that pass the time constraint that simultaneously meets the following conditions, a new candidate attack chain is initialized with the candidate event: the candidate event has not been marked as a new chain seed reset relative to the candidate attack chain; and there is a non-shared entity relationship between the candidate event and the candidate attack chain, or there is a cross-stage context bridge relationship.

7. For candidate relationships that have not triggered a new chain seed reset, perform phase rollback pruning judgment: obtain the phase index corresponding to the attack phase of the candidate event and the phase index corresponding to the most recent valid phase of the candidate chain, and calculate the phase difference; when the candidate event has a clear attack phase, the candidate chain already has a valid phase path, the candidate event and the candidate chain lack a strong entity continuation relationship and there is no cross-phase context bridging relationship, and any of the following situations occur, the candidate event is rejected from being merged into the candidate attack chain - the phase difference is less than the negative value of the preset phase pruning threshold, or the phase transfer score calculated based on the phase difference and the phase rollback rule is 0, or the phase path risk score obtained by comprehensively considering the phase rollback magnitude, the phase transfer score and the entity sharing score is not lower than the preset phase path risk pruning threshold; in, When a candidate event and a candidate chain have the strong entity continuation relationship or the cross-stage context bridging relationship, pruning will not be directly triggered due to stage rollback.

8. The method for associating incremental attack chains of security events based on dual-anchor chain states and asset adaptive dynamic windows according to claim 1, characterized in that, The differential chain condition judgment includes: For background telemetry events, the following conditions are adopted: strong entity continuity relationship, same asset relationship, tightened chain tail and anchor point time constraints, and comprehensive chain connection score not lower than the background telemetry chain connection threshold. For low-signal events, chaining can be performed through a strong entity continuation path—which requires satisfying the following conditions: strong entity continuation relationship, entity sharing score not lower than the low-signal entity sharing threshold, phase consistency score not lower than the low-signal phase threshold, and comprehensive chaining score not lower than the low-signal chaining threshold; or, chaining can be performed through a supplementary path with weak sharing that is close to high-signal evidence—which requires simultaneously satisfying the following conditions: weak sharing relationship, not belonging to a strong entity continuation relationship, same asset relationship, same phase relationship, signal interval not exceeding the dynamic signal break window, tightened chain tail time constraint, and comprehensive chaining score not lower than the low-signal weak sharing chaining threshold. For ordinary high-signal events, chaining can be performed via a strong entity-dominated path, which requires satisfying the following conditions: strong entity continuation relationship, phase consistency score not lower than the high-signal strong entity phase threshold, and comprehensive chaining score not lower than the high-signal strong entity chaining threshold; or, chaining can be performed via a constrained weak-sharing path, which requires simultaneously satisfying the following conditions: weak sharing relationship, not belonging to a strong entity continuation relationship, entity sharing score not lower than the high-signal weak-sharing entity score threshold, phase consistency score not lower than the high-signal weak-sharing phase threshold, signal strength not lower than the high-signal threshold, same asset relationship, and comprehensive chaining score not lower than the high-signal weak-sharing chaining threshold; or, chaining can be performed via a cross-phase context bridging path, which requires simultaneously satisfying the following conditions: cross-phase context bridging relationship, no phase rollback pruning triggered, signal interval not exceeding the dynamic signal break window, phase consistency score not lower than the high-signal bridging phase threshold, and comprehensive chaining score not lower than the high-signal bridging chaining threshold. When a candidate event can be incorporated into multiple candidate attack chains, the comprehensive chain-merging score is expressed as: ， The four terms in the formula are, in order, the overall entity sharing score, the stage path consistency score, the event signal strength, and the auxiliary consistency score. to The weights are non-negative and their sum is 1; the candidate chain with the highest comprehensive chain-linking score and that reaches the chain selection threshold is selected as the chain-linking target; if the difference between the highest score and the second highest score is less than the discrimination threshold, the strong entity sharing score, comprehensive entity sharing score, time distance and stage consistency score are compared in turn for secondary discrimination. If it is still uncertain, it is transferred to pending review.

9. The method for associating incremental attack chains of security events based on dual-anchor chain states and asset adaptive dynamic windows according to claim 1, characterized in that, The updated chain status includes: after events are merged, they are deduplicated by identifier and sorted by event time, updating the chain head event, chain tail event, asset set, entity set, stage path, and dual anchor points; background telemetry events and ordinary low signal events do not update the dual anchor points; For candidate events that do not meet the chain-connection conditions and seed conditions but still have security value, write them into a short-term cache queue and re-execute the chain-connection judgment after the chain state of the candidate attack chain is updated. For cached events that have expired but have not yet been merged into any candidate attack chain and still have a clear attack phase, a valid strong entity, or have reached the strength of a signal to be reviewed, a review record is generated. For candidate events or candidate relationships where multiple candidate chains have similar scores and lack strong entity continuation, where stage rollback pruning events still reach the strength of a signal to be reviewed, where the number of missing key fields reaches a threshold and the malicious marking score is high, or where weak sharing has not met the chain merging conditions but at least one of the same asset, the same rule, or the same stage is met, a review record is generated. The review record includes at least an event identifier, associated candidate chain, review reason code, and review prompt.

10. A security event incremental attack chain association system based on a dual-anchor chain state and asset adaptive dynamic window, characterized in that, include: The event standardization module is used to convert multi-source heterogeneous original security events into unified event objects and extract strong entity sets and weak entity sets; The dynamic window generation module is used to generate adaptive dynamic windows based on the historical behavior statistics and asset attributes of the assets to which the candidate events belong. The chain state maintenance module is used to maintain the chain state for each candidate attack chain, consisting of the chain head event, chain tail event, most recent anchor event, and most recent high signal event, where the most recent anchor event and the most recent high signal event constitute a double anchor. The multi-window time constraint module is used to perform multi-window time constraint judgment on candidate events and candidate attack chains based on the dynamic window and the chain state. The entity sharing relationship calculation module is used to calculate the entity sharing relationship based on the strong entity set, weak entity set, and entity set maintained by the candidate events and candidate attack chains that have passed the time constraint. The differentiated chain judgment module is used to determine the event type based on the signal strength of the candidate event, and to perform differentiated chain judgment on the candidate events of different event types based on the entity sharing relationship and the cross-stage context bridging relationship. The cross-stage context bridging relationship represents the continuity relationship between the candidate event and the candidate attack chain when there is no direct strong entity sharing, based on at least one interpretable dimension among attack stage evolution, asset context, access path, threat intelligence clues or weak entity context. The chain state update module is used to merge candidate events that meet the chain merging conditions into the corresponding candidate attack chain and update the chain state, wherein the update permission of the dual anchor points is determined by the event type and signal strength of the candidate events.

Images