NHTSA Cybersecurity Compliance Automotive Guidelines

NHTSA is developing a new online guidebook that will help automotive and highway safety stakeholders understand cybersecurity risks and the actions they can take to mitigate them. The guidebook will be an online tool released in phases and updated as new information and resources become available.

The following are some of the topics that will be addressed in the guidebook:

– Cybersecurity risks to vehicles and highway infrastructure

– Methods to reduce cybersecurity risks

– Technologies and processes to secure vehicles and highway infrastructure

– Laws, regulations, and standards related to automotive cybersecurity

– Cybersecurity research and development priorities

The purpose of the NHTSA Automotive Cybersecurity Guide

Vehicles are cyber-physical systems, and cybersecurity vulnerabilities could impact the safety of life. Therefore, NHTSA’s authority would be able to cover vehicle cybersecurity, even though it is not covered by an existing Federal Motor Vehicle Safety Standard. Nevertheless, as amended, motor vehicle and motor vehicle equipment manufacturers are required by the National Traffic and Motor Vehicle Safety Act to ensure that systems are designed to be free of unreasonable risks to motor vehicle safety, including those that may result due to the existence of potential cybersecurity vulnerabilities.

NHTSA believes that it is important for the automotive industry to make vehicle cybersecurity an organizational priority. This includes proactively adopting and using available guidance such as this document and existing standards and best practices. Prioritizing vehicle cybersecurity also means establishing other internal processes and strategies to ensure that systems will be reasonably safe under expected real-world conditions, including those that may arise due to potential vehicle cybersecurity vulnerabilities.

The automotive cybersecurity environment is dynamic and is expected to change continually and, at times, rapidly. NHTSA believes that the voluntary best practices described in this document provide a solid foundation for developing a risk-based approach and important processes that can be maintained, refreshed, and updated effectively over time to serve the needs of the automotive industry

Some key areas of focus would be:

1. Properly secure all vehicle systems and data in transit and at rest.

2. Implement security controls to prevent, detect, and respond to threats and vulnerabilities.

3. Educate and train employees on cybersecurity risks and best practices.

4. Regularly test and monitor systems to ensure they are functioning properly and effectively.

5. Maintain knowledge of emerging security threats and develop strategies to protect against them. 6. Respond to and investigate any potential security breaches.

7. Prepare and deliver security awareness training to employees.

8. Maintain and update records of security breaches and the measures taken to mitigate them.

9. Keep up to date with developments in security systems and trends.

10. Monitor compliance with security policies and procedures and report any deviations.

11. Perform any other security-related duties as required

Cybersecurity Best Practices for Modern Vehicles

Leadership Priority on Product Cybersecurity

The automotive industry needs to create corporate priorities and foster a culture that is prepared and able to handle increasing cybersecurity challenges.

Along this line, NHTSA recommends that companies developing or integrating safety-critical vehicle systems prioritize vehicle cybersecurity and demonstrate management commitment to doing so with the following actions:

•     Allocating dedicated resources within the organization focused on researching, investigating, implementing, testing, and validating product cybersecurity measures and vulnerabilities;

•     Facilitating seamless and direct communication channels though organizational ranks related to product cybersecurity matters; and

•     Enabling an independent voice for vehicle cybersecurity-related considerations within the vehicle safety design process.

Information Sharing

Executive Order 13691 – Promoting Private Sector Cybersecurity Information Sharing strongly encourages the development and formation of industry-specific Information Sharing and Analysis Organizations and calls on private companies, nonprofit organizations, executive departments, agencies, and other entities to “share information related to cybersecurity risks and incidents and collaborate in as close to real-time as possible.”

Vulnerability Reporting/Disclosure Policy

NHTSA supports additional mechanisms for information sharing, such as a vulnerability reporting/disclosure program. These have been effective in other sectors and would likely benefit the motor vehicle industry. Automotive industry members should consider creating their vulnerability reporting/disclosure policies or adopting policies used in other sectors or technical standards. Such policies would provide any external cybersecurity researcher with guidance on how to disclose vulnerabilities to organizations that manufacture and design vehicle systems.

