NMFTA Telematics Security Requirements Matrix

These recommended security requirements are intended to be informative, not directional in nature. While all reasonable steps have been taken to ensure that the recommendations are well-supported by our research and third-party verification, NMFTA and the parties contributing to these recommendations do not accept liability or responsibility for any damage or harm incurred as a result of actions taken based upon these recommendations.

We would like to acknowledge the contributions of DOT/Volpe Center and the members of the Cybersecurity Requirements for Telematics Systems working group. At the time this report was published, named participants included Derek Held of Zonar Systems, several representatives from Geotab, Altaz Valani of Security Compass, Mark Zachos, President of DG Technologies, Richard M. Litwinczuk, Senior Cybersecurity Engineer, Land Cyber Mission Assurance Program DND, Jacob D'Aoust, Junior Researcher, DeepMicro Limited. The working group benefited greatly from the contributions of several other fleet managers and telematics service providers (TSPs) who wish to remain anonymous.

The authors would also like to acknowledge the contributions of the NMFTA Request for Proposal Contract Template Language (RFPCTL) working group.

After the US DOT/Volpe published “Telematics Cybersecurity Primer for Agencies” in June 2017, we wanted to create resources for use by our motor freight carrier members to procure new telematics systems such as Electronic Logging Devices (ELD). Starting with the telematics cybersecurity controls and recommendations made by the Primer, a working group was assembled to complete a detailed list of testable cybersecurity requirements for all the components of a telematics system. We are fortunate to have been able to collaborate with DOT/Volpe and to see the efforts of the working group come to fruition through the publication of this report, which is a natural refinement of the security controls defined in the Primer.

THE INFORMATION CONTAINED HEREIN IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE INFORMATION IS WITH THE USER.

The purpose of this document is to provide government agency Fleet Managers and private industry stakeholders (e.g. TSPs, carriers, OEMs, Tier 1 suppliers, and others) responsible for the selection and procurement of Telematics, Fleet Management Information Systems (FMIS) and/or ELDs with situational awareness of potential cybersecurity risks of deploying such systems. This report also delivers a comprehensive list of cybersecurity requirements that should be satisfied by all components of a Telematics, Fleet Management Information System (FMIS) and/or Electronic Logging Devices (ELD), including validation steps for federal agencies and private industry stakeholders when deploying such systems.

The audience for this report is the agencies and private industry stakeholders responsible for the selection and procurement of Telematics, Fleet Management Information Systems (FMIS) and/or ELDs, as was the case in the previously released “Telematics Cybersecurity Primer for Agencies” report. The working group believes that any stakeholder that must procure Telematics, FMIS and/or ELDs will also find the requirements outlined in this document relevant. The complete list of requirements outlined in Appendix A will remain a living document which can respond to feedback from industry and technical experts. The requirements are hosted at https://github.com/nmfta-repo/nmfta-telematics_security_requirements and readers are encouraged to check there for updates to, and to offer feedback on, the requirements.

The comprehensive list of cybersecurity requirements for Telematics, FMIS and/or ELDs presented here was developed in collaboration with a diverse working group. The requirements are prioritized and include references to public authoritative sources containing more information, should the reader require additional details. The complete listing will provide purchasers with sufficient information to prioritize the need for cybersecurity in the Telematics, FMIS and/or ELD as well as validate the presence of the controls upon delivery of a system.

It is the recommendation of the working group that agencies and private stakeholders use these cybersecurity requirements when procuring new Telematics, FMIS and/or ELDs as well as when evaluating their current systems when the need to evaluate cybersecurity arises. The working group continues to refine the requirements and the reader is encouraged to visit https://github.com/nmfta-repo/nmfta-telematics_security_requirements to obtain the most up-to-date copy of the requirements, which is also available in a supplier questionnaire format. The site should also be used to give feedback to the working group on ways that the requirements can be further refined. It is NMFTA’s recommendation that motor freight carriers use these requirements as a natural successor to “Telematics Cybersecurity Primer for Agencies.”

The complete list of cybersecurity requirements can be found in Appendix A. Requirements are prioritized for use by stakeholders via a Criticality field to encourage adoption incrementally. These requirements are presented for all the components of a Telematics, FMIS and/or ELD: Vehicle Connection, Connectivity/Communications, Mobile App, and Cloud or Back-end and must be taken in their entirety for any assurances of cybersecurity to be realized.

The deployment of Telematics, FMIS and/or ELDs in motor vehicles is pervasive today. As with any Information System (IS), it is the owner/operator of that system who bears the responsibility for managing the security of that system. This includes security of the information being collected, managed and stored, but also the security of the assets being monitored which – if not considered in procurement – could have their security posture worsened by the introduction of a Telematics, FMIS and/or ELD. In the case of agencies as the owners of an IS, their responsibility is detailed in the Federal Information Security Management Act of 2014[^1].

A core objective of this document is to provide information to owners of Telematics, FMIS and/or ELDs in the phases of procurement of these systems so they can manage risks to security. An additional objective is to provide comprehensive cybersecurity requirements that can be consulted by the owner and potential vendors to provide sufficient information that can prioritize the needs for cybersecurity in the Telematics, FMIS and/or ELD and validate the presence of the controls upon delivery of the system.

The approach taken to create this list included consultations with many authoritative sources of cybersecurity controls and then mapping them to the components of a Telematics, FMIS and/or ELD. To do this, the report considers a simplified model of a Telematics, FMIS and/or ELD. The four components of such a simplified system are broken down by Vehicle Connection, Connectivity/Communications, Mobile App, and Cloud or Back-end and are depicted in the figure below:

The Cybersecurity Requirements for Telematics Systems matrix uses the following terms for the components of a Telematics, FMIS and/or ELD:

