Security event detection method and device, storage medium, program product and vehicle

Abstract

The invention relates to a safety event detection method and device, a storage medium, a program product and a vehicle, and according to detection information related to a vehicle alarm event, a safety verification result of the alarm event is output. According to the method, the alarm event is traced by using the detection information related to the alarm event, so that the vulnerability of the security attack is positioned; the security event analysis efficiency can be improved, and the traceability of the security event is improved.

Description

Technical Field

[0001] This application relates to the field of security detection, and more particularly to a method, device, storage medium, program product, and vehicle for detecting security incidents. Background Technology

[0002] Intelligent connected vehicles are complex cyber-physical systems. Their complex software functions and potential impact on the physical world require the system to have controllable and traceable network security capabilities, that is, the system must be able to effectively detect and trace network security attacks.

[0003] Currently used security detection methods cannot accurately trace the source of security incidents, which affects the results of security incident analysis and system vulnerability location, and consequently affects system repair and improvement. Summary of the Invention

[0004] This application provides a method, device, storage medium, program product, and vehicle for detecting security events, aiming to solve the problem of inaccurate detection of related security events.

[0005] Firstly, this application provides a method for detecting security incidents, comprising:

[0006] Based on the detection information related to the vehicle alarm event, output the security verification result of the alarm event.

[0007] As a feasible implementation of this application, the security verification result includes security events, alarm events, and false alarm events.

[0008] As a feasible implementation of this application, the security verification result is obtained by processing the detection information using a preset topology graph.

[0009] As a feasible implementation of this application, the preset topology diagram is generated based on at least one of hardware topology, software topology, and data flow topology.

[0010] As a feasible implementation of this application, the preset topology diagram includes at least a hardware and software topology diagram; the method further includes:

[0011] Based on the hardware topology and the software topology, the hardware and software topology diagram is generated.

[0012] As a feasible implementation of this application, the preset topology diagram includes at least a functional topology diagram; the method further includes:

[0013] Based on the software topology and the data flow topology, the functional topology diagram is generated.

[0014] As a feasible implementation of this application, generating the functional topology diagram based on the software topology and the data flow topology includes:

[0015] Based on the data flow topology, a function call graph is obtained;

[0016] Based on the software topology and the function call graph, the functional topology graph is generated.

[0017] As a feasible implementation of this application, the preset topology graph includes at least an extended data flow topology graph; the method further includes:

[0018] The data flow topology is expanded to obtain an extended data flow topology graph.

[0019] As a feasible implementation of this application, the method further includes:

[0020] At least one of the software topology, hardware topology, and data flow topology is simplified to obtain a simplified software topology, a simplified hardware topology, and / or a simplified data flow topology, so as to generate the preset topology diagram based on the simplified software topology, the simplified hardware topology, and / or the simplified data flow topology.

[0021] As a feasible implementation of this application, the security verification result of the alarm event is obtained by processing the detection information using a preset topology graph, including:

[0022] Determine the set of associated components that are related to the vehicle alarm event based on the detection information related to the alarm event;

[0023] An event topology diagram of the associated component set is generated based on the preset topology diagram;

[0024] The security verification result of the alarm event is determined based on the event topology graph.

[0025] As a feasible implementation of this application, the preset topology map includes a preset event topology map, and the step of determining the security verification result of the alarm event based on the event topology map includes:

[0026] Based on the comparison results between the event topology diagram and the preset event topology diagram, the security verification result of the alarm event is determined.

[0027] As a feasible implementation of this application, the preset event topology map includes at least a preset first event topology map and a preset second event topology map. The step of determining the security verification result of the alarm event based on the comparison result between the event topology map and the preset event topology map includes:

[0028] If the event topology map matches the preset first event topology map, then the security verification result of the alarm event is determined to be a non-security event.

[0029] If the event topology map matches the preset second event topology map, then the security verification result of the alarm event is determined to be a security event.

[0030] As a feasible implementation of this application, the preset first event topology diagram includes the topological relationship between events when the vehicle is under normal operating conditions and / or the topological relationship between events when the vehicle is under abnormal operating conditions, and the non-safety events include false alarm events and / or normal defect alarms.

[0031] As a feasible implementation of this application, the matching of the event topology graph with the preset event topology graph means that the topological structure of the event topology graph matches the topological structure of the preset event topology graph.

[0032] As a feasible implementation of this application, the step of generating an event topology diagram of the associated component set based on the preset topology diagram includes:

[0033] An event topology diagram of the associated component set is generated based on at least one of the hardware / software topology diagram, functional topology diagram, and extended data flow topology diagram in the preset topology diagram.

[0034] As a feasible implementation of this application, the step of generating an event topology diagram of the associated component set based on at least one of the hardware / software topology diagram, functional topology diagram, and extended data flow topology diagram in the preset topology diagram includes:

[0035] If there are no cross-domain components in the set of associated components, an event topology diagram of the set of associated components is generated based on the functional topology diagram and / or the extended data flow topology diagram.

[0036] In the case where there are cross-domain components in the set of associated components, an event topology diagram of the set of associated components is generated based on the hardware and software topology diagram, the functional topology diagram, and the extended data flow topology diagram.

[0037] As a feasible implementation of this application, the step of generating an event topology diagram of the associated component set based on the hardware / software topology diagram, the functional topology diagram, and the extended data flow topology diagram includes:

[0038] An initial event topology diagram of the associated component set is generated based on the hardware and software topology diagram;

[0039] The initial event topology is expanded based on the functional topology to obtain an expanded event topology.

[0040] The extended event topology graph is updated based on the extended data flow topology graph to obtain the event topology graph of the associated component set.

[0041] As a feasible implementation of this application, the method further includes:

[0042] If the alarm event is a security event, a security analysis is performed on the alarm event.

[0043] As a feasible implementation of this application, the security analysis of the alarm event includes:

[0044] The target topology is obtained by tracing the event topology of the alarm event through an expanded data flow topology graph.

[0045] The security analysis results of the alarm event are determined based on the event source node in the target topology.

[0046] As a feasible implementation of this application, the step of determining the security analysis result of the alarm event based on the event source node in the target topology includes:

[0047] Based on the type of the event source node in the target topology, the security analysis result of the alarm event is determined.

[0048] As a feasible implementation of this application, determining the security analysis result of the alarm event based on the type of the event source node in the target topology includes:

[0049] If the event source nodes in the target topology include user operation type source nodes, the security analysis result of the alarm event is determined to indicate that there is a security risk.

[0050] If the event source nodes in the target topology include source nodes that are not user-operated, the security analysis result of the alarm event is determined to indicate that there is a need for remediation.

[0051] As a feasible implementation of this application, the method further includes:

[0052] Based on preset operation characteristics and the behavioral characteristics of each event source node, the event source nodes are filtered to obtain target source nodes in the target topology that do not match the operation characteristics, so as to determine the security analysis result of the alarm event based on the target source nodes.

[0053] As a feasible implementation of this application, the method further includes:

[0054] If no event source node exists in the target topology, the target topology will be reported and / or a preset prompt message will be output to indicate that the alarm event cannot be analyzed.

