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.

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.

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

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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

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

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

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.

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

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.

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.

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

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)

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.

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.

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.

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.

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.

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.

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 shall have a vulnerability management process that includes steps to triage any found vulnerabilities and plan remediation.

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.

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 shall participate in a cybersecurity information sharing and analysis group in the heavy vehicle industry