An online maintenance and overload control method for a vehicle-mounted multi-source IDS alarm correlation tracking graph

Abstract

This invention discloses an online maintenance and overload control method for multi-source IDS alarm correlation tracing graphs in vehicles. Rule-based intrusion detection systems (IDS) are deployed in the vehicle host domain, vehicle Ethernet domain, and Controller Area Network (CAN) to generate alarms. At the vehicle gateway electronic control unit (ECU) side, multi-source alarms undergo event standardization, sliding time window buffering and waterline out-of-order tolerance, deduplication aggregation, and indexed candidate retrieval. Under the condition of satisfying alarm correlation judgment rules, a directed alarm tracing graph is incrementally constructed. By suppressing forks and overloads through in / out-degree limits, node / edge budgets, and priority pruning, combined with two-stage expiration recycling and tracking record solidification, stable alarm correlation and tracing are achieved under resource-constrained conditions. This method can be used for real-time tracing and offline forensic analysis on the vehicle side.

Description

Technical Field

[0001] This invention relates to the field of vehicle network security and intrusion detection technology, and in particular to an online maintenance and overload control method for vehicle multi-source IDS alarm correlation tracing graph. Background Technology

[0002] As vehicle electronic and electrical architecture evolves towards centralization and networking, multiple communication domains such as host / domain controllers, vehicle Ethernet backbone, and CAN are commonly found inside vehicles. Key functions are completed collaboratively by multiple ECUs, and the degree of system interconnection is constantly improving. Existing research, through security experiments and analyses of modern vehicles, has shown that there are exploitable attack paths between the vehicle's external interfaces and internal networks. Furthermore, remote or near-range intrusions can further impact critical vehicle functions, posing significant security risks (Koscher, K., Czeskis, A., Roesner, F., Patel, S., Kohno, T., Checkoway, S., and Savage, S. 2010. Experimental Security Analysis of a Modern Automobile. In Proceedings of the 2010 IEEE Symposium on Security and Privacy (IEEE S&P 2010), pp. 447-462. )(Checkoway, S., McCoy, D., Kantor, B., Anderson, D., Shacham, H., Savage, S., and Kohno, T. 2011. Comprehensive Experimental Analyses of Automotive Attack Surfaces. In Proceedings of the 20th USENIX Security Symposium (USENIX Security 2011). Therefore, intrusion detection and alarm analysis for vehicular networks has become an important engineering requirement.

[0003] IDS deployed on the vehicle side typically outputs abnormal clues in the form of "alarms" to indicate abnormal process behavior, abnormal network sessions, abnormal bus messages, or abnormal diagnostic activities. To derive a higher-level security posture and potential intrusion processes from a large number of alerts, academia and industry have proposed various alert aggregation and correlation methods. For example, Debar and Wespi proposed an aggregation and correlation framework for multi-sensor alerts to group low-level alerts into more interpretable security events (Debar, H., and Wespi, A. 2001. Aggregation and Correlation of Intrusion-Detection Alerts. In Recent Advances in Intrusion Detection (RAID2001), Lecture Notes in Computer Science, Springer.); Ning et al. proposed an alert correlation idea based on attack prerequisites to construct higher-level attack scenarios from dense alerts (Ning, P., Cui, Y., and Reeves, DS 2002. Analyzing Intensive Intrusion Alerts via Correlation. In Recent Advances in Intrusion Detection (RAID 2002), Lecture Notes in Computer Science, vol.2516, Springer.). Valeur et al. presented a relatively systematic alarm correlation model and component framework for recovering attack threads from multi-source alarms and reducing the impact of false alarms (Valeur, F., Vigna, G., Kruegel, C., and Kemmerer, RA 2004. A Comprehensive Approach to Intrusion Detection Alert Correlation. IEEE Transactions on Dependable and Secure Computing 1(3), 146-169.).Furthermore, the approach of intrusion tracing and dependency graph backtracking has also been used to locate intrusion steps and dependencies (King, ST, and Chen, PM 2003. BacktrackingIntrusions. In Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP 2003), pp. 223-236.). This work laid the foundation for research on "the process of higher-level attacks arising from lower-level alerts."

[0004] Existing alarm correlation and tracing methods are mostly geared towards enterprise network or server environments, typically assuming that computing and storage resources are relatively sufficient and that out-of-order alarm arrivals and sudden overloads have negligible impact on online maintenance. However, vehicle gateways need to operate online for extended periods under limited resources and simultaneously withstand sudden increases and out-of-order delays in alarms from multiple domains. Existing methods struggle to maintain the size of the tracing graph and processing latency stably without losing critical tracing relationships.

