Data protection
| CMSEC_20: What are your encryption requirements for vehicle data? |
|---|
Vehicles can collect and generate data with different levels of sensitivity and risk to your organization. You must check that the data is protected using appropriate means to comply with applicable standards, regulations, and laws. Encrypting the data in transit and at rest and controlling access to the encryption keys can be an effective technical means to help meet your data protection requirements. Begin by classifying the data generated by the vehicle to determine the type of encryption required in transit and at rest.
Consider the following best practices for encryption:
[CMSEC_BP20.1] Implement TLS 1.2+ to encrypt data in transit
By implementing TLS 1.2+ from the ECU to the connected vehicle service backend you get encryption in transit. With the addition of X.509 client certificates on the ECUs for mutual TLS you also get authorization of requests. Verify that you follow the best practices on managing the lifecycle of certificates as described above.
On AWS, you can use mutual TLS 1.2+ with AWS IoT Core and Amazon API Gateway REST APIs to authenticate ECUs using X.509 client certificates. You can also terminate mutual TLS on software deployed to AWS compute services (Amazon EC2, Amazon EKS, or Amazon ECS) behind a Network Load Balancer (NLB). Individual AWS service API requests are authenticated using the sigv4 algorithm.
[CMSEC_BP20.2] Consider client-side encryption of highly sensitive data at the ECU
When highly sensitive data is transmitted from the vehicle to a connected vehicle backend, you may consider implementing client-side encryption of the data. In this approach, the vehicle ECU encrypts the sensitive data payload before transmitting it to the connected vehicle backend service. The encrypted payload is transmitted via any intermediate systems to the backend system that has access to the keys to decrypt the payload and recover the sensitive data in the clear. Note that message parts such as HTTP headers and MQTT topic names should still be transmitted without client-side encryption so that intermediate nodes can route and queue messages. The benefit is that any intermediate systems such as a load-balancer or message broker are unable to see the sensitive data payload in the clear as these systems do not have permissions on the keys. This scheme relies on managing the encryption keys securely and granting least-privilege permissions on keys to the ECU and backend servers.
An effective pattern for client-side encryption is envelope encryption in conjunction with a key management system. In this pattern, the plaintext sensitive data is encrypted by the ECU with a data key and the data key is encrypted under another key that is managed in a key management system. The ECU transmits the encrypted data and the encrypted data key to the backend service. The backend service invokes the key management system to decrypt the encrypted data key, recovering the plaintext data key. It can then use the plaintext data key to decrypt the encrypted data. The ECU can cache the data key for a period of time or for a certain volume of data, improving performance by minimizing the need to invoke the key management service for every sensitive data element. An intermediate system that receives the encrypted data key does not have permissions to invoke the key management system to decrypt the data key and as a consequence cannot decrypt the encrypted data. The sensitive data payload remains encrypted end-to-end from the ECU to the backend service in transit and at rest.
On AWS, you can use the AWS Key Management Service
| CMSEC_21: How do you identify and protect data in your connected vehicle service? |
|---|
Classify the data processed by your connected vehicle service as described in Well-Architected Security Data Protection. Specifically, consider how you will classify data such as Vehicle Identifier (VIN), ECU serial number, vehicle location (coarse vs precise), and operator identity. Consider the specific requirements that apply to your organization, depending on factors such as where you conduct business, any industry-specific regulations, the type of data, where or from whom the data originates, and where the content is stored and processed.
Consider the following best practices to protect data.
[CMSEC_BP21.1] Do not use sensitive data to name and reference resources
You may have several resources in your connected vehicle architecture that must be uniquely named. Avoid using sensitive data such as the VIN, customer identity, location in these resources so that you can more effectively control access to the data. For example, when using MQTT, avoid using the VIN in the topic names used to send and receive messages from a vehicle's ECUs. MQTT topic names are often logged to audit log files, and can be used when subscribing to messages. Using a hashed VIN or another unique identifier that cannot be mapped to a VIN will help you limit the number of locations, systems and people that can see the VIN.
On AWS, you can use Amazon Macie
