8 Challenges of Automotive Cybersecurity

As vehicle technology advances to include more autonomy and higher degrees of connectivity, the number of electronic control units (ECUs) and overall complexity continues to increase. Today, a new vehicle might include over 100 million lines of code that manage and monitor a large array of subsystems including advanced driver assistance systems (ADAS), infotainment, collision avoidance, and engine/vehicle management. This creates openings for cybersecurity problems.

The National Highway Traffic Safety Administration (NHTSA) defines automotive cybersecurity as the “protection of automotive electronic systems, communication networks, control algorithms, software, users, and underlying data from malicious attacks, damage, unauthorized access, or manipulation.” This manipulation includes malice, such as a hacker who disables vehicle communications, disrupts navigation, or interferes with powertrain controls.

Unfortunately, manufacturers have done little to implement protective cybersecurity measures. No related automotive standards yet exist; ISO 26262, the automotive functional safety standard, merely stipulates that a manufacturer is responsible for ensuring that the vehicle is secure. This overall absence of attention translates into more risk to safety-critical systems and a growing liability that needs to be addressed.

1. Bloated Software Creates Exposure

If a body of software code is large and complex, there is a high probability that it will contain more defects than comparatively simple software. This is especially worrisome when considering the huge amount of software that is installed in modern cars.

“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 such a big difference? 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. Consequently, the manufacturers minimize the amount of code to only that which is absolutely necessary. Each line is repeatedly scrutinized and tested; this results in software that has fewer defects and is much easier to maintain. The auto industry is nowhere near this level of software quality and reliability.

2. Automotive Supply Chain Creates Vulnerabilities

The automotive industry has one of the largest and most complex supply chains in the U.S. This includes the frequent integration of third-party software, components, applications and communications protocols, presenting an array of major cybersecurity weaknesses and quality-control issues.

Cybersecurity protections are difficult with multiple players involved, each producing their own patch specifications and complying with different standards. A set of control units can be supplied by more than 20 different suppliers. Components provided by multiple distinct suppliers increases the level of risk. Moreover, the strength of an individual component may be lost in a poorly executed integration that results in a vulnerable network of interconnected elements.

A large number of 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. Consider that training, licensing, design and quality standards are enforced in all other engineering disciplines that touch aspects of human safety; lamentably, this is not the case for many types of automotive software.

The application of digital signatures to software is inconsistent. To maintain trust in the software, it should be signed when it is first built at the farthest point upstream in the supply chain. In addition, requirements should be in place to enable complete validation of the software to ensure its integrity at each level in the supply chain.

Suppliers are not always made aware of potential threats by others in the chain. A Tier 1 supplier may implement a part of a 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. Of course, these lower-tier suppliers may add defects and nonsecure features that compound the exposure to cybersecurity threats. It is common for a bad actor to start small at lower levels and then patiently lurk in one or more systems for years before deciding to attack.

Supply chain participants are tightly interconnected. We live in a world of digital buyer-seller partnerships, robotic process automation and the Internet of Things. While these arrangements provide a high degree of efficiency and convenience, the system is also inherently fraught with security risks. Cyber criminals are quite aware of these potential access points and are already exploiting them to enter internal networks that individually had been previously well-protected.

Though exposure to cyber damage is exponentially increasing, collaborating organizations often cannot control or scrutinize security measures elsewhere along the supply chain. This leads to an inability to manage security at a high level.

3. IT Cyber Solutions Don’t Readily Translate to Automotive

IT cybersecurity standards have been around for several decades (e.g., ISO/IEC 27001 and 27002, NIST, NERC/CIP). Considering the similarities – both IT and automotive contain essential networks of connected devices – why not simply map cybersecurity solutions from the IT world to automotive? Though analogous at a basic conceptual level, there are significant differences and corresponding challenges.

4. OEM and Suppliers – Most IT systems center around a single processor and some original equipment manufacturer (OEM) tweaks. It’s easy for the OEM to throw in a standard operating system and then function as an integration company. In the automotive industry, Tier 1 ECU suppliers develop most of the functionality. This includes power management, cryptography, memory management, drivers and communication protocols. The processor manufacturers are Tier 2 suppliers, so they have less impact on the final product while typically having an adverse effect on system complexity.