[0005] However, alarm aggregation and online analysis at the vehicle gateway side face stronger resource and timing constraints: on the one hand, the gateway ECU's computing power and memory budget are limited, and it needs to run in parallel with tasks such as communication forwarding and diagnostic services; on the other hand, alarms may experience sudden increases when triggered by attacks, link anomalies, or configuration changes, causing the number of events and candidate associations within the window to expand rapidly. If candidate associations are generated by performing pairwise comparisons on all alarms within the window, the computational complexity and memory consumption will increase rapidly with the window size, easily leading to accumulated processing delays or even alarm loss, thus affecting the continuity and reproducibility of tracing and attribution.

[0006] Furthermore, multi-domain alarms may experience out-of-order delivery and delays during generation, transmission, and scheduling: different alarm timestamp sources, queue queuing, and scheduling jitter can lead to inconsistencies between the "arrival order" and the "occurrence order"; if the graph is built directly according to the arrival order, unstable or unreproducible associated edges are easily formed. For processing unbounded and out-of-order data, existing works have proposed event temporal semantics, windowing, and watermark mechanisms to achieve a balance between correctness and latency (Akidau, T., Balikov, A., Bekiroglu, K., Chernyak, S., Haberman, J., Lax, R., McVeety, S., Mills, D., Nordstrom, P., and Whittle, S. 2013. MillWheel: Fault-TolerantStream Processing at Internet Scale. Proceedings of the VLDB Endowment 6(11).)(Akidau, T., Bradshaw, R., Chambers, C., Chernyak, S., Fernández-Moctezuma, RJ, Lax, R., McVeety, S., Mills, D., Perry, F., Schmidt, E., and Whittle, S. 2015. The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing. Proceedings of the VLDB Endowment 8(12), 1792-1803.). However, implementing such out-of-order tolerance and overload control mechanisms in the online maintenance of alarm tracing graphs for vehicle gateways still requires specialized design to meet the requirements of "controlled node / edge size, controlled forks, recyclable expiration, and auditable processing."

[0007] Therefore, how to organize multi-domain IDS alarms in a windowed manner and tolerate out-of-order behavior under the condition of limited vehicle gateway resources, and maintain the stable online maintenance of the alarm tracing graph through mechanisms such as deduplication and merging, indexed candidate retrieval, fork control and scale constraints, while retaining auditable processing records to support real-time tracing and offline evidence collection, is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0008] To address the following issues in existing multi-domain IDS alarm aggregation and processing on vehicle gateways: rapid expansion of node and edge scale due to sudden alarm bursts under resource-constrained conditions, excessive overhead in candidate association generation, accumulated processing delays, and even alarm loss; and the instability of graph construction based on arrival order due to out-of-order and delayed arrival of multi-domain alarms, and the unreproducible association results, this invention proposes a method to achieve stable maintenance of the alarm tracing graph under sudden load and out-of-order conditions, and to provide auditable processing records for real-time tracing and offline evidence collection.

[0009] To achieve the above objectives, the present invention adopts the following technical solution: an online maintenance and overload control method for vehicle-mounted multi-source IDS alarm correlation tracking graph, comprising the following steps.

[0010] (1) Alarm access and event standardization: Receive IDS alarms from the host, vehicle Ethernet and CAN, perform structured parsing on each alarm and map it into a standardized event; the standardized event includes at least alarm type identifier, event time, source subsystem identifier, object entity information and evidence field, so as to eliminate the differences in alarm format across multiple domains and facilitate subsequent unified processing.

[0011] (2) Windowed buffer and out-of-order tolerance: The standardized events are written into the circular buffer divided by subsystem, and the event set within the window is organized based on the sliding time window; at the same time, the event time water level is set to absorb late events within the preset out-of-order tolerance range so that they can still participate in the subsequent map building process; events that exceed the out-of-order tolerance range or are not within the sliding window are discarded or downgraded to avoid late events repeatedly disturbing the existing map structure.

[0012] (3) Deduplication and aggregation compression: Within the sliding time window, deduplication of standardized events is performed according to the preset deduplication key; duplicate events are merged to generate or update aggregate events, and at least one of the duplicate count, earliest / latest occurrence time, evidence summary or representative sample is updated to reduce the number of nodes caused by sudden alarms and suppress redundant information.

[0013] (4) Incremental graph building and index update: Create or update event nodes in the alarm tracking graph for standardized or aggregated events that enter the sliding time window; at the same time, maintain the index structure for candidate association retrieval, which is used to generate a set of candidate predecessor nodes under controlled overhead, avoiding full traversal of all nodes in the window.

[0014] (5) Fork control and degree constraint pruning: Perform alarm association determination on candidate predecessor nodes and current event nodes; when the preset association determination rules are met, establish a directed association edge from the predecessor node to the current node, and the direction of the directed association edge is determined from early to late according to the event time; and apply an in-degree upper limit and / or an out-degree upper limit to each event node. When the number of candidate association edges exceeds the degree constraint, retain some association edges and prune the remaining association edges according to the preset priority rules.

