WO2024065093A1 - 一种入侵检测方法、装置和系统 - Google Patents

一种入侵检测方法、装置和系统 Download PDF

Info

Publication number
WO2024065093A1
WO2024065093A1 PCT/CN2022/121397 CN2022121397W WO2024065093A1 WO 2024065093 A1 WO2024065093 A1 WO 2024065093A1 CN 2022121397 W CN2022121397 W CN 2022121397W WO 2024065093 A1 WO2024065093 A1 WO 2024065093A1
Authority
WO
WIPO (PCT)
Prior art keywords
detection
intrusion
target
event
vehicle
Prior art date
Application number
PCT/CN2022/121397
Other languages
English (en)
French (fr)
Inventor
汪洋一舟
李勇军
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2022/121397 priority Critical patent/WO2024065093A1/zh
Publication of WO2024065093A1 publication Critical patent/WO2024065093A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/06—Generation of reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • the present application relates to the field of information security technology, and in particular to an intrusion detection method, device and system.
  • the present application provides an intrusion detection method, device and system, which are helpful to accurately detect intrusion attacks against vehicle services.
  • 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.
  • 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 occurs 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.
  • the at least two service nodes are nodes that jointly implement the target service, and the server can detect whether an intrusion event occurs by parsing the operation logs of the at least two service nodes.
  • This method can perform comprehensive intrusion detection on service nodes involving multiple terminals or multiple systems from a business level, rather than being limited to a single service node or system, which helps to improve the detection efficiency of intrusion events.
  • the target service of the embodiment 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, activating OTA upgrade packages; vehicle Bluetooth key services; vehicle remote control services, etc.
  • OTA vehicle over-the-air
  • the service nodes used to implement the target service 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.
  • APP application
  • ECU electronice control unit
  • the embodiment of the present application does not limit the target service and the service nodes that implement the target service.
  • the intrusion detection method of the embodiment of the present application can also be expanded to other fields, such as the Internet of Things (IOT) field with similar characteristics to the Internet of Vehicles business.
  • IOT Internet of Things
  • the services involved may include, but are not limited to, smart home services.
  • 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.
  • the operation log is only an example and not a limitation of the server's information integration of multiple terminals or multiple systems.
  • the operation log can be replaced by other information that can characterize the business operation status, and the embodiments of the present application do not limit this.
  • 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 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 includes: 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.
  • the server can parse the operation logs of at least two business nodes obtained through preset detection rules, and detect whether an intrusion event occurs through the matching degree between the operation logs and the target data in the operation logs and the detection rules.
  • the specific content of the detection condition will affect the determination of the detection result.
  • the content of the detection condition it can also be set as follows: when the operation log and the target data meet all the detection conditions in 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 in the at least one detection condition, it is determined that no intrusion event has occurred.
  • the detection methods for different intrusion events may be different.
  • it can also be set as follows: for some intrusion events, when the operation log and the target data meet all the detection conditions in 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 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 in 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 at least one detection condition, it is determined that no intrusion event has occurred.
  • 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.
  • the detection field of the intrusion event includes a timestamp
  • the target data includes a time value corresponding to the timestamp
  • the at least one detection condition includes: the difference in 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 the server performs intrusion detection, it can determine that no intrusion detection event has occurred when the difference in the obtained time values meets the detection condition; and determine that an intrusion detection event has occurred when the difference in the obtained time values does not meet the detection condition.
  • the detection field of the intrusion event can include a timestamp.
  • 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 be intruded.
  • the at least one detection condition when the detection field includes a timestamp, the at least one detection condition may be replaced by: the difference in 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 may be greater than or equal to the first threshold.
  • the detection field of the intrusion event includes a uniform resource locator URL
  • the target data includes URL data
  • 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. Accordingly, when the server performs intrusion detection, it can determine that no intrusion detection event has occurred when the obtained URL data meets the detection condition; and determine that an intrusion detection event has occurred when the obtained URL data does not meet the detection condition.
  • the at least one detection condition 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 the server performs intrusion detection, it can determine that an intrusion detection event has occurred when the obtained URL data meets the detection condition; when the obtained URL data does not meet the detection condition, it can determine that no intrusion detection event has occurred.
  • 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
  • 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.
  • the at least one detection condition can be replaced by: the contents of the data corresponding to the operation identifier obtained from the operation logs of the at least two service nodes are different. Accordingly, when the server performs intrusion detection, it can determine that no intrusion detection event has occurred when the data corresponding to the obtained operation identifier meets the detection condition; and it can determine that an intrusion detection event has occurred when the data corresponding to the obtained operation identifier does not meet the detection condition.
  • the method also includes: obtaining the target detection rule from a detection rule set according to 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.
  • the server can preset a detection rule set, and use the target detection rule in the detection rule set to parse the obtained operation log to determine whether an intrusion event occurs.
  • the detection rule set can be pre-written based on known and limited intrusion attack methods, and the detection rule set can be stored in 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.
  • the target detection rule includes all the 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.
  • the method further includes: receiving configuration information, the configuration information being used to modify the alternative detection rule in the detection rule set, and/or the configuration information being used to add a new alternative detection rule to the detection rule set.
  • modification may include modifying the content of the alternative detection rule, or deleting the alternative detection rule.
  • the method further includes: outputting the detection result of the intrusion event.
  • the detection result of the intrusion event may be output on an output device associated with the server.
  • 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.
  • the detection result can be output in at least one of the following presentation modes: text, image, line.
  • the target service includes a vehicle service
  • the at least two service nodes include: the server, the target vehicle, or a user device of a user who manages the target vehicle.
  • vehicle service described here is a general term for Internet of Vehicles services, which may include but are 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 service nodes used to implement the target service 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.
  • APP application
  • ECU electronice control unit
  • the embodiment of the present application does not limit the target service and the service nodes that implement the target service.
  • the embodiment of the present application further provides an intrusion detection method, which can be implemented by a human-machine interaction interface (HMI) (or server front end).
  • HMI human-machine interaction interface
  • the human-machine interaction interface can be, for example, the HMI of an electronic device associated with the server, which can be used to output information from the server, and the presentation of the information content can include but is not limited to images, texts, lines, etc.
  • the HMI can also have or be associated with an input device, and can receive information from a front-end user (such as a security expert) through the input device, which is not limited in the embodiment of the present application.
  • 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.
  • 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.
  • the method may also 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.
  • 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.
  • 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.
  • 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 own needs, thereby triggering the presentation of intrusion detection results for the target intrusion event.
  • 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 operation logs of at least two business nodes, and the at least two business nodes are associated with a 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 a target detection rule, and the target detection rule is used to describe a detection method for an intrusion event associated with the target business.
  • the target detection rule includes a detection field for indicating the intrusion event and a rule of at least one detection condition, the detection field characterizing the characteristics of potential intrusion attack behavior of the target business
  • 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.
  • the detection field of the intrusion event includes a timestamp
  • the target data includes a time value corresponding to the timestamp
  • 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.
  • the detection field of the intrusion event includes a uniform resource locator URL
  • the target data includes URL data
  • 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.
  • 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
  • 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.
  • the acquisition unit is also used to: obtain the target detection rule from the detection rule set according to 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.
  • the target detection rule includes all the 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.
  • 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.
  • 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.
  • 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.
  • the target service includes a vehicle service
  • the at least two service nodes include: the server, the target vehicle, or a user equipment of a user who manages the target vehicle.
  • an embodiment of the present application provides a human-machine 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.
  • 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.
  • the output unit is also used to output a first interface, and the first interface 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.
  • an embodiment of the present application provides a communication device, comprising: a communication interface for communicating with other devices; and a processor coupled to the communication interface, so that the communication device 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.
  • 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 above-mentioned first aspect and any possible design of the first aspect.
  • the communication system also includes a human-machine interaction 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.
  • HMI human-machine interaction interface
  • 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 instructions and/or data interaction through the interface circuit, so that the chip system 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.
  • an embodiment of the present application provides a computer-readable storage medium, including a program or instructions.
  • the program or instructions When the program or instructions are 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.
  • an embodiment of the present application provides a computer program product.
  • the 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.
  • 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.
  • a processor which is coupled to a memory and is used to execute a computer program or instruction stored in the memory.
  • FIG1 is a schematic diagram showing an application scenario to which an embodiment of the present application is applicable
  • FIG2 is a schematic diagram showing a system architecture applicable to an embodiment of the present application.
  • FIG3 is a schematic diagram showing a flow chart of an intrusion detection method according to an embodiment of the present application.
  • FIG4 is a schematic diagram showing a system architecture applicable to an embodiment of the present application.
  • FIG5 is a schematic diagram showing a log collection principle according to an embodiment of the present application.
  • FIG6 is a schematic diagram showing the principle of generating a detection rule set according to an embodiment of the present application.
  • FIG7 shows a schematic diagram of a first interface of an embodiment of the present application
  • FIG8 is a schematic diagram showing a second interface of an embodiment of the present application.
  • 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.
  • FIG10 shows a schematic diagram of an attack on a Bluetooth key scenario in an embodiment of the present application
  • 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
  • FIG12 is a schematic diagram showing the structure of a communication device according to an embodiment of the present application.
  • FIG13 is a schematic diagram showing the structure of a human-computer interaction interface according to an embodiment of the present application.
  • FIG. 14 shows a schematic diagram of the structure of a communication device according to an embodiment of the present application.
  • the "user” mentioned in the embodiments of the present application is a person who uses the vehicle, and the user may include the vehicle owner, or other persons authorized by the vehicle owner to use the vehicle, such as the vehicle owner's relatives, friends, etc. It should be understood that for an unmanned vehicle, the user may be a virtual user or a real person who manages the vehicle, and the embodiments of the present application do not limit this.
  • the user device can be the vehicle terminal of the vehicle used by the user or the user's smart terminal, such as a mobile phone, tablet computer, etc.
  • the user device can be the vehicle terminal of the vehicle; it can also be a mobile terminal placed on the vehicle, such as a mobile phone, tablet computer, etc.; it can also be other electronic devices associated with the vehicle, such as electronic devices controlled by vehicle management personnel, including but not limited to desktop computers, laptops, mobile phones, tablet computers, etc.; the embodiment of the application does not limit the product form of the user device.
  • the service may include an Internet of Vehicles service (or vehicle service).
  • vehicle service may include, but is 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) inside the vehicle, etc.
  • APP application
  • ECU electronic control unit
  • An operation log is an ordered collection of events of operations of a specified object and its operation results.
  • the content of an operation log can be collected and recorded in the form of a log file, which can include multiple log lines, each of which can record the description of the relevant operations such as date, time, executor, and action.
  • the operation log is used to perform intrusion detection from a security perspective, so the operation log can also be called a security log.
  • Intrusion events or attack events
  • It refers to an information security incident in which an information system is attacked or invaded through the network or other technical means by taking advantage of the configuration defects, protocol defects, program defects of the information system or by using brute force attacks, causing information system anomalies or potential harm to the current operation of the information system.
  • an intrusion event is associated with 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.
  • a business can also be divided into multiple sub-businesses, and each sub-business can also involve multiple intrusion events. The embodiment of the present application does not limit the corresponding relationship between a business and an intrusion event.
  • Detection rules are used to describe the detection method of intrusion events associated with the service. Generally, one detection rule corresponds to one intrusion event.
  • 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 in other forms.
  • the embodiment of the present application does not limit the implementation of the detection rule.
  • 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.
  • the detection field is used to characterize the characteristics of potential intrusion attack behaviors of the service.
  • the detection field may include at least one of the following: a timestamp, a URL, and an operation identifier.
  • the embodiments of the present application provide an intrusion detection method, device, and system.
  • the server can detect whether an intrusion event has occurred by parsing the operation logs of at least two business nodes.
  • the method 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 or system, which helps to improve the detection efficiency of intrusion events.
  • the method and the device are based on the same technical concept. Since the principles of solving the problem by the method and the device are similar, the implementation of the device and the method can refer to each other, and the repeated parts will not be repeated.
  • 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.
  • V2X vehicle to everything
  • LTE-V long term evolution-vehicle
  • V2V vehicle to vehicle
  • the other devices include but are not limited to: other sensors such as a vehicle-mounted terminal, a vehicle-mounted controller, a vehicle-mounted module, a vehicle-mounted module, a vehicle-mounted component, a vehicle-mounted chip, a vehicle-mounted unit, a vehicle-mounted radar or a vehicle-mounted camera.
  • the vehicle can implement the method provided in the embodiment of the present application through the vehicle-mounted terminal, the vehicle-mounted controller, the vehicle-mounted module, the vehicle-mounted module, the vehicle-mounted component, the vehicle-mounted chip, the vehicle-mounted unit, the vehicle-mounted radar or the vehicle-mounted camera.
  • the control scheme in the embodiment of the present application can also be used in other intelligent terminals with mobile control functions other than the vehicle, or be set in other intelligent terminals with mobile control functions other than the vehicle, or be set in the components of the intelligent terminal.
  • the intelligent terminal can be an intelligent transportation device, an intelligent home device, a robot, etc.
  • it includes but is not limited to smart terminals or controllers, chips, other sensors such as radars or cameras, and other components in smart terminals.
  • At least one refers to one or more
  • plural refers to two or more.
  • “And/or” describes the association relationship of associated objects, indicating that three relationships may exist.
  • a and/or B can represent: A exists alone, A and B exist at the same time, and B exists 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” or similar expressions refers to any combination of these items, including any combination of single or plural items.
  • 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.
  • the ordinal numbers such as “first” and “second” mentioned in the embodiments of the present application are used to distinguish multiple objects, and are not used to limit the priority or importance of multiple objects.
  • the first user information and the second user information are only used to distinguish user information obtained at different times or in different ways, rather than indicating the difference in content, priority or importance of the two user information.
  • FIG1 shows a schematic diagram of an application scenario to which an embodiment of the present application is applicable.
  • a server 200 and at least one user equipment (UE) 100 may be included.
  • the server 200 and the at least one user equipment 100 may communicate via a network.
  • the server 200 may also be implemented via a virtual machine.
  • 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.
  • 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.
  • the processor 151 may be any conventional processor, such as a central processing unit (CPU). Alternatively, the processor 151 may also include a graphics processor (GPU), a field programmable gate array (FPGA), a system on chip (SOC), an application specific integrated circuit (ASIC), or a combination thereof.
  • CPU central processing unit
  • the processor 151 may also include a graphics processor (GPU), a field programmable gate array (FPGA), a system on chip (SOC), an application specific integrated circuit (ASIC), or a combination thereof.
  • GPU graphics processor
  • FPGA field programmable gate array
  • SOC system on chip
  • ASIC application specific integrated circuit
  • the memory 152 may also store data such as road maps, route information, the vehicle's location, direction, speed and other vehicle data, the operation logs of each ECU of the vehicle, and other information. This information can be used by the vehicle and the vehicle-mounted terminal 150 during the operation of the vehicle 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 a limitation on the embodiments of the present application.
  • the above-mentioned vehicle can be a car, a truck, a motorcycle, a bus, a ship, an airplane, a helicopter, a lawn mower, an entertainment vehicle, an amusement park vehicle, construction equipment, a tram, a golf cart, a train, etc., and the embodiments of the present application are not particularly limited.
  • 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 does not constitute any limitation.
  • the computing function can be implemented by an independent device on at least one user device 100 or by a processor 151.
  • the embodiments of the present application do not limit this.
  • FIG3 shows a flow chart of an intrusion detection method according to an embodiment of the present application.
  • the method may be implemented by the server shown in FIG1 or FIG2 and at least one user device (such as a vehicle) in collaboration. As shown in FIG3, the method may include the following steps:
  • S310 The server obtains operation logs of at least two service nodes.
  • the at least two service nodes are communication nodes associated with the target service.
  • the operation log is a record of information generated and collected by the service node in the process of implementing the target service, which is used to describe the operation related to the service.
  • the log content may include but is not limited to the operation identifier, the date or time when the operation occurred, and other information associated with the operation.
  • the target service may include vehicle service
  • the at least two service nodes include: the server, the target vehicle, or the user equipment of the user who manages the target vehicle.
  • vehicle service described here is a general term for Internet of Vehicles services, which may include but are 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 service nodes used to implement the target service 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 service and the service nodes that implement the target service.
  • the server can communicate and interact with the business node directly or indirectly.
  • 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 the business node receives a request from the server and reports the operation log requested by the server to the server.
  • 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.
  • the operation logs from the business nodes may be carried in the form of log files in communication messages from the business nodes.
  • the log files may, 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 may, for example, be referred to as a reporting period, which may be an equal time interval or an unequal time interval), or report part of the recorded log contents according to pre-configuration or negotiation.
  • the embodiment of the present application does not limit the transmission method and content of the operation log.
  • 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.
  • the target detection rule can be used to describe a method for detecting an intrusion event associated with the target business.
  • 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.
  • 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.
  • 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 it can be stored in the server in the form of other information, which is not limited in the embodiments of the present application.
  • an alternative detection rule may correspond to an intrusion event, and the alternative detection rule may include a detection field for indicating an intrusion event and a rule of at least one detection condition.
  • the detection field may characterize the characteristics of a potential intrusion attack behavior of a business, including but not limited to a timestamp, a uniform resource locator (URL) or an operation identifier, etc.
  • At least one detection condition may instruct the server to obtain target data from the operation log to be parsed according to the detection field of the intrusion event, and determine whether an intrusion event occurs according to whether the operation log and the target data meet the at least one detection condition.
  • the target detection rule includes all candidate detection rules in the detection rule set; or, the target detection rule may include the candidate detection rule associated with the target business in the detection rule set.
  • the target detection rule may include a detection field for indicating an intrusion event and a rule for at least one detection condition, and the detection field of the target detection rule characterizes the characteristics of potential intrusion attack behavior of the target business.
  • the server can obtain target data from the operation logs of at least two business nodes according to the detection field indicated by the target detection rule, and the server can determine whether an intrusion event occurs based on whether the operation log and the target data meet at least one detection condition.
  • the server may determine that no intrusion event has occurred when the operation log and the target data meet all the detection conditions of the at least one detection condition; and determine that an intrusion event has occurred when the operation log and the target data do not meet any of the at least one detection condition.
  • the server may determine that an intrusion event has occurred when the operation log and the target data meet all the detection conditions of the at least one detection condition; and determine that no intrusion event has occurred when the operation log and the target data do not meet any of the at least one detection condition.
  • the target data may include a 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.
  • the server uses the target detection rule to parse the operation log
  • 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.
  • 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.
  • 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.
  • 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 the same. Then, when the server uses the target detection rule to parse the operation log, when the content of the URL data obtained from the operation logs of the at least two service nodes is the same, the detection condition is met, and it is determined that no intrusion event has occurred; or, when the content of the URL data obtained from the at least two service nodes is different, the detection condition is not met, and it is determined that an intrusion event has occurred.
  • 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 uses the target detection rule to parse the operation log, when the content of the URL data obtained from the operation logs of the at least two service nodes is different, the detection condition is met, and it is determined that an intrusion event has occurred; or, when the content of the URL data obtained from the operation logs of the at least two service nodes is the same, the detection condition is not met, and it is determined that no intrusion event has occurred.
  • 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.
  • the server uses the target detection rule to parse the operation log
  • the detection condition is met, and it is determined that no intrusion event has occurred; or, when 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.
  • 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.
  • the server uses the target detection rule to parse the operation log
  • 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.
  • the above is only an example description of the detection fields and detection conditions indicated by the target detection rules.
  • the content of the detection fields specifically indicated by the target detection rules is not limited, nor is the content and number of the detection conditions indicated by the target detection rules. They will not be repeated here.
  • the server may also output the detection result of the intrusion event.
  • the server may be associated with an output device, and the server may output the detection result of the intrusion event through the output device.
  • the detection result may include, for example, 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.
  • the front-end user may view the relevant information of the intrusion event through the display interface of the output device. If necessary, the front-end user may use the presented information to confirm the intrusion event, trace the attack source, etc.
  • FIG4 shows a schematic diagram of the system architecture of an embodiment of the present application applied to the vehicle networking scenario.
  • the server 410 can communicate and interact with the vehicle 450 and the user's smart terminal 430 through a wireless network to implement the intrusion detection method of the embodiment of the present application.
  • 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 of the vehicle.
  • the network communication device 451 may serve as a communication bridge between external devices such as a server 410 and a smart terminal 430 and the internal ECU of the vehicle 450, realizing the capabilities of receiving, sending or forwarding operation logs.
  • the network communication device 451 may, for example, realize information transmission with each ECU of the vehicle 450 through an in-vehicle communication network.
  • the network communication device 451 may support wireless communication or wired communication, which is not limited in the embodiment of the present application.
  • Each ECU can be used as a business node and can record and save operation logs during operation.
  • the OTA control unit 452 can be used as a unit module for implementing OTA upgrade control inside the vehicle 450, and can perform operations related to the OTA upgrade service.
  • the OTA control unit 452 can receive OTA content, OTA upgrade packages, etc. from the server 410 through the network communication device 451.
  • the OTA control unit 452 can also install the OTA upgrade package and activate the OTA upgrade package.
  • the OTA control unit 452 can feed back the operation results to the server 410 through the network communication device 451.
  • the OTA control unit 452 can synchronously record and save the operation log.
  • the operation log may include, for example, information describing the execution details of the relevant operations of the OTA upgrade service, such as the execution date, execution time, executor, operation identification, operation content, and other related information.
  • HMI 453 is an input/output device in vehicle 450.
  • the HMI 453 can communicate with network communication device 451, or OTA control unit 452, or cockpit domain controller 454, or vehicle sensor system 455, or autonomous driving domain controller 456 through the in-vehicle communication network, and can provide an operation interface for outputting information from network communication device 451, or OTA control unit 452, or cockpit domain controller 454, or vehicle sensor system 455, or autonomous driving domain controller 456, or for receiving information input by the user through HMI 453, or sending the received input information to the corresponding ECU or server.
  • the HMI 453 can synchronously record and save the operation log.
  • the operation log can include, for example, 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.
  • the cockpit domain controller 454 can obtain sufficient perception data through an independent perception layer, such as in-car vision (optical), voice (acoustic), and chassis and body data such as steering wheel, brake pedal, accelerator pedal, gear, seat belt, etc., and use biometric recognition technology (mainly face recognition and voice recognition in the cabin) to comprehensively judge the physiological state (portrait, face recognition, etc.) and behavioral state (driving behavior, voice, body behavior) of the driver (or other passengers), and then push the interaction request according to the specific scene.
  • the in-car interaction mode is upgraded from only “physical button interaction” to the coexistence of "touch screen interaction", "voice interaction” and “gesture interaction".
  • the cockpit domain controller 454 can synchronously record and save the operation log.
  • the operation log may include, for example, the date, time, operation identifier, operation content and other related information of obtaining various perception data, or may include the content, date, time, operation identifier and other related information of pushing the interaction request in a specific scene.
  • the vehicle sensing system 455 may include sensors such as cameras, radars, thermometers, and hygrometers.
  • the vehicle sensing system 455 may obtain the perception results of the in-vehicle environment or the outside environment through perception, and provide the perception results to the cockpit domain controller 454 or other ECUs that need the information, such as the autonomous driving domain controller 456.
  • the vehicle sensing system 455 may record the operation logs of each sensor device, such as the content of the perception information, the date and time of generation, the operation identifier, and other associated information.
  • the autonomous driving domain controller 456 can make autonomous driving decisions and implement autonomous driving control based on the various perception results collected, such as adaptive cruise control, automatic emergency braking control, lane keeping assist control, lane departure warning control, parking assist control, etc.
  • the autonomous driving domain controller 456 can synchronously record and save the operation log in the process of running and implementing the corresponding business.
  • the operation log may include the operation identification, content, date, time or other related information involved in different autonomous driving function operations.
  • 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.
  • each ECU shown in FIG. 4 can be used as a service node of the Internet of Vehicles service to 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.
  • a data collection module can also be integrated in 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.
  • 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 service 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.
  • FIG. 4 is merely an example illustration of the ECU within the vehicle 450 and is not a limitation.
  • 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.
  • the smart terminal 430 can communicate with the server 410 and the network communication device 451 of the vehicle 450 through the mobile network.
  • An application can be installed and run on the smart terminal 430.
  • the APP can be used as a service node, for example.
  • the APP can implement vehicle management through communication interaction with the server 410 or the vehicle 450.
  • the operation log can also be synchronously recorded and saved during the operation of the APP.
  • the operation log may include, for example, operation identification, operation content, date, time or other related information related to the information or operation of the user, server 410 or vehicle 450.
  • 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 operation log of the APP and report the operation log of the APP to the server 410.
  • SDK software development kit
  • the server 410 may include a data collection module 411 , an intrusion detection 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 .
  • microservice 413_1 can provide OTA upgrade services
  • microservice 413_2 can provide vehicle remote control services
  • microservice 413_3 can provide vehicle Bluetooth key services.
  • Each microservice will generate and save corresponding operation logs during operation. The log content may vary depending on the service, and will not be repeated here.
  • 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. Or, for example, the data collection module 411 can collect operation logs from each ECU of the smart terminal 430 or the vehicle 450 through a wireless network.
  • 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.
  • the business process of the business 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 business node may record the content of the operation log at each step of the business process, and provide the collected log data to the data collection module 411 on the server 410 side through the corresponding data collection channel when necessary, as shown in FIG5 .
  • 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 the normal business and without perception.
  • 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.
  • attack means can first be analyzed for the business, for example, represented as attack means 1, attack means 2, attack means 3, attack means 4...
  • Corresponding detection rules can be generated for different attack means, 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 collected into a detection rule set, built in the intrusion detection analysis engine 412, or built in a storage module accessible to the intrusion detection analysis engine 412 (which can be the same as the storage module 414 or different).
  • 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.
  • the identification of attack means and the generation of alternative detection rules can be implemented manually or by a model (such as a machine model or a learning model), which is not limited in the embodiments of the present application.
  • Each alternative detection rule can be implemented in the form of a program code or in other product forms, which is not limited in the embodiments 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.
  • 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.
  • target detection rules the built-in alternative detection rules
  • 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.
  • the intrusion detection analysis engine 412 only needs to follow the traversed target detection rules to determine whether the intrusion event corresponding to the target detection rule has occurred by whether the required target data can be extracted from the full amount of log data and whether the extracted target data matches.
  • the corresponding relationship between an intrusion event, a detection method for the intrusion event, and related log lines may be as follows:
  • Intrusion event name The OTA microservice delivery time is inconsistent with the local update time on the vehicle side, and the vehicle may have flashed the system locally;
  • the OTA microservice will send update-related information to the vehicle side, and the vehicle side will start the OTA process after receiving the relevant information.
  • the time when the OTA microservice sends the message should be synchronized with the time when the vehicle side receives the message. If it is found that the time when the OTA microservice sends the message is too different from the time when the vehicle side receives the message, it is very likely that the vehicle-cloud communication has been hijacked by an attacker, and the attacker uses replay and other attack methods to attack.
  • Intrusion event name OTA download link was replaced
  • the OTA microservice will send update-related information to the vehicle side, and the vehicle side will start the OTA process after receiving the relevant information.
  • the download link in the message sent by the OTA microservice and the download link received by the vehicle side should be the same. If the two links are different, it is likely that they have been hijacked by attackers and the download link has been replaced.
  • a log line containing the following fields is detected in the operation log of the vehicle: begin call Vdc ua proxy InformDCUrl interface;
  • intrusion events are an example of the correspondence between intrusion events and detection methods of intrusion events, taking intrusion events A and B as examples, but not any limitation.
  • the storage module 414 can be used to store the detection results of different intrusion events of different vehicles, and can classify and store all the intrusion events.
  • the storage module 414 may also be associated with an output device.
  • the HMI of the output device may obtain the detection results of related events from the storage module 414 and output them so that front-end users can confirm events, trace intrusion sources, and perform emergency response for related events.
  • the HMI associated with the storage module 414 can output a first interface as shown in Figure 7, which can be used to present statistical results of intrusion events that have occurred up to a certain time (for example, 2022-7-28 10:58:40) from at least one dimension.
  • a certain time for example, 2022-7-28 10:58:40
  • 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.
  • 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 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 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 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 such as the threat level classification of each intrusion event: for example, 455 low risk events, 342
  • the at least one dimension may include a scenario dimension, including but not limited to at least one of the following: unified diagnostic services (UDS) diagnostic scenario, system network scenario, vehicle network scenario, OTA scenario, Bluetooth key scenario, system certificate scenario, vehicle system scenario, 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.
  • the at least one dimension may include a regional dimension, including but not limited to regions divided by different granularities such as provinces/municipalities, cities, counties, and districts.
  • a regional dimension including but not limited to regions divided by different granularities such as provinces/municipalities, cities, counties, and districts.
  • the vertical axis represents the identification of the province (for example, represented as province 1, province 2, ..., province 8), and the horizontal axis represents the statistical number of intrusion incidents occurring in different provinces.
  • the at least one dimension may include a vehicle model dimension, for example, represented as X1. As shown in Fig. 7, the ordinate may represent the vehicle model, and the abscissa may represent the statistical number of intrusion events involving the vehicle model.
  • the at least one dimension may include, for example, an intrusion event response dimension.
  • the horizontal axis represents time (e.g., the occurrence time 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 occurring in the corresponding time interval.
  • the at least one dimension may include a vehicle ECU dimension, such as a vehicle identification unit (VIU), a vehicle dynamics control (VDC), an automatic adjustment and continuous damping control system (CDC), a vehicle information and positioning transmission system (telematics-box, TBOX), or a vehicle-to-cloud communication.
  • a vehicle ECU dimension such as a vehicle identification unit (VIU), a vehicle dynamics control (VDC), an automatic adjustment and continuous damping control system (CDC), a vehicle information and positioning transmission system (telematics-box, TBOX), or a vehicle-to-cloud communication.
  • VDU vehicle identification unit
  • VDC vehicle dynamics control
  • CDC automatic adjustment and continuous damping control system
  • TBOX vehicle information and positioning transmission system
  • the first interface may also output the number of intrusion events of different threat levels involving each ECU. It should be understood that in FIG7 , the statistical results presented for different ECUs may also be connected to corresponding positions in the vehicle, which will not be repeated here.
  • the at least one dimension may also include a workbench dimension, which may present the number of intrusion events that have been 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 at which the event occurred.
  • a workbench dimension which may present the number of intrusion events that have been 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 at which the event occurred.
  • 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.
  • the HMI of the output device can receive the control information input on the first interface, and the control information is used to instruct the output of the intrusion detection result of the target intrusion event.
  • the second interface shown in FIG8 will be presented on the HMI of the output device, and the second interface will output the intrusion detection result of the target intrusion event, including the detailed content of at least one of the following information: event identification, event name, threat level, detection time, potential risk, intrusion attack object, intrusion detection process or intrusion detection context information.
  • an input box may also be presented in FIG8 , and the input box may be used for the front-end user to input or select confirmation information or a processing method for the intrusion event.
  • the HMI may receive a second indication information input in response to the intrusion detection result, and the second indication information is used to determine the intrusion event or to indicate a processing method for the intrusion event.
  • the processing methods for different intrusion events are different, and the embodiments of the present application do not limit this.
  • 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.
  • 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 the business level, rather than being limited to a single business node, which helps to improve the detection efficiency of intrusion events.
  • the output device associated with the server can output the statistical results of the intrusion event from at least one dimension, so as to facilitate the front-end user (such as a security expert) to promptly confirm, trace or respond to the intrusion event based on the presented information.
  • 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.
  • OTA has become a standard technology.
  • Each ECU of the vehicle can use the OTA function to download the OTA upgrade package from the OTA microservice on the server side to update its own system, thereby obtaining new functions or patching the system to improve system security.
  • the OTA function brings convenience to intelligent connected vehicles, it is also known as one of the main attack points for attackers.
  • a common attack method is to hijack the communication between the car and the cloud, and replace the download link of the OTA upgrade package to flash the malicious system into the vehicle-side ECU. Therefore, it is necessary to perform security detection on the intrusion event corresponding to this attack method.
  • the business nodes involve the vehicle side ECU and the server side OTA microservice, and the steps involved in the business process may include: the OTA microservice sends the download link of the OTA upgrade package.
  • the vehicle side receives the download link of the OTA upgrade package.
  • the vehicle side downloads the OTA upgrade package.
  • the vehicle side installs and activates the OTA upgrade package.
  • the data collection module of the vehicle-side ECU or OTA microservice can collect the operation log.
  • the data collection module of the server can collect the operation log 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 part or all of the alternative detection rules of the built-in detection rule set based on the obtained log data. Based on the matched target detection rule, the intrusion detection analysis engine can extract the 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.
  • the target data does not meet the corresponding detection conditions (such as the same URL content), it is recognized 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.
  • the detailed analysis details of the operation log can be found in the description of the detection method combined with the intrusion event A in the previous text, which will not be repeated here.
  • the owner 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 sends a door opening request to open the door.
  • an attack mode as shown in Figure 10 can be obtained. The attacker hijacks the Bluetooth communication between the owner APP and the vehicle, and replays the message after the owner leaves the vehicle, thereby illegally opening the door.
  • the Bluetooth key scenario may include the following steps:
  • S1 The car owner APP requests the cloud microservice for login verification.
  • the cloud microservice sends the Bluetooth key to the car owner's APP.
  • S5 The owner's APP uses the Bluetooth key to request the vehicle to open the door. During this process, the attacker may hijack the Bluetooth communication between the owner's APP and the vehicle in S6 and obtain the Bluetooth key.
  • S7 If the owner's APP does not receive a response within a timeout, the door opening process is closed.
  • S8 The attacker replays the door opening information to request to open the door.
  • the intrusion detection method shown in Figure 11 can be executed:
  • 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 and analysis engine.
  • the intrusion detection and 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 and 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.
  • intrusion detection can be performed step by step according to the priorities. For example, for a vehicle, each time an intrusion detection is performed, a Bluetooth key replay attack detection is performed first. Then, when it is confirmed that a Bluetooth key replay attack exists, the vehicle itself has been stolen and is in an unsafe state. Other services implemented based on the vehicle are all unsafe, and there is no need to perform intrusion detection in other scenarios.
  • the detection rule set built into the server can be used to parse the log data of multiple sources of the target business of the same vehicle to detect intrusion events.
  • This method can effectively identify intrusion attacks on vehicle-level services from the business level, and is not limited to a single business node.
  • the method can be decoupled from the normal business of each business node and will not affect the normal implementation of the business of the business node. Since the security defense level of the server is higher than that of the vehicle ECU, the risk of the intrusion detection analysis engine being attacked will also be greatly reduced.
  • the front-end user can view the details of the intrusion event, and can obtain and present the relevant context information of the intrusion event from the storage module, which is convenient for the front-end user to confirm, trace the source and respond to the intrusion event urgently.
  • the entrance provided by the server for configuring the alternative detection rules can also facilitate the technicians to update the detection rule set built into the intrusion detection analysis engine in a timely manner according to the update of the attack means or the missed detection information of the historical intrusion data.
  • the intrusion detection method described in the embodiment of the present application can also be used in the IOT field.
  • the same or similar method as described above in the vehicle networking scenario can be used to parse the log data of multiple sources of the same object to determine whether an intrusion event has occurred.
  • the implementation details can be found in the relevant description above and will not be repeated here.
  • the 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.
  • the relevant features can be found in the above method embodiment and will not be repeated here.
  • the communication device 1200 may include: an acquisition unit 1201, 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 1202, configured to determine whether the intrusion event occurs according to 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 detection method for an intrusion event associated with the target service.
  • an acquisition unit 1201 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 1202 configured to determine whether the intrusion event occurs according to 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 detection method for an intrusion event associated with the target service.
  • the embodiment of the present application further provides an HMI, as shown in FIG13 , the HMI 1300 may include: a communication unit 1301, used to receive an intrusion detection result of a target intrusion event, the intrusion detection result is used to indicate at least one of the following information of the target intrusion event: event identification, event name, threat level, detection event, potential risk, intrusion attack object, intrusion detection process or intrusion detection context information; an output unit 1302, used to output the intrusion detection result of the target intrusion event.
  • a communication unit 1301 used to receive an intrusion detection result of a target intrusion event
  • the intrusion detection result is used to indicate at least one of the following information of the target intrusion event: event identification, event name, threat level, detection event, potential risk, intrusion attack object, intrusion detection process or intrusion detection context information
  • an output unit 1302 used to output the intrusion detection result of the target intrusion event.
  • the division of the units in the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated.
  • 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 instructions are stored in the memory.
  • the processor calls the instructions stored in the memory to implement any of the above methods or realize the functions of the units of the device, wherein 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 inside the device or a memory outside the device.
  • CPU central processing unit
  • microprocessor a microprocessor
  • the units in the device may be implemented in the form of hardware circuits, and the functions of some or all of the units may be implemented by designing the hardware circuits, and the hardware circuits may be understood as one or more processors; for example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC), and the functions of some or all of the above units may be implemented by designing the logical relationship of the components in the circuit; for another example, in another implementation, the hardware circuit may be implemented by a programmable logic device (PLD), and a field programmable gate array (FPGA) may be used as an example, which may include a large number of logic gate circuits, and the connection relationship between the logic gate circuits may be configured by a configuration file, so as to implement the functions of some or all of the above units. All units of the above devices may be implemented in the form of a processor calling software, or in the form of hardware circuits, or in part by a processor calling software, and the rest by hardware circuits.
  • ASIC application-specific integrated circuit
  • FPGA field programm
  • the processor is a circuit with signal processing capability.
  • the processor may be a circuit with instruction reading and running capability, such as a CPU, a microprocessor, a graphics processing unit (GPU) (which may be understood as a microprocessor), or a digital signal processor (DSP), etc.; 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 may be fixed or reconfigurable, such as a hardware circuit implemented by an ASIC or PLD, such as an FPGA.
  • the process of the processor loading a configuration document to implement the hardware circuit configuration may be understood as the process of the processor loading instructions to implement the functions of some or all of the above units.
  • it may also be a hardware circuit designed for artificial intelligence, which may 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.
  • NPU neural network processing unit
  • TPU tensor processing unit
  • 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.
  • processors or processing circuits
  • the units in the above device 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).
  • SOC may include at least one processor for implementing any of the above methods or implementing the functions of each unit of the device.
  • the type of the at least one processor may be different, for example, including a CPU and an FPGA, a CPU and an artificial intelligence processor, a CPU and a GPU, etc.
  • the device 1400 shown in FIG14 includes at least one processor 1410 and a communication interface 1430.
  • a memory 1420 may also be included.
  • connection medium between the processor 1410 and the memory 1420 is not limited in the embodiment of the present application.
  • the processor 1410 may perform data transmission through the communication interface 1430 when communicating with other devices.
  • the processor 1410 in FIG. 14 can call the computer execution instructions stored in the memory 1420 so that the device 1400 can execute any of the above method embodiments.
  • 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.
  • the processor may be coupled to the memory through an interface.
  • the chip system may also directly include a memory, in which a computer program or computer instructions are stored.
  • the memory may be a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memory.
  • the nonvolatile 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.
  • RAM synchronous RAM
  • SDRAM synchronous DRAM
  • DDR SDRAM double data rate SDRAM
  • ESDRAM enhanced SDRAM
  • SLDRAM synchronous link DRAM
  • DR RAM direct rambus RAM
  • An embodiment of the present application also 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.
  • the processor is an integrated circuit chip with signal processing capabilities.
  • 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 chip (system on chip, SoC), a CPU, a network processor (network processor, NP), a microcontroller (micro controller unit, MCU), a PLD or other integrated chip, which can implement or execute the methods, steps and logic block diagrams disclosed in the embodiment 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 embodiment of the present application can be directly embodied as a hardware decoding processor to perform, or the hardware and software modules in the decoding processor can be combined to perform.
  • the software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc.
  • the storage medium is located in a memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.
  • an embodiment of the present application provides a computer-readable storage medium, which stores a program code.
  • the program code runs on the computer, the computer executes the above method embodiment.
  • an embodiment of the present application provides a computer program product.
  • the computer program product When the computer program product is run on a computer, the computer is enabled to execute the above method embodiment.
  • the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware.
  • the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.
  • 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 work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured 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.
  • These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Data Mining & Analysis (AREA)
  • Telephonic Communication Services (AREA)

