The Federal Energy Management Program (FEMP) has developed resources to help fleet managers and information technology teams plan for the emerging cybersecurity vulnerabilities associated with modern vehicles. As vehicles become safer overall, the dangers change from distracted drivers to privacy intrusion and compromised operation. To help federal agencies understand the cyber-physical threats to modern vehicles—including connected and automated vehicles, telematics systems, and electric vehicle supply equipment (EVSE)—FEMP and the National Renewable Energy Laboratory (NREL) compiled recommendations for federal fleet teams procuring modern vehicle technologies.
The recommendations below are adapted from NREL's technical report, Vehicle Cybersecurity Threats and Mitigation Approaches.
Fleet Cybersecurity Toolkit
Vehicle Cybersecurity Threats and Mitigation Approaches
NREL, August 2019
Cyber Assessment Report of Level 2 AC Powered Electric Vehicle Supply Equipment
Idaho National Laboratory, May 2018
Telematics Cybersecurity Primer for Agencies
Volpe National Transportation Systems Center, June 2017
Cybersecurity Best Practices for Modern Vehicles
National Highway Traffic Safety Administration, October 2016
Modern vehicles are governed by electronic control units that communicate along internal broadcast networks, like the controller area network (CAN) bus. Access to the CAN bus—physically or remotely—coupled with exploitation of any existing security vulnerabilities, can allow hackers to control vehicles remotely. This is highlighted in a video from WIRED that shows security engineers manipulating a car remotely.
Fleet managers can work with their information technology and contracting colleagues to mitigate incidental risks created by modern vehicle technology. General mitigation efforts should include security practices like encrypted communications for any equipment communicating over cellular or wireless networks. Specific procurement recommendations that are particularly relevant to motor vehicles are detailed in the sections below.
Connected and Automated Vehicle Cybersecurity
Connected vehicles can communicate with other vehicles through a vehicular ad hoc network or with transportation infrastructure. Automated vehicles have the ability to operate without direct human intervention to some degree—from lane centering to fully independent operation without a steering wheel in the vehicle.
While strong evidence shows that vehicle safety features like automatic emergency braking can reduce the frequency and severity of accidents (see IIHS' news story about front crash prevention systems), this sophistication creates different risks associated with safety and privacy.
Mitigation Techniques for Connected and Automated Vehicles
Federal fleet managers may want to consider a third-party examination of connected and automated vehicles by completing independent vulnerability testing of vehicle models before operating, including threat modeling, documentation and literature review, reverse engineering, manual inspection, network and radio spectrum analysis, penetrating testing, and fuzz testing.
Manufacturers can mitigate cybersecurity risks associated with connected and automated vehicles by:
- Resorting to a safe operational mode if erroneous sensor data is detected, such as driver intervention with automation levels 1 through 3
- Using secure communication infrastructure, such as DSRC, on a system like the Department of Transportation’s Security Credential Management System; and including instruction detection and prevention systems like firewalls, secure shell verification of the network and the device, key management, private access point names, and password cryptography
- Incorporating secure authorization and authentication, encryption, and network segmentation for safety-critical messages and over-the-air updates in modern vehicles.
Procurement Recommendations for Connected and Automated Vehicles
The following procurement recommendations can help federal fleets mitigate risks to connected and automated vehicles.
- Any messages sent over the air to vehicles or stored elsewhere should be encrypted using FIPS 197 AES 256 algorithm and cryptographic modules that have been validated under FIPS 140, National Security Agency Type 1 or Type 2 standards, or equivalent standards demonstrated to be acceptable alternatives.
- Connected and automated vehicles and connected infrastructure should use a continuous monitoring system and inform the agency of any breach of data or vehicles, including unauthorized access, control, or operation immediately (within 12 hours).
- All data associated with connected and automated vehicles should be stored on Federal Risk and Authorization Management Program (FedRAMP)-certified cloud service providers.
- Connected and automated vehicles and connected infrastructure should include security and privacy controls that comport with National Institute of Standards and Technology (NIST) 800-53 standards, including intrusion detection and prevention systems that comport with NIST 800-94 product selection recommendations.
- Each vehicle and each external communicator should use a unique digital signature.
- The vendor should provide proof of independent security testing, results, and remediation.
- The vendor should perform patch management services, including pushing patches made available by the manufacturer or required by the agency; provide advance notice of patches that may take the vehicle or vehicle systems offline; and provide a patch management schedule to the agency.
- Log files for all infrastructure devices, physical access, and anti-malware should be retained online for 180 days and offline for three years.
- The vendor should comply with requests to be audited and provide responses within three business days to requests for data, information, and analysis from the agency. The vendor should provide support during audit activities and efforts. These audit activities may include, but are not limited to, requests for system access for penetration testing, vulnerability scanning, incident response, and forensic review.
Many fleets benefit from telematics—if used to their maximum extent, telematics could help reduce accidents significantly and help federal fleet managers save over $2,000 per vehicle in a given year (read more in the NREL technical report, Telematics Framework for Federal Agencies: Lessons from the Marine Corps Fleet). However, aftermarket telematics devices are physically connected to motor vehicles and provide data to a remote management system. Both of these aspects provide entry points for hackers if they are not properly secured.
Mitigation Techniques for Physical Threats to Telematics
Fleet managers can mitigate risks before installing telematics by:
- Adopting an agency system security plan with procedures and policies that includes telematics devices
- Inquiring with the U.S. Department of Homeland Security (DHS) and the U.S. Navy, which have navigated the procurement process previously to ensure their telematics units and vehicles are properly protected
- Working with reputable, trusted partners to install telematics devices
- Considering a third-party examination of telematics that includes independent vulnerability testing of telematics before operating, including threat modeling, documentation and literature review, reverse engineering, manual inspection, network and radio spectrum analysis, penetrating testing, and fuzz testing.
Telematics manufacturers can mitigate physical access risks by:
- Configuring telematics connection to vehicle as read-only and disabling write access to vehicle ECUs in telematics firmware
- Adding anti-tampering or layered security methods to the telematics device so that physical access to the device will not allow partial or complete access to the network; this should include ensuring that any default passwords or configurations are customized
- Assigning unique cryptographic keys to each telematics device so that knowledge of one key cannot be used to infiltrate other devices
- Disabling the ability for external users to read firmware code from telematics devices without authorization
- Using vehicle alerts for attack detection and curtailment as well as to encourage drivers to take protective action if necessary
- Employing secure coding practices and auditing the source code.
Mitigation Techniques for Remote Threats to Telematics
In addition to the mitigation techniques for physical access, telematics companies can further mitigate remote access risks by:
- Using multi-factor authentication to verify authorized access to the telematics network
- Securing remote endpoints that telematics devices use for operation
- Using false data injection mitigation methods, such as redundant verification safeguards
- Requiring user authorization and authentication for mobile over-the-air updates capable of updating firmware
- Encrypting over-the-air firmware updates, transmission of telematics data, and data housed remotely
- Incorporating the ability to revert to the prior firmware version if an over-the-air update fails or introduces vulnerabilities
- Consulting Volpe's Telematics Cybersecurity Primer for Agencies before making acquisition decisions.
Procurement Recommendations for Physical Threats to Telematics
The following procurement recommendations can help federal fleets mitigate physical access risks.
- Vendors should monitor network activity and install a tampering alarm in the telematics device that signals to the driver, fleet manager, and manufacturer cybersecurity team if an intrusion is detected.
- If purchasing on behalf of a military organization, ensure devices are compliant with authority to operate (ATO) requirements.
- Contractors should produce the appropriate documentation that their employees have undergone favorable background investigations for all personnel that support the server/system managing the data from the telematics devices.
- Formal nondisclosure agreements and conflict of interest agreements should be required from third parties that deal with government telematics devices in any way.
- Follow procurement recommendations and guidance presented by the U.S. General Services Administration (GSA) Blanket Purchase Agreement (BPA) procurement language for telematics devices.
Procurement Recommendations for Remote Threats to Telematics
The following procurement recommendations can help federal fleets mitigate remote access risks. These should be followed in addition to the recommendations listed in the Procurement Recommendations for Physical Threats to Telematics section.
- Require vendors to comply with all areas of FedRAMP security requirement baselines including provisions for cloud service providers, and ensure this accreditation is upheld with periodic reviews.
- Encrypt any messages sent over the air or data at rest using FIPS 197 AES 256 algorithm and cryptographic modules that have been validated under FIPS 140, National Security Agency Type 1 or Type 2 standards, or equivalent standards demonstrated to be acceptable alternatives.
- Require two-factor authentication to access the telematics device remotely, or at least ensure that single-factor access control has hardened hardware security to minimize replication, replay, distributed denial-of-service, or spoofing attacks.
- Require strong, unique passwords to have defense in-depth for communications from the vehicle-to-vendor servers and use multi-factor authentication to access the telematics network.
- Implement whitelisting and blacklisting of messages sent from the network to telematics devices to prevent unsafe commands.
Electric vehicles (EVs) fuel in a different manner than conventional vehicles—they communicate with EVSE during the charging process. Different types of EVSE have varying levels of communication capabilities. While some communication is essential to establish a connection and greater capabilities provide additional benefits such as power demand management and billing options, they also expose EVs to cybersecurity threats. There are three EVSE communication standards commonly used for federal fleet vehicles:
- J1772 Level 1 or 2 EVSE use pulse width modulation
- SAE J1772 Combined Charging System EVSE use power line communication
- CHAdeMO EVSE use certain CAN signals (the same network used by vehicles).
EVSE risk mitigation techniques vary by communication standard as detailed in the NREL Vehicle Cybersecurity Threats and Mitigation Approaches report and summarized in the illustration above. The following recommendations apply to EVSE from a general perspective.
Mitigation Techniques for Physical Threats to All EVSE
EVSE companies can mitigate physical access risks to all EVSE, including SAE J1772 Level 1 and Level 2, by:
- Removing all jacks that are externally accessible from the EVSE unit
- Incorporating strong encryption of the controller boards in the EVSE, including flash memory and board-to-board communication
- Including a tampering alarm or signal to the service provider
- Employing secure coding practices and auditing the source code.
Mitigation Techniques for Remote Threats to All EVSE
EVSE companies can mitigate remote access risks to all EVSE, including SAE J1772 Level 1 and Level 2, by:
- Using code-signing techniques for firmware updates to avoid potential tampering with firmware and EVSE operations
- Using Hypertext Transfer Protocol Secure (HTTPS) communication with the web server as a more secure communication method relative to Hypertext Transfer Protocol (HTTP).
Procurement Recommendations for Physical Threats to All EVSE
The following procurement recommendations can help federal fleets mitigate EVSE physical access risks.
- EVSE should be constructed without external control board physical access points or with the minimum access points required to function in a given setting:
- This includes, but is not limited to, RJ45 (ethernet), D-subminiature serial type connections (e.g., video graphics array [VGA]), and all forms of USB.
- If control board physical access points are required for general operation and maintenance, the ports should be secured from public access or concealed in a lockable enclosure.
- All communication and management of the system board should incorporate high-level encryption:
- Firmware should be encrypted, locked, or require signatures.
- All locally stored flash memory should be encrypted.
- All encryption techniques should use FIPS 197 AES 256 algorithm and cryptographic modules that have been validated under FIPS 140 or equivalent standards demonstrated to be acceptable alternatives.
- If EVSE includes ability for network connection, a tampering alarm should be incorporated to notify owner or service provider of all local or remote access attempts.
Procurement Recommendations for Remote Threats to All EVSE
The following procurement recommendations can help federal fleets mitigate EVSE remote access risks.
- Remote firmware updates should incorporate verification through code signatures and be provided by secure, FedRAMP-approved FTP servers.
- All data storage services that house information on remote servers should be approved with FedRAMP certification.
- All remote access to EVSE or management provider sites through a web server should require the use of secure HTTPS communication.