[0015] (6) Resource budget-driven overload control: Set node budget and / or edge budget for alarm tracing graph and monitor alarm input rate; when the tracing graph size exceeds the budget or the alarm input rate exceeds the preset threshold, trigger the overload control strategy and perform at least one of the following operations on low priority events: discard, merge and compress, delay edge building or edge pruning, thereby limiting the growth of graph size and suppressing processing delay under resource-constrained conditions.

[0016] (7) Expired event removal and tracking record solidification: As the sliding time window progresses, expired event nodes and their related edges that exceed the window range are removed; and the source information and processing information of the retained nodes and edges are recorded to form a tracking record. The tracking record is used for real-time tracking and tracing display on the vehicle side or for review and auditing in offline evidence collection and analysis.

[0017] Furthermore, the alarm type identifier in step (1) is obtained by normalizing the alarm rule name or alarm rule number triggered by each subsystem rule, and the object entity information includes at least one of process identifier, network endpoint identifier or CAN message identifier.

[0018] Furthermore, the evidence field in step (1) is used to retain the original observation basis or its summary information corresponding to the alarm, including at least one or more of the following: for host domain alarms, it includes process identifier, executable file path or hash, user identifier, file path, socket information or system call type; for vehicle Ethernet domain alarms, it includes source / destination IP address, source / destination port, MAC address, protocol type, service identifier, session identifier, message length or payload summary; for CAN domain alarms, it includes CAN message identifier, bus channel, data length code (DLC), data field, signal name / signal value or sending / receiving ECU identifier.

[0019] Further, step (2) includes: setting circular buffers for the host domain, vehicle Ethernet domain and CAN domain respectively; determining the event time waterline based on the current window reference time and the preset out-of-order tolerance time; and allowing events whose event time is earlier than the waterline and are still within the sliding time window to participate in subsequent mapping processing.

[0020] Furthermore, the deduplication key in step (3) includes at least a combination of alarm type identifier and object entity information, and the update of the aggregated event includes at least one of accumulating duplicate counts, updating the earliest and latest occurrence times, merging evidence field summaries, or retaining representative samples.

[0021] Furthermore, the index structure in step (4) includes at least one of the following: time bucket index, inverted index established by alarm type identifier, and mapping index established by object entity information, so as to avoid full traversal of all nodes within the sliding time window when generating the candidate predecessor node set.

[0022] Furthermore, the association determination rules in step (5) include at least one or more of the following conditions: time proximity constraint, object entity consistency or session consistency constraint, cross-domain function / protocol compatibility constraint, and reachability constraint based on vehicle network topology.

[0023] Furthermore, the priority rules in step (5) are determined based on at least one of the following: event time proximity, aggregated event repetition count, evidence field integrity, source subsystem level, or historical association stability, and candidate association edges are retained and pruned according to priority.

[0024] Furthermore, the overload control strategy in step (6) includes: when the budget exceeds the limit, priority is given to retaining event nodes and their associated edges related to the current active path, and low-priority events on inactive paths are discarded or merged and compressed.

[0025] Furthermore, in step (7), the tracking record includes at least the original alarm reference corresponding to the event node, the event standardization mapping information, the triggering reasons for deduplication and merging and overload control, and the basis for retaining or pruning the associated edges, so as to provide auditable traceability evidence.

[0026] Compared with the prior art, the present invention has at least the following beneficial effects: (1) Improved stability and availability: Through windowed buffering, out-of-order tolerance and event time watermark mechanism, the stability of online maintenance of the tracking graph can still be maintained under the conditions of out-of-order and late arrival of multi-domain alarms, reducing the instability of association caused by fluctuations in arrival order.

[0027] (2) Controlled overhead and manageable overload: By deduplication and merging, indexed candidate retrieval, degree constraint pruning and node / edge budget control, the size of the alarm tracking graph and the associated computation overhead are controlled, which can suppress node and edge expansion when alarms occur, reduce processing delay and reduce the risk of alarm loss.

[0028] (3) Enhanced auditability: By recording the source and processing information of nodes and edges, verifiable process evidence can be provided for real-time tracing and offline evidence collection, thereby improving the interpretability and auditability of the tracing results.

[0029] (4) Strong engineering adaptability: The method is implemented for vehicle gateway ECU, compatible with alarm input form of multi-domain rule type IDS, does not rely on modification of existing vehicle communication protocol or terminal equipment, and is easy to deploy on the vehicle side. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the overall process of the method of the present invention; Figure 2 A schematic diagram illustrating the disorder tolerance of the sliding time window and the water level line; Figure 3 This is a schematic diagram of in-degree / out-degree constraints and priority pruning. Figure 4 A schematic diagram illustrating budget-driven overload control, expired item removal, and tracking record solidification. Detailed Implementation