Abstract

一种入侵检测方法、装置和系统，涉及信息安全技术领域。该方法可以包括：获取至少两个业务节点的运行日志，所述至少两个业务节点关联目标业务；根据所述至少两个业务节点的运行日志以及目标检测规则，确定是否发生所述入侵事件，所述目标检测规则用于描述所述目标业务关联的入侵事件的检测方法。该方法有助于准确地检测针对车辆业务的入侵攻击。

Description

一种入侵检测方法、装置和系统 技术领域
本申请涉及信息安全技术领域，特别涉及一种入侵检测方法、装置和系统。
背景技术
随着科技的发展和进步，车辆的智能网联化已经逐步成为车辆领域研究的重点之一。但同时，智能化、网联化发展使得车辆领域的应用环境更加特殊、管理更加困难，智能网联化所面临的网络安全威胁也更加突出。由于高度网联化，在实现车辆业务的过程中，业务可能涉及的车辆内部电子控制单元(electronic control unit，ECU)、云端服务器、车主智能终端上运行的应用程序(application，APP)均成为潜在入侵攻击对象。
因此，为保障车辆业务的安全性，如何对车辆业务的网络安全入侵(intrusion)进行准确的检测(detection)，仍为亟需解决的重要问题。
发明内容
本申请提供一种入侵检测方法、装置和系统，有助于准确地检测针对车辆业务的入侵攻击。
第一方面，本申请实施例提供一种入侵检测方法，该方法可由服务器执行，该服务器可以实现为通信装置，该通信装置可以是独立设备，也可以是设备中的芯片或部件，还可以是软件，可以部署在云端、或路侧设备、或远端服务器、或本地服务器等，本申请实施例对该服务器的产品形态以及部署方式不做限定。
该方法可以包括：获取至少两个业务节点的运行日志，所述至少两个业务节点关联目标业务；根据所述至少两个业务节点的运行日志以及目标检测规则，确定是否发生所述入侵事件，所述目标检测规则用于描述所述目标业务关联的入侵事件的检测方法。
通过上述方法，该至少两个业务节点为共同实现目标业务的节点，服务器可以通过对该至少两个业务节点的运行日志进行解析，来检测是否发生入侵事件。该方法可以从业务层面，对涉及多端或多系统的业务节点进行全面的入侵检测，而不局限于单个业务节点或系统，有助于提升入侵事件的检测效率。
示例地，本申请实施例的目标业务可以是车联网业务(或称为车辆业务)，包括但不限于：车辆的空中下载技术(over-the-air，OTA)升级相关的业务，例如OTA内容确认、下载OTA升级包、安装OTA升级包、激活OTA升级包；车辆蓝牙钥匙业务；车辆远程控制业务等。用于实现目标业务的业务节点可以包括以下至少一个：服务器、智能终端上运行的应用程序(application，APP)、车辆内部的电子控制单元(electronic control unit，ECU)等。本申请实施例对该目标业务以及实现目标业务的业务节点不做限定。
可以理解的是，本申请实施例的入侵检测方法还可以扩展地应用于其它领域，例如与车联网业务具有相似特性的物联网(internet of things，IOT)领域，涉及的业务例如可以包括但不限于智能家居业务，业务节点可以包括以下至少一个：智能网关、智能门锁、智能灯具、房主APP等多个终端设备，在此不再赘述。
可以理解的是，本申请实施例中，运行日志仅是对服务器对多端或多系统的信息整合 的示例而非限定，在它实施例中，该运行日志可以替换为其它能够表征业务运行情况的信息，本申请实施例对此不做限定。
结合第一方面，在一种可能的设计中，所述目标检测规则包括用于指示所述入侵事件的检测字段以及至少一个检测条件的规则，所述检测字段表征所述目标业务的潜在入侵攻击行为的特征，所述根据所述至少两个业务节点的运行日志以及目标检测规则，确定是否发生所述入侵事件，包括：根据所述目标检测规则指示的检测字段，从所述至少两个业务节点的运行日志中获取目标数据；在所述运行日志和所述目标数据满足所述至少一个检测条件中的所有检测条件时，确定未发生入侵事件；在所述运行日志或所述目标数据不满足所述至少一个检测条件中的任一检测条件时，确定发生入侵事件。
通过上述方法，服务器可以通过预设的检测规则，来对所获取得到的至少两个业务节点的运行日志进行解析，通过运行日志和运行日志中的目标数据与检测规则的匹配度检测是否发生入侵事件。
可以理解的是，本申请实施例中，检测条件的具体内容会影响检测结果的判定。例如，在一些设计中，与前文描述相反地，根据检测条件的内容，还可以设置为：在所述运行日志和所述目标数据满足所述至少一个检测条件中的所有检测条件时，确定发生入侵事件；在所述运行日志或所述目标数据不满足所述至少一个检测条件中的任一检测条件时，确定未发生入侵事件。
对于不同入侵事件的检测方式可以不同。在一些实施例中，针对不同的入侵事件，还可以设置为：针对一些入侵事件，在所述运行日志和所述目标数据满足所述至少一个检测条件中的所有检测条件时，确定未发生入侵事件；在所述运行日志或所述目标数据不满足所述至少一个检测条件中的任一检测条件时，确定发生入侵事件。针对另一些入侵事件，在所述运行日志和所述目标数据满足所述至少一个检测条件中的所有检测条件时，确定发生入侵事件；在所述运行日志或所述目标数据不满足所述至少一个检测条件中的任一检测条件时，确定未发生入侵事件。
也就是说，对于入侵事件的检测，需要根据检测规则以及检测条件的具体内容而调整，本申请实施例对此不做限定。
结合第一方面，在一种可能的设计中，所述入侵事件的检测字段包括时间戳，所述目标数据包括所述时间戳对应的时间值，所述至少一个检测条件包括：从所述至少两个业务节点的运行日志中获取的时间值的差值小于或等于第一阈值。相应地，服务器在进行入侵检测时，可以在获得的时间值的差值满足该检测条件时，确定未发生入侵检测事件；在获得的时间值的差值不满足该检测条件时，确定发生入侵检测事件。
通过上述方法，入侵事件的检测字段可以包括时间戳，在进行入侵检测时，服务器可以比对从至少两个业务节点获得的运行日志中提取的时间戳信息，若两两比对相差较大，则表明某个业务节点可能存在入侵。
可以理解的是，本申请实施例中，在检测字段包括时间戳时，上述至少一个检测条件可以替换为：从所述至少两个业务节点的运行日志中获取的时间值的差值大于或等于第二阈值。该第二阈值可以大于或等于第一阈值。相应地，服务器在进行入侵检测时，可以在获得的时间值的差值满足该检测条件时，确定发生入侵检测事件；在获得的时间值的差值不满足该检测条件时，确定未发生入侵检测事件。
结合第一方面，在一种可能的设计中，所述入侵事件的检测字段包括统一资源定位符 URL，所述目标数据包括URL数据，所述至少一个检测条件包括：从所述至少两个业务节点的运行日志中获取的URL数据的内容相同。相应地，服务器在进行入侵检测时，可以在获得的URL数据满足该检测条件时，确定未发生入侵检测事件；在获得的URL数据不满足该检测条件时，确定发生入侵检测事件。
可以理解的是，本申请实施例中，在检测字段包括URL时，上述至少一个检测条件可以替换为：从所述至少两个业务节点的运行日志中获取的URL数据的内容不相同。相应地，服务器在进行入侵检测时，可以在获得的URL数据满足该检测条件时，确定发生入侵检测事件；在获得的URL数据不满足该检测条件时，确定未发生入侵检测事件。
结合第一方面，在一种可能的设计中，所述入侵事件的检测字段包括操作标识，所述操作标识关联执行所述目标业务包含的操作，所述目标数据包括所述操作标识对应的数据，所述至少一个检测条件包括：从所述至少两个业务节点的运行日志中获取的操作标识对应的数据的内容相同。服务器在进行入侵检测时，可以在获得的操作标识对应的数据满足该检测条件时，确定未发生入侵检测事件；在获得的操作标识对应的数据不满足该检测条件时，确定发生入侵检测事件。
可以理解的是，本申请实施例中，在检测字段包括操作标识时，上述至少一个检测条件可以替换为：从所述至少两个业务节点的运行日志中获取的操作标识对应的数据的内容不相同。相应地，服务器在进行入侵检测时，可以在获得的操作标识对应的数据满足该检测条件时，确定未发生入侵检测事件；在获得的操作标识对应的数据不满足该检测条件时，确定发生入侵检测事件。
结合第一方面，在一种可能的设计中，所述方法还包括：根据所述运行日志，从检测规则集合中获取所述目标检测规则，其中，所述检测规则集合包括预先为所述目标业务的多种潜在入侵攻击行为配置的备选检测规则，所述备选检测规则用于描述所述潜在入侵攻击行为对应的入侵事件的检测方法。
通过上述方法，服务器可以预设检测规则集合，并利用该检测规则集合中的目标检测规则对获得的运行日志进行解析，以确定是否发生入侵事件。
可以理解的是，本申请实施例中，检测规则集合可以是预先根据已知且有限的入侵攻击手段编写的，该检测规则集合可以是以程序代码的方式存储在服务器，本申请实施例对该检测规则集合以及任何备选检测规则的实现方式不做限定。
结合第一方面，在一种可能的设计中，所述目标检测规则包括所述检测规则集合中的全部备选检测规则；或者，所述目标检测规则包括所述检测规则集合中与所述目标业务关联的备选检测规则。
结合第一方面，在一种可能的设计中，所述方法还包括：接收配置信息，所述配置信息用于修改所述检测规则集合中的备选检测规则，和/或，所述配置信息用于在所述检测规则集合中新增备选检测规则。可以理解的是，本申请实施例中，“修改”可以包括对备选检测规则的内容修改，或者删除备选检测规则。
结合第一方面，在一种可能的设计中，所述方法还包括：输出所述入侵事件的检测结果。在一种可选的实施方式中，可以是在所述服务器关联的输出设备输出所述入侵事件的检测结果。
结合第一方面，在一种可能的设计中，所述入侵事件的检测结果包括所述入侵事件的以下至少一项信息：事件标识、事件名称、威胁等级、检测时间、潜在风险、入侵攻击对 象、入侵检测流程或者入侵检测上下文信息。示例地，该检测结果可以采用以下至少一种呈现方式输出：文本、图像、线条。
结合第一方面，在一种可能的设计中，所述目标业务包括车辆业务，所述至少两个业务节点包括：所述服务器、目标车辆或者管理所述目标车辆的用户的用户设备。需要说民的是，此处描述的车辆业务是对车联网业务的泛称，该车联网业务可以包括但不限于：车辆的OTA升级相关的业务，例如OTA内容确认、下载OTA升级包、安装OTA升级包、激活OTA升级包；车辆蓝牙钥匙业务；车辆远程控制业务等。用于实现目标业务的业务节点可以包括以下至少一个：服务器、智能终端上运行的应用程序(application，APP)、车辆内部的电子控制单元(electronic control unit，ECU)等。本申请实施例对该目标业务以及实现目标业务的业务节点不做限定。
第二方面，本申请实施例还提供了一种入侵检测方法，该方法可以由人机交互界面(human machine interaction，HMI)(或称为服务器前端)实现，该人机交互界面例如可以是服务器关联的电子设备的HMI，可以用于输出来自服务器的信息，信息内容的呈现方式可以包括但不限于图像、文本、线条等。在一个可选的实施方式中，该HMI还可以具有或者关联于输入设备，可以通过输入设备接收来自前端用户(例如安全专家)的信息，本申请实施例对此不做限定。
该方法可以包括：接收目标入侵事件的入侵检测结果，所述入侵检测结果用于指示所述目标入侵事件的以下至少一项信息：事件标识、事件名称、威胁等级、检测时间、潜在风险、入侵攻击对象、入侵检测流程或者入侵检测上下文信息；输出所述目标入侵事件的入侵检测结果。
通过上述方法，HMI可以对目标入侵事件的入侵检测结果进行输出展示，有助于前端用户查看该入侵检测结果，并利用相关上下文信息进行目标入侵事件的确认、溯源和响应等。
结合第二方面，在一种可能的设计中，所述方法还可以包括：接收响应于所述入侵检测结果输入的第二指示信息，其中，所述第二指示信息用于确认所述入侵事件，或者所述第二指示信息用于指示对所述入侵事件的处理方法。
通过上述方法，HMI可以通过输入设备接收第二指示信息，该第二指示信息可以是前端用户下发的，可以用于进行目标入侵事件的确认、溯源和响应等。
结合第二方面，在一种可能的设计中，所述方法还包括：输出第一界面，所述第一界面用于从至少一种维度呈现入侵事件的统计结果；接收在所述第一界面输入的控制信息，所述控制信息用于指示输出所述目标入侵事件的入侵检测结果。
通过上述方法，HMI可以从至少一种维度呈现入侵事件的统计结果，前端用户可以根据自身需求向HMI输入控制信息，从而触发对目标入侵事件的入侵检测结果的呈现。
第三方面，本申请实施例提供了一种通信装置，该通信装置例如可以部署在服务器，该通信装置可以包括：获取单元，用于获取至少两个业务节点的运行日志，所述至少两个业务节点关联目标业务；确定单元，用于根据所述至少两个业务节点的运行日志以及目标检测规则，确定是否发生所述入侵事件，所述目标检测规则用于描述所述目标业务关联的入侵事件的检测方法。
结合第三方面，在一种可能的设计中，所述目标检测规则包括用于指示所述入侵事件的检测字段以及至少一个检测条件的规则，所述检测字段表征所述目标业务的潜在入侵攻 击行为的特征，所述确定单元用于：根据所述目标检测规则指示的检测字段，从所述至少两个业务节点的运行日志中获取目标数据；在所述运行日志和所述目标数据满足所述至少一个检测条件中的所有检测条件时，确定未发生入侵事件；在所述运行日志或所述目标数据不满足所述至少一个检测条件中的任一检测条件时，确定发生入侵事件。
结合第三方面，在一种可能的设计中，所述入侵事件的检测字段包括时间戳，所述目标数据包括所述时间戳对应的时间值，所述至少一个检测条件包括：从所述至少两个业务节点的运行日志中获取的时间值的差值小于或等于第一阈值。
结合第三方面，在一种可能的设计中，所述入侵事件的检测字段包括统一资源定位符URL，所述目标数据包括URL数据，所述至少一个检测条件包括：从所述至少两个业务节点的运行日志中获取的URL数据的内容相同。
结合第三方面，在一种可能的设计中，所述入侵事件的检测字段包括操作标识，所述操作标识关联执行所述目标业务包含的操作，所述目标数据包括所述操作标识对应的数据，所述至少一个检测条件包括：从所述至少两个业务节点的运行日志中获取的操作标识对应的数据的内容相同。
结合第三方面，在一种可能的设计中，所述获取单元还用于：根据所述运行日志，从检测规则集合中获取所述目标检测规则，其中，所述检测规则集合包括预先为所述目标业务的多种潜在入侵攻击行为配置的备选检测规则，所述备选检测规则用于描述所述潜在入侵攻击行为对应的入侵事件的检测方法。
结合第三方面，在一种可能的设计中，所述目标检测规则包括所述检测规则集合中的全部备选检测规则；或者，所述目标检测规则包括所述检测规则集合中与所述目标业务关联的备选检测规则。
结合第三方面，在一种可能的设计中，所述通信装置还包括收发单元，用于接收配置信息，所述配置信息用于修改所述检测规则集合中的备选检测规则，和/或，所述配置信息用于在所述检测规则集合中新增备选检测规则。
结合第三方面，在一种可能的设计中，所述通信装置还包括输出单元，用于在所述服务器关联的输出设备输出所述入侵事件的检测结果。
结合第三方面，在一种可能的设计中，所述入侵事件的检测结果包括所述入侵事件的以下至少一项信息：事件标识、事件名称、威胁等级、检测时间、潜在风险、入侵攻击对象、入侵检测流程或者入侵检测上下文信息。
结合第三方面，在一种可能的设计中，所述目标业务包括车辆业务，所述至少两个业务节点包括：所述服务器、目标车辆或者管理所述目标车辆的用户的用户设备。
第四方面，本申请实施例提供了一种人机交互界面HMI，包括：通信单元，用于接收目标入侵事件的入侵检测结果，所述入侵检测结果用于指示所述目标入侵事件的以下至少一项信息：事件标识、事件名称、威胁等级、检测时间、潜在风险、入侵攻击对象、入侵检测流程或者入侵检测上下文信息；输出单元，用于输出所述目标入侵事件的入侵检测结果。
结合第四方面，在一种可能的设计中，所述通信单元还用于接收响应于所述入侵检测结果输入的第二指示信息，其中，所述第二指示信息用于确认所述入侵事件，或者所述第二指示信息用于指示对所述入侵事件的处理方法。
结合第四方面，在一种可能的设计中，所述输出单元还用于输出第一界面，所述第一 界面用于从至少一种维度呈现入侵事件的统计结果；所述通信单元还用于接收在所述第一界面输入的控制信息，所述控制信息用于指示输出所述目标入侵事件的入侵检测结果。
第五方面，本申请实施例提供了一种通信装置，所述通信装置包括：通信接口，用于与其他装置进行通信；处理器，与所述通信接口耦合，使得所述通信装置执行上述第一方面以及第一方面任一可能设计所述的方法，或者执行上述第二方面以及第二方面任一可能设计所述的方法。
第六方面，本申请实施例提供了一种通信系统，包括服务器，所述服务器用于实现如上述第一方面以及第一方面任一可能设计所述的方法。
结合第六方面，在一种可能的设计中，所述通信系统还包括人机交互界面HMI，所述HMI用于实现上述第二方面以及第二方面任一可能设计所述的方法。
第七方面，本申请实施例提供了一种芯片系统，包括至少一个处理器和接口电路，所述处理器用于通过所述接口电路执行指令和/或数据的交互，使得所述芯片系统执行上述第一方面以及第一方面任一可能设计所述的方法，或者执行上述第二方面以及第二方面任一可能设计所述的方法。
第八方面，本申请实施例提供了一种计算机可读存储介质，包括程序或指令，当所述程序或指令被执行时，上述第一方面以及第一方面任一可能设计所述的方法被执行，或者上述第二方面以及第二方面任一可能设计所述的方法被执行。
第九方面，本申请实施例提供了一种计算机程序产品，当计算机读取并执行所述计算机程序产品时，使得计算机执行上述第一方面以及第一方面任一可能设计所述的方法，或者执行上述第二方面以及第二方面任一可能设计所述的方法。
第十方面，本申请实施例提供了一种芯片，包括处理器，所述处理器与存储器耦合，用于执行所述存储器中存储的计算机程序或指令，当所述计算机程序或指令被执行时，实现上述第一方面或第一方面任一可能设计所述的方法，或者执行上述第二方面以及第二方面任一种可能设计所述的方法。
本申请实施例在上述各方面提供的实现的基础上，还可以进行进一步组合以提供更多实现。
上述第三方面至第十方面中任一方面中的任一可能实现方式可以达到的技术效果，可以相应参照上述第一方面中任一方面中的任一可能实现方式可以达到的技术效果描述，重复之处不予论述。
附图说明
图1示出了本申请实施例适用的应用场景的示意图；
图2示出了本申请实施例适用的系统架构的示意图；
图3示出了本申请实施例的入侵检测方法的流程示意图；
图4示出了本申请实施例适用的系统架构的示意图；
图5示出了本申请实施例的日志收集原理的示意图；
图6示出了本申请实施例的检测规则集合的生成原理示意图；
图7示出了本申请实施例的第一界面的示意图；
图8示出了本申请实施例的第二界面的示意图；
图9示出了本申请实施例的OTA场景下的入侵检测方法的流程示意图；
图10示出了本申请实施例的蓝牙钥匙场景的攻击示意图；
图11示出了本申请实施例的蓝牙钥匙场景下的入侵检测方法的流程示意图；
图12示出了本申请实施例的通信装置的结构示意图；
图13示出了本申请实施例的人机交互界面的结构示意图；
图14示出了本申请实施例的通信装置的结构示意图。
具体实施方式
为了便于理解本申请实施例的技术方案，下面先对涉及的部分用语进行说明。
1、用户：
本申请实施例述及的“用户”是使用车辆的人，该用户可以包括车主，也可以包括被车主授权使用车辆的其他人，比如车主的亲属、朋友等。应理解，对于无人驾驶车辆，用户可以是虚拟用户，也可以是管理该车辆的真实人物，本申请实施例对此不做限定。
2、用户设备：
一般指用户所使用的电子设备，例如用户使用的车辆的车载终端或者用户的智能终端，例如手机、平板电脑等。对于无人驾驶车辆，用户设备可以是该车辆的车载终端；也可以是放置在该车辆上的移动终端，例如手机、平板电脑等；还可以是与该车辆关联的其它电子设备，例如车辆管理人员操控的电子设备，包括但不限于台式计算机、笔记本电脑、手机、平板电脑等；本申请实施例对用户设备的产品形态不做限定。
3、业务节点：
一般指用于实现业务的通信节点。
示例地，业务例如可以包括车联网业务(或称为车辆业务)。业务节点可以包括但不限于以下至少一个：服务器、用户的智能终端、用户的智能终端上运行的应用程序(application，APP)、车辆内部的电子控制单元(electronic control unit，ECU)等。本申请实施例对业务以及实现业务的业务节点的产品形态或者部署方式均不做限定。
4、运行日志：
网络设备、系统及服务程序等，在运作时都会产生一个称为log的事件记录，即运行日志。运行日志为指定对象的操作和其操作结果按事件的有序集合。运行日志的内容可以是以日志文件的形式收集和记录的，可以包括多个日志行，每一行日志都可以记载日期、时间、执行者及动作等相关操作的描述。
本申请实施例中，运行日志用于从安全方面进行入侵检测，因此运行日志还可以称为安全日志。
5、入侵事件(或称为攻击事件)：
是指通过网络或其它技术手段，利用信息系统的配置缺陷、协议缺陷、程序缺陷或使用暴力攻击对信息系统实施攻击或入侵，并造成信息系统异常、或对信息系统当前运行造成潜在危害的信息安全事件。
本申请实施例中，入侵事件与业务关联，在实现业务的过程中，任一点位均可能被攻击，因此，业务与入侵事件的关系可以是一对多，即一种业务可以涉及多个入侵事件。相似地，不同业务也可能发生相同的入侵事件，因此，业务与入侵事件的关系也可以是多对一，即一个入侵事件可以涉及多个业务。在一些实施例中，业务还可以划分为多个子业务，每个子业务也可以涉及多个入侵事件。本申请实施例对业务与入侵事件的对应关系不做限 定。
6、检测规则：
检测规则用于描述业务关联的入侵事件的检测方法。一般地，一条检测规则对应一个入侵事件。
本申请实施例中，服务器可以包括多个入侵事件的检测规则，汇集为检测规则集合。每个检测规则可以是以程序代码的方式配置在服务器，也可以以其它形式配置在服务器，本申请实施例对检测规则的实现方式不做限定。
其中，为了便于区分，可以将检测规则集合中的每个待使用的检测规则称为备选检测规则，对运行日志进行解析所使用到的检测规则称为目标检测规则。
7、检测字段：
检测字段用于表征业务的潜在入侵攻击行为的特征。示例地，检测字段可以包括以下至少一项：时间戳、URL、操作标识。
本申请实施例提供了一种入侵检测方法、装置和系统，服务器可以通过对至少两个业务节点的运行日志进行解析，来检测是否发生入侵事件。该方法可以从业务层面，对涉及多端或多系统的业务节点进行全面的入侵检测，而不局限于单个业务节点或系统，有助于提升入侵事件的检测效率。其中，方法和装置是基于同一技术构思的，由于方法及装置解决问题的原理相似，因此装置与方法的实施可以相互参见，重复之处不再赘述。
需要说明的是，本申请实施例中的入侵检测方法可以应用于车联网，如车-万物(vehicle to everything，V2X)、车间通信长期演进技术(long term evolution-vehicle，LTE-V)、车辆-车辆(vehicle to vehicle，V2V)等。例如可以应用于具有驾驶移动功能的车辆，或者车辆中具有驾驶移动功能的其它装置。该其它装置包括但不限于：车载终端、车载控制器、车载模块、车载模组、车载部件、车载芯片、车载单元、车载雷达或车载摄像头等其他传感器，车辆可通过该车载终端、车载控制器、车载模块、车载模组、车载部件、车载芯片、车载单元、车载雷达或车载摄像头，实施本申请实施例提供的方法。当然，本申请实施例中的控制方案还可以用于除了车辆之外的其它具有移动控制功能的智能终端，或设置在除了车辆之外的其它具有移动控制功能的智能终端中，或设置于该智能终端的部件中。该智能终端可以为智能运输设备、智能家居设备、机器人等。例如包括但不限于智能终端或智能终端内的控制器、芯片、雷达或摄像头等其它传感器、以及其它部件等。
需要说明的是，本申请实施例中“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a和b,a和c,b和c,或a和b和c，其中a,b,c可以是单个，也可以是多个。
以及，除非有特别说明，本申请实施例提及“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的优先级或者重要程度。例如，第一用户信息、第二用户信息，只是为了区分不同时期或者不同方式获得的用户信息，而不是表示这两个用户信息的内容、优先级或者重要程度等的不同。
为了便于理解，下面结合附图及实施例进行介绍。
图1示出了本申请实施例适用的应用场景的示意图。在该应用场景中，可以包括服务器200和至少一个用户设备(user equipment，UE)100(例如用户设备100_1、用户设备100_2等)。服务器200和该至少一个用户设备100可以通过网络进行通信。在一个实施例中，该服务器200还可以通过虚拟机来实现。
示例地，该至少一个用户设备100可以包括车辆。如图2所示，车辆的部分或所有功能受车载终端150控制。车载终端150可以包括至少一个处理器151，处理器151可以执行存储在例如存储器152这样的非暂态计算机可读介质中的指令153。在一些实施例中，车载终端150还可以是采用分布式方式控制车辆的个体组件或子系统的多个计算设备。
处理器151可以是任何常规的处理器，诸如中央处理单元(central processing unit，CPU)。替选地，处理器151还可以包括诸如图像处理器(graphic process unit，GPU)，现场可编程门阵列(field programmable gate array，FPGA)、片上系统(system on chip，SOC)、专用集成芯片(application specific integrated circuit，ASIC)或它们的组合。
除了指令153以外，存储器152还可存储数据，例如道路地图、路线信息，车辆的位置、方向、速度以及其它的车辆数据，车辆的各个ECU的运行日志，以及其他信息。这些信息可在车辆在自主、半自主和/或手动模式中操作期间被车辆和车载终端150使用。应理解，图2中车辆的结构不应理解为对本申请实施例的限制。
在一种可选的实现方式中，上述车辆可以为轿车、卡车、摩托车、公共汽车、船、飞机、直升飞机、割草机、娱乐车、游乐场车辆、施工设备、电车、高尔夫球车、火车等，本申请实施例不做特别的限定。
需要说明的是，图2中示出的车载终端150仅为说明车辆侧的用于实现车辆侧的计算功能的装置的示例而非任何限定，该计算功能可以由至少一个用户设备100上的独立装置实现，也可以由处理器151实现，本申请实施例对此不做限定。
图3示出了本申请实施例的入侵检测方法的流程示意图。其中，该方法可由图1或图2所示的服务器和至少一个用户设备(例如车辆)协同实现，如图3所示，该方法可以包括以下步骤：
S310：服务器获取至少两个业务节点的运行日志。
本申请实施例中，该至少两个业务节点是关联目标业务的通信节点。运行日志是业务节点在实现目标业务的过程中产生和收集的信息记录，用于描述业务相关的操作，日志内容可以包括但不限于操作标识、操作发生的日期或时间、操作关联的其它信息等。
示例地，目标业务可以包括车辆业务，所述至少两个业务节点包括：所述服务器、目标车辆或者管理所述目标车辆的用户的用户设备。需要说明的是，此处描述的车辆业务是对车联网业务的泛称，该车联网业务可以包括但不限于：车辆的OTA升级相关的业务，例如OTA内容确认、下载OTA升级包、安装OTA升级包、激活OTA升级包；车辆蓝牙钥匙业务；车辆远程控制业务等。用于实现目标业务的业务节点可以包括以下至少一个：服务器、智能终端上运行的APP、车辆内部的ECU等。本申请实施例对该目标业务以及实现目标业务的业务节点不做限定。
服务器可以直接地或间接地与业务节点进行通信交互。在实施S310时，服务器可以实时地或周期性从该至少两个业务节点获取运行日志。其中，运行日志的获取方式，可以是业务节点主动上报运行日志，也可以是业务节点接收到来自于服务器的请求向服务器上 报服务器所请求获取的运行日志。或者，运行日志的获取方式还可以是，服务器实时地或周期性地接收来自至少两个业务节点的运行日志并保存，在需要的情况下从本地获取相应业务节点的运行日志。本申请实施例对该运行日志的获取方式不做限定。
在该至少两个业务节点向服务器发送运行日志时，来自业务节点的运行日志可以是以日志文件的方式承载在来自业务节点的通信消息中，该日志文件例如可以完整地记录业务节点在前一次上报时刻至本次上报时刻(该时间间隔例如可以称为上报周期，可以是等时间间隔，也可以是不等时间间隔)内所记录的全部日志内容，或者是按照预先配置或协商情况上报所记录日志的部分内容，本申请实施例对该运行日志的传输方式以及内容不做限定。
S320：服务器根据所述至少两个业务节点的运行日志以及目标检测规则，确定是否发生所述入侵事件。
本申请实施例中，目标检测规则可以用于描述所述目标业务关联的入侵事件的检测方法，实施S320时，服务器可以利用该目标检测规则对该至少两个业务节点的运行日志进行解析，以检测是否发生入侵事件。
作为一种可选的实施方式，实施S320之前，服务器可以是根据运行日志，从检测规则集合中获取该目标检测规则。该检测规则集合可以包括预先为不同业务的多种潜在入侵攻击行为配置的备选检测规则，备选检测规则用于描述所述潜在入侵攻击行为对应的入侵事件的检测方法。其中，服务器可以与管理人员操控的用户设备进行通信交互并接收配置信息，该配置信息可以用于修改检测规则集合中的备选检测规则，和/或，配置信息可以用于在所述检测规则集合中新增备选检测规则。各个备选检测规则可以是以程序代码的方式存储在服务器，也可以是以其它信息形式存储在服务器，本申请实施例对此不做限定。
一般，一条备选检测规则可以对应于一个入侵事件，备选检测规则可以包括用于指示入侵事件的检测字段以及至少一个检测条件的规则。其中，检测字段可以表征业务的潜在入侵攻击行为的特征，包括但不限于时间戳、统一资源定位符(uniform resource locator，URL)或者操作标识等。至少一个检测条件可以指示服务器根据入侵事件的检测字段从待解析的运行日志中获取目标数据，并根据该运行日志和目标数据是否满足该至少一个检测条件，来确定是否发生入侵事件。
示例地，目标检测规则包括所述检测规则集合中的全部备选检测规则；或者，目标检测规则可以包括所述检测规则集合中与所述目标业务关联的备选检测规则。目标检测规则可以包括用于指示入侵事件的检测字段以及至少一个检测条件的规则，目标检测规则的检测字段表征目标业务的潜在入侵攻击行为的特征。
在实施S320时，服务器可以根据目标检测规则指示的检测字段，从至少两个业务节点的运行日志中获取目标数据，服务器可以根据运行日志和目标数据是否满足该至少一个检测条件，来确定是否发生入侵事件。
例如，根据检测条件的内容，服务器可以是在运行日志和目标数据满足该至少一个检测条件中的所有检测条件时，确定未发生入侵事件；在运行日志和目标数据不满足该至少一个检测条件中的任一检测条件时，确定发生入侵事件。或者例如，根据检测条件的内容，服务器可以是在运行日志和目标数据满足该至少一个检测条件中的所有检测条件时，确定发生入侵事件；在运行日志和目标数据不满足该至少一个检测条件中的任一检测条件时，确定未发生入侵事件。
以目标检测规则指示的入侵事件的检测字段包括时间戳为例，目标数据可以包括时间戳对应的时间值。若该目标检测规则指示的检测条件包括：从至少两个业务节点的运行日志中获取的时间值的差值小于或等于第一阈值。那么，服务器在利用该目标检测规则对运行日志进行解析时，可以在从至少两个业务节点的运行日志中获取的时间值的差值小于或等于第一阈值时，即满足检测条件，确定未发生入侵事件；或者，在从至少两个业务节点的运行日志中获取的时间值的差值大于第一阈值时，即不满足检测条件，确定发生入侵事件。若该目标检测规则指示的检测条件包括：从至少两个业务节点的运行日志中获取的时间值的差值大于或等于第二阈值，第二阈值大于或等于第一阈值。那么，服务器在利用该目标检测规则对运行日志进行解析时，可以在从至少两个业务节点的运行日志中获取的时间值的差值大于或等于第二阈值时，即满足检测条件，确定发生入侵事件；或者，在从至少两个运行日志中获取的时间值的差值小于第二阈值时，即不满足检测条件，确定未发生入侵事件。
相似地，以目标检测规则指示的入侵事件的检测字段包括URL为例，目标数据可以包括URL数据。若该目标检测规则指示的检测条件包括：从所述至少两个业务节点的运行日志中获取的URL数据的内容相同。那么，服务器在利用该目标检测规则对运行日志进行解析时，可以在从至少两个业务节点的运行日志中获取的URL数据的内容相同时，即满足检测条件，确定未发生入侵事件；或者，在从至少两个业务节点中获取的URL数据的内容不相同时，即不满足检测条件，确定发生入侵事件。若该目标检测规则指示的检测条件包括：从所述至少两个业务节点的运行日志中获取的URL数据的内容不相同。那么，服务器在利用该目标检测规则对运行日志进行解析时，可以在从至少两个业务节点的运行日志中获取的URL数据的内容不相同时，即满足检测条件，确定发生入侵事件；或者，在从至少两个业务节点的运行日志中获取的URL数据的内容相同时，即不满足检测条件，确定未发生入侵事件。
相似地，以目标检测规则指示的入侵事件的检测字段包括操作标识为例，该操作标识可以关联执行目标业务包含的操作，目标数据可以包括操作标识对应的数据。若目标检测规则指示的检测条件包括：从至少两个业务节点的运行日志中获取的操作标识对应的数据的内容相同。那么，服务器在利用该目标检测规则对运行日志进行解析时，可以在从至少两个业务节点的运行日志中获取的操作标识对应的数据的内容相同时，即满足检测条件，确定未发生入侵事件；或者，在从至少两个业务节点中获取的操作标识对应的数据的内容不相同时，即不满足检测条件，确定发生入侵事件。若该目标检测规则指示的检测条件包括：从所述至少两个业务节点的运行日志中获取的操作标识对应的数据的内容不相同。那么，服务器在利用该目标检测规则对运行日志进行解析时，可以在从至少两个业务节点的运行日志中获取的操作标识对应的数据的内容不相同时，即满足检测条件，确定发生入侵事件；或者，在从至少两个业务节点的运行日志中获取的操作标识对应的数据的内容相同时，即不满足检测条件，确定未发生入侵事件。
需要说明的是，以上仅是对目标检测规则指示的检测字段以及检测条件的示例说明，在具体实施例中，并不限定目标检测规则具体指示的检测字段的内容，也不限定该目标检测规则指示的检测条件的内容和数量，在此不再赘述。
在一个可选的实施方式中，服务器还可以输出入侵事件的检测结果。具体例如，服务器可以关联输出设备，服务器可以通过该输出设备输出入侵事件的检测结果。该检测结果 例如可以包括入侵事件的以下至少一项信息：事件标识、事件名称、威胁等级、检测时间、潜在风险、入侵攻击对象、入侵检测流程或者入侵检测上下文信息。前端用户可以在通过该输出设备的显示界面查看入侵事件的相关信息。在需要的情况下，前端用户可以利用所呈现的信息对该入侵事件进行确认、攻击溯源等。
为了便于理解，下面以应用于车联网场景为例，介绍本申请实施例的具体实现细节。
图4示出了本申请实施例的应用于车联网场景的系统架构示意图。其中，以图1中的用户设备包括图2中的车辆、或者用户的智能终端为例，参阅图4所示，该场景中，服务器410可以通过无线网络与车辆450、用户的智能终端430进行通信交互，以实施本申请实施例的入侵检测方法。
下面对系统涉及的各个功能模块进行介绍。
1、车辆450：
车辆450例如可以包括多个ECU，例如网络通信装置451、OTA控制单元452、人机交互界面HMI 453、座舱域控制器454、车辆传感系统455或者自动驾驶域控制器456，以及用于实现车辆内部通信的车内通信网络(例如CAN总线等)。网络通信装置451可以作为服务器410、智能终端430等外部设备与车辆450的内部ECU之间的通信桥梁，实现关于运行日志的收发或转发等能力。在车辆450内部，该网络通信装置451例如可以通过车内通信网络实现与车辆450的各个ECU之间的信息传输。本申请实施例中，该网络通信装置451可以支持无线通信方式或有线通信方式，本申请实施例对此不做限定。
各个ECU可以作为业务节点，在运行过程中可以记录运行日志并保存。
例如，OTA控制单元452可以作为车辆450内部实现OTA升级控制的单元模块，可以执行与OTA升级业务相关的操作。比如OTA控制单元452可以通过网络通信装置451接收来自服务器410的OTA内容、OTA升级包等。或者，OTA控制单元452还可以安装OTA升级包、激活OTA升级包。或者，OTA控制单元452可以将操作结果通过网络通信装置451反馈至服务器410。在OTA控制单元452运行并实现相应业务的过程中，该OTA控制单元452可以同步记录运行日志并保存。该运行日志中例如可以包括描述OTA升级业务的相关操作的执行详情的信息，例如执行日期、执行时间、执行者、操作标识、操作内容以及其它关联信息等。
例如，HMI 453为车辆450内的输入/输出设备，该HMI 453可以通过车内通信网络与网络通信装置451、或OTA控制单元452、或座舱域控制器454、或车辆传感系统455、或自动驾驶域控制器456通信，并可以提供操作界面，用于输出来自网络通信装置451、或OTA控制单元452、或座舱域控制器454、或车辆传感系统455、或自动驾驶域控制器456的信息，或者用于接收用户通过HMI 453输入的信息，或者将接收到的输入信息发送给相应的ECU或服务器。在该HMI 453的运行并实现相应业务的过程中，该HMI 453可以同步记录运行日志并保存。该运行日志中例如可以包括输出信息的内容、日期、时间、操作标识以及关联的其它信息，或者包括输入信息的内容、日期、时间、操作标识以及关联的其它信息等。
例如，座舱域控制器454可以通过独立感知层，获得足够的感知数据，例如车内视觉(光学)、语音(声学)以及方向盘、刹车踏板、油门踏板、档位、安全带等底盘和车身数据，利用生物识别技术(车舱内主要是人脸识别、声音识别)，来综合判断驾驶员(或 其他乘员)的生理状态(人像、脸部识别等)和行为状态(驾驶行为、声音、肢体行为)，随后根据具体场景推送交互请求。车内交互方式从仅有“物理按键交互”升级至“触屏交互”、“语音交互”、“手势交互”并存的状态。座舱域控制器454在运行并实现相应业务的过程中，可以同步记录运行日志并保存。该运行日志中例如可以包括获取各种感知数据的日期、时间、操作标识、操作内容以及关联的其它信息，或者可以包括在具体场景下推送交互请求的内容、日期、时间、操作标识以及其它关联信息。
例如，车辆传感系统455可以包括摄像头、雷达、温度计、湿度计等传感器件，该车辆传感系统455可以通过感知获得车内环境或者车外环境的感知结果，并将该感知结果提供给座舱域控制器454或其它需要该信息的ECU，例如自动驾驶域控制器456等。相似地，车辆传感系统455可以记录各个传感器件的运行日志，例如感知信息的内容、产生日期、时间、操作标识以及关联的其它信息等。
例如，自动驾驶域控制器456可以根据收集到的各种感知结果进行自动驾驶决策并实施自动驾驶控制，例如自适应巡航控制、自动紧急制动控制、车道保持辅助控制、车道偏离预警控制、泊车辅助控制等。自动驾驶域控制器456在运行并实现相应业务的过程中，可以同步记录运行日志并保存。该运行日志中可以包括不同自动驾驶功能操作涉及的操作标识、内容、日期、时间或者其它关联信息等。
在需要的情况下，以上各个车辆ECU可以将保存的运行日志上报给服务器410，服务器410可以对收集到的来自至少两个业务节点的运行日志进行解析，以确定是否发生入侵事件。
需要说明的是，本申请实施例中，图4示出的各个ECU均可作为车联网业务的一个业务节点向服务器410提供自身的运行日志。不同ECU在实现各自业务的过程中产生的运行日志包含的内容可以有所不同，本申请实施例对该运行日志的内容不做限定。在另一个可选的实施例中，还可以在网络通信装置451集成数据收集模块，该数据收集模块可以从车辆450的各个ECU获取所需的运行日志上报至服务器。为了减少对服务器410实现的车联网业务的影响，一种可选的实施方式是，服务器410与车辆450之间的运行日志传输通道可以是独立通道，独立于服务器410与车辆450之间的业务传输通道，本申请实施例对服务器410与车辆450之间运行日志传输方式不做限定。
应理解的是，图4仅是对车辆450内的ECU的示例说明而非任何限定，在其它实施例中，该车辆450还可以包括未示出的其它ECU，例如动力域控制器、底盘域控制器等，在此不再赘述。
2、智能终端430：
智能终端430可以通过移动网络与服务器410和车辆450的网络通信装置451通信。智能终端430上可以安装并运行应用程序(application，APP)，该APP例如可以作为业务节点，在APP运行过程中，APP可以通过与服务器410或车辆450的通信交互实施车辆管理。相似地，APP运行过程中也可以同步记录运行日志并保存。该运行日志中例如可以包括与用户、服务器410或车辆450的信息或操作涉及的操作标识、操作内容、日期、时间或者其它关联信息等。
在具体实施时，在智能终端430侧的数据收集模块可以是以软件开发工具包(software development kit，SDK)的形式打包在管理车辆的APP，并可以用于收集APP的运行日志以及向服务器410上报APP的运行日志。
3、服务器410：
服务器410可以包括数据收集模块411、入侵检测分析引擎412、存储模块414和至少一个微服务，例如表示为微服务413_1、微服务413_2或者微服务413_3。
(1)微服务：
不同的微服务各自作为业务节点，可以用于为车辆450提供不同的车联网业务，例如微服务413_1可以提供OTA升级业务，微服务413_2可以提供车辆的远程控制业务，微服务413_3可以提供车辆的蓝牙钥匙业务等。各个微服务在运行过程中会产生相应的运行日志并保存。日志内容根据业务不同可以有所不同，在此不再赘述。
(2)数据收集模块411：
数据收集模块411可以收集来自于多端(例如至少两个业务节点)的运行日志。例如数据收集模块411可以通过调用各个微服务的接口收集来自于不同微服务的运行日志。或者例如，数据收集模块411可以通过无线网络收集来自于智能终端430或者来自于车辆450的各个ECU的运行日志。
在一个可选的实施方式中，数据收集模块411可以对收集到的多端日志数据进行数据清洗和聚合，按照车辆维度对来自于同一辆车、同一个车主APP以及对应的微服务的日志数据进行统一归类和存储。
需要说明的是，本申请实施例中，对于任一业务节点，该业务节点的业务流程可以包括至少一个步骤，例如表示为步骤1、步骤2、步骤3……。位于业务节点的数据收集模块可以在业务流程的各个步骤记录运行日志的内容，并在需要的情况下，通过相应的数据收集通道，将收集到的日志数据提供给服务器410侧的数据收集模块411，如图5所示。
需要说明的是，图5中以虚线箭头表示业务节点与服务器410的数据收集模块411之间的数据收集通道，该数据收集通道可以是独立通道，与正常业务流程解耦，即在不需要正常业务进行特殊的适配以及无感知的情况下，实现对业务节点的日志数据的收集。
(3)入侵检测分析引擎412：
入侵检测分析引擎412可以针对每辆车的所有端来源的日志数据进行统一的分析，通过将日志数据与预设的检测规则集合中的备选检测规则进行匹配的方法，来识别是否发生入侵检测事件。
具体实施时，如图6所示，在发起入侵检测之前，首先可以针对业务分析常见攻击手段(或称为入侵攻击行为)，例如表示为攻击手段1、攻击手段2、攻击手段3、攻击手段4……。针对不同的攻击手段可以生成相应的检测规则，例如表示为备选检测规则1、备选检测规则2、备选检测规则3、备选检测规则4……。针对不同业务生成的备选检测规则可以汇集为检测规则集合，内置在入侵检测分析引擎412，或者内置在该入侵检测分析引擎412能够访问的存储模块(可以与存储模块414相同，也可以不同)。在一个可选的实施方式中，入侵检测分析引擎412可以提供配置接口，该配置接口可以用于接收配置信息，该配置信息可以用于修改检测规则集合中的备选检测规则，和/或，所述配置信息可以用于在所述检测规则集合中新增备选检测规则。
需要说明的是，本申请实施例中，对于攻击手段的识别以及备选检测规则的生成，可以是人工实现的，也可以是通过模型(例如机器模型或者学习模型)实现的，本申请实施例对此不做限定。各备选检测规则可以是以程序代码的方式实现，也可以是以其它产品形态实现，本申请实施例对此不做限定。检测规则集合中的所有备选检测规则在投入使用之 前，均已完成测试，符合检测规则所需满足的各种条件，在此不再赘述。
在发起入侵检测时，服务器410的入侵检测分析引擎412可以基于针对同一车辆获取到的至少两个业务节点的日志数据，对内置的全部或部分备选检测规则(称为目标检测规则)进行遍历匹配，以确定是否发生入侵事件。
需要说明的是，本申请实施例中，对多端日志数据进行数据聚合的功能也可以集成在入侵检测分析引擎412，本申请实施例对此不做限定。在进行入侵检测时，入侵检测分析引擎412只需按照遍历到的目标检测规则，通过是否能够在全量的日志数据中提取所需的目标数据，以及所提取到的目标数据是否匹配，来确定是否发生该目标检测规则对应的入侵事件。
示例地，入侵事件、入侵事件的检测方法以及相关日志行的对应关系可以如下所示：
入侵事件A：
入侵事件名称：OTA微服务下发时间与车辆侧本地更新时间不一致，可能被车辆本地刷写系统；
威胁等级：中危；
潜在风险：在OTA流程开始阶段，OTA微服务会下发更新相关信息至车辆端，车辆端接收到相关信息后会开始执行OTA流程。在实际的环境中，OTA微服务下发消息的时间与车辆端接收到消息的时间应该是同步的，如果就发现OTA微服务下发消息的时间与车辆端接收到消息的时间相差过大，很有可能是车云通信被攻击者劫持，攻击者使用重放等攻击手段进行攻击。
检测方法：
1).在车辆端的运行日志中检测包含如下字段的日志行：任务标识(task Id)(任务标识例如为操作标识的一种示例)；
2).在该日志行提取task Id：345607472024893440；
3).在该日志行下方检测包含如下字段的日志行：begin call Vdc ua proxy InformDCUrl interface；
4).提取该日志行中的时间戳(timestamp)对应的时间值：1652258444029；
5).在OTA微服务的运行日志中检测该taskid应该有多行匹配(如果没有则直接检测出入侵威胁)，找到其中的第一行提取发生时间(occur time)对应的时间值：1652258443625；
6).对两个时间值进行对比，如果时间相差大于1个小时，则可能遭受攻击。
相关日志行：
2022-05-11 16:40:42.856|2817414160|OTAManager|INFO|Task Id:345607472024893440|OTATaskObjectHolder.cpp|189
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
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版本交样"}],"size":41050},supportingEcus:null}).caller class:com.huawei.ivcs.ota.scheduler.task.processor.impl.DispatchProcessor,line:790。
入侵事件B：
入侵事件名称：OTA下载链接被替换；
威胁等级：高危；
潜在风险：在OTA流程开始阶段，OTA微服务会向车辆端下发更新相关信息至车端，车辆端接收到相关信息后会开始执行OTA流程。在实际的环境中，OTA微服务下发消息中的下载链接与车辆端接收到消息的下载链接应该是相同的，如果发现两个链接有差异，则很可能已经被攻击者劫持，并替换掉下载链接。
检测方法：
1).在车辆端的运行日志中检测到包含如下字段的日志行：begin call Vdc ua proxy InformDCUrl interface；
2).在该日志行提取车辆端接收到的升级包的下载链接：
https://cdn.fgaif1.ias.huawei.com/*****5_SW％253A1.01.C_220429_2225_00.zip；
3).在该行中提取OTA任务的taskId：345607472024893440；
4).在OTA微服务的运行日志中检测如下字段：dcPackages，应该能检测到多条字段；
5).应该可以通过taskId过滤出2行(如果没有检测到直接检测出入侵威胁)记录，选取第一行，提取出其中的下载url：
https://cdn.fgaif1.ias.huawei.com/2022/04/29/1651225361442/TBOX_7900010-SY01-2225_SW％253A1.01.C_220429_2225_00.zip；
6).将车辆端检测的url拆分为前半部分和后半部分：https://cdn.fgaif1.ias.huawei.com/，5_SW％253A1.01.C_220429_2225_00.zip；
7).将车辆端、OTA微服务的url链接进行匹配，以确定两者内容是否相同。
相关日志行：
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
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版本交样"}],"size":41050},supportingEcus:null}).caller class:com.huawei.ivcs.ota.scheduler.task.processor.impl.DispatchProcessor,line:790。
需要说明的是，以上是以入侵事件A和入侵事件B为例，对入侵事件、入侵事件的检测方法的对应关系的示例说明而非任何限定。在其它实施例中，还需要结合入侵事件可能涉及的具体的攻击手段生成相应的检测规则，以便后续利用该检测规则对该入侵事件进行检测，在此不再赘述。
(4)存储模块414：
存储模块414可以用于存储不同车辆的不同入侵事件的检测结果，并可以将所有的入侵事件进行归类存储。
在一个可选的实施方式中，存储模块414还可以关联输出设备。示例地，该输出设备的HMI可以从存储模块414获取相关事件的检测结果并输出，以便前端用户针对相关事件进行事件确认、入侵溯源以及进行应急响应等。
具体例如，存储模块414关联的HMI上，可以输出如图7所示的第一界面，该第一界面可以用于从至少一种维度呈现截止到某个时刻(例如2022-7-28 10:58:40)发生的入侵事件的统计结果。
示例地，该至少一种维度例如可以包括警报维度，例如各个入侵事件的威胁等级分类：低危风险、中危风险、高危风险、超危风险等；入侵事件的总数量；各威胁等级对应的入侵事件的数量：例如，455个低危风险事件、342个中危风险事件、162个高危风险事件、24个超危风险事件。
或者，该至少一种维度例如可以包括场景维度，包括但不限于以下至少一个：统一诊断服务(unified diagnostic services，UDS)诊断场景、系统网络场景、车载网络场景、OTA场景、蓝牙钥匙场景、系统证书场景、车载系统场景、远程车控场景等。统计结果可以包括不同场景下涉及的入侵事件的数量，如图7所示，可以以横坐标表示入侵事件的统计数量，纵坐标表示场景。
或者，该至少一种维度例如可以包括地域维度，包括但不限于以省/直辖市、市、县、区等不同粒度划分的地域。如图7所示，以按照省份划分的地域为例，以纵坐标表示省份的标识(例如表示为省份1、省份2、……、省份8)，横坐标表示不同省份发生的入侵事件的统计数量。
或者，该至少一种维度例如可以包括车型维度，例如表示为X1。如图7所示，纵坐标可以表示车型，横坐标可以表示该车型涉及的入侵事件的统计数量。
或者，该至少一种维度例如可以包括入侵事件响应维度。如图7所示，以横坐标表示时间(例如入侵事件的发生时间或者入侵事件响应的处理时间)，以横坐标表示对应时间区间内发生的入侵事件数量或者入侵事件响应数量。
或者，该至少一种维度可以包括车辆ECU维度，例如车辆识别单元(vehicle identification unit，VIU)、车辆动态控制(vehicle dynamics control，VDC)、自动调节及不间断减震控制系统(continuous damping control，CDC)、车辆信息和定位传输系统 (telematics-box，TBOX)、或者车云通信等。如图7所示，第一界面还可以输出各个ECU涉及的不同威胁等级的入侵事件的数量。应理解，图7中还可以将针对不同ECU呈现是统计结果连接至车辆中的对应位置，在此不再赘述。
或者，该至少一种维度还可以包括工作台维度，该工作台维度可以呈现已处理的入侵事件的数量(例如688)、待处理的入侵事件的数量(例如295)、以及最近事件列表，该最近事件列表可以呈现最近发生的入侵事件以及该事件的发生时间。
对于在图7中从至少一个维度呈现的统计结果，前端用户可以通过鼠标或其它输入方式选择某个具体项，从而图7所示的第一界面可以跳转至第二界面(或者并列展示第一界面和第二界面)，该第二界面可以呈现所选择的具体项的更细粒度的信息详情。
以前端用户选择“最近事件列表”中的某个事件为例，输出设备的HMI可以接收在该第一界面输入的控制信息，该控制信息用于指示输出目标入侵事件的入侵检测结果。相应地，输出设备的HMI上会呈现如图8所示的第二界面，该第二界面会输出目标入侵事件的入侵检测结果，包括以下至少一项信息的详细内容：事件标识、事件名称、威胁等级、检测时间、潜在风险、入侵攻击对象、入侵检测流程或者入侵检测上下文信息。
在一个可选的实施方式中，图8中还可以呈现输入框，该输入框可以用于前端用户输入或选择针对该入侵事件的确认信息或者处理方法。相应地，HMI可以接收响应于入侵检测结果输入的第二指示信息，该第二指示信息用于确定入侵事件或者用于指示对入侵事件的处理方法。其中，不同入侵事件的处理方法有所不同，本申请实施例对此不做限定。
由此，输出设备可以非常方便地呈现入侵事件的检测结果以及相关上下文，以方便前端用户在查阅这些信息后，及时地对入侵事件进行确认、响应处理、攻击溯源等等。
至此，已经结合附图及实施例详细介绍了本申请实施例的系统架构，其中，服务器作为入侵检测端，可以从实现目标业务的至少两个业务节点收集运行日志，并对收集到的日志数据进行解析，来检测各个业务节点或者业务节点之间的网络通信等是否存在入侵事件。该服务器可以从业务层面对涉及多端或多系统的业务节点进行全面的入侵检测，而不局限于单个业务节点，有助于提升入侵事件的检测效率。同时，服务器关联的输出设备可以从至少一种维度输出入侵事件的统计结果，以方便前端用户(例如安全专家)及时地根据所呈现的信息对入侵事件进行确认、溯源或者响应等。
为例便于理解，下面结合OTA场景和蓝牙钥匙场景，对本申请实施例的入侵检测方法进行介绍。
1、OTA场景：
在智能网联车辆领域，OTA已经成为一种标配技术，车辆的各个ECU可以通过OTA功能从服务器侧的OTA微服务下载OTA升级包来更新自身系统，从而获取新的功能或者给系统打补丁，以提高系统安全性。而OTA功能在为智能网联车辆带来便利的同时，也称为攻击者主要攻击点之一。其中，一种常见的攻击方式是通过劫持车云之间的通信，通过替换OTA升级包的下载链接，从而将恶意的系统刷写进入车端ECU。因此，需要对该攻击手段对应的入侵事件进行安全检测。
如图9所示，在OTA场景下，在车端和OTA微服务执行正常的OTA流程时，业务节点涉及车端ECU和服务器侧的OTA微服务，业务流程涉及的步骤可以包括：OTA微服务下发OTA升级包的下载链接。相应地，车辆端接收OTA升级包的下载链接。车辆端下载 OTA升级包。车辆端安装和激活OTA升级包。
基于本申请实施例的入侵检测方法，在车端ECU或OTA微服务各自实现相应的业务步骤的过程中，车端ECU或OTA微服务各自的数据收集模块可以收集运行日志。服务器的数据收集模块可以从车端ECU或OTA微服务各自的数据收集模块收集运行日志，并将所收集到的日志数据提供给入侵检测分析引擎。入侵检测分析引擎可以基于获得的日志数据，与内置的检测规则集合的部分或者全部备选检测规则进行遍历匹配。基于匹配到的目标检测规则，入侵检测分析引擎可以从相关运行日志中提取目标数据(例如OTA升级包的下载链接)，并将提取到的目标数据的内容进行匹配，若目标数据不满足相应的检测条件(例如URL内容相同)，则识别出发生入侵事件。进一步地，该入侵事件的检测结果或者日志上下文均可在服务器的前端HMI上输出，前端用户(例如安全专家)可以对入侵事件进行确认。在经过安全专家人工确认后，确认入侵事件。对运行日志的详细解析细节可以参见前文中结合入侵事件A的检测方法的描述，在此不再赘述。
2、蓝牙钥匙场景：
在正常的车辆蓝牙钥匙(开车门)业务流程中，车主APP会在云端相应的微服务获取蓝牙钥匙，然后使用所获取的蓝牙钥匙与车辆进行蓝牙通信，并发送开门请求来打开车门。本申请实施例中，可以通过对蓝牙钥匙业务常见的攻击场景进行建模，可以得到如图10所示的攻击模式，攻击者通过劫持车主APP与车辆端的蓝牙通信，并在车主离开车辆后将该消息进行重放，从而实现非法开启车门的操作。
如图10所示，蓝牙钥匙场景可以包括以下步骤：
S1：车主APP向云端微服务请求进行登录验证。
S2：云端微服务验证成功后，向车主APP发送反馈信息。
S3：车主APP在成功登录后，向云端微服务申请蓝牙钥匙。
S4：云端微服务向车主APP下发蓝牙钥匙。
S5：车主APP使用蓝牙钥匙向车辆请求打开车门。在此过程中，攻击者可能在S6劫持车主APP与车辆端的蓝牙通信，获得蓝牙钥匙。在S7：车主APP若超时未接收到相应则关闭开门流程。
S8：攻击者重放开门信息，以请求开启车门。
S9：车辆向攻击者发送车门开启成功的提醒。
在对图10所示的攻击场景进行威胁建模后，即可识别出在该攻击的过程中，哪些端会受到影响。经过识别可以发现，需要对车主APP以及车辆APP的运行日志进行收集和分析，生成蓝牙钥匙开门重放攻击对应的入侵检测规则。进而，即可执行如图11所示的入侵检测方法：
服务器的数据收集模块可以收集车辆APP的运行日志和云端微服务的运行日志，并将所获取的运行日志提供给入侵检测分析引擎。该入侵检测分析引擎会基于蓝牙钥匙重放攻击规则，从收集到的日志数据中提取蓝牙钥匙开门相关信息，例如相关操作时间(例如使用蓝牙钥匙开门指令的操作时间或接收蓝牙钥匙开门指令的操作时间)。入侵检测分析引擎可以将提取到的两个操作时间值进行比较，例如计算两时间值之差是否满足检测条件(例如小于或等于第一阈值)。若否，即两个时间值之差过大，表明车辆可能遭受蓝牙钥匙重放攻击。
需要说明的是，本申请实施例中，对于车辆而言，攻击者可能是通过蓝牙钥匙重放攻 击打开车门并造成其它车辆攻击，因此，在一种可选的实施方式中，还可以为不同场景的入侵事件以及备选检测规则设置优先级，在具体实施时，还可以按照优先级逐步进行入侵检测。例如，对于车辆，在每次进行入侵检测时，先进行一次蓝牙钥匙重放攻击的检测，那么在确认存在蓝牙钥匙重放攻击时，该车辆本身已经失窃，处于非安全状态，基于该车辆实现的其它业务均是不安全的，无需再执行其它场景下的入侵检测。
应理解，此处仅是对不同场景下的入侵检测的实施顺序的示例说明而非任何限定，在具体实施时，也可以不设置优先级，在此不再赘述。
至此，已经结合附图及实施例解释了本申请实施例的入侵检测方法在车联网场景下的应用，通过该方法，可以利用服务器内置的检测规则集合，对同一车辆的目标业务的多端来源的日志数据进行解析，以检测入侵事件。该方法能够从业务层面有效识别出针对整车级业务的入侵攻击，而不局限于单个业务节点。同时，该方法可以与各个业务节点的正常业务解耦，不会影响业务节点的业务的正常实现。由于服务器的安全防御等级高于车辆ECU，也会极大地降低入侵检测分析引擎被攻击的风险。并且，在服务器关联的输出设备，前端用户可以查看入侵事件详情，并可以从存储模块获取和呈现入侵事件的相关上下文信息，便于前端用户对入侵事件进行确认、溯源以及紧急响应等。服务器所提供的用于配置备选检测规则的入口，还可以方便技术人员根据攻击手段的更新或者历史入侵数据的漏检信息，及时地更新入侵检测分析引擎内置的检测规则集合。
应理解，本申请实施例述及的入侵检测方法还可以用于IOT领域，在IOT领域可以采用与上文在车联网场景下的相同或相似的方法，对同一对象的多端来源的日志数据进行解析，以确定是否发生入侵事件。实施细节可以参见前文的相关描述，在此不再赘述。
本申请实施例还提供了一种通信装置，用于执行上述方法实施例中服务器、车辆ECU、智能终端等所执行的方法，相关特征可参见上述方法实施例，在此不再赘述。
如图12所示，在一个示例中，该通信装置1200可以包括：获取单元1201，用于获取至少两个业务节点的运行日志，所述至少两个业务节点关联目标业务；确定单元1202，用于根据所述至少两个业务节点的运行日志以及目标检测规则，确定是否发生所述入侵事件，所述目标检测规则用于描述所述目标业务关联的入侵事件的检测方法。具体实现方式，请参考上述方法实施例中服务器所实现的方法步骤，这里不再赘述。
在另一个示例中，本申请实施例还提供了一种HMI，如图13所示，该HMI 1300可以包括：通信单元1301，用于接收目标入侵事件的入侵检测结果，所述入侵检测结果用于指示所述目标入侵事件的以下至少一项信息：事件标识、事件名称、威胁等级、检测事件、潜在风险、入侵攻击对象、入侵检测流程或者入侵检测上下文信息；输出单元1302，用于输出所述目标入侵事件的入侵检测结果。具体实现方式，请参考上述方法实施例中输出设备所实现的方法步骤，这里不再赘述。
应理解，以上装置中各单元的划分仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。此外，装置中的单元可以以处理器调用软件的形式实现；例如装置包括处理器，处理器与存储器连接，存储器中存储有指令，处理器调用存储器中存储的指令，以实现以上任一种方法或实现该装置各单元的功能，其中处理器例如为通用处理器，例如中央处理单元(Central Processing Unit，CPU)或微处理器，存储器为装置内的存储器或装置外的存储器。或者，装置中的单元可以以硬件电路的 形式实现，可以通过对硬件电路的设计实现部分或全部单元的功能，该硬件电路可以理解为一个或多个处理器；例如，在一种实现中，该硬件电路为专用集成电路(application-specific integrated circuit，ASIC)，通过对电路内元件逻辑关系的设计，实现以上部分或全部单元的功能；再如，在另一种实现中，该硬件电路为可以通过可编程逻辑器件(programmable logic device，PLD)实现，以现场可编程门阵列(Field Programmable Gate Array，FPGA)为例，其可以包括大量逻辑门电路，通过配置文件来配置逻辑门电路之间的连接关系，从而实现以上部分或全部单元的功能。以上装置的所有单元可以全部通过处理器调用软件的形式实现，或全部通过硬件电路的形式实现，或部分通过处理器调用软件的形式实现，剩余部分通过硬件电路的形式实现。
在本申请实施例中，处理器是一种具有信号的处理能力的电路，在一种实现中，处理器可以是具有指令读取与运行能力的电路，例如CPU、微处理器、图形处理器(graphics processing unit，GPU)(可以理解为一种微处理器)、或数字信号处理器(digital singnal processor，DSP)等；在另一种实现中，处理器可以通过硬件电路的逻辑关系实现一定功能，该硬件电路的逻辑关系是固定的或可以重构的，例如处理器为ASIC或PLD实现的硬件电路，例如FPGA。在可重构的硬件电路中，处理器加载配置文档，实现硬件电路配置的过程，可以理解为处理器加载指令，以实现以上部分或全部单元的功能的过程。此外，还可以是针对人工智能设计的硬件电路，其可以理解为一种ASIC，例如神经网络处理单元(Neural Network Processing Unit，NPU)张量处理单元(Tensor Processing Unit，TPU)、深度学习处理单元(Deep learning Processing Unit,DPU)等。
可见，以上装置中的各单元可以是被配置成实施以上方法的一个或多个处理器(或处理电路)，例如：CPU、GPU、NPU、TPU、DPU、微处理器、DSP、ASIC、FPGA，或这些处理器形式中至少两种的组合。
此外，以上装置中的各单元可以全部或部分可以集成在一起，或者可以独立实现。在一种实现中，这些单元集成在一起，以片上系统(system-on-a-chip，SOC)的形式实现。该SOC中可以包括至少一个处理器，用于实现以上任一种方法或实现该装置各单元的功能，该至少一个处理器的种类可以不同，例如包括CPU和FPGA，CPU和人工智能处理器，CPU和GPU等。
在一个简单的实施例中，本领域的技术人员可以想到上述实施例中的通信装置均可采用图14所示的形式。
如图14所示的装置1400，包括至少一个处理器1410和通信接口1430。在一种可选的设计中，还可以包括存储器1420。
本申请实施例中不限定上述处理器1410以及存储器1420之间的具体连接介质。
在如图14的装置中，处理器1410在与其他设备进行通信时，可以通过通信接口1430进行数据传输。
当通信装置采用图14所示的形式时，图14中的处理器1410可以通过调用存储器1420中存储的计算机执行指令，使得装置1400可以执行上述任一方法实施例。
本申请实施例还涉及一种芯片系统，该芯片系统包括处理器，用于调用存储器中存储的计算机程序或计算机指令，以使得该处理器执行上述任一实施例的方法。
在一种可能的实现方式中，该处理器可以通过接口与存储器耦合。
在一种可能的实现方式中，该芯片系统还可以直接包括存储器，该存储器中存储有计 算机程序或计算机指令。
示例地，存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。
本申请实施例还涉及一种处理器，该处理器用于调用存储器中存储的计算机程序或计算机指令，以使得该处理器执行上述任一实施例所述的方法。
示例地，在本申请实施例中，处理器是一种集成电路芯片，具有信号的处理能力。例如，该处理器可以是FPGA，可以是通用处理器、DSP、ASIC或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，还可以是系统芯片(system on chip，SoC)，还可以是CPU，还可以是网络处理器(network processor，NP)，还可以是微控制器(micro controller unit，MCU)，还可以是PLD或其他集成芯片，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。
在一种可能的实现方式中，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有程序代码，当所述程序代码在所述计算机上运行时，使得计算机执行上述方法实施例。
在一种可能的实现方式中，本申请实施例提供了一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行上述方法实施例。
因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机 或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例范围。这样，倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。在本申请的各个实施例中，如果没有特殊说明以及逻辑冲突，各个实施例之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。

