Intrusion detection method, device and system

Abstract

The invention discloses an intrusion detection method, device and system, and relates to the technical field of information security. The method can comprise the following steps: acquiring running logs of at least two service nodes, wherein the at least two service nodes are associated with a target service; and according to the operation logs of the at least two service nodes and a target detection rule, whether the intrusion event occurs is determined, and the target detection rule is used for describing a detection method of the intrusion event associated with the target service. The method is helpful for accurately detecting intrusion attacks for vehicle services.

Description

Intrusion detection method, device and system Technical Field

[0001] The present application relates to the field of information security technology, and in particular to an intrusion detection method, device and system. Background Art

[0002] With the development and advancement of technology, intelligent and connected vehicles have gradually become a key research focus in the automotive field. However, this intelligent and connected development has also made the application environment in the automotive field more specialized and management more difficult, and has also intensified the cybersecurity threats faced by intelligent and connected vehicles. Due to this high degree of connectivity, the electronic control units (ECUs) within vehicles, cloud servers, and applications (APPs) running on the owner's smart terminal that may be involved in vehicle services have all become potential targets for intrusion and attack.

[0003] Therefore, in order to ensure the security of vehicle services, how to accurately detect network security intrusions in vehicle services remains an important issue that needs to be addressed urgently.

[0004] Summary of the Invention

[0005] The present application provides an intrusion detection method, device, and system that help accurately detect intrusion attacks against vehicle services.

[0006] On the first aspect, an embodiment of the present application provides an intrusion detection method, which can be executed by a server. The server can be implemented as a communication device. The communication device can be an independent device, a chip or component in a device, or software. It can be deployed in the cloud, or a roadside device, or a remote server, or a local server, etc. The embodiment of the present application does not limit the product form and deployment method of the server.

[0007] The method may include: obtaining operation logs of at least two business nodes, the at least two business nodes being associated with a target business; determining whether the intrusion event has occurred based on the operation logs of the at least two business nodes and a target detection rule, the target detection rule being used to describe a detection method for an intrusion event associated with the target business.

[0008] With the above method, the at least two service nodes are nodes that jointly implement the target service. The server can analyze the operation logs of the at least two service nodes to detect whether an intrusion event has occurred. This method can perform comprehensive intrusion detection on service nodes involving multiple terminals or multiple systems from a business perspective, rather than being limited to a single service node or system, helping to improve the efficiency of intrusion event detection.

[0009] For example, the target service of the embodiments of the present application may be an Internet of Vehicles service (or vehicle service), including but not limited to: services related to vehicle over-the-air (OTA) upgrades, such as OTA content confirmation, downloading OTA upgrade packages, installing OTA upgrade packages, and activating OTA upgrade packages; vehicle Bluetooth key services; vehicle remote control services, etc. The service nodes used to implement the target service may include at least one of the following: a server, an application (APP) running on a smart terminal, an electronic control unit (ECU) inside a vehicle, etc. The embodiments of the present application do not limit the target service and the service nodes that implement the target service.

[0010] It is understandable that the intrusion detection method of the embodiment of the present application can also be expanded and applied to other fields, such as the Internet of Things (IOT) field which has similar characteristics to the Internet of Vehicles business. The businesses involved may include, but are not limited to, smart home businesses, and the business nodes may include at least one of the following: smart gateways, smart door locks, smart lamps, homeowner APPs and other terminal devices, which will not be repeated here.

[0011] It can be understood that in the embodiment of the present application, the operation log is only an example and not a limitation of the server's information integration of multiple terminals or multiple systems. In other embodiments, the operation log can be replaced with other information that can represent the business operation status, and the embodiment of the present application does not limit this.

[0012] In combination with the first aspect, in a possible design, the target detection rule includes a detection field for indicating the intrusion event and a rule for at least one detection condition, the detection field characterizing the characteristics of the potential intrusion attack behavior of the target business, and determining whether the intrusion event has occurred based on the operation logs of the at least two business nodes and the target detection rule, including: obtaining target data from the operation logs of the at least two business nodes according to the detection field indicated by the target detection rule; determining that no intrusion event has occurred when the operation log and the target data meet all detection conditions of the at least one detection condition; determining that an intrusion event has occurred when the operation log or the target data does not meet any detection condition of the at least one detection condition.

[0013] Through the above method, the server can parse the operation logs of at least two business nodes obtained through preset detection rules, and detect whether an intrusion event has occurred by matching the operation logs and the target data in the operation logs with the detection rules.

[0014] It is understood that in the embodiments of the present application, the specific content of the detection conditions may affect the determination of the detection results. For example, in some designs, contrary to the above description, based on the content of the detection conditions, it can also be set as follows: when the operation log and the target data meet all the detection conditions of the at least one detection condition, it is determined that an intrusion event has occurred; when the operation log or the target data does not meet any of the detection conditions of the at least one detection condition, it is determined that no intrusion event has occurred.

[0015] The detection methods for different intrusion events can be different. In some embodiments, for different intrusion events, it can also be set as follows: for some intrusion events, when the operation log and the target data meet all the detection conditions of the at least one detection condition, it is determined that no intrusion event has occurred; when the operation log or the target data does not meet any of the detection conditions of the at least one detection condition, it is determined that an intrusion event has occurred. For other intrusion events, when the operation log and the target data meet all the detection conditions of the at least one detection condition, it is determined that an intrusion event has occurred; when the operation log or the target data does not meet any of the detection conditions of the at least one detection condition, it is determined that no intrusion event has occurred.

[0016] That is to say, the detection of intrusion events needs to be adjusted according to the specific content of the detection rules and detection conditions, and the embodiments of the present application do not limit this.

[0017] In conjunction with the first aspect, in one possible design, the detection field of the intrusion event includes a timestamp, the target data includes a time value corresponding to the timestamp, and the at least one detection condition includes: a difference between time values ​​obtained from the operation logs of the at least two service nodes is less than or equal to a first threshold. Accordingly, when performing intrusion detection, the server can determine that an intrusion detection event has not occurred if the difference between the obtained time values ​​meets the detection condition; and determine that an intrusion detection event has occurred if the difference between the obtained time values ​​does not meet the detection condition.

[0018] Through the above method, the detection field of the intrusion event can include a timestamp. When performing intrusion detection, the server can compare the timestamp information extracted from the operation logs obtained from at least two business nodes. If the difference between the two comparisons is large, it indicates that a business node may have been intruded.

[0019] It will be appreciated that in embodiments of the present application, when the detection field includes a timestamp, the at least one detection condition described above can be replaced by: the difference between the time values ​​obtained from the operation logs of the at least two service nodes is greater than or equal to a second threshold. The second threshold can be greater than or equal to the first threshold. Accordingly, when performing intrusion detection, the server can determine that an intrusion detection event has occurred if the difference between the obtained time values ​​meets the detection condition; and determine that no intrusion detection event has occurred if the difference between the obtained time values ​​does not meet the detection condition.

[0020] In conjunction with the first aspect, in one possible design, the detection field of the intrusion event includes a uniform resource locator (URL), the target data includes URL data, and the at least one detection condition includes: the content of the URL data obtained from the operation logs of the at least two service nodes is identical. Accordingly, when performing intrusion detection, the server can determine that no intrusion detection event has occurred if the obtained URL data meets the detection condition; and determine that an intrusion detection event has occurred if the obtained URL data does not meet the detection condition.

[0021] It is understood that in this embodiment of the present application, when the detection field includes a URL, the at least one detection condition described above can be replaced by: the content of the URL data obtained from the operation logs of the at least two service nodes is different. Accordingly, when performing intrusion detection, the server can determine that an intrusion detection event has occurred if the obtained URL data meets the detection condition; and determine that no intrusion detection event has occurred if the obtained URL data does not meet the detection condition.

[0022] In conjunction with the first aspect, in one possible design, the detection field of the intrusion event includes an operation identifier, the operation identifier is associated with executing an operation included in the target business, the target data includes data corresponding to the operation identifier, and the at least one detection condition includes: the content of the data corresponding to the operation identifier obtained from the operation logs of the at least two business nodes is identical. When performing intrusion detection, the server can determine that no intrusion detection event has occurred if the data corresponding to the obtained operation identifier meets the detection condition; and determine that an intrusion detection event has occurred if the data corresponding to the obtained operation identifier does not meet the detection condition.

[0023] It is understood that in this embodiment of the present application, when the detection field includes an operation identifier, the at least one detection condition described above can be replaced by: the data corresponding to the operation identifier obtained from the operation logs of the at least two service nodes is different in content. Accordingly, when performing intrusion detection, the server can determine that no intrusion detection event has occurred if the data corresponding to the obtained operation identifier meets the detection condition; and determine that an intrusion detection event has occurred if the data corresponding to the obtained operation identifier does not meet the detection condition.

[0024] In combination with the first aspect, in a possible design, the method also includes: obtaining the target detection rule from the detection rule set based on the operation log, wherein the detection rule set includes alternative detection rules pre-configured for multiple potential intrusion attack behaviors of the target business, and the alternative detection rules are used to describe the detection method of the intrusion event corresponding to the potential intrusion attack behavior.

[0025] Through the above method, the server can preset a detection rule set and use the target detection rules in the detection rule set to parse the obtained operation log to determine whether an intrusion event occurs.

[0026] It can be understood that in an embodiment of the present application, the detection rule set can be pre-written based on known and limited intrusion attack methods, and the detection rule set can be stored on the server in the form of program code. The embodiment of the present application does not limit the implementation method of the detection rule set and any alternative detection rules.

[0027] In combination with the first aspect, in one possible design, the target detection rule includes all alternative detection rules in the detection rule set; or, the target detection rule includes the alternative detection rule in the detection rule set that is associated with the target service.

[0028] In conjunction with the first aspect, in one possible design, the method further includes: receiving configuration information, wherein the configuration information is used to modify the alternative detection rule in the detection rule set, and / or the configuration information is used to add an alternative detection rule to the detection rule set. It is understood that in the embodiments of the present application, "modification" may include modifying the content of the alternative detection rule or deleting the alternative detection rule.

[0029] In conjunction with the first aspect, in a possible design, the method further includes: outputting the detection result of the intrusion event. In an optional implementation, the detection result of the intrusion event may be output on an output device associated with the server.