[0031] Without departing from the concept of this invention, those skilled in the art may make equivalent modifications to the sequence of steps and parameter configurations, all of which should fall within the protection scope of this invention.

[0032] The core technology of this invention is to perform windowed buffering and out-of-order tolerance on multi-domain IDS alarm flows under conditions of limited vehicle gateway resources and sudden, out-of-order alarms. Through deduplication and merging, indexed candidate retrieval, degree-constrained pruning, and budget-driven overload control mechanisms, it achieves stable online maintenance of the alarm tracing graph, while simultaneously generating auditable tracing records to support real-time tracing and offline forensic analysis. This invention takes alarms output from IDS in three regular domains—host domain, vehicle Ethernet domain, and CAN domain—as input, and constructs and maintains an alarm tracing graph on the gateway side through alarm correlation for tracing and evidence preservation.

[0033] Input: Multi-source IDS alarm flow Each alarm includes at least an alarm generation timestamp, alarm type (rule name or rule number), alarm source subsystem identifier, and several original evidence fields (such as process / connection / message fields). In an optional implementation, a vehicle operating status summary (such as vehicle speed, gear, or ignition status) can also be entered for subsequent priority or retention policy adjustments, but this is not mandatory.

[0034] Output: (i) The alarm tracing graph after maintenance (ii) its window snapshot; (iii) Overload control status and statistics (such as discard count, merge count, budget usage, etc.).

[0035] Terminology and Data Structure Definitions To avoid ambiguity in terminology and ensure consistency of symbols throughout the text, this invention uses the following terms and symbols uniformly, and clearly defines the meaning of parameters: 1. Standardized Events. Parse and map any alarm as a standardized event. Defined as:

[0036] in: Alarm type identifier; For event time; For the source subsystem identifier; For object entity information; For evidence fields or their summaries / references.

[0037] 2. Aggregated events. The merged, deduplicated events are denoted as aggregated events. Defined as:

[0038] in: To aggregate the time span; For aggregate count; This is a summary of evidence or a representative sample set.

[0039] 3. Window and water level. The sliding time window length is... (seconds), the current window reference time is Window range is The out-of-order tolerance period is... The event timeline is as follows:

[0040] If the event satisfies and If so, it is determined to be an absorbable late event; if or late If so, the record will be discarded or downgraded.

[0041] 4. Node time scalar (used for edge construction direction and sorting). To accommodate both normalized and aggregated events, this can be any event during graph construction and sorting. Define its representative time:

[0042] And for any node definition .

[0043] 5. Alarm Tracking Graph. A directed graph is maintained within the window. ,in A set of event nodes (nodes correspond to) or ), This is a set of directed and associative edges. If edges are established... Then it requires This ensures that the direction of the edge is determined from morning to night according to the event time.

[0044] 6. Degree Constraints and Resource Budget. Set an in-degree limit for each node. and the upper limit of out-degree Node budget is Calculated as Input rate threshold is (strips / second).

[0045] 7. Symbol abbreviation. For ease of subsequent description, abbreviations are used for nodes. : , ,in To obtain object entity information Extracted entity keys.

[0046] like Figure 1 As shown, the input to the method of this invention is the alarm source, including regular IDS alarms generated by the host domain, vehicle Ethernet domain, and CAN domain. First, "parsing and normalization" is performed on multi-source alarms, converting raw alarms from different sources and formats into unified standardized events. Then, the "window buffer + watermark" stage is entered, where standardized events are organized using a sliding time window and out-of-order tolerance processing. Next, "deduplication and aggregation" is performed to merge and compress duplicate or highly similar alarms. Based on this, a candidate predecessor node set is generated through "indexed candidate retrieval," and the alarm tracing graph is "incrementally updated." Then, "degree constraint + budget control" limits the node fork scale and suppresses overload under resource-constrained conditions. Finally, "expired recycling and tracking records" are performed, outputting an "alarm tracing graph snapshot." "and "tracking records (audit / evidence collection)".

[0047] like Figure 2 As shown, the horizontal axis "Event Time" represents the timeline of standardized events arranged by event time; the "Sliding Time Window" at the top of the graph represents the current window range. ,in The left boundary of the window. This represents the right boundary of the window; the "water level line" in the diagram corresponds to... This is used to distinguish between absorbable late events and events that can no longer participate in window processing. (See diagram) , , , and This represents a sample event within the window; This indicates an event that is late but still within the acceptable range of disorder, and therefore "late is acceptable"; This indicates events that have fallen outside the window and are therefore "discarded outside the window." In the diagram, "processed within the window" means that events within the current sliding time window will continue to participate in subsequent deduplication, graph construction, and association processing, while "outside the window" means that events outside the window will no longer participate in the graph maintenance of the current window.