A vulnerability reporting/disclosure policy should inform cybersecurity researchers how a company plans to interact with them. In general, the company’s expectations for the relationship between companies and cybersecurity researchers should be described in detail and publicly available.

Vulnerability / Exploit / Incident Response Process

The automotive industry should have a documented process for responding to incidents, vulnerabilities, and exploits. This process should cover impact assessment, containment, recovery and remediation actions, and the associated testing.

This process should clearly outline the roles and responsibilities of each responsible group within the organization and specify any internal and external coordination requirements. The process should be designed to ensure rapid response without sole dependence on any single person.

The automotive industry should periodically define metrics to assess its response process's effectiveness. In addition, companies should document details of each identified and reported vulnerability, exploit, or incident. These documents should include information that extends from onset to disposition with sufficient granularity to enable response assessment.

Self-Auditing

In addition to implementing a cybersecurity process based on a sound systems engineering approach, the automotive industry should document the cybersecurity process details to allow for auditing and accountability. Such documentation may include the following:

•     risk assessments,

•     penetration test results,

•     organizational decisions.

Further, such documents should be retained through the expected life span of the associated product. Persistent documents (such as cybersecurity requirements) should follow a robust version control protocol and be revised regularly as new information, data, and research results become available.

Risk Assessment

The automotive industry should develop and use a risk-based approach to assessing vulnerabilities and potential impacts and consider the entire supply chain of operations. This approach should involve an ongoing risk management framework to assess and mitigate risk over time.

At a minimum, organizations should consider cybersecurity risks to safety-critical vehicle control functions and PII. For example, a risk assessment process and the associated documentation should consider the following questions as suggested in the following modification of the documented NIST and CIS.

Penetration Testing and Documentation

The automotive industry should consider extensive product cybersecurity testing, including penetration tests. These tests should include stages that deploy qualified testers who have not been part of the development team and are highly incentivized to identify vulnerabilities.

All reports resulting from these penetration tests should be maintained as part of the internal documentation associated with the cybersecurity approach. Documentation should identify the testers, their qualifications, and their recommendations.

These penetration testing reports should also document the disposition of detected cybersecurity vulnerabilities. If a vulnerability is fixed, the details of the fix need to be documented. If a vulnerability is not addressed, the reasoning behind the acceptability of the underlying risk should be documented as well. In addition, the penetration testing reports should note the authorized approving authority for each vulnerability.

Self-Review

The automotive industry should establish procedures for internal review and documentation of cybersecurity-related activities. This will assist companies in better understanding their cybersecurity practices and determining where their processes could benefit from improvement. One suggested approach is for the automotive industry to produce annual reports on the state of their cybersecurity practices. These annual reports could discuss the current state of implemented cybersecurity controls, findings from self-auditing activities, and records maintenance. Information concerning the corporate structure related to cybersecurity and all other cybersecurity efforts would be valuable information for stakeholders and consumers.

Fundamental Vehicle Cybersecurity Protections

The following recommendations are based on what NHTSA has learned through its internal applied research as well as from stakeholder experiences shared with NHTSA. These recommendations do not form an exhaustive list of actions necessary for securing automotive computing systems, and all items may not be applicable in each case. These protections serve as a small subset of potential actions which can move the motor vehicle industry toward a more cyber-aware posture.

Limit Developer/Debugging Access in Production Devices

Software developers have considerable access to ECUs. Such ECU access might be facilitated by an open debugging port or a serial console. However, developer access should be limited or eliminated if there is no foreseeable operational reason for the continued access to an ECU for deployed units.

If continued developer access is necessary, any developer-level debugging interfaces should be appropriately protected to limit access to authorized privileged users. Physically hiding connectors, traces, or pins intended for developer debugging access should not be considered a sufficient form of protection.

Control Keys

Any key (e.g., cryptographic) or password which can provide an unauthorized, elevated level of access to vehicle computing platforms should be protected from disclosure. Any key obtained from a single vehicle’s computing platform should not provide access to multiple vehicles.

1.1.3        Control Vehicle Maintenance Diagnostic Access