[0030] In conjunction with the first aspect, in one possible design, the intrusion event detection result includes at least one of the following information about the intrusion event: event identifier, event name, threat level, detection time, potential risk, intrusion attack target, intrusion detection process, or intrusion detection context information. For example, the detection result can be output in at least one of the following presentation formats: text, image, or line.

[0031] In combination with the first aspect, in one possible design, the target business includes a vehicle business, and the at least two business nodes include: the server, the target vehicle, or a user device of a user who manages the target vehicle. It should be noted that the vehicle business described here is a general term for Internet of Vehicles business, which may include but is not limited to: services related to vehicle OTA upgrades, such as OTA content confirmation, downloading OTA upgrade packages, installing OTA upgrade packages, activating OTA upgrade packages; vehicle Bluetooth key services; vehicle remote control services, etc. The business nodes used to implement the target business may include at least one of the following: a server, an application (APP) running on an intelligent terminal, an electronic control unit (ECU) inside a vehicle, etc. The embodiment of the present application does not limit the target business and the business nodes that implement the target business.

[0032] Secondly, embodiments of the present application further provide an intrusion detection method, which can be implemented by a human-machine interaction interface (HMI) (or server front-end). This HMI, for example, can be the HMI of an electronic device associated with the server, and can be used to output information from the server. The information content can be presented in the form of, but not limited to, images, text, lines, etc. In an optional embodiment, the HMI can also have or be associated with an input device, and can receive information from a front-end user (e.g., a security expert) through the input device, although this embodiment of the present application is not limited to this.

[0033] The method may include: receiving an intrusion detection result of a target intrusion event, wherein the intrusion detection result is used to indicate at least one of the following information of the target intrusion event: event identifier, event name, threat level, detection time, potential risk, intrusion attack object, intrusion detection process or intrusion detection context information; and outputting the intrusion detection result of the target intrusion event.

[0034] Through the above method, the HMI can output and display the intrusion detection results of the target intrusion event, which helps the front-end user to view the intrusion detection results and use the relevant context information to confirm, trace and respond to the target intrusion event.

[0035] In combination with the second aspect, in one possible design, the method may further include: receiving second indication information input in response to the intrusion detection result, wherein the second indication information is used to confirm the intrusion event, or the second indication information is used to indicate a method for handling the intrusion event.

[0036] Through the above method, the HMI can receive the second indication information through the input device. The second indication information can be sent by the front-end user and can be used to confirm, trace and respond to the target intrusion event.

[0037] In combination with the second aspect, in a possible design, the method also includes: outputting a first interface, the first interface being used to present statistical results of intrusion events from at least one dimension; receiving control information input on the first interface, the control information being used to instruct the output of intrusion detection results of the target intrusion event.

[0038] Through the above method, the HMI can present the statistical results of intrusion events from at least one dimension, and the front-end user can input control information to the HMI according to his or her own needs, thereby triggering the presentation of intrusion detection results for the target intrusion event.

[0039] In a third aspect, an embodiment of the present application provides a communication device, which can be deployed on a server, for example. The communication device may include: an acquisition unit, used to acquire the operation logs of at least two business nodes, and the at least two business nodes are associated with the target business; a determination unit, used to determine whether the intrusion event occurs based on the operation logs of the at least two business nodes and the target detection rules, and the target detection rules are used to describe the detection method of the intrusion event associated with the target business.

[0040] In combination with the third aspect, in a possible design, the target detection rule includes a detection field for indicating the intrusion event and a rule for at least one detection condition, the detection field characterizing the characteristics of the potential intrusion attack behavior of the target business, and the determination unit is used to: obtain target data from the operation logs of the at least two business nodes according to the detection field indicated by the target detection rule; determine that no intrusion event has occurred when the operation log and the target data meet all detection conditions of the at least one detection condition; determine that an intrusion event has occurred when the operation log or the target data does not meet any detection condition of the at least one detection condition.

[0041] In combination with the third aspect, in one possible design, the detection field of the intrusion event includes a timestamp, the target data includes a time value corresponding to the timestamp, and the at least one detection condition includes: the difference between the time values ​​obtained from the operation logs of the at least two business nodes is less than or equal to a first threshold.

[0042] In combination with the third aspect, in one possible design, the detection field of the intrusion event includes a uniform resource locator URL, the target data includes URL data, and the at least one detection condition includes: the content of the URL data obtained from the operation logs of the at least two business nodes is the same.

[0043] In combination with the third aspect, in one possible design, the detection field of the intrusion event includes an operation identifier, the operation identifier is associated with executing the operation included in the target business, the target data includes data corresponding to the operation identifier, and the at least one detection condition includes: the content of the data corresponding to the operation identifier obtained from the operation logs of the at least two business nodes is the same.

[0044] In combination with the third aspect, in a possible design, the acquisition unit is also used to: obtain the target detection rule from the detection rule set based on the operation log, wherein the detection rule set includes alternative detection rules pre-configured for multiple potential intrusion attack behaviors of the target business, and the alternative detection rules are used to describe the detection method of the intrusion event corresponding to the potential intrusion attack behavior.

[0045] In combination with the third aspect, in one possible design, the target detection rule includes all alternative detection rules in the detection rule set; or, the target detection rule includes the alternative detection rule in the detection rule set that is associated with the target business.

[0046] In combination with the third aspect, in one possible design, the communication device also includes a transceiver unit for receiving configuration information, wherein the configuration information is used to modify the alternative detection rules in the detection rule set, and / or the configuration information is used to add new alternative detection rules in the detection rule set.

[0047] In combination with the third aspect, in a possible design, the communication apparatus further includes an output unit configured to output the detection result of the intrusion event on an output device associated with the server.

[0048] In combination with the third aspect, in one possible design, the detection result of the intrusion event includes at least one of the following information of the intrusion event: event identifier, event name, threat level, detection time, potential risk, intrusion attack object, intrusion detection process or intrusion detection context information.

[0049] In combination with the third aspect, in one possible design, the target service includes a vehicle service, and the at least two service nodes include: the server, the target vehicle, or a user device of a user who manages the target vehicle.

[0050] In a fourth aspect, an embodiment of the present application provides a human-computer interaction interface HMI, comprising: a communication unit for receiving an intrusion detection result of a target intrusion event, wherein the intrusion detection result is used to indicate at least one of the following information of the target intrusion event: event identifier, event name, threat level, detection time, potential risk, intrusion attack object, intrusion detection process or intrusion detection context information; an output unit for outputting the intrusion detection result of the target intrusion event.

[0051] In combination with the fourth aspect, in one possible design, the communication unit is also used to receive second indication information input in response to the intrusion detection result, wherein the second indication information is used to confirm the intrusion event, or the second indication information is used to indicate a method for handling the intrusion event.

[0052] In combination with the fourth aspect, in one possible design, the output unit is also used to output a first interface, which is used to present statistical results of intrusion events from at least one dimension; the communication unit is also used to receive control information input on the first interface, and the control information is used to indicate the output of the intrusion detection results of the target intrusion event.

[0053] In a fifth aspect, an embodiment of the present application provides a communication device, comprising: a communication interface for communicating with other devices; a processor coupled to the communication interface, so that the communication device executes the method described in the above-mentioned first aspect and any possible design of the first aspect, or executes the method described in the above-mentioned second aspect and any possible design of the second aspect.

[0054] In a sixth aspect, an embodiment of the present application provides a communication system, including a server, wherein the server is used to implement the method described in the first aspect and any possible design of the first aspect.

[0055] In combination with the sixth aspect, in a possible design, the communication system further includes a human-machine interface HMI, and the HMI is used to implement the method described in the above-mentioned second aspect and any possible design of the second aspect.

[0056] In the seventh aspect, an embodiment of the present application provides a chip system comprising at least one processor and an interface circuit, wherein the processor is used to execute the interaction of instructions and / or data through the interface circuit, so that the chip system executes the method described in the above-mentioned first aspect and any possible design of the first aspect, or executes the method described in the above-mentioned second aspect and any possible design of the second aspect.

[0057] In an eighth aspect, an embodiment of the present application provides a computer-readable storage medium comprising a program or instruction. When the program or instruction is executed, the method described in the first aspect and any possible design of the first aspect is executed, or the method described in the second aspect and any possible design of the second aspect is executed.

[0058] In the ninth aspect, an embodiment of the present application provides a computer program product. When a computer reads and executes the computer program product, the computer executes the method described in the first aspect and any possible design of the first aspect, or executes the method described in the second aspect and any possible design of the second aspect.

[0059] In the tenth aspect, an embodiment of the present application provides a chip, including a processor, which is coupled to a memory and is used to execute a computer program or instruction stored in the memory. When the computer program or instruction is executed, it implements the method described in the above-mentioned first aspect or any possible design of the first aspect, or executes the above-mentioned second aspect and any possible design of the second aspect.

[0060] Based on the implementations provided in the above aspects, the embodiments of the present application can be further combined to provide more implementations.

[0061] The technical effects that can be achieved by any possible implementation method in any of the third to tenth aspects mentioned above can be referred to the description of the technical effects that can be achieved by any possible implementation method in any of the first aspect mentioned above, and the repetitions will not be discussed. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] FIG1 is a schematic diagram showing an application scenario to which an embodiment of the present application is applicable;

[0063] FIG2 is a schematic diagram showing a system architecture applicable to an embodiment of the present application;

[0064] FIG3 shows a schematic flow chart of an intrusion detection method according to an embodiment of the present application;

[0065] FIG4 is a schematic diagram showing a system architecture applicable to an embodiment of the present application;

[0066] FIG5 is a schematic diagram showing the log collection principle of an embodiment of the present application;

[0067] FIG6 is a schematic diagram showing the principle of generating a detection rule set according to an embodiment of the present application;

[0068] FIG7 shows a schematic diagram of a first interface according to an embodiment of the present application;

[0069] FIG8 shows a schematic diagram of a second interface according to an embodiment of the present application;

[0070] FIG9 is a schematic diagram showing a flow chart of an intrusion detection method in an OTA scenario according to an embodiment of the present application;

[0071] FIG10 shows a schematic diagram of an attack on a Bluetooth key scenario according to an embodiment of the present application;

[0072] FIG11 is a schematic diagram showing a flow chart of an intrusion detection method in a Bluetooth key scenario according to an embodiment of the present application;

[0073] FIG12 shows a schematic structural diagram of a communication device according to an embodiment of the present application;

[0074] FIG13 shows a schematic structural diagram of a human-computer interaction interface according to an embodiment of the present application;

