A system for detecting and diverting attacks on in-vehicle controllers and networks

Abstract

A vehicle system comprising: a first vehicle bus, wherein the first vehicle bus comprises one or more electronic control units (ECUs) configured to operate, wherein the one or more ECUs are configured to communicate with a remote server; a second vehicle bus, wherein the second vehicle bus is configured to communicate with the one or more ECUs, wherein the second vehicle bus comprises one or more vehicle drive ECUs configured to operate vehicle drive functions; a gateway controller configured to control communication between the first vehicle bus and the second vehicle bus; and a honeypot configured to emulate vehicle data, wherein the honeypot is further configured to monitor activity from a remote attacker.

Description

Technical Field

[0001] This disclosure relates to security systems and mechanisms that can be used on communication networks in vehicles and other systems such as aerospace, aviation, and maritime. Background Technology

[0002] Attackers targeting modern connected vehicles may target infotainment systems or similar systems that connect to remote servers and the outside world via interfaces such as Bluetooth, Wi-Fi, or other mobile data connections. Honeypots can be used for computer security. Automotive honeypots can focus on replicating interfaces to lure attackers. However, if attackers manage to compromise the vehicle, they can further advance by attacking more sensitive and secure critical parts of the car. While some existing intrusion detection systems may exist, they typically gather very limited information about the attacker's methods and capabilities. Summary of the Invention

[0003] According to one embodiment, a vehicle system includes: a first vehicle bus, wherein the first vehicle bus includes one or more electronic control units (ECUs) configured to operate, wherein the one or more ECUs are configured to communicate with a remote server; a second vehicle bus, wherein the second vehicle bus is configured to communicate with the one or more ECUs, wherein the second vehicle bus includes one or more vehicle driving ECUs configured to operate vehicle driving functions; a gateway controller configured to control communication between the first vehicle bus and the second vehicle bus; and a honeypot configured to emulate vehicle data, wherein the honeypot is further configured to monitor activities from a remote attacker.

[0004] According to a second embodiment, the vehicle system includes: a vehicle bus, the vehicle bus including one or more electronic control units (ECUs) configured to operate, at least one of the one or more ECUs being configured to communicate directly with a remote server; a honeypot configured to emulate vehicle data, wherein the honeypot is further configured to monitor the activities of attackers from one or more ECUs on the vehicle bus, wherein the honeypot includes one or more security vulnerabilities; and one or more processors communicating with the honeypot.

[0005] According to a third embodiment, the system includes: a first bus, wherein the first bus includes one or more electronic control units (ECUs) configured as operating system components, wherein the one or more ECUs are configured to communicate with a remote server; a second bus, wherein the second bus is configured to communicate with the one or more ECUs, wherein the second bus includes one or more ECUs configured as operating system functions; a gateway controller, configured to monitor and control communication between the first bus and the second bus; and a honeypot, configured to emulate the gateway controller but not interfere with benign communication between the first bus and the second bus, wherein the honeypot is further configured to monitor activity from remote devices and is located on the first bus. Attached Figure Description

[0006] Figure 1 A schematic basic depiction of electromechanical system 2 is shown.

[0007] Figure 2 A schematic basic depiction of electromechanical system 2 is shown, which has industrial automation components that communicate with each other and with other network users using fieldbus.

[0008] Figure 3 This is an example of an in-vehicle network that includes such a honeypot system.

[0009] Figure 4 This is an example flowchart illustrating the process and methods of using honeypots to combat attacks. Detailed Implementation

[0010] This document describes embodiments of the present disclosure. However, it should be understood that the disclosed embodiments are merely examples, and other embodiments may take various alternative forms. The figures are not necessarily to scale; some features may be enlarged or reduced to show details of specific components. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as a representative basis for teaching those skilled in the art to adopt the embodiments in various ways. As will be understood by those skilled in the art, various features illustrated and described with reference to any of the figures may be combined with features illustrated in one or more other figures to produce embodiments not explicitly illustrated or described. The combinations of illustrated features provide representative embodiments of typical applications. However, various combinations and modifications of features consistent with the teachings of this disclosure may be desired for a particular application or implementation.