Diagnostic features should be limited as much as possible to a specific mode of vehicle operation which accomplishes the intended purpose of the associated feature. Diagnostic operations should be designed to eliminate or minimize potentially dangerous ramifications if they are misused or abused outside of their intended purposes.

For example, a diagnostic operation that may disable a vehicle’s brakes could be restricted to operating only at low speeds. In addition, this diagnostic operation might not disable all brakes at the same time, and/or it might limit the duration of such diagnostic control action.

Control Access to Firmware

In many cases, firmware precisely determines the actions of an ECU. Extracting firmware is often the first stage of discovering a vulnerability or structuring an end-to-end cyberattack.

Developers should employ good security coding practices and tools that support security outcomes in their development processes.

Many platforms may be able to support whole disk encryption of external non-volatile media. In this case, encryption should be considered a useful tool in preventing the unauthorized recovery and analysis of firmware.

Firmware binary images may also be obtained from a firmware updating process. Organizations should reduce opportunities for a third party to obtain unencrypted firmware during software updates.

Limit Ability to Modify Firmware

Limiting the ability to modify firmware would make it more challenging for malware to be installed on vehicles. For example, using digital signing techniques may make it more difficult and prevent an automotive ECU from booting modified/ unauthorized and potentially damaging firmware images. In addition, firmware updating systems that employ signing techniques could prevent the installation of a damaging software update that did not originate from an authorized motor vehicle or equipment manufacturer.

Control Proliferation of Network Ports, Protocols and Services

The use of network servers on vehicle ECUs should be limited to essential functionality only and services over such ports should be protected to prevent use by unauthorized parties. Any software listening on an internet protocol (IP) port offers an attack vector that may be exploited. Any unnecessary network services should be removed.

Use Segmentation and Isolation techniques in Vehicle Architecture Design.

Privilege separation with boundary controls is important to improving the security of systems. Logical and physical isolation techniques should be used to separate processors, vehicle networks, and external connections as appropriate to limit and control pathways from external threat vectors to cyber-physical features of vehicles. Strong boundary controls, such as strict white list-based filtering of message flow between different segments, should be used to secure interfaces.

Control Internal Vehicle Communications

Critical safety messages could directly or indirectly impact the operations of a safety-critical vehicle control system.

Sending safety signals as messages on common data buses should be avoided when possible. For example, providing an ECU with dedicated inputs from critical sensors eliminates the common data bus spoofing problem.

If critical safety information must be passed across a communication bus, this information should reside on communication buses segmented from any vehicle ECUs with external network interfaces. A segmented communications bus may also mitigate the potential effects of interfacing insecure aftermarket devices to vehicle networks.

Critical safety messages, particularly those passed across non-segmented communication buses, should employ a message authentication scheme to limit the possibility of message spoofing.

Log Events

An immutable log of events sufficient to reveal the nature of a cybersecurity attack or a successful breach should be maintained and periodically scrutinized by qualified maintenance personnel to detect trends of cyber-attack.

Control Communication to Back-End Servers

Widely accepted encryption methods should be employed in any IP-based operational communication between external servers and the vehicle. Consistent with these methods, such connections should not accept invalid certificates.

Control Wireless Interfaces

In some situations, it may be necessary to exert fine-grained control over a vehicle’s connection to a cellular wireless network. The industry should plan for and design-in features that could allow changes in network routing rules to be quickly propagated and applied to one, a subset, or all vehicles.

Education

NHTSA believes that an educated workforce is crucial to improving the cybersecurity posture of motor vehicles.

The NHTSA guide can be found here.

Aftermarket device manufacturers should consider that their devices are interfaced with cyber-physical systems, and they could impact the safety of life. Even though the system's primary purpose may not be safety-related (e.g., telematics device collecting fleet operational data), if not properly protected, it could be used as a proxy to influence the safety-critical system behavior on vehicles. Aftermarket devices could also be brought on to all ages and types of vehicles with varying levels of cybersecurity protection on the vehicle side of the interface. Therefore, these devices should include strong cybersecurity protections on the units since they could impact the safety of vehicles regardless of their intended primary function.