[0055] As a feasible implementation of this application, the step of tracing the event topology of the alarm event by extending the data flow topology to obtain the target topology includes:

[0056] Extract the tracing information associated with each event node in the event topology from the extended data flow topology;

[0057] Based on the log information of the alarm event, the source tracing information is filtered to obtain the target source tracing information;

[0058] The event topology is processed based on the target tracing information until the target topology is obtained.

[0059] As a feasible implementation of this application, processing the event topology based on the target tracing information until the target topology is obtained includes:

[0060] The event nodes in the event topology are replaced based on the source nodes in the target source information, and the edge information of the source nodes is generated in the event topology to obtain the updated event topology.

[0061] The updated event topology is processed by expanding the data flow topology until the event topology can no longer be updated. Then, branches in the current event topology that do not contain event source nodes are removed to obtain the target topology.

[0062] As a feasible implementation of this application, the log information of the alarm event includes log information within a preset interval time corresponding to the trigger time of the alarm event.

[0063] As a feasible implementation of this application, the data flow topology is determined by function calls and data transmission information between the vehicle's software programs and / or hardware components.

[0064] As a feasible implementation of this application, the security analysis of the alarm event includes:

[0065] Obtain the attack event associated with the alarm event;

[0066] Security analysis is performed on the alarm event based on the attack event.

[0067] As a feasible implementation of this application, the method further includes:

[0068] The attack events are filtered based on the log information of the alarm events to obtain the target attack events, and the alarm events are then used for security analysis based on the target attack events.

[0069] As a feasible implementation of this application, the method further includes:

[0070] In response to an alarm event detected by the vehicle via a data packet.

[0071] As a feasible implementation of this application, the packet detection includes at least one of deep packet detection and / or deep dynamic flow detection.

[0072] Secondly, this application provides a controller on which an event detection system and a security analysis system are deployed, and the controller is communicatively connected to the domain controller of the vehicle;

[0073] The event detection system is used to detect alarms for events reported by the domain controller of the vehicle, and after an alarm event is triggered, the security analysis system processes the detection information related to the vehicle alarm event and outputs the security verification result of the alarm event.

[0074] Thirdly, this application provides an electronic device, including a processor; a memory for storing processor-executable instructions; wherein the processor is configured to perform the steps of the security event detection method described in any of the preceding claims.

[0075] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, the computer program being loaded by a processor to perform the steps of the security event detection method described in any of the preceding claims.

[0076] Fifthly, this application provides a computer program product comprising a computer program that, when executed by a processor, causes the computer program product to perform the steps of the security event detection method as described in any of the preceding claims.

[0077] Sixthly, this application provides a vehicle including the electronic equipment described above.

[0078] This application responds to vehicle alarm events and uses related events associated with the alarm events to trace the source of the alarm events. It analyzes the security verification results of the alarm events from upstream and downstream perspectives, that is, to further detect whether the alarm events are security events, thereby improving the traceability of security events and ensuring the detection effect of case events. Attached Figure Description

[0079] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0080] To gain a more complete understanding of this application and its beneficial effects, the following description will be provided in conjunction with the accompanying drawings, wherein the same reference numerals in the following description denote the same parts.

[0081] Figure 1a This is a schematic diagram illustrating the effect of deep packet inspection.

[0082] Figure 1b This is a schematic diagram illustrating the effect of depth / dynamic flow detection.

[0083] Figure 2 A schematic flowchart illustrating the steps for detecting a security event, provided as an embodiment of this application;

[0084] Figure 3 This application provides a flowchart illustrating the steps for outputting the security verification result of the alarm event based on the associated event in an embodiment of the present application.

[0085] Figure 4a This is a schematic diagram illustrating the effect of a topology for a security event.

[0086] Figure 4b This is a schematic diagram illustrating the topological effects of a normal event.

[0087] Figure 4c A schematic diagram illustrating the effect of a topology for a functional defect event;

[0088] Figure 5 This application provides a schematic flowchart illustrating the steps for performing security analysis on alarm events.

[0089] Figure 6a This is a flowchart illustrating the steps for tracing the event topology based on data flow topology, as provided in an embodiment of this application.

[0090] Figure 6b A schematic diagram illustrating the generation of a security event graph provided in an embodiment of this application;

[0091] Figure 7 This application provides a schematic flowchart illustrating the steps involved in constructing a topology graph.

[0092] Figure 8 A detailed flowchart illustrating the steps involved in detecting a security event, as provided in this application embodiment;

[0093] Figure 9aA schematic diagram of the architecture of a controller provided in an embodiment of this application;

[0094] Figure 9b This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0095] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0096] To clearly understand the implementation scheme of the security event detection method provided in this application embodiment, the application scenarios of security events will be specifically described below. Specifically, the security event detection method provided in this application is mainly aimed at detecting the network security of intelligent connected vehicles. In particular, intelligent connected vehicles are complex cyber-physical systems, often requiring the system to effectively detect and trace network security attacks. However, the hardware architecture, software logic, and data flow of different models and products from different suppliers are not entirely the same, resulting in different security event chain topologies. Therefore, purely event-based methods, especially those based on single or limited event analysis, often have a high false alarm rate due to the lack of system and business information. For example, taking the commonly used packet inspection method for security event detection as an example, it typically includes two types: Deep Packet Inspection (DPI) and Deep / Dynamic Flow Inspection (DFI). Figure 1a As shown, Figure 1a This is a schematic diagram illustrating the effect of deep packet inspection. Figure 1bThis is a schematic diagram illustrating the effects of deep / dynamic flow inspection. It can be seen that deep packet inspection, based on the firewall's core 4-tuple analysis, adds application-layer data traffic analysis, providing more detailed analysis of packet content, such as analyzing and inspecting request headers like IP, TCP, and HTTP. Deep / dynamic flow inspection, on the other hand, is primarily based on application traffic pattern analysis. By analyzing information such as packet length, connection rate, transmitted bytes, and intervals between packets, it matches application traffic characteristics in the model to identify application types. However, for security incidents, most attack traffic characteristics are closely related to attacker habits, and attack traffic is usually relatively small, mixed in with normal business traffic. Therefore, deep / dynamic flow inspection is not ideal in terms of security incident detection efficiency. Furthermore, neither deep packet inspection nor deep / dynamic flow inspection can analyze the context of security incidents, making accurate backtracking of security incidents impossible.

[0097] To address the aforementioned issues, this application, building upon traditional detection methods such as deep packet inspection and deep / dynamic flow inspection, further emphasizes subsequent analysis and backtracking. The aim is to improve the accuracy of identifying potential security events from alarm events, reduce the false alarm rate of existing products, enhance the accuracy of system vulnerability location, and ensure that vehicle-side security alarms and indications are meaningful to users, thus avoiding interference from high false alarm rates.

[0098] For details, please refer to Figure 2 , Figure 2 The flowchart illustrating the steps for detecting a security event provided in this application embodiment specifically includes the following steps:

[0099] S210, based on the detection information related to the vehicle alarm event, output the security verification result of the alarm event.

[0100] In this embodiment of the application, the detection information related to the vehicle alarm event usually refers to other event information that is associated with the alarm event.