[0011] Figure 1 A schematic basic depiction of electromechanical system 2 is shown. In this electromechanical system 2, particularly in industrial automation systems, machine control data 1 is acquired. Figure 1The example includes speed 1 (exchangeable with machine control data or the machine control reference below). Machine control data 1 is transmitted in the electromechanical system 2 within a network 3 having multiple network users 4, 6. For this purpose, control data 1 is sent in network 3 by a properly configured publisher using a data exchange standard that supports a publish / subscribe communication model. Network users 6, 4 receive the transmitted data via network 3 using the data exchange standard. In this case, the publisher performs the transmission in the form of network messages. The transmitted network messages are all intended for subscribers who are separate from the publisher and can be selected as needed. Subscribers selectively receive network messages containing their desired control data 1 (preferably under event control in each case) or select said network messages; additionally or alternatively, relevant subscribers may also selectively obtain the desired control data 1 from the received / analyzed network messages. Network messages can be transmitted via the Controller Area Network (CAN) protocol or any other communication method.

[0012] In the case of the industrial automation system 2 shown, the machine controller 4 of the electromechanical system 2 is incorporated into network 3 as a network user, specifically, firstly via fieldbus 21 connecting the machine controller 4 to the industrial automation components; and secondly via asynchronous network segment 27 connecting the machine controller 4 to other IT components (such as, for example, PCs). The machine controller 4 can be configured indiscriminately as a subscriber and / or publisher. If configured as a publisher, it provides message identifier 7 to control data 1, encodes or decodes the control data using a data exchange standard to generate a network message, and sends the network message via network 3. If the machine controller 4 is configured as a subscriber, it receives network messages intended for that subscriber (which is the machine controller 4) via network 3 using message identifier 7, and decodes the network message using a data exchange standard to generate usable control data 1.

[0013] The electromechanical system 2 is designed to communicate with industrial automation components primarily via a fieldbus 21. The machine controller 4 has an integrated PLC 14 and an equally integrated CNC 15. Visualization of the machine control data 1 is performed via a display 16, also integrated into the machine controller 4. Furthermore, the machine controller 4 has a port for a USB flash drive 17 for exchanging control data within a specific location not incorporated into the network 3. Additionally, a hard disk / SSD 18 is present, which acts as the machine controller's internal data storage, and on which control data 1 is also stored, buffered, and exchanged between various modules. The fieldbus 21 connects the machine controller 4 to two drive controllers 22 and 23. An electric motor 25 is started by the drive controller 23. The drive controller 22 actuates a servo motor 24. A tachometer 26 is used to return instantaneous speed 1 (or other data used for actuating and / or monitoring the servo motor 24) to the drive controller 22. Speed ​​1 is also transmitted to the machine controller 4 via the fieldbus 21, where it is processed according to the invention and used for communication. To ensure the consistency of control data 1 (especially its consistency over time), a clock is provided, among other things, for the system time 19 of machine controller 4. Control data 1 can be provided with a system time, particularly a system time synchronized throughout the system, for example, in the form of a timestamp using clock 19.

[0014] Network 3 can also use asynchronous network segment 27 to establish communication connections between electromechanical system 2 or components of electromechanical system 2 and a network architecture based on asynchronous (and non-real-time compatible) network protocols. In alternative embodiments, synchronous network segments can also be utilized. Asynchronous network segment 27 has been used to integrate industrial PC 6. Industrial PC 6 also has an internal hard disk / SSD 18 and a port for USB flash drive 17 (see above); in addition, a CD / DVD drive 33 is shown in an exemplary manner, which can also be used to load or forward control data 1 transmitted according to this disclosure. Various programs run on industrial PC 6, wherein an OPC-UA compliant application entity 30 and a PC application 31 (e.g., a control or simulation tool) for control data 1 are shown in an exemplary manner. In the exemplary embodiment shown, the data exchange standard is OPC-UA. The OPC-UA compliant application entity 30 of industrial PC 6 is used to provide OPC-UA compliant functionality on commercially available industrial PC 6, particularly communication via OPC-UA. Communication of control data according to this disclosure is achieved by receiving, transmitting, decoding, or encoding control data 1 via an OPC-UA compliant application 30, and then bidirectionally exchanging it with any PC application 31, which can be selected as needed, for the control data 1. Furthermore, control data 1 becomes exchangeable with other network users 34, 35, 36, 37, and 38 via an OPC-UA compliant interface. For this purpose, each network user 4, 6, 34, 35, 36, 37, and 38 also has an OPC-UA compliant interface and / or application.