• Vehicle Connection Device – The component of Telematics, FMIS and/or ELD that is connected to vehicle networks -- tractor and/or trailer. There may also be a Human Machine Interface (HMI) aspect to this component. In cases where the HMI is a separate device from that which connects to vehicular networks, then all the requirements identified as being applicable to the ‘Mobile App’ (see below) should be considered to apply to the HMI device.
• Connectivity/Communications – The component of a Telematics, FMIS and/or ELD which communicates data with the Cloud or Back-end (see below). This may or may not be the same device as the Vehicle Connection Device. In cases where they are the same device, both sets of the requirements identified as being applicable to a Vehicle Connection Device and the requirements identified as being applicable to Connectivity/Communications components should be considered to apply to the device.
• Cloud or Back-end – The component or components of a Telematics, FMIS and/or ELD which are internet facing, where data is collected, where commands or remote control of vehicular components are possible and where monitoring of the entire fleet or subsets thereof is made possible by dashboard or operations center features. In some cases, these components will be hosted by service providers, while in others they may be hosted by the owner. In either case, all the requirements identified as being applicable to Cloud or Back-end should be considered to apply to the device.
• Mobile App – The component of a Telematics, FMIS and/or ELD, which presents Human Machine Interfaces to drivers or other users of the system, may or may not have its own communications paths to the Cloud or Back-end and may or may not be hosted in a device separate from the Vehicle Connection Device, but is otherwise able to connect to and communicate with that vehicular component.

A goal of the working group was to ensure that stakeholders who procure equipment could also be capable of verifying that the equipment satisfies cybersecurity requirements. Therefore, each requirement includes a validation step which is intended to be executed by the purchaser. In some cases, the verification of the cybersecurity requirement requires more specialized knowledge than is reasonable to expect the purchaser to have. In these few cases, the validation steps recommend consulting a 3rd party report.

In recognizing that implementing cybersecurity for systems is an ongoing process for which there are rarely enough resources, each requirement has been each assigned a ‘criticality.’ These criticalities can be used to prioritize implementation by vendors or selection of vendors by purchasers.

We have avoided any requirements that are novel or otherwise unique in favor of referencing publicly available authoritative sources; at the time of drafting this report the authoritative references include:

1. National Institute of Standards and Technology, Computer Security Resource Center. “Federal Information Security Modernization Act (FISMA).” Last modified December 2014. Accessed February 2020. http://csrc.nist.gov/drivers/documents/FISMA-final.pdf
2. National Institute of Standards and Technology, Computer Security Resource Center. “Security and Privacy Controls for Information Systems and Organizations.” Last modified December 2020. Accessed May 2021. https://doi.org/10.6028/NIST.SP.800-53r5
3. CTIA Certification LLC. “Cybersecurity Certification Test Plan for IoT Devices.” (CCTPID) Last modified January 2021. Accessed June 2021. https://ctiacertification.org/wp-content/uploads/2020/10/CTIA-Cybersecurity-Test-Plan-1.2.2.pdf
4. ETSI Technical Committee Cyber Security (TC CYBER). “EN 303 645.” Last modified April 2020. Accessed May 2021. https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.00_30/en_303645v020100v.pdf
5. Cloud Security Alliance. “Consensus Assessment Initiative Questionnaire (CAIQ).” Last modified September 2019. Accessed May 2021. https://cloudsecurityalliance.org/artifacts/consensus-assessments-initiative-questionnaire-v3-1
6. Open Web Application Security Project (OWASP). “Application Security Verification Standard (ASVS).” Last modified March 2019. Accessed June 2019. https://github.com/OWASP/ASVS/raw/master/4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0-en.pdf
7. Cyber ITL. “Methodology.” Accessed June 2019. https://cyber-itl.org/about/methodology/
8. ISO/IEC. “29147:2018 Information technology – Security techniques – Vulnerability disclosure.” Last modified Oct 2018. Accessed June 2019. https://www.iso.org/standard/72311.html
9. Elazari, Amit. “#LegalBugBounty Hall of Fame.” Accessed June 2019. https://amitelazari.com/%23legalbugbounty-hof
10. The Building Security In Maturity Model. “BSIMM.” Accessed June 2019. https://www.bsimm.com/download.html
11. Open Web Application Security Project (OWASP). “Mobile Application Security Verification Standard (MASVS).” Accessed June 2019. https://github.com/OWASP/owasp-masvs/releases/tag/1.2RC
12. Klinedinst, D. CMU, US DOT, FMCSA Office of Analysis, Research and Technology et. al. . “Cybersecurity Best Practices for Integration/Retrofit of Telematics and Aftermarket Electronic Systems into Heavy Vehicles.” Lost modified May 11th 2020. Accessed May 12th 2020. https://rosap.ntl.bts.gov/view/dot/49248
13. DHS, Binding Operational Directive 20-01. Last modified September 2, 2020. Accessed Jan 18th 2021. https://cyber.dhs.gov/bod/20-01/
14. Open Web Application Security Project (OWASP). “Embedded Application Security Project.” Last modified September 2020. Accessed May 2021. https://owasp.org/www-project-embedded-application-security/

Additional authoritative sources will be included in future versions of this report.

With regards to the FMCSA report "Cybersecurity Best Practices for Integration/Retrofit of Telematics and Aftermarket Electronic Systems into Heavy Vehicles" reference which is included in the references: the Cybersecurity Requirements for Telematics Systems Requirements matrix is aligned with the guidelines recommended by the FMCSA in their report. However, there are some differences between the audiences of the FMCSA report and the Cybersecurity Requirements for Telematics Systems Requirements matrix and also some requirements in the matrix which do not have a corresponding guideline in the FMCSA report. For more details on these topics please see the NMFTA bulletin on the FMCSA "Cybersecurity Best Practices for Integration/Retrofit of Telematics and Aftermarket Electronic Systems into Heavy Vehicles."