[0075] FIG14 shows a schematic structural diagram of a communication device according to an embodiment of the present application. DETAILED DESCRIPTION

[0076] In order to facilitate understanding of the technical solutions of the embodiments of the present application, some of the terms involved are explained below.

[0077] 1. User:

[0078] The "user" mentioned in the embodiments of this application is the person who uses the vehicle. This user can include the vehicle owner, or other persons authorized by the vehicle owner to use the vehicle, such as the vehicle owner's relatives or friends. It should be understood that for autonomous vehicles, the user can be a virtual user or a real person who manages the vehicle, and this embodiment of the application does not limit this.

[0079] 2. User device:

[0080] Generally refers to an electronic device used by a user, such as an onboard terminal in a vehicle used by the user or a user's smart terminal, such as a mobile phone or tablet computer. For unmanned vehicles, a user device can be the vehicle's onboard terminal; it can also be a mobile terminal placed on the vehicle, such as a mobile phone or tablet computer; it can also be other electronic devices associated with the vehicle, such as electronic devices operated by vehicle management personnel, including but not limited to desktop computers, laptops, mobile phones, tablet computers, etc.; the embodiments of this application do not limit the product form of the user device.

[0081] 3. Business nodes:

[0082] Generally refers to the communication node used to implement business.

[0083] For example, a service may include an Internet of Vehicles service (or vehicle service). Service nodes may include, but are not limited to, at least one of the following: a server, a user's smart terminal, an application (APP) running on the user's smart terminal, an electronic control unit (ECU) within a vehicle, etc. The embodiments of this application do not limit the product form or deployment method of the service or the service nodes that implement the service.

[0084] 4. Operation log:

[0085] Network devices, systems, and service programs all generate a record of events during operation, known as a log. This log is an ordered collection of events, including the operations and their results. Logs are collected and recorded in log files and can contain multiple log lines. Each line can include a description of the relevant operation, including the date, time, performer, and action.

[0086] In the embodiment of the present application, the operation log is used to perform intrusion detection from a security perspective, so the operation log can also be called a security log.

[0087] 5. Intrusion incidents (also known as attack incidents):

[0088] An information security incident refers to an attack or intrusion into an information system through network or other technical means, which exploits configuration defects, protocol defects, program defects of the information system or uses brute force attacks, causing information system anomalies or potential harm to the current operation of the information system.

[0089] In the embodiments of the present application, intrusion events are associated with businesses. In the process of implementing a business, any point may be attacked. Therefore, the relationship between a business and an intrusion event can be one-to-many, that is, one business can involve multiple intrusion events. Similarly, the same intrusion event may occur in different businesses. Therefore, the relationship between a business and an intrusion event can also be many-to-one, that is, one intrusion event can involve multiple businesses. In some embodiments, a business can also be divided into multiple sub-businesses, and each sub-business can also involve multiple intrusion events. The embodiments of the present application do not limit the corresponding relationship between businesses and intrusion events.

[0090] 6. Detection rules:

[0091] Detection rules are used to describe the detection method for business-related intrusion events. Generally, one detection rule corresponds to one intrusion event.

[0092] In the embodiment of the present application, the server may include multiple intrusion event detection rules, which are aggregated into a detection rule set. Each detection rule may be configured on the server in the form of program code or other forms. The embodiment of the present application does not limit the implementation method of the detection rule.

[0093] For the sake of distinction, each detection rule to be used in the detection rule set may be referred to as a candidate detection rule, and the detection rule used to parse the operation log may be referred to as a target detection rule.

[0094] 7. Detection fields:

[0095] The detection field is used to characterize the characteristics of potential intrusion attack behaviors of a service. For example, the detection field may include at least one of the following: a timestamp, a URL, and an operation identifier.

[0096] The embodiments of the present application provide an intrusion detection method, device, and system. A server can detect whether an intrusion event has occurred by parsing the operation logs of at least two business nodes. This method can perform comprehensive intrusion detection on business nodes involving multiple terminals or multiple systems from a business perspective, rather than being limited to a single business node or system, thereby helping to improve the detection efficiency of intrusion events. The method and device are based on the same technical concept. Since the principles of solving problems in the method and device are similar, the implementation of the device and method can refer to each other, and the repeated parts will not be repeated.

[0097] It should be noted that the intrusion detection method in the embodiment of the present application can be applied to the Internet of Vehicles, such as vehicle to everything (V2X), long term evolution-vehicle (LTE-V), vehicle to vehicle (V2V), etc. For example, it can be applied to a vehicle with a driving mobile function, or other devices in a vehicle with a driving mobile function. The other devices include but are not limited to: other sensors such as an on-board terminal, an on-board controller, an on-board module, an on-board module, an on-board component, an on-board chip, an on-board unit, an on-board radar or an on-board camera. The vehicle can implement the method provided in the embodiment of the present application through the on-board terminal, on-board controller, on-board module, on-board module, on-board component, on-board chip, on-board unit, on-board radar or on-board camera. Of course, the control scheme in the embodiment of the present application can also be used in other smart terminals with mobile control functions other than vehicles, or be set in other smart terminals with mobile control functions other than vehicles, or be set in a component of the smart terminal. The smart terminal can be an intelligent transportation device, a smart home device, a robot, etc. For example, it includes but is not limited to smart terminals or controllers, chips, radars, cameras and other sensors, and other components within smart terminals.

[0098] It should be noted that, in the embodiments of the present application, "at least one" refers to one or more, and "more" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, c can be single or multiple.

[0099] Furthermore, unless otherwise specified, ordinal numbers such as "first" and "second" in the embodiments of this application are used to distinguish between multiple objects and are not used to define the priority or importance of multiple objects. For example, the first user information and the second user information are only used to distinguish user information obtained at different times or by different methods, and do not indicate differences in the content, priority, or importance of the two user information.

[0100] For ease of understanding, the following is an introduction with reference to the accompanying drawings and embodiments.

[0101] Figure 1 shows a schematic diagram of an application scenario applicable to an embodiment of the present application. In this application scenario, a server 200 and at least one user equipment (UE) 100 (e.g., user equipment 100_1, user equipment 100_2, etc.) may be included. The server 200 and the at least one user equipment 100 may communicate via a network. In one embodiment, the server 200 may also be implemented as a virtual machine.

[0102] For example, the at least one user device 100 may include a vehicle. As shown in FIG2 , some or all functions of the vehicle are controlled by an in-vehicle terminal 150. The in-vehicle terminal 150 may include at least one processor 151, which may execute instructions 153 stored in a non-transitory computer-readable medium such as a memory 152. In some embodiments, the in-vehicle terminal 150 may also be a plurality of computing devices that control individual components or subsystems of the vehicle in a distributed manner.

[0103] The processor 151 may be any conventional processor, such as a central processing unit (CPU). Alternatively, the processor 151 may include a graphics processing unit (GPU), a field programmable gate array (FPGA), a system on chip (SOC), an application specific integrated circuit (ASIC), or a combination thereof.

[0104] In addition to the instructions 153, the memory 152 may also store data such as road maps, route information, the vehicle's location, direction, speed, and other vehicle data, operation logs of the vehicle's various ECUs, and other information. This information can be used by the vehicle and the onboard terminal 150 during operation in autonomous, semi-autonomous, and / or manual modes. It should be understood that the structure of the vehicle in FIG. 2 should not be construed as limiting the embodiments of the present application.

[0105] In an optional implementation, the above-mentioned vehicle can be a car, truck, motorcycle, bus, ship, airplane, helicopter, lawn mower, recreational vehicle, amusement park vehicle, construction equipment, tram, golf cart, train, etc., and the embodiments of the present application do not make special limitations.

[0106] It should be noted that the vehicle-mounted terminal 150 shown in Figure 2 is only an example of a device on the vehicle side for implementing the computing function on the vehicle side and is not a limitation. The computing function can be implemented by an independent device on at least one user device 100, or by the processor 151. The embodiments of the present application do not limit this.

[0107] FIG3 shows a flow chart of an intrusion detection method according to an embodiment of the present application. The method may be implemented collaboratively by the server shown in FIG1 or FIG2 and at least one user device (e.g., a vehicle). As shown in FIG3 , the method may include the following steps:

[0108] S310: The server obtains operation logs of at least two service nodes.

[0109] In the embodiment of the present application, the at least two service nodes are communication nodes associated with the target service. An operation log is a record of information generated and collected by a service node during the implementation of the target service, describing the operations related to the service. The log content may include, but is not limited to, the operation identifier, the date or time the operation occurred, and other information associated with the operation.

[0110] For example, the target business may include vehicle business, and the at least two business nodes include: the server, the target vehicle, or the user equipment of the user who manages the target vehicle. It should be noted that the vehicle business described here is a general term for Internet of Vehicles business, which may include but is not limited to: vehicle OTA upgrade-related business, such as OTA content confirmation, downloading OTA upgrade package, installing OTA upgrade package, activating OTA upgrade package; vehicle Bluetooth key business; vehicle remote control business, etc. The business nodes used to implement the target business may include at least one of the following: a server, an APP running on an intelligent terminal, an ECU inside a vehicle, etc. The embodiments of the present application do not limit the target business and the business nodes that implement the target business.

[0111] The server can communicate and interact with the business node directly or indirectly. When implementing S310, the server can obtain the operation log from the at least two business nodes in real time or periodically. The operation log can be obtained by the business node actively reporting the operation log, or by the business node receiving a request from the server and reporting the operation log requested by the server to the server. Alternatively, the operation log can also be obtained by the server receiving and saving the operation log from at least two business nodes in real time or periodically, and obtaining the operation log of the corresponding business node locally when necessary. The embodiment of the present application does not limit the method for obtaining the operation log.

[0112] When the at least two business nodes send operation logs to the server, the operation logs from the business nodes can be carried in the communication messages from the business nodes in the form of log files. The log files can, for example, completely record all log contents recorded by the business nodes from the previous reporting time to the current reporting time (the time interval can, for example, be called a reporting period, which can be a constant time interval or an unequal time interval), or report part of the recorded log content according to pre-configuration or negotiation. The embodiment of the present application does not limit the transmission method and content of the operation log.

[0113] S320: The server determines whether the intrusion event occurs according to the operation logs of the at least two service nodes and the target detection rule.