[0048] like Figure 3 As shown in the figure This indicates the event node currently awaiting connection. to This represents the set of candidate predecessor nodes, obtained through index retrieval, that may establish an edge connection with the current node. This embodiment uses the in-degree constraint as an example: for the current node... Select the predecessor from the candidate predecessor nodes according to the priority rules. Incoming edges are retained, while other associated edges are pruned. Solid arrows in the diagram represent retained associated edges, and dashed arrows represent pruned associated edges. The right side indicates a "degree constraint: retain before..." "Prune all incoming edges and all other associated edges" describes the priority pruning process based on the upper limit of the in-degree of the graph; for the upper limit of the out-degree... The same method can be used for control.

[0049] like Figure 4 As shown in the diagram, the "Status Monitoring" module is used to monitor the number of nodes in the current alarm tracing graph. Number of edges and alarm input rate The "overload trigger judgment" module in the diagram is used to compare the above state variables with the budget and threshold, where the budget includes the node budget. Calculate Threshold is When a condition exceeds the limit, the "Control Strategy" module in the graph is entered, and at least one of the following operations, "Discard / Aggregate / Delay Edge Building / Prune," is executed to suppress the graph size from growing too fast and reduce the processing load. Among them, "Discard" means to directly discard low-priority events, "Aggregate" means to increase the merging and compression intensity, "Delay Edge Building" means to postpone the establishment of some associated edges, and "Prune" means to reduce the number of associated edges to be retained.

[0050] The method of the present invention includes the following steps: Step 1, Alarm Access and Event Standardization: Receive alarms generated by rule-based IDS from the host domain, vehicle Ethernet domain, and CAN domain. Parse each alarm and map it to a standardized event. The standardized event includes at least an alarm type identifier, event time, source subsystem identifier, object entity information, and an evidence field. The alarm type identifier is obtained by normalizing the alarm rule name or alarm rule number triggered by each subsystem rule. The object entity information includes at least one of a process identifier, network endpoint identifier, or CAN message identifier. The evidence field is used to retain... The original observation data or its summary information corresponding to the alarm shall include at least one or more of the following: For host domain alarms, process identifier, executable file path or hash, user identifier, file path, socket information or system call type; for vehicle Ethernet domain alarms, source / destination IP address, source / destination port, MAC address, protocol type, service identifier, session identifier, message length or payload summary; for CAN domain alarms, CAN message identifier, bus channel, data length code (DLC), data field, signal name / signal value or transmitting / receiving ECU identifier.

[0051] Step 2, Windowing Buffering and Out-of-Order Tolerance: The standardized events are written into circular buffers divided by subsystem, and the event set within the window is organized based on a sliding time window. An event time watermark is set to absorb late events within a preset out-of-order tolerance range. Events exceeding the out-of-order tolerance range or not within the sliding time window are discarded or downgraded. Circular buffers are set for the host domain, vehicle Ethernet domain, and CAN domain respectively; the event time watermark is determined based on the current window reference time and the preset out-of-order tolerance duration; events whose times are earlier than the watermark but are still within the sliding time window are allowed to participate in subsequent mapping processing.

[0052] In this embodiment, circular buffers are established for the host domain, Ethernet domain, and CAN domain, respectively. Each buffer stores a reference to a normalized event or aggregated event along with the necessary index key.

[0053] When an alarm is received At that time, perform the following operations: (1) Analysis And generate standardized events ; (2) Write ; (3) Based on the current window reference time Calculate window range and water level line ; (4) If If the event occurs, it is considered an over-window event, and the event is either discarded or only written to a downgraded summary record. (5) If and If it is a late event that can be absorbed, it will be included in the window and marked with a late attribute for stability processing during subsequent map building. (6) If If it does not arrive normally, it will be processed in subsequent steps.

[0054] The above mechanism guarantees that: given In this way, late arrivals are contained within a controllable range, and late arrivals exceeding this range will not repeatedly disturb the existing graph structure within the window, thereby improving the stability of online maintenance.

[0055] Step 3, Deduplication, Merging, and Aggregation Compression: Within a sliding time window, standardized events are deduplicated according to a preset deduplication key. Duplicate events are merged into aggregate events, and at least one of the following is updated in the aggregate event: duplicate count, time span, or evidence summary. The deduplication key includes at least a combination of alarm type identifier and object entity information. Updating the aggregate event includes at least one of accumulating the duplicate count, updating the earliest and latest occurrence times, merging evidence field summaries, or retaining representative samples.

[0056] To suppress node bloat caused by sudden alarm bursts, event deduplication and merging are performed within the window. Let the deduplication key function be:

[0057] in Extract results for entity keys. For any new event within the window. : (1) In the mapping table China and Israel Check if a corresponding aggregate event exists. ; (2) If it does not exist, create a new aggregate event. and initialize , ; (3) If it exists, then update: , , Slight update (e.g., keep the most recent) (each item represents a sample or an updated hash digest). (4) As the node carrier for subsequent graph construction (i.e., the node correspondence) Instead of repeating everything This reduces the number of nodes and the overhead of establishing duplicate edges.