Each requirement captured is augmented with Criticality, Verification Steps, Public Requirements References, etc. A sample requirement is shown below:

The example requirement above demonstrates the form in which each requirement is presented in Appendix A.

UID

shows a unique value assigned to the requirement for easy reference

CATEGORY

groups like requirements together

CRITICALITY

assigns a ‘priority’: a recommendation to the purchaser for each requirement:

• High: the working group advises that purchasers do not accept proposals that do not meet all ‘High’ criticality requirements
• Medium: the working group advises that purchasers may accept proposals that do not meet ‘Medium’ criticality requirements when the failure is justifiable or mitigated by the vendor
• Low: the working group advises that purchasers may accept proposals that do not meet ‘Low’ criticality requirements

CHILDREN

Captures the applicable component categories; shows to which of the components of the Telematics, FMIS and/or ELD that this requirement applies by listing the child requirements that are specific to Cloud, Connectivity, Mobile, or Vehicle Connection components.

PUB_REFS

Captures the public requirements references / descriptions from external authoritative requirements as were known to the working group at the time of this draft. These references are included so that

• Purchasers can easily refer to the referenced sections of the document for further clarification on what are acceptable norms when evaluating vendor responses to RFPs AND
• Vendors can use the referenced sections of the documents for establishing common language and terms in the responses to RFPs to amortize the costs of developing detailed responses.

STATEMENT

Shows the requirement as it applies to the components of a Telematics, FMIS and/or ELD. The working group made every effort to make these requirements shorter and more succinct than the authoritative external references.

VERIFICATION

shows the steps which can be executed by purchasers to confirm that a given Telematics, FMIS and/or ELD satisfies this requirement. There are several cases where the working group does not expect that purchasers will perform their own verification. Where it is recommended that either a third party be engaged to provide an analysis which can be used by the purchasers to verify vendor claims, or that the vendor perform a demonstration that the requirement is satisfied which can be observed and confirmed by the purchaser. In such cases, rationale will be given. Due to the costly nature of delegating to a third party or of preparing a demonstration, this will only be recommended in cases where the requirement has been listed as having high Criticality. Because of the high Criticality of these requirements, it would be ideal to verify them relying on both a third party and a demonstration; the recommendation of the working group is that one or the other is sufficient.

• In the context of verification via reports from a third party it is acceptable to either, as a purchaser, contract the third party for testing or to verify documentation provided by a third party contracted by the vendor.
• In the context of demonstration by the vendor, it is important that the purchaser ensure the demonstration covers the non-functional aspects of these requirements, (e.g. for secure boot it is not sufficient to demonstrate that valid images are bootable, but rather it is necessary to demonstrate that tampered images are not bootable.)

COMMENT

Shows comments or notes from the working group.

This project available in a supplier questionnaire format, one sheet for each of Vehicle Connection, Connectivity/Communications, Mobile App, and Cloud or Back-end.

These questionnaires can be sent in request to vendors to evaluate each of the applicable components of a telematics system that is being procured.

The working group has produced the comprehensive list of cybersecurity requirements for Telematics, FMIS and/or ELDs found in Appendix A. These requirements are prioritized via Criticality and assigned to one or more components in a generic Telematics, FMIS and/or ELD. They also include references to public, authoritative sources for more details on the requirement for the benefit of additional understanding on the part of the purchaser and vendor.

The working group recommends that federal agency fleet managers and private industry stakeholders use these requirements when procuring new Telematics, FMIS and/or ELDs, as well as when evaluating their current systems when the need to evaluate cybersecurity arises. It is NMFTA’s recommendation that motor freight carriers use these requirements as a natural successor to “Telematics Cybersecurity Primer for Agencies.” The requirements contained in this report complete several key areas which are missing in the Primer.

The working group continues to refine the requirements and the reader is encouraged to visit https://github.com/nmfta-repo/nmfta-telematics_security_requirements to obtain the most up-to-date copy of the requirements, which is also available in a supplier questionnaire format. The site should also be used to give feedback to the working group on ways that the requirements can be further refined.

In this section the reader will find all of the requirements of the TSRM. The latest version can be found at https://github.com/nmfta-repo/nmfta-telematics_security_requirements

The vendor's system shall record event and system logs

Ideally the logs are immutable, backed up, and retained for a certain period of time

Vendor devices will implement least privilege for the memory spaces of processes handling protected data. i.e. data in-use, of the categories of sensitive protected data above, or shall be segmented from software components which do not handle such data. Acceptable segmentations include Mandatory Filesystem Access Controls and Mandatory Volatile Memory Access Controls.

e.g. a Linux system with MAC configured to deny access to the processes dealing with protected data and also denying debugger access to the memory space of those processes.

All actions taken by the vendor's telematics system that are capable of supporting access controls shall be configured such that each user account or process/service account are assigned only the minimal privileges required to perform the specific, intended, actions of the user or process/service account.

This principle underpins system security

The vendor's system shall employ cryptographic authentication to prevent unauthorized access to telematics systems and data.

Identity management is critical

e.g. PINs, single-sign on with carrier’s identity provider (SAML or other), vendor managed identity provider (SAML or other)

The vendor shall identify all instances where the telematics system includes actions that cannot support access authentication and/or execute with elevated privileges

Identifying information about the connected devices will not be made available without authentication first.

e.g. it should not be possible to identify the device type nor firmware version by port scanning a connected device. Also, it should not be able to determine that a vehicle is operational or not via non-authorized connections.