[0101] In this embodiment, vehicle alarm events can still be detected using safety detection tools in related technologies. That is, in response to vehicle alarm events, the following typically applies:

[0102] In response to an alarm event detected by the vehicle via a data packet.

[0103] As one feasible implementation, the packet detection includes at least one of deep packet inspection and / or deep dynamic flow inspection, that is, it can be implemented using the aforementioned tools such as DPI, DFI or firewalls, and this application does not limit it.

[0104] When a corresponding alarm event is triggered by a safety detection tool, in this embodiment of the application, the detection information related to the vehicle alarm event will be further used to trace and locate the source of the alarm event, thereby further determining the safety verification result of the alarm event. The safety verification result usually includes a safety event, a defect alarm event, or a false alarm event, to indicate whether the alarm event is a specific safety event, a defect alarm event caused by a normal functional defect, or a false alarm event that does not pose a safety or alarm risk.

[0105] Furthermore, based on the detection information related to the vehicle alarm event, the security verification result of the alarm event is output. This can typically be obtained by processing a preset topology graph with a topological structure, pre-constructed based on information such as the vehicle's hardware and software architecture and data transmission. Specifically, to facilitate understanding of the scheme for pre-constructing the preset topology graph, the preset topology graph will be explained in detail below.

[0106] Specifically, in one feasible embodiment, the preset topology map is generated based on at least one of hardware topology, software topology and data flow topology, that is, the preset topology map may include multiple topology maps.

[0107] For example, in one embodiment, the preset topology diagram includes a hardware and software topology diagram, which is typically obtained by processing the hardware and software topology.

[0108] Alternatively, in one embodiment, the preset topology diagram further includes a functional topology diagram. Specifically, the functional topology diagram can be obtained based on the software topology and the data flow topology. The generation of the functional topology diagram based on the software topology and the data flow topology may specifically include:

[0109] Based on the data flow topology, a function call graph is obtained;

[0110] Based on the software topology and the function call graph, the functional topology graph is generated.

[0111] In other words, by parsing the data flow topology, the function call relationships can be obtained, forming a function call graph. Then, based on the software topology and the function call relationships of each software, a functional topology graph can be obtained.

[0112] Alternatively, in one embodiment, the preset topology graph further includes an extended data flow topology graph, wherein the extended data flow topology graph can be obtained by expanding the data flow topology graph; that is, the method for generating the extended data flow topology graph includes:

[0113] The data flow topology is expanded to obtain an extended data flow topology graph.

[0114] Specifically, in one feasible implementation, extending the data flow topology can be further achieved by updating the nodes in the initial data flow topology graph based on the function information between software components. In other words, the methods for generating the extended data flow topology graph include:

[0115] Based on the data flow topology, an initial data flow topology graph is obtained;

[0116] The nodes in the initial data flow topology graph are updated based on the software components and the function information between the software components to obtain the extended data flow topology graph.

[0117] Here, the software components can be software that includes multiple vehicle control domains.

[0118] Of course, to further simplify the topology diagram, in one embodiment, the hardware topology, software topology, and data flow topology used to generate the preset topology diagram can be simplified in advance to obtain a simplified topology. The preset topology diagram is then generated based on the simplified topology, such as the aforementioned hardware and software topology diagram, functional topology diagram, and extended data flow topology diagram, etc. In other words, the method further includes:

[0119] At least one of the software topology, hardware topology, and data flow topology is simplified to obtain a simplified software topology, a simplified hardware topology, and / or a simplified data flow topology, so as to generate the preset topology diagram based on the simplified software topology, the simplified hardware topology, and / or the simplified data flow topology.

[0120] Of course, the embodiments provided above are merely illustrative examples of a preset topology diagram including a single topology diagram. In fact, to improve subsequent detection results, the preset topology diagram typically includes multiple topology diagrams as described above, such as hardware / software topology diagrams, functional topology diagrams, and data flow topologies. To clearly understand the multiple topology diagrams provided in the embodiments of this application, the implementation schemes for constructing multiple topology diagrams will be explained in detail below. For example, please refer to... Figure 7 , Figure 7 This application provides a flowchart illustrating the steps for constructing a topology graph, specifically including the following steps:

[0121] 701: Extract the hardware topology from the vehicle's EEA (Electrical / Electronic Architecture) topology design and hardware architecture diagram. First, simplify the hardware architecture to include the core processing unit and human-machine interface (e.g., touchscreen, microphone); external access interfaces (e.g., Wi-Fi (mobile hotspot), Bluetooth, USB (Universal Serial Bus), TF (TransFlash) card, etc.). Embed the simplified hardware topology into the EEA topology to generate a hardware topology diagram.

[0122] 702: Simplified Hardware Topology Diagram G hw Remove devices that cannot send complex or important commands; these are typically low-speed wired access devices such as LIN (Local Interconnect Network), as they usually only respond to simple control commands and cannot send complex control commands to other devices in the vehicle, posing little threat to vehicle security. Alternatively, low-risk devices can be removed based on the TARA (Threat Analysis and Risk Assessment) results of the components. Generate a simplified hardware topology diagram;

[0123] 703: Extracting Software Topology G from Software Design Documents and Other Materials sw Software topologies can be obtained from design materials such as software design documents and package diagrams, or they can be extracted from the source code.

[0124] 704: Software Topology Simplification: Due to engineering practices, some libraries or functions in the design are unused in the actual production system and need to be removed through topology simplification. Furthermore, because modern systems have sandboxing and memory isolation mechanisms, although multiple applications may interact with the same component, this component is isolated between different applications. Therefore, software components should be split by application to avoid building a large component relationship graph containing multiple applications. Further, the relationship graph with a single-chain structure can be compressed, retaining the first and last nodes and adding annotations to intermediate nodes on the edges.

[0125] 705: Extracting Data Flow Topology Graphs (G) from Data Flow Documents, Source Code, etc. data This allows us to obtain the most detailed data flow topology diagram. Data flow is the foundation for constructing various event chains and also the data layer manifestation of normal behavior. Apart from code injection attacks, most other operations by attackers are based on probing normal data flow or obtaining unauthorized information based on normal data flow.

[0126] 706: Data Flow Topology Simplification. Based on software component relationships, a data flow graph within a single component retains only one node; for data flows interacting with external components, interaction nodes and control flow nodes are retained, and connected computation nodes are merged. For data flow graphs between multiple components, single-chain relationships are compressed, and within the same component relationship graph, the beginning and end are retained.

[0127] 707: Combine software deployment information with hardware topology information and append it to the software topology G. SW (V, E), where each vertex adds a deployment hardware ID based on the deployment. For multi-core, multi-processor systems, add the processor ID / core ID. If virtualization technology is used, add the virtual machine device ID. A data example is: v(hw_id[.soc_id][.vm_id]). Related information can be stored in XML, JSON, or binary text formats, with no format restrictions. For bus-based or wireless communication, the corresponding 'e' indicates the physical communication device and communication protocol type, such as CAN (Controller Area Network) / TCP (Transmission Control Protocol) / UDP (User Datagram Protocol), etc. Additionally, if a note is provided regarding the security technology used in the communication, for compatibility, hw_id = 0 can be added to indicate memory communication or other communication methods that do not rely on bus or wireless methods.

