Design principles
There are a number of principles that can help strengthen the security of your connected mobility solution in addition to the overall Well-Architected Framework security design principles:
Identify automotive and general regulatory and compliance standards: Design and architect solutions to help adhere to industry-standard security frameworks and regulations. The automotive industry has specific regulations and standards to consider. Automotive specific standards and frameworks that should be considered by you and your applicable stakeholders include, and are not limited to: ISO/SAE 21434 for cybersecurity, ISO 26262 for functional safety, ASPICE for software development lifecycle process, ISO 24089 for OTA, and regulations like UNR 155/156 for developing a cyber security management system and software update management system in automotive. It is important to consider and align to general standards when building connected mobility applications like ISO 27001, NIST Cybersecurity Framework, and privacy laws like GDPR. This helps to verify that the systems in scope are validated against the highest levels of safety, security, and privacy.
You have a choice of protocols that can be used for vehicle connectivity to the cloud: There are several protocols that can be used to for vehicle connectivity to the cloud. The protocols and services that you use can influence the security properties of the connection between vehicle to cloud. Common protocol patterns include HTTPS, MQTT/TLS, Kafka over TLS, Secure RTP, and gRPC over TLS. Consider cost, performance, bandwidth, business applicability, and more when deciding which protocol fits your connectivity use-case.
Implement secure identity lifecycle management for vehicles and consumers: An end-to-end identity management system should manage the entire lifecycle for vehicles, owners, drivers, operators and partner identities. There are unique considerations for electronic control units (ECUs) device certificates such as provisioning, expiry, rotation/revocation, validation, and certificate management. Consumer identities need to be considered as they interact with different vehicles and vehicle features. It is important to verify the validity and mapping between the different identity types (owner, driver, and vehicle) and pro-actively revoke or extend identities and the associated permissions over time.
Establish least privilege permissions for vehicles and systems: Vehicles should have fine-grained access permissions to backend systems and access to vehicles from other systems should follow the same guiding principle of least privilege. Vehicles receive communication from many endpoints such as charging stations, backend systems, and consumer applications. Scoping down the permissions will help reduce the risk of lateral movements from a compromised entity (vehicle or system). Vehicle ECUs should only be able to communicate with topics or endpoints that they are required to operate. Permissions of vehicle ECUs should be audited and reviewed continuously.
Classify and protect data collected from systems and applications related to connected mobility: Connected mobility applications interact with sensitive data including but not limited to personal identifiable information (PII), location data, VINs, and user data. Customers need to implement data protection mechanisms such as data encryption, data anonymization, and data access control to safeguard the sensitive data. Use secure communication channels such TLS to confirm that data transmitted between vehicles and the cloud is protected from interception, tampering, or other types of attacks. Vehicles, sensors, and systems should only collect the data necessary to facilitate their function.
Design for continuous monitoring and verify trusted software and firmware: implement continuous monitoring mechanisms of your connected mobility service such as in-vehicle and the vehicle environment (such as charging stations, and mobile applications) to detect and respond to security incidents and alert your purpose-built vehicle security operations center (VSOC). Use secure firmware and software update mechanisms to create timely security patches and updates over the air. Implement secure boot and chain of trust mechanisms to verify that only trusted software components are loaded and executed on the vehicle's hardware.
Design for resiliency in-vehicle and in the cloud: implement redundancy and resilient mechanisms to check that critical systems such as brakes, steering, and power train continue to operate even in the event of a security issue.
Confirm that backend systems in the cloud are also resilient and able to recover from such events. Consider implementing managed services and highly available backend systems by leveraging multiple Availability Zones and plan the disaster recovery for your solution in another AWS Region. Backup your critical data frequently to help meet the desired Recovery Point Objective (RPO) of the solution. Implement vehicle shadow logic to maintain state during loss of connectivity to the cloud.
Define a vehicle and system threat model: implement threat modeling to identify potential security risks and vulnerabilities in the system (vehicle, vehicle related infrastructure, applications, backend) and implement appropriate security controls to mitigate these risks. Confirm that you follow automotive threat modeling standards such as Threat Analysis and Risk Assessment (TARA) or another methodology to cover in-vehicle threats and measure appropriate risk ratings.
Train your staff so that they are able to address vehicle security risks and the impact across the organizations: Deliver a training program that can provide your security team and developers with vehicle cybersecurity and compliance training, cloud security training, and fundamental information technology training. It is important to evaluate program effectiveness and update periodically.