All remote access methods and possible remote actions to/on telematics system shall be documented.

For all components of the system, the vendor shall provide a listing of all wireless communication interfaces to the system and specify how the interfaces can be configured and/or disabled.

e.g. Bluetooth, cellular, satellite, Wi-Fi hotspot, Wi-Fi client, infrared, NFC, RFID

The vendor shall not use any deprecated encryption+authentication on any Wi-Fi interface of the device. At the time of drafting this includes WEP, WPS or open/none.

The vendor shall implement, for all Bluetooth interfaces, pairing that must be specifically allowed by physical controls on the device and be time-limited. Furthermore, pairing will not use legacy pairing or passkey entry.

Any and all software or firmware implementing wireless interface encrytion+authentication (those satisfying AC-061 and AC-062 above) will be prepared for future deprecation of methods. i.e. That software/firmware is upgradable.

Authentication attempts to the vendor’s devices and backends shall be rate-limited to an industry accepted rate.

All authentication offered on device-local interfaces shall expect credentials which are unique to each device instance and uncorrelated to any and all public information about the device.

This requirement applies to many common facilities found on devices. e.g. local management portals, local Wi-Fi access points, Bluetooth pairing codes, local ssh servers, local serial console logins

All components of the vendor's system shall be configured to utilize the principle of least functionality and use only the services necessary for secure operations of the system. Additionally, customers should have the option of disabling any features they do not want or do not need by having unnecessary services’ executables removed or at least disabled such that their execution (by even superuser) is not possible in deployed systems.

E.g. this is particularly true of unauthenticated or unencrypted transport services (which would not satisfy protected communication requirements above) such as File Transfer Protocol, telnet, Short Messaging Service, etc.

The vendor’s devices shall have all services used for troubleshooting disabled or properly protected from unauthorized access and use.

Deploying with test or debug facilities enabled is egregious

Vendor ensures that any and all interfaces used for testing or debug are unavailable in production builds of the devices

Deploying with test or debug facilities enabled is egregious.

Functionality that allows for the direct execution of scripts or commands by the device or system can often be exploited by a malicious party and therefore must be disabled.

The vendors’ devices shall have a default system configuration that ensures security ‘out of the box’. In other words, the default configuration should be the most-secure and any additional features should be disabled by default and have their security implications communicated in documentation.

Sufficient customer guidance should be provided to allow for that customer to understand the risks associated with enabling any insecure features of the device.

All remote hosts of the vendor's system shall be configured to uniquely identify and authenticate all other remote hosts of the system and/or any other interfacing systems.

e.g. that a remote system authenticate the other remote parties by referring to the unique identifiers using mutually authenticated TLS

Any authenticators (unique identification) for devices used in vendor’s systems shall be uncorrelated to any and all public information about the device, e.g. lot number, product number, serial number MAC address are all unacceptable inputs to device identifiers.

Where public information is any information that is visible (externally or internally) on the device or discoverable by searches based on that visible information.

Cryptographic modules used in the vendors system shall be compliant with Federal Information Processing Standards (FIPS) 140-2: Level 1.

e.g. • For each attempt to use the authentication mechanism, the probability shall be less than one in 1,000,000 that a random attempt will succeed, or a false acceptance will occur (e.g., guessing a password or PIN, false acceptance error rate of a biometric device, or some combination of authentication methods) • For multiple attempts to use the authentication mechanism during a one-minute period, the probability shall be less than one in 100,000 that a random attempt will succeed, or a false acceptance will occur • Feedback of authentication data to an operator shall be obscured during authentication (e.g., no visible display of characters when entering a password). • Feedback provided to an operator during an attempted authentication shall not weaken the strength of the authentication mechanism

The vendor shall have a documented incident response plan (IRP) in place which provides the carriers with a point of contact for components used within their telematics system

TSPs must demonstrate this level of maturity to be trusted with business critical functions

The vendor shall have procedures in place to ensure that components outside of the carrier’s direct control are not updated or modified without prior coordination and approval by an organization-defined individual or role

The vendor shall have procedures in place to test backup restoration processes of their own systems and their own facilities on at least an annual basis.

TSPs must demonstrate this level of maturity to be trusted with business critical functions

The vendor must have a disposal of goods policy which covers the management of all computer equipment and storage media dealing with customer information including but not limited to PII and customer business operations data.

The vendor's disposal of goods policy must forbid disposal in skips, dumps or landfills until it has been processed to purge or clear previously stored information.

The vendor's processes to remove previously stored information must include acceptable processes for magnetic media, solid-state media, printers, scanners, laptops, smartphones, server and desktop computers.

Vendors must provide manual backup/override capabilities to their safety related services to ensure that any failure of the device does not result in a safety issue.

The vendor shall have a System Security Plan (SSP) which details a clear and concise understanding of authorization boundaries of the telematics system.

The vendor shall have a documented Information Security Architecture (ISA) for the telematics system.

The vendor shall provide interfaces to their backend using the Open Telematics API -- enabling carriers to have failover to other providers to avoid interruptions due to single point of failure in provider telematics services.

Telematics is business critical to the carriers, failover is needed for this service

The vendor shall have personnel security policies & procedures, position risk categorization, personnel screening, personnel termination, personnel transfer, access agreements and third-party personnel security.

Vendor shall have risk assessments conducted at an industry accepted rate. Resulting risk assessment documentation should include all components and the overall system that is within the vendor's control. The rate suggested is twice per product release; both at product design and at integration phases

The vendor shall use the results of risk assessments to influence systems development and processes.

The vendor shall have an Information Security Management Plan (ISMP).

Sometimes referred to as ISMS as in ISO/IEC 2700.