Also, since most vehicle OEMs focus on the mechanicals, the Tier 1 suppliers typically make all of the electronic design decisions. The OEMs develop the functional requirements, add a few general recommendations and dump in all of the automotive industry regulations. The key advantage for the Tier 1 supplier is nearly full responsibility for a component without any blame to assign to any other company for any defects or problems. The primary disadvantage is the inability to maintain a big-picture view of the system. None of the Tier 1 suppliers have a view of the entire vehicle, and none of the OEMs have a clear understanding of the ECU internals. The result is merely an integration of independent parts, rather than a unified architecture.

5. Multiple Interconnected Systems – A vehicle platform consists of many component types including sensors, simple logic circuits, complex onboard computers, embedded operating systems and proprietary chipsets. It’s challenging to combine Windows, macOS, Linux, and Java Virtual Machines into a single cohesive configuration.

6. Consequences of Malfunction — Software errors in a smartphone do not carry the same consequences as in a vehicle.

Let’s say, in a vehicle, you have an intrusion-detection system that decides that an incoming “brake signal” is corrupt. Results can be horrific if this detection is erroneous, the signal is ignored and the vehicle goes into a lake. What if the signal is a hack, not spotted as such, and the vehicle suddenly halts in rush-hour traffic? Responsibility, in either case, can be sticky. Many OEMs may simply decide that it is simpler to skip the intrusion-detection subsystem.

To correct any defects that may be discovered, software upgrades are a necessity. As with computers or consumer electronics, it has become rather easy to perform over-the-air (OTA) updates of virtually any vehicle component. However, if a fault or deficiency is found in an ECU, the supplier needs to conduct analysis and integrate a fix into the component. This must be supported by testing, and the OEM must account for all possible vehicle architecture variations. Inevitably, one of the tests will brick a component, or perhaps the entire vehicle, making an OTA update impossible. This results in a large number of “defective” cars cruising around that will not receive the upgrade until the next physical service event.

7. Time to Market – The average elapsed time from concept to vehicle production is four long years. This means that the major decisions affecting architecture, security concepts and operating systems occur nearly four years before vehicles roll off the final assembly line. Though suppliers endeavor to maintain software up to the point of production start, none of them would voluntarily replace an entire operating system kernel midway through development. This means that many, many months of additional hidden bugs, fixes, vulnerabilities, security methods and communication pathways go without scrutinization. If any of the new components fail in testing or threatens to delay production, the OEM will default to substituting a legacy ECU, rather than risking the new one.

8. Automotive Cybersecurity Requires Urgent Attention

Acceptable safety and trust in our vehicles cannot be realized without a cyber-secure framework. Even if safety-critical systems are designed for safety, resilience and reliability, disaster can still arise on our highways if vehicles are compromised by a malicious actor – especially with the potential to strike numerous systems in a single attack.

Standardization will provide a good starting point and foundation.

The existing functional safety standard for vehicles (ISO 26262) – applicable to design, implementation and manufacturing – requires the analysis of hazards and assessment of risks. Cybersecurity can be enhanced by ensuring that software threats are included in this exercise. Subsequent testing then validates that risks have been reduced to acceptable levels.

ISO Standard 21434, Automotive Cybersecurity, is currently under development. It builds on SAE J3061, Cybersecurity Guidebook for Cyber-Physical Vehicle Systems. Support of these standards will bring new assurance to security issues.

Finally, cybersecurity can be enhanced through the standardization of software architecture for automotive electronic control units. This is the aim of AUTOSAR (AUTomotive Open System ARchitecture). Founded in 2003, AUTOSAR is a “worldwide development partnership of vehicle manufacturers, suppliers, service providers and companies from the automotive electronics, semiconductor and software industry.” Standardized architecture creates the opportunity to automate software testing which should result in improved software quality and reliability.

Summary

There is a dire need in the industry for all suppliers to embrace proper security controls for their products and their development processes. Solutions may not always be easy; however, it must be realized that the repercussions of delay or avoidance can be substantial.

Interested in learning more about AUTOSAR for your organization? Contact our team today! 

Further reading and references

Automotive Cybersecurity and Trustworthiness 

Cybersecurity and the Automotive Supply Chain

Framework for automotive cybersecurity