The move toward software-defined vehicles is enabling a wealth of safety, comfort and convenience innovations – and the innovations do not stop when those vehicles leave a dealership. Through over-the-air (OTA) updates, the software that runs the vehicle can continue to evolve and improve throughout its lifecycle, delighting consumers for years to come.
This is a powerful capability, but it requires an approach to development that always has cybersecurity in mind. Attacks might come from physical access to a vehicle, or even via Wi-Fi or Bluetooth, but cellular connections mean an attacker could potentially access the vehicle’s systems from anywhere in the world.
To secure those communications and protect the vehicle’s software, the automotive industry should adopt a posture of “assume harm.” That is, even after establishing a relationship with an outside entity, the systems in the vehicle should assume that the entity may have been compromised and could cause harm to the systems.
Proactive and reactive
Cybersecurity has to be baked into companies’ processes from the very beginning – from design and development through manufacturing – and the “assume harm” mindset helps guide automotive software and hardware developers to create systems with cybersecurity built into them, at all levels. It puts the focus on actions to take, rather than on establishing identity and determining access rights.
The actions taken by the vehicle’s systems could be proactive or reactive.
Proactively, for example, a system could require that every OTA communication it receives be formatted exactly as specified in the relevant communications protocol – regardless of whether the source has been verified. This helps protect against cyberattacks that use deliberately misformatted packets to open up a vulnerability. If a communication arrives that does not conform to the protocol, the system could ignore it or simply send a reply to the sender to indicate that there was an error.
Reactively, the vehicle systems should respond in a secure fashion to any events. For example, if the vehicle goes a long time without being able to establish an OTA connection, the systems could potentially shut down certain subsystems to prevent harm. Similarly, if an intrusion-detection system sees that a component has been infected with malware, the system should be prepared to shut down that component.
Diligence in software and hardware
As the name implies, in a software-defined vehicle, every capability that is added to a vehicle brings along its own software. As automotive ecosystems grow and evolve, that software could come from multiple suppliers. Software from different suppliers may run on the same hardware platform, and applications may communicate with one another.
All of that software must be analyzed for threats and common vulnerabilities, through software composition analysis, penetration testing and periodic risk assessments. This environment requires defense-in-depth strategies, including secure updates, secure boot, identity access management, isolation-through-virtualization techniques and more.
On the hardware side, the microchips used within a vehicle’s electronic control units must also be secured. That hardware could potentially include commercial off-the-shelf chips. Examples of secure hardware capabilities include secure storage, tamper detection, hardware acceleration for crypto-algorithms, secure firmware upgrades, secure key updates, secure boot, secure debug and other features.
These strategies are important for hardening systems against attacks, and they are also necessary to help build trust in the software-defined vehicles that are rapidly reshaping the automotive industry with their compelling advantages. Vehicles are no longer closed systems, and any security approach must recognize that and account for it, from the hardware to the software to the communications systems. With an “assume harm” approach, the system is always on guard, with a rigorous take on cybersecurity at every step.