[0128] 708: Integrate software component diagrams and function call diagrams to generate a functional topology diagram G fun (V, E). To address the phenomenon of multiple call channels between components, cross-component function calls are extracted from the function call graph and extended to the component graph to form a functional topology graph. This graph is a hypergraph, and there may be multiple function call edges between two components.

[0129] 709: In the data flow topology graph G d Add component v to node V of (V, E). sw And function information fun, V(v sw .fun) generates an extended data flow topology graph G data (V(v sw This information can be quickly linked to functional topology diagrams or software / hardware topology diagrams for source tracing and root cause analysis.

[0130] 710: G SW G fun G data Store the data in a file, such as a knowledge graph repository, or in a custom format file. Then, deploy the three graphs according to the V-shaped arrangement of their associated information to create an index directory. The index is then formatted according to the V-shaped arrangement. swPerform indexing.

[0131] Based on steps 701 to 710 above, a basic topology graph is constructed and can be used for subsequent processing.

[0132] Furthermore, based on the foregoing, please refer to Figure 3 , Figure 3 The security verification result of the alarm event obtained by processing the detection information using a preset topology map according to the embodiments of this application specifically includes steps S310 to S330:

[0133] S310, determine the set of associated components that are related to the vehicle alarm event based on the detection information related to the alarm event.

[0134] In this embodiment of the application, the detection information related to vehicle alarm events typically describes event information associated with the alarm event. Based on this, by parsing the detection information, such as analyzing the triggering components of event information related to each domain alarm event, the set of associated components that are related to the alarm event can be further determined for subsequent security verification processing.

[0135] S320, Generate an event topology diagram of the associated component set based on the preset topology diagram.

[0136] In this embodiment, based on the aforementioned determination of the set of associated components (i.e., multiple components) related to the alarm event, an event topology diagram of the associated component set can be generated by further combining the aforementioned preset topology diagrams. Specifically, the event topology diagram of the associated component set is generated based on at least one of the hardware / software topology diagram, functional topology diagram, and extended data flow topology diagram in the preset topology diagrams. Furthermore, the specific method for generating the event topology diagram can be further based on whether there are cross-domain components in the key component set. Cross-domain components refer to components distributed across multiple control domains of the vehicle. For example, the vehicle's control domains may include the body control domain, chassis control domain, power control domain, and intelligent driving control domain, used to control different structures or functions of the vehicle. When the key component set does not include cross-domain components, meaning the key component set consists entirely of components within the same control domain, it is not necessary to use the hardware / software topology diagram. Instead, the functional topology diagram and / or extended data flow topology diagram of the components within that control domain can be directly determined to generate the event topology diagram of the associated component set. Conversely, if the set of key components includes cross-domain components—that is, components located in different control domains, such as power components in the power control domain and intelligent driving computing components in the intelligent driving control domain—it is often necessary to determine the specific components in the corresponding control domain based on the hardware and software topology diagram. This is then used to further generate an event topology set through a functional extension diagram and an extended data flow topology diagram. Specifically, generating the event topology diagram of the associated component set based on at least one of the hardware and software topology diagram, functional topology diagram, and extended data flow topology diagram in the preset topology diagram includes:

[0137] If there are no cross-domain components in the set of associated components, an event topology diagram of the set of associated components is generated based on the functional topology diagram and / or the extended data flow topology diagram.

[0138] When cross-domain components exist in the set of associated components, an event topology diagram for the set of associated components is generated based on the hardware / software topology diagram, the functional topology diagram, and the extended data flow topology diagram. Generating the event topology diagram for the set of associated components from the hardware / software topology diagram, the functional topology diagram, and the extended data flow topology diagram typically includes the following steps:

[0139] An initial event topology diagram of the associated component set is generated based on the hardware and software topology diagram;

[0140] The initial event topology is expanded based on the functional topology to obtain an expanded event topology.

[0141] The extended event topology graph is updated based on the extended data flow topology graph to obtain the event topology graph of the associated component set.

[0142] First, an initial time topology diagram for each component in the set of related components is generated based on the hardware and software topology diagram. Then, the event topology diagram is expanded using the functional topology diagram to obtain the expanded event topology diagram. Finally, the expanded event topology diagram is updated based on the expanded data flow topology diagram to obtain the event topology diagram of the set of related components.

[0143] S330, Determine the security verification result of the alarm event based on the event topology graph.

[0144] In this embodiment of the application, by obtaining the event topology associated with the alarm event, the security verification result of the alarm event can be further confirmed based on the event topology. Specifically, the security verification result is used to indicate whether the alarm event is a security event. For example, the alarm event is a security event, or the alarm event is a false alarm event or an abnormal warning event caused by a functional defect.

[0145] Specifically, determining the security verification result of the alarm event based on the event topology typically involves comparing the event topology with a preset event topology map, and determining the security verification result of the alarm event based on the comparison result. That is, determining the security verification result of the alarm event based on the event topology map includes:

[0146] Based on the comparison results between the event topology diagram and the preset event topology diagram, the security verification result of the alarm event is determined.

[0147] The preset event topology map typically includes multiple event topology maps indicating different types of events. For example, the preset time topology map usually includes a preset first event topology map and a preset second event topology map. Specifically, determining the security verification result of the alarm event based on the event topology typically includes:

[0148] If the event topology map matches the preset first event topology map, then the security verification result of the alarm event is determined to be a non-security event.

[0149] If the event topology map matches the preset second event topology map, then the security verification result of the alarm event is determined to be a security event.

[0150] The matching of the event topology map with the preset event topology map typically refers to the matching of the event topology map of the associated component set with the preset event topology map in terms of structural features of the topology, such as having the same or highly similar event flow directions. Furthermore, the preset first event topology map includes the topological relationships between events when the vehicle is under normal operating conditions and / or the topological relationships between events when the vehicle is under abnormal operating conditions, thereby indicating that the alarm event is a non-safety event, such as an abnormal false alarm event and / or a defect alarm event. The preset second topology map typically includes the topological relationships between events when the vehicle triggers a safety event. For a clearer understanding of the above, please refer to [link to relevant documentation]. Figures 4a-4c The diagrams show different preset event topologies. For example, as shown below... Figure 4a The image shown is a schematic diagram illustrating the effect of a security event topology diagram. Figure 4b The image shown is a schematic diagram illustrating the effect of a normal event topology diagram. Figure 4c The image shown is a schematic diagram illustrating the effect of a functional defect event topology diagram.

[0151] It is understandable that if the event topology graph of the associated component collection is... Figure 4b If the topological characteristics of the normal event topology diagram match those shown, it can be determined that the alarm event itself should be a normal event, meaning it can be understood as a false alarm. Similarly, if the event topology diagram of the associated component set matches... Figure 4c If the topological characteristics of the shown functional defect event topology map match, then this alarm event can be considered a normal warning event triggered by an anomaly, and not a safety event. Therefore, the event can be recorded and uploaded for cloud processing. And in the event topology and... Figure 4a When the topological structure of the security event matches, the current alarm event can be considered a security event, requiring further processing, such as further source tracing and localization of the security event. In other words, the method provided in this application also includes:

[0152] If the alarm event is a security event, a security analysis is performed on the alarm event.

[0153] Specifically, the following will detail the specific steps for security analysis of alarm events. In this embodiment, to trace the source of alarm events, a preset data flow topology graph will be used to perform source analysis based on the aforementioned related events. This determines the event source node of each event, thereby determining the security analysis result of the alarm event. For details, please refer to... Figure 5 , Figure 5 This application provides a flowchart illustrating the steps for security analysis of alarm events, specifically including steps S510 to S520:

[0154] S510, trace the event topology of the associated events of the alarm event through a preset data flow topology diagram to obtain the target topology.

[0155] In this embodiment, the data flow topology diagram refers to the data extracted from the data flow document and source code. Data flow is the foundation for constructing various event chains and represents the data layer of normal behavior. Except for code injection attacks, most other attacker operations are based on probing within normal data flow or obtaining unauthorized information from normal data flow. Furthermore, the data flow topology diagram can be further expanded to include hardware and software architecture information such as vehicle components and function call information between them, etc.

[0156] The event topology of the associated events of the alarm event has been described in detail above, and will not be repeated here.

[0157] Building upon the aforementioned foundation, the event topology of related events can be traced using a data flow topology graph. For example, by tracing each node in the event topology to obtain related nodes in the data flow topology graph, and then readjusting the nodes and edges in the event topology until a topology meeting certain requirements is obtained, the resulting topology can be considered the target topology after tracing the origins of each node in the related events. Specifically, the detailed implementation scheme for tracing the event topology using a data flow topology graph to obtain the target topology will be explained later.

[0158] S520, determine the security analysis result of the alarm event based on the event source node in the target topology.

[0159] In this embodiment of the application, after the aforementioned tracing of the event topology is completed, so that each node in the event topology is traced back to the source node, the security analysis results of the alarm event can be further determined based on the event source node in the target topology.

[0160] Specifically, as a common and feasible implementation, the security analysis result of determining the alarm event based on the event source node in the target topology can usually be determined by the node type of the event source node. That is, determining the security analysis result of the alarm event based on the event source node in the target topology includes:

[0161] Based on the type of the event source node in the target topology, the security analysis result of the alarm event is determined.

[0162] Here, the type of event source node can typically be classified based on the operation command that triggered the event. For example, it can usually include user operation types or non-user operation types, such as system commands. Based on this, the security analysis result of the alarm event is determined according to the type of event source node in the target topology, which can specifically include:

[0163] If the event source nodes in the target topology include user operation type source nodes, the security analysis result of the alarm event is determined to indicate that there is a security risk.

[0164] If the event source nodes in the target topology include source nodes that are not user-operated, the security analysis result of the alarm event is determined to indicate that there is a need for remediation.

[0165] In this embodiment of the application, when the event source node includes a source node of user operation type, that is, when there is an event type caused by user operation, the security analysis result of the alarm event can be considered to be that there is a security risk, that is, it may be caused by abnormal user operation. When the event source node includes a source node of non-user operation type, such as the underlying protocol or other functions, the event is considered to have a repair requirement, that is, it needs to be reported to the cloud for security repair and update.

[0166] Of course, in order to further improve the security analysis results of alarm events, the event source nodes in the target topology can be further matched with the behavioral characteristics of each event source node by using the user's operating habits as preset operating characteristics. This will filter the event source nodes and select the target source nodes that do not match the operating characteristics, that is, the event nodes that do not match the user's operating habits. Based on these target source nodes, the security analysis results of alarm events can be determined more accurately.

[0167] Of course, if there is no event source node in the target topology, it can be assumed that the current resources cannot meet the needs of tracing the event source. In this case, the target topology can be reported, or a preset prompt message can be output to indicate that the current alarm event cannot be analyzed.

[0168] Of course, to better understand the implementation scheme provided in this application for processing event topology until the target topology is obtained, the following will explain it in conjunction with a specific processing flow. For details, please refer to [link / reference needed]. Figure 6a , Figure 6a This application provides a flowchart illustrating the steps for tracing event topology based on data flow topology in an embodiment of the present application. Specifically, it includes steps S610 to S630:

[0169] S610, extract the source information associated with each event node in the event topology from the preset data flow topology.

[0170] In this embodiment, as can be seen from the foregoing description, the data flow topology is the foundation for the construction of various event chains and the data layer representation of normal behavior. It typically describes the data calls or data transmissions between various events. Therefore, by matching each event node in the event topology with the data flow topology, the source information associated with each event node can be extracted from the data flow topology, such as the upstream and downstream event nodes related to the event node, as well as the data transmission information between them, etc.

[0171] S620, the source information is filtered based on the log information of the alarm event to obtain the target source information.

[0172] Based on the above, the source information is filtered through the log information of alarm events. That is, source information that matches the event information in the log needs to be retained, while source information that does not exist or does not match the log information is removed, so as to obtain the target source information that has corresponding records when the system is running.

[0173] Of course, in order to better filter the traceability information, in this embodiment, the log information of the alarm event includes the log within a preset interval time of the trigger time of the alarm event, that is, the log within a given time before the trigger time.

[0174] S630, The event topology is processed based on the target tracing information until the target topology is obtained.

[0175] In this embodiment of the application, based on the target tracing information that exists in the filtered log records, the connection relationship between nodes and edges in the tracing information is used to perform corresponding addition, deletion or replacement operations on the nodes and edges in the event topology, so that the event topology can be updated until the final target topology that meets the requirements is obtained.

[0176] Specifically, processing the event topology typically includes iterative processing. That is, after processing the event nodes to obtain the updated event topology, the updated event topology can be processed again. Specifically, processing the event topology based on the target tracing information until the target topology is obtained includes:

[0177] The event nodes in the event topology are replaced based on the source nodes in the target source information, and the edge information of the source nodes is generated in the event topology to obtain the updated event topology.

[0178] The updated event topology is processed using a preset data flow topology until the event topology can no longer be updated. Then, branches in the current event topology that do not contain event source nodes are removed to obtain the target topology.

[0179] Specifically, to facilitate understanding of the above content, the following will provide a complete explanation of the specific process for processing the event topology. Please refer to [link / reference needed]. Figure 6b , Figure 6b A flowchart illustrating the steps for generating an event topology, as provided in this application embodiment, specifically includes the following steps:

[0180] For a selected event topology, obtain the edge point set of the event topology. Then, obtain the backtracking edges (directed edges pointing to the points) of each point in the edge point set from the data flow topology. Based on the log information, remove the edges and corresponding top and bottom edges in the data flow topology that have no related event records in the log, obtaining the remaining edges and vertices. Then, remove the vertices and corresponding dangling edges from the event topology. Add the remaining edges and corresponding one-sided vertices from the data flow topology to obtain the updated event topology. Repeat the above operations with the updated event topology, i.e., obtain the edge point set and obtain the updated event topology again, until the updated event topology cannot be further processed, or the backtracking log information exceeds the preset time interval. Delete the passive branches in the latest obtained event topology and retain the final obtained topology as the target topology.

[0181] Of course, it should be noted that the aforementioned security analysis of events is based solely on alarm events. In fact, to improve the accuracy of alarm event analysis, as a further feasible implementation of this application, while performing security analysis through alarm events, it is also possible to introduce potential attack events targeting the alarm events, so as to perform security analysis of the alarm events based on the overall attack events. That is to say, the security analysis of the alarm events includes:

[0182] Obtain the attack event associated with the alarm event;

[0183] Security analysis is performed on the alarm event based on the attack event.

[0184] In this embodiment, by merging the event topologies of attack events and alarm events into a subsequent security topology, the security analysis effect of events can be further improved. Furthermore, during the security analysis of alarm events based on attack events, it is also possible to filter attack events based on log information to identify target attack events within a preset time interval, thereby performing security analysis on the alarm events based on the target attack events. Specifically, in this embodiment, an attack tree matching the alarm information type of the alarm event can be selected from a preset set of attack trees of components. Then, based on log information, it is determined whether there is upstream information matching the attack tree. If not, the attack tree can be removed, and the remaining attack tree subgraphs with matching information and the event topology of the alarm events are combined and merged into a topology graph for subsequent security analysis. The implementation scheme for subsequent processing of the topology graph can be found in the foregoing. Figure 5 , Figure 6a as well as Figure 6b The relevant explanations and descriptions will not be repeated here in the embodiments of this application.

[0185] This application responds to vehicle alarm events and uses related events associated with the alarm events to trace the source of the alarm events. It analyzes the security verification results of the alarm events from upstream and downstream perspectives, that is, to further detect whether the alarm events are security events, thereby improving the traceability of security events and ensuring the detection effect of case events.

[0186] Specifically, to facilitate understanding of the complete security incident detection process provided in this application, the following will be combined with the aforementioned solution; please refer to [link / reference]. Figure 8 A detailed procedure for detecting a security incident is provided, specifically including the following steps:

[0187] 801: Initial security incident information is obtained using traditional detection methods. When an alarm is detected by an IDS (intrusion detection system), etc. (this information may be a false alarm, a fault, or a real security incident), the relevant detection information <timestamp t is observed by the security incident component v. sw The alarm information is passed to the analysis and backtracking engine, which is then awakened and begins to execute the subsequent analysis steps.

[0188] 802: Extract the recorded data from the logs, and compare it with component v. sw The set of connected component nodes V' sw Then follow G SW Topology extensions construct event topologies for subsequent processing.

[0189] 803: If the event topology matches the characteristics of the normal topology, ignore the subgraph (indicating that the event may be a false alarm); if the event topology matches the characteristics of the functional defect event topology, log the functional defect and upload it to the cloud as needed. If the event topology has the characteristics of the security event topology, retain the event topology for subsequent security analysis.

[0190] In addition, it is also possible to read data for component v. sw The attack tree set is used to select attack trees that match the alarm information type (there may be multiple trees). Then, logs within the trigger time interval (t ± Δt) are read. If no matching upstream information for the attack tree is found in the logs, the attack tree is removed. The remaining attack tree subgraphs are then merged with the previously generated event topology to form a new temporal topology, which becomes the potential security event subgraph set {G}. sub}

[0191] 804: If the security event sub-graph is empty, it indicates a false alarm or defect. End analysis.

[0192] If the security event subgraph is not empty, further analysis is performed.

[0193] 805: Using a subgraph matching algorithm, match each subgraph in the security event subgraph set {G} one by one in the extended data flow graph. sub For each subgraph, if a matching subgraph is found, proceed to step 806; if no matching subgraph of the original event topology is found, proceed to step 809; other subgraphs, such as the attack tree subgraph, need to be discarded.

[0194] 806: Select a security event subgraph event topology {G sub}, obtain the edge point set V of the subgraph sub ∈V sw From the extended data flow graph G data Get all V sub Backtracking edge E sub (i.e., the directed edge points to V) sub Remove edges (the edges for which no related events are recorded in the log) and their corresponding vertices, and obtain E'. sub ,V' sub From G sub Remove vertex V sub -V' sub And the corresponding overhanging edges, then add E' sub And the corresponding vertex on the other side, to obtain G sub1 Then from G sub1 Select edge vertex V sub1 Repeat the above steps.

[0195] 807: Repeat step 806 to expand the security event subgraph until it cannot be expanded or the backtracking log duration exceeds T; delete all passive branches to obtain the final security event topology graph G. s ; Detect G s Does it contain G? s The subgraph was not analyzed.

[0196] 808: Detecting subgraph G s Does the set of fixed points contain event source class vertices (i.e., user interaction nodes or network access nodes)? If so, it is a security event topology graph. If not, it indicates insufficient vehicle-side information for analysis and backtracking.

[0197] 809: If the subgraph does not contain an event source node (i.e., a user interaction node or a network access node), the topology is reported, an alarm is generated, and the cloud will process it further; otherwise, it is discarded.

[0198] 810: Subgraph G s The set of fixed points contains event source class vertices, filtered based on user habit analysis (such as dwell time at each fixed point). If G s The behavior characteristics and user habits are similar, indicating that the behavior was accidentally triggered by the user. Upload the sub-graph G. s and security events, but without generating a notification; local from {G s Remove the subgraph.

[0199] 811: For all generated dynamic security event subgraphs {G} s Check if the system contains user-operated event sources. If so, generate a clear alert and prompt the user to reconfigure security measures. For other security event sources, since users cannot operate or repair them themselves, the specific risks are only recorded in the system security aggregation log.

[0200] 812: All generated dynamic security event subgraphs {G s The report is uploaded to the cloud, where repair work orders are dispatched.

[0201] As a further feasible implementation of this application, this application also provides a controller, please refer to... Figure 9a , Figure 9a This is an architectural diagram of a controller according to an exemplary embodiment, wherein an event detection system and a security analysis system are deployed on the controller, and the controller is communicatively connected to the domain controller of the vehicle.

[0202] The event detection system is used to detect alarms for events reported by the domain controller of the vehicle, and after an alarm event is triggered, the security analysis system processes the detection information related to the vehicle alarm event and outputs the security verification result of the alarm event.

[0203] For details, please refer to Figure 9a , Figure 9a The security analysis system can specifically exist in the form of a security analysis backtracking engine, while the event detection system can specifically be an IDS or firewall, etc. In addition, the event detection system can also include a log module to read log information of corresponding events. Furthermore, the controller can be set up in the vehicle terminal to communicate with multiple domain controllers of the vehicle through the gateway controller to receive data uploaded by different domain controllers, such as the chassis domain controller, body domain controller, powertrain domain controller, and intelligent driving domain controller. Of course, the controller can also be set up directly in the gateway, or directly in a specific domain to detect events in a specific domain. The embodiments of this application will not be elaborated here.

[0204] In addition, the controller can also communicate with the cloud server to process security events, thereby uploading the corresponding security events to the cloud server.

[0205] Of course, the controller provided above is only one feasible implementation scheme, and the security event detection method provided in this application can also be implemented by other electronic devices.

[0206] Figure 9b This is a block diagram illustrating an electronic device 900 according to an exemplary embodiment. For example... Figure 9b As shown, the electronic device 900 may include a processor 901 and a memory 902. The electronic device 900 may also include one or more of a multimedia component 903, an input / output (I / O) component 904, and a communication component 905. In this embodiment, the electronic device 900 may be a device that integrates and implements the security event detection method provided in this embodiment.

[0207] The processor 901 controls the overall operation of the electronic device 900 to complete all or part of the steps in the aforementioned security event detection method. The memory 902 stores various types of data to support the operation of the electronic device 900. This data may include, for example, instructions for any application or method operating on the electronic device 900, and application-related data such as contact data, sent and received messages, pictures, audio, video, etc. The memory 902 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. Multimedia component 903 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 902 or transmitted via communication component 905. The audio component also includes at least one speaker for outputting audio signals. I / O component 904 provides an interface between processor 901 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 905 is used for wired or wireless communication between the electronic device 900 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IoT, eMTC, or other 5G technologies, or combinations thereof, is not limited here. Therefore, the corresponding communication component 905 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.

[0208] In an exemplary embodiment, the electronic device 900 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the aforementioned method for detecting security events.

[0209] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the security event detection method provided in any of the above embodiments.

[0210] This application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it enables the computer program product to implement the security event detection method provided in any of the above embodiments.

[0211] This application also provides a vehicle equipped with the aforementioned electronic devices.

[0212] In one embodiment, the vehicle can be configured for fully or partially autonomous driving. For example, the vehicle can control itself while in autonomous driving mode, and can determine the current state of the vehicle and its surrounding environment through human intervention, determine the possible behaviors of at least one other vehicle in the surrounding environment, and determine the confidence level corresponding to the probability of that other vehicle performing a possible behavior, and control the vehicle based on the determined information. When the vehicle is in autonomous driving mode, it can be configured to operate without human interaction.

[0213] The vehicle may also include various subsystems, such as a driving system, sensor system control system, one or more peripheral devices, as well as power supply, computer system, and user interface. Optionally, the vehicle may include more or fewer subsystems, and each subsystem may include multiple components, such as multiple ECUs (electronic control units, i.e., vehicle computers) per subsystem.

[0214] In addition, each subsystem and component of the vehicle can be interconnected via wired or wireless means.

[0215] A propulsion system may include components that provide powered motion to the vehicle. In one embodiment, the propulsion system may include an engine, an energy source, a transmission, and wheels / tires. The engine may be an internal combustion engine, an electric motor, an air-compressed engine, or a combination of other types of engines, such as a hybrid engine consisting of a gasoline engine and an electric motor, or a hybrid engine consisting of an internal combustion engine and an air-compressed engine. The engine converts energy into mechanical energy.

[0216] Examples of energy sources include gasoline, diesel, other petroleum-based fuels, propane, other compressed gas-based fuels, ethanol, solar panels, batteries, and other sources of electricity. Energy sources can also power other systems in the vehicle.

[0217] A transmission system can transmit mechanical power from an engine to the wheels. The transmission system may include a gearbox, a differential, and a drive shaft. In one embodiment, the transmission system may also include other components, such as a clutch. The drive shaft may include one or more axles that can be coupled to one or more wheels.

[0218] A sensor system may include several sensors that sense information about the vehicle's surrounding environment. For example, a sensor system may include a positioning system (which could be GPS, BeiDou, or another positioning system), an inertial measurement unit (IMU), radar, a laser rangefinder, and cameras. The sensor system may also include sensors from the vehicle's internal systems being monitored (e.g., an in-vehicle air quality monitor, fuel gauge, oil temperature gauge, etc.). Sensor data from one or more of these sensors can be used to detect objects and their corresponding characteristics (position, shape, orientation, speed, etc.). This detection and identification is a critical function for the safe operation of autonomous vehicles.

[0219] A positioning system can be used to estimate a vehicle's geographical location. An IMU is used to sense changes in the vehicle's position and orientation based on inertial acceleration. In one embodiment, the IMU can be a combination of an accelerometer and a gyroscope.

[0220] Radar can use radio signals to sense objects in the vehicle's surrounding environment. In some embodiments, in addition to sensing objects, radar can also be used to sense the speed and / or direction of travel of objects.

[0221] A laser rangefinder can use lasers to sense objects in the environment in which a vehicle is located. In some embodiments, a laser rangefinder may include one or more laser sources, a laser scanner, one or more processing modules, and other system components.

[0222] The camera can be used to capture multiple images of the vehicle's surroundings. The camera can be a still camera or a video camera.

[0223] A control system controls the operation of a vehicle and its components. Control systems can include various elements, including steering systems, throttles, braking units, computer vision systems, route control systems, and obstacle avoidance systems.

[0224] The steering system is operable to adjust the vehicle's direction of travel. For example, in one embodiment, it can be a steering wheel system.

[0225] The throttle is used to control the engine's operating speed and, consequently, the vehicle's speed.

[0226] The braking unit is used to control the deceleration of the vehicle. The braking unit uses friction to slow down the wheels.

[0227] In other embodiments, the braking unit can convert the kinetic energy of the wheels into electrical current. The braking unit may also take other forms to slow down the wheel rotation speed, thereby controlling the vehicle speed.

[0228] Computer vision systems can be operated to process and analyze images captured by cameras to identify objects and / or features in the environment surrounding a vehicle. These objects and / or features may include traffic signals, road boundaries, and obstacles. Computer vision systems may use object recognition algorithms, structure from motion (SFM) algorithms, video tracking, and other computer vision techniques. In some embodiments, computer vision systems may be used to map the environment, track objects, estimate object velocities, and so on.

[0229] A route control system is used to determine the driving route of a vehicle. In some embodiments, the route control system may combine data from GPS and one or more predetermined maps to determine the driving route for the vehicle.

[0230] Obstacle avoidance systems are used to identify, assess, and avoid or otherwise traverse potential obstacles in the environment in which a vehicle is located.

[0231] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0232] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0233] The embodiments, implementation methods, and related technical features of this application can be combined and substituted for each other without conflict.

[0234] The above are merely preferred embodiments of this application and are not intended to limit this application in any way. Any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of this application without departing from the scope of the technical solution of this application shall still fall within the scope of the technical solution of this application.

Claims

1. A method for detecting security incidents, characterized in that, include: Based on the detection information related to the vehicle alarm event, output the security verification result of the alarm event.

2. The detection method according to claim 1, characterized in that, The security verification results include security events, defect alarm events, and false alarm events.

3. The method according to claim 1 or 2, characterized in that, The security verification result is obtained by processing the detection information using a preset topology diagram.

4. The method according to claim 3, characterized in that, The preset topology diagram is generated based on at least one of hardware topology, software topology, and data flow topology.

5. The method according to claim 4, characterized in that, The preset topology diagram includes at least a hardware and software topology diagram; The method further includes: Based on the hardware topology and the software topology, the hardware and software topology diagram is generated.

6. The method according to claim 4, characterized in that, The preset topology diagram includes at least a functional topology diagram; The method further includes: Based on the software topology and the data flow topology, the functional topology diagram is generated.

7. The method according to claim 6, characterized in that, The process of generating the functional topology diagram based on the software topology and the data flow topology includes: Based on the data flow topology, a function call graph is obtained; Based on the software topology and the function call graph, the functional topology graph is generated.

8. The method according to claim 4, characterized in that, The preset topology diagram includes at least an extended data flow topology diagram; The method further includes: The data flow topology is expanded to obtain an extended data flow topology graph.

9. The method according to any one of claims 4 to 8, characterized in that, The method further includes: At least one of the software topology, hardware topology, and data flow topology is simplified to obtain a simplified software topology, a simplified hardware topology, and / or a simplified data flow topology, so as to generate the preset topology diagram based on the simplified software topology, the simplified hardware topology, and / or the simplified data flow topology.

10. The method according to claim 3, characterized in that, The security verification result of the alarm event is obtained by processing the detection information using a preset topology map, including: Determine the set of associated components that are related to the vehicle alarm event based on the detection information related to the alarm event; An event topology diagram of the associated component set is generated based on the preset topology diagram; The security verification result of the alarm event is determined based on the event topology graph.

11. The method according to claim 10, characterized in that, The preset topology map includes a preset event topology map, and determining the security verification result of the alarm event based on the event topology map includes: Based on the comparison results between the event topology diagram and the preset event topology diagram, the security verification result of the alarm event is determined.

12. The method according to claim 11, characterized in that, The preset event topology map includes at least a preset first event topology map and a preset second event topology map. Determining the security verification result of the alarm event based on the comparison result between the event topology map and the preset event topology map includes: If the event topology map matches the preset first event topology map, then the security verification result of the alarm event is determined to be a non-security event. If the event topology map matches the preset second event topology map, then the security verification result of the alarm event is determined to be a security event.

13. The method according to claim 12, characterized in that, The preset first event topology diagram includes the topological relationships between events when the vehicle is under normal operating conditions and / or the topological relationships between events when the vehicle is under abnormal operating conditions. The non-safety events include abnormal false alarm events and / or defect alarm events.

14. The method according to claim 12, characterized in that, The matching of the event topology graph with the preset event topology graph means that the topological structure of the event topology graph matches the topological structure of the preset event topology graph.

15. The method according to claim 10, characterized in that, The process of generating an event topology diagram of the associated component set based on the preset topology diagram includes: An event topology diagram of the associated component set is generated based on at least one of the hardware / software topology diagram, functional topology diagram, and extended data flow topology diagram in the preset topology diagram.

16. The method according to claim 15, characterized in that, The event topology diagram that generates the set of associated components based on at least one of the hardware / software topology diagram, functional topology diagram, and extended data flow topology diagram in the preset topology diagram includes: If there are no cross-domain components in the set of associated components, an event topology diagram of the set of associated components is generated based on the functional topology diagram and / or the extended data flow topology diagram. In the case where there are cross-domain components in the set of associated components, an event topology diagram of the set of associated components is generated based on the hardware and software topology diagram, the functional topology diagram, and the extended data flow topology diagram.

17. The method according to claim 16, characterized in that, The generation of the event topology diagram of the associated component set based on the hardware / software topology diagram, the functional topology diagram, and the extended data flow topology diagram includes: An initial event topology diagram of the associated component set is generated based on the hardware and software topology diagram; The initial event topology is expanded based on the functional topology to obtain an expanded event topology. The extended event topology graph is updated based on the extended data flow topology graph to obtain the event topology graph of the associated component set.

18. The method according to any one of claims 2 to 17, characterized in that, The method further includes: If the alarm event is a security event, a security analysis is performed on the alarm event.

19. The method according to claim 18, characterized in that, The security analysis of the alarm event includes: The target topology is obtained by tracing the event topology of the alarm event through an expanded data flow topology graph. The security analysis results of the alarm event are determined based on the event source node in the target topology.

20. The method according to claim 19, characterized in that, The security analysis result for determining the alarm event based on the event source node in the target topology includes: Based on the type of the event source node in the target topology, the security analysis result of the alarm event is determined.

21. The method according to claim 20, characterized in that, The determination of the security analysis result of the alarm event based on the type of the event source node in the target topology includes: If the event source nodes in the target topology include user operation type source nodes, the security analysis result of the alarm event is determined to indicate that there is a security risk. If the event source nodes in the target topology include source nodes that are not user-operated, the security analysis result of the alarm event is determined to indicate that there is a need for remediation.

22. The method according to claim 19, characterized in that, The method further includes: Based on preset operation characteristics and the behavioral characteristics of each event source node, the event source nodes are filtered to obtain target source nodes in the target topology that do not match the operation characteristics, so as to determine the security analysis result of the alarm event based on the target source nodes.

23. The method according to claim 19, characterized in that, The method further includes: If no event source node exists in the target topology, the target topology will be reported and / or a preset prompt message will be output to indicate that the alarm event cannot be analyzed.

24. The method according to claim 19, characterized in that, The step of tracing the event topology of the alarm event by extending the data flow topology to obtain the target topology includes: Extract the source information associated with each event node in the event topology graph from the extended data flow topology; The source tracing information is filtered based on the log information of the alarm event to obtain the target source tracing information; The event topology graph is processed based on the target tracing information until the target topology is obtained.

25. The method according to claim 24, characterized in that, Processing the event topology graph based on the target tracing information until the target topology is obtained includes: The event nodes in the event topology graph are replaced based on the source nodes in the target source information, and the edge information of the source nodes is generated in the event topology graph to obtain the updated event topology graph. The updated event topology graph is processed by expanding the data flow topology until the event topology graph can no longer be updated. Then, branches in the currently obtained event topology graph that do not contain event source nodes are removed to obtain the target topology.

26. The method according to claim 24, characterized in that, The log information of the alarm event includes logs within a preset interval time corresponding to the trigger time of the alarm event.

27. The method according to claim 18, characterized in that, The security analysis of the alarm event includes: Obtain the attack event set of the alarm event; Security analysis is performed on the alarm events based on the attack event set.

28. The method according to claim 27, characterized in that, The method further includes: The attack event set is filtered based on the log information of the alarm events to obtain the target attack events, and the alarm events are then analyzed based on the target attack events.

29. The method according to any one of claims 1 to 28, characterized in that, The method further includes: In response to an alarm event detected by the vehicle via a data packet.

30. The method according to claim 29, characterized in that, The packet detection includes at least one of deep packet detection and / or deep dynamic stream detection.

31. A controller, characterized in that, The controller is equipped with an event detection system and a security analysis system, and the controller is communicatively connected to the vehicle's domain controller. The event detection system is used to detect alarms for events reported by the domain controller of the vehicle, and after an alarm event is triggered, the security analysis system processes the detection information related to the vehicle alarm event and outputs the security verification result of the alarm event.

32. An electronic device, characterized in that, The device includes a processor; a memory for storing processor-executable instructions; wherein the processor is configured to perform the steps of the method for detecting security events as described in any one of claims 1-30.

33. A computer-readable storage medium, characterized in that, It stores a computer program, which is loaded by a processor to perform the steps of the security event detection method according to any one of claims 1-30.

34. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, causes the computer program product to perform the steps of the security event detection method as described in any one of claims 1-30.

35. A vehicle, characterized in that, Including the electronic device as described in claim 32.

Images