Claims (22)

  1. 一种入侵检测方法，其特征在于，应用于服务器，所述方法包括：
    获取至少两个业务节点的运行日志，所述至少两个业务节点关联目标业务；
    根据所述至少两个业务节点的运行日志以及目标检测规则，确定是否发生所述入侵事件，所述目标检测规则用于描述所述目标业务关联的入侵事件的检测方法。
  2. 根据权利要求1所述的方法，其特征在于，所述目标检测规则包括用于指示所述入侵事件的检测字段以及至少一个检测条件的规则，所述检测字段表征所述目标业务的潜在入侵攻击行为的特征，所述根据所述至少两个业务节点的运行日志以及目标检测规则，确定是否发生所述入侵事件，包括：
    根据所述目标检测规则指示的检测字段，从所述至少两个业务节点的运行日志中获取目标数据；
    在所述运行日志和所述目标数据满足所述至少一个检测条件中的所有检测条件时，确定未发生入侵事件；
    在所述运行日志或所述目标数据不满足所述至少一个检测条件中的任一检测条件时，确定发生入侵事件。
  3. 根据权利要求2所述的方法，其特征在于，所述入侵事件的检测字段包括时间戳，所述目标数据包括所述时间戳对应的时间值，所述至少一个检测条件包括：
    从所述至少两个业务节点的运行日志中获取的时间值的差值小于或等于第一阈值。
  4. 根据权利要求2或3所述的方法，其特征在于，所述入侵事件的检测字段包括统一资源定位符URL，所述目标数据包括URL数据，所述至少一个检测条件包括：
    从所述至少两个业务节点的运行日志中获取的URL数据的内容相同。
  5. 根据权利要求2-4中任一项所述的方法，其特征在于，所述入侵事件的检测字段包括操作标识，所述操作标识关联执行所述目标业务包含的操作，所述目标数据包括所述操作标识对应的数据，所述至少一个检测条件包括：
    从所述至少两个业务节点的运行日志中获取的操作标识对应的数据的内容相同。
  6. 根据权利要求1-5中任一项所述的方法，其特征在于，所述方法还包括：
    根据所述运行日志，从检测规则集合中获取所述目标检测规则，其中，所述检测规则集合包括预先为所述目标业务的多种潜在入侵攻击行为配置的备选检测规则，所述备选检测规则用于描述所述潜在入侵攻击行为对应的入侵事件的检测方法。
  7. 根据权利要求6所述的方法，其特征在于，
    所述目标检测规则包括所述检测规则集合中的全部备选检测规则；或者，
    所述目标检测规则包括所述检测规则集合中与所述目标业务关联的备选检测规则。
  8. 根据权利要求6或7所述的方法，其特征在于，所述方法还包括：
    接收配置信息，所述配置信息用于修改所述检测规则集合中的备选检测规则，和/或，所述配置信息用于在所述检测规则集合中新增备选检测规则。
  9. 根据权利要求1-8中任一项所述的方法，其特征在于，所述方法还包括：
    在所述服务器关联的输出设备输出所述入侵事件的检测结果。
  10. 根据权利要求9所述的方法，其特征在于，所述入侵事件的检测结果包括所述入侵事件的以下至少一项信息：事件标识、事件名称、威胁等级、检测时间、潜在风险、入侵 攻击对象、入侵检测流程或者入侵检测上下文信息。
  11. 根据权利要求1-10中任一项所述的方法，其特征在于，所述目标业务包括车辆业务，所述至少两个业务节点包括：所述服务器、目标车辆或者管理所述目标车辆的用户的用户设备。
  12. 一种入侵检测方法，其特征在于，应用于人机交互界面HMI，所述方法包括：
    接收目标入侵事件的入侵检测结果，所述入侵检测结果用于指示所述目标入侵事件的以下至少一项信息：事件标识、事件名称、威胁等级、检测事件、潜在风险、入侵攻击对象、入侵检测流程或者入侵检测上下文信息；
    输出所述目标入侵事件的入侵检测结果。
  13. 根据权利要求12所述的方法，其特征在于，所述方法还包括：
    接收响应于所述入侵检测结果输入的第二指示信息，其中，所述第二指示信息用于确认所述入侵事件，或者所述第二指示信息用于指示对所述入侵事件的处理方法。
  14. 根据权利要求12或13所述的方法，其特征在于，所述方法还包括：
    输出第一界面，所述第一界面用于从至少一种维度呈现入侵事件的统计结果；
    接收在所述第一界面输入的控制信息，所述控制信息用于指示输出所述目标入侵事件的入侵检测结果。
  15. 一种通信装置，其特征在于，包括：
    获取单元，用于获取至少两个业务节点的运行日志，所述至少两个业务节点关联目标业务；
    确定单元，用于根据所述至少两个业务节点的运行日志以及目标检测规则，确定是否发生所述入侵事件，所述目标检测规则用于描述所述目标业务关联的入侵事件的检测方法。
  16. 一种人机交互界面HMI，其特征在于，包括：
    通信单元，用于接收目标入侵事件的入侵检测结果，所述入侵检测结果用于指示所述目标入侵事件的以下至少一项信息：事件标识、事件名称、威胁等级、检测事件、潜在风险、入侵攻击对象、入侵检测流程或者入侵检测上下文信息；
    输出单元，用于输出所述目标入侵事件的入侵检测结果。
  17. 一种通信装置，其特征在于，所述通信装置包括：
    通信接口，用于与其他装置进行通信；
    处理器，与所述通信接口耦合，使得所述通信装置执行如权利要求1-11中任意一项所述的方法，或者执行如权利要求12-13中任意一项所述的方法。
  18. 一种通信系统，其特征在于，包括服务器，所述服务器用于实现如权利要求1-11中任一项所述的方法。
  19. 根据权利要求18所述的通信系统，其特征在于，还包括人机交互界面HMI，所述HMI用于实现如权利要求12-13中任一项所述的方法。
  20. 一种芯片系统，其特征在于，包括至少一个处理器和接口电路，所述处理器用于通过所述接口电路执行指令和/或数据的交互，使得所述芯片系统执行权利要求1-11中任一项所述的方法，或者执行权利要求12-13中任一项所述的方法。
  21. 一种计算机可读存储介质，其特征在于，包括程序或指令，当所述程序或指令被执行时，如权利要求1-11中任意一项所述的方法被执行，或者如权利要求12-13中任一项所述的方法被执行。
  22. 一种计算机程序产品，其特征在于，当计算机读取并执行所述计算机程序产品时，使得计算机执行如权利要求1-11中任一项所述的方法，或者执行如权利要求12-13中任一项所述的方法。