[0015] Asynchronous network segment 27 was additionally used in the incorporation architecture:

[0016] The office PC 34, which works in conjunction with the EDGE (edge) computing system 35, allows for the relocation of analytical or computational tasks, such as those related to the electromechanical system 2. Part of the asynchronous network segment 27 is also a wireless transmitter 20, which is similarly used for transmitting control data 1, etc.

[0017] The laptop 36, tablet 37, and standalone PC 38 also communicate via the wireless transmitter 20.

[0018] Network connection to a cloud 66 accessible via the Internet (e.g., for storing control data 1 with global availability, for example for preventive maintenance or analysis of electromechanical system 2).

[0019] exist Figure 1In the exemplary embodiment shown, machine controller 4 is initially configured as a publisher and simultaneously as a subscriber. For this purpose, machine controller 4 is incorporated into electromechanical system 2 as a network user and can transmit control data 1 on machine controller 4 throughout network 3. In the illustrated publisher configuration, from the perspective of machine controller 4, three publisher paths 28 are provided: one leading from machine controller 4 to industrial PC 6, one to EDGE computing system 35, or as an entry point for one of office PCs 34, and one to drive controller 22. For this purpose, drive controller 22 has an integrated drive machine controller (not shown here) or an integrated drive PLC. Publisher path 28 is a physical and / or virtual path using the communication architecture of network 3 and is physically implemented, for example, by means of Ethernet and / or by means of wireless transmitter 20 and / or by means of fieldbus 21 (this also applies to subscriber path 29 with necessary modifications in detail, as described below).

[0020] Additionally, when the machine controller 4 is configured as a publisher, it provides a message identifier 7 for the control data, encodes the control data into a network message using a communication protocol, and sends the network message via network 3. In the illustrated exemplary embodiment, there are network users 6 and 35 configured as subscribers in asynchronous network segment 27 who receive control data 1 published by the machine controller 4 according to this disclosure. As a result, control data 1 from the electromechanical system 2 is available on the office PC 6 and in the EDGE computing system 35. Specifically, the industrial PC 6 has an OPC-UA compliant application entity 30, which is an application running on the industrial PC and communicates bidirectionally with the target PC application 31 for the control data 1, and transmits the control data 1 exchanged in an OPC-UA compliant manner. Typically, such an OPC-UA compliant application entity 30 or an OPC-UA compliant application can exist on each of the network users 4, 6, 34, 35, 36, 37, and 38. Meanwhile, there is a drive controller 22 configured as a subscriber, which receives control data 1 from machine controller 4 using publisher path 28 (from the perspective of machine controller 4); this can be physically done via fieldbus 21, so that communication of control data 1 can also be done in real time.

