6 min read

Framework for Automotive Cybersecurity

Picture of Steve Neemeh Steve Neemeh : Nov 12, 2021 11:13:57 AM

Cybersecurity

Framework for automotive cybersecurity

This is Part 3 of a three-part blog series on automotive cybersecurity. If you have not yet read Part 1: Automotive cybersecurity and trustworthiness, and Part 2: Cybersecurity and the automotive supply chain, we highly recommend that you do so before continuing with Part 3.

Part 3 explores the dire need for standardization and the development of a maturity model for automotive cybersecurity.

The automotive industry is desperately in need of guidance that will propel it toward viable cybersecurity — both for the supply chain and vehicle platforms. We propose that the way forward is to develop a framework that takes the form of a cybersecurity maturity model.

IT cybersecurity standards have been in existence for several decades, as providers and users have found it necessary to collaborate toward the production of capabilities, policies, and practices. There are several major IT cybersecurity standards, including ISO/IEC 27001 & 27002, NIST, and NERC/CIP. To date, there are no such standards that pertain to the automotive world.

IT cyber solutions don’t readily translate to automotive

Many professionals refer to the putative similarities between automotive and IT cybersecurity. Perhaps this is because they both contain essential networks of connected devices. Since there is similarity at this basic conceptual level, the question is often put forward: Why not simply map cybersecurity solutions over from the IT world to the automotive world? As one might expect, it’s not that simple. Many companies have gone down this path, with very little to show for the effort.

Automotive and IT cybersecurity differ in many critical ways:

OEM versus Tier 1 versus Tier 2 — Most IT systems center around a single processor and some OEM tweaks. It’s easy for an OEM to throw in a standard operating system and Voila! the OEM functions as an integration company. In the automotive industry, Tier 1 electronic control unit (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. But the wicket is much stickier than this.

Since most vehicle OEMs focus on 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 has a view of the entire vehicle, and none of the OEMs has a clear understanding of the ECU internals. This result is merely an integration of independent parts, rather than a unified architecture. Without question, this is a huge security problem that persists throughout the entire industry.

Accommodating error conditions — This is a big one. Let’s say your team creates an intrusion-detection system that decides the incoming “brake signal” is corrupt. What then? Consider the consequences if this adjustment is erroneous and the vehicle goes into a lake. Or, what if there is no error, and an attacker suddenly halts the car in rush-hour traffic? Precisely who is responsible in either case? Many OEMs simply decide that it is simpler and safer not to implement the intrusion-detection subsystem.

Multiple interconnected systems — A vehicle platform consists of many component types, including automotive sensors, simple logic circuits, complex onboard computers, embedded operating systems, proprietary chipsets, Linux-based systems, Java Virtual Machines, classic and adaptive ECU partitions, AT-based Modems, HSMs, and even hypervisors. It’s challenging to combine Windows and macOS into a single system.

The quagmire of upgrades — It has become rather easy to perform over-the-air updates of virtually any vehicle component. However, the supplier needs to conduct an analysis and integrate a fix into the component whenever a vulnerability is found in an ECU. Then comes the testing, and more testing. But then, the OEM must test across all possible vehicle architecture variations. Inevitably, one of the tests will brick a component — or perhaps the entire vehicle. Quite simply, this results in a large number of vulnerable cars cruising around that won’t get the upgrade until the next service event.

Speeding to market? Not quite. — The average elapsed time from concept to 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 unexplored. Even worse, 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.

Standardization — Perhaps foremost here is AUTomotive Open System ARchitecture (AUTOSAR), the global automotive partnership for standardized ECU software architectures. In addition, there are government initiatives, committees, ISO 26262, SAE 21434, and various other groups working to craft and enforce automotive standards. However, there is no apparent momentum, consensus, or guidance. Moreover, with such a high degree of complexity, variety, many editions of any given vehicle platform, and suppliers all over the globe, makes it especially challenging to achieve agreement on much at all.

Existing automotive safety and security models

There is essentially no automotive cybersecurity model currently available for guidance. Both the National Institute of Standards and Technology (NIST) and the Industrial Internet Consortium (IIC) have cybersecurity frameworks, but neither addresses automotive security. ISO 26262, the automotive functional safety standard, merely stipulates that a manufacturer is responsible for ensuring that the vehicle is secure.

When considering models to provide cybersecurity guidance, it is essential that the model does not define the implementation nor specify which industry players are winners and losers. A suitable automotive cybersecurity model should outline a path toward the maturation of security techniques. The cybersecurity guidelines must be testable and applicable to design, implementation, and manufacturing.

Pursuing an automotive security maturity framework

The Security Maturity Model (SMM) published by the IIC is a security framework that defines context, goals, and requirements. It helps manufacturers understand their security objectives and determine how best to invest in tools and practices that meet their needs and requirements. The SMM does not define what the appropriate security level should be. Instead, it provides guidance and structure for companies to consider maturity levels appropriate for their industry and product. Though the SMM does not directly address automotive security, it has many good characteristics that can be adopted and converted into a model for the automotive industry.

The IIC SMM defines measures of product effectiveness in meeting the requirements. It also defines:

Five comprehensiveness levels for every security domain, subdomain, and practice, from Level 0 to Level 4, with larger numbers indicating a higher degree of comprehensiveness.
Three levels of scope for every security facet, from Level 1 to Level 3, with higher numbers indicating a narrower and more specific scope.

The core of the SMM consists of many practices grouped into three domains: governance, enablement, and hardening.

Security governance addresses:

Strategy, business processes, legal and operational issues, reputation protection, and revenue generation.
Modeling of all threats and performing risk assessments.
Management of the supply chain and other external dependencies, to aim at controlling and minimizing system exposure to attacks from third parties that have privileged access and may use that access to conceal attacks.

Security enablement addresses:

Hardware and software solutions, such as cryptographic operations and identity management.
Identity and access management, the aim of which is to control resource usage by all agents to reduce the risk of information leakage, tampering, theft, or destruction.
Asset protection, including hardware root-of-trust, secure execution environment, and physical access protection.
Data protection, such as data at rest, data in motion, and data in use — in the vehicle, OTA updates, and through the cloud.

Security hardening addresses:

Vulnerability and patching/updating management.
Monitoring and information sharing.
Event and incident response management.

In crafting an automotive cybersecurity maturity model, each of the domains and subdomains above could be mapped to the automotive safety integrity levels (ASIL) functionality and safety levels in the ISO 26262 standard.

Applying the Security Maturity Model

We expect most organizations to first establish a maturity target. Business level stakeholders define the target using some form of a business objectives questionnaire. Technical level stakeholders then take such objectives and translate them into more detailed security requirements based on their understanding of the system.

Once a target has been created or a relevant industry profile identified, organizations would conduct an assessment to capture the current maturity state. The security maturity of the target state and current state can be compared to identify gaps and opportunities for improvement. Based on the gap analysis, business and technical stakeholders can establish a roadmap, take action, and measure progress.

After implementing enhancements, organizations can perform another assessment. The cycle repeats to ensure that the appropriate security target is always maintained in an ever-changing threat landscape.

Conclusion

Automotive trustworthiness is built upon a solid foundation of robust cybersecurity. In this three-part series, it has been shown that the industry is woefully behind in security standardization and regulation. Surprisingly, many new vehicle features lack adequate protection. Worse, the automotive supply chain has many points of exposure to malicious actors. Clearly, automotive cybersecurity is a problem that urgently requires standardization. The way forward is to develop an automotive security safety model that meets the needs of the entire industry.