PCT/CN2022/121397 2022-09-26 2022-09-26 一种入侵检测方法、装置和系统 WO2024065093A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/121397 WO2024065093A1 (zh) 2022-09-26 2022-09-26 一种入侵检测方法、装置和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/121397 WO2024065093A1 (zh) 2022-09-26 2022-09-26 一种入侵检测方法、装置和系统

Publications (1)

Publication Number Publication Date
WO2024065093A1 true WO2024065093A1 (zh) 2024-04-04

Family

ID=90475106

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/121397 WO2024065093A1 (zh) 2022-09-26 2022-09-26 一种入侵检测方法、装置和系统

Country Status (1)

Country Link
WO (1) WO2024065093A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107948172A (zh) * 2017-11-30 2018-04-20 恒安嘉新（北京）科技股份公司 一种基于人工智能行为分析的车联网入侵攻击检测方法和系统
CN109495438A (zh) * 2017-09-11 2019-03-19 通用汽车环球科技运作有限责任公司 用于车内网络入侵检测的系统和方法
CN109495439A (zh) * 2017-09-11 2019-03-19 通用汽车环球科技运作有限责任公司 用于车内网络入侵检测的系统和方法
CN112822684A (zh) * 2021-02-04 2021-05-18 中汽创智科技有限公司 车辆入侵检测方法及防御系统
WO2021162473A1 (ko) * 2020-02-14 2021-08-19 현대자동차주식회사 차량 내 네트워크에 대한 침입 탐지를 위한 시스템 및 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109495438A (zh) * 2017-09-11 2019-03-19 通用汽车环球科技运作有限责任公司 用于车内网络入侵检测的系统和方法
CN109495439A (zh) * 2017-09-11 2019-03-19 通用汽车环球科技运作有限责任公司 用于车内网络入侵检测的系统和方法
CN107948172A (zh) * 2017-11-30 2018-04-20 恒安嘉新（北京）科技股份公司 一种基于人工智能行为分析的车联网入侵攻击检测方法和系统
WO2021162473A1 (ko) * 2020-02-14 2021-08-19 현대자동차주식회사 차량 내 네트워크에 대한 침입 탐지를 위한 시스템 및 방법
CN112822684A (zh) * 2021-02-04 2021-05-18 中汽创智科技有限公司 车辆入侵检测方法及防御系统