[0021] Meanwhile, machine controller 4 is configured as a subscriber (specifically, as above in the case of being configured as a publisher, in each case as integrated control PLC 14). In this case, it receives control data from industrial PC 6 using subscriber path 29 (from the machine controller's perspective).

[0022] Figure 2A schematic basic depiction of an electromechanical system 2 is shown, which has industrial automation components communicating with each other and with other network users or automation components using a fieldbus 44. The fieldbus 44 can be any type of communication bus, such as or similar to a CAN bus. A fieldbus ring topology 44 can connect multiple machine controllers 4, 39, 40, 41, 42 (collectively referred to below as 4+ for simplicity) to communicate with each other in real time; this can be, for example, a Sercos fieldbus, an EtherCAT fieldbus, a Profinet fieldbus, or a TSN-based fieldbus or a real-time compatible TSN network. In the exemplary embodiment shown, the fieldbus ring topology 44 is a double ring in opposite directions to provide redundancy, for example, suitable for safety applications. Alternatively, a star topology (or any other topology) can be implemented for TSN using a TSN-compatible switch. Machine controllers 4, 39 can have industrial automation components connected to them. In one example, machine controller 4 can act as a master. Machine controller 40 has a drive controller 43 connected to it via a real-time communication medium such as fieldbus 21, which has an integrated machine controller (e.g., PLC). In addition, two other drive controllers 22 are connected, each influencing either a servo motor 24 or an electric motor 25. Machine controller 41 has only a drive controller 43 connected to it via fieldbus 21, which has an integrated machine controller influencing a servo motor 24 with a tachometer 26; in each case, the tachometer 26 is used to return speed 1 to drive controller 43. Finally, machine controller 42 has drive controllers 22 and 43 connected to it, drive controller 22 having a connected servo motor 24 / tachometer 26 combination, and drive controller 43 having an integrated machine controller and an electric motor 25 influenced thereby.

[0023] Furthermore, according to this disclosure, publish / subscribe communication paths 45 that can be implemented virtually or physically can be shown. For example, they can be physically implemented by means of a fieldbus ring topology 44 or by utilizing other communication connections not shown here. Machine controller 4 is configured as a publisher and transmits control data acquired from machine controller 41 via communication path 45; in this respect, machine controller 41 is configured as a subscriber. Simultaneously, machine controller 4 is configured as a subscriber to control data 1 acquired from machine controller 41; in this respect, machine controller 41 is configured as a publisher. Meanwhile, machine controller 4, configured as a subscriber, acquires published control data from machine controller 42, which is the publisher. According to this disclosure, control data can also be transmitted by drives 22, 43. For this purpose, machine controller 39 is configured as a subscriber to control data 1 published by drive controller 43, which has an integrated machine controller and is connected to machine controller 41 via fieldbus 21 as a publisher. Simultaneously, drive controller 43 connected to machine controller 42 also acquires control data 1 from drive controller 43 connected to machine controller 41. Finally, the drive controller 43, connected to the machine controller 40, is configured as a publisher and publishes (in particular) control data received by the machine controller 41 via communication path 45, in which case the machine controller 41 is configured as a subscriber. Both direct communication via the fieldbus ring topology 44 and communication via the illustrated publish / subscribe communication path 45 can occur in real time.

[0024] Figure 3 This is an example of an in-vehicle network that includes such a honeypot system. Vehicle system 301 may include a first CAN bus network 303 and a second CAN bus network 305. One of the CAN bus networks may include lower-critical systems and ECUs connected to that network, such as telematics systems, navigation systems, multimedia systems, etc. The other CAN bus network may include higher-critical systems. Such higher-critical systems may be used to operate the vehicle, such as braking systems (e.g., any system-related ECUs), electronic throttle control, engine control units, etc. Although separate bus networks may exist within vehicle system 301, a gateway 307 may be present for communication between different networks within the vehicle.

[0025] In embodiments of the described system, a honeypot 309 may exist as a security mechanism. The honeypot 309 can act as a security mechanism to thwart attackers by serving as a distraction. The honeypot 309 can thwart attackers by emulating vehicle data. However, the honeypot 309 may not actually communicate with the operating ECUs that control vehicle functions. In one example, the automotive honeypot 309 may attempt to emulate the entire vehicle, particularly devices connected to a remote network. The honeypot 309 can thus emulate communication with various ECUs; however, the honeypot 309 may not interfere with benign communication between the various ECUs communicating with each other on the bus (e.g., not an attack or vulnerability). An example is an internet connection to an infotainment system, or a vehicle-to-vehicle (V2V) or vehicle-to-everything (V2X) controller in a highly autonomous or fully autonomous vehicle.

[0026] In one embodiment, a vehicle can utilize a fake gateway controller to act as a honeypot. A typical gateway controller might be a target of interest for attackers because it connects multiple buses of the vehicle to each other, similar to a router. However, these buses may have different levels of security criticality. One security practice might be to avoid connecting any security-critical ECUs to a network of controllers that have connections to external networks. Therefore, the infotainment system on CAN A wouldn't be directly connected to a security-critical ECU like the drivetrain or brakes on CAN B.

[0027] In one embodiment, any ECU 311 can be used as a honeypot 309, and therefore the honeypot 309 can be configured to emulate the ECU. For example, the honeypot 309 can be configured to run dummy commands; however, instead of communicating with active vehicle components (e.g., like an engine ECU), the honeypot 309 can run commands to emulate the kind of data communication that typically occurs between the component the honeypot is mimicking and various vehicle components. Therefore, the honeypot is not limited to simply emulating gateways between various vehicle buses; it can be implemented with any vehicle component.

[0028] In one embodiment, ECU 311 may be a powertrain ECU on a safety-critical bus, or a combination of multiple honeypot ECUs. In another embodiment, the honeypot may be deployed on every vehicle in a fleet, or only on randomly selected vehicles. Honeypot 309 may also include vulnerable code or software loaded into the memory of honeypot 309, or a vulnerable ECU communicating with honeypot 309, or any other ECU. Therefore, such a vulnerability could potentially lure an attacker. Typically, attackers need multiple vulnerabilities to gain the level of control they require to deploy a full-scale attack, but such vulnerable code eliminates this need.

[0029] Honeypots can possess several potential attack surfaces that attackers can exploit. One could be determining which module responds to which ID and message at the end of any CAN message. This might require brute force and reverse engineering, which could be detected by the honeypot and even further encouraged by spoofed responses to CAN messages. In another example, an attacker could take over the infotainment system. From this point, the attacker could determine how to flash new firmware onto the CAN controller portion of the infotainment system (e.g., the software or hardware operating with the CAN controller). From there, the attacker could send arbitrary CAN messages to the CAN bus to see which controller responds to which CAN ID message. Honeypot 309 could be used to identify such activity, such as arbitrary CAN messages, which CAN bus the message is sent to, and which controller will respond to which CAN ID message. Honeypot 309 could also serve as a convergence point for multiple CAN IDs and messages, actively responding to them to lure attackers to it.

[0030] Honeypot 309 can also be used to monitor secure flashing. For secure flashing (and other diagnostics) of controllers connected to the CAN bus in a vehicle, the Unified Diagnostic Service (UDS) is used. The security signature of the UDS can be a seed / key algorithm, which may typically require some form of brute-force / data collection to break. The honeypot can simulate such a seed to lure an attacker into attacking a device. The vehicle system can then collect information about the attacker and their capabilities. Such information can include the location where the attack began, the attacker's capabilities, and other similar information.

[0031] In another example, if an attacker has physical access to the car, they can directly flash the microcontroller using the open JTAG (or SPI, i2C) interface. A honeypot can exploit a fake JTAG interface, presented to the attacker (physically visible on the microcontroller), to deceive them into attacking the honeypot. Furthermore, instead of simply forging the JTAG interface, the system can use the honeypot to forge a complete microcontroller with a JTAG (or other similar) interface.

[0032] In yet another embodiment, the system can enable the honeypot to record (e.g., store) what the real gateway did in the past and replay those actions and commands. Therefore, the honeypot and the system can have information for replicating the past actions of the real gateway, including the type of data communication and which ECU or vehicle component the data was destined for.

[0033] Systems or honeypots can leverage records of what a real gateway has done in the past. For example, a system can record gateway operations of an actual honeypot (not the gateway) and enable the honeypot to simulate those operations. Replay can utilize known responses to observed states and transitions to attempt to mimic the honeypot's simulation. Systems and honeypots can also simulate gateways using rule-based systems. For example, a system or honeypot can determine whether a message (e.g., message x) originates from CAN bus A, then transition it to a different message (e.g., message y) for CAN bus B, potentially waiting for a threshold time (e.g., two seconds), before sending a reply from CAN bus B to CAN bus A.

[0034] although Figure 3 The operation is shown relative to the vehicle, but it can be used with any type of system. For example, similar technologies can also be used in the Internet of Things (IoT) or Industry 4.0 fields, where attacks are considered a risk, but honeypots are deployed more deeply within real systems.

[0035] Figure 4 This is an example flowchart of a process and method for using honeypots to combat attacks. In step 401, a processor or controller that is part of or communicates with the honeypot can receive data from one or more remote devices or ECUs that are communicating with remote devices. The data can be of any type, such as communication commands, notifications, or any other data. In step 403, the system can monitor this data from the remote devices. The data can be analyzed to determine whether it needs to be transmitted to another receiver (e.g., another ECU) or executed.

[0036] In decision 405, the system can determine whether such data from a remote device originates from a potential attacker. The system can analyze the data for threat code or commands that might execute malware, viruses, security threats, etc. If the system determines that the data does not originate from an attacker, it can simply continue monitoring the data. The system may contain code or programs for monitoring such data to determine whether the activity originates from an attacker.

[0037] In step 407, the system can then perform countermeasures based on this determination. A potential countermeasure could be complete silence, and the system could therefore instruct no countermeasures to be taken, using a honeypot as a distraction. In another example, a honeypot can be used to log intrusions. Thus, a honeypot can log intrusion-related data such as IP addresses, MAC addresses, device names, commands, messages, identifiers, or other intrusion-related data. Such information can be analyzed locally or sent to a control center. Attacks can be analyzed locally or remotely (e.g., at a control center) to identify future security enhancements to other security mechanisms and ECUs, such as more robust code, to prevent such attacks from occurring in the future. For example, proactively responding to an intrusion by defaulting to the vehicle's limp-home mode (driving only at very slow speeds) or disabling certain components / controllers of the vehicle. Countermeasures can be one of the aforementioned countermeasures, or a combination of any of them.

[0038] The processes, methods, or algorithms disclosed herein are deliverable to / implemented by a processing device, controller, or computer, which may include any existing programmable electronic control unit or dedicated electronic control unit. Similarly, the processes, methods, or algorithms may be stored in various forms as data and instructions executable by a controller or computer, including but not limited to information permanently stored on non-writable storage media such as ROM devices and information reproducibly stored on writable storage media such as floppy disks, magnetic tapes, CDs, RAM devices, and other magnetic and optical media. The processes, methods, or algorithms may also be implemented in a software executable object. Alternatively, the processes, methods, or algorithms may be embodied, wholly or partially, using suitable hardware components—such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), state machines, controllers, or other hardware components or devices—or a combination of hardware, software, and firmware components.

