For the last decade, the concept of “zero trust” has dominated cybersecurity discussions across industries. Like many buzzwords, however, the exact meaning of zero trust has been diluted over time, lost in rhetoric. The National Institute of Standards and Technology (NIST) recently tried to counter this trend by publishing a standard for Zero Trust Architecture to define the term and provide common-sense use cases.
Still, the very name “zero trust” can be misleading. While zero-trust systems avoid implicitly trusting users solely based on their physical location or network connection, at some point they have to trust something, somewhere — or else they would never be able to communicate with anything outside the system or get anything done.
An alternative and effective way to think about cybersecurity is “assume harm.” That is, even once a relationship with an outside entity has been established, assume that the entity is out to do harm, as it may have been compromised. This frame of mind takes the focus off establishing identity and access privileges and instead targets practical actions to take, either proactively or reactively.
As vehicles become more software-defined, this approach to security becomes important in several ways:
Software. Every capability that is added to a vehicle brings along its own software. Those pieces of software could come from multiple suppliers; they may need to run on the same hardware platform; and they may talk to each other. All software must be analyzed for threats and common vulnerabilities, through software composition analysis, penetration testing and periodic risk assessments.
Defense-in-depth strategies are important, including secure updates, secure boot, identity access management, isolation-through-virtualization techniques and much more. These strategies are important for hardening systems against attacks and building trust in software-defined vehicles.
Hardware. Many capabilities have electronic control units with their own hardware, and that hardware increasingly includes commercial off-the-shelf (COTS) microchips that could be vulnerable to attacks.
Secure hardware is the backbone of security for software-defined vehicles. 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 many other features. Data orchestration is possible in a software-defined vehicle only when taking advantage of these hardware capabilities.
Communication. Each application may communicate wirelessly, whether it is receiving over-the-air (OTA) updates or retrieving content for an infotainment system. Vehicles are no longer closed systems, and any security approach must recognize that and account for it.
Taking an assume-harm approach means always being on guard. One example is to require that every incoming communication — either from the outside world or from other modules in the vehicle — be formatted exactly according to protocol, without exception. In the past, IT systems have been compromised by attackers that deliberately misformatted communications to open up a vulnerability. An infamous example is the Code Red worm of 2001, which overflowed a buffer with a long string of letters when it arrived at target computers. That overflow gave it the opportunity to execute malicious code.
Systems can reduce their vulnerability by validating that any incoming communication follows standard protocols to the letter, no matter the source. If the communication does not fit those parameters, the system can either ignore it or let the sending system know of the error. A buffer would never have a chance to overflow, for example.
Systems must also react in a secure fashion to events. For example, OTA updates require an active wireless connection, but how should the vehicle react if the connection is severed for an extended period of time, either intentionally or unintentionally? How long does it wait? And should it shut down certain subsystems to prevent harm?
An additional challenge is that vehicles must protect systems against potential attacks seen in other industries, such as man-in-the-middle attacks that attempt to fake a signal to the vehicle and then route it through a different infrastructure to load the vehicle with a malicious update. Intrusion-detection systems will be needed, and the vehicle will have to be prepared to react to different scenarios, including the possibility of shutting down an infected component.
A posture of “assume harm” is key to developing the software-defined vehicles of the future. Every step must be blocked and tackled. Every interaction must be checked. The financial industry has been taking this approach for years. Now, the automotive industry must also take a rigorous approach to cybersecurity, especially as vehicles move toward higher levels of automation.