May include any of the following: System interconnections, System monitoring plan, Vulnerability management plan, Incident response plan (see IR-010 for authoritative requirement), System Security Plan (SSP) or System Security , Authorization Agreement (SSAA), Contingency Plan, Contingency Plan Test Results, Federal Information Processing Standards (FIPS) 199 Categorization, Privacy Threshold Analysis (PTA), E-Authentication, Security Test and Evaluation (ST&E) Plan, Plan of Action and Milestones (POAM), Annual Self-Assessments

The vendor shall have penetration testing performed, to an industry accepted best practice, at an industry accepted pace.

Penetration testing can be performed by teams internal to the TSP; industry best practice is to have external pentesting performed periodically also.

Periodic pentesting keeps everyone honest

Vendor shall have Security Testing and Evaluation (ST&E) of the system and/or components that includes all results of the security testing and evaluation, including discovered vulnerabilities and a plan/process to mitigate discovered vulnerabilities or weaknesses in the system.

The vendor shall perform due diligence to ensure its suppliers also meet the vendor's security requirements

Cryptographic keys used in the vendors’ systems must be generated, stored and managed according to industry best practice.

Communication paths that traverse outside controlled boundaries must protect confidentiality and integrity of data

Underpins device functionality and security.

Naive implementations of TLS clients could still be susceptible to replay and MiTM attacks.

The default configuration must be secure in order to prevent downgrade attacks.

Communication path cryptographic protections must not use identities, keys or shared secrets which are common across multiple deployed devices

Measures will be taken by vendors to protect the confidentiality of any information at rest on the devices that could be interpreted as Sensitive and/or Personally Identifiable Information. This sensitive information is defined in SCP-030 where ‘at rest’ is understood to mean any state where the data is in a non-volatile storage medium, e.g. eMMC not RAM.

Failing to adequately protect PII can incur large fines

Logs and error messages must not expose PII without authentication.

e.g. this applies also to apps on mobile where data is cached until it can be synced to other vehicle-connected devices. This data must be encrypted as per this requirement.

NB: ideally these systems should be designed to minimize the collection of PII.

Vendors will supply documentation detailing what data is and is not protected at rest by cryptography.

Vendors are encouraged to expand the list of categories of data which will be protected on-device.

Data of the categories above will be protected using cryptographic keys which are not correlated to any public information about the devices.

Public information is any information that is visible (externally or internally) on the device or discoverable by searches based on that visible information.

All customer-related data will be logically segmented (e.g. encrypted with segmented keys) such that it is possible to produce all data related to one customer without inadvertently exposing any data of any others.

Otherwise could cause PII breaches and incur strong penalties

The vendor shall enforce controls integrated into the telematics device to limit the possible commands and data transmitted to the vehicle network.

Vehicle network protection is paramount

The vendor's system shall implement protection of communications sessions against attacks including session hijacking and traffic manipulation. Where a session is understood to mean a time-limited authenticated login with the cloud/back-end.

Sessions shall be invalidated at logout.

Sessions must be randomized and uniquely identified.

Protections must be implemented to restrict certificate authorities to a short (maximum 3) list of those expected by the vendor, i.e. secure communications must implement certificate pinning to a short whitelist of certificate authorities.

Certificate pinning shall be implemented on all telematics device to server communications (e.g. telematics gateways or IVGs). Administrative ‘backend’ systems may be exempt from this requirement to allow for stream inspection by enterprise intrusion detection systems.

Confidentiality and integrity of communication underpins the security of the system

Certificate pinning in clients -- when combined with the other requirement for e.g. fail-over – could result in extra complications and so functional testing of fail over should be performed.

The vendor shall implement checks for expired certificates and ensure the ability to remove trust in any given root certificate authority from their systems and devices PKI implementations.

The vendors’ systems shall implement protection of remote communication sessions by implementation of an inactivity timer that disconnects / de-authenticates the user after no more than 5 minutes of inactivity.

The vendor's system shall separate execution domains and/or processes (i.e. process isolation within both the telematics device and back-end system and between the serial communications in the telematics device and the interface to the vehicle network)

The vendor’s system shall provide a means to download unstructured customer data in an industry-standard format (Open Telematics API). This download will occur over secured communication protocols.

Telematics is business critical and failover is required

e.g. csv, txt, json formats

The vendor’s software shall not contain any credentials that are shared among other copies of software; e.g. the software cannot contain hardcoded API keys or API passwords

Vendors shall limit hardware support for deprecated or insecure communications protocols. This includes those with known vulnerabilities.

Vendors must ensure that their authentication mechanism is protected against brute force attacks. This includes ensuring that any password storage functions provide sufficient security through the use of industry best practice hashing mechanisms (such as BCrypt), as well as providing limits on access to sensitive services.

The vendor shall have a process for remediating flaws in deployed telematics devices and backend systems.

In the case of telematics devices, firmware update capabilities are important to be able to remediate all flaws that could be located in the device.

This is a leniently-worded requirement that a process to update device firmware exists

The vendor shall implement/deploy secure over the air update systems including assurances of integrity&authenticity. Also rollback protections and a means of denying the use of old potentially compromised signing keys.

The vendor shall have a capability to mitigate vulnerabilities across all of the telematics devices, backend applications, and systems. Identified vulnerabilities are remediated or mitigated using suitable compensating controls on a timeline predicated by the severity of the vulnerability identified.

Identified vulnerabilities are remediated or mitigated using suitable compensating controls on a timeline predicated by the severity of the vulnerability identified. Taking no longer than the following elapsed times: high in 30d, moderate in 90d and low in 180d.