[0039] While exemplary embodiments have been described above, these embodiments are not intended to describe all possible forms covered by the claims. The terms used in this specification are descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of this disclosure. As previously stated, features of various embodiments may be combined to form other embodiments of the invention that may not be explicitly described or illustrated. Although various embodiments have been described as providing advantages over or being preferred over other embodiments or prior art implementations, those skilled in the art will recognize that one or more features or characteristics may be compromised to achieve desired overall system properties, depending on the particular application and implementation. These properties may include, but are not limited to, cost, strength, durability, lifecycle cost, merchantability, appearance, packaging, size, maintainability, weight, manufacturability, ease of assembly, etc. Therefore, where any embodiment is described as less desirable than other embodiments or prior art implementations with respect to one or more characteristics, such embodiments are not outside the scope of this disclosure and may be desirable for a particular application.

Claims

1. A vehicle system comprising: a first vehicle bus, wherein the first vehicle bus comprises one or more electronic control units (ECUs) configured to operate, wherein the one or more ECUs are configured to communicate with a remote server; a second vehicle bus, wherein the second vehicle bus is configured to communicate with the one or more ECUs, wherein the second vehicle bus comprises one or more vehicle drive ECUs configured to operate vehicle drive functions; a gateway controller configured to control communication between the first vehicle bus and the second vehicle bus; and a honeypot configured to emulate vehicle data, wherein the honeypot is further configured to monitor activity from a remote attacker, wherein the honeypot is configured to emulate the gateway controller, and wherein the second vehicle bus and the one or more vehicle drive ECUs are not connected to the remote server.