[0114] In an embodiment of the present application, the target detection rule can be used to describe a method for detecting an intrusion event associated with the target business. When implementing S320, the server can use the target detection rule to parse the operation logs of the at least two business nodes to detect whether an intrusion event occurs.

[0115] As an optional implementation, before implementing S320, the server may obtain the target detection rule from the detection rule set based on the operation log. The detection rule set may include alternative detection rules pre-configured for a variety of potential intrusion attack behaviors of different businesses, and the alternative detection rules are used to describe the detection method of the intrusion event corresponding to the potential intrusion attack behavior. Among them, the server can communicate and interact with the user equipment controlled by the administrator and receive configuration information, and the configuration information can be used to modify the alternative detection rules in the detection rule set, and / or, the configuration information can be used to add alternative detection rules to the detection rule set. Each alternative detection rule can be stored in the server in the form of program code, or can be stored in the server in the form of other information, and this embodiment of the application does not limit this.

[0116] Generally, an alternative detection rule may correspond to an intrusion event, and the alternative detection rule may include a detection field for indicating the intrusion event and a rule of at least one detection condition. The detection field may characterize the characteristics of potential intrusion attack behavior of the service, including but not limited to a timestamp, a uniform resource locator (URL), or an operation identifier. The at least one detection condition may instruct the server to obtain target data from the operation log to be parsed based on the detection field of the intrusion event, and determine whether an intrusion event has occurred based on whether the operation log and the target data meet the at least one detection condition.

[0117] For example, the target detection rule includes all candidate detection rules in the detection rule set; or the target detection rule may include the candidate detection rules in the detection rule set that are associated with the target business. The target detection rule may include a detection field for indicating an intrusion event and a rule for at least one detection condition, wherein the detection field of the target detection rule characterizes the characteristics of potential intrusion attack behavior of the target business.

[0118] When implementing S320, the server can obtain target data from the operation logs of at least two business nodes based on the detection field indicated by the target detection rule. The server can determine whether an intrusion event occurs based on whether the operation logs and the target data meet at least one detection condition.

[0119] For example, based on the content of the detection condition, the server may determine that no intrusion event has occurred when the operation log and target data meet all detection conditions of the at least one detection condition; and determine that an intrusion event has occurred when the operation log and target data do not meet any detection condition of the at least one detection condition. Alternatively, for example, based on the content of the detection condition, the server may determine that an intrusion event has occurred when the operation log and target data meet all detection conditions of the at least one detection condition; and determine that no intrusion event has occurred when the operation log and target data do not meet any detection condition of the at least one detection condition.

[0120] Taking the case where the detection field of the intrusion event indicated by the target detection rule includes a timestamp as an example, the target data may include the time value corresponding to the timestamp. If the detection condition indicated by the target detection rule includes: the difference in time values ​​obtained from the operation logs of at least two business nodes is less than or equal to a first threshold. Then, when the server uses the target detection rule to parse the operation log, when the difference in time values ​​obtained from the operation logs of at least two business nodes is less than or equal to the first threshold, the detection condition is met and it is determined that no intrusion event has occurred; or, when the difference in time values ​​obtained from the operation logs of at least two business nodes is greater than the first threshold, the detection condition is not met and it is determined that an intrusion event has occurred. If the detection condition indicated by the target detection rule includes: the difference in time values ​​obtained from the operation logs of at least two business nodes is greater than or equal to a second threshold, the second threshold is greater than or equal to the first threshold. Then, when the server uses the target detection rule to parse the operation log, when the difference between the time values ​​obtained from the operation logs of at least two business nodes is greater than or equal to the second threshold, the detection condition is met and it is determined that an intrusion event has occurred; or, when the difference between the time values ​​obtained from at least two operation logs is less than the second threshold, the detection condition is not met and it is determined that no intrusion event has occurred.

[0121] Similarly, taking the example of a target detection rule indicating that the detection field of an intrusion event includes a URL, the target data may include URL data. If the detection condition indicated by the target detection rule includes: the content of the URL data obtained from the operation logs of the at least two service nodes is identical, then when the server parses the operation logs using the target detection rule, if the content of the URL data obtained from the operation logs of the at least two service nodes is identical, then the detection condition is satisfied, and it is determined that no intrusion event has occurred; or if the content of the URL data obtained from the at least two service nodes is different, then the detection condition is not satisfied, and it is determined that an intrusion event has occurred. If the detection condition indicated by the target detection rule includes: the content of the URL data obtained from the operation logs of the at least two service nodes is different, then when the server parses the operation logs using the target detection rule, if the content of the URL data obtained from the operation logs of the at least two service nodes is different, then the detection condition is satisfied, and it is determined that an intrusion event has occurred; or if the content of the URL data obtained from the operation logs of the at least two service nodes is identical, then the detection condition is not satisfied, and it is determined that no intrusion event has occurred.

[0122] Similarly, taking the case where the detection field of the intrusion event indicated by the target detection rule includes an operation identifier, the operation identifier can be associated with the operation included in the target business, and the target data can include the data corresponding to the operation identifier. If the detection condition indicated by the target detection rule includes: the content of the data corresponding to the operation identifier obtained from the operation logs of at least two business nodes is the same. Then, when the server uses the target detection rule to parse the operation log, if the content of the data corresponding to the operation identifier obtained from the operation logs of at least two business nodes is the same, the detection condition is met, and it is determined that no intrusion event has occurred; or, if the content of the data corresponding to the operation identifier obtained from at least two business nodes is different, the detection condition is not met, and it is determined that an intrusion event has occurred. If the detection condition indicated by the target detection rule includes: the content of the data corresponding to the operation identifier obtained from the operation logs of the at least two business nodes is different. Then, when the server uses the target detection rule to parse the operation log, when the content of the data corresponding to the operation identifier obtained from the operation logs of at least two business nodes is different, the detection condition is met and it is determined that an intrusion event has occurred; or, when the content of the data corresponding to the operation identifier obtained from the operation logs of at least two business nodes is the same, the detection condition is not met and it is determined that no intrusion event has occurred.

[0123] It should be noted that the above is only an example description of the detection fields and detection conditions indicated by the target detection rules. In specific embodiments, the content of the detection fields specifically indicated by the target detection rules is not limited, nor is the content and quantity of the detection conditions indicated by the target detection rules limited. They will not be repeated here.

[0124] In an optional embodiment, the server can also output the detection results of the intrusion event. For example, the server can be associated with an output device, and the server can output the detection results of the intrusion event through the output device. The detection results may include, for example, at least one of the following information about the intrusion event: event identifier, event name, threat level, detection time, potential risk, intrusion attack target, intrusion detection process, or intrusion detection context information. The front-end user can view relevant information about the intrusion event through the display interface of the output device. If necessary, the front-end user can use the presented information to confirm the intrusion event, trace the attack source, and so on.

[0125] For ease of understanding, the specific implementation details of the embodiments of the present application are introduced below using the application in the Internet of Vehicles scenario as an example.

[0126] Figure 4 shows a schematic diagram of the system architecture of an embodiment of the present application in a connected vehicle scenario. Taking the example of the user device in Figure 1 including the vehicle in Figure 2 or the user's smart terminal, as shown in Figure 4 , in this scenario, server 410 can communicate and interact with vehicle 450 and the user's smart terminal 430 via a wireless network to implement the intrusion detection method of the embodiment of the present application.

[0127] The following is an introduction to the various functional modules involved in the system.

[0128] 1. Vehicle 450:

[0129] The vehicle 450 may include, for example, a plurality of ECUs, such as a network communication device 451, an OTA control unit 452, a human-machine interface HMI 453, a cockpit domain controller 454, a vehicle sensor system 455 or an autonomous driving domain controller 456, and an in-vehicle communication network (such as a CAN bus, etc.) for realizing internal communication within the vehicle. The network communication device 451 may serve as a communication bridge between external devices such as a server 410 and an intelligent terminal 430 and the internal ECU of the vehicle 450, realizing capabilities such as receiving, sending or forwarding operation logs. Inside the vehicle 450, the network communication device 451 may, for example, realize information transmission with various ECUs of the vehicle 450 through an in-vehicle communication network. In an embodiment of the present application, the network communication device 451 may support wireless communication or wired communication, which is not limited in the embodiment of the present application.

[0130] Each ECU can serve as a business node and can record and save operation logs during operation.

[0131] For example, the OTA control unit 452 can serve as a unit module for implementing OTA upgrade control inside the vehicle 450, and can perform operations related to the OTA upgrade service. For example, the OTA control unit 452 can receive OTA content, OTA upgrade packages, etc. from the server 410 through the network communication device 451. Alternatively, the OTA control unit 452 can also install the OTA upgrade package and activate the OTA upgrade package. Alternatively, the OTA control unit 452 can feed back the operation results to the server 410 through the network communication device 451. In the process of the OTA control unit 452 running and implementing the corresponding service, the OTA control unit 452 can synchronously record and save the operation log. The operation log may, for example, include information describing the execution details of the relevant operations of the OTA upgrade service, such as the execution date, execution time, executor, operation identifier, operation content, and other related information.

[0132] For example, HMI 453 is an input / output device within vehicle 450. HMI 453 can communicate with network communication device 451, OTA control unit 452, cockpit domain controller 454, vehicle sensor system 455, or autonomous driving domain controller 456 via an in-vehicle communication network. HMI 453 can provide an operation interface for outputting information from network communication device 451, OTA control unit 452, cockpit domain controller 454, vehicle sensor system 455, or autonomous driving domain controller 456, or for receiving information input by a user through HMI 453, or for transmitting received input information to a corresponding ECU or server. During the operation of HMI 453 and the implementation of corresponding services, HMI 453 can simultaneously record and save an operation log. This operation log can, for example, include the content, date, time, operation identifier, and other associated information of the output information, or the content, date, time, operation identifier, and other associated information of the input information.

[0133] For example, the cockpit domain controller 454 can obtain sufficient sensory data through an independent perception layer, such as in-vehicle visual (optical) and audio (acoustic) data, as well as chassis and body data such as the steering wheel, brake pedal, accelerator pedal, gear position, and seatbelts. Using biometric recognition technology (primarily facial and voice recognition within the cabin), it comprehensively determines the driver's (or other passengers') physiological state (such as portrait and facial recognition) and behavioral state (driving behavior, voice, and body movements), and then pushes interaction requests based on specific scenarios. In-vehicle interaction methods have been upgraded from solely "physical button interaction" to a state where "touchscreen interaction," "voice interaction," and "gesture interaction" coexist. While running and implementing corresponding services, the cockpit domain controller 454 can simultaneously record and save an operation log. This operation log can, for example, include the date, time, operation identifier, operation content, and other related information when various sensory data was acquired, or it can include the content, date, time, operation identifier, and other related information of the interaction request pushed in a specific scenario.