[0058] In an optional implementation, different merging strategies can be configured for different alarm types. For example, high-frequency heartbeat alarms or repetitive scan alarms can be aggregated first, while representative samples of strong semantic alarms can be retained for evidence collection.

[0059] Step 4, Indexed Candidate Retrieval and Incremental Graph Building: Create or update event nodes in the alarm tracking graph for standardized or aggregated events entering the sliding time window, and maintain an index structure for candidate association retrieval to generate a set of candidate predecessor nodes. The index structure includes at least one of the following: a time bucket index, an inverted index built by alarm type identifier, and a mapping index built by object entity information, to avoid a full traversal of all nodes within the sliding time window when generating the set of candidate predecessor nodes.

[0060] To avoid full pairwise comparisons within a window, this embodiment employs indexed candidate retrieval. At least one of the following index structures is maintained (which can be used in combination): (1) Time bucket index: by time granularity Divide the time into buckets (in seconds), and maintain a list of nodes within each bucket. ; (2) Type Inverted Index: Create an inverted index for alarm type identifiers. ; (3) Entity mapping index: Establish a mapping for entity keys .

[0061] When a new node Enter window (corresponding event) When generating a candidate predecessor set based on the index, ,For example:

[0062] in Indicates and A finite set of adjacent time buckets is used to limit the time neighborhood, thereby keeping the candidate size and retrieval cost under control.

[0063] Then, for each candidate node Perform "association determination" and decide whether to establish an edge. Association determination can be based on a preset set of rules. The invention provides, for example, one or a combination of time proximity constraints, entity consistency constraints, source domain compatibility constraints, topological reachability constraints, or vehicle state consistency constraints; the core of the invention lies in the overload control mechanism for candidate generation and online maintenance, and the association determination rules. The configuration can be replaced according to the vehicle model and IDS.

[0064] Step 5: Fork Control, Degree Constraint Pruning, and Priority Retention: Perform alarm association determination on candidate predecessor nodes and the current event node; when the preset association determination rules are met, establish a directed association edge from the predecessor node to the current node, and the direction of the directed association edge is determined according to the event time from earliest to latest; and apply an in-degree upper limit and / or an out-degree upper limit to each event node. When the number of candidate association edges exceeds the degree upper limit, retain some association edges and prune the remaining association edges according to the priority rules. The association determination rules include at least one or more of the following conditions: time proximity constraint (the time difference between two events does not exceed a threshold). The constraints include object entity consistency or session consistency constraints, cross-domain function / protocol compatibility constraints, and reachability constraints based on the vehicular network topology. Priority rules are determined based on at least one of the following: event time proximity, aggregated event duplicate count, evidence field integrity, source subsystem level, or historical association stability, and candidate association edges are retained or pruned according to the stated priority.

[0065] To control the size of the fork in the tracing graph, for each node Set the in-degree limit and the upper limit of out-degree When on candidate precursor set When establishing edges: (1) For each candidate edge Calculate priority score Priority scores can be weighted by the following factors: event time proximity, aggregate count, etc. Evidence integrity score, source subsystem level, historical stability, etc.; (2) According to Sort the candidate edges and keep only the top ones. Cut along the edge of the strip, and trim the rest along the edge. (3) The same applies to outgoing edges, only retaining the first edge. Striped edge; (4) Write the reason for the trimming (degree exceeding the limit, insufficient priority, etc.) into the tracking record. .

[0066] By using degree constraints and priority preservation, the graph structure within the window maintains controllable bifurcation, thereby limiting the growth of the number of edges and stabilizing online maintenance latency.

[0067] Step 6: Resource Budget-Driven Overload Control: Set node and / or edge budgets for the alarm tracing graph and monitor the alarm input rate. When the alarm tracing graph size exceeds the budget or the alarm input rate exceeds a preset threshold, trigger an overload control strategy to perform at least one of the following operations on low-priority events: discarding, merging and compressing, delaying edge construction, or pruning. The overload control strategy includes: when the budget exceeds the limit, prioritizing the retention of event nodes and their associated edges related to the currently active path, and discarding or merging and compressing low-priority events on inactive paths.