2. The vehicle system of claim 1, wherein the honeypot is located on the first vehicle bus.

3. The vehicle system of claim 1, wherein the honeypot is located on the first vehicle bus, wherein the one or more ECUs comprise ECUs associated with an infotainment system of the vehicle or another non-safety critical system of the vehicle.

4. The vehicle system of claim 1, wherein the honeypot is configured to emulate the one or more vehicle drive ECUs.

5. The vehicle system of claim 1, wherein the honeypot is configured to log activity from the remote attacker.

6. The vehicle system of claim 1, wherein the honeypot comprises a memory that stores one or more software or hardware vulnerabilities.

7. The vehicle system of claim 1, wherein the honeypot is further configured to emulate communication with an additional ECU that is not in the vehicle, wherein the additional ECU comprises one or more software or hardware vulnerabilities.

8. A vehicle system comprising: a vehicle bus comprising one or more electronic control units (ECUs) configured to operate, wherein at least one of the one or more ECUs is configured to directly communicate with a remote server; a honeypot configured to emulate vehicle data, wherein the honeypot is further configured to monitor activity from an attacker of the one or more ECUs on the vehicle bus, wherein the honeypot comprises one or more security vulnerabilities; and one or more processors in communication with the honeypot, wherein the vehicle bus comprises a first vehicle bus and a second vehicle bus, wherein the first vehicle bus comprises one or more ECUs configured to communicate with the remote server, wherein the second vehicle bus is configured to communicate with the one or more ECUs, wherein the second vehicle bus comprises one or more vehicle drive ECUs configured to operate vehicle drive functions and not connected to the remote server.