[0134] For example, the vehicle sensing system 455 may include sensors such as cameras, radars, thermometers, and hygrometers. The vehicle sensing system 455 may obtain perception results of the vehicle's interior or exterior environments and provide these perception results to the cockpit domain controller 454 or other ECUs that require this information, such as the autonomous driving domain controller 456. Similarly, the vehicle sensing system 455 may record operational logs for each sensor device, such as the content of the perception information, the date and time of generation, operation identifiers, and other associated information.

[0135] For example, autonomous driving domain controller 456 can make autonomous driving decisions and implement autonomous driving controls based on the various perception results it collects, such as adaptive cruise control, automatic emergency braking, lane keeping assist, lane departure warning, and parking assist. While operating and implementing corresponding services, autonomous driving domain controller 456 can simultaneously record and save an operation log. This operation log can include the operation identifier, content, date, time, or other relevant information related to different autonomous driving function operations.

[0136] When necessary, each of the above vehicle ECUs may report the saved operation logs to the server 410 , and the server 410 may parse the collected operation logs from at least two service nodes to determine whether an intrusion event occurs.

[0137] It should be noted that, in the embodiment of the present application, each ECU shown in FIG4 can serve as a service node of the Internet of Vehicles business and provide its own operation log to the server 410. The contents of the operation logs generated by different ECUs in the process of implementing their respective services may be different, and the embodiment of the present application does not limit the contents of the operation logs. In another optional embodiment, a data collection module can also be integrated into the network communication device 451, and the data collection module can obtain the required operation logs from each ECU of the vehicle 450 and report them to the server. In order to reduce the impact on the Internet of Vehicles business implemented by the server 410, an optional implementation method is that the operation log transmission channel between the server 410 and the vehicle 450 can be an independent channel, independent of the business transmission channel between the server 410 and the vehicle 450. The embodiment of the present application does not limit the operation log transmission method between the server 410 and the vehicle 450.

[0138] It should be understood that Figure 4 is only an example illustration of the ECU in the vehicle 450 and does not provide any limitation. In other embodiments, the vehicle 450 may also include other ECUs not shown, such as a power domain controller, a chassis domain controller, etc., which will not be described in detail here.

[0139] 2. Intelligent terminal 430:

[0140] Smart terminal 430 can communicate with server 410 and network communication device 451 of vehicle 450 via a mobile network. An application (APP) can be installed and run on smart terminal 430. This APP can, for example, serve as a service node. During APP operation, the APP can implement vehicle management by communicating with server 410 or vehicle 450. Similarly, an operation log can also be recorded and saved during APP operation. This operation log can, for example, include operation identifiers, operation content, date, time, or other related information related to information or operations of the user, server 410, or vehicle 450.

[0141] In a specific implementation, the data collection module on the smart terminal 430 side can be packaged in the form of a software development kit (SDK) in the APP for managing the vehicle, and can be used to collect the APP's operation logs and report the APP's operation logs to the server 410.

[0142] 3. Server 410:

[0143] The server 410 may include a data collection module 411 , an intrusion detection and analysis engine 412 , a storage module 414 , and at least one microservice, for example, represented as microservice 413_1 , microservice 413_2 , or microservice 413_3 .

[0144] (1) Microservices:

[0145] Each microservice, acting as a service node, can provide different IoV services for vehicle 450. For example, microservice 413_1 can provide OTA upgrades, microservice 413_2 can provide remote vehicle control, and microservice 413_3 can provide Bluetooth key access. Each microservice generates and saves a corresponding operation log during operation. The log content can vary depending on the service and is not detailed here.

[0146] (2) Data collection module 411:

[0147] The data collection module 411 can collect operation logs from multiple terminals (e.g., at least two service nodes). For example, the data collection module 411 can collect operation logs from different microservices by calling the interfaces of each microservice. Alternatively, the data collection module 411 can collect operation logs from the smart terminal 430 or from each ECU in the vehicle 450 via a wireless network.

[0148] In an optional embodiment, the data collection module 411 can clean and aggregate the collected multi-terminal log data, and uniformly classify and store the log data from the same vehicle, the same owner APP and the corresponding microservices according to the vehicle dimension.

[0149] It should be noted that in the embodiments of the present application, for any service node, the service process of the service node may include at least one step, for example, represented as step 1, step 2, step 3, etc. The data collection module located at the service node may record the contents of the operation log at each step of the service process and, if necessary, provide the collected log data to the data collection module 411 on the server 410 through the corresponding data collection channel, as shown in Figure 5.

[0150] It should be noted that the dotted arrow in Figure 5 represents the data collection channel between the business node and the data collection module 411 of the server 410. The data collection channel can be an independent channel, decoupled from the normal business process, that is, the collection of log data of the business node is achieved without the need for special adaptation of normal business and without perception.

[0151] (3) Intrusion Detection Analysis Engine 412:

[0152] The intrusion detection analysis engine 412 can perform a unified analysis on the log data from all end sources of each vehicle, and identify whether an intrusion detection event has occurred by matching the log data with the alternative detection rules in the preset detection rule set.

[0153] In specific implementation, as shown in Figure 6, before initiating intrusion detection, common attack methods (or intrusion attack behaviors) can first be analyzed for the business, for example, represented as attack method 1, attack method 2, attack method 3, attack method 4... Corresponding detection rules can be generated for different attack methods, for example, represented as alternative detection rule 1, alternative detection rule 2, alternative detection rule 3, alternative detection rule 4... The alternative detection rules generated for different businesses can be aggregated into a detection rule set, built into the intrusion detection analysis engine 412, or built into a storage module accessible to the intrusion detection analysis engine 412 (which can be the same as the storage module 414 or different). In an optional embodiment, the intrusion detection analysis engine 412 can provide a configuration interface, which can be used to receive configuration information, which can be used to modify the alternative detection rules in the detection rule set, and / or the configuration information can be used to add alternative detection rules to the detection rule set.

[0154] It should be noted that, in the embodiment of the present application, the identification of attack means and the generation of alternative detection rules can be achieved manually or by a model (such as a machine model or a learning model), which is not limited in the embodiment of the present application. Each alternative detection rule can be implemented in the form of program code or in other product forms, which is not limited in the embodiment of the present application. All alternative detection rules in the detection rule set have been tested before being put into use and meet the various conditions that the detection rules need to meet, which will not be repeated here.

[0155] When initiating intrusion detection, the intrusion detection analysis engine 412 of the server 410 can traverse and match all or part of the built-in alternative detection rules (called target detection rules) based on the log data of at least two business nodes obtained for the same vehicle to determine whether an intrusion event has occurred.

[0156] It should be noted that in the embodiment of the present application, the function of aggregating multi-terminal log data can also be integrated into the intrusion detection analysis engine 412, and the embodiment of the present application does not limit this. When performing intrusion detection, the intrusion detection analysis engine 412 only needs to follow the traversed target detection rules and determine whether the required target data can be extracted from the full amount of log data and whether the extracted target data matches, to determine whether an intrusion event corresponding to the target detection rule has occurred.

[0157] For example, the correspondence between an intrusion event, an intrusion event detection method, and related log lines may be as follows:

[0158] Intrusion Event A:

[0159] Intrusion event name: The OTA microservice delivery time is inconsistent with the local update time on the vehicle side, and the vehicle's local system may be flashed;

[0160] Threat Level: Medium;

[0161] Potential Risk: At the beginning of the OTA process, the OTA microservice sends update-related information to the vehicle. Upon receiving this information, the vehicle begins the OTA process. In real-world scenarios, the time the OTA microservice sends the message should be synchronized with the time the vehicle receives it. If a significant discrepancy is observed between the time the OTA microservice sends the message and the time the vehicle receives it, it is likely that the vehicle-to-cloud communication has been hijacked by an attacker, who may be using replay attacks or other means to launch attacks.

[0162] Detection method:

[0163] 1) Detecting a log line containing the following fields in the vehicle-side operation log: task ID (a task ID is an example of an operation ID);

[0164] 2). Extract the task ID from the log line: 345607472024893440;

[0165] 3) Check for the following log line below the log line: begin call Vdc ua proxy InformDCUrl interface;

[0166] 4) Extract the time value corresponding to the timestamp in the log line: 1652258444029;

[0167] 5) Check the taskid in the OTA microservice's running log. There should be multiple matching lines (if not, an intrusion threat is detected directly). Find the first line and extract the time value corresponding to the occurrence time: 1652258443625.

[0168] 6) Compare the two time values. If the time difference is greater than 1 hour, the network may be under attack.

[0169] Relevant log lines:

[0170] 2022-05-11 16:40:42.856|2817414160|OTAManager|INFO|Task Id:345607472024893440|OTATaskObjectHolder.cpp|189

[0171] 2022-05-11 16:40:44.030|2775450640|OTAManager|INFO|begin call Vdc ua proxy InformDCUrl interface,request is:{requestBase:{taskId:345607472024893440,timestamp:1652258444029},dcCluster:[{url:https: / / cdn.fgaif1.ias.huawei.com / *****5_SW%253A1.01.C_220429_2225_00.zip,size:41050,isRollBack:false}]}.|UAProxyLogPrintWrapper.cpp|44

