In July, WIRED
reported that "white-hat" hackers Charlie Miller and Chris Valasek hacked into and took remote control of an operating vehicle via its "infotainment" system
. In August, other hackers gained remote entry to another vehicle using a third-party telematics device connected to its OBD II port
. Use of these types of telematics devices has become increasingly popular for a variety of reasons ranging from insurance discounts to safety or improved efficiency.
While the WIRED report was alarming because it revealed the vulnerability of the vehicle’s infotainment and critical control systems to hacking, auto manufacturers have well-established recall processes and can move quickly to plug such holes. The newest situation with the third-party telematics device might be even more concerning because of the volume of device manufacturers and service providers. Many may not have the robust testing and recall systems of today’s auto manufacturers.
A vehicle is a mobile network of computers
The design of the Controller Area Network (CAN) in vehicles provides a key challenge for vehicle security. The CAN is an internal vehicle network that allows car components to communicate with each other without a host computer. When this communication system was created, all of those systems were closed and did not communicate outside the vehicle. As manufacturers optimized vehicles to work with smartphones, these internal networks have been opened to outside influence.
Hackers refer to these potential opportunities to access a system as "attack surfaces." Auto manufacturers have been quick to address these security gaps in the wake of the WIRED story. But managers of commercial auto and truck fleets should consider that aftermarket vehicle telematics systems may open additional attack surfaces and take proactive steps to manage this risk.
Strategy for commercial fleet owners
No networked computer system is entirely "hack-proof," as many government agencies and businesses can attest. In most cases, companies accept that the benefits of connectedness outweigh the potential risks. To provide utmost protection, however, defensive strategies must be built into the product development cycle and continually tested and upgraded even after the product is deployed.
As companies consider the benefits of a variety of vehicle telematics systems, a few additional questions in the vendor selection process are warranted:
- If the device includes cellular, wireless or Bluetooth communication capabilities, what is the risk analysis process used to design access security into the devices?
- Is there an "authentication protocol" that only allows the device to communicate with a trusted source or can anyone with the mobile number or other connection send commands to the device?
- What is the risk analysis process used to prevent the telematics device from transmitting commands to the vehicle? (It’s one thing for the device to receive information from the vehicle computer but a whole different challenge when it can send commands back to the vehicle.)
- Is message traffic to and from the device and the data stored on the device encrypted so that it cannot be read by others without the encryption key?
- How does the telematics vendor conduct ongoing penetration testing for its system?
- What is the process to continually update the software on the device as enhancements are made and security holes are closed? (Ideally, this should be over-the-air rather than requiring the vendor to have to install new software on the device manually.)
In this new world of an "Internet of Things" where all sorts of systems will communicate with the outside world, the answers to questions like these provide a sense of how much effort the telematics provider is putting into addressing security issues as a part of their business model.