9. The vehicle system of claim 8, wherein the honeypot is located on the first vehicle bus.

10. The vehicle system of claim 8, wherein the honeypot is located on the second vehicle bus. ​ 11. The vehicle system of claim 8, wherein the processor is configured to collect and analyze data associated with an attack from an attacker.

12. The vehicle system of claim 8, wherein the processor is configured to log activity of the honeypot in response to a communication between the remote device and the honeypot.

13. A system comprising: a first bus, wherein the first bus comprises one or more electronic control units (ECUs) configured to operate system components, wherein the one or more ECUs are configured to communicate with a remote server; a second bus, wherein the second bus is configured to communicate with the one or more ECUs, wherein the second bus comprises one or more ECUs configured to operate system functions; a gateway controller configured to monitor and control communications between the first bus and the second bus; and a honeypot configured to mimic the gateway controller but not interfere with benign communications between the first bus and the second bus, wherein the honeypot is further configured to monitor activity from a remote device and is located on the first bus, and wherein the second bus comprises one or more vehicle driving ECUs configured to operate vehicle driving functions and the second bus and the one or more vehicle driving ECUs are not connected to the remote server.

14. The system of claim 13, wherein the honeypot is further configured to determine whether the activity from the remote device is a remote attacker.

15. The system of claim 13, wherein the honeypot is further configured to determine whether the activity from the remote device is a remote attacker via sending data associated with the activity from the remote device to the remote server.

16. The system of claim 14, wherein the honeypot is further configured to mimic system communications in response to a determination that the remote device is a remote attacker.

17. The system of claim 14, wherein the honeypot is further configured to log activity from the remote device in response to a determination that the remote device is a remote attacker.

Images