Similar Documents

Publication Publication Date Title
US11875144B2 (en) Over-the-air (OTA) mobility services platform
US12046085B2 (en) System, method, and apparatus for managing vehicle data collection
US11277427B2 (en) System and method for time based anomaly detection in an in-vehicle communication
US20220224700A1 (en) System and method for connected vehicle cybersecurity
US11115433B2 (en) System and method for content based anomaly detection in an in-vehicle communication network
JP2023516760A (ja) 車両データ収集を管理するためのシステム、方法、及び装置
CN109523652B (zh) 基于驾驶行为的保险的处理方法、装置、设备及存储介质
Strandberg et al. A systematic literature review on automotive digital forensics: Challenges, technical solutions and data collection
US12116013B2 (en) Distributed in-vehicle realtime sensor data processing as a service
US11935341B2 (en) Data storage device and non-transitory tangible computer readable storage medium
WO2018179536A1 (ja) 情報処理装置、情報処理方法、プログラムとそれを記憶した記録媒体
Siegel Data proxies, the cognitive layer, and application locality: enablers of cloud-connected vehicles and next-generation internet of things
CN115203078A (zh) 基于soa架构的车辆数据采集系统、方法、设备及介质
WO2024065093A1 (zh) 一种入侵检测方法、装置和系统
US12101523B2 (en) Method and system for vehicle data file playback

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22959745

Country of ref document: EP

Kind code of ref document: A1