Attention Vehicle Manufacturers: The Vulnerability Management Countdown Has Begun

Software vulnerabilities are weaknesses or flaws in computer code that could allow an attacker to gain control of a system. For as long as humans continue to write code, vulnerabilities will exist. Thus, it’s imperative that organizations invest in effectively detecting and mitigating vulnerabilities – before they become a risk.

As vehicles become more connected and more software-driven, automotive-related software vulnerabilities are growing at an alarming rate. But these published vulnerabilities are only the tip of the iceberg. The uncomfortable truth is that a car can be on the road for years without anyone knowing there is a vulnerability – until there’s an attack!

Meeting New Vulnerability Management Requirements

Given the potentially devastating impact of a cyber attack on a vehicle or fleet – from driver and public safety dangers to mass recalls and brand tarnishing – automotive-related vulnerabilities cannot be ignored.

Recognizing the safety implications of cyber attacks in the automotive space, new regulations and standards are being developed that will require OEMs to monitor incidents and risks to their vehicle fleets over the entire lifecycle. In June 2020, the UN introduced regulation UNR155 that outlines new cyber security practices for vehicle manufacturers (OEMs), including a requirement to monitor, protect and respond to vulnerabilities, as well as mitigating vulnerabilities “within a reasonable timeframe.”

Today, OEMs and Tier 1s are exploring ways to manage vulnerabilities in a timely and effective manner, as stipulated by UNR 155 and ISO/SAE 21434. Let’s examine some of the serious challenges the automotive supply chain will need to overcome to meet these requirements.

Challenge #1 – Magnitude and Complexity of Code

The sheer magnitude and complexity of the code in a typical vehicle has made vulnerability management a nightmare. With about 100 million lines of code per vehicle and growing (twice as much as Windows 10 and 250 times more than the original space shuttle), spread across multiple systems, discovering a security flaw is like searching for a needle in a haystack.

Moreover, software typically includes a mix of open source, 3rd party and proprietary code, often coming from lower tier suppliers.

Challenge #2 – Fragmented Supply Chain

A typical vehicle contains up to 100 ECUs, each of which may be provided by a different Tier 1 supplier. Moreover, some manufacturers work with more than one supplier for a particular ECU. Add the fact that Tier 1 suppliers often work with their own Tier 2 and Tier 3 suppliers, and you’ve got a vehicle with multiple ECUs running software and OS developed by different lower tier suppliers (some of which are unknown to the OEM).
It’s also common to have multiple OS (e.g., AUTOSAR, Linux, Android) and software functionality on the same ECU from different suppliers, further complicating the vulnerability management challenge.

For purposes of comparison, this level of fragmentation is extremely rare in the IT world.

Challenge #3 – Limited Visibility

Due to the high level of fragmentation and number of tiers, OEMs have limited access to the source code for the ECUs. In addition, OEMs and Tier 1s don’t always purchase source code from a supplier, but rather an automotive-specific image. This further impairs vulnerability detection, as well as the ability to patch a vulnerability once detected.

Due to the multi-tier supply chain, the OEM who is ultimately responsible for the vehicle on the road doesn’t always know where the code came from and who is responsible for the vulnerability. From a software perspective, everything below Tier 1 can be “invisible” to the OEM and the longer the supply chain (more tiers), the more difficult it is to know whether a published vulnerability is relevant to the code within a given vehicle.

This lack of visibility makes it difficult for OEMs to detect, patch and manage vulnerabilities in an efficient manner.

Challenge #4 – Vehicle Lifetime

Vehicles are typically five years in design and production, followed by 10 -15 years on the road. This means that even if your vehicle was designed and tested with security in mind, vulnerabilities need to be managed in a way to allow for their ongoing and future detection and mitigation.

There are no “end of life” announcements in the automotive industry, OEMs can’t stop support for cars on the road, and must ensure continuous vehicle safety for 10-15 years. This is a major challenge and requires a way to support legacy software and patches throughout the vehicle’s lifetime.

Today, over-the-air (OTA) updates are common for vehicle entertainment systems and telematics ECUs. However, this OTA capability is often sorely lacking for safety-critical ECUs like steering, acceleration, etc. and should be urgently addressed.

Challenge #5 – Difficulty of Impact Assessment

Once a vulnerability affecting vehicles is published, it’s up to the OEM’s security analyst to determine the vulnerability’s impact and the vehicle’s risk exposure. However, due to the code complexity and lack of visibility described earlier, it’s very hard for the analyst to get answers to the most important questions for impact assessment.

These include: Is the vulnerability in my vehicle’s code? In which ECU? How many vehicles are affected? What systems does it affect? Is the vulnerability exploitable or is the ECU secured by other means? Is the potential impact severe enough to warrant further investment? Having access to the information required to answer these questions is critical for reducing risk exposure and accelerating time to response.

Challenge #6 – Mitigation Complexity

Once the decision to mitigate the vulnerability is made, implementing the patch in a vehicle’s software environment is a complex endeavor, whether it is a simple configuration change or a full software upgrade. From an architecture standpoint, a vehicle is a “system of systems” comprising many ECUs, all of which are connected in a network. Accordingly, any code update or vulnerability patch for one ECU could affect other systems. Therefore, after patching a vulnerability, it is necessary to verify that the ECU’s functionality remains intact and that the upgrade has not adversely affected other systems.

In addition, due to the fragmented supply chain, OEMs don’t have the ability to mitigate most vulnerabilities on their own and must coordinate with one or more suppliers. And since different development teams are involved, this raises the question of which party is responsible (OEM, Tier 1, Tier 2) for the patch.

Other key questions, still unanswered at this stage, include: How best to patch? When to patch? Can it be done via an OTA update? How to perform security tests after production? and more.
Solutions addressing these issues will need to be found in the next two years.

Where to Begin: Cooperation and Transparency Across the Ecosystem

To address these vulnerability management challenges, the entire automotive ecosystem – OEMS, ECU suppliers at all tiers of the automotive supply chain, communication providers and leading vendors – must work together to ensure that there is transparency across the ecosystem.
Combining improved visibility and transparency with the right vulnerability management tools will enable OEMs to better understand their cyber risk exposure and shorten the time from detection to mitigation – helping them keep vehicles secure and people safe from attack.

Go to our Argus Vehicle Vulnerability Management page for more information about how Argus can help solve your vulnerability management challenges.