This is Part 2 of a three-part blog series on automotive cybersecurity. If you have not yet read Part 1: Automotive Cybersecurity and Trustworthiness, we highly recommend that you do so before continuing with Part 2.
Part 2 walks the reader through the automotive supply chain and the challenges of ensuring it is cyber secure.
Although most automotive OEMs consider automotive cybersecurity to be a real concern that warrants attention, less than half of them are addressing it proactively. Most OEMs are well behind when it comes to any sort of cyber defense capability. Among those that have operational cybersecurity teams or units, considerably less than half are confident of their abilities to identify and mitigate cyber threats. Increasing complexity, multiple stakeholders, and supplier vulnerability each contribute to the cybersecurity challenges the industry faces.
Consider the increasing complexity of automotive manufacturing. There are no industry-common requirements. Nomenclature and conceptualization vary from company to company. The number of potential points for cyberattacks is already high and is bound to increase with the addition of more functionality. An average vehicle may contain 30 to 100 control units and each unit carries its own dedicated operating system. Software code can run into hundreds of millions of lines. All of this leads to supply chain confusion and discontinuity which is magnified because suppliers support multiple OEMs.
There are many stakeholders, none of whom have adopted any industry standard for automotive cybersecurity. The development of countermeasures is made difficult by the number of players involved — each producing their proprietary patch specifications and complying with different standards. A set of control units in a single vehicle might be provided by more than 20 different vendors and the strength of an individual component may be lost in a poorly executed integration that results in a vulnerable network of interconnected elements. OEMs are faced with significant integration risks and need to develop robust testing to mitigate this risk.
The automotive supply chain is complex and disparate, with an array of major cybersecurity vulnerabilities. Many suppliers lack awareness regarding potential threats. Even if aware, suppliers in a collaborative relationship often cannot scrutinize or control security measures elsewhere along the chain. This can lead to the application of inadequate security management resources and opens multiple exposures that cybercriminals can exploit.
One area of vulnerability is the tightly interconnected nature of suppliers. While this arrangement provides a high degree of efficiency and convenience, it’s also inherently fraught with security risks. We now live in the world of digital buyer-seller partnerships, robotic process automation, and the Internet of Things (IoT). The resulting supply chain exposure to cyber damage is exponentially increasing. Cybercriminals are quite aware of these connections and are already exploiting them to access internal networks that had been previously well-protected. It has become crucial that all supply chain participants inquire about the security measures of their suppliers and sub-suppliers.
A Tier 1 supplier may implement a partial solution and pass one or more cybersecurity vulnerabilities down the supply chain to Tier 2 and Tier 3 suppliers. These suppliers add hardware and software and perform safety, security, functional, and regression testing. These lower-tier suppliers may add defects and non-secure features that compound the exposure to cybersecurity threats.
In most cases, attacks begin at the “weakest link” of this highly connected digital ecosystem: typically, small-to-medium enterprise manufacturers and suppliers. It is common for bad actors to start small, often placing backdoors that allow access for the future placement of malware. Such openings might sit patiently in the background for years before a real attack is triggered.
Beyond interconnected suppliers, the larger cyber concern lies in the embedded software, including how it is created, updated, and authenticated.
Often, automakers don’t know the original software authors.
To reduce development costs, much of the automotive industry makes liberal use of open-source software on platforms such as Android or Linux. Open-source software is built on a crowd-sourcing model in which hordes of hobbyists have been contributors to its design and construction.
A large number of unknown software authors coming together in a complex supply chain makes it especially challenging for an automaker to maintain the software that runs in its vehicles. The training, licensing, design, and quality standards that are enforced in other engineering disciplines affecting human safety are, lamentably, absent in many types of automotive software.
Even the software from a known author is often written by suppliers rather than a car manufacturer. A Jeep Cherokee was remotely hacked in 2015 as a study demonstration of vehicle vulnerabilities. Access was gained through a non-secure infotainment system built by Harman (owned by Samsung). Harman was a Tier 1 supplier; much of a vehicle’s software is devised at lower tiers.
The great volume and complexity of vehicle software can also be a problem. There is a higher probability of finding defects in bloated code than in comparatively simple software.
The 2016 Stout Automotive Warranty and Recall Report cited a spike in software-related car recalls.
“Today’s cars can contain over 100 million lines of code. For perspective, an F-35 joint strike fighter jet contains about 9 million,” says Neil Steinkamp, a director in the Stout automotive division. “When you have that much software in a car — and particularly when much of that software is relatively new — there are going to be some issues.”
Why should there be such a big difference in the volume of code in a car in comparison with a fighter airplane? It’s quite simple: each line of code is a liability because it is potentially a point of failure. Aircraft manufacturers focus intensively on this potential liability and consequently minimize the amount of code to only that which is absolutely necessary. Each line is repeatedly scrutinized and tested, and this results in software that is much easier to maintain and contains much fewer defects. The auto industry is nowhere near this level of software quality and reliability.
Vehicle recalls for software problems increased threefold between 2011 and 2016. The 2017 Stout Automotive Warranty and Recall Report offered this explanation:
"One reason for the likelihood of sustained elevated recalls in the coming years is an increased number of defects related to software and integrated electronic components. The continued development of new technologies to assist drivers, differentiate vehicles, and improve vehicle safety also poses recall risk. The widespread use of such innovations as adaptive cruise control, rear backup cameras, forward-collision detection, emergency braking, and brake assist improve vehicle safety, yet add complexity to safety-critical systems.”
Carmakers have a strong financial incentive to focus on software-heavy features. Since software isn’t physical, it can be mass-produced at an extremely low cost. Software features can significantly boost the price of a vehicle — sometimes by thousands of dollars.
The more software a car contains, the greater the probability that some vulnerability or defect exists that a hacker can exploit and take control of a vehicle. Indeed, “bug bounty” programs have clearly shown that a vulnerability can be bought for a mere $10-30,000. For a malicious criminal, this is much less expensive than the purchase of other means of destruction. Moreover, a particularly astute hacker can make it appear that a third party was responsible for the attack.
There are two primary pathways for inserting malware into a production vehicle during (a) design and manufacture and (b) software updates.
Manufacturers are motivated to perform updates wirelessly over-the-air (OTA). This method is far less expensive (and less embarrassing) than recalls. Several major carmakers, including General Motors, have declared an intent to add or expand support of OTA updates of vehicle software by 2023.
While this mode of software distribution may be suitable for mobile phones and home computers, it is potentially dangerous in automobile platforms that contain various safety-critical components. Software directs or influences many aspects of driving from braking to steering — a faulty update might affect thousands of vehicles simultaneously and disastrously.
Unfortunately, the significant reduction in the price OTA brings to repairing defective software may lead to suppliers recklessly rushing the job and delivering poorly tested products. Beating the competition in this way may provide a significant temporary competitive advantage, even if the software is flawed. This aggressive practice brings with it a serious risk to consumers, especially if the software affects vehicle components directly related to safety.
This is precisely the claim brought forward in a lawsuit against Tesla, a carmaker that has been pioneering OTA updates. Tesla customers claim they paid more than they should for the privilege of becoming “beta testers of half-baked software that renders Tesla vehicles dangerous if engaged.”
OTA updates depend heavily on multiple IT technologies for secure delivery of the payload, validation of the delivery, and performing the update to the vehicle software. This delivery method is well understood, with multiple types of solutions already available. It’s important to realize, however, that OTA delivery is exploitable as a very secure way of delivering corrupted software to a large number of vehicles.
Perhaps the most significant challenge in the software supply chain is guaranteeing authenticity. If you cannot verify the code’s source and subsequent chain of custody, you are vulnerable to whatever flaws and intrusions the code may have suffered.
Consider the use of open-source software. It is usually obtained from a library or repository outside the direct control of a vehicle’s manufacturer or suppliers. It might contain unintended flaws; it might include intentionally malicious code. Implementation of the code without a line-by-line review commits the user to blindly accepting and relying on its integrity.
Software may pass through several hands before it reaches a control unit in a vehicle. Each handoff provides an opportunity for mischief; for instance, a hacker could take control of a supplier’s communications and undermine the integrity of software being distributed.
To guarantee authenticity requires knowledge and verification of the software’s entire life flow: who wrote it; what security reviews have been performed; who has touched it; what are its known vulnerabilities; what are its licensing details; etc.
The application of digital signatures or keys at each exchange – beginning at the furthest point upstream and maintained throughout the chain of custody – will help validate the software before passing it on.
It may also be possible to assess authenticity within a running vehicle. An attacker’s errant code (perhaps inserted through OTA processes) might be spotted at runtime by comparing its instructions to a known/expected set. If an anomaly is detected, the system might react by terminating a process or signaling to the driver that something is amiss.
The supply chain situation is well summarized in a 2017 publication from the Computer Security Resource Center (with the National Institute of Standards and Technology):
“Software supply chain attacks are particularly bothersome and insidious because they violate the basic and assumed trust between software provider and consumer. Customers have been correctly conditioned to buy and install software only from trusted sources and to download and use patches or updates only from authorized vendor sites. Now, customers must be wary of performing those basic, proper, and prudent cybersecurity tasks when purchasing software and maintaining systems, since even authorized resources may be compromised.”
“Attackers have broken this trust by surreptitiously infecting software with malware in the development and distribution process in ways virtually impossible to detect. In these instances, attackers have successfully compromised the software development cycle and inserted malware before the code has been compiled and signed – therefore, creating a package that includes malware undetectable by typical customers and anti-virus, anti-malware programs. In other instances, attackers have disrupted distribution channels by placing dummy code, updates, and patches on sites that customers use to obtain software releases and, ironically, security updates.”
Automotive Cybersecurity and Trustworthiness
Framework for Automotive Cybersecurity