Vendors shall provide a document that defines vulnerabilities severities (e.g. CVSS). Negotiation of mutually aggregable exceptions to the remediation timelines is acceptable to compensate for cases where the complexity of remediation or mitigations of the vulnerability is prohibitively expensive to execute in the prescribed timeline. In general, the timelines of remediation can be agreed -to in a SLA.

The vendor shall use digitally signed software on telematics devices and prohibit execution of unsigned or invalidly signed software.

Note may just want to make this one vendor shall utilize digitally signed firmware

The vendor shall utilize a boot verification process built with (asymmetric) cryptographic digital signatures and implemented such that the public key used for verification or the hash of the public key used for verification is protected from being tampered on the device.

Secure boot underpins the access control which protects the vehicle networks

Vendors shall implement a hardware based root of trust for boot authentication of the device.

The vendor shall provide a means (and document the process) for customers to verify the firmware in their devices.

Is a rare feature to find deployed and is nice-to-have over and above secure boot

The vendor shall utilize an array of code safety features across the entire collection of executables in its devices: ASLR, DEP, CFI, Stack Guards, Fortification, and RELRO. Unless that code safety feature is not applicable on the system architecture, in which case it should be noted.

Without any of these, exploitation is trivial

The vendor shall use the techniques of sanitizing/filtering inputs, segmenting memory spaces of input parsers from other execution and/or using provably correct or memory safe languages for input processing.

The vendor shall design security components that fail-secure to protect integrity of systems and data.

The vendor shall utilize protective mechanisms to protect components from unauthorized runtime/volatile modification of code.

Not well defined enough to make this of critical importance to TSPs or carriers

The vendor shall maintain a responsible disclosure program that allows for vulnerabilities discovered in the system (device, mobile app or backend) by researchers, and other external entities to be reported, tracked and mitigated.

Vulnerability programs should include sufficient legal provisions to provide for a “Legal Safe Harbor” for researchers.

The vendor must monitor information systems for attack and unauthorized access including employing automated analysis tools

Regardless of how secure a system might be it will eventually be breached; therefore monitoring is of high criticality

e.g. SIEM, IDS, WAF, Application monitoring

The vendor conducts regular vulnerability scans of operating environment to verify software components in use have been patched according to remediation SLAs.

The vendor shall have a vulnerability management process that includes steps to triage any found vulnerabilities and plan remediation.

This requirement, if satisfied, shows process maturity but is nice-to-have over and above the previous requirements in this category

The vendor shall verify code and best practice standards prior to deployment including:

Static Code Analysis / Static Application Security Testing (SCA/SAST)

Dependency Scanning for known vulnerabilities in third party components

The vendor shall implement ongoing monitoring and protection against malicious code in production using a well governed process that addresses all entry and exit points in the system.

e.g. whitelisting, anti-malware scanning, cryptographic protections

The vendor shall verify code according to best-practice coding standards

The vendor shall actively monitor resources such as NIST Common Vulnerabilities and Exposures (CVE), Bugtraq, for security alerts and advisories related to the telematics system’s components

The vendor shall notify their customers of any vulnerabilities discovered in the telematics systems components via monitoring or vulnerability disclosure programs. The notification to customers will happen in a timely manner.

Remediation SLA or objectives are defined and are adhered to by the security and development teams. Identified vulnerabilities are remediated or mitigated using suitable compensating controls

The vendor’s software will have software resiliency measures included that will slow the progress of tampering and reverse engineering efforts.

This is a nice-to-have. Mature solutions that process sensitive information in devices that could be in the hands of attackers are expected to have these protections; however, allowances should be made for products to focus on the necessary security controls first, for which these resiliency requirements are not a substitute

The vendor shall participate in a cybersecurity information sharing and analysis group in the heavy vehicle industry

This Cloud or Back-end component must satisfy requirement AA-010

This Cloud or Back-end component must satisfy requirement AC-010

This Cloud or Back-end component must satisfy requirement AC-030

This Cloud or Back-end component must satisfy requirement AC-040

This Cloud or Back-end component must satisfy requirement AC-041

This Cloud or Back-end component must satisfy requirement AC-050

This Cloud or Back-end component must satisfy requirement AC-070

This Cloud or Back-end component must satisfy requirement CM-020

This Cloud or Back-end component must satisfy requirement CM-030

This Cloud or Back-end component must satisfy requirement CM-040

This Cloud or Back-end component must satisfy requirement IA-010

This Cloud or Back-end component must satisfy requirement IA-030

This Cloud or Back-end component must satisfy requirement IR-010

This Cloud or Back-end component must satisfy requirement M-010

This Cloud or Back-end component must satisfy requirement M-020

This Cloud or Back-end component must satisfy requirement M-030

This Cloud or Back-end component must satisfy requirement M-031

This Cloud or Back-end component must satisfy requirement M-032

This Cloud or Back-end component must satisfy requirement P-010

This Cloud or Back-end component must satisfy requirement P-020

This Cloud or Back-end component must satisfy requirement P-030

This Cloud or Back-end component must satisfy requirement PS-010

This Cloud or Back-end component must satisfy requirement RA-010

This Cloud or Back-end component must satisfy requirement RA-020

This Cloud or Back-end component must satisfy requirement SAA-010

This Cloud or Back-end component must satisfy requirement SAA-020

This Cloud or Back-end component must satisfy requirement SAA-030

This Cloud or Back-end component must satisfy requirement SAA-040

This Cloud or Back-end component must satisfy requirement SAA-050

This Cloud or Back-end component must satisfy requirement SCP-010

This Cloud or Back-end component must satisfy requirement SCP-011

This Cloud or Back-end component must satisfy requirement SCP-020

This Cloud or Back-end component must satisfy requirement SCP-030