[0172] 2022-05-11 08:40:43.625|[null]|transport-vert.x-eventloop-thread-2|INFO|LogProducerServiceImpl.java:49|send log LogModel(vehicleTaskId=345607472024893440,occurTime=1652258443625,stage=DISPATCH,event=51,executor=0,result=null, formatArgs=null,errorInfo={id:345607472024893440,type:0,policy:TaskPolicy(taskType=NORMAL,executeType=null,executeDateTime=null,promptDownload=N,downloadMethod=null,failedAction=STOP,retryTimes=0,flashTtl=300,otaScope=3,rescuePolicy=null),dpPackage:{"pkgId":"341274703425512448","vin":"F1790********0168","packageInfos":DpPackageForDispatch.P ackageInfo(version=v1.0,dcPackages=[{"domain":"4","path":"https: / / cdn.fgaif1.ias.huawei.com / 2022 / 04 / 29 / 1651225361442 / TBOX_7900010-SY01-2225_SW%253A1.01.C_220429_2225_00.zip","unzipSize":41050,"zipSize":41050,"rollback":0}],ecus=[DpPackageForDispatch.Ecu(domain=4,ecuId=7900010-SY01-2225,clay=1,partition=1,tc=20,nodeAddr=0x1728,srcVersion=DpPackageForDispatch.VersionInfo(software=[DpPackageForDispatch.Software(id=soft,version=SW:1.01.C_220429_2225_00)]),destVersion=DpPackageForDispatch.VersionInfo(software=[DpPackageForDispatch.Software(id=soft,version=SW:1.01.C_220429_2225_00)]),supportOta=false)],ruleInfo=DpPackageForDispatch.RuleInfo(version=1,rule={"pre_install":{"opr":7,"elms":[{"opr":7,"sub_elms":[{"var":"obd","opr":1,"val":"n"},{"var":"chargingState","opr":9,"val":"0,1"}]}]}}),upgradeOrder=DpPackageForDispatch.ComposeOrdersInner(install=DpPackageForDispatch.Co mposeOrderInner(stages=[DpPackageForDispatch.ComposeStageInner(voltageType=1,kl15=null,orderSegments=null,orderNodeAddr=[[0x1728,0x1728]])]),rollback=DpPackageForDispatch.ComposeOrderInner(stages=[DpPackageForDispatch.Compos eStageInner(voltageType=1,kl15=null,orderSegments=null,orderNodeAddr=[[0x1728,0x1728]])]),active=DpPackageForDispatch.ComposeOrderInner(stages=[])),supportingEcus=[]),"issueDate":1651225430000,"upgradeDuration":20},edition:{"revno":null,"prettyVersion":"SW1.01.C_220429_2225_00","issueDate":1651225430000,"releaseNotes":[{"la ng":"ZH","releaseNote":"18 version sample"}],"size":41050},supportingEcus:null}).caller class:com.huawei.ivcs.ota.scheduler.task.processor.impl.DispatchProcessor,line:790.

[0173] Intrusion Event B:

[0174] Intrusion event name: OTA download link replaced;

[0175] Threat Level: High;

[0176] Potential Risk: At the beginning of the OTA process, the OTA microservice sends update-related information to the vehicle. Upon receiving the information, the vehicle begins the OTA process. In a real-world environment, the download link in the message sent by the OTA microservice and the download link received by the vehicle should be identical. If the two links differ, it is likely that an attacker has hijacked and replaced the download link.

[0177] Detection method:

[0178] 1) A log line containing the following fields is detected in the vehicle's operation log: begin call Vdc ua proxy InformDCUrl interface;

[0179] 2) Extract the download link of the upgrade package received by the vehicle from this log line:

[0180] https: / / cdn.fgaif1.ias.huawei.com / *****5_SW%253A1.01.C_220429_2225_00.zip;

[0181] 3) Extract the OTA task's taskId from this row: 345607472024893440;

[0182] 4) Check the following field in the OTA microservice's runtime log: dcPackages. Multiple fields should be detected.

[0183] 5) You should be able to filter out two rows of records by taskId (if no intrusion threat is detected directly), select the first row, and extract the download URL:

[0184] https: / / cdn.fgaif1.ias.huawei.com / 2022 / 04 / 29 / 1651225361442 / TBOX_7900010-SY01-2225_SW%253A1.01.C_220429_2225_00.zip;

[0185] 6) Split the vehicle detection URL into the first and second halves: https: / / cdn.fgaif1.ias.huawei.com / ,5_SW%253A1.01.C_220429_2225_00.zip;

[0186] 7) Match the URL links of the vehicle side and OTA microservice to determine whether the content of the two is the same.

[0187] Relevant log lines:

[0188] 2022-05-11 16:40:44.030|2775450640|OTAManager|INFO|begin call Vdc ua proxy InformDCUrl interface,request is:{requestBase:{taskId:345607472024893440,timestamp:1652258444029},dcCluster:[{url:https: / / cdn.fgaif1.ias.hu awei.com / *****5_SW%253A1.01.C_220429_2225_00.zip,size:41050,isRollBack:false}]}.|UAProxyLogPrintWrapper.cpp|44

[0189] 2022-05-11 08:40:43.625|[null]|transport-vert.x-eventloop-thread-2|INFO|LogProducerServiceImpl.java:49|send log LogModel(vehicleTaskId=345607472024893440,occurTime=1652258443625,stage=DISPATCH,event=51,executor=0,result=null,formatArgs=null,errorInfo={id:345607472024893440,type:0,policy:TaskPolicy(taskType=NORMAL,executeType=null,executeDateTime=null,promptDownload=N,downloadMethod=null,failedAction=STOP,retryTimes=0,flashTtl=300,otaScope=3,rescuePolicy=null),dpPackage:{"pkgId":"341274703425512448","vin":"F1790********0168","packageInfos":DpPackageForDispatch.P ackageInfo(version=v1.0,dcPackages=[{"domain":"4","path":"https: / / cdn.fgaif1.ias.huawei.com / 2022 / 04 / 29 / 1651225361442 / TBOX_7900010-SY01-2225_SW%253A1.01.C_220429_2225_00.zip","unzipSize":41050,"zipSize":41050,"rollback":0}],ecus=[DpPackageForDispatch.Ecu(domain=4,ecuId=7900010-SY01-2225,clay=1,partition=1,tc=20,nodeAddr=0x1728,srcVersion=DpPackageForDispatch.VersionInfo(software=[DpPackageForDispatch.Software(id=soft,version=SW:1.01.C_220429_2225_00)]),destVersion=DpPackageForDispatch.VersionInfo(software=[DpPackageForDispatch.Software(id=soft,version=SW:1.01.C_220429_2225_00)]),supportOta=false)],ruleInfo=DpPackageForDispatch.RuleInfo(version=1,rule={"pre_install":{"opr":7,"elms":[{"opr":7,"sub_elms":[{"var":"obd","opr":1,"val":"n"},{"var":"chargingState","opr":9,"val":"0,1"}]}]}}),upgradeOrder=DpPackageForDispatch.ComposeOrdersInner(install=DpPackageForDispatch.Co mposeOrderInner(stages=[DpPackageForDispatch.ComposeStageInner(voltageType=1,kl15=null,orderSegments=null,orderNodeAddr=[[0x1728,0x1728]])]),rollback=DpPackageForDispatch.ComposeOrderInner(stages=[DpPackageForDispatch.Compos eStageInner(voltageType=1,kl15=null,orderSegments=null,orderNodeAddr=[[0x1728,0x1728]])]),active=DpPackageForDispatch.ComposeOrderInner(stages=[])),supportingEcus=[]),"issueDate":1651225430000,"upgradeDuration":20},edition:{"revno":null,"prettyVersion":"SW1.01.C_220429_2225_00","issueDate":1651225430000,"releaseNotes":[{"la ng":"ZH","releaseNote":"18 version sample"}],"size":41050},supportingEcus:null}).caller class:com.huawei.ivcs.ota.scheduler.task.processor.impl.DispatchProcessor,line:790.

[0190] It should be noted that the above uses intrusion events A and B as examples to illustrate the correspondence between intrusion events and intrusion event detection methods, and does not limit the scope of the present invention. In other embodiments, it is necessary to generate corresponding detection rules based on the specific attack methods that may be involved in the intrusion event, so that the detection rules can be used to detect the intrusion event later. This will not be further described here.

[0191] (4) Storage module 414:

[0192] The storage module 414 can be used to store detection results of different intrusion events of different vehicles, and can classify and store all intrusion events.

[0193] In an optional embodiment, the storage module 414 may also be associated with an output device. For example, the HMI of the output device may obtain the detection results of relevant events from the storage module 414 and output them so that front-end users can confirm the relevant events, trace the intrusion source, and perform emergency response.

[0194] For example, the HMI associated with the storage module 414 may output a first interface as shown in FIG7 , which may be used to present statistical results of intrusion events occurring up to a certain time (eg, 2022-7-28 10:58:40) from at least one dimension.

[0195] For example, the at least one dimension may include an alarm dimension, such as the threat level classification of each intrusion event: low risk, medium risk, high risk, extreme risk, etc.; the total number of intrusion events; the number of intrusion events corresponding to each threat level: for example, 455 low risk events, 342 medium risk events, 162 high risk events, and 24 extreme risk events.

[0196] Alternatively, the at least one dimension may include, for example, a scenario dimension, including but not limited to at least one of the following: a unified diagnostic services (UDS) diagnostic scenario, a system network scenario, an in-vehicle network scenario, an OTA scenario, a Bluetooth key scenario, a system certificate scenario, an in-vehicle system scenario, a remote vehicle control scenario, etc. The statistical results may include the number of intrusion events involved in different scenarios. As shown in FIG7 , the horizontal axis may represent the statistical number of intrusion events, and the vertical axis may represent the scenario.

[0197] Alternatively, the at least one dimension may include a geographical dimension, including but not limited to regions divided by different granularities such as provinces / municipalities, cities, counties, and districts. As shown in FIG7 , taking the regions divided by province as an example, the vertical axis represents the identifier of the province (e.g., represented as Province 1, Province 2, ..., Province 8), and the horizontal axis represents the statistical number of intrusion incidents occurring in different provinces.

[0198] Alternatively, the at least one dimension may include a vehicle model dimension, for example, represented as X1. As shown in FIG7 , the ordinate may represent the vehicle model, and the abscissa may represent the statistical number of intrusion events involving the vehicle model.

[0199] Alternatively, the at least one dimension may include, for example, an intrusion event response dimension. As shown in FIG7 , the horizontal axis represents time (e.g., the time of occurrence of the intrusion event or the processing time of the intrusion event response), and the horizontal axis represents the number of intrusion events or the number of intrusion event responses that occurred within the corresponding time interval.

[0200] Alternatively, the at least one dimension may include a vehicle ECU dimension, such as a vehicle identification unit (VIU), vehicle dynamics control (VDC), automatic adjustment and continuous damping control system (CDC), vehicle information and positioning transmission system (telematics-box, TBOX), or vehicle-to-cloud communication. As shown in FIG7 , the first interface may also output the number of intrusion events of different threat levels involving each ECU. It should be understood that FIG7 may also present statistical results for different ECUs connected to corresponding locations in the vehicle, which will not be repeated here.

