Federal Fleet Cybersecurity

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.