[0068] Overload control is triggered when an alarm occurs suddenly or the size within the window grows too rapidly. Let the node budget be... This represents the maximum number of nodes that can be retained in the alarm tracking graph; let the edge budget be... This represents the maximum number of associated edges that can be retained in the alarm tracing graph; let the input rate threshold be... This represents the maximum allowed alarm input rate to be processed per unit of time. Each statistical period... Calculate the alarm input rate $r$ and the size of the current alarm tracing graph. and And perform the following operations: (1) If and and Normal process handling; (2) If any condition is not met, the overload control strategy is triggered. The overload control strategy It includes at least one or a combination of the following operations: (2.1) Discard: Events of low-priority alarm types or low-trust source domains are discarded directly; (2.2) Enhanced aggregation: Increase the aggregation strength, for example, by expanding the equivalence range of deduplicated bonds or increasing the compression ratio of representative samples; (2.3) Delayed edge building: Only create nodes and delay the establishment of some associated edges, and then build them after the load decreases; (2.4) Edge trimming: Reduce the upper limit of in-degree and the upper limit of out-degree Alternatively, increase the retention threshold to quickly reduce the number of edges; (3) Write the triggering reason (budget overrun or rate overrun) and the specific strategy action into the tracking record. It also updates statistical counts, including the number of discards, merges, delays, and cuts.

[0069] In an optional implementation, an active path priority strategy can be set, that is, to give higher retention priority to path-related nodes that have been recently accessed or output, and to prioritize the pruning of nodes that have not been updated for a long time, thereby improving the retention rate of key tracking information.

[0070] Step 7: Expired Event Removal, Two-Stage Deletion, and Tracking Record Solidification: As the sliding time window progresses, expired event nodes and their related edges that exceed the window's range are removed. Source and processing information is recorded for the retained nodes and edges to form tracking records. These tracking records are used for real-time tracking and tracing on the vehicle side or for offline evidence collection and analysis. The tracking records include at least the original alarm reference corresponding to the event node, standardized event mapping information, the triggering reasons for deduplication and merging and overload control, and the basis for retaining or pruning related edges, to provide auditable evidence for tracing and tracing.

[0071] As the window advances, it is necessary to remove superwindow nodes and edges to reclaim resources. This embodiment employs a two-stage deletion process to reduce the overhead of frequent deletions: (1) Marking phase: When the node The corresponding event time is satisfied At that time, Mark it as an expired candidate and disconnect its associated edges or mark the associated edges as invalid; (2) Cleanup phase: When the cleanup cycle is reached When a preset security condition is met (e.g., the number of expired candidates exceeds a threshold), expired candidate nodes and their invalid edges are deleted in batches, and each index structure is updated synchronously. (3) Record solidification: Retain necessary summaries (e.g., type, time span, count, source and reason for pruning) for deleted nodes and edges, and write them into the tracking record. This is to support offline auditing and evidence review.

[0072] Example of tracking record fields (for auditing and forensics): To ensure auditability, tracking records... Structured entries can be used for storage. Each node record must include at least: (1) Node identifier With corresponding event fields ; (2) Original alarm reference (log offset, hash, or index number); (3) Standardized mapping information (field mapping rule version number); (4) Deduplication and merging information (dkey, number of merges, representative sample summary); (5) Overload control information (whether it was discarded / whether edge construction was delayed / whether it was pruned, trigger reason); (6) Edge retention criteria (priority score, degree constraint clipping results).

[0073] Each edge record must include at least: source and destination node identifiers, creation time, and a set of association determination rules. The number or summary, and the reason for being cut / retained.

[0074] To facilitate project implementation, parameters can be set according to vehicle model computing power and alarm intensity: window length Desirable - Seconds; Out-of-order tolerance time Desirable - Milliseconds; time bucket granularity Desirable - milliseconds; degree constraints Desirable - ;Budget Determined by available memory and expected latency; input rate threshold The value is determined by the CPU available to the ECU and the desired processing cycle. The above values ​​are merely examples and do not constitute a limitation of the present invention.

[0075] As can be seen from the above embodiments, under conditions of limited vehicle gateway resources and sudden, out-of-order alarms, the present invention can achieve stable online maintenance of alarm tracking graphs and form auditable tracking records to support real-time tracking and offline evidence collection. This is achieved through mechanisms such as windowed buffering, water level out-of-order tolerance, deduplication and aggregation compression, indexed candidate retrieval, degree constraint pruning, budget-driven overload control, and expired removal and recycling.

Claims