[0201] Alternatively, the at least one dimension may also include a workbench dimension, which may present the number of intrusion events processed (e.g., 688), the number of intrusion events to be processed (e.g., 295), and a recent event list, which may present the most recent intrusion event and the time when the event occurred.

[0202] For the statistical results presented from at least one dimension in Figure 7, the front-end user can select a specific item through the mouse or other input methods, so that the first interface shown in Figure 7 can jump to the second interface (or display the first interface and the second interface side by side), and the second interface can present more fine-grained information details of the selected specific item.

[0203] For example, if a front-end user selects an event in the "Recent Event List," the output device's HMI can receive control information input on the first interface, indicating the output of the intrusion detection results for the target intrusion event. Accordingly, the output device's HMI will display a second interface, as shown in FIG8 , which displays the intrusion detection results for the target intrusion event, including details of at least one of the following: event identifier, event name, threat level, detection time, potential risk, intrusion attack target, intrusion detection process, or intrusion detection context information.

[0204] In an optional embodiment, FIG8 may also present an input box, which can be used by the front-end user to enter or select confirmation information or a handling method for the intrusion event. Accordingly, the HMI can receive second indication information input in response to the intrusion detection result, which is used to confirm the intrusion event or to indicate the handling method for the intrusion event. The handling methods for different intrusion events may vary, and this embodiment of the application is not limited to this.

[0205] As a result, the output device can very conveniently present the detection results and related context of the intrusion event, so that the front-end user can confirm, respond to, trace the source of the intrusion event in a timely manner after consulting this information.

[0206] So far, the system architecture of the embodiment of the present application has been described in detail in conjunction with the accompanying drawings and embodiments, wherein the server, as an intrusion detection terminal, can collect operation logs from at least two business nodes that implement the target business, and parse the collected log data to detect whether there are intrusion events in each business node or the network communication between business nodes. The server can perform comprehensive intrusion detection on business nodes involving multiple terminals or multiple systems from a business level, rather than being limited to a single business node, which helps to improve the detection efficiency of intrusion events. At the same time, the output device associated with the server can output statistical results of intrusion events from at least one dimension to facilitate front-end users (such as security experts) to promptly confirm, trace or respond to intrusion events based on the presented information.

[0207] For ease of understanding, the intrusion detection method of the embodiment of the present application is introduced below in combination with the OTA scenario and the Bluetooth key scenario.

[0208] 1. OTA scenario:

[0209] In the field of intelligent connected vehicles, OTA (Over-the-Air) has become a standard technology. Each vehicle's ECU can use OTA to download OTA upgrade packages from a server-side OTA microservice to update its own system, thereby gaining new features or patching the system to improve system security. While OTA functionality brings convenience to intelligent connected vehicles, it also presents a key attack point for attackers. One common attack method involves hijacking vehicle-to-cloud communications and replacing the OTA upgrade package download link to flash a malicious system into the vehicle's ECU. Therefore, security detection is necessary for intrusion events corresponding to this attack method.

[0210] As shown in Figure 9, in an OTA scenario, when the vehicle and the OTA microservice execute a normal OTA process, the business nodes involve the vehicle-side ECU and the server-side OTA microservice. The steps involved in the business process may include: the OTA microservice sends the download link for the OTA upgrade package. In response, the vehicle receives the download link for the OTA upgrade package. The vehicle downloads the OTA upgrade package. The vehicle installs and activates the OTA upgrade package.

[0211] Based on the intrusion detection method of the embodiment of the present application, during the process of the vehicle-side ECU or OTA microservice each implementing the corresponding business steps, the data collection module of the vehicle-side ECU or OTA microservice can collect operation logs. The data collection module of the server can collect operation logs from the data collection module of the vehicle-side ECU or OTA microservice and provide the collected log data to the intrusion detection analysis engine. The intrusion detection analysis engine can traverse and match some or all of the alternative detection rules in the built-in detection rule set based on the obtained log data. Based on the matched target detection rules, the intrusion detection analysis engine can extract target data (such as the download link of the OTA upgrade package) from the relevant operation log and match the content of the extracted target data. If the target data does not meet the corresponding detection conditions (such as the same URL content), it identifies that an intrusion event has occurred. Furthermore, the detection results or log context of the intrusion event can be output on the front-end HMI of the server, and the front-end user (such as a security expert) can confirm the intrusion event. After manual confirmation by the security expert, the intrusion event is confirmed. Detailed parsing details of the operation log can be found in the description of the detection method in conjunction with intrusion event A above, and will not be repeated here.

[0212] 2. Bluetooth key scenario:

[0213] In a normal vehicle Bluetooth key (door opening) process, the owner's app obtains the Bluetooth key from the corresponding microservice in the cloud, then uses the obtained Bluetooth key to communicate with the vehicle via Bluetooth and send a door opening request to open the door. In this embodiment of the application, by modeling common attack scenarios for the Bluetooth key service, an attack pattern can be obtained as shown in Figure 10. The attacker hijacks the Bluetooth communication between the owner's app and the vehicle and replays the message after the owner leaves the vehicle, thereby illegally opening the door.

[0214] As shown in Figure 10, the Bluetooth key scenario may include the following steps:

[0215] S1: The car owner's app requests login verification from the cloud microservice.

[0216] S2: After successful verification by the cloud microservice, feedback information is sent to the car owner's APP.

[0217] S3: After successfully logging in, the car owner APP applies for the Bluetooth key from the cloud microservice.

[0218] S4: The cloud microservice sends the Bluetooth key to the car owner's APP.

[0219] S5: The owner's app uses the Bluetooth key to request the vehicle to open the door. During this process, an attacker could hijack the Bluetooth communication between the owner's app and the vehicle at S6 and obtain the Bluetooth key. At S7: If the owner's app does not receive a response within a timeout, it terminates the door opening process.

[0220] S8: The attacker replays the door opening information to request to open the car door.

[0221] S9: The vehicle sends a reminder to the attacker that the door was successfully opened.

[0222] After threat modeling the attack scenario shown in Figure 10, we can identify which terminals will be affected during the attack. This identification reveals the need to collect and analyze the operation logs of the owner's app and the vehicle's app to generate intrusion detection rules corresponding to the Bluetooth key replay attack. Furthermore, we can execute the intrusion detection method shown in Figure 11:

[0223] The data collection module of the server can collect the operation logs of the vehicle APP and the operation logs of the cloud microservices, and provide the obtained operation logs to the intrusion detection analysis engine. The intrusion detection analysis engine will extract the Bluetooth key door opening related information from the collected log data based on the Bluetooth key replay attack rules, such as the relevant operation time (such as the operation time of using the Bluetooth key door opening instruction or the operation time of receiving the Bluetooth key door opening instruction). The intrusion detection analysis engine can compare the two extracted operation time values, such as calculating whether the difference between the two time values ​​meets the detection condition (for example, less than or equal to the first threshold). If not, that is, the difference between the two time values ​​is too large, indicating that the vehicle may be subject to a Bluetooth key replay attack.

[0224] It should be noted that in the embodiments of the present application, for a vehicle, an attacker may use a Bluetooth key replay attack to open the vehicle door and cause attacks on other vehicles. Therefore, in an optional implementation, priorities can be set for intrusion events and alternative detection rules in different scenarios. During specific implementation, intrusion detection can also be performed step by step according to the priority. For example, for a vehicle, each time an intrusion detection is performed, a Bluetooth key replay attack detection is first performed. If a Bluetooth key replay attack is confirmed, the vehicle itself has been stolen and is in an unsafe state. Other services implemented based on the vehicle are also unsafe, and there is no need to perform intrusion detection for other scenarios.

[0225] It should be understood that this is merely an example of the order of implementing intrusion detection in different scenarios and is not a limitation. In specific implementations, priority may not be set, which will not be elaborated here.

[0226] Thus far, the application of the intrusion detection method of the present invention in the context of the Internet of Vehicles (IoV) has been explained in conjunction with the accompanying drawings and examples. This method utilizes a server-based detection rule set to analyze log data from multiple sources for the same vehicle's target services to detect intrusion events. This method effectively identifies intrusion attacks targeting the entire vehicle's services at the service level, rather than being limited to a single service node. Furthermore, this method is decoupled from the normal operations of each service node, without impacting the normal operation of these nodes. Because the server's security level is higher than that of the vehicle's ECU, the risk of attacks on the intrusion detection and analysis engine is greatly reduced. Furthermore, front-end users can view intrusion event details on the server's associated output device and retrieve and present relevant contextual information from the storage module, facilitating front-end user confirmation, tracing, and emergency response. The server's portal for configuring alternative detection rules also facilitates timely updating of the detection rule set built into the intrusion detection and analysis engine based on updated attack vectors or missed detections in historical intrusion data.

[0227] It should be understood that the intrusion detection method described in the embodiments of this application can also be used in the IoT field. In this field, the same or similar methods as those described above in the Internet of Vehicles scenario can be used to parse log data from multiple sources for the same object to determine whether an intrusion event has occurred. Implementation details can be found in the relevant description above and will not be repeated here.

[0228] An embodiment of the present application also provides a communication device for executing the method executed by the server, vehicle ECU, smart terminal, etc. in the above method embodiment. Relevant features can be found in the above method embodiment and will not be repeated here.

[0229] As shown in Figure 12, in one example, the communication device 1200 may include: an acquisition unit 1201 for acquiring operation logs of at least two service nodes associated with a target service; and a determination unit 1202 for determining whether an intrusion event has occurred based on the operation logs of the at least two service nodes and a target detection rule, wherein the target detection rule describes a method for detecting an intrusion event associated with the target service. For specific implementation methods, please refer to the method steps implemented by the server in the above method embodiment, and will not be repeated here.

[0230] In another example, an embodiment of the present application further provides an HMI, as shown in FIG13 . The HMI 1300 may include: a communication unit 1301 for receiving an intrusion detection result of a target intrusion event, wherein the intrusion detection result indicates at least one of the following information about the target intrusion event: an event identifier, an event name, a threat level, a detection event, a potential risk, an intrusion attack target, an intrusion detection process, or intrusion detection context information; and an output unit 1302 for outputting the intrusion detection result of the target intrusion event. For specific implementation methods, please refer to the method steps implemented by the output device in the above method embodiment, which will not be repeated here.