This Cloud or Back-end component must satisfy requirement SCP-040

This Cloud or Back-end component must satisfy requirement SCP-050

This Cloud or Back-end component must satisfy requirement SCP-090

This Cloud or Back-end component must satisfy requirement SCP-091

This Cloud or Back-end component must satisfy requirement SCP-092

This Cloud or Back-end component must satisfy requirement SCP-110

This Cloud or Back-end component must satisfy requirement SCP-120

This Cloud or Back-end component must satisfy requirement SCP-130

This Cloud or Back-end component must satisfy requirement SII-010

This Cloud or Back-end component must satisfy requirement SII-011

This Cloud or Back-end component must satisfy requirement SII-020

This Cloud or Back-end component must satisfy requirement SII-021

This Cloud or Back-end component must satisfy requirement SII-070

This Cloud or Back-end component must satisfy requirement SII-071

This Cloud or Back-end component must satisfy requirement SII-080

This Cloud or Back-end component must satisfy requirement SII-081

This Cloud or Back-end component must satisfy requirement SII-090

This Cloud or Back-end component must satisfy requirement SII-100

This Cloud or Back-end component must satisfy requirement SII-110

This Cloud or Back-end component must satisfy requirement SII-120

This Cloud or Back-end component must satisfy requirement SII-130

This Cloud or Back-end component must satisfy requirement SII-140

This Cloud or Back-end component must satisfy requirement SII-150

This Cloud or Back-end component must satisfy requirement SII-170

This Cloud or Back-end component must satisfy requirement SII-171

This Cloud or Back-end component must satisfy requirement SII-180

This Cloud or Back-end component must satisfy requirement SII-200

This Connectivity/Communications component must satisfy requirement AC-010

This Connectivity/Communications component must satisfy requirement AC-020

This Connectivity/Communications component must satisfy requirement AC-030

This Connectivity/Communications component must satisfy requirement AC-040

This Connectivity/Communications component must satisfy requirement AC-041

This Connectivity/Communications component must satisfy requirement AC-050

This Connectivity/Communications component must satisfy requirement AC-060

This Connectivity/Communications component must satisfy requirement AC-061

This Connectivity/Communications component must satisfy requirement AC-062

This Connectivity/Communications component must satisfy requirement AC-063

This Connectivity/Communications component must satisfy requirement AC-080

This Connectivity/Communications component must satisfy requirement CM-010

This Connectivity/Communications component must satisfy requirement CM-020

This Connectivity/Communications component must satisfy requirement CM-030

This Connectivity/Communications component must satisfy requirement CM-040

This Connectivity/Communications component must satisfy requirement IA-010

This Connectivity/Communications component must satisfy requirement IA-020

This Connectivity/Communications component must satisfy requirement IA-030

This Connectivity/Communications component must satisfy requirement IR-010

This Connectivity/Communications component must satisfy requirement M-010

This Connectivity/Communications component must satisfy requirement M-040

This Connectivity/Communications component must satisfy requirement PS-010

This Connectivity/Communications component must satisfy requirement RA-010

This Connectivity/Communications component must satisfy requirement RA-020

This Connectivity/Communications component must satisfy requirement SAA-010

This Connectivity/Communications component must satisfy requirement SAA-020

This Connectivity/Communications component must satisfy requirement SAA-030

This Connectivity/Communications component must satisfy requirement SAA-040

This Connectivity/Communications component must satisfy requirement SAA-050

This Connectivity/Communications component must satisfy requirement SCP-010

This Connectivity/Communications component must satisfy requirement SCP-011

This Connectivity/Communications component must satisfy requirement SCP-020

This Connectivity/Communications component must satisfy requirement SCP-030

This Connectivity/Communications component must satisfy requirement SCP-040

This Connectivity/Communications component must satisfy requirement SCP-060

This Connectivity/Communications component must satisfy requirement SCP-090

This Connectivity/Communications component must satisfy requirement SCP-091

This Connectivity/Communications component must satisfy requirement SCP-120

This Connectivity/Communications component must satisfy requirement SCP-130

This Connectivity/Communications component must satisfy requirement SCP-140

This Connectivity/Communications component must satisfy requirement SII-010

This Connectivity/Communications component must satisfy requirement SII-011

This Connectivity/Communications component must satisfy requirement SII-020

This Connectivity/Communications component must satisfy requirement SII-021

This Connectivity/Communications component must satisfy requirement SII-030

This Connectivity/Communications component must satisfy requirement SII-040

This Connectivity/Communications component must satisfy requirement SII-041

This Connectivity/Communications component must satisfy requirement SII-060

This Connectivity/Communications component must satisfy requirement SII-070

This Connectivity/Communications component must satisfy requirement SII-071

This Connectivity/Communications component must satisfy requirement SII-080

This Connectivity/Communications component must satisfy requirement SII-081

This Connectivity/Communications component must satisfy requirement SII-090

This Connectivity/Communications component must satisfy requirement SII-110

This Connectivity/Communications component must satisfy requirement SII-120

This Connectivity/Communications component must satisfy requirement SII-130

This Connectivity/Communications component must satisfy requirement SII-140

This Connectivity/Communications component must satisfy requirement SII-150

This Connectivity/Communications component must satisfy requirement SII-170

This Connectivity/Communications component must satisfy requirement SII-171

This Connectivity/Communications component must satisfy requirement SII-180

This Connectivity/Communications component must satisfy requirement SII-200

This Vehicle Connection component must satisfy requirement AC-010

This Vehicle Connection component must satisfy requirement AC-020

This Vehicle Connection component must satisfy requirement AC-030

This Vehicle Connection component must satisfy requirement AC-040