1. A method for online maintenance and overload control of an on-board multi-source IDS alarm correlation tracing graph, characterized in that, Includes the following steps: (1) Alarm access and event standardization: Receive alarms generated by regular IDS from the host domain, vehicle Ethernet domain and controller LAN CAN domain, parse each alarm and map it into a standardized event. The standardized event includes at least alarm type identifier, event time, source subsystem identifier, object entity information and evidence field. (2) Windowed buffer and out-of-order tolerance: The standardized events are written into the circular buffer divided by subsystem, and the event set within the window is organized based on the sliding time window. At the same time, the event time water level is set to absorb late events within the preset out-of-order tolerance range, and events that exceed the out-of-order tolerance range or are not within the sliding time window are discarded or downgraded. (3) Deduplication and aggregation compression: Deduplication of standardized events is performed within a sliding time window according to a preset deduplication key, duplicate events are merged into aggregate events, and at least one of the duplicate count, time span or evidence summary of the aggregate events is updated. (4) Incremental graph building and index update: Create or update event nodes in the alarm tracking graph for standardized or aggregated events that enter the sliding time window, and maintain the index structure for candidate association retrieval to generate a set of candidate predecessor nodes; (5) Alarm association and fork control: Perform alarm association determination on candidate predecessor nodes and current event nodes; when the preset association determination rules are met, establish a directed association edge from the predecessor node to the current node, and the direction of the directed association edge is determined from early to late according to the event time; and apply an in-degree limit and / or an out-degree limit to each event node. When the number of candidate association edges exceeds the degree limit, retain some association edges and prune the rest of the association edges according to the priority rules. (6) Resource budget-driven overload control: Set the node budget and / or edge budget of the alarm tracing graph and monitor the alarm input rate. When the size of the alarm tracing graph exceeds the budget or the alarm input rate exceeds the preset threshold, trigger the overload control strategy and perform at least one of the following operations on low-priority events: discard, merge and compress, delay edge building or edge pruning. (7) Expired event removal and tracking record solidification: as the sliding time window progresses, expired event nodes and their related edges that exceed the window range are removed, and source information and processing information are recorded for the retained nodes and edges to form tracking records. The tracking records are used for real-time tracking and tracing on the vehicle side or offline evidence collection and analysis.

2. The online maintenance and overload control method for vehicle-mounted multi-source IDS alarm correlation tracking graph according to claim 1, characterized in that, The alarm type identifier in step (1) is obtained by normalizing the alarm rule name or alarm rule number triggered by each subsystem rule, and the object entity information includes at least one of process identifier, network endpoint identifier or CAN message identifier.

3. The online maintenance and overload control method for vehicle-mounted multi-source IDS alarm correlation tracking graph according to claim 1, characterized in that, The evidence field in step (1) is used to retain the original observation basis or its summary information corresponding to the alarm, including at least one or more of the following: for host domain alarms, it includes process identifier, executable file path or hash, user identifier, file path, socket information or system call type; for vehicle Ethernet domain alarms, it includes source / destination IP address, source / destination port, MAC address, protocol type, service identifier, session identifier, message length or payload summary; For CAN domain alarms, this includes CAN message identifier, bus channel, data length code (DLC), data field, signal name / signal value, or transmitting / receiving ECU identifier.

4. The online maintenance and overload control method for vehicle-mounted multi-source IDS alarm correlation tracking graph according to claim 1, characterized in that, Step (2) includes: setting circular buffers for the host domain, vehicle Ethernet domain and CAN domain respectively; determining the event time water level based on the current window reference time and the preset out-of-order tolerance time; and allowing events whose event time is earlier than the water level and are still within the sliding time window to participate in subsequent mapping processing.

5. The online maintenance and overload control method for vehicle-mounted multi-source IDS alarm correlation tracking graph according to claim 1, characterized in that, The deduplication key in step (3) includes at least a combination of alarm type identifier and object entity information, and the update of the aggregated event includes at least one of accumulating duplicate counts, updating the earliest and latest occurrence times, merging evidence field summaries, or retaining representative samples.

6. The online maintenance and overload control method for vehicle-mounted multi-source IDS alarm correlation tracking graph according to claim 1, characterized in that, The index structure in step (4) includes at least one of the following: time bucket index, inverted index established by alarm type identifier, and mapping index established by object entity information, so as to avoid full traversal of all nodes within the sliding time window when generating the candidate predecessor node set.

7. The online maintenance and overload control method for vehicle-mounted multi-source IDS alarm correlation tracking graph according to claim 1, characterized in that, The association determination rules in step (5) include at least one or more of the following conditions: time proximity constraint, object entity consistency or session consistency constraint, cross-domain function / protocol compatibility constraint, and reachability constraint based on vehicle network topology.

8. The online maintenance and overload control method for vehicle-mounted multi-source IDS alarm correlation tracking graph according to claim 1, characterized in that, The priority rules in step (5) are determined based on at least one of the following: event time proximity, aggregated event repetition count, evidence field integrity, source subsystem level, or historical association stability, and candidate association edges are retained or pruned according to priority.

9. The online maintenance and overload control method for vehicle-mounted multi-source IDS alarm correlation tracking graph according to claim 1, characterized in that, The overload control strategy in step (6) includes: when the budget exceeds the limit, priority is given to retaining event nodes and their associated edges related to the current active path, and low-priority events on inactive paths are discarded or merged and compressed.

10. The online maintenance and overload control method for vehicle-mounted multi-source IDS alarm correlation tracing graph according to claim 1, characterized in that, In step (7), the tracking record includes at least the original alarm reference corresponding to the event node, the event standardization mapping information, the triggering reasons for deduplication and overload control, and the basis for retaining or pruning related edges, so as to provide auditable traceability evidence.

Images