[0231] It should be understood that the division of the various units in the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into a physical entity, or they can be physically separated. In addition, the units in the device can be implemented in the form of a processor calling software; for example, the device includes a processor, the processor is connected to a memory, and the memory stores instructions. The processor calls the instructions stored in the memory to implement any of the above methods or realize the functions of the various units of the device, where the processor is, for example, a general-purpose processor, such as a central processing unit (CPU) or a microprocessor, and the memory is a memory within the device or a memory outside the device. Alternatively, the units in the device can be implemented in the form of hardware circuits, and the functions of some or all of the units can be realized by designing the hardware circuits. The hardware circuit can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC), which realizes the functions of some or all of the above units by designing the logical relationship of the components in the circuit. For another example, in another implementation, the hardware circuit can be implemented by a programmable logic device (PLD). Taking a field programmable gate array (FPGA) as an example, it can include a large number of logic gate circuits, and the connection relationship between the logic gate circuits is configured by configuring the configuration file, thereby realizing the functions of some or all of the above units. All units of the above devices can be implemented in the form of software called by the processor, or in the form of hardware circuits, or in part by the form of software called by the processor, and the rest by hardware circuits.

[0232] In an embodiment of the present application, a processor is a circuit with a signal processing capability. In one implementation, the processor may be a circuit with instruction reading and execution capability, such as a CPU, a microprocessor, a graphics processing unit (GPU) (which can be understood as a microprocessor), or a digital signal processor (DSP); in another implementation, the processor may implement certain functions through the logical relationship of a hardware circuit, and the logical relationship of the hardware circuit is fixed or reconfigurable, such as a hardware circuit implemented by an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and implementing the hardware circuit configuration can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. In addition, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), etc.

[0233] It can be seen that each unit in the above device can be one or more processors (or processing circuits) configured to implement the above method, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0234] In addition, the various units in the above devices can be fully or partially integrated together, or can be implemented independently. In one implementation, these units are integrated together and implemented in the form of a system-on-a-chip (SOC). The SOC may include at least one processor for implementing any of the above methods or implementing the functions of the various units of the device. The type of the at least one processor can be different, for example, including a CPU and FPGA, a CPU and an artificial intelligence processor, a CPU and a GPU, etc.

[0235] In a simple embodiment, those skilled in the art may appreciate that the communication devices in the above embodiments may all adopt the form shown in FIG. 14 .

[0236] As shown in FIG14 , the apparatus 1400 includes at least one processor 1410 and a communication interface 1430. In an optional design, a memory 1420 may also be included.

[0237] The embodiment of the present application does not limit the specific connection medium between the processor 1410 and the memory 1420.

[0238] In the apparatus as shown in FIG. 14 , the processor 1410 may transmit data through the communication interface 1430 when communicating with other devices.

[0239] When the communication device adopts the form shown in FIG14 , the processor 1410 in FIG14 can call the computer-executable instructions stored in the memory 1420 so that the device 1400 can execute any of the above method embodiments.

[0240] An embodiment of the present application also relates to a chip system, which includes a processor for calling a computer program or computer instructions stored in a memory so that the processor executes the method of any of the above embodiments.

[0241] In a possible implementation, the processor may be coupled to the memory through an interface.

[0242] In a possible implementation, the chip system may also directly include a memory, in which a computer program or computer instructions are stored.

[0243] For example, the memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache memory. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0244] An embodiment of the present application further relates to a processor, which is used to call a computer program or computer instruction stored in a memory so that the processor executes the method described in any of the above embodiments.

[0245] For example, in the embodiments of the present application, the processor is an integrated circuit chip with signal processing capabilities. For example, the processor can be an FPGA, a general-purpose processor, a DSP, an ASIC or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, a system on chip (SoC), a CPU, a network processor (NP), a microcontroller unit (MCU), a PLD or other integrated chip, and can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the embodiments of the present application can be directly embodied as being executed by a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0246] It should be understood that the embodiments of the present application may be provided as methods, systems, or computer program products.

[0247] In one possible implementation, an embodiment of the present application provides a computer-readable storage medium, which stores program code. When the program code runs on the computer, the computer executes the above method embodiment.

[0248] In a possible implementation, an embodiment of the present application provides a computer program product. When the computer program product is run on a computer, the computer is caused to execute the above method embodiment.

[0249] Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0250] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0251] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0252] Obviously, those skilled in the art can make various changes and modifications to the embodiments of the present application without departing from the scope of the embodiments of the present application. Thus, if these modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these changes and variations. In the various embodiments of the present application, unless otherwise specified or logically conflicting, the terms and / or descriptions between the various embodiments are consistent and can be referenced to each other, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

Claims

1. An intrusion detection method, characterized in that: Applied to a server, the method includes: Obtaining operation logs of at least two service nodes, where the at least two service nodes are associated with a target service; Determine whether the intrusion event occurs based on the operation logs of the at least two service nodes and a target detection rule, where the target detection rule is used to describe a method for detecting an intrusion event associated with the target service.

2. The method according to claim 1, characterized in that The target detection rule includes a detection field for indicating the intrusion event and a rule for at least one detection condition, wherein the detection field characterizes a feature of a potential intrusion attack behavior of the target service. Determining whether the intrusion event occurs based on the operation logs of the at least two service nodes and the target detection rule includes: Acquire target data from the operation logs of the at least two service nodes according to the detection field indicated by the target detection rule; When the operation log and the target data satisfy all the detection conditions of the at least one detection condition, determining that no intrusion event has occurred; When the operation log or the target data does not satisfy any one of the at least one detection condition, it is determined that an intrusion event occurs.

3. The method according to claim 2, characterized in that The detection field of the intrusion event includes a timestamp, the target data includes a time value corresponding to the timestamp, and the at least one detection condition includes: A difference between time values ​​obtained from the operation logs of the at least two service nodes is less than or equal to a first threshold.

4. The method according to claim 2 or 3, characterized in that The detection field of the intrusion event includes a uniform resource locator (URL), the target data includes URL data, and the at least one detection condition includes: The content of the URL data obtained from the operation logs of the at least two service nodes is the same.

5. The method according to any one of claims 2 to 4, characterized in that The detection field of the intrusion event includes an operation identifier, the operation identifier is associated with executing an operation included in the target service, the target data includes data corresponding to the operation identifier, and the at least one detection condition includes: The data corresponding to the operation identifiers obtained from the operation logs of the at least two service nodes have the same content.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: According to the operation log, the target detection rule is obtained from the detection rule set, wherein the detection rule set includes alternative detection rules pre-configured for multiple potential intrusion attack behaviors of the target business, and the alternative detection rules are used to describe the detection method of the intrusion event corresponding to the potential intrusion attack behavior.

7. The method according to claim 6, characterized in that The target detection rule includes all candidate detection rules in the detection rule set; or, The target detection rule includes an alternative detection rule associated with the target service in the detection rule set.

8. The method according to claim 6 or 7, characterized in that The method further comprises: Configuration information is received, where the configuration information is used to modify an alternative detection rule in the detection rule set, and / or the configuration information is used to add a new alternative detection rule in the detection rule set.

9. The method according to any one of claims 1 to 8, characterized in that The method further comprises: The detection result of the intrusion event is outputted on an output device associated with the server.

10. The method according to claim 9, characterized in that The detection result of the intrusion event includes at least one of the following information of the intrusion event: event identifier, event name, threat level, detection time, potential risk, intrusion attack object, intrusion detection process or intrusion detection context information.

11. The method according to any one of claims 1 to 10, characterized in that The target service includes a vehicle service, and the at least two service nodes include: the server, the target vehicle, or a user equipment of a user who manages the target vehicle.

12. An intrusion detection method, characterized in that: Applied to a human-machine interface (HMI), the method includes: Receive an intrusion detection result of a target intrusion event, the intrusion detection result being used to indicate at least one of the following information of the target intrusion event: event identifier, event name, threat level, detection event, potential risk, intrusion attack object, intrusion detection process, or intrusion detection context information; Output the intrusion detection result of the target intrusion event.

13. The method according to claim 12, characterized in that The method further comprises: Second indication information input in response to the intrusion detection result is received, wherein the second indication information is used to confirm the intrusion event, or the second indication information is used to indicate a method for handling the intrusion event.

14. The method according to claim 12 or 13, characterized in that The method further comprises: Outputting a first interface, wherein the first interface is used to present statistical results of intrusion events from at least one dimension; Control information input on the first interface is received, where the control information is used to instruct output of an intrusion detection result of the target intrusion event.

15. A communication device, characterized in that: include: an acquiring unit, configured to acquire operation logs of at least two service nodes, wherein the at least two service nodes are associated with a target service; A determination unit is configured to determine whether the intrusion event occurs based on the operation logs of the at least two service nodes and a target detection rule, wherein the target detection rule is used to describe a method for detecting an intrusion event associated with the target service.

16. A human-machine interface HMI, characterized in that: include: A communication unit, configured to receive an intrusion detection result of a target intrusion event, wherein the intrusion detection result is used to indicate at least one of the following information of the target intrusion event: event identifier, event name, threat level, detection event, potential risk, intrusion attack object, intrusion detection process, or intrusion detection context information; An output unit is used to output the intrusion detection result of the target intrusion event.

17. A communication device, characterized in that: The communication device comprises: a communication interface for communicating with other devices; A processor is coupled to the communication interface, causing the communication device to execute the method according to any one of claims 1 to 11, or execute the method according to any one of claims 12 to 13.

18. A communication system, characterized in that: The method comprises a server, wherein the server is configured to implement the method according to any one of claims 1 to 11.

19. The communication system according to claim 18, wherein: It also includes a human-machine interface HMI, which is used to implement the method according to any one of claims 12-13.

20. A chip system, characterized in that: The chip system comprises at least one processor and an interface circuit, wherein the processor is used to execute instructions and / or data interaction through the interface circuit, so that the chip system executes the method according to any one of claims 1 to 11, or executes the method according to any one of claims 12 to 13.

21. A computer-readable storage medium, characterized in that The method comprises a program or an instruction. When the program or the instruction is executed, the method according to any one of claims 1 to 11 is executed, or the method according to any one of claims 12 to 13 is executed.

22. A computer program product, characterized in that When a computer reads and executes the computer program product, the computer is enabled to execute the method according to any one of claims 1 to 11, or execute the method according to any one of claims 12 to 13.

Images