This Vehicle Connection component must satisfy requirement AC-041

This Vehicle Connection component must satisfy requirement AC-050

This Vehicle Connection component must satisfy requirement AC-060

This Vehicle Connection component must satisfy requirement AC-061

This Vehicle Connection component must satisfy requirement AC-062

This Vehicle Connection component must satisfy requirement AC-063

This Vehicle Connection component must satisfy requirement AC-080

This Vehicle Connection component must satisfy requirement CM-010

This Vehicle Connection component must satisfy requirement CM-020

This Vehicle Connection component must satisfy requirement CM-030

This Vehicle Connection component must satisfy requirement CM-040

This Vehicle Connection component must satisfy requirement IA-010

This Vehicle Connection component must satisfy requirement IA-020

This Vehicle Connection component must satisfy requirement IA-030

This Vehicle Connection component must satisfy requirement IR-010

This Vehicle Connection component must satisfy requirement M-010

This Vehicle Connection component must satisfy requirement M-040

This Vehicle Connection component must satisfy requirement PS-010

This Vehicle Connection component must satisfy requirement RA-010

This Vehicle Connection component must satisfy requirement RA-020

This Vehicle Connection component must satisfy requirement SAA-010

This Vehicle Connection component must satisfy requirement SAA-020

This Vehicle Connection component must satisfy requirement SAA-030

This Vehicle Connection component must satisfy requirement SAA-040

This Vehicle Connection component must satisfy requirement SAA-050

This Vehicle Connection component must satisfy requirement SCP-010

This Vehicle Connection component must satisfy requirement SCP-011

This Vehicle Connection component must satisfy requirement SCP-020

This Vehicle Connection component must satisfy requirement SCP-030

This Vehicle Connection component must satisfy requirement SCP-040

This Vehicle Connection component must satisfy requirement SCP-060

This Vehicle Connection component must satisfy requirement SCP-100

This Vehicle Connection component must satisfy requirement SCP-140

This Vehicle Connection component must satisfy requirement SII-010

This Vehicle Connection component must satisfy requirement SII-011

This Vehicle Connection component must satisfy requirement SII-020

This Vehicle Connection component must satisfy requirement SII-021

This Vehicle Connection component must satisfy requirement SII-030

This Vehicle Connection component must satisfy requirement SII-040

This Vehicle Connection component must satisfy requirement SII-041

This Vehicle Connection component must satisfy requirement SII-060

This Vehicle Connection component must satisfy requirement SII-070

This Vehicle Connection component must satisfy requirement SII-071

This Vehicle Connection component must satisfy requirement SII-080

This Vehicle Connection component must satisfy requirement SII-081

This Vehicle Connection component must satisfy requirement SII-090

This Vehicle Connection component must satisfy requirement SII-120

This Vehicle Connection component must satisfy requirement SII-130

This Vehicle Connection component must satisfy requirement SII-140

This Vehicle Connection component must satisfy requirement SII-150

This Vehicle Connection component must satisfy requirement SII-170

This Vehicle Connection component must satisfy requirement SII-171

This Vehicle Connection component must satisfy requirement SII-180

This Vehicle Connection component must satisfy requirement SII-200

This Mobile App component must satisfy requirement AC-010

This Mobile App component must satisfy requirement AC-030

This Mobile App component must satisfy requirement AC-040

This Mobile App component must satisfy requirement AC-041

This Mobile App component must satisfy requirement AC-050

This Mobile App component must satisfy requirement AC-080

This Mobile App component must satisfy requirement CM-020

This Mobile App component must satisfy requirement CM-030

This Mobile App component must satisfy requirement CM-040

This Mobile App component must satisfy requirement IA-010

This Mobile App component must satisfy requirement IA-030

This Mobile App component must satisfy requirement IR-010

This Mobile App component must satisfy requirement M-010

This Mobile App component must satisfy requirement PS-010

This Mobile App component must satisfy requirement RA-010

This Mobile App component must satisfy requirement RA-020

This Mobile App component must satisfy requirement SAA-010

This Mobile App component must satisfy requirement SAA-020

This Mobile App component must satisfy requirement SAA-030

This Mobile App component must satisfy requirement SAA-040

This Mobile App component must satisfy requirement SAA-050

This Mobile App component must satisfy requirement SCP-010

This Mobile App component must satisfy requirement SCP-011

This Mobile App component must satisfy requirement SCP-020

This Mobile App component must satisfy requirement SCP-030

This Mobile App component must satisfy requirement SCP-040

This Mobile App component must satisfy requirement SCP-090

This Mobile App component must satisfy requirement SCP-091

This Mobile App component must satisfy requirement SCP-120

This Mobile App component must satisfy requirement SCP-130

This Mobile App component must satisfy requirement SCP-140

This Mobile App component must satisfy requirement SII-010

This Mobile App component must satisfy requirement SII-011

This Mobile App component must satisfy requirement SII-020

This Mobile App component must satisfy requirement SII-021

This Mobile App component must satisfy requirement SII-030

This Mobile App component must satisfy requirement SII-070

This Mobile App component must satisfy requirement SII-071

This Mobile App component must satisfy requirement SII-080

This Mobile App component must satisfy requirement SII-081

This Mobile App component must satisfy requirement SII-090

This Mobile App component must satisfy requirement SII-120

This Mobile App component must satisfy requirement SII-130

This Mobile App component must satisfy requirement SII-140

This Mobile App component must satisfy requirement SII-150

This Mobile App component must satisfy requirement SII-170

This Mobile App component must satisfy requirement SII-171

This Mobile App component must satisfy requirement SII-180

This Mobile App component must satisfy requirement SII-190

This Mobile App component must satisfy requirement SII-200